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

[Yakov Rekhter <yakov@juniper.net>]

JP,

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

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.