RE: draft-raggarwa-l2vpn-vpls-mcast-01.txt

"Ali Sajassi \(sajassi\)" <sajassi@cisco.com> Tue, 25 October 2005 07:16 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUJ2X-0000wF-6L; Tue, 25 Oct 2005 03:16:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUJ2W-0000wA-1U for l2vpn@megatron.ietf.org; Tue, 25 Oct 2005 03:16:08 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26199 for <l2vpn@ietf.org>; Tue, 25 Oct 2005 03:15:53 -0400 (EDT)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUJFQ-0000ad-F8 for l2vpn@ietf.org; Tue, 25 Oct 2005 03:29:28 -0400
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 25 Oct 2005 00:15:58 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9P7Fuub007844; Tue, 25 Oct 2005 00:15:56 -0700 (PDT)
Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Oct 2005 00:15:55 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 25 Oct 2005 00:15:55 -0700
Message-ID: <75B2A84D9323BC4CA3977CF378CE75EBB115E0@xmb-sjc-21e.amer.cisco.com>
Thread-Topic: draft-raggarwa-l2vpn-vpls-mcast-01.txt
Thread-Index: AcXUG7IRXI8XwxmVSjK8lj4DCo5BEQFDiYvQ
From: "Ali Sajassi (sajassi)" <sajassi@cisco.com>
To: Shane Amante <shane@castlepoint.net>, l2vpn@ietf.org
X-OriginalArrivalTime: 25 Oct 2005 07:15:55.0979 (UTC) FILETIME=[F0FFE9B0:01C5D933]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Content-Transfer-Encoding: quoted-printable
Cc:
Subject: RE: draft-raggarwa-l2vpn-vpls-mcast-01.txt
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


This draft is in good alignment with L3VPN multicast mechanism and uses
the same constructs as L3VPN mechanism (such as selective/inclusive and
aggregate selective/inclusive MDTs). As such I would support this draft
in leveraging such constructs in providing provider-based multicast
trees for VPLS and avoiding ingress replication. However, there are
certain limitations in using MDT wrt VPLS that need to be clearly stated
in this draft. These limitations have been described in
draft-sajassi-l2vpn-vpls-bridge-interop for over a year now.

1) Since multicast and unicast paths are different in the network, it
can result in a loop within the customer's network or can result in
black holing the customer traffic. In this scheme the BPDUs is sent
either on unicast or multicast tunnels. A failure of the tunnel carrying
BPDU can result in loops within provider and customer network. And a
failure of the tunnel not carrying BPDUs can result in black holing
customer traffic over that tunnel.

2) Since multicast and unicast paths are different in the network, the
service provider or customer Ethernet OAM (802.1ag or ITU Y.17ethoam)
does not work because the Eth OAM frames are sent over one path or
another and thus the failure for one of them (either unicast or
multicast paths) cannot be detected anymore by this mechanism. 

3) If unknown unicast are sent over MDT, then this may result in packet
re-ordering (this is mentioned in the draft).

Couple of other comments:

A) The mechanism for upstream label assignment and discovery for
shared-tree needs to be described or else indicate it is for future
study. In other words, for shared-tree what type of label assignment is
used between ingress PE and RP, and between RP and egress PE. Also how
does discovery works with having RP in between.

B) Section 16 talks about encapsulation for mcast data and only IP
packets are shown without any MAC address. However, the text states that
VSI is used for forwarding these packets. The VSI is basically a
filtering database which uses MAC address for forwarding the frames and
not IP addresses.

-Ali          

> -----Original Message-----
> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] 
> On Behalf Of Shane Amante
> Sent: Tuesday, October 18, 2005 12:37 PM
> To: l2vpn@ietf.org
> Subject: draft-raggarwa-l2vpn-vpls-mcast-01.txt
> 
> Folks,
> 
> Please voice your opinion and comment on whether this draft 
> should become a L2VPN WG document.  There has been good 
> support for it becoming a WG document at the last IETF.  This 
> draft is important because it defines the procedures for 
> supporting Multicast Trees over VPLS.
> 
> Please let us know your opinion and comments by Tuesday, 10/25.
> 
> Vach & Shane
>