Re: BGP TE attr last call by softwires WG

[Yakov Rekhter <[e-mail]>]

Adrian,

> Hi,
> 
> > From: David Ward <[e-mail]> 
> > 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.

I already answered this in my other e-mail yesterday.

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

For the second one the answer is in rfc5251:

   Consideration of inter-AS and inter-provider L1VPNs requires further
   analysis beyond the scope of this document.

Yakov.