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

Ali Sajassi <sajassi@cisco.com> Thu, 18 November 2004 06:42 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 BAA05745 for <l2vpn-web-archive@ietf.org>; Thu, 18 Nov 2004 01:42:14 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUg2J-0001C9-3d for l2vpn-web-archive@ietf.org; Thu, 18 Nov 2004 01:44:55 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUfwl-0001gP-H9; Thu, 18 Nov 2004 01:39:11 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUfwG-0001SN-5Q for l2vpn@megatron.ietf.org; Thu, 18 Nov 2004 01:38:40 -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 BAA05207 for <l2vpn@ietf.org>; Thu, 18 Nov 2004 01:38:38 -0500 (EST)
Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUfyp-00016C-7w for l2vpn@ietf.org; Thu, 18 Nov 2004 01:41:19 -0500
Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 17 Nov 2004 22:38:13 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from sajassi-w2k4.cisco.com (sjc-vpn1-369.cisco.com [10.21.97.113]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id iAI6c5W0002828; Wed, 17 Nov 2004 22:38:06 -0800 (PST)
Message-Id: <4.3.2.7.2.20041117210911.027a5300@airborne.cisco.com>
X-Sender: sajassi@airborne.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 17 Nov 2004 22:38:02 -0800
To: "Busschbach, Peter B (Peter)" <busschbach@lucent.com>, 'Ali Sajassi' <sajassi@cisco.com>, l2vpn@ietf.org
From: Ali Sajassi <sajassi@cisco.com>
In-Reply-To: <B99995113B318D44BBE87DC50092EDA90C0D61B7@nj7460exch006u.ho .lucent.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e
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: 7fa173a723009a6ca8ce575a65a5d813

Hi Peter,

Please refer to my comments below ...

[snipped]


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

Exactly. These full-mesh of PWs are dedicated to carry the service 
providers BPDUs only and this full-mesh is for the PE-rs devices of that 
island only and not the whole network. So if the whole network consists of 
5 access islands each of which having three PE-rs devices, then each island 
has a full-mesh of three PWs for its BPDU traffic. And if a VPLS instance 
(for a given customer) spans across all the five islands, then that VPLS 
instance needs a full-mesh of 105 PWs (15*7). The idea of having a separate 
full-mesh of PWs for each island's BPDU traffic is to make each island STP 
independent from every other islands.


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

This won't happen. The full-mesh of PWs for that islands BPDUs is for the 
virtual bridge port that I draw in the PE model in page 7 of my IETF 
presentation (I have sent my preso to the chairs to be posted). So if you 
take a look at that figure, hopefully things become more clear. When that 
virtual port gets blocked, then all the VPLS instances (or provider VLANs) 
over that port gets blocked as well and therefore, only a single PE-rs will 
be active for any given VPLS instance. Even if there is another link 
between the two PE-rs devices, the MSTP will take care of blocking this 
additional link.


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

There are scenarios with dual-homing of a customer site or redundant 
connection via another network, where a unidirectional failure of PW can 
result in a loop - it would be easier to show these scenarios via figures. 
Also in the scenario that you describe above, because the CE1 connected to 
PE1 doesn't receive BPDUs directly from the CE2 (connected to PE2), then it 
can miscalculate its path to the root and block its link and open up an 
alternative link through another network which is not desirable.



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

typically 2 seconds.

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

Typically yes, all the PEs need to learn MAC addresses but what I am 
talking about is that the MAC address learning can be optimized (per 
802.1ad) such that only the PEs that need to learn MAC addresses, then 
learn MAC addresses. Let me give you another example, if a customer has 
only two CEs connected via a VPLS network, then we can optimized our 
network such that no MAC address learning is needed because the path 
between the two CEs through the network is basically a PtP path. Now if you 
consider three CEs, then there can be only a single Y branch along the path 
between the three CEs and therefore, only the PE with Y branch needs to 
learn MAC address. With this optimization, the question is not if a PE can 
learn customer MAC addresses but whether a PE needs to learn customer MAC 
addresses.

-Ali



> >
>[snipped to the end]