Re: [Softwires] BGP TE attr last call by softwires WG

["Don Fedyk" <[e-mail]>]

Hi Adrian

I should talk this over with my Co-authors so for now I won't answer all
your points but I will ask for clarification.

See Inline:

> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]] 
> 
> 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.

Interface MTU is part of the PSC TE attributes in the our spec. If the
MTUs are different they should not be aggregated. 
Also In L1VPN (LSC and TDM) networks the Switching type covers Switching
granularity (which is like an MTU).  

I'm trying to understand if you are saying the following text would fix
the problem or you see a larger issue: 
"Therefore, such routes and the corresponding TE information SHALL NOT
be aggregated unless they share identical Traffic Engineering
Attributes".

> 
>    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 remember we discussed this aspect originally in the context of L1VPNs
and limited it to a single AS since L1VPNs Basic Mode are limited to a
single AS. I don't recall if we thought this was applicable to a multi
AS solution.  We should clarify this point either way.  

We will get back to you shortly on this point. 
Thanks,
Don 

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