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

Ali Sajassi <sajassi@cisco.com> Fri, 19 November 2004 02:47 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 VAA20601 for <l2vpn-web-archive@ietf.org>; Thu, 18 Nov 2004 21:47:04 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUyqT-00070Y-91 for l2vpn-web-archive@ietf.org; Thu, 18 Nov 2004 21:49:57 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUym1-0005QJ-1B; Thu, 18 Nov 2004 21:45:21 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUyYy-0001dJ-C2 for l2vpn@megatron.ietf.org; Thu, 18 Nov 2004 21:31:52 -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 VAA19080 for <l2vpn@ietf.org>; Thu, 18 Nov 2004 21:31:50 -0500 (EST)
Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUybi-0006a5-34 for l2vpn@ietf.org; Thu, 18 Nov 2004 21:34:42 -0500
Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 18 Nov 2004 18:31:34 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from sajassi-w2k4.cisco.com (sjc-vpn4-188.cisco.com [10.21.80.188]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id iAJ2VJYs012726; Thu, 18 Nov 2004 18:31:20 -0800 (PST)
Message-Id: <4.3.2.7.2.20041118175841.0284ca90@airborne.cisco.com>
X-Sender: sajassi@airborne.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 18 Nov 2004 18:31:16 -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: <B99995113B318D44BBE87DC50092EDA90C0D61CF@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

Peter,

At 03:54 PM 11/18/2004 -0500, Busschbach, Peter B (Peter) wrote:
>Ali,
>
>Thanks for the detailed reponse. Things are becoming clearer. I discovered 
>that one of the issues that causes much of my confusion is the way 
>Ethernet deals with Spanning Trees. I tend to think of a Spanning Tree as 
>a tree from which entire links are pruned. Instead, in the ethernet world, 
>it is a matter of blocking ports. Someday, hopefully, I will be able to 
>internalize that.

And the blocking doesn't have to be for all the VLANs - e.g., it can be for 
a group of VLANs by associated that group of VLANs with a one instance of 
spanning tree by running MSTP. Therefore, by allowing multiple spanning 
trees (typically 2 or 3), you can have a nice load balancing across 
different links.


>A few things:
>
>Ali> There are scenarios with dual-homing of a customer site or
>Ali> redundant
>Ali> connection via another network, where a unidirectional
>Ali> failure of PW can
>Ali> result in a loop - it would be easier to show these
>Ali> scenarios via figures.
>
>It would be very helpful for me to see a detailed example that shows 
>exactly what can go wrong and why. If at some point in time you develop 
>such material that you are willing to share, I would greatly appreciate it.

Sure, I will work on it and will add it as an appendix to my bridge-interop 
draft.


>Ali> Now if you
>Ali> consider three CEs, then there can be only a single Y
>Ali> branch along the path
>Ali> between the three CEs and therefore, only the PE with Y
>Ali> branch needs to
>Ali> learn MAC address. With this optimization, the question is
>Ali> not if a PE can
>Ali> learn customer MAC addresses but whether a PE needs to
>Ali> learn customer MAC
>Ali> addresses.
>
>With three CEs you can create an architecture in which *none* of the PEs 
>needs to perform MAC address learning: create point-to-point links between 
>the CEs and let one of the CEs function as the hub node.

True, but this is no longer a VPLS service and instead it is a VPWS service.


>I understand your point  that you don't necessarily need to do MAC 
>learning in every PE. However, it is not clear to me what the ultimate 
>relevance of that is. With N CEs in a regular VPLS architecture, all N PEs 
>need to do MAC address learning. However, as you point out, you could 
>choose for a different architecture: create a VPLS among a subset of PEs 
>(including the empty subset) and connect all remaining PEs to that subset 
>via point-to-point PWs. These remaining PEs then don't need to perform MAC 
>address learning. By doing this, you trade data plane efficiency off 
>against the number of MAC entries that you store in the network. The 
>question is: do you think this fine-tuning of VPLS is important? It seems 
>to me that the benefit is small and the operational complexity significant.

This depends on what flavor of VPLS we are talking about. With VPLS H-VPLS 
with either QinQ or MPLS access network, you will have at least four 
bridging nodes along the path of any two CEs. So if a customer has three 
sites as they are connected to the provider network as follow:


CE1 ----- u-PE1---------n-PE1 -----------------------n-PE2 
--------------u-PE2 ------ CE2
                                                                    |
                                                                    |--------------------u-PE-3 
------ CE3

then the only PEs that need to learn MAC addresses for that customer is 
n-PE2. Also when you use QinQ access network (802.1ad), then you can take 
advantage of 802.1ad protocols for figuring out which PE doesn't need to 
learn customer MAC addresses and disable MAC address learning on those PE 
dynamically without any configuration what so ever. This is specified in 
802.1ad standard. With MPLS access network one can also leverage the 
802.1ad protocol as well and achieve the same result. So even with MPLS 
access network you will setup the PWs for a give customer as before and 
then run the .1ad protocol on your PEs to decided which PEs should disable 
MAC address learning for which customers. This should disabling feature 
should be transparent and orthogonal to your PW setup.

-Ali



>Peter
>
>
>P.S.
>
>A completely different question (not just for Ali, but for anyone who 
>reads this email): when I check my own emails in the email archive (e.g. 
>http://www.ietf.org/mail-archive/web/l2vpn/current/msg00793.html ) I see 
>that the lines are not trunkated. Instead, you need to use the scroll bar 
>to scroll to the end of a sentence. This is not the case for emails from 
>others in the same archive. I have tried to solve it and even worked with 
>our IT department, but to no avail.
>
>When you receive my emails, do they appear on your screen as they do in 
>the archive (i.e. with scroll bar)? Any idea what to do about it?