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

[Yakov Rekhter <yakov@juniper.net>]

Adrian,

> Yakov,
> 
> OK, that helps a lot. 

Glad to hear this.

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

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.

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