Subject: [mpls] RE: [PWE3] Fwd: I-D ACTION:draft-bryant-pwe3-mpls-transport-00.txt

From: "O'Connor, Don" <[email-masked]>
Date: Thu, 22 Mar 2007 10:52:23 -0500

I do not support draft-bryant-pwe3-mpls-transport-00.txt as a WG draft for the following reasons

1) Transport MPLS as pursued by ITU encompasses functionality that overlaps work in multiple IETF WGs. A minimum subset is PWE3 and MPLS. Work in CCAMP is also most probably relevant. Without companion work in the MPLS WG on a T-MPLS implementation profile, draft-bryant-pwe3-mpls-transport-00.txt serves no useful purpose

I suggest that a first necessary step is that the appropriate Area Directors consider whether or not they want to take on the entire task of generating a complete Transport MPLS implementation profile based on current RFC / ID / extensions and doing it right and comprehensively. WG charters should be updated appropriately

In its present form draft-bryant-pwe3-mpls-transport-00.txt is an incomplete attempt at addressing a portion of what ITU SG 15 and ITU SG 13 are pursuing for Transport MPLS

If IETF leadership decides that they would like to pursue a comprehensive Transport MPLS implementation profile, it should be done in cooperation and coordination with leadership in ITU SG 15 and SG 13. I would support such as effort if it is done in this context. To date draft-bryant-pwe3-transport-00.txt does not fall into this category

2) draft-bryant-pwe3-mpls-transport-00.txt does not adequately address Transport MPLS OAM and Protection Switching requirements

2A) Protection Switching - linear protection switching coordinated by an appropriate OAM protocol is required. It is necessary to meet the requirements of G.8131

2B) Current pseudowire VCCC OAM lacks - Maintenance Entity Levels, MEP / MIP, AIS / RDI, PM measurement. It is necessary to provide the functionality being developed for Y.17tom

Regards

Don

-----Original Message-----
From: Danny McPherson [mailto:[email-masked]]
Sent: Thursday, March 22, 2007 4:31 AM
To: pwe3 ((((((((E-mail)))))))) WG
Subject: [PWE3] Fwd: I-D ACTION:draft-bryant-pwe3-mpls-transport-00.txt 

Folks,
As discussed in the meeting, I'd like to solicit WG feedback on
adopting this as a WG document.   If you're in favor or opposed
to adopting this please speak up now.

-danny

Begin forwarded message:

> From: [email-masked]
> Date: October 16, 2006 1:50:01 PM MDT
> To: [email-masked]
> Subject: I-D ACTION:draft-bryant-pwe3-mpls-transport-00.txt
> Reply-To: [email-masked]
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> 	Title		: Application of PWE3 to MPLS Transport Networks
> 	Author(s)	: S. Bryant
> 	Filename	: draft-bryant-pwe3-mpls-transport-00.txt
> 	Pages		: 13
> 	Date		: 2006-10-16
> 	
>   A need has been identified to identify a strict subset of the PWE3
>   over MPLS pseudowire functionality suitable for the construction of
>   transport networks. This draft describes the IETF recommended  
> profile
>   for such cases. This document describes the IETF-recommended profile
>   for such a configuration. In particular the profile of an RFC4448
>   PWE3 Ethernet pseudowire that can be used to address these
>   requirements is described.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-bryant-pwe3-mpls- 
> transport-00.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
> Internet-Drafts are also available by anonymous FTP. Login with the
> username "anonymous" and a password of your e-mail address. After
> logging in, type "cd internet-drafts" and then
> "get draft-bryant-pwe3-mpls-transport-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-bryant-pwe3-mpls-transport-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> Content-Type: text/plain
> Content-ID: <[email-masked]>
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce

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

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

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 22 Mar 2007 13:59:37 -0400

Hi,

> 1) Transport MPLS as pursued by ITU encompasses functionality that  
> overlaps work in multiple IETF WGs. A minimum subset is PWE3 and  
> MPLS. Work in CCAMP is also most probably relevant. Without  
> companion work in the MPLS WG on a T-MPLS implementation profile,  
> draft-bryant-pwe3-mpls-transport-00.txt serves no useful purpose

	Although Townsley and Ross/Ward should declare
which WGs are most relevant for this draft, my two
cents are that although PWE3 and MPLS are surely relevant to the
draft as-written, I don't see where CCAMP (or any other WG)
needs to be involved other than PWE3 since the purpose of
the draft is to show how the requirements for T-MPLS can
be solved using a few "off the shelf" and already deployed
protocols.

