Re: [mpls-tp] liaisons to the ITU-T (3) the cooperation on MPLS-TP

"Luyuan Fang (lufang)" <lufang@cisco.com> Sun, 08 February 2009 00:27 UTC

Return-Path: <lufang@cisco.com>
X-Original-To: mpls-tp@core3.amsl.com
Delivered-To: mpls-tp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADD8F3A6B6F for <mpls-tp@core3.amsl.com>; Sat, 7 Feb 2009 16:27:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.444
X-Spam-Level:
X-Spam-Status: No, score=-6.444 tagged_above=-999 required=5 tests=[AWL=-0.445, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YaXkIJ17KKe3 for <mpls-tp@core3.amsl.com>; Sat, 7 Feb 2009 16:27:18 -0800 (PST)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id A80193A6A22 for <mpls-tp@ietf.org>; Sat, 7 Feb 2009 16:27:17 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.37,397,1231113600"; d="scan'208";a="36322239"
Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 08 Feb 2009 00:27:20 +0000
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n180RKko004539; Sat, 7 Feb 2009 19:27:20 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n180RKPk015948; Sun, 8 Feb 2009 00:27:20 GMT
Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 7 Feb 2009 19:27:20 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sat, 07 Feb 2009 19:27:20 -0500
Message-ID: <DD7E9F364F33B54881C225192D4872D701A9FBAD@xmb-rtp-211.amer.cisco.com>
In-Reply-To: <b2d141720902071410v6ab34eb9yd2306105201c14a2@mail.gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [mpls-tp] liaisons to the ITU-T (3) the cooperation on MPLS-TP
Thread-Index: AcmJcPp6ZrcVhxyzQjuD9e68pWhS5AAErKVQ
References: <49803887.8000301@pi.nu> <498C65A1.50205@chello.nl><498C74BC.5080103@cisco.com> <00c601c98885$e575cba0$b06162e0$@com><EC5B248E13A6A7419C388615FADC5C970B637367@proton.jnpr.net><00d501c98894$2cb92bc0$862b8340$@com><C2851245E9854E69A7A54FDD07C6E543@your029b8cecfe><000401c988c4$d1cf4880$756dd980$@com><80A68A44-AA52-4364-AF15-418D2D950198@lucidvision.com><003a01c98936$39990a20$accb1e60$@com> <b2d141720902071410v6ab34eb9yd2306105201c14a2@mail.gmail.com>
From: "Luyuan Fang (lufang)" <lufang@cisco.com>
To: "Andrew G. Malis" <amalis@gmail.com>, davarish@yahoo.com
X-OriginalArrivalTime: 08 Feb 2009 00:27:20.0819 (UTC) FILETIME=[015ADC30:01C98984]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12107; t=1234052840; x=1234916840; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lufang@cisco.com; z=From:=20=22Luyuan=20Fang=20(lufang)=22=20<lufang@cisco.com > |Subject:=20RE=3A=20[mpls-tp]=20liaisons=20to=20the=20ITU-T =20(3)=20the=20cooperation=20on=20MPLS-TP |Sender:=20 |To:=20=22Andrew=20G.=20Malis=22=20<amalis@gmail.com>,=20<d avarish@yahoo.com>; bh=ilwWqKFoePxca4hTG6tI2nI3+W5M22w+INbwlp0PgPY=; b=bd+TDYoCKYTH1MPDAr8qX+VDlj6VphD86DTe7+3O75ZL0LgntgqOnk3Xga NHtlAhO4Uu9hSu1BrLabZgvgdZaGYCBcA5rglx/l6AUYh6uo4l56qthBmZ6r 9PwNXb+PYZ;
Authentication-Results: rtp-dkim-2; header.From=lufang@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; );
Cc: BUSI ITALO <Italo.Busi@alcatel-lucent.it>, mpls-tp@ietf.org
Subject: Re: [mpls-tp] liaisons to the ITU-T (3) the cooperation on MPLS-TP
X-BeenThere: mpls-tp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: MPLS-TP Mailing list <mpls-tp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls-tp>, <mailto:mpls-tp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls-tp>
List-Post: <mailto:mpls-tp@ietf.org>
List-Help: <mailto:mpls-tp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls-tp>, <mailto:mpls-tp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Feb 2009 00:27:19 -0000

