Re: [CCAMP] I-D Action:draft-kern-ccamp-rsvpte-hop-attributes-00.txt

[András Kern <[e-mail]>]

Hi Adrian,

The considered use case is to enable configuring non-intrusive and/or 
tandem connection monitoring entities for OTN networks: to carry 
endpoint identification and monitoring parameter encoding structures. 
The update of draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext (should be uploaded by next Monday) will make use of the new ERO subobject.
 
This placeholder (HOP_ATTRIBUTES subobject) may be useful in other 
cases as well, like for instance WSON. That is why it has been 
submitted as a separated document.
 
As an alternative I have considered using the LSP_REQUIRED_ATTRIBUTES, 
but in that case there may be a mismatch between the hops encoded in 
the LSP_REQUIRED_ATTRIBUTES and the hops that will be actually used, 
i.e., the ones specified in the ERO.
 
The scope of the RRO_ATTRIBUTES is different, it encodes LSP related attributes, these will likely be different form the the hop related  attributes. That is why a new subobject is proposed. However, curently I do not see a clear use case for HOP ATTRIBUTES in the RRO. So merging with RRO_ATTRIBUTES may be possible.
 
Best Regards
Andras 

> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]] 
> Sent: Tuesday, October 20, 2009 12:06 AM
> To: Attila Takacs; András Kern
> Cc: [e-mail]
> Subject: Fw: I-D Action:draft-kern-ccamp-rsvpte-hop-attributes-00.txt 
> 
> Hi,
> 
> Did you notice that RFC 5420 allows the recording of per 
> attributes in the RRO using the RRO Attributes Subobject as 
> defined in section 7.2?
> 
> I would suggest you should not define a duplicate of this 
> function, and if you need similar function in the ERO you 
> should use the same subobject type and number.
> 
> The RRO Attributes Subobject collects only flags (not TLVs). 
> This was a deliberate decision based on scalability and there 
> being no defined requirements for collecting TLVs.
> 
> Similarly, we did not define an ERO Attributes Subobject, 
> because there was no defined requirement to have an LSP 
> behave differently on different hops.
> 
> I think that it might be useful if you could set out your 
> requirements before extending the protocol in this way.
> 
> Cheers,
> Adrian
> 
> ----- Original Message -----
> From: <[e-mail]>
> To: <[e-mail]>
> Sent: Monday, October 19, 2009 4:45 PM
> Subject: I-D Action:draft-kern-ccamp-rsvpte-hop-attributes-00.txt
> 
> 
> >A New Internet-Draft is available from the on-line Internet-Drafts 
> >directories.
> >
> > Title           : Encoding of Attributes of LSP 
> intermediate hops using 
> > RSVP-TE
> > Author(s)       : A. Kern, A. Takacs
> > Filename        : draft-kern-ccamp-rsvpte-hop-attributes-00.txt
> > Pages           : 10
> > Date            : 2009-10-19
> >
> > RFC5420 specifies a general framework to support signaling and
> > reporting of generic attributes relevant for a signaled LSP.  This
> > document extends the concept and defines a new Explicit Route
> > subobject for RSVP-TE to allow the specification and reporting of
> > attributes relevant to a particular hop of the signaled LSP.
> >
> > A URL for this Internet-Draft is:
> > 
> http://www.ietf.org/internet-drafts/draft-kern-ccamp-rsvpte-ho
> p-attributes-00.txt
> 
>