Re: [mpls] I-D ACTION:draft-ietf-mpls-explicit-resource-control-bundle-03.txt

["Adrian Farrel" <[e-mail]>]

Hi Anca,

Interesting to see this draft back again. I think it expired in April 2007 
and I had assumed we had given up on it.

A couple of thoughts...

===

In the terminology section you have:
   For unnumbered component links, the component link
   ID is assumed to be unique on an advertising node.

I think this reflects exactly what was discussed several IETFs ago (possibly 
in CCAMP with respect to the hierarchy-bis draft or maybe 
draft-ietf-ccamp-gmpls-addressing-03). However, don't you need to have some 
RFC 2119 language here? Failing this assumption will break your draft, so 
this is a "MUST" in which case I suggest you move it from the Terminology 
section to the main body of the draft.

===

More generally, way back in March 2006, in Dallas, CCAMP discussed how to 
build EROs and RROs in order to qualify this in 
draft-ietf-ccamp-gmpls-addressing (now RFC 4990). We had a survey and 
published the results in 
http://www.watersprings.org/pub/id/draft-farrel-ccamp-ero-survey-00.txt. The 
conclusion seemed to be that implementations of bundling simply reported 
(and signaled) component links by including two sequential interface IDs, 
the first indicating the TE link and the second the component link. There 
was no need to use different subobject types for these two pieces of 
information as their ordering and context was sufficient.

I recall that in the discussions it was even suggested that it was not 
necessary to include both the TE link ID and the component link ID as the 
component link ID actually has global scope even if it does not have global 
visibility. But the survey seemed to indicate that people wanted to "play 
safe" and include both identifiers.

===

Part of the question may hinge on the U-bit that you have defined for your 
new suobjects. This bit allows different component links to be used in each 
direction. Have we had a thorough discussion of this requirement? Last time 
I talked to people about this, it seemed to be the case that, just as we 
would not split a bidirectional LSP across separate TE links in each 
direction, we would not split an LSP across separate component links in each 
direction. After all, component links are just TE links that are bundled for 
advertisement.

It was suggested that component links might be unidirectional components of 
a bidirectional bundle. But surely, just as with TE links, unidirectional 
data channels are paired to form bidirectional data links.

I note, however, that RFC 4990 decided to allow different component links to 
be used in each direction with some (rather unclear) suggestion that 
ordering the subobjects is enough to allow you to determine the direction.

===

So, we come to the big question. Why do we need to change existing 
implementations and introduce a different way of encoding EROs and RROs for 
bundled links?

Cheers,
Adrian

PS. I think that introducing a flag "component link recording desired" is a 
great idea.




----- Original Message ----- 
From: <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Sent: Wednesday, April 02, 2008 8:15 PM
Subject: [mpls] I-D 
ACTION:draft-ietf-mpls-explicit-resource-control-bundle-03.txt


>A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Multiprotocol Label Switching Working 
> Group of the IETF.
>
> Title : Component Link Recording and Resource Control for TE Link Bundles
> Author(s) : A. Zamfir
> Filename : draft-ietf-mpls-explicit-resource-control-bundle-03.txt
> Pages : 12
> Date : 2008-4-2
>
> Record Route is a useful administrative tool that has been used
>   extensively by the service providers. However, when TE links are
>   bundled, identification of label resource in Record Route Object
>   (RRO) is not enough for the administrative purpose. Network service
>   providers would like to know the component link within a TE link that
>   is being used by a given LSP. In other words, when link bundling is
>   used, resource recording requires mechanisms to specify the component
>   link identifier, along with the TE link identifier and Label. As it
>   is not possible to record component link in the RRO, this draft
>   defines the extensions to RSVP-TE [RFC3209] and [RFC3473] to specify
>   component link identifiers for resource recording purposes.
>
>   This draft also defines the Explicit Route Object (ERO) counterpart
>   of the RRO extension. The ERO extensions are needed to perform
>   explicit label/ resource control over bundled TE link. Hence, this
>   document defines the extensions to RSVP-TE [RFC3209] and [RFC3473] to
>   specify component link identifiers for explicit resource control and
>   recording over TE link bundles.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-mpls-explicit-resource-control-bundle-03.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>


--------------------------------------------------------------------------------


> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
> 


_______________________________________________
mpls mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mpls