Very well said, Andy!
Luyuan 

-----Original Message-----
From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On
Behalf Of Andrew G. Malis
Sent: 07 February 2009 17:10
To: davarish@yahoo.com
Cc: mpls-tp@ietf.org; BUSI ITALO
Subject: Re: [mpls-tp] liaisons to the ITU-T (3) the cooperation on
MPLS-TP

Sharam,

The IP/MPLS Forum has defined the MPLS Inter-Carrier Interconnect
Specification ( http://www.ipmplsforum.org/tech/IPMPLSForum19.0.0.pdf
). Just this past week I was in discussion with a large European-based
interconnect provider (they interconnect several hundred service
provider networks) that has customers interested in interconnecting
using this specification. I know of several other providers that have
also expressed interest.

In addition, Verizon (for one) has widely deployed MPLS in its public
and private IP backbone networks and intends to deploy MPLS-TP in its
transport network. We are extremely concerned with precluding any
potential harm through the accidental interconnection of IP/MPLS and
transport layer MPLS, either through operational or provisioning error,
or though physical misconnections in a CO. With MPLS-TP, we know that
potential harm can be precluded. We cannot be so sure with T-MPLS as
defined in the current recommendations.

Cheers,
Andy

On Sat, Feb 7, 2009 at 10:10 AM, Shahram Davari <davari@rogers.com>
wrote:
> Tom,
>
> What I meant was that MPLS/T-MPLS are not used at Internet peering 
> points (E-NNI). Off course a single ISP can use MPLS or T-MPLS in 
> their own network, but they are in full control of their own network 
> and could make sure incompatible protocols are not used or are used in
a controlled manner.
>
> -Shahram
>
> -----Original Message-----
> From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]
> Sent: February-07-09 9:58 AM
> To: davarish@yahoo.com
> Cc: 'Adrian Farrel'; 'Thomas Walsh'; stbryant@cisco.com; 
> hhelvoort@chello.nl; 'BUSI ITALO'; mpls-tp@ietf.org
> Subject: Re: [mpls-tp] liaisons to the ITU-T (3) the cooperation on 
> MPLS-TP
>
>
>
>> Hi Adrian and Tom,
>>
>> I am personally in favour of deprecating T-MPLS, because I think the 
>> industry needs one set of standard and having two will lead to 
>> confusion.
>> But  I don't think T-MPLS is dangerous for the public "Internet" 
>> (sine MPLS or T-MPLS are not used in the public Internet) ,
>
>        Sharam,
>
>        I am a little surprised by your assertion above that MPLS is 
> not used in the public Internet.  The reality is quite the contrary.  
> Perhaps you meant something else or this is a typo?
>
>        --Tom
>
>
>
>> and I also don't think not
>> following IETF change procedures is a convincing argument (because 
>> one might come up with a valid protocol without following the IETF 
>> change process).
>>
>> Best regards,
>> Shahram
>>
>> -----Original Message-----
>> From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On 
>> Behalf Of Adrian Farrel
>> Sent: February-06-09 3:59 PM
>> To: davarish@yahoo.com; 'Thomas Walsh'; stbryant@cisco.com; 
>> hhelvoort@chello.nl
>> Cc: 'BUSI ITALO'; mpls-tp@ietf.org
>> Subject: Re: [mpls-tp] liaisons to the ITU-T (3) the cooperation on 
>> MPLS-TP
>>
>> Shahram,
>>
>> Trying to defuse a little...
>> I'm not sure that discussing the IETF behavior is entirely helpful, 
>> but for reference, RFCs that are "replaced" are marked in the RFC 
>> list as 'obsolete.' RFCs that are no longer relevant are marked as 
>> 'historic' and RFCs that are considered harmful are obsoleted by a 
>> new RFC that describes how they are harmful.
>>
>> What is at stake here is what is most helpful to the community at 
>> large. If a technology (e.g. T-MPLS) is being replaced by another 
>> technology
>> (MPLS-TP)
>>
>> by wide consensus of the community (ITU-T and IETF) it is not helpful

