Re: Questions about draft-sajassi-l2vpn-vpls-bridge-interop-00

[Ali Sajassi <[e-mail]>]

Peter,

Please refer to my comments below ...

At 04:56 PM 11/16/2004 -0500, Busschbach, Peter B (Peter) wrote:
>1) Section 8 of draft-sajassi-l2vpn-vpls-bridge-interop-00 says "And if 
>the CE devices belonging to an ESI are IEEE bridges, then a partial-mesh 
>of PWs can cause broadcast storms in the customer and provider networks"
>
>I understand that when a MAC address becomes unreachable, new messages 
>destined for that MAC address will be replicated over all links, but does 
>that qualify as a broadcast storm? Or is there more to it than that?

It is more than that. The type of broadcast storm that I am talking about 
is a permanent one as the result of a loop inside the customer network. 
When a customer site is dual-homed (even if its CE is singled-homed) or 
when it has backward connections, then a failure of PW in one direction can 
result in a loop within the customer network.


>2) The next sentence in section 8: "Furthermore, it can cause multiple 
>copies of a single frame to be received by the CE and/or PE devices"
>
>How can that happen?

One of the scenario that this can happen is during n-PE redundancy of 
section 9.2 of vpls-ldp draft. In this case, when the PW that carries the 
provider BPDU traffic between two n-PEs fail, then both n-PEs go into 
forwarding state and both forward the traffic of a given customer (VPLS) 
over their corresponding PWs. The receiving PE, receive two copies of each 
packets that gets brodcasted.



>3) A few paragraphs down: "Therefore, the detection time may be longer 
>than the detection time needed for loop prevention inside the customer network"
>
>Apparently, partial mesh can lead to a loop in the customer network. I 
>guess this is a consequence of the interworking between STP and VPLS, but 
>don't understand the details. Is this easy to explain or should I take a 
>course in STP?

Well, lets give it try first :-) In the bridge world, the Ethernet link 
failure is not uni-directional  (if it fails, it fails in both direction). 
Furthermore, the bridge finds out about the link failure immediately and 
does its failure recovery (by switching to alternate links). In IEEE 
bridges, if a bridge stops receiving BPDUs over a link but doesn't get any 
failure indication for that link, it puts that link in the forwarding state 
(from its previous blocked state). Now in case of a uni-directional failure 
of a PW, if the detection & recovery time for a PW failure is greater than 
twice the BPDU hello time, then it can result in a loop inside the customer 
network.


>4) Section 10 "For example, if a service instance is associated with four 
>CEs at four different sites, then the maximum number of provider bridges 
>(or PEs), that need to participate in that customer MAC address learning, 
>is only three regardless of how many PEs are in the path of that service 
>instance."
>
>I don't understand that. If four CE2 are connected to four PEs with a 
>full-mesh of PWs between the PEs, don't all four PEs need to participate 
>in MAC address learning?

Let me give you another example: if three customer CEs are connected via 10 
provider bridges (e.g., there are ten bridges in the path of these three 
CEs), then only a single bridge needs to do MAC address learning. The 
reason for this is that the data path through other nine bridges along the 
end-to-end path is PtP and thus no MAC address learning is needed for those 
nine bridges. IEEE 802.1ad does this by using the GVRP and disabling MAC 
address learning for the VLANs that have only a single ingress and egress 
point on that bridge.



>That's all (for now).

I am glad that you are going through these issues. I think these are 
important issues that providers need to be aware of when offering 
multipoint Ethernet service.

-Ali


>Peter