Subject: RE: [VPLS OAM] Follow-up from Seoul L2VPN session

From: "Serbest, Yetik" <[email-masked]>
Date: Thu, 4 Mar 2004 09:42:58 -0600

Dinesh,

Thank you the concise and excellent update.

OAM for L2VPN services (VPWS and VPLS alike) is an important requirement.

My understanding is that your drafts are summary of the work going on in
ITU-T Q.3/13, IEEE 802.1 and MEF. They are not specific to this group, as
Ethernet layer procedures are defined. There is a draft aimed to be specific
to VPLS. It is the HVPLS-OAM draft, which received four main objections:

1.       Special TTL (Time To Live) processing: HVPLS-OAM proposal requires
that the PE router remember the TTL value of the VC Label (VC-LSP spoke) at
the ingress of the PE, and decrement and place it in the TTL value of the
VC-LSP (PW between PEs) at the egress of the PE. This is a layering
violation.

2.       No support for 802.1Q (VLANs) spokes: HVPLS-OAM proposal is
specifically designed for the architecture with MPLS attachment circuits.

3.       Transport (MPLS) dependency: HVPLS-OAM solution is for MPLS
transport. It does not support IP backbones (e.g., L2TPv3 or IP or GRE
tunnels).

4.       Lack of ECMP (Equal Cost Multi-Path) support: HVPLS-OAM proposal
utilizes an OAM label (value of 14) at the bottom of the label stack, which
is aligned with ITU Y.1711. With ECMP hashing using all the labels in the
stack, OAM packets will not follow the same path as the customer data
packets.

Based on this observation, the question is "do we need to work on OAM
solutions in this group?" As you put it, perhaps we should only define the
requirements/framework for L2VPN OAM, and let other bodies work on the
solutions, e.g., PWE3 for VPWS, ITU/802.1 for VPLS.

I would appreciate some discussion on this in the group.

Thanks,

yetik

-----Original Message-----
From: Dinesh Mohan [mailto:[email-masked]] 
Sent: Wednesday, March 03, 2004 5:32 PM
To: [email-masked]
Subject: [VPLS OAM] Follow-up from Seoul L2VPN session

As a follow-up from yesterday's discussion, let me first point out to the
following slides that were presented during the meeting: 

 <http://urax.utfors.net/~loa/ietf59-vpls-oam-v1.ppt>
http://urax.utfors.net/~loa/ietf59-vpls-oam-v1.ppt 

The drafts that were represented are: 
 
<http://www.ietf.org/internet-drafts/draft-sajassi-mohan-l2vpn-vpls-fm-00.tx
t>
http://www.ietf.org/internet-drafts/draft-sajassi-mohan-l2vpn-vpls-fm-00.txt

<http://www.ietf.org/internet-drafts/draft-mohan-sajassi-l2vpn-vpls-pm-00.tx
t>
http://www.ietf.org/internet-drafts/draft-mohan-sajassi-l2vpn-vpls-pm-00.txt

During the meeting it was acknowledged that VPLS OAM is an important area to
tackle since it is a key requirement for providers. 

It was also my observation that the material was generally well received.
However, few questions that came up during discussions included:

- What really is the scope of VPLS OAM? 
- Should it be different from Ethernet OAM discussions in ITU-T Q.3/13, IEEE
802.1 and MEF since VPLS deals specifically with MPLS/IP transport?

Subsequently, it was generally felt that as next steps: 
- Scope for VPLS OAM needs to be clarified 
- Requirements and Framework for VPLS OAM needs to be created. There would
then serve as inputs to other working groups/bodies.

- VPLS specific OAM solutions should then be worked in IETF. 

Towards that, I would like to add that: 
- The drafts introduce important constructs/framework for dealing with the
OAM that differentiate between the service/network layers. It also aligns
with ongoing OAM work in other bodies (we may not want to re-invent the
wheel!)

- The FM/PM mechanisms proposed in the drafts are applicable for VPLS as a
Ethernet service irrespective of the underlying transport mechanism e.g. LDP
based or BGP based solutions.

