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

From: Stewart Bryant <[email-masked]>
Date: Mon, 03 Sep 2007 11:58:42 +0100

Andrew G. Malis wrote:
> 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:

In general I agree with Andy - I think that we need a
better method of carrying MPLS over MPLS than
the method proposed in the draft. However the draft
reflects exactly the ITU proposal back to them
except using standard methods.

We therefore have two choices: we can continue
with this draft, with a high expectation of a
second rfc in the near future, or we can design
an MPLS over MPLS mechanism and include
it in this draft. I am concerned that although
MPLS over MPLS is in principle simple, it will
take us a while to design it, get it reviewed by
the PWE3 and MPLS WGs etc etc.

If it helps we can change the title to make it clearer.

To that end Don O'Conor suggested a change in title to

"Application of Ethernet Pseudowires to MPLS Transport Networks"

Which is something that I would propose we do.

My proposal here is that we leave figure 1 unchanged, change the
title and try to get a good mpls/mpls approach on the table
by the next IETF.

What do other folks think?

Stewart

>
>  
> +----------------------------------------------------------------+
> |                                                                |
> |                  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:
>> Yaakov Stein wrote:
>>> 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.
>> I have re-written the abstract and intro, and will post the proposed
>> alternate by COB today.
>>>  
>>> 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?
>> 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.
>>>
>>> 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.
>>
>> 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.
>>>
>>>  
>>>
>>> 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?
>> 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
>>
>>
>> _______________________________________________
>> 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: Mon, 3 Sep 2007 13:49:02 +0100

Thanks Stewart,

A few further observations.....

1    Eth only.  No protocol changes needed.  Restrictive to Eth.  Has issue that MPLS OAM is not the same as PW OAM, so has potential misconnectivity problem due to inconsistent Characteristic Information (CI).  Many layers => MPLS_Eth_Eth-PW_server-in-station (any, probably Eth)_MPLS_server-phys-line (any, probably Eth)...each of these has different OAM.  Does not recur efficiently.   End-end Eth and PW layers both degenerate (ie 1-hop) but this would not be true for PW layer if this is multi-hop.
 
2    New MPLS PW.  Removes end-end Eth layer in above, ie MPLS_MPLS-PW_server-in-station (any, probably Eth)_MPLS_server-phys-line (any, probably Eth).  Same OAM CI problem as above.  Needs new MPLS PW objects defining for CP signalling (still targeted LDP I guess).  PW layer degenerate (ie 1-hop) but this would not be true for PW layer if this is multi-hop.  Overall, better solution than above but not by much IMO.  
 
3    Reserved label.  Removes both end-end Eth and PW layer, ie MPLS_server-in-station (any, probably Eth)_MPLS_server-phys-line (any, probably Eth).  Does not have the OAM problem as CI consistent here (Note - a reserved label is not like an arbitrary label as it has a globally well-known semantic).   Stewart has however raised concerns about ECMP load-balancing techniques here (if LDP only?...but what about using RSVP-TE?).  This seems to have both consistent CI and efficiency advantages (including recursive stacking) and would allow the use of RSVP-TE.

Not sure if that helps...just trying to look at pros/cons and other options.

regards, Neil

> -----Original Message-----
> From: Stewart Bryant [mailto:[email-masked]] 
> Sent: 03 September 2007 11:59
> To: Andrew G. Malis
> Cc: George Swallow (swallow); Yaakov Stein; [email-masked]; 
> Danny McPherson
> Subject: Re: [PWE3] WG LC: draft-ietf-pwe3-mpls-transport-00.txt
> 
> 
> Andrew G. Malis wrote:
> My proposal here is that we leave figure 1 unchanged, change 
> the title and try to get a good mpls/mpls approach on the 
> table by the next IETF.
> 
> 
> >>> 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.
> >>>  
> >>> 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.
> 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.

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 03 Sep 2007 17:07:11 +0100

Phil Bedard wrote:
> 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 latter.

I am proposing that we change the title to

> 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.  
Remember that the constants come from the ITU expressing their needs in 
building a transport network (these are called up in the liaison.

Our goal here is to say, "if those are your constraints, here is how you 
achieve a network with those constraints using *existing*  IETF technology."

As such I don't think that we should attempt to justify the constraints 
in PWE3 consensus text, it does not really matter whether we believe 
them or not, the ITU does and is using them to justify a whole new 
definition of a PWE3 over MPLS  technology.

> 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.
We need to think about the correct notation. I copied a lot of those 
requirements from the ITU liaison. However following concerns for 
clarity in Figure 1, I used the term client and server to distinguish 
between the two MPLS networks. I have tried replacing transport with 
server in the requirements/config section.

Does anyone have an alternate proposal?
>
> 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.

It is becoming clear that we need another more general document. The 
question is whether we continue with this and produce the more general 
solution later, or whether we change direction now.

I do not think that this document presents any problem regarding 
producing a future work, and the technical proposal is a strict subset 
of our existing work, so I am inclined to suggest that we continue on 
this path.

Stewart

>
> Phil
>
>
> On Jul 25, 2007, at 3:13 PM, Danny McPherson wrote:
>
>> 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
>>>
>>
>>
>>
>>

---

From: "Shah, Himanshu" <[email-masked]>
Date: Tue, 4 Sep 2007 16:21:20 -0400

> What do other folks think?

I think changing the name that appropriately reflects the
content of the draft would be the step in right direction.

So I agree with Stewarts suggested course of action.

/himanshu

---

From: "JOUNAY Frederic RD-RESA-LAN" <[email-masked]>
Date: Wed, 5 Sep 2007 11:40:20 +0200

Hi all,
As stated by the chairs during the last meeting P2MP PW was referred as
a new potential work item for the WG.
The P2MP PW related drafts posted for the Pragues meeting have recently
expired (requirements draft presented during the meeting). I would like
to hear feedbacks on this item from the WG. Particularly do you think
that the topic deserves to be studied in the WG ?

Regards,
Frederic

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 05 Sep 2007 10:54:42 +0100

> that the topic deserves to be studied in the WG ?
Speaking as an individual contributor - yes I think we need to address 
this topic.

Stewart