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.
> 
> Unfortunately, as defined, it is not generic enough to support other
> applications.

As I said before (in my e-mail on Oct 10):

   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.

> > 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.
> 
> With the major difference being that we proposed to reuse the IGP TE  
> TLVs.
> 
> We do agree on using BGP to carry TE related data such such "external"
> links but why not reusing the IGP TE TLVs instead of defining a new BGP
> attribute 

In BGP all the information is carried as BGP *attributes* - one can
not take IGP TE TLVs and stuff then "as is" into a BGP Update
message. Which means that carrying any new information in BGP
*requires* to define a new BGP attribute (that is precisely why we
defined a new BGP TE attribute).

Hopefully that answer your question of "why not reusing the IGP TE
TLVs instead of defining a new BGP attribute".

>         that will not have the ability to support other  
> applications. 
> In particular, for the CE to CE case, we'll need all the TE link
> characteristics, as defined in IGP TE.

See my first comment above.

> The approach of having a generic ID defining the protocol details and  
> other applicability statement is fine but I'd rather have a different  
> approach for that generic draft.

So, you withdraw the suggestion you made in your e-mail on Oct 11
to merge draft-fedyk-bgp-te-attribute and your draft.
  
> > 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.
> 
> Of course, the same approach can be taken for GMPLS.
> 
> > 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).
> 
> Absolutely, but it does not have the appropriate MPLS TE attributes,
> (TE metrics, colors, but also other TLVs defined in other RFCs)
> hence my proposal to reuse the MPLS and GMPLS TE extensions
> specified for IGP TE.

See my comments above.

With all this in mind let me suggest that if you think BGP needs
to carry more information than what is currently defined in
draft-fedyk-bgp-te-attribute, then after CCAMP WG accepts
draft-fedyk-bgp-te-attribute as a CCAMP WG document you get consensus
of the CCAMP WG that this information is indeed has to be added,
and then we'll add it to the document.

Yakov.