> I suggest that a first necessary step is that the appropriate Area  
> Directors consider whether or not they want to take on the entire  
> task of generating a complete Transport MPLS implementation profile  
> based on current RFC / ID / extensions and doing it right and  
> comprehensively. WG charters should be updated appropriately

	Why do charters need to be updated? If you have read the draft,
we have shown how a "comprehensive T-MPLS solution" can be built only
using existing (and deployed) protocols.  What you are advocating is
slowing down the progress on this issue with needless procedural  
process.

> In its present form draft-bryant-pwe3-mpls-transport-00.txt is an  
> incomplete attempt at addressing a portion of what ITU SG 15 and  
> ITU SG 13 are pursuing for Transport MPLS

	Perhaps you could elaborate on this statement?

> If IETF leadership decides that they would like to pursue a  
> comprehensive Transport MPLS implementation profile, it should be  
> done in cooperation and coordination with leadership in ITU SG 15  
> and SG 13. I would support such as effort if it is done in this  
> context. To date draft-bryant-pwe3-transport-00.txt does not fall  
> into this category

	I think the point is that the IETF leadership has already
decided to pursue T-MPLS by virtue of it being a true subset of
MPLS/PWE3. I don't see why any further procedural actions are
necessary to move this work forward.

> 2) draft-bryant-pwe3-mpls-transport-00.txt does not adequately  
> address Transport MPLS OAM and Protection Switching requirements

	Please be specific.

> 2A) Protection Switching - linear protection switching coordinated  
> by an appropriate OAM protocol is required. It is necessary to meet  
> the requirements of G.8131

	Please be specific.

> 2B) Current pseudowire VCCC OAM lacks - Maintenance Entity Levels,  
> MEP / MIP, AIS / RDI, PM measurement. It is necessary to provide  
> the functionality being developed for Y.17tom

	Although this is true, adding these is not difficult, and
is something that is already being discussed as part of the MH-VCCV
work.

	--Tom

---

From: "O'Connor, Don" <[email-masked]>
Date: Thu, 22 Mar 2007 15:32:13 -0500

Tom,

Please see my replies below

Regards

Don

-----Original Message-----
From: Thomas D. Nadeau [mailto:[email-masked]]
Sent: Thursday, March 22, 2007 1:00 PM
To: O'Connor, Don
Cc: Danny McPherson; pwe3 ((((((((((((((((E-mail)))))))))))))))) WG;
Swallow George; [email-masked]; Townsley Mark; Ward David; Ross Callon
Subject: Re: [PWE3] Fwd: I-D
ACTION:draft-bryant-pwe3-mpls-transport-00.txt 

	Hi,

[Don - CCAMP involvement may not be needed in the near term, but my view is that it would be needed in the longer term if a more comprehensive relationship is developed between ITU SG 15 and IETF for Transport MPLS standardization (including the Control Plane aspects). For example for Transport Multi-Segment Pseudowires the preferred signaling solution could be GMPLS RSVP-TE rather than LDP]

[Don - My understanding is that the goals / perceived applications of Transport MPLS go beyond the Ethernet Port connectivity scenario in the existing draft. I think a longer term commitment is needed than just the draft in question. Consequently a potential appropriate step would be charter updates for PWE3 and MPLS WGs. As a near term minimum I think the MPLS WG should agree to work on Transport MPLS RFCs. Section 4 of the draft in question could be used as a starting basis for an ID on Transport MPLS LSPs. My understanding is that ITU also wishes to support P2MP Transport MPLS LSPs. So this would require an implantation profile from the MPLS WG.]

[Don - I will offer several examples - Multi-Segment Transport Pseudowires, protection switching as defined in G.8131, Transport MPLS Ring Protection, OAM as defined in Y.17tor / Y.17tom, ID on Transport MPLS LSPs including P2MP, Control Plane LDP per segmented PWs may not be the appropriate solution]

[Don - I think a more comprehensive longer term commitment is needed beyond draft-bryant]

	Please be specific.

[Don - please see G.8131,G.8031, Y.17tor / Y.17tom]

	Please be specific.

[Don - please see the detailed functionality in G.8131 and G.8031]

