Subject: VPLS OAM != .1ag

From: "KOMPELLA Vach" <[email-masked]>
Date: Wed, 5 Dec 2007 12:25:56 -0600

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
[email-masked]
+1 650 623-2556

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Fri, 7 Dec 2007 16:04:45 -0800

Vach,

As I pointed out during the meeting, if you use the right model, then
you will see that the combination of 802.1ag with VCCV gives a very good
coverage. The problem is that you are starting with a wrong model and
your coverage analysis is based on that model - e.g., you are assuming
that for H-VPLS w/ MPLS access, the packet does not touch bridge module
at n-PE devices and thus 802.1ag doesn't give you coverage on the n-PE.
And that is a wrong assumption to begin with. 

As I mention during the meeting, lets start with the right model and
then perform the analysis and see if there is any issues with  the
coverage of .1ag + VCCV before introducing yet another oam mechanism. 

I had a chat with Olen to review with him the models in bridge-interop
draft and RFC 4664 and take the discussion from there.

Cheers,
Ali

P.S. I will be on PTO starting next week but I am sure there will be
tons of discussions before I come back :-)     

> -----Original Message-----
> From: KOMPELLA Vach [mailto:[email-masked]] 
> Sent: Wednesday, December 05, 2007 10:26 AM
> To: [email-masked]
> Subject: VPLS OAM != .1ag
> 
> 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

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 7 Dec 2007 20:15:30 -0500

Ali, I totally agree with your point.

	--Tom

---

From: "Dutta, Pranjal Kumar \(Pranjal\)" <[email-masked]>
Date: Sat, 8 Dec 2007 07:53:16 +0530

Ali,
 
Both draft-stokes-l2vpn-cfm-vccv and draft-stokes-vkompella-l2vpn-vpls-oam should be evaluated together to consider the solutions proposed. VCCV alone can do the diagnostics across the PWs in the VPLS  and .1ag mechanisms can be used for diagnostics of the bridging/MAC aspects. 
 
But the issue here is the mapping or inconsistency of packet forwarders to the PWs - that's  the association of the MACs with VPLS transport. In such issues .1ag verification methods does not provide adequate details. VCCV diagnostics would declare everything fine as the PW alone is doing quite well. Then some intuitive debugging through various forwarding/mapping tables might lead to the issue, provided the problem is persistent enough. Such intuitive debugging does not help in troubleshooting transient mapping issues.
 
draft-stokes-vkompella-vpls-oam provides a methodology to diagnose such issues that can't be covered by .1ag + VCCV together. Again to re-iterate that it is not a replacement of .1ag. 
 
Cheers,
Pranjal

________________________________

From: Ali Sajassi (sajassi) [mailto:[email-masked]]
Sent: Sat 12/8/2007 5:34 AM
To: KOMPELLA, Vach (Vach); [email-masked]
Subject: RE: VPLS OAM != .1ag

Vach,

Cheers,
Ali