The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2007-Mar> msg00300



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

[mpls] Re: [PWE3] Fwd: I-DACTION:draft-bryant-pwe3-mpls-transport-00.txt

  • From: Stewart Bryant <stbryant@cisco.com>
  • Date: Fri, 23 Mar 2007 08:43:09 +0000
  • Authentication-Results: ams-dkim-1; header.From=stbryant@cisco.com; dkim=pass (sig from cisco.com/amsdkim1002 verified; );
  • Cc: mpls@ietf.org, townsley@cisco.com, "pwe3 \(\(\(\(\(\(\(\(E-mail\)\)\)\)\)\)\)\) WG" <pwe3@ietf.org>
  • DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3115; t=1174639398;x=1175503398; c=relaxed/simple; s=amsdkim1002;h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;d=cisco.com; i=stbryant@cisco.com;z=From:=20Stewart=20Bryant=20<stbryant@cisco.com>|Subject:=20Re=3A=20[PWE3]=20Fwd=3A=20I-D=20ACTION=3Adraft-bryant-pwe3-mpls-transport-00.txt |Sender:=20;bh=woAvb/oUNIy8oL4JIdre9nHxG94WUIPdU1RHUDkAAuc=;b=bNFy0xpx0DUPxbwbTXbAVzatGdNbB95R/ebg+Btv41r72fcpIRRY6mhbuLivv6XUNidxC9RFSgEpVZEnIySWXey4zeUa300lsNt+63jpcQ6mbxwlbE7bl4A/fbim8C3S;
  • User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)

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.

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

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