Re: BGP TE attr last call by softwires WG

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

Hello Don,

Thanks for the response.

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

Right.
Aggregation in this case is hard to make representative of reality.

> Also In L1VPN (LSC and TDM) networks the Switching type
> covers Switching granularity (which is like an MTU).

Sure. But I wanted to keep in PSC, because that problem represents a single 
layer network.

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

The question I am asking is - is the solution to this problem to advertise 
two routes?
(Clearly two is a special case of many.)

I don't believe that in the general (non-TE case) we would consider the case 
of two parallel links between CE and PE as route aggregation. The PE would 
simply advertise reachability (through itself) to the CE.

Hence my question below.

> >    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
[SNIP]
> 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.

Thanks.
I guess:
- if applicable, how?
- if not applicable, how prevent?

Cheers,
Adrian