>> to allow people to think that the old technology is still valid and 
>> worth implementing. Doing so would mislead people into thinking that 
>> they there is
>>
>> community support for the technology. A new hardware company coming 
>> to the list of Recommendations might conclude that the industry 
>> supports the technology and might waste valuable development time 
>> pursuing the technology.
>>
>> Given that the IETF has persuaded the ITU-T that T-MPLS should not be

>> worked
>>
>> on further and should be replaced by MPLS-TP, it is dangerously 
>> misleading to leave the T-MPLS Recommendations "lying around".
>>
>> The agreement in Geneva seems to have been a compromise. The IETF 
>> requested that the ITU-T should delete the existing T-MPLS 
>> Recommendations.
>> The ITU-T
>> has decided to leave the Recommendations in place until they are 
>> "replaced"
>> by the v2 Recommendations that will move to MPLS-TP. It is debateable

>> whether this replacement will mean that the v1 Recommendations are 
>> 'deprecated', 'obsoleted', or merely 'replaced'. It would seem 
>> sensible, however, to note that G.xxxx v2 completely replaces G.xxxx 
>> v1 even if the latter remains available in the repository. Someone 
>> implementing or deploying G.xxxx would take the most recent version.
>>
>> Actually, I had some reservations about the agreement in Geneva. It 
>> seems to
>>
>> me to be predicated on the ITU-T pulling its finger out and producing

>> the v2
>>
>> Recommendations. As yet I have not seen even an editor's revisions of

>> any one Recommendation (perhaps I have not looked in the right 
>> place?).
>> If the
>> ITU-T is not willing to produce this work I must assume that the JWT 
>> agreement is not backed by meaningful intent.
>>
>> Cheers,
>> Adrian
>> ----- Original Message -----
>> From: "Shahram Davari" <davari@rogers.com>
>> To: "'Thomas Walsh'" <twalsh@juniper.net>; <davarish@yahoo.com>; 
>> <stbryant@cisco.com>; <hhelvoort@chello.nl>
>> Cc: "'BUSI ITALO'" <Italo.Busi@alcatel-lucent.it>; <mpls-tp@ietf.org>
>> Sent: Friday, February 06, 2009 7:50 PM
>> Subject: Re: [mpls-tp] liaisons to the ITU-T (3) the cooperation on 
>> MPLS-TP
>>
>>
>>> Hi Tom,
>>>
>>> AFAIK IETF doesn't remove an obsolete RFC from its server (e.g.
>>> RFC2598).
>>> Are you then asking that ITU should remove obsolete recommendations 
>>> from its server.
>>>
>>> Regards,
>>> Shahram
>>>
>>> -----Original Message-----
>>> From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On 
>>> Behalf Of Thomas Walsh
>>> Sent: February-06-09 2:16 PM
>>> To: davarish@yahoo.com; stbryant@cisco.com; hhelvoort@chello.nl
>>> Cc: BUSI ITALO; mpls-tp@ietf.org
>>> Subject: Re: [mpls-tp] liaisons to the ITU-T (3) the cooperation on 
>>> MPLS-TP
>>>
>>> Sharam,
>>>
>>> Please note I am not speaking for Stewart here, but this is my own 
>>> reaction to what you just said.
>>>
>>> These are two necessary steps for sure and as far as I know are 
>>> being followed.  I see nothing inconsistent in what Stuart said.
>>>
>>> Bottom line:
>>> The T-MPLS Recommendations were never submitted according to the 
>>> IETF change process and hence must be removed.
>>>
>>> Monique and I just spent two weeks in January at ITU-T SG 13 and SG 
>>> 11.
>>> We generally found very good cooperation in their understanding that

>>> they can not publish any change to IP or an MPLS protocol in a 
>>> Recommendation without following the IETF change process.
>>>
>>> The JWT agreement had two options (1) and (2).
>>>
>>> Option 2 would allow publication of T-MPLS Recommendations by ITU-T 
>>> as they currently exist as long as they remove the MPLS Ethertype.
>>>
>>> Option (1) does not allow use of the MPLS Ethertype in an ITU-T 
>>> Recommendation unless it's a protocol approved by IETF according to 
>>> its change process.  And this option conforms to the IETF Change 
>>> process.
>>>
>>> Please do not quote JWT agreements out of context. The JWT agreement