[Don - One potential way to add the missing OAM functionality is to: 1) Allocate VCCV code points for "Y.1731 / 802.1ag for pseudowires" and 2)modify Y.1731 / 802.1ag for use with VCCV (e.g. use AII rather than Ethernet SA / DA] 

	--Tom

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 22 Mar 2007 16:49:51 -0400

On Mar 22, 2007:4:32 PM, at 4:32 PM, O'Connor, Don wrote:

> [Don - CCAMP involvement may not be needed in the near term, but my  
> view is that it would be needed in the longer term if a more  
> comprehensive relationship is developed between ITU SG 15 and IETF  
> for Transport MPLS standardization (including the Control Plane  
> aspects). For example for Transport Multi-Segment Pseudowires the  
> preferred signaling solution could be GMPLS RSVP-TE rather than LDP]

	Perhaps. FYI, our draft, as-written supports both static
and signaled paths via GMPLS/RSVP-TE. From section 4.2:

	 In this section we describe the profile when RSVP-TE [] or the bi-
	 directional support in GMPLS [] are used to configure the MPLS PSN
	 used to provide the transport LSPs.

> [Don - My understanding is that the goals / perceived applications  
> of Transport MPLS go beyond the Ethernet Port connectivity scenario  
> in the existing draft. I think a longer term commitment is needed  
> than just the draft in question. Consequently a potential  
> appropriate step would be charter updates for PWE3 and MPLS WGs. As  
> a near term minimum I think the MPLS WG should agree to work on  
> Transport MPLS RFCs. Section 4 of the draft in question could be  
> used as a starting basis for an ID on Transport MPLS LSPs. My  
> understanding is that ITU also wishes to support P2MP Transport  
> MPLS LSPs. So this would require an implantation profile from the  
> MPLS WG.]

	I still don't see why the charters need to be updated per se,
except perhaps to add milestones for these work items explicitly.
Whether or not that is necessary is again up to the chairs/ADs, but
IMHO it is unnecessary.

> [Don - I will offer several examples - Multi-Segment Transport  
> Pseudowires, protection switching as defined in G.8131, Transport  
> MPLS Ring Protection, OAM as defined in Y.17tor / Y.17tom, ID on  
> Transport MPLS LSPs including P2MP, Control Plane LDP per segmented  
> PWs may not be the appropriate solution]
> [Don - One potential way to add the missing OAM functionality is  
> to: 1) Allocate VCCV code points for "Y.1731 / 802.1ag for  
> pseudowires" and 2)modify Y.1731 / 802.1ag for use with VCCV (e.g.  
> use AII rather than Ethernet SA / DA]

	Another is to modify y.17tom (which is a fantastic way to
name a document I might add!)  to reference y.1714.  We have in
fact already made recent contributions to do so. And of course, as
I said, to add MIP/MEPs to MH-VCCV.

	--Tom

---

From: "O'Connor, Don" <[email-masked]>
Date: Thu, 22 Mar 2007 16:30:32 -0500

Tom

Your reply below indicated that

"Perhaps. FYI, our draft, as-written supports both static
and signaled paths via GMPLS/RSVP-TE. From section 4.2:

	 In this section we describe the profile when RSVP-TE [] or the bi-
	 directional support in GMPLS [] are used to configure the MPLS PSN
	 used to provide the transport LSPs."

My initial comment was

"For example for Transport Multi-Segment Pseudowires the  
> preferred signaling solution could be GMPLS RSVP-TE rather than LDP"

This comment did not refer to signaling for the MPLS PSN (as in section 4.2). This comment suggested that maybe GMPLS RSVP-TE could be used for Transport Pseudowire signaling for multi-segment transport pseudowires. 

Regards

Don

-----Original Message-----
From: Thomas D. Nadeau [mailto:[email-masked]]
Sent: Thursday, March 22, 2007 3:50 PM
To: O'Connor, Don
Cc: Danny McPherson; pwe3 ((((((((((((((((E-mail)))))))))))))))) WG;

	--Tom

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 23 Mar 2007 08:43:09 +0000

O'Connor, Don wrote:

> 
> 1) Transport MPLS as pursued by ITU encompasses functionality
that overlaps work in multiple IETF WGs. A minimum subset is PWE3
and MPLS. Work in CCAMP is also most probably relevant. Without
companion work in the MPLS WG on a T-MPLS implementation profile,
draft-bryant-pwe3-mpls-transport-00.txt serves no useful purpose

