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

From: Yakov Rekhter <[email-masked]>
Date: Wed, 07 Nov 2007 07:43:21 -0800

JP,

> Hi Yakov,
> 
> Sorry for the delay, I had missed that one - in line.

no problems... response in-line...

> >>>>>>>>>>> 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.
> 
> Sure my concern is basically to see an ID redefining all TE related
> attributes rather than carrying in a new BGP attributes all TLVs
> that have been defined already for IGPs ?
> 
> >
> >>> 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.
> 
> No no ... I'm proposing to define a BGP attribute carrying the IGP TE  
> TLV.

So, you do not want to withdraw your proposal to merge
draft-fedyk-bgp-te-attribute and your draft. Correct ? If yes, then
what your proposal to define a BGP attribute carrying the IGP TE
has to do with your proposal to merge these two drafts ?

> >>> 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.
> 
> Well this is the approach of (potentially) redefining everything as  
> opposed to carrying the IGP TE TLV in that new BGP attribute ?

Here is the list of IGP(OSPF) TE TLVs, as defines in rfc3630:

      1 - Link type
      2 - Link ID 
      3 - Local interface IP address 
      4 - Remote interface IP address
      5 - Traffic engineering metric
      6 - Maximum bandwidth 
      7 - Maximum reservable bandwidth
      8 - Unreserved bandwidth 
      9 - Administrative group

rfc4203 adds the following TE TLVs to the above list:

     11 - Link Local/Remote Identifiers
     14 - Link Protection Type
     15 - Interface Switching Capability Descriptor
     16 - Shared Risk Link Group

Do you propose to carry all of the above TLVs in a single BGP
attribute ?

If yes, do you propose to carry just what is listed above, or do
you propose to carry some other TLVs, in addition to what is listed
above ?

If you propose to carry only some (but not all) of the above TLVs,
then which of the above TLVs do you propose to carry ?

Yakov.

---

From: JP Vasseur <[email-masked]>
Date: Fri, 09 Nov 2007 09:12:08 -0500

Hi Yakov,

[snip]

> then which of the above TLVs do you propose to carry ?

I think that we first need to agree on the approach ... You define a new BGP
attribute to carry some Link attributes whereas we propose to define a
generic BGP attribute used to carry TE Link attributes that have already
been defined for IGPs. If, as I think, your intention is to carry in that
BGP attributes physical link attributes (as opposed to any form of
aggregated TE information), then why not reusing existing TE TLVs that have
already been defined for IGPs ?

If we agree to adopt this approach, my proposal was to (1) define a generic
BGP attribute with (2) application use cases companion documentS.

(1) Could be yours if you agree with the changes.
(2) draft-vasseur-ccamp-ce-ce-te could point to (1) and document the CE to
CE use case.

Thoughts ?

Thanks.

JP.

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 19 Nov 2007 12:51:55 -0800

JP,

> BGP attribute with (2) application use cases companion documentS.

Before we start to discuss how to encode information in BGP, we
first need to settle on what information to encode.

With this in mind I am still waiting for you to answer my question
above.  Namely, out of all the TLVs I listed above do you propose
to carry all of them in BGP ? If not then which one ?

Yakov.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 19 Nov 2007 13:10:27 -0800

Hi JP,

> You define a new BGP
> been defined for IGPs.

Can you also clarify what NLRI/NLRIs this new attribute will be 
"attached" to ? In IGPs we do flood links and nodes ... in BGP we 
distribute reachability to particular prefixes.

Also could you clarify how based on such NLRI it will be inserted into 
TE database in the peering AS ?

Thx,
R.

---

From: JP Vasseur <[email-masked]>
Date: Wed, 21 Nov 2007 17:55:14 -0500

Hi Yakov,

> From: Yakov Rekhter <[email-masked]>
> Date: Mon, 19 Nov 2007 12:51:55 -0800
> To: JP Vasseur <[email-masked]>
> Cc: Yakov Rekhter <[email-masked]>, Adrian Farrel <[email-masked]>,
> <[email-masked]>
> Subject: Re: accepting draft-fedyk-bgp-te-attribute-02.txt as a CCAMP WG
> document 
> 
> JP,
> 

As far as the CE to CE application is concerned (our ID) we basically need
all the attributes specified in RFC3630/3784.
By the way, just a quick note to mention that the aim of our ID is to
optimize the path computation of a CE to CE LSPs thus avoiding a single PCE
(PE the head-end CE is attached to) when computing the shortest constrained
CE to CE path as opposed to two PCEs using the BRPC procedure for a TE LSP
traversing 3 domains.

Cheers.

JP.