does Y.1731 support for VPLS service under ASR 9000 platform?

[Eric Guo]

Hi All,

we are planning to setup OAM for monitoring performance of our VPLS service interface? By checked Cisco document, I couldn't find related document  that can confirm Y.1731 support multi-point to mulit-point interface by full mesh topology in our environment.

Does someone have this kind of experience that could share with me?  The document or configuration example are welcomed as well.

Thanks in advance,

Eric.

[xthuijs]

Hi Eric,

yes that can be done, but just to note that the CFM service is p2p, that is you check a circuit from endpoint to endpoint, but those endpoints can be found via bridges.

Got a picture with config for you attached:

xander

[Eric Guo]

thanks Xander for your input!

on top of this question. Actually, I am looking for better solution to monitoring mutli interfaces at same time. In our environment, we have many of this kind L2vpn setup for customer. instead of monitor end by end,  we want to monitor them from central point of view. do you have a better idea for this?

I attached one customer setup example below, and diagram as well.

At the meantime, we also looking for a good idea for how to setup hierarchical monitoring system that it could cross other SP domain.

thanks,

Eric.

PE-siteA:
============

L2vpn

 pw-class encap-mpls
  encapsulation mpls
  !

bridge group customer
  bridge-domain customer
   interface GigabitEthernet0/1/0/1.100
   !
   vfi 100
    neighbor PE-siteB loopback-IP pw-id 100
     pw-class encap-mpls
    !
    neighbor PE-ASBR loopback-IP pw-id 100
     pw-class encap-mpls
    !
   !
 !

=============

PE-siteB:
============

bridge group customer
  bridge-domain customer
   interface GigabitEthernet0/2/0/1.100
   !
   vfi 100
    neighbor PE-siteA loopback-IP pw-id 100
     pw-class encap-mpls
    !
    neighbor PE-ASBR loopback-IP pw-id 100
     pw-class encap-mpls
    !
   !
 !

=============
PE-siteC:
=============

bridge group customer
  bridge-domain customer
   interface GigabitEthernet0/1/0/2.100
   !
   interface GigabitEthernet0/5/0/2.100
   vfi 100
    neighbor PE-siteA loopback-IP pw-id 100
     pw-class encap-mpls
    !
    neighbor PE-siteB loopback-IP pw-id 100
     pw-class encap-mpls
    !
   !
 !

==============

PE interface setup:

==============

interface GigabitEthernet0/1/0/2.100 l2transport
 encapsulation dot1q 100
 rewrite ingress tag pop 1 symmetric

=================================

[xthuijs]

Totally understand your scenario Eric, and there are a few options as to how you can go about it.

If you want truly service level "assurance" or monitoring, there is no other way then setting up these probes on a per site/AC to site/AC bases, which means that in a 3 PE node design, you'll have to create a "triangle" of CFM checks from A to B, B to C and A to C.

But this can grow out of hand quickly when you have numerous l2vpn's in overlayed in this.

Another approach is to check PE to PE access on LDP. For instance, set up mpls probes that checks the PE to PE access, this assumes then that the AC and BD itself are all square so it doesn't give you a true service level measuring, but it provides some notification already on the PE access.

Another approach is to set up a single BD for verification purposes and run SLA probes from attached test CE's to remote CE's. This way you have service level measuring for true, but this omits the individiual verifications and status monitoring of your customer AC obviously, but is another approach you can take. This would prove that the service is operational, but doesnt test the individual BD's.

So you could select an individual option and provide say an upsell to your customers that they can get individual monitoring with 1731 for instance.

1731 provides for a great level of delay and jitter monitoring or just basic connectivity test.

each customer themselves can also use (udp) probes to verify their end to end service or "outsource" it to you.

Managing the probes can be done with eg applications like Prime which is a good app that can help with the service level assurance.

regards

xander

[Eric Guo]

thanks again Xander for your sharing !

If in future ASR 9K XR release,  we could set up hierarchy CFM for single VPLS service multiplex interfaces full-mesh topology. It would be great.

thanks,

Eric,

[xthuijs]

It is a nice thought indeed, but the problem is that the 1731 protocol itself doesn't allow for multidrop, or having the ability to have instances on a parent or things like that.

it would require a protocol extension to simplify its use, right now as per the original design, it was meant to serve as p2p.

if you are passionate about this, you could comment on the spec and request that extension, and if that gets honored, then surely every vendor will follow if it receives enough traction.

If we were to do this only on the a9k/xr, then it will result in a lot of interop issues without it being standardized.

hopefully that makes sense... not that I am not willing, but it is too risky "to go your own way" in these situations without a standardized agreement.

xander

[Eric Guo]

understood.

[Eric Guo]

Hi Xander,

I check around  EtherCFM MIB patch for Cisco XR platform, but I didn't find one.

do you have a clue for this?

thanks, Eric

[xthuijs]

Hi ERic,

Have you tried the  Module: IEEE8021-CFM-MIB

this should work and is supported.

xander

[Eric Guo]

thanks Xander for your information, I will check. 

Eric.