Subject: RE: [PWE3] WG LC: draft-ietf-pwe3-mpls-transport-00.txt

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 1 Aug 2007 13:51:29 +0300

Danny and Stewart, 
 
While definitely in favor of this ideas behind this draft,
I have a hard time with a lot of the wording.
 
First, the Abstract and Introduction describe the problem
to be solved as transport (AKA as "carriage") of MPLS
over MPLS. Specifically, the Introduction explains that direct
transport of one carrier´s MPLS traffic over another carrier´s MPLS
network can not be done by simple label stacking, and so a PW
is required.
 
But then there is a sharp turn and the rest of the draft is about
transport of Ethernet over MPLS, not MPLS over MPLS.
Some explanation is required here (other than the fact that 
the PWE charter disallows MPLS PWs over MPLS),
or the Introduction should be reworded.
 
Second, the text mentions in second places that the draft
defines a "profile". It is not clear a profile of what.
At first I though it was a profile of RFC4448, and section 5 says this as well. 
But then I found the sentence 
  The only PWE3 encapsulation that is supported in this version of the
   profile is Ethernet RFC4448 [RFC4448].
So, if RFC4448 is used in the profile, it must be a profile of something else.
So is it a profile of MPLS? Or maybe a profile of RFC3985 ?

In any case, although profiles are used in many standards bodies, 

we have never discussed profiles before. Is this term really needed?

If so, please explain it.

Third, a number of constraints are put on this PW. For example,

PHP must not be used in the underlying network, 

the PWE control protocol MUST NOT be used, VCCV modes, configuration,

and the fact that the CW MUST be used. 

Although these are in response to the referenced ITU requests, 

these liaisons are ephemeral. I think specific explanations of why these constraints 

are being enforced is absolutely required, in addition to being useful to the reader.

Fourth, and perhaps most significant, 

in several places we seem to overstepping PWE charter restrictions

by exerting control over the underlying PSN and specifying placement of the PSN tunnel. 

For example, PHP MUST NOT be used, RSVP-TE MUST be used, 

no label merging, no ECMP, etc.  Perhaps this needs to be a joint PWE and MPLS WG draft?

Y(J)S

________________________________

De: Danny McPherson [mailto:[email-masked]]
Enviado el: mié 25/07/2007 22:13
Para: [email-masked]
Asunto: [PWE3] WG LC: draft-ietf-pwe3-mpls-transport-00.txt

Folks,
Please consider today the beginning of a two week WG LC
for this draft.  WG LC will end on 2007-08-08.  Please provide
comments to [email-masked] ASAP.

Thanks!

-danny

Begin forwarded message:

> From: [email-masked]
> Date: May 23, 2007 1:50:02 PM MDT
> To: [email-masked]
> Cc: [email-masked]
> Subject: I-D ACTION:draft-ietf-pwe3-mpls-transport-00.txt
> Reply-To: [email-masked]
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Pseudowire Emulation Edge to Edge 
> Working Group of the IETF.
>
>       Title           : Application of PWE3 to MPLS Transport Networks
>       Author(s)       : S. Bryant, et al.
>       Filename        : draft-ietf-pwe3-mpls-transport-00.txt
>       Pages           : 11
>       Date            : 2007-5-23
>      
>    A key requirement has been identified by the operator community for
>    the transparent carriage of the MPLS network of one party over the
>    MPLS network of another party.  This document describes one IETF-
>    recommended profile to satisfy this requirement using the existing
>    RFC4448 PWE3 Ethernet pseudowire standard.  This solution does not
>    preclude other solutions being developed in the future.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-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-ietf-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-ietf-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

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

---

From: <[email-masked]>
Date: Wed, 1 Aug 2007 12:41:22 +0100

Hi Yaakov,  let me see if can help here...please see in-line.

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]] 
Sent: 01 August 2007 11:51
To: Danny McPherson; [email-masked]; Stewart Bryant (E-mail)
Subject: RE: [PWE3] WG LC: draft-ietf-pwe3-mpls-transport-00.txt

Danny and Stewart, 

NH=> No doubt you understand the key issue here, ie stacked LSPs per se are NOT functionally decoupled and thus do not provide a client/server layer network relationship directly.  The practical driver for this is (at least) twofold: 
 
1    Operators do not wish to be forced into 'peering' their MPLS networks for a whole raft of technical, commercial and regulatory reasons.  Moreover, networks operating as peers assume a well defined *public* service....no such public MPLS service exists. 
 
Aside=> This mistake is also being made in other ITU Recs.  For example, this peering relationship is assumed in y.1732/3 (T-MPLS OAM).....but its even worse here as its assumes operators will happily also sublayer a network and allow multi-party ownership of those sublayers (this is the TCM stuff).  Moreover, these draft Recs also assumes operators will want to try and peer interwork T-MPLS and Ethernet!  This is absolutely no-go......trying to peer interwork 2 technologies that belong to the *same* network mode is bad enough unless they are almost identical in ALL CP and DP functional components (including the key 'application to 1st layer network' adaptation functions), but when they belong to different network modes this is just a plain daft idea.
 
2    As operators sunset older technologies that used to provide a client/server transport service (eg FR, ATM, PDH, SDH) and largely have MPLS only networks, then the client/server issue needs to be addressed in MPLS.
 
