Subject: Re: VPLS OAM != .1ag

From: "KOMPELLA Vach" <[email-masked]>
Date: Fri, 7 Dec 2007 20:17:41 -0600

Ali,

As I have repeatedly said, your model doesn't map MAC addresses in the bridge to PWs in the VPLS forwarders.  This is expressed in the draft that Olen presented. 

It is not enough to say we will test the forwarding through the bridge and the forwarding of an individual PW to determine the complete forwarding path. You have to identify the mapping of MAC address to the associated PW in the VPLS forwarder - somethiing neither .1ag nor VCCV are capable of. 

I have the model right. I don't see your point. 

Tom, if you see something I don't, can you express it as something other than "you have the wrong model.". I have given a concrete example of why I have the right model. 

I hope this isn't harking back to the same issue that VPLS-OAM isn't enough because no-one is saying that.  
-Vach

----- Original Message -----
From: Ali Sajassi (sajassi) <[email-masked]>
To: KOMPELLA Vach; [email-masked] <[email-masked]>
Sent: Fri Dec 07 18:04:45 2007
Subject: RE: VPLS OAM != .1ag

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

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Sun, 9 Dec 2007 14:28:42 -0800

Vach,
 
I think there is a misunderstanding on your part regarding how the model
in bridge-interop and RFC 4664 works since you are making some claims
listed below that are non-existent if you use the model properly:
 
1) Forwarding at n-PE doesn't go through bridge module at n-PE for
H-VPLS with MPLS access (when packet is switched between access and core
networks)
 
2) VCCV OAM is not sufficient for multi-segment PW which is used for
inter-AS option B and thus we need  additional OAM functionality
 
3) 802.1ag + VCCV does not cover MAC address mapping between PWs and
VPLS forwarders.
 
Let me go through each with you:
 
1) I hope from all the conversation that we have had so far, it is clear
that bridge module is used when doing switching between access and core
networks. This was the original intention when I helped the editors to
put this model in the RFC 4664. And it is the same model that is used in
my bridge-interop draft that has passed WG last call and becoming RFC.
This means that 802.1ag can detect and isolate faults not only at the
u-PE devices but also at the n-PE devices
 
2) The OAM for multi-segment PW needs to be taken care by PW VCCV. If
there is anything missing in this area, then we need to address this
using VCCV PW in PWE3 and not coming with yet another mechanism. The
scope of this work is outside of VPLS since the multi-segment PW can be
directly connected to AC (rather than VSI).
 
3) By having a down MEP at the interface between bridge module and VPLS
forwarder, you can cover both VPLS forwarder and the associated PWs such
that if there is any issue with either forwarder or PW, you can detect
it and isolate the fault accordingly. If you think, there is a scenario,
that cannot be covered in terms of fault detection or isolation, please
be specific.
 
I am supposed to be on my PTO for next couple of weeks so I won't be
checking my emails regardless of how tempting that may be :-) If needed,
I like to ask Dinesh to continue this discussion and provide any
clarifications that may be needed. 
 
Cheers,
Ali

________________________________

	From: KOMPELLA Vach [mailto:[email-masked]] 
	Sent: Friday, December 07, 2007 6:18 PM
	To: Ali Sajassi (sajassi); [email-masked]
	Subject: Re: VPLS OAM != .1ag

	Ali,
	
	As I have repeatedly said, your model doesn't map MAC addresses
in the bridge to PWs in the VPLS forwarders.  This is expressed in the
draft that Olen presented.
	
	It is not enough to say we will test the forwarding through the
bridge and the forwarding of an individual PW to determine the complete
forwarding path. You have to identify the mapping of MAC address to the
associated PW in the VPLS forwarder - somethiing neither .1ag nor VCCV
are capable of.

	Tom, if you see something I don't, can you express it as
something other than "you have the wrong model.". I have given a
concrete example of why I have the right model.
	
	I hope this isn't harking back to the same issue that VPLS-OAM
isn't enough because no-one is saying that. 
	-Vach
	
	----- Original Message -----
	From: Ali Sajassi (sajassi) <[email-masked]>
	To: KOMPELLA Vach; [email-masked] <[email-masked]>
	Sent: Fri Dec 07 18:04:45 2007
	Subject: RE: VPLS OAM != .1ag

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

---

From: Jeremy Brayley <[email-masked]>
Date: Mon, 10 Dec 2007 17:02:50 -0500

Ali (or Dinesh),

