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

[<[e-mail]>]

I'd suggest a slightly different approach....

What we should do is define/agree the important arch principles we should be striving for and then check the components (be they DP, CP or MP based) against these.  This does assume we know what the right arch principles are of course, and I'm not sure we are all on the same page here.  Further, it is always a tough issue to admit where past mistakes have been made and correct these (eg a long time ago I thought co-ps mode AIS was a good idea, but I don't now that I have properly understood the arch principles of what this OAM DP message represents).  Again this assumes we can recognise those mistakes, though this itself may not always be true.

Aside=> There are many points made by Christopher below that I would take issue with.  I'll post a response shortly.

regards, Neil

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Sprecher, 
> Nurit (NSN - IL/Hod HaSharon)
> Sent: 15 December 2010 08:32
> To: ext BUSI, ITALO (ITALO); Christopher LILJENSTOLPE; Huub 
> van Helvoort
> Cc: [e-mail]; Ad hoc MPLS-TP; [e-mail]
> Subject: Re: [mpls-tp] R: [mpls] MPLS WG slides from CMCC
> 
> Hi,
> I think at the current status, we should do it vice versa...
> Any one that wants to push for another solution than 
> currently being defined by the WG, should present the 
> technical issues it has with the current proposals when he 
> present alternative ones!
> We should aim for technical discussion and do it tool by tool!
> Best regadrs,
> Nurit
>  
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of ext BUSI, ITALO (ITALO)
> Sent: Wednesday, December 15, 2010 10:28 AM
> To: Christopher LILJENSTOLPE; Huub van Helvoort
> Cc: [e-mail]; Ad hoc MPLS-TP; [e-mail]
> Subject: [mpls-tp] R: [mpls] MPLS WG slides from CMCC
> 
> 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/meetin
> > >>>>>>> g-
> > 
> notes/CMCC%20implementation%20and%20consideration%20for%20MPLS-TP-01.p
> > df
> > >>>>>>>
> > >>>>>>> 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
> _______________________________________________
> 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
>