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

From: "Monique Morrow (mmorrow)" <[email-masked]>
Date: Thu, 4 Mar 2004 23:50:07 +0100

Ali et al,
 
I would have to agree with your assessment of the draft,its
applicability to VPLS service and the alignment to IEEE,  ITU-T, and MEF
. 
It is reasonable therefore,to ask this WG whether or not the mechanisms
that are being developed elsewhere shall be sufficient as a base for
VPLS FM.
 
Monique

	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ali Sajassi (sajassi)
	Sent: 04 March 2004 21:30
	To: Serbest, Yetik; 'Dinesh Mohan'; [email-masked]
	Subject: RE: [VPLS OAM] Follow-up from Seoul L2VPN session

	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:

		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 
		
		The drafts that were represented are: 
	
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
.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

---

From: Loa Andersson <[email-masked]>
Date: Mon, 08 Mar 2004 00:09:21 +0100

All,

what we said in summarising the Seoul meeting was that there are
three possible areas we need to look at to see if the working
need to do any work.

- definition of vpls specific OAM (could be a framework)
- if there are vpls specific OAM requirements that we need
   to produce, in order to support other standards organizations
   in their work
- if there are protocol extensions to existing IETF protocols we need to
   initiate in the IETF for vpls specific OAM

It was also accepted that most of the OAM work (read non-vpls specific)
should be done in other standards organizations.

/Loa

-- 

Loa Andersson

mobile +46 739 81 21 64