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

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 19 Oct 2009 23:06:03 +0100

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: <[email-masked]>
To: <[email-masked]>
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-hop-attributes-00.txt

---

From: András Kern <[email-masked]>
Date: Tue, 20 Oct 2009 15:25:55 +0200

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:[email-masked]] 
> Sent: Tuesday, October 20, 2009 12:06 AM
> To: Attila Takacs; András Kern
> Cc: [email-masked]
> 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
>