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

["Adrian Farrel" <adrian@olddog.co.uk>]

Yet another draft without an agenda slot, and once again I'm a co-author. So, again,
Kireeti is arbiter.

If you recall, this draft is the result of merging a couple of drafts in related areas in
order to produce a single view of the control and reporting of component links.

A little while back there was some discussion on the list about this draft raising a
couple of concerns (as far as I recall).
I have summarised these below as far as I remember them, but would appreciate input from
the people who raised the issues (and anyone else).

[On re-reading the draft I see a number of editorial issues that I will sort out with my
co-authors.]

Thanks,
Adrian


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.

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