As I understand it T-MPLS is a strict subset of MPLS, so I am
at a loss to understand why additional MPLS work is needed. Indeed
if work is needed, it is NOT a true subset, should not be called
xMPLS and most important MUST NOT use the MPLS codepoints. So
if you are correct we should be send an urgent Liaison requiring
ITU to withdraw the T-MPLS specification.

> 
> I suggest that a first necessary step is that the appropriate 
Area Directors consider whether or not they want to take on the
entire task of generating a complete Transport MPLS implementation
profile based on current RFC / ID / extensions and doing it right
and comprehensively. WG charters should be updated appropriately

If extensions are needed it is surely not a TRUE subset, and
appropriate ammendments need to be made to the ITU specs.

> 
> In its present form draft-bryant-pwe3-mpls-transport-00.txt is 
an incomplete attempt at addressing a portion of what ITU SG 15
and ITU SG 13 are pursuing for Transport MPLS

Please could you be more specific - perhaps contributing text?

> 
> If IETF leadership decides that they would like to pursue 
a comprehensive Transport MPLS implementation profile, it
should be done in cooperation and coordination with leadership
in ITU SG 15 and SG 13. I would support such as effort if
it is done in this context. To date
draft-bryant-pwe3-transport-00.txt does not fall into this
category

Again please be specific.

"Define requirements for and mechanisms to provide
protection and restoration of PWs." is an element of the
PWE3 existing charter. There seems no reason why a suitable
design would not encompass the requirements of a transport
application.

Please could you articulate any specific aspects of a PW
solution that we need to be careful to address that you
would not ordinarily expect us to address. Perhaps
I could encourage you to submit a solutions draft on
the subject of protection mechanisms?

I will leave that to the OAM specialist to respond on, but
I do not see any reason why transport should have any
requirements that diverge from the normal PW case, i.e. if
a requirement is NEEDED in one domain, I would expect it to
be NEEDED in the other.

- Stewart

---

From: "Italo Busi" <[email-masked]>
Date: Fri, 23 Mar 2007 11:46:44 +0100

Stewart,

see in line marked with [ib]

Italo

> From: Stewart Bryant [mailto:[email-masked]]
> Sent: Friday, March 23, 2007 9:43 AM
> To: O'Connor, Don
> Cc: [email-masked]; [email-masked]; [email-masked]; pwe3
> ((((((((E-mail)))))))) WG; Danny McPherson

[ib] I cannot see any reference in Don's comment that violates the view of
T-MPLS data plane being a subset of MPLS data plane. He simply advocates the
need to have also a profile of MPLS WG as well as CCAMP WG works in the relevant
WGs.

> appropriate ammendments need to be made to the ITU specs.

[ib] Good point. So far, T-MPLS data plane is a true subset of MPLS data plane.
However future extensions might be required. It is my understanding, from the LS
statements that ITU-T has sent so far, that ITU-T will require them following
the (G)MPLS Change Process.
It is also my understanding that IETF will define these protocol extensions
based on the (G)MPLS Change Process.
Is my understanding correct?

---

From: "O'Connor, Don" <[email-masked]>
Date: Fri, 23 Mar 2007 10:55:38 -0500

Stewart, Italo

Please see my replies below marked [Don]

Regards

Don

-----Original Message-----
From: Italo Busi [mailto:[email-masked]]
Sent: Friday, March 23, 2007 5:47 AM
To: Stewart Bryant; O'Connor, Don
Cc: [email-masked]; pwe3 ((((((((E-mail)))))))) WG; [email-masked]
Subject: [mpls] RE: [PWE3] Fwd:
I-DACTION:draft-bryant-pwe3-mpls-transport-00.txt

Stewart,

Italo

[Don] I am in agreement with Italo. T-MPLS is a subset of IETF IP/MPLS data plane. But the scope of T-MPLS goes far beyond your current draft. So if IETF wishes to pursue T-MPLS standardization, it will be necessary to generate a number of implementation profile RFCs in PWE3, MPLS, and CCAMP WGs. In addition the current IETF MPLS related RFC / ID do not yet address T-MPLS protection switching and certain OAM requirements. So new work in IETF is needed in this area. For reference for T-MPLS protection switching and OAM requirements please see - G.8131, G.8031 and Y.17tom. Your current draft represents an effort to show that transport mpls can be addressed without any updates to existing RFC / ID without addressing the difficult issues of transport protection switching and OAM. I do not believe that it should be a WG draft until there is a commitment to go beyond existing PWE3 RFC/ID to address these requirements. 

