RE: draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt

[John Drake <jdrake@calient.net>]

Snipped
 
> 
> 1. Does this draft add anything at all?
> Isn't everything you need to know about bundling already covered in
> 3471/3/7 and the BUNDLE draft?
> 
> 2. Why is it necessary to define new unnumbered component link
> identifiers?
> 
> If I recall, there was some acceptance that the draft was necessary to
> define route
> recording of component link choice on the basis both that it might be
> useful and to
> provide symmetry with label recording [RFC3209]. At the same time (and for
> similar
> reasons) ERO specification/control of component link might be desirable. I
> believe this
> takes care of the first issue.
[John Drake] 

If one uses the type 3 (IF_IINDEX) TLV, as stipulated in the bundling draft,
then there is no issue to be solved.  Per the bundling draft and RFC 3477, a
selected component link will be carried in the RRO and can then be placed in
the ERO of a subsequent Path message.  So this I-D is not needed to address
that problem.

> 
> The second issue is more controversial. The view against the draft says
> that it is
> possible to identify a component link using IF_ID TLVs of type 4 and 5
[John Drake] 

From the bundling draft:

"If the component link is unnumbered, the IF_ID RSVP_HOP object, or
 IF_ID TLV carries Type 3 (IF_INDEX) TLV (see [GMPLS-SIG]). The value
 carried in Type 3 TLV contains the identifier of the selected
 component link assigned to the link by the sender of the Path/REQUEST
 message."

.
> These TLVs contain
> an IP address and a component link ID.
> The claim of (some of) the authors is that this is fine if the bundle is
> identified by an
> IP address (i.e. is numbered) - in this case the component link ID is a
> reference within
> the bundle.
> It is also OK if the bundle is unnumbered and the component link ID is
> unique across the
> node - in this case the IP address identifies the node and the component
> link can be found
> and the bundle deduced by a reverse lookup (we assume that a component
> link is a member of
> just one bundle).
> Note that it is not necessary for the component link ID to come from the
> same space as the
> unnumbered interface IDs (as the draft seems to say) because a different
> TLV type number
> is used.
> The problem arises if the component link IDs are unique only within the
> context of a
> bundle and not across the whole box. In this case, it is necessary to
> identify the bundle
> and the component link ID. This can be done for numbered bundles using the
> existing TLVs,
> but no mechanism exists to identify the component link of an unnumbered
> bundle in this
> case. The draft defines new TLVs to make this possible.
> The detractors say that this is not necessary because we can force the
> component links to
> have unique identities across the whole LSR. The supporters say yes, but
> why would you
> want to make this requirement when, clearly, bundle membership defines a
> hierarchy of
> identification.
[John Drake] 

From the bundling draft:

"A component link may be either numbered or unnumbered. A bundled link
 may itself be numbered or unnumbered independent of whether the
 component links of that bundled link are numbered or not."

and:

"Furthermore, link local identifiers for all unnumbered links of a given LSR
(whether component links, Forwarding Adjacencies or bundled links) MUST be
 unique in the context of that LSR."

So, what the authors of this I-D are attempting to do is redefine the
meaning of 'component link'.