Subject: Re: [CCAMP] poll on making draft-margaria-ccamp-lsp-attribute-ero-02 a WG document

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 10 Dec 2012 23:20:08 -0000

<very definitely speaking as an individual and not to be taken in any way as AD
input!>

When we defined the LSP attribute object, we deliberately did not include this
function. Our thinking was that we were defining attributes of the LSP and that
this function is defining behavior of specific nodes. Attributes of an LSP can
be classed as behavior of *all* nodes on the LSP, or behavior of the end points
of the LSP.

The two example use cases supplied by Mach in his email
(http://tools.ietf.org/html/draft-dong-ccamp-rsvp-te-mpls-tp-li-lb-05 and
http://tools.ietf.org/html/draft-dong-ccamp-rsvp-te-plr-designation-00) are
helpful for understanding the intention of the work, but seem to support my
understanding of the purpose.

If the authors have a different intention (i.e., not targeting instructions at a
specific node on the LSP) then it would be helpful if they spoke up.

Otherwise (and assuming that this function is actually needed!) I think it would
be helpful to reclass this as a normal subobject of a normal ERO. This would
allow the ERO to pass through nodes that do not support the new subobject
without having to define a new top-level object that will not be understood and
without complicating the ERO processing further. Obviously, returning the fact
that the new subobject was processed will require a new RRO subobject.

I do not much care whether this change is made before or after adoption as a WG
draft, but I do believe it should be discussed at some point, and my current
view is that the change should be made at some point.

I think adoption probably hinges on whether the WG believes that there is a need
to target commands at specific nodes on the LSP.

Cheers,
Adrian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Lou Berger
> Sent: 07 December 2012 20:48
> To: [email-masked]
> Subject: [CCAMP] poll on making draft-margaria-ccamp-lsp-attribute-ero-02 a
> WG document
> 
> All,
> 
> This is to start a two week poll on making
> draft-margaria-ccamp-lsp-attribute-ero-02 a ccamp working
> group document. Please send mail to the list indicating "yes/support"
> or "no/do not support".  If indicating no, please state your technical
> reservations with the document.
> 
> The poll ends Friday December 21.
> 
> Much thanks,
> Lou (and Deborah)
> 
> PS We're still waiting on one IPR statement.
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp

---

From: "Margaria, Cyril (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 11 Dec 2012 09:40:35 +0100

Hi, 

Thanks for your input, Please see inline.

Best regards / Mit freundlichen Grüßen
Cyril Margaria

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of ext Adrian Farrel
> Sent: Tuesday, December 11, 2012 12:20 AM
> To: 'Lou Berger'; [email-masked]
> Subject: Re: [CCAMP] poll onmaking draft-margaria-ccamp-lsp-attribute-
> ero-02 a WG document
> 
> <very definitely speaking as an individual and not to be taken in any
> way as AD input!>
> 
> When we defined the LSP attribute object, we deliberately did not
> include this function. Our thinking was that we were defining
> attributes of the LSP and that this function is defining behavior of
> specific nodes. Attributes of an LSP can be classed as behavior of
> *all* nodes on the LSP, or behavior of the end points of the LSP.
> 
> http://tools.ietf.org/html/draft-dong-ccamp-rsvp-te-plr-designation-00)
> are helpful for understanding the intention of the work, but seem to
> support my understanding of the purpose.
> 
> If the authors have a different intention (i.e., not targeting
> instructions at a specific node on the LSP) then it would be helpful if
> they spoke up.

This is our intention to target instruction at specific node, in addition 
this mechanism is also useful for draft-ietf-ccamp-wson-signaling.

> Otherwise (and assuming that this function is actually needed!) I think
> it would be helpful to reclass this as a normal subobject of a normal
> ERO. This would allow the ERO to pass through nodes that do not support
> the new subobject without having to define a new top-level object that
> will not be understood and without complicating the ERO processing
> further. Obviously, returning the fact that the new subobject was
> processed will require a new RRO subobject.

This was the feedback of the last Meeting, we agree on this mechanism and 
it will be included in the next revision (pre or post WG adoption, this was BTW in -00).
We will take into account the feedback of the processing in the RRO.

> I do not much care whether this change is made before or after adoption
> as a WG draft, but I do believe it should be discussed at some point,
> and my current view is that the change should be made at some point.
> 
> I think adoption probably hinges on whether the WG believes that there
> is a need to target commands at specific nodes on the LSP.
> 
Thanks a lot for your input.

> > From: [email-masked] [mailto:[email-masked]] On
> Behalf
> > Of Lou Berger
> > Subject: [CCAMP] poll on making
> > draft-margaria-ccamp-lsp-attribute-ero-02 a WG document
> >
> > All,
> >
> > draft-margaria-ccamp-lsp-attribute-ero-02 a ccamp working group
> > document. Please send mail to the list indicating "yes/support"