Cheers,
Adrian
----- Original Message -----
From: "Yakov Rekhter" <yakov@juniper.net>
To: "Adrian Farrel" <adrian@olddog.co.uk>
Cc: "Yakov Rekhter" <yakov@juniper.net>; <softwires@ietf.org>;
<ccamp@ops.ietf.org>
Sent: Tuesday, September 09, 2008 6:55 PM
Subject: Re: Meanwhile, back on topic (BGP-TE)
> Adrian,
>
>> Hi Yakov et al.,
>>
>> Thanks for the 02 revision
>>
>> The new text in the Abstract and Introduction goes a long way to
>> addressing
>> my concerns.
>>
>> The scope and applicability of this attribute currently excludes
>> its
>> use for non-VPN deployment scenarios.
>
> Glad to hear this.
>
>> But it doesn't answer my multi-AS question. What will an ASBR
>> advertise
>> onwards?
>
> ASBRs just re-advertise VPN routes without modifying TE attribute
> of these routes.
>
>> The TE parameters that it receives from the source PE are the TE
>> parameters
>> of the PE-CE link to a specific port. If it advertises those
>> parameters
>> it
>> is clearly not advertising the TE parameters of the route, but I am
>> not
>> clear how a BGP speaker down the line can tell that this is just the
>> PE-CE
>> link that is being described. But to do otherwise would imply that the
>> ASBR
>> is making some assessment of the TE route available from the ASBR to
>> the
>> PE.
>
> The TE information is associated with a *VPN* route, not with the
> (non-VPN) route from the ASBR to the PE.
>
>> This is the question I was trying to raise about "TE aggregation"
>> (which
>> is
>> *not* route aggregation).
>>
>> It seems to me that this whole question is either out of scope of
>> requiring
>> significant future study.
>
> It seems to me that this whole question is due to the lack of
> understanding that the TE attribute is associated with a VPN route
> originated by a PE, not with a (non-VPN) route to the PE that
> originates the VPN route. The TE attribute of a VPN route is
> propagated "as is" by the VPN service provider(s), without any
> modifications.
>
> To make it clear that the draft only deals with using BGP TE
> attribute for VPN routes I would propose the following changes:
>
> 1. Section 1 and Section 2 replace
>
> The scope and applicability of this attribute currently excludes its
> use for non-VPN deployment scenarios.
>
> with
>
> The scope and applicability of this attribute currently excludes its
> use for non-VPN reachability information.
>
> 2. Section 2 replace
>
> In certain cases (e.g., L1VPN [RFC5195]) it may be useful to augment
> reachability information carried in BGP with the Traffic Engineering
> information.
>
> with
>
> In certain cases (e.g., L1VPN [RFC5195]) it may be useful to augment
> VPN reachability information carried in BGP with the Traffic
> Engineering
> information.
>
>> Probably the solution that can get us to closure most quickly is one
>> where
>> we update your new text to say...
>>
>> The scope and applicability of this attribute is currently limited
>> to
>> single-AS VPN deployment scenarios.
>
> So far you did not present any technical reason(s) to justify
> imposing this limitation.
>
>> I would also like to see a something added to Section 4 along the
>> lines
>> of...
>>
>> Traffic engineering aggregation is the process of reporting a set
>> of
>> TE
>> parameters for a single route where multiple paths exist across the
>> domain. The results of TE aggregation MUST NOT be advertised
>> using the Traffic Engineering Attribute.
>
> Could you please illustrate how the concept of "traffic engineering
> aggregation" is applicable in the context of VPN routing information
> advertised in BGP.
>
> Yakov.
>