NH=> Well, we have to introduce some form of 'functional breakwater' between the 2 MPLS networks that are owned/operated by different parties.  We can't do this directly with stacked LSPs as noted above...as least as currently defined (but see paragraph below)....so we have to insert a different technology (this is a degenerate layer network of 1-hop).  Note - the handling of the S bit is important here.  So why not use Ethernet? 
 
Having said that, if we had a reserved label (from the 0-15 set) that had the special/global functional meaning "This label implies the termination of the server (outer) MPLS stack/network belonging to party A and the carriage of a client (inner) MPLS MPLS stack/network belonging to party B", then we could do a proper MPLSoverMPLS client/server relationship far more elegantly and efficiently IMO (ie MPLSoverMPLS instead of MPLSoverEthernetoverPWoverMPLS).  However, such a scheme is not yet defined.  This draft merely shows it is possible to provide a client/server relationship using existing IETF rfcs/IDs.
 
Does that help Yaakov?
 
regards, Neil

Y(J)S

  _____  

Folks,

Thanks!

-danny

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 01 Aug 2007 08:52:27 -0700

Danny,

> comments to [email-masked] ASAP.

Support.

Yakov.

---

From: <[email-masked]>
Date: Wed, 1 Aug 2007 17:27:46 +0100

Danny, I support this...though I do have to declare an interest as
co-author.

regards Neil

> From: Danny McPherson [mailto:[email-masked]] 
> Sent: 25 July 2007 20:14
> To: [email-masked]
> Subject: [PWE3] WG LC: draft-ietf-pwe3-mpls-transport-00.txt
> 
> 
> Folks,
> for this draft.  WG LC will end on 2007-08-08.  Please 
> provide comments to [email-masked] ASAP.
> 
> Thanks!
> 
> -danny
> 
> Begin forwarded message:
> 
> 
> > directories. This draft is a work item of the Pseudowire Emulation 
> > Edge to Edge
> > the message. You can also visit 
> > https://www1.ietf.org/mailman/listinfo/I-D-announce
> > logging in, type "cd internet-drafts" and then "get 
> > draft-ietf-pwe3-mpls-transport-00.txt".
> >
> > http://www.ietf.org/shadow.html or 
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >

---

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 2 Aug 2007 09:48:48 +0300

Neil
 
I completely understand the issue, I was just commenting on the WORDING.
 
The draft needs cleaning up on several issues, as I detailed.
 
That being said, I am completely in support of direct layering of MPLS
over MPLS. As you may recall, Shahram and I proposed this to the MPLS
WG a long time ago, asking simply for setting the stack bit and then having
another label stack. This was soundly rejected.
 
That being said, I am perfectly happy with putting in a CW
or a special label to separate the label stacks.
 
Y(J)S

De: [email-masked] [mailto:[email-masked]]
Enviado el: mié 01/08/2007 14:41
Para: Yaakov Stein; [email-masked]; [email-masked]; [email-masked]
Asunto: RE: [PWE3] WG LC: draft-ietf-pwe3-mpls-transport-00.txt

	-----Original Message-----
	From: Yaakov Stein [mailto:[email-masked]] 
	Sent: 01 August 2007 11:51
	To: Danny McPherson; [email-masked]; Stewart Bryant (E-mail)
	Subject: RE: [PWE3] WG LC: draft-ietf-pwe3-mpls-transport-00.txt

	Danny and Stewart, 

	 

	 

	Does that help Yaakov?
	 
	regards, Neil

	Y(J)S

	Folks,
	
	Thanks!
	
	-danny

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 02 Aug 2007 09:15:59 +0100

> The draft needs cleaning up on several issues, as I detailed.
I will take a look at how best to fold these in.
> another label stack. This was soundly rejected
>  
Speaking personally I prefer the CW, then we can inject VCCV.
Otherwise I do not see how we layer the OAMs correctly.

Stewart

---

From: Phil Bedard <[email-masked]>
Date: Thu, 2 Aug 2007 16:26:58 -0400

I'm confused somewhat by the title of the draft, does it mean  
"Application of PWE to transparent transport of a client MPLS  
network" or does it mean "Application of PWE3 to build a transport- 
like MPLS network."    The abstract would lead me to believe the  
former but then most of the draft speaks of an EoMPLS PW with  
"transport-like" restrictions used to carry that MPLS network.    I'd  
like to see more explanation of what constitutes a "Transport LSP/PW"  
and why there are certain constraints/requirements for that LSP as  
opposed to a regular PW/LSP.  The document starts using the concept  
of a "transport LSP" without fully defining what it is.   Most of the  
requirements are under the control plane section but I think it  
deserves better explanation.

It may be clearer to have another draft that defines an "Ethernet  
transport PW/LSP" (that may borrow much of its content from the SG15  
T-MPLS requirements and this document) and a draft that explains how  
that transport LSP can be used to transport a client MPLS network, or  
any other type of network that can be encapsulated into Ethernet.

Phil

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Thu, 2 Aug 2007 15:55:22 -0500

