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

[<[e-mail]>]

Hi Italo...I think its only fair to point out here that I spent a year
or so arguing for the use of a CV flow in MPLS ~7 years ago when I was
writing Y.1710/Y.1711.  At that time this 'powerful tool' came in for a
quite a bit of ridicule within IETF.  Of course this was quite
understandable, because if one breaks the rules of a connection (eg LDP
or PHP merging) then a simple CV OAM solution like Y.1711 can't be used
and one requires much more complex OAM.....and when one factors-in ECMP
this becomes almost proactively intractable IMO.  But OAM is the least
of the problems that such constructs create; fundamentally if one cannot
determinsitically manage resource because the rules of a connection are
broken then one has to design/operate the whole network to the single
most stringent client SLA in force.

Good OAM only follows good initial network/protocol design....so
understanding/getting the arch rules right for each of the 3 network
modes is crucially important...and they are *not* the same.  I am not at
all impressed by arguments from those folks that try and force some kind
of 'common functional solution' here...whether this is the myth of a
common CP running IP to Optics or those that advocate the same OAM for
all 3 network modes.  Sure we can re-use some components....but we
should do this wisely and from a position of proper technical
understanding and not dogma.

When we are dealing with the co-ps mode the most important thing to get
right is the rules of a connection....good OAM can then follow from
this.  And good OAM is not complex, it is just the opposite, ie
simple/sparse.

If you really want a best-case/lowest-cost solution for proactive
misconnectivity protection for the co-ps mode then it's a jolly good
idea to have a SA in each/every traffic unit (not just an adjunct OAM CV
flow)....just like one finds in PBB-TE for example.

regards, neil

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of BUSI ITALO
> Sent: 18 February 2009 12:06
> To: Loa Andersson
> Cc: [e-mail]
> Subject: Re: [mpls-tp] liaisons to the ITU-T (3) the 
> cooperation on MPLS-TP
> 
> The first version of T-MPLS OAM tools are defined in ITU-T 
> (approved and
> in-force) Recommendation G.8112
> 
> G.8112 CV is powerful enogh to detect misconnections
> 
> Italo
> 
> > -----Original Message-----
> > From: Loa Andersson [mailto:[e-mail]] 
> > Sent: Wednesday, February 18, 2009 11:45 AM
> > To: BUSI ITALO
> > Cc: Andrew G. Malis; [e-mail]
> > Subject: Re: [mpls-tp] liaisons to the ITU-T (3) the 
> > cooperation on MPLS-TP
> > 
> > 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]
> > 
> > 
> > 
> _______________________________________________
> mpls-tp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>