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

"Busschbach, Peter B (Peter)" <busschbach@lucent.com> Wed, 17 November 2004 16:01 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11758 for <l2vpn-web-archive@ietf.org>; Wed, 17 Nov 2004 11:01:04 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUSHS-0004Lv-HV for l2vpn-web-archive@ietf.org; Wed, 17 Nov 2004 11:03:38 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUS99-0000hy-Qg; Wed, 17 Nov 2004 10:55:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUS5I-00084T-AN for l2vpn@megatron.ietf.org; Wed, 17 Nov 2004 10:51:04 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10909 for <l2vpn@ietf.org>; Wed, 17 Nov 2004 10:51:01 -0500 (EST)
Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUS7j-00047G-1M for l2vpn@ietf.org; Wed, 17 Nov 2004 10:53:35 -0500
Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id iAHFoU4g023174 for <l2vpn@ietf.org>; Wed, 17 Nov 2004 09:50:30 -0600 (CST)
Received: by NJ7460EXCH001H with Internet Mail Service (5.5.2657.72) id <4M32TXDZ>; Wed, 17 Nov 2004 10:50:30 -0500
Message-ID: <B99995113B318D44BBE87DC50092EDA90C0D61B7@nj7460exch006u.ho.lucent.com>
From: "Busschbach, Peter B (Peter)" <busschbach@lucent.com>
To: 'Ali Sajassi' <sajassi@cisco.com>, l2vpn@ietf.org
Date: Wed, 17 Nov 2004 10:50:27 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196
Subject: RE: Questions about draft-sajassi-l2vpn-vpls-bridge-interop-00
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: l2vpn.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe>
Sender: l2vpn-bounces@ietf.org
Errors-To: l2vpn-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7

Hi Ali,

Thanks for your response. If you don't mind, I do have a few follow-up questions.

Peter

> -----Original Message-----
> From: Ali Sajassi [mailto:sajassi@cisco.com]
> Sent: Wednesday, November 17, 2004 1:29 AM
> To: Busschbach, Peter B (Peter); l2vpn@ietf.org
> Subject: Re: Questions about 
> draft-sajassi-l2vpn-vpls-bridge-interop-00
> 
[snipped]

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

Unfortunately, I don't fully understand section 9.2 of the vpls-ldp draft. Perhaps you could shed your light on that as well :-)   Section 9.2 mentions:

"If an island has more than one PE-rs, then a dedicated full-mesh of pseudowires is used among these PE-rs devices for carrying the SP BPDU packets for  that island."

What is meant by "dedicated"? Since the PE-rs devices are part of the VPLS network, there is by definition a full mesh of PWs between them. Are the dedicated PWs for SP BDPU packets different PWs than the ones that carry the data traffic?

Also, would it not be possible that as a result of running MSTP in the P-VPLAN, the VPLS network itself is blocked? E.g. if an MTU-s is connected to both PE1 and PE2 and the resulting spanning tree is such that the link between PE1 and PE2 is blocked (i.e. the MTU-s is the root), then MTU-s will forward packets with unknown MAC address received from PE1 to PE2 and vice versa. Now, if PE1 and PE2 both block all traffic from the VPLS network, the P-VPLAN is isolated from all remote nodes. On the other hand, if PE1 and PE2 both forward traffic over the VPLS network, there is a loop.


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

Does a single PW failure in a full-mesh of PWs cause a total interruption of BPDUs? I would think that in a bridge world, every site that participates in a VPLS instance would generate BPDUs. If PE1 stops receiving BDPUs from PE2 due to a PW failure, but if it continues receiving BPDUs from PE3, PE4, etc., why would it change the forwarding 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,

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


I still don't understand. If three CEs are connected to three PEs, don't all three PEs need to participate in MAC address learning?

You can avoid any MAC learning in PEs by establishing point-to-point PWs between CEs. However, in a regular VPLS architecture, each PE needs to do MAC learning, right? 


> 
[snipped to the end]