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

From: "Ali Sajassi \(sajassi\)" <[email-masked]>
Date: Wed, 26 Oct 2005 11:02:41 -0700

Please refer to my comments inline ... 

> -----Original Message-----
> From: Yuji KAMITE [mailto:[email-masked]] 
> Sent: Wednesday, October 26, 2005 1:22 AM
> To: Ali Sajassi (sajassi)
> Cc: 'Shane Amante'; [email-masked]
> Subject: RE: draft-raggarwa-l2vpn-vpls-mcast-01.txt
> 
> 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. 

Yes, but how is it related to our discussion of EthOAM ? 

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

Well that is the problem that I was referring to: because of divergent
between unicast and mcast path in this scheme, you can send the EthOAM
over one or the other and whichever one you choose, the other one is
left unprotected. This problem doesn't exist in current VPLS and current
bridged networks.

-Ali

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

---

From: [email-masked]
Date: Fri, 28 Oct 2005 13:15:50 +0200

Ali,

This issue is not unique to VPLS with MDT. It may also be present in 
provider backbone bridging and link aggregation will have it as well. Link 
aggregation resolves it quickly by taking the failed link out of the 
active group.

Ethernet OAM is not meant to monitor the underlying server layer trails, 
in this case the MPLS LSPs. The MPLS layer is responsible for this and 
VPLS with MDT will have a few more trails to monitor then VPLS itself. As 
such, in a N point VPLS service each of the N endpoints has N-1 p2p LSP 
endpoints and N-1 MDT endpoints (one from each of the N-1 other 
endpoints). Connectivity for all these 2(N-1) LSPs is to be monitored to 
detect any fault. 

At a VPLS/MDT egress point X these 2(N-1) LSPs can be viewed as N-1 groups 
of two LSPs.: one p2p LSP and one branch of a p2mp LSP. These two come 
from the same ingress point Y.

What the egress point now has to do is to combine the defect state of both 
the Y-to-X p2p and the p2mp LSP; if either of the two fails the traffic on 
both is blocked and ETH-AIS is generated.

Regards,
Maarten

---------------------------------------------------------------------
Maarten Vissers
Network and Product Strategy - Optical Networks Division
Alcatel SEL AG 
Office: Lorenzstrasse 10; D-70435 Stuttgart; Germany
Home office: Simone de Beauvoirlaan 7; 1277 BE Huizen; The Netherlands
VoIP: +49 711 821 43528
Mobile: +31 65 141 8140
Email:[email-masked]

"Ali Sajassi \(sajassi\)" <[email-masked]>
Sent by: [email-masked]
26-10-2005 20:02
 
        To:     "Yuji KAMITE" <[email-masked]>
        cc:     [email-masked], Shane Amante <[email-masked]>
        Subject:        RE: draft-raggarwa-l2vpn-vpls-mcast-01.txt

-Ali