Meanwhile, back on topic (BGP-TE)

["Adrian Farrel" <adrian@olddog.co.uk>]

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