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