Re: Meanwhile, back on topic (BGP-TE)

[Yakov Rekhter <yakov@juniper.net>]

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.