[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: BGP TE attr last call by softwires WG



Hi Yakov,

You have answered my first question, within the limited scope of basic mode, single-AS L1VPN autodiscovery, perfectly. I hope no-one would disagree with your interpretation.

This is good, and I support the use of this draft in that limited scenario, and I suspect that the concept is extensible to any port-based VPN.

Will you be adding to the draft to say that this is the full extent of the applicability of this draft (perhaps using RFC 2119 language)?

If not, then I'm afraid that my question stands. What will happen in the case where BGP is used to advertise TE capabilities on non-(L1)VPN CE-PE links?

Thanks,
Adrian

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

Let's put the general (non-TE) case aside, and focus on the L1VPN
scenario.

According to the bgp-auto-discovery and l1vpn-basic-mode drafts in
the context of L1VPN what is advertised in the BGP auto-discovery
information is the information about *ports*.  Therefore, in the
context of L1VPN TE information advertisements are associated with
individual *ports*, not with a particular CE.  Which means that if
a CE is connected to a PE by N ports, then the BGP auto-discovery
information has to advertise all these N ports, and associated with
each such advertisement may be the TE information.

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.

The answer to your question is that if the implementation follows
the spec, it would advertise information about *ports*.  So, if a
CE has two ports that connect it to a PE, then the PE originates
two L1VPN advertisements, one per port, each with its own TE
attribute.