While I support the intention of the draft for responding to ITU's requirements and as one approach for MPLS over MPLS, I am also concerned on the wording. ITU is viewing the problem they are trying to solve as supporting MPLS functionality in transport equipment. This draft is from the view of the operator for solving the problem of "transport of MPLS over MPLS". Probably the operator's problem for transporting MPLS initiated T-MPLS, though about the only commonality now is the word "transport". I don't think T-MPLS views the problem as label stacking and client/server separation but as giving a "transport" look and feel to (server network) MPLS.
 
As Yaakov suggested, it would help to point to ITU's requirements in the appropriate sections or in an appendix. This will also provide a context for the profile without needing to read the liaisons. And this will make it clear for the reader that use of external provisioning, while not precluded from being supported by current PW/MPLS, is listed in this profile to satisfy ITU's requirements. May want to include in Section 4 on MPLS a discussion of MPLS OAM.
 
Also prefer if the wording is toned down in regard to the urgency and the lack of solutions for decoupling control planes and data planes. Each operator (and customer) will have their preferences and interpretation on how to provide functional decoupling. At ITU, this statement by IETF was interpreted as acknowledging the need for T-MPLS (and T-MPLS's solution of using a non-MPLS control plane and non-MPLS OAM). For those not following MFA, MFA is taking a different approach for MPLS over MPLS- they are defining a MPLS UNI. Here's the liaison to CCAMP:
https://datatracker.ietf.org/documents/LIAISON/file385.doc
 
Deborah

From: Yaakov Stein [mailto:[email-masked]] 
Sent: Thursday, August 02, 2007 2:49 AM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [PWE3] WG LC: draft-ietf-pwe3-mpls-transport-00.txt

Neil

 

Y(J)S

	-----Original Message-----
	From: Yaakov Stein [mailto:[email-masked]] 
	Sent: 01 August 2007 11:51
	To: Danny McPherson; [email-masked]; Stewart Bryant (E-mail)
	Subject: RE: [PWE3] WG LC: draft-ietf-pwe3-mpls-transport-00.txt

	Danny and Stewart, 

	 

	 

	Does that help Yaakov?
	 
	regards, Neil

	Y(J)S

	Folks,
	
	Thanks!
	
	-danny

---

From: "Shah, Himanshu" <[email-masked]>
Date: Fri, 3 Aug 2007 09:04:24 -0400

I share same concerns with Yaakov. What is here about PW or PW interoperability?
Since its all about how MPLS should behave (when there is a particular payload in Ethernet
PW), shouldn't this be pursued in/along with MPLS WG?  
I hesitate to think what Walmart will bring as requirements for their MPLS traffic over Ethernet PW
is carried over SP's MPLS network...:-)
 
Anyway, this draft appears to be in a super fast track for 'other' reasons, and I perfectly understand
all the arguments about MPLS and T-MPLS, etc. Good thing it is just informational...
 
himanshu

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]]
Sent: Thursday, August 02, 2007 2:49 AM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [PWE3] WG LC: draft-ietf-pwe3-mpls-transport-00.txt

Neil

 

Y(J)S

  _____  

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]] 
Sent: 01 August 2007 11:51
To: Danny McPherson; [email-masked]; Stewart Bryant (E-mail)
Subject: RE: [PWE3] WG LC: draft-ietf-pwe3-mpls-transport-00.txt

Danny and Stewart, 

 

 

Does that help Yaakov?
 
regards, Neil

Y(J)S

  _____  

Folks,

Thanks!

-danny

---

From: "O'Connor, Don" <[email-masked]>
Date: Fri, 3 Aug 2007 10:49:13 -0500

In order to prevent any confusion or ambiguity between the IP/MPLS over IP/MPLS solution in this draft with the more general Generic Pseudowires approach (with a Control Word and PID) can we please change the title of this draft to
 
"Application of Ethernet Pseudowires to MPLS Transport Networks"
 
or 
 
"Application of Ethernet Pseudowires to the MPLS Transport Application"
 
Regards
 
Don

-----Original Message-----
From: Shah, Himanshu [mailto:[email-masked]]
Sent: Friday, August 03, 2007 8:04 AM
To: Yaakov Stein; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [Junk released by Allow List] RE: [PWE3] WG LC: draft-ietf-pwe3-mpls-transport-00.txt

 
 
himanshu

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]]
Sent: Thursday, August 02, 2007 2:49 AM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [PWE3] WG LC: draft-ietf-pwe3-mpls-transport-00.txt

Neil

 

Y(J)S

  _____  

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]] 
Sent: 01 August 2007 11:51
To: Danny McPherson; [email-masked]; Stewart Bryant (E-mail)
Subject: RE: [PWE3] WG LC: draft-ietf-pwe3-mpls-transport-00.txt

Danny and Stewart, 

 

 

Does that help Yaakov?
 
regards, Neil

Y(J)S

  _____  

Folks,

Thanks!

-danny

---

From: dimitri papadimitriou <[email-masked]>
Date: Fri, 03 Aug 2007 20:36:26 +0200

deborah

i agree, this document has gone past its scope (i think during the 
meeting is was clear to provide an answer) and i too

 > don't think T-MPLS views the problem as label stacking and
 > client/server separation but as giving a "transport" look and feel to
 > (server network) MPLS.