- Infact, the mechanisms proposed equally apply to Ethernet VPWS as a
Ethernet service. 
- MPLS based OAM mechanisms belong to the MPLS layer, as highlighted in the
presentation and in the drafts. 
- There is no reason, why service layer OAM mechanisms cannot interwork with
the MPLS-based mechanisms as an optimization, however, for preserving the
layer sanity, each layer still needs to be equipped with right OAM toolset.

Comments? 

Best Regards, 
Dinesh Mohan                                           
Tel: (613) 763-4794 [ESN: 393-4794]     Nortel Networks 
Fax: (613) 763-2697                                 3500 Carling Ave. 
Email: [email-masked]        Ottawa, Canada K1Y4H7 
 <http://www.nortelnetworks.com> http://www.nortelnetworks.com

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 4 Mar 2004 11:06:50 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Serbest, Yetik
Sent: Thursday, March 04, 2004 10:43 AM
To: 'Dinesh Mohan'; [email-masked]
Subject: RE: [VPLS OAM] Follow-up from Seoul L2VPN session

Dinesh,

OAM for L2VPN services (VPWS and VPLS alike) is an important
requirement.

My understanding is that your drafts are summary of the work going on in
ITU-T Q.3/13, IEEE 802.1 and MEF. They are not specific to this group,
as Ethernet layer procedures are defined. There is a draft aimed to be
specific to VPLS. It is the HVPLS-OAM draft, which received four main
objections:

1.       Special TTL (Time To Live) processing: HVPLS-OAM proposal
requires that the PE router remember the TTL value of the VC Label
(VC-LSP spoke) at the ingress of the PE, and decrement and place it in
the TTL value of the VC-LSP (PW between PEs) at the egress of the PE.
This is a layering violation.

2.       No support for 802.1Q (VLANs) spokes: HVPLS-OAM proposal is
specifically designed for the architecture with MPLS attachment
circuits.

4.       Lack of ECMP (Equal Cost Multi-Path) support: HVPLS-OAM
proposal utilizes an OAM label (value of 14) at the bottom of the label
stack, which is aligned with ITU Y.1711. With ECMP hashing using all the
labels in the stack, OAM packets will not follow the same path as the
customer data packets.

Based on this observation, the question is "do we need to work on OAM
solutions in this group?" As you put it, perhaps we should only define
the requirements/framework for L2VPN OAM, and let other bodies work on
the solutions, e.g., PWE3 for VPWS, ITU/802.1 for VPLS.
 
[>]  I think it is important to have a draft such as the one we just
proposed because
it makes clear how to test the complete picture without having people
re-invent

the wheel (i.e.: re-use existing tools/techniques), or try to do things
as described in points 1-4 

for the sake of solving this specific VPLS OAM problem. As such, the
actual mechanisms
probably should be defined in their respective standards bodies (PWs in
PWE3, 
Enet in IEEE, etc...), thus this draft would be considered informational
in nature

as it only describes how to combine these mechanisms together to achieve

the goal of describing comprehensive OAM for VPLS.

    --Tom

Thanks,

yetik

-----Original Message-----
From: Dinesh Mohan [mailto:[email-masked]] 
Sent: Wednesday, March 03, 2004 5:32 PM
To: [email-masked]
Subject: [VPLS OAM] Follow-up from Seoul L2VPN session

As a follow-up from yesterday's discussion, let me first point out to
the following slides that were presented during the meeting: 

 
<http://www.ietf.org/internet-drafts/draft-sajassi-mohan-l2vpn-vpls-fm-0
0.txt>
http://www.ietf.org/internet-drafts/draft-sajassi-mohan-l2vpn-vpls-fm-00
.txt 
 
<http://www.ietf.org/internet-drafts/draft-mohan-sajassi-l2vpn-vpls-pm-0
0.txt>
http://www.ietf.org/internet-drafts/draft-mohan-sajassi-l2vpn-vpls-pm-00
.txt 

During the meeting it was acknowledged that VPLS OAM is an important
area to tackle since it is a key requirement for providers. 

It was also my observation that the material was generally well
received. However, few questions that came up during discussions
included:

- What really is the scope of VPLS OAM? 
- Should it be different from Ethernet OAM discussions in ITU-T Q.3/13,
IEEE 802.1 and MEF since VPLS deals specifically with MPLS/IP transport?

