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

["Ali Sajassi \(sajassi\)" <[e-mail]>]

I forgot to mention about another issue which is: sending unknown
unicast frames over shared MDT and learning action at the egress PE. 

When the MDT is a shared-tree, then the tree identifier identifies the
RP node and not the ingress PE nodes. Therefore, another label is needed
to identify the ingress PE - e.g., a packet received at the egress PE
will have three labels (outer-label identifying the tree, middle label
identifying the ingress PE, and inner label identifying the VPLS
instance). If this is deemed too tedious, then the use of shared-MDT for
unknown unicast traffic should be avoided and instead ingress
replication over P2P PWs should be used.

-Ali

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> On Behalf Of Ali Sajassi (sajassi)
> Sent: Tuesday, October 25, 2005 12:16 AM
> To: Shane Amante; [e-mail]
> Subject: RE: draft-raggarwa-l2vpn-vpls-mcast-01.txt
> 
> 
> 
> 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: [e-mail] 
> [mailto:[e-mail]] On Behalf 
> > Of Shane Amante
> > Sent: Tuesday, October 18, 2005 12:37 PM
> > To: [e-mail]
> > 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
> > 
>