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 >
- draft-raggarwa-l2vpn-vpls-mcast-01.txt Shane Amante
- Re: draft-raggarwa-l2vpn-vpls-mcast-01.txt Thomas Morin
- RE: draft-raggarwa-l2vpn-vpls-mcast-01.txt Yuji KAMITE
- RE: draft-raggarwa-l2vpn-vpls-mcast-01.txt McCoy, Chris
- RE: draft-raggarwa-l2vpn-vpls-mcast-01.txt Yuji KAMITE
- Re: draft-raggarwa-l2vpn-vpls-mcast-01.txt Marc Lasserre
- Re: draft-raggarwa-l2vpn-vpls-mcast-01.txt Rahul Aggarwal
- Re: draft-raggarwa-l2vpn-vpls-mcast-01.txt Yuichi Ikejiri
- RE: draft-raggarwa-l2vpn-vpls-mcast-01.txt Ali Sajassi (sajassi)
- RE: draft-raggarwa-l2vpn-vpls-mcast-01.txt Ali Sajassi (sajassi)
- RE: draft-raggarwa-l2vpn-vpls-mcast-01.txt Yuji KAMITE
- RE: draft-raggarwa-l2vpn-vpls-mcast-01.txt Ali Sajassi (sajassi)
- RE: draft-raggarwa-l2vpn-vpls-mcast-01.txt Maarten.Vissers