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

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 9 Sep 2008 00:01:32 +0100

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.

But it doesn't answer my multi-AS question. What will an ASBR advertise 
onwards?

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.

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.

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.

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.

Cheers,
Adrian

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 09 Sep 2008 10:55:00 -0700

Adrian,

>    use for non-VPN deployment scenarios.

Glad to hear this.

> But it doesn't answer my multi-AS question. What will an ASBR advertise 

ASBRs just re-advertise VPN routes without modifying TE attribute
of these routes.

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

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.

>    single-AS VPN deployment scenarios.

So far you did not present any technical reason(s) to justify
imposing this limitation.

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 9 Sep 2008 19:22:42 +0100

Yakov,

OK, that helps a lot. My concern was that to be fully useful, the VPN route 
TE information needs to be combined with TE information about the potential 
paths to the PE.

What I did not want to see was that the VPN route TE information would be 
updated by a transit node to reflect any information about the path to the 
PE.

This appears to be a limitation you intended to impose, so it is just about 
getting the words right. I like what you have suggested below. Can you add 
some form of "...and MUST NOT be modified by any other BGP speaker..." or do 
you consider that part of the definition of the attribute inherited from the 
base BGP spec?

Cheers,
Adrian

----- Original Message ----- 
From: "Yakov Rekhter" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: "Yakov Rekhter" <[email-masked]>; <[email-masked]>; 
<[email-masked]>
Sent: Tuesday, September 09, 2008 6:55 PM
Subject: Re: Meanwhile, back on topic (BGP-TE)

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 09 Sep 2008 14:16:50 -0700

Adrian,

> OK, that helps a lot. 

Glad to hear this.

> My concern was that to be fully useful, the VPN route 

How about adding the following:

  Procedures for modifying the Traffic Engineering attribute,
  when re-advertising a route that carries such attribute
  are outside the scope of this document.

Yakov.

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 9 Sep 2008 22:42:31 +0100

Perfect.
Thanks for your patience.
Adrian
----- Original Message ----- 
From: "Yakov Rekhter" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: "Yakov Rekhter" <[email-masked]>; <[email-masked]>; 
<[email-masked]>
Sent: Tuesday, September 09, 2008 10:16 PM
Subject: Re: Meanwhile, back on topic (BGP-TE)

>> >> of the PE-CE link to a specific port. If it advertises those 
>> >> parameters
>> >> it
>> >> is making some assessment of the TE route available from the ASBR to 
>> >> the
>> >> PE.
>> >
>> >> This is the question I was trying to raise about "TE aggregation" 
>> >> (which
>> >> is
>> >>    Traffic engineering aggregation is the process of reporting a set 
>> >> of
>> >> TE