Meanwhile, back on topic (BGP-TE)

[Adrian Farrel(IETF CCAMP WG)]

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


_______________________________________________
Softwires mailing list
Softwires@...
https://www.ietf.org/mailman/listinfo/softwires

[Yakov Rekhter]

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.
_______________________________________________
Softwires mailing list
Softwires@...
https://www.ietf.org/mailman/listinfo/softwires

[Adrian Farrel(IETF CCAMP WG)]

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" <yakov@...>
To: "Adrian Farrel" <adrian@...>
Cc: "Yakov Rekhter" <yakov@...>; <softwires@...>;
<ccamp@...>
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.
>

_______________________________________________
Softwires mailing list
Softwires@...
https://www.ietf.org/mailman/listinfo/softwires

[Yakov Rekhter]

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@...>
> To: "Adrian Farrel" <adrian@...>
> Cc: "Yakov Rekhter" <yakov@...>; <softwires@...>;
> <ccamp@...>
> 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.
> >
>

_______________________________________________
Softwires mailing list
Softwires@...
https://www.ietf.org/mailman/listinfo/softwires

[Adrian Farrel(IETF CCAMP WG)]

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

> 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@...>
>> To: "Adrian Farrel" <adrian@...>
>> Cc: "Yakov Rekhter" <yakov@...>; <softwires@...>;
>> <ccamp@...>
>> 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.
>> >
>>
>

_______________________________________________
Softwires mailing list
Softwires@...
https://www.ietf.org/mailman/listinfo/softwires