>>> does not give ITU-T the right to ignore the IETF change process.
>>>
>>> ITU-T may freely use IETF approved protocols.  T-MPLS is not IETF 
>>> approved according to the change process. IETF has a right to ask 
>>> for these offending documents to be withdrawn.
>>>
>>> Just my view,
>>>
>>> Tom
>>>
>>>
>>>> -----Original Message-----
>>>> From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On
>>> Behalf
>>>> Of Shahram Davari
>>>> Sent: Friday, February 06, 2009 10:08 AM
>>>> To: stbryant@cisco.com; hhelvoort@chello.nl
>>>> Cc: 'BUSI ITALO'; mpls-tp@ietf.org
>>>> Subject: Re: [mpls-tp] liaisons to the ITU-T (3) the cooperation on
>>> MPLS-
>>>> TP
>>>>
>>>> Hi Stewart,
>>>>
>>>> Here is your own report:
>>>>
>>>> http://www.ietf.org/internet-drafts/draft-bryant-mpls-tp-jwt-report
>>>> -
>>>> 00.txt
>>>>
>>>> and here is what it says in your report that ITU-T agreed to do:
>>>>
>>>> - Alignment of the current T-MPLS ITU-T Recommendations with
MPLS-TP
>>>>      and,
>>>> - Termination of the work on current T-MPLS.
>>>>
>>>> I can't see anywhere in the report the term or intention of
>>> deprecating.
>>>> Could you please clarify which part of this report indicates
>>> deprecating?
>>>>
>>>> Thanks,
>>>> Shahram
>>>>
>>>> -----Original Message-----
>>>> From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On
>>> Behalf
>>>> Of Stewart Bryant
>>>> Sent: February-06-09 12:35 PM
>>>> To: hhelvoort@chello.nl
>>>> Cc: BUSI ITALO; mpls-tp@ietf.org
>>>> Subject: Re: [mpls-tp] liaisons to the ITU-T (3) the cooperation on
>>> MPLS-
>>>> TP
>>>>
>>>> Huub van Helvoort wrote:
>>>>> Stewart,
>>>>>
>>>>> You replied:
>>>>>
>>>>>>> So by keeping the word "depreciation" in the liaison response 
>>>>>>> the whole discussion will start again and as Stuart already 
>>>>>>> mentioned a few times, this is a waste of time and resources.
>>>>>>> And also it confuses the industry about the position of the
IETF.
>>>>>>
>>>>>> There is no confusion about the position of the IETF. It has 
>>>>>> quite clearly stated that T-MPLS is a potential danger to the 
>>>>>> Internet and should not be deployed.
>>>>>>
>>>>>> The most appropriate action under such circumstances is 
>>>>>> deprecation of the protocol.
>>>>>
>>>>> Does this mean that you do not accept the agreement documented in 
>>>>> the JWT report and WP3 report and that all the time spent to 
>>>>> discuss these agreements is wasted and that you want to start this

>>>>> discussion again.
>>>>>
>>>> Huub
>>>>
>>>> I can see no logical linkage between my statement and your 
>>>> deduction. Please will you explain it to me.
>>>>
>>>> Stewart
>>>>
>>>> _______________________________________________
>>>> mpls-tp mailing list
>>>> mpls-tp@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/mpls-tp
>>>>
>>>> _______________________________________________
>>>> mpls-tp mailing list
>>>> mpls-tp@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/mpls-tp
>>> _______________________________________________
>>> mpls-tp mailing list
>>> mpls-tp@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mpls-tp
>>>
>>> _______________________________________________
>>> mpls-tp mailing list
>>> mpls-tp@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mpls-tp
>>>
>>
>> _______________________________________________
>> mpls-tp mailing list
>> mpls-tp@ietf.org
>> https://www.ietf.org/mailman/listinfo/mpls-tp
>>
>> _______________________________________________
>> mpls-tp mailing list
>> mpls-tp@ietf.org
>> https://www.ietf.org/mailman/listinfo/mpls-tp
>>
>
> _______________________________________________
> mpls-tp mailing list
> mpls-tp@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls-tp
>
_______________________________________________
mpls-tp mailing list
mpls-tp@ietf.org
https://www.ietf.org/mailman/listinfo/mpls-tp