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?
- Questions about draft-sajassi-l2vpn-vpls-bridge-i… Busschbach, Peter B (Peter)
- Re: Questions about draft-sajassi-l2vpn-vpls-brid… Ali Sajassi
- RE: Questions about draft-sajassi-l2vpn-vpls-brid… Busschbach, Peter B (Peter)
- RE: Questions about draft-sajassi-l2vpn-vpls-brid… Ali Sajassi
- RE: Questions about draft-sajassi-l2vpn-vpls-brid… Busschbach, Peter B (Peter)
- RE: Questions about draft-sajassi-l2vpn-vpls-brid… Ali Sajassi
- RE: Questions about draft-sajassi-l2vpn-vpls-brid… Lionel.Silman
- RE: Questions about draft-sajassi-l2vpn-vpls-brid… Ali Sajassi