side note: i have seen the term "transport look and feel" many times but 
what does is really mean ? if wording along could be provided along 
these lines in the introduction this would be helpful for the common 
IETF'er reading the document -> the term * transport * deserves a 
specific attention to me as this doc. is produced in the IETF context

now, where i have a major issue in this document is the following sentence

"In other words, stacked LSPs do not intrinsically provide a client-
  server layer network relationship.  Several operators have identified
  this as a problem that requires urgent attention."

[...]

"One solution to the problem is to use existing pseudo-wire (PW)
  techniques to insert a 'functional other technology breakwater'
  between the two MPLS networks (of say party A and party B as noted
  above).  This could in principle use any PW technology.  However, in
  this document we restrict our solution to using an Ethernet PW as
  defined in RFC4448 [RFC4448]."

so MPLS-over-MPLS is now becoming MPLS-over-Ethernet-over-PW-over-MPLS
but this has a bestial impact ... if an operator as two separate units
we will a stack like requiring client/server relationship

IP/MPLS-over-Ethernet-over-PW-over-MPLS-over-Ethernet-over-PW-over-MPLS

... i am fine to consider a work item on MPLS client/server (or other 
MPLS UNI) if that operationally required but have difficulties to see 
how it relates to the initial set of requirements from ITU ? did they 
ask for a client/server relationship of some sort ?

thanks,
-d.

