The MPLS WG Archive

["O'Connor, Don" <don.oconnor@us.fujitsu.com>]

Stewart, Italo

Please see my replies below marked [Don]

Regards

Don

-----Original Message-----
From: Italo Busi [mailto:italo.busi@alcatel-lucent.it]
Sent: Friday, March 23, 2007 5:47 AM
To: Stewart Bryant; O'Connor, Don
Cc: mpls@ietf.org; pwe3 ((((((((E-mail)))))))) WG; townsley@cisco.com
Subject: [mpls] RE: [PWE3] Fwd:
I-DACTION:draft-bryant-pwe3-mpls-transport-00.txt


Stewart,

see in line marked with [ib]

Italo

> -----Original Message-----
> From: Stewart Bryant [mailto:stbryant@cisco.com]
> Sent: Friday, March 23, 2007 9:43 AM
> To: O'Connor, Don
> Cc: swallow@cisco.com; mpls@ietf.org; townsley@cisco.com; pwe3
> ((((((((E-mail)))))))) WG; Danny McPherson
> Subject: Re: [PWE3] Fwd: I-D
> ACTION:draft-bryant-pwe3-mpls-transport-00.txt
>
>
> 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.
>

[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.

[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. 

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

[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?

[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)

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

[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

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

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


>
> >
> > 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
>
> "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?

[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

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

[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

>
> - Stewart
>


_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls