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

From: Yakov Rekhter <[email-masked]>
Date: Wed, 27 Aug 2008 06:40:52 -0700

Don and Hamid,

What is your take on the attached ?

Yakov.
------- Forwarded Message

Date:    Wed, 27 Aug 2008 11:46:26 +0100
From:    "Adrian Farrel" <[email-masked]>
To:      "Yakov Rekhter" <[email-masked]>
cc:      "Don Fedyk" <[email-masked]>, <[email-masked]>, <[email-masked]
	  om>,
	 <[email-masked]>, <[email-masked]>,
	 "Hamid Ould-Brahim" <[email-masked]>
Subject: 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.

------- End of Forwarded Message

_______________________________________________
Softwires mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/softwires