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.