> From: Ali Sajassi (sajassi) [mailto:[email-masked]] 
> Sent: Sunday, December 09, 2007 5:29 PM
> To: KOMPELLA Vach; [email-masked]
> I think there is a misunderstanding on your part regarding 
> how the model in bridge-interop and RFC 4664 works since you 
> are making some claims listed below that are non-existent if 
> you use the model properly:
>  
> 1) Forwarding at n-PE doesn't go through bridge module at 
> n-PE for H-VPLS with MPLS access (when packet is switched 
> between access and core networks)
>  
> 2) VCCV OAM is not sufficient for multi-segment PW which is 
> used for inter-AS option B and thus we need  additional OAM 
> functionality
>  
> 3) 802.1ag + VCCV does not cover MAC address mapping between 
> PWs and VPLS forwarders.
>  
> 1) I hope from all the conversation that we have had so far, 
> it is clear that bridge module is used when doing switching 
> between access and core networks. This was the original 
> intention when I helped the editors to put this model in the 
> RFC 4664. And it is the same model that is used in my 
> bridge-interop draft that has passed WG last call and 
> becoming RFC. This means that 802.1ag can detect and isolate 
> faults not only at the u-PE devices but also at the n-PE devices
>  
> 2) The OAM for multi-segment PW needs to be taken care by PW 
> VCCV. If there is anything missing in this area, then we need 
> to address this using VCCV PW in PWE3 and not coming with yet 
> another mechanism. The scope of this work is outside of VPLS 
> since the multi-segment PW can be directly connected to AC 
> (rather than VSI).
>  
> 3) By having a down MEP at the interface between bridge 
> module and VPLS forwarder, you can cover both VPLS forwarder 
> and the associated PWs such that if there is any issue with 
> either forwarder or PW, you can detect it and isolate the 
> fault accordingly. If you think, there is a scenario, that 
> cannot be covered in terms of fault detection or isolation, 
> please be specific.

The issue is with CFM linktrace.  I agree you would have coverage for
CCM and Loopback.  

But let's say rather than a down MEP you have a MIP on the interface
between the bridge module and the forwarder.  And we're talking a simple
full mesh VPLS forwarder, not an H-VPLS case.

Now suppose the bridge module receives a CFM LinkTrace message from one
of its ACs and the target address is known to be reachable through the
emulated LAN interface.  When it responds the MIP is supposed to include
an egress port ID in the LTR.  

In the model you describe, won't the MIP respond only with the emulated
port ID?  (Because the PWs are hidden behind the VPLS forwarder from the
bridge module's persective.)

Now the PE certainly knows the MAC to PW binding, but with the module
you describe I believe the MIP wouldn't report the binding.  Instead it
would likely report the emulated LAN interface as the egress port ID and
rebroadcast the LTM to every PE.  Assuming there are similar MIPs on the
other PEs, you would be able to trace the PEs in the path to the target,
but you would not learn the PWs.  Nor would you be sure that the MAC to
PW binding actually exists in the VPLS forwarder.  The VPLS forwarder
might be forwarding to the target as an unknown unicast even.

I think this is the problem that Vach is talking about.

Note that I believe that CFM is adequate to return the MAC to PW binding
info in LinkTrace.  It just requires CFM to treat the PWs as virtual
ports on the same bridge module and return the right PW as the egress
port ID in the LTR.  The MIP would then rebroadcast the LTM on the right
PW for the target MAC. 

Thanks,

Jeremy

> I am supposed to be on my PTO for next couple of weeks so I 
> won't be checking my emails regardless of how tempting that 
> may be :-) If needed, I like to ask Dinesh to continue this 
> discussion and provide any clarifications that may be needed. 
>  
> Cheers,
> Ali
> 
> 
> 	As I have repeatedly said, your model doesn't map MAC 
> addresses in the bridge to PWs in the VPLS forwarders.  This 
> is expressed in the draft that Olen presented.
> 	
> 	It is not enough to say we will test the forwarding 
> through the bridge and the forwarding of an individual PW to 
> determine the complete forwarding path. You have to identify 
> the mapping of MAC address to the associated PW in the VPLS 
> forwarder - somethiing neither .1ag nor VCCV are capable of.
> 	
> 	Tom, if you see something I don't, can you express it 
> as something other than "you have the wrong model.". I have 
> given a concrete example of why I have the right model.
> 	
> 	I hope this isn't harking back to the same issue that 
> VPLS-OAM isn't enough because no-one is saying that. 
> 	-Vach
>