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

"Busschbach, Peter B (Peter)" <busschbach@lucent.com> Tue, 16 November 2004 22:44 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 RAA04447 for <l2vpn-web-archive@ietf.org>; Tue, 16 Nov 2004 17:44:04 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUC5j-0005la-9i for l2vpn-web-archive@ietf.org; Tue, 16 Nov 2004 17:46:28 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUBuE-0001WV-Rb; Tue, 16 Nov 2004 17:34:34 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUBJQ-0007Az-RI for l2vpn@megatron.ietf.org; Tue, 16 Nov 2004 16:56:32 -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 QAA23287 for <l2vpn@ietf.org>; Tue, 16 Nov 2004 16:56:31 -0500 (EST)
Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUBLi-0002MS-Ij for l2vpn@ietf.org; Tue, 16 Nov 2004 16:58:54 -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 iAGLuU8i014983 for <l2vpn@ietf.org>; Tue, 16 Nov 2004 15:56:30 -0600 (CST)
Received: by NJ7460EXCH001H with Internet Mail Service (5.5.2657.72) id <4M32S7TJ>; Tue, 16 Nov 2004 16:56:30 -0500
Message-ID: <B99995113B318D44BBE87DC50092EDA90C0D61AD@nj7460exch006u.ho.lucent.com>
From: "Busschbach, Peter B (Peter)" <busschbach@lucent.com>
To: l2vpn@ietf.org
Date: Tue, 16 Nov 2004 16:56:29 -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: 7655788c23eb79e336f5f8ba8bce7906
Subject: 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: 93238566e09e6e262849b4f805833007

1) Section 8 of draft-sajassi-l2vpn-vpls-bridge-interop-00 says "And if the CE devices belonging to an ESI are IEEE bridges, then a partial-mesh of PWs can cause broadcast storms in the customer and provider networks"

I understand that when a MAC address becomes unreachable, new messages destined for that MAC address will be replicated over all links, but does that qualify as a broadcast storm? Or is there more to it than that?


2) The next sentence in section 8: "Furthermore, it can cause multiple copies of a single frame to be received by the CE and/or PE devices"

How can that happen?


3) A few paragraphs down: "Therefore, the detection time may be longer than the detection time needed for loop prevention inside the customer network"

Apparently, partial mesh can lead to a loop in the customer network. I guess this is a consequence of the interworking between STP and VPLS, but don't understand the details. Is this easy to explain or should I take a course in STP?


4) Section 10 "For example, if a service instance is associated with four CEs at four different sites, then the maximum number of provider bridges (or PEs), that need to participate in that customer MAC address learning, is only three regardless of how many PEs are in the path of that service instance."

I don't understand that. If four CE2 are connected to four PEs with a full-mesh of PWs between the PEs, don't all four PEs need to participate in MAC address learning?


That's all (for now).

Peter