BRUNGARD, DEBORAH A, ATTLABS wrote:
> While I support the intention of the draft for responding to ITU's
> requirements and as one approach for MPLS over MPLS, I am also
> concerned on the wording. ITU is viewing the problem they are trying
> to solve as supporting MPLS functionality in transport equipment.
> This draft is from the view of the operator for solving the problem
> of "transport of MPLS over MPLS". Probably the operator's problem for
> transporting MPLS initiated T-MPLS, though about the only commonality
> now is the word "transport". I don't think T-MPLS views the problem
> as label stacking and client/server separation but as giving a
> "transport" look and feel to (server network) MPLS.
> 
> As Yaakov suggested, it would help to point to ITU's requirements in
> the appropriate sections or in an appendix. This will also provide a
> context for the profile without needing to read the liaisons. And
> this will make it clear for the reader that use of external
> provisioning, while not precluded from being supported by current
> PW/MPLS, is listed in this profile to satisfy ITU's requirements. May
> want to include in Section 4 on MPLS a discussion of MPLS OAM.
> 
> Also prefer if the wording is toned down in regard to the urgency and
> the lack of solutions for decoupling control planes and data planes.
> Each operator (and customer) will have their preferences and
> interpretation on how to provide functional decoupling. At ITU, this
> statement by IETF was interpreted as acknowledging the need for
> T-MPLS (and T-MPLS's solution of using a non-MPLS control plane and
> non-MPLS OAM). For those not following MFA, MFA is taking a different
> approach for MPLS over MPLS- they are defining a MPLS UNI. Here's the
> liaison to CCAMP: 
> From: Yaakov Stein [mailto:[email-masked]] Sent: Thursday, August
> 02, 2007 2:49 AM To: [email-masked]; [email-masked];
> [email-masked]; [email-masked] Subject: RE: [PWE3] WG LC:
> draft-ietf-pwe3-mpls-transport-00.txt
> 
> 
> Neil
> 
> That being said, I am completely in support of direct layering of
> MPLS over MPLS. As you may recall, Shahram and I proposed this to the
> MPLS WG a long time ago, asking simply for setting the stack bit and
> then having another label stack. This was soundly rejected.
> 
> That being said, I am perfectly happy with putting in a CW or a
> special label to separate the label stacks.
> 
> Y(J)S
> 
> De: [email-masked] [mailto:[email-masked]] Enviado
> el: mié 01/08/2007 14:41 Para: Yaakov Stein; [email-masked];
> [email-masked]; [email-masked] Asunto: RE: [PWE3] WG LC:
> draft-ietf-pwe3-mpls-transport-00.txt
> 
> 
> -----Original Message----- From: Yaakov Stein
> [mailto:[email-masked]] Sent: 01 August 2007 11:51 To: Danny
> McPherson; [email-masked]; Stewart Bryant (E-mail) Subject: RE: [PWE3]
> WG LC: draft-ietf-pwe3-mpls-transport-00.txt   Danny and Stewart,  
> While definitely in favor of this ideas behind this draft, I have a
> hard time with a lot of the wording.  First, the Abstract and
> Introduction describe the problem to be solved as transport (AKA as
> "carriage") of MPLS over MPLS. Specifically, the Introduction
> explains that direct transport of one carrier´s MPLS traffic over
> another carrier´s MPLS network can not be done by simple label
> stacking, and so a PW is required. NH=> No doubt you understand the
> key issue here, ie stacked LSPs per se are NOT functionally decoupled
> and thus do not provide a client/server layer network relationship
> directly.  The practical driver for this is (at least) twofold:  1
> Operators do not wish to be forced into 'peering' their MPLS networks
> for a whole raft of technical, commercial and regulatory reasons.
> Moreover, networks operating as peers assume a well defined *public*
> service....no such public MPLS service exists.  Aside=> This mistake
> is also being made in other ITU Recs.  For example, this peering
> relationship is assumed in y.1732/3 (T-MPLS OAM).....but its even
> worse here as its assumes operators will happily also sublayer a
> network and allow multi-party ownership of those sublayers (this is
> the TCM stuff).  Moreover, these draft Recs also assumes operators
> will want to try and peer interwork T-MPLS and Ethernet!  This is
> absolutely no-go......trying to peer interwork 2 technologies that
> belong to the *same* network mode is bad enough unless they are
> almost identical in ALL CP and DP functional components (including
> the key 'application to 1st layer network' adaptation functions), but
> when they belong to different network modes this is just a plain daft
> idea.  2    As operators sunset older technologies that used to
> provide a client/server transport service (eg FR, ATM, PDH, SDH) and
> largely have MPLS only networks, then the client/server issue needs
> to be addressed in MPLS.  But then there is a sharp turn and the rest
> of the draft is about transport of Ethernet over MPLS, not MPLS over
> MPLS. Some explanation is required here (other than the fact that the
> PWE charter disallows MPLS PWs over MPLS), or the Introduction should
> be reworded. NH=> Well, we have to introduce some form of 'functional
> breakwater' between the 2 MPLS networks that are owned/operated by
> different parties.  We can't do this directly with stacked LSPs as
> noted above...as least as currently defined (but see paragraph
> below)....so we have to insert a different technology (this is a
> degenerate layer network of 1-hop).  Note - the handling of the S bit
> is important here.  So why not use Ethernet?  Having said that, if we
> had a reserved label (from the 0-15 set) that had the special/global
> functional meaning "This label implies the termination of the server
> (outer) MPLS stack/network belonging to party A and the carriage of a
> client (inner) MPLS MPLS stack/network belonging to party B", then we
> could do a proper MPLSoverMPLS client/server relationship far more
> elegantly and efficiently IMO (ie MPLSoverMPLS instead of
> MPLSoverEthernetoverPWoverMPLS).  However, such a scheme is not yet
> defined.  This draft merely shows it is possible to provide a
> client/server relationship using existing IETF rfcs/IDs.  Does that
> help Yaakov?  regards, Neil  Second, the text mentions in second
> places that the draft defines a "profile". It is not clear a profile
> of what. At first I though it was a profile of RFC4448, and section 5
> says this as well. But then I found the sentence The only PWE3
> encapsulation that is supported in this version of the profile is
> Ethernet RFC4448 [RFC4448]. So, if RFC4448 is used in the profile, it
> must be a profile of something else. So is it a profile of MPLS? Or
> maybe a profile of RFC3985 ?
> 
> De: Danny McPherson [mailto:[email-masked]] Enviado el: mié 25/07/2007
> 22:13 Para: [email-masked] Asunto: [PWE3] WG LC:
> draft-ietf-pwe3-mpls-transport-00.txt  
> 
> Folks, Please consider today the beginning of a two week WG LC for
> this draft.  WG LC will end on 2007-08-08.  Please provide comments
> to [email-masked] ASAP.  Thanks!  -danny  Begin forwarded message:   >
> From: [email-masked] > Date: May 23, 2007 1:50:02 PM MDT >
> To: [email-masked] > Cc: [email-masked] > Subject: I-D
> ACTION:draft-ietf-pwe3-mpls-transport-00.txt > Reply-To:
> [email-masked] > > A New Internet-Draft is available from
> the on-line Internet-Drafts > directories. > This draft is a work
> item of the Pseudowire Emulation Edge to Edge > Working Group of the
> IETF. > >       Title           : Application of PWE3 to MPLS
> Transport Networks >       Author(s)       : S. Bryant, et al. >
> Filename        : draft-ietf-pwe3-mpls-transport-00.txt >       Pages
> : 11 >       Date            : 2007-5-23 > >    A key requirement has
> been identified by the operator community for >    the transparent
> carriage of the MPLS network of one party over the >    MPLS network
> of another party.  This document describes one IETF- >    recommended
> profile to satisfy this requirement using the existing >    RFC4448
> PWE3 Ethernet pseudowire standard.  This solution does not >
> preclude other solutions being developed in the future. > > > A URL
> for this Internet-Draft is: >
> http://www.ietf.org/internet-drafts/draft-ietf-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-ietf-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-ietf-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 >
> >       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 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> 
> _______________________________________________ pwe3 mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/pwe3

---

From: "Drake, John E" <[email-masked]>
Date: Fri, 3 Aug 2007 14:07:53 -0700

Dimitri,

Snipped...

>   this as a problem that requires urgent attention."

JD:  I have seen variations of this statement many times and I have
always thought it looked suspiciously like an assertion.  I would be
very interested in seeing an enumerated list of the perceived issues,
but I am explicitly excluding in advance the use of terms like
'functional architecture'. 

Both the GMPLS UNI and the MEF UNI that Deborah mentioned yesterday are
using stacked LSPs (LSP hierarchy, as defined in RFC 4206, is probably a
better term), and if this is ill-considered it would be nice to know
why.  

> but this has a bestial impact ... if an operator as two 
> separate units we will a stack like requiring client/server 
> relationship

JD: 'bestial' is okay.  If one were looking for a less pejorative term,
one might use 'ill-considered' or 'lame'

---

From: dimitri papadimitriou <[email-masked]>
Date: Fri, 03 Aug 2007 23:22:08 +0200

