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

From: John Drake <[email-masked]>
Date: Thu, 22 Jul 2004 15:28:47 -0700

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'.

---

From: dimitri papadimitriou <[email-masked]>
Date: Fri, 23 Jul 2004 10:49:58 +0200

john, see in-line

John Drake wrote:

>> 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?
>> 
>> 
>> 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]
> 

the drafts mentions that "When link bundling is used to aggregate multiple
component links into a TE link bundle, the label is not the only resource that
needs to be identified and recorded.In other words, the TE link bundle
identifier and the label value specified in the ERO/RRO objects are not enough
to completely identify the resource."

at least to make things clear it is meant to avoid situation where in the RRO
you [TE link and label recording] you're remark is but the use [component link
and label] it works if you make the assumption that you can retrieve the
association at the ingress (which is not commonly the case by definition of
bundling)

>> that it is possible to identify a component link using IF_ID TLVs of type 4
>> and 5

yes it is more controversial

> [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."

signaling processing from RFC 3473 which are the corner stone of the discussion

"For bidirectional LSPs, the sender chooses the data interface in each
direction. In all cases but bundling, the upstream interface is implied by the
downstream interface. For bundling, the path sender explicitly identifies the
component interface used in each direction."

as most non-packet LSPs are bi-directional and make commonly use of bundling we
are in a situation where once bundling is used, the second sentence does not
apply and all IF_ID's are making use these two type

now the link bundling draft mentions (and points to 3473)

" Signaling must identify both the component link to use and the label to use.
The choice of the component link to use is always made by the sender of the
Path/REQUEST message (if an LSP is bidirectional [GMPLS-SIG], the sender chooses
a component link in each direction). For unidirectional LSPs, and the forward
direction of bidirectional LSPs, the sender of a Resv/MAPPING message chooses
the label. For the reverse direction of a bidirectional LSP, the sender of the
Path/REQUEST message selects the upstream label.

With RSVP the choice of the component link is indicated by the sender of the
Path message by including the IF_ID RSVP_HOP object in the Path message, as
described in section 8 of [GMPLS-RSVP]."

>> 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 
>> hierarchy of identification.

this one is even more controversial it comes from the issue based on the 
definition here below

> [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."

from RFC 3471 "The IP address field may carry either an IP address of a link or 
an IP address associated with the router, where associated address is the value 
carried in a router address TLV of routing."

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

point here above two usage of the "IP address" and you will see that the authors 
have spent time to sort out a complex intrication between several drafts