[mpls-tp] R: [mpls] MPLS WG slides from CMCC

["BUSI, ITALO (ITALO)" <[e-mail]>]

Chris,

> However, there
> are outstanding concerns on this draft on multiple levels
> (interoperability with the  "standard" MPLS stack, a number of issues
> raised in various reviews, including a routing area review, etc.).

Could you please send a list of these issues?

I do not recall to have seen any on the mpls-tp mailing list.

Thanks, Italo

> -----Messaggio originale-----
> Da: [e-mail] [mailto:[e-mail]] Per conto di
> Christopher LILJENSTOLPE
> Inviato: mercoledì 15 dicembre 2010 6.16
> A: Huub van Helvoort
> Cc: [e-mail]; Ad hoc MPLS-TP; [e-mail]
> Oggetto: Re: [mpls] [mpls-tp] MPLS WG slides from CMCC
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> Greetings,
> 
> Comments in line...
> On 14Dec2010, at 21.40, Huub van Helvoort wrote:
> 
> > Hej Christopher,
> >
> > Please see in-line [hvh]
> >
> >> I don't believe I do. The requirements document just that, requirements,
> <snip>
> >> document yet.
> >
> > [hvh] one of the reasons for *not* accepting it as WG draft was that
> > there were too many co-authors.
> >
> >> Therefore, basing your technology around it is a dice roll. I assume
> <snip>
> >>
> >> path once or twice myself).
> >
> > [hvh] another reason for the selection was the availability of
> > a solution.
> 
> To be sure, this is a "emotional" issue for both sides.  However, there
> are outstanding concerns on this draft on multiple levels
> (interoperability with the  "standard" MPLS stack, a number of issues
> raised in various reviews, including a routing area review, etc.).  I also
> am personally concerned about re-use of existing technology and standards,
> where possible.  I believe I am not the only one with those concerns (the
> amount of protocols running around in the network today is a nightmare, I
> would prefer not to add to that stack if I don't have to).  I am also
> concerned about the propagation of two completely separate approaches to
> answer 5860 that could both be considered "MPLS-TP OAM" solutions.
> Interoperation would become "interesting"
> 
> >
> >> However, if CMCC (or any other carrier) have decided to deploy draft-
> bhh
> >> based on an understanding that draft-bhh WOULD become a standard, that
> >> would be an unfortunate misunderstanding.
> >
> > [hvh] the fact that they are really interested in this solution is
> > proven by the standardisation of this solution in CCSA.
> 
> This is a real concern.  There is a reason why network standards (and
> their organizations) are International in scope (i.e. the ITU and IETF).
> In the days of very little cross-border connectivity, we could get away
> with "national" or "regional" standards.  However, even in those days,
> they caused issues.  How many people remember the fun of T1/E1/J1 or the
> early days of SONET/SDH interworking?  How about the joys of the North
> American GSM frequencies vs. the ROW?  Even with those fairly constrained
> interoperation issues, there was damage done to the market, and customers
> were inconvenienced (witness the slow uptake of GSM in the NA market and
> paucity of GSM handsets for same, for example).
> 
> More lately, there have been attempts to have national standards for WiMAX,
> WiFi encryption, and 3G networks.  All of us who travelled to the last
> IETF from other locations with 3G phones had the experience of a national
> 3G standard network (and having to manually set phones to other,
> international standard, networks).  The other examples here have pretty
> much died away.
> 
> Any SDO should have the ability to act on it's own, for the best interest
> of it's constituents.  However, an SDO doing so, in a space that is
> recognized as being the domain of another SDO does so at a risk, and
> should do so fully understanding that risk/reward calculation.
> 
> I am not competent to speak to the CCSA decision, but I am sure they made
> that decision fully cogent of the ongoing discussion in the IETF regarding
> these drafts.  However, the fact that they have elected to standardize on
> a individual contribution to the IETF should not put a burden or
> expectation on the IETF to then ratify that individual contribution,
> outside of the normal IETF process.
> 
> To present the argument as you have, may, if anything, increase resistance
> to the draft in question, if for no other reason than not wishing to set a
> precedent.
> 
> >
> > [hvh] because service providers outside of China also want to
> > use this solution they would like to make it an international
> > standard.
> 
> As above
> >
> >> It is my understanding that
> >> the working group has never guaranteed that draft-bhh would become a
> >> STANDARD, and if that had been signaled, then I would expect draft-bhh
> >> to be a working-group draft, at least. I am not saying that it won't
> >> become a standard, I'm just saying that one (or a few) operators
> >
> > [hvh] it is not a few anymore.
> >
> >> deciding to deploy something does not automatically grant it a quick
> >> path to standardization in the IETF, especially if other operators have
> >> a differing opinion of that draft proposal.
> >
> > [hvh] also one, or a few.
> 
> On these two, we can count noses (or hums), but doing so on the list and
> in the room multiple times in the past has not materially changed the
> equation.
> 
> >
> > M.v.h. Huub.
> 
> Respectfully,
> Christopher
> 
> >
> > ============
> >> On 14Dec2010, at 18.51, Huub van Helvoort wrote:
> >>
> >>> Hello Chris,
> >>>
> >>> You wrote:
> >>>
> >>>> My concern here is that the requirements are based on a DRAFT.
> >>>
> >>> I think you have the order wrong.
> >>> The MPLS-TP OAM requirements are in RFC5860:
> >>> http://tools.ietf.org/html/rfc5860
> >>>
> >>> draft-bhh-MPLS-TP-OAM-Y1731 is a solution based on RFC5860.
> >>>
> >>>> Not that
> >>>> that doesn't happen from time to time, but that does not mean that
> the
> >>>> IETF must then standardize that DRAFT. Someone writing a spec based
> on
> >>>> DRAFTs are taking an (educated) gamble that that DRAFT will be
> >>>> standardized and supported by other vendors.
> >>>
> >>> draft-bhh-MPLS-TP-OAM-Y1731 provides a set of tools that fits in
> >>> a larger toolbox with multiple tools.
> >>>
> >>>> In short, the decision, is, of course, the prerogative of the
> purchaser,
> >>>
> >>> The service provider can pick a selection of the tools for
> >>> use in his network by enabling the ones he needs.
> >>> CMCC and many other service providers have a preference for
> >>> the tools provided by draft-bhh-MPLS-TP-OAM-Y1731.
> >>>
> >>> Best regards, Huub.
> >>>
> >>> ===================
> >>>> On 11Nov2010, at 18.52, Larry wrote:
> >>>>
> >>>>> Dear Huub:
> >>>>>
> >>>>> Yes!
> >>>>> Actually, China Mobile has introduced 38,000 PTN equipments based on
> >>>>> pre-standard G.8114 in 2009. China Mobile will introduce more than
> >>>>> 110,000 PTN equipments based on draft-bhh-MPLS-TP-OAM-Y1731 in 2010.
> >>>>> We will upgrade G.8114 to Y.1731 based OAM by the end of this year.
> >>>>> Because Draft-bhh and relevant CCSA standard are based on Y.1731, so
> I
> >>>>> use Y.1731 to present all of them.
> >>>>> Thank you!
> >>>>>
> >>>>> Best regards,
> >>>>>
> >>>>> Han Li
> >>>>>
> >>>>>
> *************************************************************************
> >>>>> Han Li, Ph.D
> >>>>> China Mobile Research Institute
> >>>>> Unit 2, 28 Xuanwumenxi Ave, Xuanwu District, Beijing 100053, China
> >>>>> Fax: [phone]
> >>>>> MOBILE: [phone]
> >>>>>
> *************************************************************************
> >>>>>
> >>>>>
> >>>>> --- 10年11月11日，周四, Huub van Helvoort <[e-mail]
> >>>>> <mailto:[e-mail]>
> >>>>> <mailto:[e-mail]>> 写道：
> >>>>>
> >>>>>> 发件人: Huub van Helvoort <[e-mail]
> >>>>>> <mailto:[e-mail]>
> >>>>>> <mailto:[e-mail]>>
> >>>>>> 主题: Re: [mpls-tp] [mpls] MPLS WG slides from CMCC
> >>>>>> 收件人: [e-mail] <mailto:[e-mail]> <mailto:[e-mail]>
> >>>>>> 抄送: "'lihan'" <[e-mail]
> <mailto:[e-mail]>
> >>>>>> <mailto:[e-mail]>>, "Ad hoc MPLS-TP"
> >>>>>> <[e-mail] <mailto:[e-mail]>
> >>>>>> <mailto:[e-mail]>>,
> >>>>>> "[e-mail] <mailto:[e-mail]>
> >>>>>> <mailto:[e-mail]>" <[e-mail] <mailto:mpls-
> [e-mail]>
> >>>>>> <mailto:[e-mail]>>
> >>>>>> 日期: 2010年11月11日,周四,下午3:21
> >>>>>> Li Han, 你好！
> >>>>>>
> >>>>>> Thank you very much for this informative information.
> >>>>>>
> >>>>>>> http://wiki.tools.ietf.org/misc/mpls-tp/attachment/wiki/meeting-
> notes/CMCC%20implementation%20and%20consideration%20for%20MPLS-TP-01.pdf
> >>>>>>>
> >>>>>>> There are links from the meetings materials page
> >>>>>>> (http://wiki.tools.ietf.org/misc/mpls-tp/wiki/meeting-notes)
> >>>>>> and from the wiki
> >>>>>>> home page (http://wiki.tools.ietf.org/misc/mpls-tp/)
> >>>>>>
> >>>>>> I have a question about slide 3:
> >>>>>> the last bullet states: OAM: "based on Y.1731 and pre-
> >>>>>> standard G.8114"
> >>>>>>
> >>>>>> By "based on Y.1731" do you refer to
> >>>>>> draft-bhh-mpls-tp-oam-y1731
> >>>>>> and the CCSA standard that will soon be published?
> >>>>>>
> >>>>>> Thank you, Huub.
> >
> >
> >
> > --
> > *****************************************************************
> >                      我爱外点一七三一
> >
> 
> 
> -----BEGIN PGP SIGNATURE-----
> 
> iQEcBAEBAgAGBQJNCE8UAAoJEGmx2Mt/+Iw/fs4H/0cILw+AkS69D1jfWpx2fmK1
> LAP62cNtSujmyH+IZQJkEP7tmVJSmZxFfeSetcGa8Ww+BRcUaYTth69KxoEfYoea
> n/5CXdOI7n0xy/VWRvZh7iT8d6OghjJCcI9eZsD/MrnkR3RAvKzBAiQEoZb0HPVF
> JGzAFwCLtj8q3czwVVQcK3B0ZkRxKr5T8U8WIXRVgXJFXG4l8YVoSXaBvFH9muk7
> etmPOZj0WnlgoaIKnfRg2yPxImMRKQwojv8xopR+wFBbS8uuZdXGWGZ1Q41Hl6dz
> BrJPaAFPAc6lDY/lfbX8Tndq+gWwXVykB1gjfO+tr7nvEJ3Djpze3Pw0SJxkEG0=
> =48WW
> -----END PGP SIGNATURE-----
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls