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

From: Danny McPherson <[email-masked]>
Date: Thu, 22 Mar 2007 03:31:25 -0600

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

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 22 Mar 2007 03:36:45 -0700

Danny,

> to adopting this please speak up now.

In favor.

Yakov.

---

From: Danny Prairie <[email-masked]>
Date: Thu, 22 Mar 2007 09:44:11 -0400

I'm in favour.

Regards,

Danny

---

From: "Italo Busi" <[email-masked]>
Date: Thu, 22 Mar 2007 14:57:25 +0100

I oppose.

Quoting a mail from Stewart on Jan 25, 2007:
"
At IETF67 we agreed to liaise draft-bryant-pwe3-mpls-transport-00 to ITU SG15
"

I do not understand why we are progressing this draft to become a WG draft
without sending such a liaison.

Italo

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

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 22 Mar 2007 10:18:26 -0400

Why should that preclude this becoming
a WG draft for that reason? The IETF's PWE3 Working Group
is not barred from accepting drafts based on what another
SDO might reply to in a liason statement, as far
as I know. Perhaps Townsley can clarify?

	--Tom

---

From: "Italo Busi" <[email-masked]>
Date: Thu, 22 Mar 2007 16:12:30 +0100

Tom,

I do not think IETF PWE3 WG is barred on the LS reply.

However, the WG agreed at the IETF 67 to send the LS.

There was no further discussion about this topic since then (including the PWE3
WG meeting this week) other than on the text of the LS statement.

I do not understand why now we wish to change the agreement reached at the last
IETF meeting.

Thanks, Italo

> From: Thomas D. Nadeau [mailto:[email-masked]]
> Sent: Thursday, March 22, 2007 3:18 PM
> To: Italo Busi
> Cc: Townsley Mark; pwe3((((((((((((((((E-mail))))))))))))))))WG; Danny
> McPherson
> Subject: Re: [PWE3] Fwd: I-D
> ACTION:draft-bryant-pwe3-mpls-transport-00.txt
>
>
>
> >> Subject: [PWE3] Fwd: I-D ACTION:dr

---

From: "Italo Busi" <[email-masked]>
Date: Thu, 22 Mar 2007 16:12:30 +0100

Tom,

Thanks, Italo

 From [email-masked] Thu Mar 22 11:13:28 2007
Return-pataft-bryant-pwe3-mpls-

---

From: Mark Townsley <[email-masked]>
Date: Thu, 22 Mar 2007 16:09:12 +0100

> as I know. Perhaps Townsley can clarify?
Technically, of course not. But if the WG agreed to do something with 
this document and there has been no follow-through, it would seem a bit 
incredulous to move forward before doing so.

- Mark
>> I do not understand why we are progressing this draft to become a WG 
>> drafh: <[email-masked]>
Date: Thu, 22 Mar 2007 16:09:12 +0100
From: Mark Townsley <[email-masked]>
To: "Thomas D. Nadeau" <[email-masked]>
Subject: Re: [PWE3] Fwd: I-D ACTION:draft-bryant-pwe3-mpls-transport-00.txt
Cc: Italo Busi <[email-masked]>, pwe3 WG <[email-masked]>,
	Danny McPherson <[email-masked]>

> as I know. Perhaps Townsley can clarify?
Technically, of course not. But if the WG agreed to do something with 
this document and there has been no follow-through, it would seem a bit 
incredulous to move forward before doing so.

- Mark

t

---

From: Mark Townsley <[email-masked]>
Date: Thu, 22 Mar 2007 16:16:34 +0100

Adrian Farrel wrote:
> To the contrary, in fact.
> I would think that a working group would be unlikely to liaise 
> (although not precluded from liaising work in progress until it has 
> become a WG draft.
>
> Of course, I would also hope that we can liaise this as soon as possible.
A very good point, Adrian, I answered too quickly. Procedurally, a WG 
document would be far better for a liaison if the WG already believes 
this is work for the working group to pursue. Technically, the IETF 
doesn't even have change control on this document, as I understand it 
the copyrights are still held by the individual authors on the draft.

If the decision to liaise was made with the *expectation* that feedback 
was being requested as a decision point towards whether or not the WG 
should take on this work, then that should be done first.

To be clear, unless the WG decides to link itself with another SDO on 
its own (e.g., the TRILL WG mandating a review of its architecture by 
the IEEE in its charter), it operates independently.

- Mark

>
> Adrian
> ----- Original Message ----- From: "Thomas D. Nadeau" <[email-masked]>
> To: "Italo Busi" <[email-masked]>
> Cc: "Townsley Mark" <[email-masked]>; "pwe3 
> ((((((((((((((((E-mail)))))))))))))))) WG" <[email-masked]>; "Danny 
> McPherson" <[email-masked]>
> Sent: Thursday, March 22, 2007 2:18 PM

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 22 Mar 2007 11:24:15 -0400

> However, the WG agreed at the IETF 67 to send the LS.

	Yes, I recall that. We however, did not agree
to wait to move forward on any WG status documents based
on sending that LS. 8)

> There was no further discussion about this topic since then  
> (including the PWE3 WG meeting this week) other than on the text of  
> the LS statement.
>
> I do not understand why now we wish to change the agreement reached  
> at the last IETF meeting.

	I do not think we are changing the understanding from
last time, as I said above. It is a good idea to send a LS,
and I do not think anyone on the list is advocating against this.
However, I also think that in parallel the WG needs to adopt
this document as a starting point of discussion on this topic
from the IETFs perspective, as well as a reference point
for the LS.

	--Tom

---

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,

-danny

---

From: Luca Martini <[email-masked]>
Date: Thu, 22 Mar 2007 09:37:52 -0600

Mark Townsley wrote:
> this document and there has been no follow-through, it would seem a 
> bit incredulous to move forward before doing so.
>
OK, but does this document need to be a WG document to send the liaison 
statement properly ?
After all all we can say now is " Stewart Bryant has been working on 
this topic" .
But as a WG item this would be the view of the WG.
So it might be better to get agreement about this document WG status 
before we send the liaison statement.

My 2c.

Luca
P.S. I think this document should become a WG document.

>>> draft
>>>> Subject: [PWE3] Fwd: I-D 
>>>>> You can also visit 
>>>>> https://www1.ietf.org/mailman/listinfo/I-D-announce

---

From: Mark Townsley <[email-masked]>
Date: Thu, 22 Mar 2007 17:53:20 +0100

Luca Martini wrote:
> OK, but does this document need to be a WG document to send the 
> liaison statement properly ?
The discussion probably should have gone like that in the first place.

- Mark

---

From: "O'Connor, Don" <[email-masked]>
Date: Thu, 22 Mar 2007 12:14:00 -0500

Mark

The issue goes beyond the PWE3 WG. What is the PSN Tunnel for a PWE3 Transport PW ? Is the PSN tunnel a ITU G.8110.1 T-MPLS path ? A PWE3 Transport PW is of not value without a specification for the Transport MPLS tunnel that carries this pseudowire. 

So first before there is any discussion of WG status - it is first necessary to determine if the MPLS WG plans to take up the work of specifying the Transport MPLS tunnel for the Transport Pseudowire

It is not necessary to have very incomplete WG draft in order to send a liaison. The correct first step is for a joint liaison from PWE3, MPLS, and probably also CCAMP that indicates a willingness to develop a full implementation profile for ITU Transport MPLS requirements and desire to work together.

Regards

Don

-----Original Message-----
From: Mark Townsley [mailto:[email-masked]]
Sent: Thursday, March 22, 2007 11:53 AM
To: Luca Martini
Cc: Thomas D. Nadeau; Danny McPherson; pwe3 WG; Italo Busi
Subject: Re: [PWE3] Fwd: I-D

- Mark

---

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: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 22 Mar 2007 14:13:30 -0400

> Mark
>
> The issue goes beyond the PWE3 WG. What is the PSN Tunnel for a  
> PWE3 Transport PW ? Is the PSN tunnel a ITU G.8110.1 T-MPLS path ?  
> A PWE3 Transport PW is of not value without a specification for the  
> Transport MPLS tunnel that carries this pseudowire.

> So first before there is any discussion of WG status - it is first  
> necessary to determine if the MPLS WG plans to take up the work of  
> specifying the Transport MPLS tunnel for the Transport Pseudowire

	Don,

	There is no need to agree on what the IETF views as
an appropriate "transport tunnel". What we specified in the draft
meets the requirements of g.8110 in that we specified an RSVP-TE
tunnel that has ECMP and PHP disabled.  This has already been
defined (and deployed) as per a number of IETF RFCs, thus implying
IETF "consensus" on the tunnel. There is no magic here, nor a need
to create something new in this regard.  All this will do is as I
said before, create additional procedural overhead to slow the progress
of this work down. I am however, in favor of sending liaison statements
to the ITU informing them of our status on this work, while progressing
in parallel here.

	--Tom

> It is not necessary to have very incomplete WG draft in order to  
> send a liaison. The correct first step is for a joint liaison from  
> PWE3, MPLS, and probably also CCAMP that indicates a willingness to  
> develop a full implementation profile for ITU Transport MPLS  
> requirements and desire to work together.
>
> Regards
>
> Don
>
>
>

---

From: "Italo Busi" <[email-masked]>
Date: Thu, 22 Mar 2007 20:02:38 +0100

Tom,

I do not understand how you can claim that "What we specified in the draft meets
the requirements of g.8110 in that we specified an RSVP-TE tunnel that has ECMP
and PHP disabled." without waiting for the LS reply (BTW I guess you meant
G.8110.1).

Don has raised good points where the draft is not meeting the requirements. I
think he is right.

Italo

> Sent: Thursday, March 22, 2007 7:14 PM
> To: O'Connor, Don
> Cc: Mark Townsley; Luca Martini; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; Danny McPherson; pwe3 WG; Italo Busi

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 22 Mar 2007 15:00:30 -0000

To the contrary, in fact.
I would think that a working group would be unlikely to liaise (although not 
precluded from liaising work in progress until it has become a WG draft.

Adrian
----- Original Message ----- 
From: "Thomas D. Nadeau" <[email-masked]>
To: "Italo Busi" <[email-masked]>
Cc: "Townsley Mark" <[email-masked]>; "pwe3 

>>> Subject: [PWE3] Fwd: I-D ACTION:draft-bryant-pwe3-mpls- transport-00.txt
>>>
>>>
>>>
>>> Folks,
>>>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D- announce

---

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: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 22 Mar 2007 16:40:03 -0400

> (although not precluded from liaising work in progress until it has  

	That was the point I was trying to make too. Maybe
I should have used English instead of American English? *)
Anyway, I think the liaison process is orthogonal to whether or
not PWE3 accepts the document and moves it forward.

> Of course, I would also hope that we can liaise this as soon as  

	Agreed.

	--Tom

> Cc: "Townsley Mark" <[email-masked]>; "pwe3 ((((((((((((((((E- 
> mail)))))))))))))))) WG" <[email-masked]>; "Danny McPherson"  
> <[email-masked]>

---

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 07:26:43 +0000

> as I know. Perhaps Townsley can clarify?

Indeed, the ITU would (could) not liaise a contribution
to IETF, they would ONLY liaise back what we would call
a WG draft. Indeed I don't think that the IETF has
any right to liaise an individual submission to another
SDO. This resulted in something of a contradiction
in the position that we got to at at the last IETF.

We do not need permisison from the ITU to adopt the
draft and it is up to the IETF when we descide that it
is ready for external input.

- Stewart

---

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: Stewart Bryant <[email-masked]>
Date: Fri, 23 Mar 2007 08:44:34 +0000

Mark
> The discussion probably should have gone like that in the first place.

Hindsight etc.

Stewart

---

From: Enrique Hernandez-Valencia <[email-masked]>
Date: Fri, 23 Mar 2007 05:02:01 -0400

Danny,

No. Premature, if desired goal is to work with ITU-T and address
longer term needs.

Rgds,
Enrique

---

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 09:50:27 -0500

Stewart

The current draft should / should not become a WG draft based on its contents (or lack there of) not on any liaison considerations. I do not think it should be a WG document until there is more of a commitment to address the difficult issues - "transport" protection switching and OAM. The current draft represents an effort to show that transport mpls can be addressed without any updates to existing RFC / ID. This is not possible. It should not be a WG document until it starts to address transport protection switching and OAM (for reference please see G.8131, G.8031, and Y.1731, IEEE 802.1ag, and Y.17tom)

Regards

Don

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]]
Sent: Friday, March 23, 2007 2:27 AM
To: Thomas D. Nadeau
Cc: Italo Busi; Danny McPherson;
pwe3((((((((((((((((E-mail))))))))))))))))WG; Townsley Mark
Subject: Re: [PWE3] Fwd: I-D
ACTION:draft-bryant-pwe3-mpls-transport-00.txt

- Stewart

---

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

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

---

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: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Mon, 26 Mar 2007 10:24:01 -0500

Agree- this should become a WG draft and we should liaison.

The document is ready to be a WG draft as it provides a good basis for
addressing the requirements (listed in the appendix). Liaising as a WG
draft indicates our willingness to work on the topic and cooperate to
progress.

Deborah 

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Thursday, March 22, 2007 11:01 AM
To: Thomas D. Nadeau; Italo Busi
Cc: Townsley Mark; pwe3((((((((((((((((E-mail))))))))))))))))WG; Danny
McPherson

To the contrary, in fact.
I would think that a working group would be unlikely to liaise (although
not 
precluded from liaising work in progress until it has become a WG draft.

Of course, I would also hope that we can liaise this as soon as
possible.

Adrian
----- Original Message ----- 
From: "Thomas D. Nadeau" <[email-masked]>
To: "Italo Busi" <[email-masked]>
Cc: "Townsley Mark" <[email-masked]>; "pwe3 

>> At IETF67 we agreed to liaise draft-bryant-pwe3-mpls-transport-00  to
ITU 
>> SG15

---

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: "Giles Heron" <[email-masked]>
Date: Mon, 26 Mar 2007 21:54:34 +0100

I'm in favour of adopting this.  It's a good starting point to work from...

Giles

---

From: Monique Morrow <[email-masked]>
Date: Mon, 26 Mar 2007 15:13:02 -0400

Italo,

The base draft was to capture requirements as defined by the ITU and how
these requirements can be achieved using existing IETF mechanisms.

I am attaching a reminder of what was presented at IETF 67.

Rather the contrary to assert that the draft is immature to be a WG -- seems
quite reasonable  <if not long time overdue> .

Regards, Monique

---

From: "Busschbach, Peter B \(Peter\)" <[email-masked]>
Date: Tue, 27 Mar 2007 13:55:14 -0500

I don't think this draft should become a working group document.

A large part of the draft is devoted to specifying characteristics of
the PSN. This is not within the scope of PWE3. The rest of the draft
poses arbitrary restrictions with regards to pseudo wires: no sequence
numbering, statically provisioned PWs, etc. In my opinion the IETF
should not get involved in defining such profiles. (The IETF defines
protocols, not profiles.)

Peter

> Sent: Thursday, March 22, 2007 5:31 AM
> > logging in, type "cd internet-drafts" and then "get 
> > draft-bryant-pwe3-mpls-transport-00.txt".
> >
> > http://www.ietf.org/shadow.html or 
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >

---

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Wed, 28 Mar 2007 10:47:33 -0400

Peter, 

[clipped...]

> 
> A large part of the draft is devoted to specifying 
> characteristics of the PSN. This is not within the scope of 
> PWE3. 

You may have a point here. PWE3 does not specify PSN
particularly if this PSN creates a non IP-based MPLS 
version.

As indicated in my previous email, I think that part of 
the draft needs to be specified in mpls wg maybe as 
as an internet-draft describing 
"Application of MPLS in Non-IP Network Environment"

Hamid.

---

From: "David Allan" <[email-masked]>
Date: Wed, 28 Mar 2007 17:10:56 -0400

Danny:

I'd like a better idea of where this draft is going to go....

Right now it primarily describes the art of the possible with other
RFCs... Does that make it a BCP? And if so, is this what the group
really considers "B" (further is there experience with the suggested
profile to make the claim)? 

If it is purely for the purpose of liaising it, I'd be against that as
IMO that is insufficient reason, it's not really a work item...and if
there actually is real work to do to progress the draft, what is it?  

Cheers
Dave

---

From: "JOUNAY Frederic RD-RESA-LAN" <[email-masked]>
Date: Thu, 29 Mar 2007 10:31:07 +0200

In favor to adpat this as a WG doc. 

Frederic

---

From: "NIGER Philippe RD-RESA-LAN" <[email-masked]>
Date: Thu, 29 Mar 2007 16:36:51 +0200

Agree also with this.

Philippe.

-----Message d'origine-----
De : BRUNGARD, DEBORAH A, ATTLABS [mailto:[email-masked]] 
Envoyé : lundi 26 mars 2007 17:24
À : [email-masked]
Cc : Danny McPherson
Objet : RE: [PWE3] Fwd: I-D ACTION:draft-bryant-pwe3-mpls-transport-00.txt 

The document is ready to be a WG draft as it provides a good basis for addressing the requirements (listed in the appendix). Liaising as a WG draft indicates our willingness to work on the topic and cooperate to progress.

Deborah 

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]]
Sent: Thursday, March 22, 2007 11:01 AM
To: Thomas D. Nadeau; Italo Busi
Cc: Townsley Mark; pwe3((((((((((((((((E-mail))))))))))))))))WG; Danny McPherson
Subject: Re: [PWE3] Fwd: I-D

To the contrary, in fact.
I would think that a working group would be unlikely to liaise (although not precluded from liaising work in progress until it has become a WG draft.

Adrian
----- Original Message -----
From: "Thomas D. Nadeau" <[email-masked]>
To: "Italo Busi" <[email-masked]>
Cc: "Townsley Mark" <[email-masked]>; "pwe3
((((((((((((((((E-mail)))))))))))))))) WG" <[email-masked]>; "Danny McPherson" <[email-masked]>
Sent: Thursday, March 22, 2007 2:18 PM
Subject: Re: [PWE3] Fwd: I-D
ACTION:draft-bryant-pwe3-mpls-transport-00.txt

>
> Why should that preclude this becoming a WG draft for that reason? The 
> IETF's PWE3 Working Group is not barred from accepting drafts based on 
> what another SDO might reply to in a liason statement, as far as I 
> know. Perhaps Townsley can clarify?
>
> --Tom
>
>
>> I oppose.
>>
ITU 

>>>> command.  To decode the response(s), you will need "munpack" or a 
>>>> MIME-compliant mail reader.  Different MIME-compliant mail
readers
>>>> "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.
>>>>

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 29 Mar 2007 17:09:39 +0100

Dave

As you point out the draft does not define any new protocols, instead it 
defines how to use the IETF protocol suite to address a set of 
requirements that have been posed.

It could be a BCP or it could be informational. I think that we need to 
adopt the draft, liaise it to SG15 and see what the response is. Then we 
can decide where we want to take it.

To this end the B would be there to say "if you start with the following 
requirements (PW over MPLS in a transport environment) then this what 
the IETF considers is the best approach".

Setting the detail aside, for the moment, the problem that we are faced 
with is another SDO writing normative text to describe a protocol suite 
that looks like PWE3/MPLS,  that uses the same codepoints as PWE3/MPLS 
(i.e. is indistinguishable to a receiving node), but which on several 
occasions has included important semantic differences, thereby creating 
a schism in the definition of PWE3/MPLS. The purpose of this draft is to 
attempt to prevent that schism by demonstrating that the existing 
specifications provide a way to address the requirements posed.

- Stewart

---

From: "Italo Busi" <[email-masked]>
Date: Thu, 29 Mar 2007 18:28:59 +0200

Stewart,

could you please specify which is the "schism" you see?

I thought we made a careful review of the documents to ensure that they are
aligned with existing IETF RFCs. Have I missed something?

Thanks, Italo

> Sent: Thursday, March 29, 2007 6:10 PM
> To: David Allan
> Cc: pwe3 ((((((((E-mail)))))))) WG; Danny McPherson

---

From: "David Allan" <[email-masked]>
Date: Thu, 29 Mar 2007 13:01:56 -0400

Hi Stweart:

Fully appreciate the problem. IMO a better solution would simply be to
liase the text with a bit of editing rather than adopting the draft as a
WG item....convert the draft INTO the liaison....

We think these are the requirements you are seeking to address. This is
how we'd do it....

Doesn't have to be a WG item to do that...

Rgds
Dave

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: Thursday, March 29, 2007 12:10 PM
To: Allan, David (CAR:NS00)
Cc: Danny McPherson; pwe3 ((((((((E-mail)))))))) WG
Subject: Re: [PWE3] Fwd: I-D

Dave

- Stewart

---

From: <[email-masked]>
Date: Thu, 29 Mar 2007 18:22:54 +0100

Hi Dave/Stewart,

We've discussed this issue quite a bit internally, and in our (operator)
view the primary requirement to address is 'how to achieve a proper
client/server relationship (ie true client transparency) when the MPLS
network of party A requires carriage over the MPLS network of party B?'.

Stewart's draft shows one way to achieve this....I can think of others.
However, the key point is that this draft shows one way we can get this
client/server relationship using existing IETF standards.  

regards, Neil
> From: David Allan [mailto:[email-masked]] 
> Sent: 29 March 2007 18:02
> To: [email-masked]
> Subject: RE: [PWE3] Fwd: I-D 
> Fully appreciate the problem. IMO a better solution would 
> simply be to liase the text with a bit of editing rather than 
> adopting the draft as a WG item....convert the draft INTO the 
> liaison....
> 
> We think these are the requirements you are seeking to 
> address. This is how we'd do it....
> 
> As you point out the draft does not define any new protocols, 
> instead it defines how to use the IETF protocol suite to 
> address a set of requirements that have been posed.
> 
> It could be a BCP or it could be informational. I think that 
> we need to adopt the draft, liaise it to SG15 and see what 
> the response is. Then we can decide where we want to take it.
> 
> To this end the B would be there to say "if you start with 
> the following requirements (PW over MPLS in a transport 
> environment) then this what the IETF considers is the best approach".
> 
> Setting the detail aside, for the moment, the problem that we 
> are faced with is another SDO writing normative text to 
> describe a protocol suite that looks like PWE3/MPLS,  that 
> uses the same codepoints as PWE3/MPLS (i.e. is 
> indistinguishable to a receiving node), but which on several 
> occasions has included important semantic differences, 
> thereby creating a schism in the definition of PWE3/MPLS. The 
> purpose of this draft is to attempt to prevent that schism by 
> demonstrating that the existing specifications provide a way 
> to address the requirements posed.
> 
> - Stewart
> 
> 
> 
> 
> David Allan wrote:
> > Danny:
> >

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 29 Mar 2007 18:59:53 +0100

Italo

As you know it took IETF effort to find the conflicts in the first 
version - and most distressingly took hours and hours to *negotiate* the 
required corrections. It continues to take hours and hours of IETF WG 
chair, IAB and IESG time as you move the TMPLS work forward.

Unless SG15 move TMPLS off the IETF codepoints, or makes it crystal 
clear that the IETF texts  are the sole normative texts and its own text 
is informative and subject to change in the event of a conflict with the 
IETF definition, IETF will continue to spend hours reviewing and 
negotiating. If IETF misses an important difference, or fails to point 
out a conflict with our intended future direction, we create the schism 
that I am concerned about.

- Stewart

---

From: "O'Connor, Don" <[email-masked]>
Date: Fri, 30 Mar 2007 12:08:27 -0500

Neil, Stewart, Dave

In order to accomplish

"when the MPLS
network of party A requires carriage over the MPLS network of party B?'."

This should be accomplished (in IETF PWE3) by the Generic Pseudowires concept that has been discussed in the recent past.

Stewart - where does the PWE3 WG stand on Generic Pseudowires?

Regards

Don

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, March 29, 2007 12:23 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [PWE3] Fwd: I-D

Hi Dave/Stewart,

regards, Neil

---

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