Re: BGP TE attr last call by softwires WG

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

Hi,

> From: David Ward <dward@cisco.com> 
> Sent: Tue Aug 12 23:48 
> Subject: BGP TE attr last call by softwires WG 
>
> The softwire WG has LC'ed 
>
> http://www.ietf.org/internet-drafts/draft-ietf-softwire-
> bgp-te-attribute-01.txt 
>
> We will keep open an additional two-week period for wider
> review before moving forward in the publication process. 
> Please have any comments to the authors and softwires WG 
> by Aug 26, 2008. 

I have no objection to the basic idea of distributing TE
information about CE-PE links especially for use in VPNs. 
But I am worried by one aspect of the document. Hopefully
this is just an editorial issue.

The last call in Softwires appears to have generated some
discussion about aggregation, and this led to the addition 
of section 4.

| 4. Implication on aggregation
|
|    Routes that carry the Traffic Engineering Attribute 
|    have additional semantics that could affect traffic 
|    forwarding behavior. Therefore, such routes SHALL NOT 
|    be aggregated unless they share identical Traffic
|    Engineering Attributes.

As far as it goes, this paragraph is great. It says "do not
perform route aggregation unless it is sensible to do so."

But it says nothing about TE aggregation.

Notwithstanding the TE attribute is non-transitive, there 
is the potential for an implementation to believe that it
should provide some form of TE aggregation.

Consider two cases:

1. A CE is attached by parallel links to a single PE

  Suppose the links have the same switching types, but 
  different bandwidths. Link-a has plenty of bandwidth
  available with an MTU size of x. Link-b has not much
  bandwidth available with an MTU size of y > x.

  Normally, we would expect the PE to advertise a single
  piece of reachability information for the CE leaving
  the actual choice of links to be made by the PE.

  What would the PE advertise in this case?
  - It cannot aggregate the TE information because that
    would imply that there was lots of bandwidth at the 
    larger MTU size.
  - It could include duplicate Switching Capability
    Descriptors, but that would need some clarification as
    duplicate descriptors are intended for different 
    switching caps in the IGP RFCs.
  - It could advertise two pieces of reachability
    information, but that would be a change to how the
    implementation currently works.

2. There is more than one AS

  Consider

    CE1--PE1...AS1...ASBR1--ASBR2...AS2...PE2--CE2

  PE2 advertises reachability to CE2 and includes TE 
  information. The TE attribute is non-transitive so it is
  not just passed on, but ASBR2 wants to announce
  reachability to CE2 (in the VPN case, we may want to 
  support a multi-AS VPN).

  So ASBR2 can advertise reachability to CE2, but what TE
  parameters does it advertise? The parameters for the 
  link PE2-CE2 are not so helpful because the TE 
  reachability across AS2 may be different. Yet any attempt
  to perform a computation of the TE reachability across
  AS2 (i.e. TE aggregation) is complex and potentially
  unstable. (Of course, if a tunnel is pre-established
  between ASBR2 and PE2 this is a different matter.)


I think that these two different scenarios need attention
in the I-D. 

For the first one, it may just be a matter of indicating 
which approach is to be used.

For the second one, I hope the answer is to recommend 
against any form of TE aggregation. This could easily be
added to section 4, and I would be happy to provide text.
BUT, it will still leave open the question about if and how
TE information is propagated beyond the AS.

Thanks for any clarifications.

Adrian