Re: BGP TE attr last call by softwires WG

[JP Vasseur <[e-mail]>]

Hi all,

I'd like to second Adrian's point here - see below.


On 8/22/08 1:18 AM, "Adrian Farrel" <[e-mail]> wrote:

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

That is also my concern ... It would be really nice to clarify that TE
aggregation must be avoided.

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

Same question.

Thanks Don.

JP.

> Cheers,
> Adrian
> 
>