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

[JP Vasseur <jvasseur@cisco.com>]

Hi Yakov,


> From: Yakov Rekhter <yakov@juniper.net>
> Date: Mon, 19 Nov 2007 12:51:55 -0800
> To: JP Vasseur <jvasseur@cisco.com>
> Cc: Yakov Rekhter <yakov@juniper.net>, Adrian Farrel <adrian@olddog.co.uk>,
> <ccamp@ops.ietf.org>
> Subject: Re: accepting draft-fedyk-bgp-te-attribute-02.txt as a CCAMP WG
> document 
> 
> 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 ?

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.

> 
> Yakov.