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

[John Drake <jdrake@calient.net>]

Dimitri,

I would agree with you that there are some issues with 3471/3473.  However,
this I-D just adds more complexity.

Thanks,

John

> -----Original Message-----
> From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com]
> Sent: Friday, July 23, 2004 1:50 AM
> To: John Drake
> Cc: Adrian Farrel; ccamp@ops.ietf.org; Zafar Ali; Dimitri Papadimitriou;
> aruns@movaz.com; 'Anca Zamfir'
> Subject: Re: draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt
> 
> 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?
> >>
> >>
> >> 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 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)
> 
> >> 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
> 
> 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
> >> want to make this requirement when, clearly, bundle membership defines
> a
> >> 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."
> 
> > 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'.
> 
> 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