> JD: 'bestial' is okay.

sorry used it in the french connotation meaning "brute force"

-d.

Drake, John E wrote:
> .

---

From: "Drake, John E" <[email-masked]>
Date: Fri, 3 Aug 2007 14:28:51 -0700

I thought the other connotation was more evocative. 

> From: dimitri papadimitriou [mailto:[email-masked]] 
> Sent: Friday, August 03, 2007 2:22 PM
> To: Drake, John E
> Cc: [email-masked]
> Subject: Re: [PWE3] WG LC: draft-ietf-pwe3-mpls-transport-00.txt
> 
> 
>  > JD: 'bestial' is okay.
> 
> > Both the GMPLS UNI and the MEF UNI that Deborah mentioned yesterday 
> > are using stacked LSPs (LSP hierarchy, as defined in RFC 4206, is 
> > probably a better term), and if this is ill-considered it would be 
> > nice to know why.
> > 
> >> [...]
> >>
> >> but this has a bestial impact ... if an operator as two separate 
> >> units we will a stack like requiring client/server relationship
> > 
> > JD: 'bestial' is okay.  If one were looking for a less pejorative 
> > term, one might use 'ill-considered' or 'lame'
> > 
> > 
> > .
> > 
>

---

From: dimitri papadimitriou <[email-masked]>
Date: Fri, 03 Aug 2007 23:36:43 +0200

john

coming back to the main point, the issue is that this apparent client / 
server relationship need result in a draft under last call which has 
deep impact on IETF MPLS arch.

why suddenly MPLS levels needs to be decoupled by Ethernet ?

-d.

---

From: "Drake, John E" <[email-masked]>
Date: Fri, 3 Aug 2007 14:51:01 -0700

Dimitri,

I thought I was completely agreeing with you.  As someonev pointed out,
the document is being fast-tracked, and sometimes, as we have seen in
the past with the first attempt at adding ASON call/connection
functionality to GMPLS, fast-tracking can be a Bad Idea(tm).

The way we usually do things is to have a requirements I-D, which in
this case would describe the client/server deficiencies with LSP
hierachy, and that I-D should be worked on in the MPLS/GMPLS working
groups and *not* in PWE3.

I don't recall any correspondence from the MPLS/GMPLS working groups to
the PWE3 working group saying, in effect, "PWE3 working group, please
help us figure out how to fix the client/server defects in LSP hierarchy
because we can't figure out how to fix them on our own".

Thanks,

John
> Sent: Friday, August 03, 2007 2:37 PM
> To: Drake, John E
> Cc: [email-masked]
> coming back to the main point, the issue is that this 
> apparent client / server relationship need result in a draft 
> under last call which has deep impact on IETF MPLS arch.
> 
> >>>> now, where i have a major issue in this document is the 
> following 
> >>>> sentence
> >>>>

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 8 Aug 2007 00:16:43 +0100

Hi,

I support this work as an attempt to address the requirements set out in 
references [1] and [2]. I believe that it is *a* way to achieve a solution 
to the requirements using existing building blocks without needing to 
develop any new data plane or control plane features.

It is not clear to me why the insertion of an additional Ethernet header is 
required. But as portrayed in the figure, with the downstream interface of 
CE1 being an Ethernet interface *and* the client and server layer MPLS 
networks not coexisting on the same box, there is apparently no option. I 
would, however, draw your attention to the border peer model described in 
draft-ietf-ccamp-mpls-gmpls-interwork-reqts-01.txt. in this model there 
would be no requirement to insert an additional Ethernet header into the 
flow.

I have a few comments on the text...

Adrian

===
Section 1
  "MPLS [RFC3031] is based on the ability to arbitrarily stack label
   switched paths (LSPs)."
Of course, it is clear to me what you mean, but this is not the language of 
RFC 3031. In 3031 it is the labels that are "stacked" (section 3.9). The 
LSPs are arranged as a hierarchy (section 3.27.4).
Can you clean up the language, please.
===
Section 1
   "Such stacked LSPs all belong to the same MPLS
    layer network."
