The MPLS WG Archive

["Italo Busi" <italo.busi@alcatel-lucent.it>]

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.

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

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


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