RE: Questions about draft-sajassi-l2vpn-vpls-bridge-interop-00
"Busschbach, Peter B (Peter)" <busschbach@lucent.com> Thu, 18 November 2004 21:39 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 QAA19245 for <l2vpn-web-archive@ietf.org>; Thu, 18 Nov 2004 16:39:47 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUu33-0007fP-Ug for l2vpn-web-archive@ietf.org; Thu, 18 Nov 2004 16:42:38 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUtiJ-0007m1-5z; Thu, 18 Nov 2004 16:21:11 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUtIf-0007Ou-Tu for l2vpn@megatron.ietf.org; Thu, 18 Nov 2004 15:54:42 -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 PAA09349 for <l2vpn@ietf.org>; Thu, 18 Nov 2004 15:54:39 -0500 (EST)
Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUtLM-0004fy-GM for l2vpn@ietf.org; Thu, 18 Nov 2004 15:57:28 -0500
Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id iAIKscZ2020481 for <l2vpn@ietf.org>; Thu, 18 Nov 2004 14:54:39 -0600 (CST)
Received: by NJ7460EXCH001H with Internet Mail Service (5.5.2657.72) id <4M32V6GA>; Thu, 18 Nov 2004 15:54:38 -0500
Message-ID: <B99995113B318D44BBE87DC50092EDA90C0D61CF@nj7460exch006u.ho.lucent.com>
From: "Busschbach, Peter B (Peter)" <busschbach@lucent.com>
To: 'Ali Sajassi' <sajassi@cisco.com>, l2vpn@ietf.org
Date: Thu, 18 Nov 2004 15:54:35 -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: 8b30eb7682a596edff707698f4a80f7d
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: 7baded97d9887f7a0c7e8a33c2e3ea1b
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. 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. 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. 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. 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