Well, now!
Setting aside whether I agree or not (and I don't!) I don't think we have a 
definition of "layer network" conveniently to hand. Can you either reference 
it, or explain it.
===
Section 1
   "The limited isolation provided by this mechanism
   means that it is not possible to directly carry an LSP belonging to
   the MPLS network of party A over an LSP belonging to the MPLS network
   of party B in a truly transparent, functionally decoupled manner.  In
   other words, stacked LSPs do not intrinsically provide a client-
   server layer network relationship."
"Truly transparent" and "functionally decoupled" would be better replaced by 
a description of the problem that is seen. in other words, what is it that 
you cannot do because of this aledged issue?
What value does "intrinsically" add to this text? It seems to me to suggest 
that a client/server layer network relationship can be created using some 
technique and can use hierarchical LSPs, but that the use of heirarchical 
LSPs does not create the relationship. That would be just fine, wouldn't it?
===
Section 1
   "Several operators have identified this as a problem that requires
    urgent attention."
I think we can do without this assertion. It is the type of text brought in 
to justify the existence of an I-D, but adoption as a WG draft is enough 
proof of the acceptance of the problem, and this assertion jars.
On the other hand, if you were to explain why this is a problem (i.e. what 
the problem is) and why it needs urgent attention, then I think that would 
be a great help in reviewing this document.
===
Section 1 para 2
   "One solution to the problem..."
I don't think you have explained the problem.
===
Section 1 para 2
   "However, in
   this document we restrict our solution to using an Ethernet PW as
   defined in RFC4448 [RFC4448] ."
This is fine as an approach, and no-one can possibly object. But please be 
clear that you are not carrying MPLS over an MPLS network. You are carrying 
Ethernet over an MPLS network. That is, as in your figure, there is an AC, 
and that AC is an 802.3 conneciton, and the PW is an Ethernet PW that knows 
nothing about its payload.
So, as an applicability statement for solving a specific problem, your draft 
is fine, but maybe 10 pages too long?
===
Section 1 para 2
s/[RFC4448] ./[RFC4448]./
===
Section 1 final para
   "An IP or an MPLS Label Switched Path (LSP) must be established
   between CE1 and CE2."
Does this read "An IP Label Switched Path"? I don't think so. An IP *what* 
must be established between CE1 and CE2?
===
Seciton 1 final para
   "This MPLS PSN may utilize Penultimate-Hop
   Popping (PHP)."
Which PSN? You have not talked about a PSN so far; just an IP or an MPLS 
LSP.
===
Section 1 final para
   "This MPLS PSN may utilize Penultimate-Hop
   Popping (PHP).  This LSP is to be carried over Ethernet.  An Ethernet
   PW is provisioned between PE1 and PE2 and used to carry the Ethernet
   from PE1 to PE2.  The Ethernet PW is carried over an MPLS PSN, but
   this PSN MUST NOT be configured with PHP."

There are too many requirements and allowances wrt PHP without any 
explanations. The only other references to PHP in the I-D are in sections 
4.1 and 4.2 and are raw statements of procedural requirement without any 
derivation from funcitonal requirements.

So you need two things:
1. You need to explain the consequences of allowing PHP in the IP/MPLS PSN. 
That is, since in the example the penultimate hop is CE1, the MPLS packet 
sent from CE1 to CE2 may have no MPLS labels.
2. What are the functional requirements in the server MPLS PSN that lead you 
to state that PHP MUST NOT be configured. You should be able to do this with 
reference to specific requirements stated in [1] and [2].
(Hint: I am not disputing the deconfiguration of PHP, merely trying to get 
you to say why.)
===
Figure 1
s/<--MPLS PSN (no PHP)->/<--MPLS LSP (no PHP)->/
===
Section 2

This section defines a profile and so in a sense it is fine. But since you 
are making decisions about what features are allowed and what are not, it 
behoves you to say why. I suspect the reason is largely "because we have 
limited our scope to a particular problem space" (e.g. static 
configuration), but this problem space is not defined anywhere in the 
document.
===
Section 3
At what level is the OAM described operating?
Is this CE-CE OAM on the MPLS LSP, CE-CE OAM on the Ethernet, or PE-PE OAM 
on the MPLS LSP tunnel?
>From the references to PW, I assume that this is actually operating PE-PE on 
the PW.
Please clarify the text.
===
Section 4

"4.  MPLS Layer

   This section describes the profile of the MPLS RFC3031 [RFC3031] PSN
   .  The profile considers two cases:"

As clear as mud :-)
The figure describes two MPLS PSNs.
===
Section 4.1
Suffers the same problem as section 2.
The profile is fine, but the reasons for cuting this profile are absent.
Again, references to specifc requirements in [1] and [2] would be fine.
===
Section 4.2
Why is bidirecitonality not a requirement when it is required in section 
4.1?
===
Section 4.2
Why is P2MP not a requirement when it is required in section 4.1?
===
Section 4.2
   "o  Penultimate hop popping by the LSRs MUST be disabled on LSPs
      providing PWE3 transport network functionality."
In practice, what does this mean for the signaling protocols?
Or is this, in fact, an instruction to the egress LSR. If so, how does the 
egress LSR distinguish "LSPs providing PWE3 transport network functionality" 
from other LSPs?
===
Section 5
s/is applicable/are applicable/
===
Section 6
If this I-D is a profile of PW, it is also a profile of the security 
mechanisms for PW. So you must make some statement about which PW security 
mechanisms are applicable, and which must be used.
===

===
Section 8.1
VCCV is not at revision 14
===

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 31 Aug 2007 12:58:55 +0100

Hamid,

Hamid Ould-Brahim wrote:
> Couple of comments on the draft:
>
>
> - As a general comment, I think a key motivation behind 
>   this draft is to define an IETF/PWE3 profile on how best to 
>   meet ITU T-MPLS requirements using exclusively IETF PWE3 and 
>   MPLS protocols. In simple words, this draft is what IETF
>   PWE3 WG thinks the best design/arch to meet T-MPLS requirements 
>   (reqs listed in the ITU-T liaisons referenced in the draft). 
>
>   However nowhere in this version of the draft the 
>   motivation or context of this draft is being captured. 
>   I think it will be useful if this draft captures 
>   the motivation or similar text such that we can relate this work 
>   to T-MPLS activities/discussions that led to this work in 
>   the first place.
>   
There was a reference to the Liaison statements in the intro. John Drake 
has produced a new into that I am looking at using. Please can you take 
a look at the next version and see if you think that we need to add more 
background.
> - Section 4 (MPLS Layer)
>
>  First sentence:
>
> "This section describes the profile of the MPLS RFC3031 [RFC3031] PSN".
>
> However section 4.2 includes GMPLS-based control plane for
> setting up transport LSP. I suggest the first sentence in section 
> 4 to include then a reference to GMPLS architecture RFC [RFC3945].  
>   

