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

[Loa Andersson <[e-mail]>]

Italo,

exactly what are you referring to here? Where are "the powerful
T-MPLS OAM tools" documented?

/Loa

BUSI ITALO wrote:
> Andy,
> 
> T-MPLS provides powerful OAM tools to detect any misconfiguration errors
> and prevent "accidental interconnection of IP/MPLS and transport layer
> MPLS"
> 
> Italo
> 
>> -----Original Message-----
>> From: Andrew G. Malis [mailto:[e-mail]] 
>> Sent: Saturday, February 07, 2009 11:10 PM
>> To: [e-mail]
>> Cc: Thomas Nadeau; BUSI ITALO; [e-mail]
>> 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 
>> <[e-mail]> 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:[e-mail]]
>>> Sent: February-07-09 9:58 AM
>>> To: [e-mail]
>>> Cc: 'Adrian Farrel'; 'Thomas Walsh'; [e-mail];
>>> [e-mail]; 'BUSI ITALO'; [e-mail]
>>> 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: [e-mail] [mailto:[e-mail]] On
>>>> Behalf
>>>> Of Adrian Farrel
>>>> Sent: February-06-09 3:59 PM
>>>> To: [e-mail]; 'Thomas Walsh'; [e-mail];
>>>> [e-mail]
>>>> Cc: 'BUSI ITALO'; [e-mail]
>>>> 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" <[e-mail]>
>>>> To: "'Thomas Walsh'" <[e-mail]>; <[e-mail]>;
>>>> <[e-mail]>; <[e-mail]>
>>>> Cc: "'BUSI ITALO'" <[e-mail]>; 
>> <[e-mail]>
>>>> 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: [e-mail] 
>> [mailto:[e-mail]] On
>>>>> Behalf
>>>>> Of Thomas Walsh
>>>>> Sent: February-06-09 2:16 PM
>>>>> To: [e-mail]; [e-mail]; [e-mail]
>>>>> Cc: BUSI ITALO; [e-mail]
>>>>> 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: [e-mail] 
>> [mailto:[e-mail]] On
>>>>> Behalf
>>>>>> Of Shahram Davari
>>>>>> Sent: Friday, February 06, 2009 10:08 AM
>>>>>> To: [e-mail]; [e-mail]
>>>>>> Cc: 'BUSI ITALO'; [e-mail]
>>>>>> 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: [e-mail] 
>> [mailto:[e-mail]] On
>>>>> Behalf
>>>>>> Of Stewart Bryant
>>>>>> Sent: February-06-09 12:35 PM
>>>>>> To: [e-mail]
>>>>>> Cc: BUSI ITALO; [e-mail]
>>>>>> 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
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/mpls-tp
>>>>>>
>>>>>> _______________________________________________
>>>>>> mpls-tp mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/mpls-tp
>>>>> _______________________________________________
>>>>> mpls-tp mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/mpls-tp
>>>>>
>>>>> _______________________________________________
>>>>> mpls-tp mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/mpls-tp
>>>>>
>>>> _______________________________________________
>>>> mpls-tp mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/mpls-tp
>>>>
>>>> _______________________________________________
>>>> mpls-tp mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/mpls-tp
>>>>
>>> _______________________________________________
>>> mpls-tp mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mpls-tp
>>>
> _______________________________________________
> mpls-tp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls-tp

-- 


Loa Andersson

Sr Strategy and Standards Manager
Ericsson ///                          phone:  [phone]

                                       email:  [e-mail]
                                               [e-mail]
                                               [e-mail]