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?