Subject: RE: VPLS OAM != .1ag

From: Jeremy Brayley <[email-masked]>
Date: Fri, 7 Dec 2007 17:57:11 -0500

Vach,

I think you make a useful point about CFM's (802.1ag's) ability to trace
MAC address to PW bindings in VPLS.  Someone should be able to trace MAC
to PW bindings just like MAC to physical Ethernet port bindings.

***from draft-stokes-vkompella-l2vpn-vpls-oam-01.txt
     - For troubleshooting and validation, it is necessary to know the
       PW behind which a specific MAC address is located. As CFM
       entities are not present in intermediate VPLS forwarders in an H-
       VPLS[L2VPN-CFM], it is not possible to obtain information with
       such granularity from CFM operations. 
***

However, I wonder how much of this is due to the VPLS model as presented
in RFC 4664.  I agree that if an implementation followed this model it
would seem that PWs (and their MAC bindings) would be invisible to CFM.
You also have to assume that CFM MPs could only be placed on the bridge
ports or emulated LAN interface and not associated with the VPLS
forwarder.  At least I would certainly get that impression from the VPLS
model in RFC 4664.

But I think there is a different way of modeling VPLS that allows CFM to
address the MAC to PW binding issue. 

In short, why not treat the PWs just like any other port on the bridge
module?

For example, you can eliminate the separation between the VPLS forwarder
and bridge by treating each PW as if it is a separate port on the
bridge.  You wouldn't need the concept of a VPLS forwarder. And as a
bridge port, you would ensure that the PW is visible to CFM.  There
would be no special requirement to enhance the CFM protocols to support
PWs because they look just like ports.

Thanks,

Jeremy 

--Vach Kompella writes:
I want to re-iterate that VPLS OAM is not a replacement for .1ag (which
neither Ali nor Dan seem to have noticed).  In fact, the first slide of
my presentation states that it fixes the holes in our analysis of the
capabilities provided through .1ag+VCCV (Olen's presentation).

In essence, providers are interested in figuring out the mapping of PWs
to ethernet MACs, as the MACs are learned, and tracing the consistency
of the mapping across the VPLS domain.  This specifically covers the
MPLS details of the PWs in the VPLS forwarders, which is not covered in
.1ag.  This also covers the mapping of the FDB to the PWs which is not
covered by VCCV.

Obviously, this can be (somewhat painfully) achieved by going to
individual nodes and using some combinations of .1ag and VCCV, and
dumping FDB contents.  However, you still have to correlate the failure
in the forwarding of .1ag and the state of PWs in a VPLS forwarder
reported by VCCV, and the dumping of FDB contents, and putting all that
together to get the desired effect.  And you are still left with the
unsatisfactory feeling that you relied on the output of some tables as
opposed to pushing a packet through the suspect forwarding plane entity.

Vach Kompella
IP Division, Alcatel
vach.kompella at alcatel-lucent.com
+1 650 623-2556

---

From: "KOMPELLA Vach" <[email-masked]>
Date: Fri, 7 Dec 2007 18:06:54 -0600

Hi Jeremy,

We debated this a long time back, and we decided on this model because
the group of PWs is a single entity, otherwise it doesn't model the
split horizon aspect of a VPLS.  For proper operation, the set of PWs
have to be all up or the VPLS forwarder is down.

We debated whether to model the VPLS as a giant switch with the
collection of PWs across all VPLS PEs being the "switch fabric" and the
attachment circuits being the ports, and I think that didn't fly.  It's
a nice abstraction for presenting what a VPLS does, but it is too
simplistic to model the bridge component, the PWs and the split horizon
requirement on the PWs.

-Vach  

> -----Original Message-----
> From: Jeremy Brayley [mailto:[email-masked]] 
> Sent: Friday, December 07, 2007 2:57 PM
> To: KOMPELLA Vach; [email-masked]
> Subject: RE: VPLS OAM != .1ag
> 
> Vach,
> 
> I think you make a useful point about CFM's (802.1ag's) 
> ability to trace MAC address to PW bindings in VPLS.  Someone 
> should be able to trace MAC to PW bindings just like MAC to 
> physical Ethernet port bindings.
> 
> However, I wonder how much of this is due to the VPLS model 
> as presented in RFC 4664.  I agree that if an implementation 
> followed this model it would seem that PWs (and their MAC 
> bindings) would be invisible to CFM.
> You also have to assume that CFM MPs could only be placed on 
> the bridge ports or emulated LAN interface and not associated 
> with the VPLS forwarder.  At least I would certainly get that 
> impression from the VPLS model in RFC 4664.
> 
> But I think there is a different way of modeling VPLS that 
> allows CFM to address the MAC to PW binding issue. 
> 
> In short, why not treat the PWs just like any other port on 
> the bridge module?
> 
> For example, you can eliminate the separation between the 
> VPLS forwarder and bridge by treating each PW as if it is a 
> separate port on the bridge.  You wouldn't need the concept 
> of a VPLS forwarder. And as a bridge port, you would ensure 
> that the PW is visible to CFM.  There would be no special 
> requirement to enhance the CFM protocols to support PWs 
> because they look just like ports.
> 
> Thanks,
> 
> Jeremy 
> 
> --Vach Kompella writes:
> I want to re-iterate that VPLS OAM is not a replacement for 
> .1ag (which neither Ali nor Dan seem to have noticed).  In 
> fact, the first slide of my presentation states that it fixes 
> the holes in our analysis of the capabilities provided 
> through .1ag+VCCV (Olen's presentation).
> 
> In essence, providers are interested in figuring out the 
> mapping of PWs to ethernet MACs, as the MACs are learned, and 
> tracing the consistency of the mapping across the VPLS 
> domain.  This specifically covers the MPLS details of the PWs 
> in the VPLS forwarders, which is not covered in .1ag.  This 
> also covers the mapping of the FDB to the PWs which is not 
> covered by VCCV.
> 
> Obviously, this can be (somewhat painfully) achieved by going 
> to individual nodes and using some combinations of .1ag and 
> VCCV, and dumping FDB contents.  However, you still have to 
> correlate the failure in the forwarding of .1ag and the state 
> of PWs in a VPLS forwarder reported by VCCV, and the dumping 
> of FDB contents, and putting all that together to get the 
> desired effect.  And you are still left with the 
> unsatisfactory feeling that you relied on the output of some 
> tables as opposed to pushing a packet through the suspect 
> forwarding plane entity.
> 
> Vach Kompella
> IP Division, Alcatel