Re: BGP TE attr last call by softwires WG

["Adrian Farrel" <[e-mail]>]

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