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

[JP Vasseur <jvasseur@cisco.com>]

Hi Yakov,

On Oct 15, 2007, at 4:22 PM, Yakov Rekhter wrote:

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

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

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.

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

Thanks.

JP.

> Yakov.