Re: accepting draft-fedyk-bgp-te-attribute-02.txt as a CCAMP WG document

[Yakov Rekhter <yakov@juniper.net>]

JP,

> >>>>>>> 2. Could you conceive of using your I-D to meet the requirements
> >>>>>>> of the Vasseur I-D?
> >>>>>> In order for me to answer this question I'd like to get a clear
> >>>>>> description of the requirements of the Vasseur I-D.
> >>>>>
> >>>>> I'm not trying to fight JP's battles for him.
> >>>>> Just trying to find out whether we have two problem spaces or one.
> >>>>>
> >>>>> I think the abstract of his I-D is relatively clear:
> >>>>>
> >>>>>   This document proposes MP-BGP protocol extension so as to convey
> >>>>>   Traffic Engineering Link characterictics of PE (Provider Edge) - CE
> >>>>>   (Customer Edge) links in order to extend the visibility of the
> >>>>>   Traffic Engineering Database to those links.  This can then be used
> >>>>>   to more efficiently compute CE-to-CE Traffic Engineering Label
> >>>>>
> >>>>
> >>>> Yakov, let me know if you need further clarification on the
> >>>> application ... sounds
> >>>> pretty obvious, extend the TED to some PE-CE links where a CE to CE
> >>>> TE LSP
> >>>> is needed. The path computation piece is then very much similar to
> >>>> inter-domain TE (per domain, PCE, ...).
> >>>
> >>> Given the above I could conceive of using the BGP TE attribute, as
> >>> defined in draft-fedyk-bgp-te-attribute, to meet the requirements
> >>> of your I-D. I hope that answers Adrian's question.
> >>
> >> Well for the CE to CE application, we need all TE link attribute for
> >> the PE-CE links, thus our proposal to reuse the TE link attributes
> >> already defined for the IGPs ?
> >
> > If there is a CCAMP WG consensus to add additional information to
> > what is currently specified in the BGP TE attribute the authors of
> > draft-fedyk-bgp-te-attribute have no problems with adding this info
> > to what is presently specified in draft-fedyk-bgp-te-attribute.
> >
> 
> On the first question, I do not think that there is yet a CCAMP consensus
> (on both drafts by the way). Furthermore, if we can agree to simply reuse
> the IGP-TE TLVs to be carried in BGP for the "PE-CE" links we are  
> effectively merging the two IDs, which I had proposed to do since 
> a single draft would then serve both applications and may be future 
> ones. Makes sense ?

No, it does *not* make sense, and here is why. There should be a
separate draft that just defines the BGP TE attribute. Then there
may be one or more other drafts that describe applications that
*use* the BGP TE attribute. Such drafts would just point to the
first draft.

draft-fedyk-bgp-te-attribute is the former - it just defines the
BGP TE attribute. draft-vasseur-ccamp-ce-ce-te-02 is the latter  -
it defines an application that uses the BGP TE attribute. That is
precisely why it does not make any sense to merge the two IDs.

Yet another reason why merging the two IDs does not make sense is
that the BGP TE attribute, as specified in draft-fedyk-bgp-te-attribute,
carries the *GMPLS* TE information, while in your draft you propose
to carry just *MPLS* TE, but *not* GMPLS TE information. Quoting
from your draft:

   This document also defines a new attribute called the
   TE attribute which carries the set of sub-TLVs defined in [RFC3784].
   The format of the BGP TE attribute will be defined in a further
   revision of this document.

Note that rfc3784 is about *MPLS* TE extensions. GMPLS TE extensions
are defined in rfc4203.

Wrt reusing the IGP-TE TLVs, if you look at what is carried in the
BGP TE attribute, as specified in draft-fedyk-bgp-te-attribute, you
should be able to notice that is has precisely the same encoding
as the Interface Switching Capability Descriptor sub-TLV (as defined
in rfc4203). 

Yakov.