Subject: [mpls-tp] Linear Ether APS-g8031

From: Saravanan P <[email-masked]>
Date: Sun, 26 Dec 2010 21:14:48 -0800

Folks,

I am implementing Ether APS channel functionality over pseudo wire/LSP  and using BFD for CCM . As per my understanding  Liner protection switching functionality shall be implemented by two standard  IETF(draft-ietf-mpls-tp-linear-protection) and another one is I-TUT (g8031).

CCM functionality would be either y.1731 or BFD but EtherAps should be g8031 or IETF.

Is this combination work in field and any one foresee  interoperability issue? I don't see anywhere in requirement document for g8031 as an  APS option on LSP/PW

Regards,
Saravanan.
www.ixiacom.com<http://www.ixiacom.com>

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 27 Dec 2010 10:06:51 +0100

Hello Saravanan,

You wrote:

> I am implementing Ether APS channel functionality over pseudo wire/LSP
> and using BFD for CCM . As per my understanding Liner protection
> switching functionality shall be implemented by two standard
> IETF(draft-ietf-mpls-tp-linear-protection) and another one is I-TUT (g8031).

FYI: G.8031 is the linear protection for Ethernet.
G.8131 is linear protection for MPLS-TP, see also
http://tools.ietf.org/html/draft-zulr-mpls-tp-linear-protection-switching
which is based on G.8131.

> CCM functionality would be either y.1731 or BFD but EtherAps should be

The linear protection uses the SF (signal/service fail) as trigger.
SF detection can be based on MT-CCM defined in
http://tools.ietf.org/html/draft-bhh-mpls-tp-oam-y1731
or on extended BFD.

> Is this combination work in field and any one foresee interoperability
> issue?

The MT-CCM and G.8131 combination has been tested several times
by EANTC and is deployed in China by major operators in many nodes.

> I don’t see anywhere in requirement document for g8031 as an APS
> option on LSP/PW.

As I mentioned above look for G.8131, but you will not
find that in any requirement document as this is considered
a solution of the generic "linear protection requirement".

Best regards, Huub.

-- 
*****************************************************************
                          我爱外点一七三一

---

From: Saravanan P <[email-masked]>
Date: Mon, 27 Dec 2010 01:32:07 -0800

Hello Huub,

Thanks for this clarification.
Can I consider flowing two drafts are different option for implementing APS in MPL-TP?

1) Linear Protection Switching in MPLS-TP  draft-zulr-mpls-tp-linear-protection-switching-01.txt

2) MPLS-TP Linear Protection  draft-ietf-mpls-tp-linear-protection-03.txt

Regards,
Saravanan.

-----Original Message-----
From: Huub van Helvoort [mailto:[email-masked]]
Sent: Monday, December 27, 2010 2:37 PM
To: Saravanan P
Cc: [email-masked]
Subject: Re: [mpls-tp] Linear Ether APS-g8031

Hello Saravanan,

FYI: G.8031 is the linear protection for Ethernet.
G.8131 is linear protection for MPLS-TP, see also http://tools.ietf.org/html/draft-zulr-mpls-tp-linear-protection-switching
which is based on G.8131.

> Is this combination work in field and any one foresee interoperability

The MT-CCM and G.8131 combination has been tested several times by EANTC and is deployed in China by major operators in many nodes.

> I don’t see anywhere in requirement document for g8031 as an APS

As I mentioned above look for G.8131, but you will not find that in any requirement document as this is considered a solution of the generic "linear protection requirement".

Best regards, Huub.

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 27 Dec 2010 10:54:44 +0100

Hello Saravanan,

> 2) MPLS-TP Linear Protection  draft-ietf-mpls-tp-linear-protection-03.txt

I would like to avoid to have options.

When I started as co-editor of the linear protection draft
it was my objective to use G.8131 as basis because the protocol
described in G.8131 is based on experience with that protocol
in other packet technologies and TDM.

However, the other editors made several changes to the protocol
which made it in fact a new -untested- protocol.

That is the reason I resigned as co-editor and support draft-zulr
because that is still based on G.8131 and has been used in
interop tests.

Best regards, Huub.

---

From: Saravanan P <[email-masked]>
Date: Mon, 27 Dec 2010 02:08:12 -0800

Hello Huub,

Should I wait till either one of the following solutions would  become matured RFC standard.
Or this would be vendor option.
Regards,
Saravanan.

-----Original Message-----
From: Huub van Helvoort [mailto:[email-masked]]
Sent: Monday, December 27, 2010 3:25 PM
To: Saravanan P
Cc: [email-masked]
Subject: Re: [mpls-tp] Linear Ether APS-g8031

Hello Saravanan,

You replied:

> 1) Linear Protection Switching in MPLS-TP
> draft-zulr-mpls-tp-linear-protection-switching-01.txt
>
> 2) MPLS-TP Linear Protection
> draft-ietf-mpls-tp-linear-protection-03.txt

When I started as co-editor of the linear protection draft it was my objective to use G.8131 as basis because the protocol described in G.8131 is based on experience with that protocol in other packet technologies and TDM.

However, the other editors made several changes to the protocol which made it in fact a new -untested- protocol.

That is the reason I resigned as co-editor and support draft-zulr because that is still based on G.8131 and has been used in interop tests.

Best regards, Huub.

>> I am implementing Ether APS channel functionality over pseudo
>> wire/LSP and using BFD for CCM . As per my understanding Liner
>> protection switching functionality shall be implemented by two
>> standard
>> CCM functionality would be either y.1731 or BFD but EtherAps should
>> be
>> g8031 or IETF.
>
>> Is this combination work in field and any one foresee
>> interoperability issue?
>

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 27 Dec 2010 14:57:56 +0100

Hello Saravanan,

 > become matured RFC standard.

This depends on how long you like to wait.

> Or this would be vendor option.

It is up to the vendors to decide what should be implemented.
It depends on where you want to deploy your equipment.
You may find some help/hints in:
http://tools.ietf.org/id/draft-fang-mpls-tp-oam-considerations

Best regards, Huub.