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

From: "Ali Sajassi \(sajassi\)" <[email-masked]>
Date: Tue, 25 Oct 2005 00:15:55 -0700

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: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Shane Amante
> Sent: Tuesday, October 18, 2005 12:37 PM
> To: [email-masked]
> 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
>

---

From: "Yuji KAMITE" <[email-masked]>
Date: Wed, 26 Oct 2005 17:21:40 +0900

Hi,

> 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. 

Basically I believe it is recommended that control frames (like BPDU)
should be flooded over unicast, not over MDT;
but let me ask some questions. 

For example:

Suppose 802.1ag CC is enabled at customer domain (CE speaks .1ag),
and VPLS core is capable of MDT as well as unicast PWs.

Natively CC would be forwarded on multicast scheme.
But I think
 - if CC is aimed for unicast reachability, it is better for PE to encapsulate it over unicast PWs.
 - if CC is aimed for multicast reachability, it is better for PE to encapsulate it over MDT.
because customer would wish that CC is flowing on the "real" data path in the core.
I'm wondering if it is possible for PE to differentiate it.

Link trace/loopback case might be a little different, but I'm not yet quite sure.

Interworking between customer CFM and VPLS-ping like things,  might be
possible to solve the issue, but possibly complicated.

-Yuji