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

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

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.
Here is the problem. If we add text, we will have to track the current 
t-mpls requirements as we take this document forward, whereas by 
pointing to an explicit external document that is frozen in time (the 
liaisons) we set a checkpoint. We also may fall into the trap of needing 
to justify the requirements, which is what I think we should be doing.

Which approach does the WG prefer?
> 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.
>
I have added some text on external provisioning in the MPLS section 
(PWE3 has always had external provisioning as an explicit option).

I have requested that the authors with OAM expertise provide some text 
on MPLS OAM.

I also added some text to the security section, although perhaps we need 
to take a closer look at that, since as far as I am aware it's been a 
long time since anyone seriously considered static routing in a 
largescale core packet network.

> 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
I have proposed using the new Intro text that was sent to me, and which 
I forwarded to the list.

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

---

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

Shah, Himanshu wrote:
> 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?
The MPLS WG chairs are in the loop. I will ask Danny to ask for formal 
review of the next
version.

Stewart
> 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
>
>