Change made.

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 31 Aug 2007 17:10:48 +0100

> or the Introduction should be reworded.
I have re-written the abstract and intro, and will post the proposed
alternate by COB today.
> we have never discussed profiles before. Is this term really needed?
Profile is the term that ITU used in its T-MPLS and we propagated the
term into this draft without really thinking about the implications.

I have taken a look at each use of the term and tried to replace with
suitable alternative working. I am a bit concerned that this is less
concise, but let's see. We can always go back.

The one case I left it in was VCCV, where it seemed to fit OK.
> are being enforced is absolutely required, in addition to being useful 

I am concerned here that by putting in a justification we risk and argument
over the validity of the design decision. As you saw we are responding
to an ITU liaison. That liaison is no more ephemeral than an RFC, it is
published on the IETF web site, and there is no current policy of deleting
them after some period of time as with drafts. The earliest liaison posted
is 1995.
> no label merging, no ECMP, etc.  Perhaps this needs to be a joint PWE 
We are not changing MPLS technology, simply specifying usage of a subset of
that technology in that application, and certainly both MPLS chairs are 
aware
of this draft one commented, the other is an author.

Perhaps George or Loa, could comment on whether that would like Danny
to request an MPLS WG review of this document.

- Stewart

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 31 Aug 2007 13:49:29 -0400

Like some of the other folks that have responded on this list, while in general I'm in support of the draft, I am concerned with the overhead added by the use of an Ethernet layer between the two MPLS label stacks, and don't see enough benefit to offset the overhead.  I would much prefer two label stacks separated by a control word.

Unless this is going to be restricted to be only used as shown in Figure 1, in conjunction with physical Ethernet ports, thus justifying the use of the Ethernet layer in the protocol stack.  But that seems awfully restrictive, and I don't recall any ITU-T requirements that would restrict this to Ethernet ports.  Thus, I've adapted figure 1 a bit from the draft:

+----------------------------------------------------------------+
|                                                                |
|                  IP/MPLS PSN (PHP may be enabled)              |
|                                                                |
|                  +---------------------------+                 |
|                  |                           |                 |
|                  |      MPLS PSN (No PHP)    |                 |
|                  |                           |                 |
|     CE1          |PE1                     PE2|           CE2   |
|   +-----+      +-----+                   +-----+      +-----+  |
|   | | | |      | | | |                   | | | |      | | | |  |
|   | | | +------+ | | |                   | | | +------+ | | |  |
|   | | | |      | | | |                   | | | |      | | | |  |
|   +-----+      +-----+                   +-----+      +-----+  |
|     |            |  |                      | |            |    |
|     |            +-- ---------------------- -+            |    |
+----- --- -------- -- ---------------------- - -------- --- ----+
      |            |  |<--MPLS PSN (no PHP)->| |            |
      |            |                           |            |
      |            |<-------MPLS PW----------->|            |
      |                                                     |
      |                                                     |
      |                                                     |
      |<---------IP/MPLS LSP (PHP may be supported)-------->|

I've just made the links between CEs and PEs to be general way to pass MPLS frames. Whatever physical interface type is used (Ethernet, PoS, etc.) would be terminated and the encapsulation would be stripped at entry to each PE, and re-added at each PE exit. There would be less overhead on the wire, and dissimilar physical interfaces could be used at each end.

We would need to specify an MPLS PW, but that would be pretty trivial.

Cheers,
Andy

At 8/31/2007 05:10 PM +0100, Stewart Bryant wrote:
>that technology in that application, and certainly both MPLS chairs are aware

---

From: <[email-masked]>
Date: Fri, 31 Aug 2007 19:10:59 +0100

Hi Andy,
 
So, to be clear here, are you suggesting we need to define a 'MPLS PW'?
 
An alternative solution would be to use a reserved label that carries the semantic 'this delimits stacked LSPs from 2 different MPLS layer networks'.  This would not require a PW at all, can be efficiently recursed, and allows the (*server*) interconnecting technologies between the 2 MPLS networks to be of any type.
 
regards, Neil

-----Original Message-----
From: Andrew G. Malis [mailto:[email-masked]] 
Sent: 31 August 2007 18:49
To: [email-masked]
Cc: George Swallow (swallow); Yaakov Stein; [email-masked]; Danny McPherson
Subject: Re: [PWE3] WG LC: draft-ietf-pwe3-mpls-transport-00.txt

Cheers,
Andy

Yaakov Stein wrote:

Danny and Stewart,

 

 

- Stewart

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 31 Aug 2007 14:42:11 -0400

Neil,

Yes, that could also work, but we would need to specify the signaling and OAM when such a reserved label is used. 

For an MPLS PW, life would be simpler, since we've already defined the signaling (RFC 4447) and OAM (VCCV).
 
Cheers,
Andy