[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Hi Yakov,

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

On Oct 16, 2007, at 9:55 AM, 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.


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

Cheers.

JP.



Yakov.