Subject: [PWE3] new rev : draft-ietf-pwe3-ms-pw-requirements-05.txt

From: Luca Martini <[email-masked]>
Date: Wed, 21 Mar 2007 04:16:11 -0600

WG,

After a very good review by our chair , Danny, I updated the MS-PW 
requirements draft to V05.
The update contains only English wording , and grammar changes, a a 
deletion of the following unclear statement:

-iv. MS-PW OAM SHOULD support switch over between 1:1 protected
            LSPs end-to-end.

Note that support for this is already included in the PWE3 architectures 
, and it makes no sense for MS-PW in this context.
if anybody can figure out what was really meant by this statement I 
would be happy to add something that is more clear.

Thanks.
Luca

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 21 Mar 2007 08:34:01 -0400

I think you mean something like this:

	1) MS-PW OAM SHOULD provide a mechanism by which
		loss of connectivity or degradation of 	
		the expected path quality in one or more
		of the MS-PW segments
		is detected, and then used to trigger a
		protection mechanism used to choose an alternate
		path for the end-to-end MS-PW to use.

		Note that MS-PW OAM SHOULD be
		should be used in conjunction with the underlying 			OAM mechanisms  
to detect faults, especially
		in cases where the MS-PW OAM mechanisms are
		capable of detecting faults on the same
		order of time as those used to detect faults on
		the underlying LSPs.

	3) Some operational scenarios require that the
		the underlying OAM mechanisms used to
		protect the actual LSP(s) carrying the
		MS-PWs use their local protection
		mechanisms to repair a fault (i.e. MPLS
		TE-FRR). In these cases, the MS-PW OAM
		mechanism may still be able to detect
		the fault and therefore MUST be capable of
		suppressing this alarm (or correlating it with
		the previous fault) so as to not duplicate the
		original alarm, as this could result in
		unnecessary flapping between the alternate
		paths.

> Note that support for this is already included in the PWE3  
> architectures , and it makes no sense for MS-PW in this context.

---

From: Luca Martini <[email-masked]>
Date: Wed, 21 Mar 2007 06:06:30 -0600

>         path for the end-to-end MS-PW to use.
This still does not parse correctly.
You want a mechanism to detect packet loss , and then take some kind 
action ?
It sounds like a PW requirement.  What special part of this requirement 
is specific to MS-PW ?

Luca

>         should be used in conjunction with the underlying             
> OAM mechanisms to detect faults, especially

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 21 Mar 2007 10:35:07 -0400

On Mar 21, 2007:8:06 AM, at 8:06 AM, Luca Martini wrote:

>>         loss of connectivity or degradation of            the  
>> expected path quality in one or more
>>         of the MS-PW segments

	That is why I said "something like this" *)

> You want a mechanism to detect packet loss , and then take some  
> kind action ?

	I want such a mechanism that works for MH-PWs.

> It sounds like a PW requirement.  What special part of this  
> requirement is specific to MS-PW ?

	I agree, this isn't specific to MH-PWs, as pw redundancy is
applicable to SH PWs, but it should also apply to MH-PWs, and
any specific changes needed for it to continue working using
similar/same semantics as before should also be a requirement.

	--Tom

>>         should be used in conjunction with the  
>> underlying             OAM mechanisms to detect faults, especially
>>> After a very good review by our chair , Danny, I updated the MS- 
>>> PW requirements draft to V05.
>>> The update contains only English wording , and grammar changes, a  
>>> a deletion of the following unclear statement:
>>>
>>> if anybody can figure out what was really meant by this statement  
>>> I would be happy to add something that is more clear.
>>>
>>> Thanks.
>>> Luca
>>>
>>>

---

From: "O'Connor, Don" <[email-masked]>
Date: Wed, 21 Mar 2007 11:13:41 -0500

The original requirement was (From Section 6.3.3 Resiliency)

"The solution should allow for the protection of a PW-segment, a
   contiguous set of PW-segments, as well as the end-end path."

and from Section 7 on OAM

"MS-PW OAM SHOULD support switch over between 1:1 protected
LSPs end-to-end."

It appears to me that the intent of these requirements was to request support for bidirectional 1:1 protection switching for MS-PW end to end between T-PEs where protection switching is supported by a PW OAM protocol. The support takes two forms

1) Fault detection

2) Coordination of subsequent protection switching - make before break, revertive / non-revertive / forced switch / "extra traffic"

ITU-T has generated recommendations for Ethernet Protection Switching (G.8031) and T-MPLS Protection Switching (G.8131),which provide models for the functionality that was requested by the requirement under discussion 

A free copy of G.8031 can be obtained from the following ITU link

http://www.itu.int/rec/T-REC-G.8031-200606-I/en

G.8131 was recently approved and is in the pre-publication stage

Ethernet Protection 1:1 Switching is coordinated by extensions to the Ethernet OAM protocol Y.1731 / IEEE 802.1ag

Tom's suggested expansion of the 1:1 protection requirement raised the issue of the relationship between EE MS-PW protection and underlying protection mechanisms such as MPLS TE-FRR. ITU has been doing linear protection switching for many years going back to circuit switched recommendations. This issue has typically been addressed by using a hold-off timer. For reference please see Section 11.2 of G.8031.

In summary I suggest Section 6.3.3 Resiliency should be updated as follows

The solution should allow for the protection of a PW-segment, a
   contiguous set of PW-segments, as well as the end-end path.

[Add the following - End-end path protection should be bidirectional 1:1 protection switching. An OAM protocol should be used to detect the fault and monitor the continuity of the protection path. Protection switching should be coordinated by an appropriate end-end protocol] 

The primary and protection segments paths must share the same segments
   endpoints. Solutions should allow for having the backup paths setup
   prior to the failure or as a result of failure. The choice should be
   made by configuration. When resources are limited and cannot satisfy
   all PWs, the PWs with the higher setup priorities should be given
   preference when compared with the setup priorities of other PWs being
   setup or the holding priorities of existing PWs.

I suggest that Section 7.0 item iv be updated to indicate

"MS-PW OAM SHOULD support the end-end 1:1 protected switching discussed in Section 6.3.3"

Regards

Don

-----Original Message-----
From: Thomas D. Nadeau [mailto:[email-masked]]
Sent: Wednesday, March 21, 2007 9:35 AM
To: Luca Martini
Cc: pwe3
Subject: Re: [PWE3] new rev : draft-ietf-pwe3-ms-pw-requirements-05.txt

	--Tom