[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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