Subsequently, it was generally felt that as next steps: 
- Scope for VPLS OAM needs to be clarified 
- Requirements and Framework for VPLS OAM needs to be created. There
would then serve as inputs to other working groups/bodies.

Towards that, I would like to add that: 
- The drafts introduce important constructs/framework for dealing with
the OAM that differentiate between the service/network layers. It also
aligns with ongoing OAM work in other bodies (we may not want to
re-invent the wheel!)

- The FM/PM mechanisms proposed in the drafts are applicable for VPLS as
a Ethernet service irrespective of the underlying transport mechanism
e.g. LDP based or BGP based solutions.

- Infact, the mechanisms proposed equally apply to Ethernet VPWS as a
Ethernet service. 
- MPLS based OAM mechanisms belong to the MPLS layer, as highlighted in
the presentation and in the drafts. 
- There is no reason, why service layer OAM mechanisms cannot interwork
with the MPLS-based mechanisms as an optimization, however, for
preserving the layer sanity, each layer still needs to be equipped with
right OAM toolset.

Comments? 

Best Regards, 
Dinesh Mohan

---

From: Ali Sajassi <[email-masked]>
Date: Thu, 04 Mar 2004 12:29:47 -0800

Hi Yetik,

Given that VPLS service as defined in the L2VPN framework is an emulated 
LAN service wrt to a group of CEs and it can use different PSN network 
(e.g., IP or MPLS), it is important to be able to address VPLS OAM at the 
service layer (as well as network layer) and for different types of PSN. 
The propose of this draft is mainly two folds: 1) to inform the IETF 
community of the current mechanisms under development in other standard 
bodies in regard to Ethernet services and 2) to show the applicability of 
these mechanisms to VPLS service.

The draft just describes the concepts and mechanisms for fault management 
portion of OAM at the high level and it does that in order to acquaint the 
IETF audience with the type of tools/mechanisms that will be available for 
this purpose and to open the discussion to see if these tools are enough 
for FM aspect of VPLS service or do we need to consider additional 
tools/mechanisms.

The mechanisms that are discussed in the draft, are being worked on in 
other standard bodies such as ITU, MEF, and IEEE and I would expect the 
detail message specifications to be done in IEEE. However, we just want to 
ensure that L2VPN is informed of the activity and its applicability and its 
coverage to VPLS - e.g., whether VPLS FM is covered well with these 
mechanisms or not.

I think this is a good informative draft for the subject of VPLS  fault 
management as it describes at high level how FM tools for Ethernet can be 
applied to VPLS.

-Ali

At 09:42 AM 3/4/2004 -0600, Serbest, Yetik wrote:

>Ethernet layer procedures are defined. There is a draft aimed to be 
>requires that the PE router remember the TTL value of the VC Label (VC-LSP 
>spoke) at the ingress of the PE, and decrement and place it in the TTL 
>value of the VC-LSP (PW between PEs) at the egress of the PE. This is a 
>layering violation.
>
>utilizes an OAM label (value of 14) at the bottom of the label stack, 
>which is aligned with ITU Y.1711. With ECMP hashing using all the labels 
>in the stack, OAM packets will not follow the same path as the customer 
>data packets.
>
>
>
><http://urax.utfors.net/~loa/ietf59-vpls-oam-v1.ppt>http://urax.utfors.net/~loa/ietf59-vpls-oam-v1.ppt 
>
>
><http://www.ietf.org/internet-drafts/draft-sajassi-mohan-l2vpn-vpls-fm-00.txt>http://www.ietf.org/internet-drafts/draft-sajassi-mohan-l2vpn-vpls-fm-00.txt 
>
>During the meeting it was acknowledged that VPLS OAM is an important area 
>to tackle since it is a key requirement for providers.
>
>with ongoing OAM work in other bodies (we may not want to re-invent the wheel!)
>
>Ethernet service irrespective of the underlying transport mechanism e.g. 
>LDP based or BGP based solutions.
>
>with the MPLS-based mechanisms as an optimization, however, for preserving 
>the layer sanity, each layer still needs to be equipped with right OAM toolset.
>
>Comments?
>
>Best Regards,
>Dinesh Mohan
><http://www.nortelnetworks.com>http://www.nortelnetworks.com
>
>