[Don] I do not see and would not support any data plane changes. I disagree with Stewart's comment above

"If extensions are needed it is surely not a TRUE subset, and
> appropriate amendments need to be made to the ITU specs."

IETF is extending MPLS technology all the time. The extensions that I see that are required are: 1) transport OAM enhancements 2) support for transport protection switching 3) GMPLS - ASON control plane enhancements (using the procedures that CCAMP has in place with ITU)

> Please could you be more specific - perhaps contributing text?

[Don] I will offer several examples - Multi-Segment Transport Pseudowires, protection switching as defined in G.8131, Transport MPLS Ring Protection, OAM as defined in Y.17tor / Y.17tom, ID on Transport MPLS LSPs including P2MP, Control Plane LDP per segmented PWs may not be the appropriate solution. I would be happy to contribute text if there is agreement that

1) IETF will standardize G.8131 MPLS linear protection switching and that this protection switching will be coordinated by either and updated version of an appropriate OAM (e.g. VCCV) or signaling protocol (e.g. LDP)

2) IETF will add transport OAM enhancements to MPLS / PWE3 OAM RFC / ID / new ID. This could also be done in your ID. One way to accomplish this for pseudowires is to:

A) Add code points for VCCV / Y.1731

B) Modify VCCV / Y.1731 for non-Ethernet clients (i.e. replace Ethernet SA / DA with AII)

To date there has been some resistance among some PWE3 participants to allow additional VCCV code points (even though VCCV has many options) for Y.1731

Another possibility is to add VCCV code points for ITU Y.17tom. I would also support this option

> Again please be specific.

[Don] My comment above provides ample examples of what is needed. I also envision work in CCAMP on GMPLS for T-MPLS

> the subject of protection mechanisms?

[Don} I believe that your draft should address transport protection switching and OAM. The current draft is an effort to show that Transport MPLS requirements can be without any new functionality added to PWE3 / IETF RFC / ID. I disagree with this premise. If you wish to take on T-MPLS in PWE3 and other IETF WGs, I think more of a commitment is needed to add this functionality. I would be happy to contribute text to your draft if we can reach agreement on some of the basic new functional requirements such as

A) Linear protection switching coordinated (as in G.8131) by either VCCV and / or LDP

B) OAM enhancements - such as BFD for MH-PW per hop, per N hops, EE, AIS / RDI, PM measurement, etc

> a requirement is NEEDED in one domain, I would expect it to

[Don] To date I have seen some reluctance to support VCCV / Y.1731 which meets transport OAM requirements. VCCV / Y.1731 can be run over a MPLS PSN So the issue of an Ethernet PSN is not a problem for VCCV / Y.1731. I would also support VCCV / Y.17tom

---

From: Stewart Bryant <[email-masked]>
Date: Sat, 24 Mar 2007 00:13:13 +0000

Don

A draft does not need to be complete for it to be
accepted as a WG draft, it needs to be a suitable
platform that the WG can use to move forward.

> IETF is extending MPLS technology all the time. The extensions 
that I see that are required are:

1) transport OAM enhancements

Given that the existing PWE3 OAM functions are adequate
for our own purposes, what is special about the transport
environment that requires extensions?

It is not appropriate to list alternative OAM protocols,
PWE3 needs to know what specific additional functionality
it needs to provide a comprehensive OAM design.

2) support for transport protection switching

PWE3 has already started work on protection. What
requirements exist in the transport network that are not
addressed by the proposed work?

Would you be prepared to contribute text to a PWE3 protection
requirements draft?

3) GMPLS - ASON control plane enhancements (using the procedures
that CCAMP has in place with ITU)

The control plane design for PWE3 over MPLS and for MPLS is
a proven design that is widely deployed. How is the existing
designs unsuitable, and what additional requirements does a
transport environment have that are not satisfied by that
design.

- Stewart

---

From: "dimitri papadimitriou" <[email-masked]>
Date: Sun, 25 Mar 2007 12:28:22 +0200

stewart

reading this lengthy thread, there is indeed a lack of description of
(potentially) missing requirements/features from draft-bryant & others;

hence, it would be helpful to have such piece of text (using language
that is understandable by the IETF community) and apply the mpls-gmpls
change process to it - this because it is not obvious, at this point
in time, that the potential changes would be acceptable for the IETF
itself

ps: you are correct when stating that a draft does not need to be ready
for RFC editorship to become a working group doc.

thanks,
- d.

-- 
-dimitri.

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 26 Mar 2007 16:55:09 +0100

Dimitri

Remember that the point of the draft was to note that the requirements
specified by ITU at the time when the draft was written could be met
without any additional work.

- Stewart

dimitri papadimitriou wrote:
> On Sat, 24 Mar 2007 01:13:13 +0100, Stewart Bryant 
> <[email-masked]> wrote:
>
>> Don
>>
> ---dimitri.

---

From: "Italo Busi" <[email-masked]>
Date: Mon, 26 Mar 2007 18:38:02 +0200

Stewart,

I agree that a draft should not be ready for RFC editorship to become a WG
draft.

However, based on this mail discussion, I do not think the draft is going in the
direction to meet the requirements so I do not support it to become a WG draft.

Moreover, I am now lost about the intent of the draft.

If the intent of the draft is to show to ITU-T how you believe that T-MPLS could
have been designed to meet the ITU-T requirements, it is good not to make it a
WG draft and liaise it to ITU-T, as agreed at the IETF 67.

Otherwise if the intent is to start an activity inside IETF to define T-MPLS, I
think that the draft is too much immature to become WG draft. We need to clearly
define the scope and objective of this work inside IETF and its relationship
with the ITU-T and therefore, based on that, identify which are the required
changes to this draft to become a WG document.

Thanks, Italo

> Sent: Monday, March 26, 2007 5:55 PM
> To: dimitri papadimitriou
> Cc: [email-masked]; pwe3
> Subject: Re: [mpls] RE: [PWE3]Fwd:

---

From: "O'Connor, Don" <[email-masked]>
Date: Fri, 30 Mar 2007 17:28:01 -0500

Stewart

The current draft-bryant does not add any new functionality to existing PWE3 RFC / ID for transport requirements. It should not become a wg draft until there is evidence that there is a commitment to support some new functionality to address transport specific requirements in Appendix A of draft-bryant. More specifically these are the OAM and Survivability requirements 21 - 27 in Appendix A. As a minimum there should be some sections and initial text for

1) Bidirectional 1:1 linear protection switching for pseudowires and associated PSN tunnel

- This protection switching is coordinated by enhancements to the applicable layer OAM protocol - i.e. VCCV and LSP Ping

For more detailed requirements and reference please see ITU recommendation G.8131

2) Pseudowire and PSN Tunnel Transport OAM Extensions

- My suggested minimum subset extensions would be - ME Levels, MEP / MIP, PM measurement, AIS / RDI , Tandem Connection Monitoring (i.e. - for a multi-hop PW and / or PSN tunnel the ability to enable a continuous continuity check for one / N / all hops), and Synchronous Status Message

Please also see my replies in line to your email below

Regards

Don

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]]
Sent: Friday, March 23, 2007 7:13 PM
To: O'Connor, Don
Cc: [email-masked]; pwe3
Subject: Re: [mpls] RE: [PWE3] Fwd:

Don

[Don] ME Levels, MEP / MIP, PM measurement, AIS / RDI, Tandem Connection Monitoring, and Synchronous Status Message

[Don] Linear bidirectional 1:1 protection switching for both pseudowire and PSN tunnel. This protection switching should be coordinated by updates to VCCV and LSP Ping. The abstract to draft-bryant implies that it specifies a complete transport network solution. So transport orientated protection switching should be included in draft-bryant. I could contribute text

[Don] draft-ietf-pwe3-ms-pw-requirements-05.txt already addresses a number of the relevant requirements. If we agree to have a transport protection switching section in draft-bryant, I can suggest some additional transport orientated requirements for ms-pw-requirements. Note that was also need to address PSN tunnel layer linear 1:1. RFC 3469 provides a superset of the transport PSN tunnel protection switching requirements.

With respect to existing protection work in PWE3 as evidenced by draft-muley-pwe3-redundancy-01.txt and draft-muley-dutta-pwe3-redundancy-bit-00.txt, some of addressed applications may be applicable for mpls transport (e.g. multi-homing) but I do not believe that the redundancy bit is applicable. Transport mpls linear protection switching is coordinated by the OAM protocol. For reference please see G.8131.  

[Don] QOS / Traffic Engineering for multi-segment PW. My opinion is that for transport mpls draft-raggarwa-rsvpte-pw-03.txt, provides a better solution than LDP based segmented pseudowires.

- Stewart