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

From: Huub van Helvoort <[email-masked]>
Date: Tue, 14 Dec 2010 08:51:06 +0100

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: +86 10 63601087
>> MOBILE: 13501093385
>> *************************************************************************
>>
>>
>> --- 10年11月11日，周四, Huub van Helvoort <[email-masked]
>> <mailto:[email-masked]>> 写道：
>>
>>> 发件人: Huub van Helvoort <[email-masked]
>>> <mailto:[email-masked]>>
>>> 主题: Re: [mpls-tp] [mpls] MPLS WG slides from CMCC
>>> 收件人: [email-masked] <mailto:[email-masked]>
>>> 抄送: "'lihan'" <[email-masked]
>>> <mailto:[email-masked]>>, "Ad hoc MPLS-TP"
>>> <[email-masked] <mailto:[email-masked]>>,
>>> "[email-masked] <mailto:[email-masked]>" <[email-masked]
>>> <mailto:[email-masked]>>
>>> 日期: 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.

-- 
*****************************************************************
                          我爱外点一七三一

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Tue, 14 Dec 2010 19:09:16 +1100

Greetings Huub,

	I don't believe I do.  The requirements document just that, requirements, not solutions.  After RFC5860 was published, a few potential solutions to the requirements set out in RFC5860 were proposed, one of those is bhh.  Just because bhh supposedly responds to RFC5860 does not mean that it automatically becomes a standard.  The road to standardization has many corpses along it (look at the road to IPng, for example, or idr).  Just because it responds to RFC5860 does not change the fact that  a draft is just that, a draft.  That draft isn't even accepted as a working-group document yet.  

	Therefore, basing your technology around it is a dice roll.  I assume that CMCC has evaluated the risk of draft-bhh not becoming a standard and has decided that that risk is outweighed by whatever benefits CMCC will derive from deploying a solution based around draft-bhh, even if it does not become a standard.  If they have, then good on them, do what you need to do to keep your network running (I've ventured off the trodden path once or twice myself). 

	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.  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 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.

	Christopher

On 14Dec2010, at 18.51, Huub van Helvoort wrote:

> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp

---
李柯睿
Check my PGP key here:
https://www.asgaard.org/~cdl/cdl.asc

---

From: Huub van Helvoort <[email-masked]>
Date: Tue, 14 Dec 2010 11:40:48 +0100

Hej Christopher,

Please see in-line [hvh]

> I don't believe I do. The requirements document just that, requirements,
> not solutions. After RFC5860 was published, a few potential solutions to
> the requirements set out in RFC5860 were proposed, one of those is bhh.
> Just because bhh supposedly responds to RFC5860 does not mean that it
> automatically becomes a standard. The road to standardization has many
> corpses along it (look at the road to IPng, for example, or idr). Just
> because it responds to RFC5860 does not change the fact that a draft is
> just that, a draft. That draft isn't even accepted as a working-group
> 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
> that CMCC has evaluated the risk of draft-bhh not becoming a standard
> and has decided that that risk is outweighed by whatever benefits CMCC
> will derive from deploying a solution based around draft-bhh, even if it
> does not become a standard. If they have, then good on them, do what you
> need to do to keep your network running (I've ventured off the trodden
> path once or twice myself).

[hvh] another reason for the selection was the availability of
a solution.

> 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.

[hvh] because service providers outside of China also want to
use this solution they would like to make it an international
standard.

> 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.

M.v.h. Huub.

============
>>>> <mailto:[email-masked]>
>>>>> <mailto:[email-masked]>
>>>>> 收件人: [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>>>> 抄送: "'lihan'" <[email-masked] <mailto:[email-masked]>
>>>>> <[email-masked] <mailto:[email-masked]>
>>>>> <mailto:[email-masked]>>,
>>>>> "[email-masked] <mailto:[email-masked]>
>>>>> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 14 Dec 2010 17:17:25 +0000

Laying the history and various grievances related to draft-bhh aside as they are orthogonal to Chris' point.

Chris is right. The boiler plate of all Internet-Drafts states:

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

If someone (or some organisation) wishes to ignore that advice then it is a case of caveat emptor.

Some other SDO normatively referencing an Internet-Draft is not (IMO) justification to make the referenced draft Standards Track.

Having significant deployment(s) may make it worthwhile to document the technology in an RFC of some kind (but not by itself sufficient to justify a Standards Track RFC IMO)

WG consensus should be used to judge what documents the WG adopts & how they are then progressed.

Ben

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 14 Dec 2010 21:32:56 +0100

Skickat från min iPhone

> Please see in-line [hvh]
<snip>
> there were too many co-authors.
Huub,

You kbps as well as I do that this statement is not true.

It was pointed out to the authors of the document that it did not follow the guidelines for IDs, too many names on the front page. 
Further this was done in a context where it was not even asked that the document should be accepted as a wg doc!

/Loa

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Wed, 15 Dec 2010 16:16:03 +1100

Greetings,

Comments in line...

<snip>
<snip>
> [hvh] another reason for the selection was the availability of

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"

> 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.

> use this solution they would like to make it an international

As above
> [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

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 15 Dec 2010 07:13:30 +0100

Hi,

I agree with Loa….! The number of authors has never been a criteria to accept or oppose a document. 

I think the main issue with this draft is that (at least most of) the authors are not open to discuss it tool by tool and indicate for each specific tool, what are the issues with the solutions being developed (in the WG documents) that they are trying to address when presenting another solution.

If this is something technical, we should discuss it (tool by tool). I am sure that any technical issue can be resolved (probably even in the frame of the solution being developed in the WG document).  We want to develop quality standards and any technical discussion can contribute to it. 

I would like to encourage to review the WG documents and comment…

Best regards,

Nurit

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext [email-masked]
Sent: Tuesday, December 14, 2010 10:33 PM
To: Huub van Helvoort
Cc: [email-masked]; Ad hoc MPLS-TP; [email-masked]
Subject: Re: [mpls-tp] [mpls] MPLS WG slides from CMCC

Skickat från min iPhone

	Hej Christopher,
	
	Please see in-line [hvh]

<snip>

Huub,

/Loa

---

From: "BUSI, ITALO (ITALO)" <[email-masked]>
Date: Wed, 15 Dec 2010 09:28:27 +0100

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: [email-masked] [mailto:[email-masked]] Per conto di
> Christopher LILJENSTOLPE
> Inviato: mercoledì 15 dicembre 2010 6.16
> A: Huub van Helvoort
> Oggetto: Re: [mpls] [mpls-tp] MPLS WG slides from CMCC
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> Greetings,
> 
> Comments in line...
> 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"
> 
> >
> 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.
> 
> >
> 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
> 
> >
> > ============
> <mailto:[email-masked]>
> >>>>>>> http://wiki.tools.ietf.org/misc/mpls-tp/attachment/wiki/meeting-
> notes/CMCC%20implementation%20and%20consideration%20for%20MPLS-TP-01.pdf
> >>>>>>>
> -----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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 15 Dec 2010 09:32:28 +0100

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: [email-masked] [mailto:[email-masked]] On Behalf Of ext BUSI, ITALO (ITALO)
Sent: Wednesday, December 15, 2010 10:28 AM
To: Christopher LILJENSTOLPE; Huub van Helvoort
Cc: [email-masked]; Ad hoc MPLS-TP; [email-masked]
Subject: [mpls-tp] R: [mpls] MPLS WG slides from CMCC

Chris,

Thanks, Italo

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 15 Dec 2010 10:47:49 +0200

Italo,
One of the issues I've raised in Maastricht was lack of support for the trace route function that is explicitly required in 5860 (please see the minutes of the MPLS WG session at http://www.ietf.org/proceedings/78/minutes/mpls.txt, look for discussion of draft-fang-mpls-tp-oam-considerations). 

AFAIK, this issue has never been resolved. Or did I miss something?

Regards,
     Sasha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of BUSI, ITALO (ITALO)
Sent: Wednesday, December 15, 2010 10:28 AM
To: Christopher LILJENSTOLPE; Huub van Helvoort
Cc: [email-masked]; Ad hoc MPLS-TP; [email-masked]
Subject: [mpls-tp] R: [mpls] MPLS WG slides from CMCC

Chris,

Thanks, Italo

---

From: <[email-masked]>
Date: Wed, 15 Dec 2010 10:07:54 +0000

Hi Christopher,  I have several remarks in-line as there are some misconceptions here IMO: 

Christopher LILJENSTOLPE wrote 15 December 2010 05:16
<snipped>

> > 
> > [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.).

NH=> This is a key point, but not in the manner I believe you imply or may expect.  The reason for doing MPLS-TP in the first place was to produce a transparent transport network solution.  This, almost by definition, could not be a profile (sub-set of) MPLS as-is but needed new behaviours (eg an OOB CP) and, in particular, it should have paid very close attention to what transparency really means...because this is *the* fundamental DP service that a  transport network provides to its clients.

Now, as I have pointed out previously, transparency demands that the server treats all clients and each of their symbols equally...in particular the server must make no attempt to understand the meaning of and/or modify a client's symbols.  One less obvious consequence of this is that all client symbols MUST be treated equally wrt to 'urgency' and 'importance', as these requirements are only known to message/file/stream applications in the TOS layer network and a transport network is not TOS by definition => thus one cannot have meaningful multiple QoS (sic) classes in the connections of a truly transparent transport network.  However, when we look at MPLS-TP we see we have retained:

-	sublayering => which implies MPLS LSPs are treated differently to other clients.  Further, sublayering is quite unnecessary and creates problems in a transport network per se.  For example, one can have misconnectivity not only between different layers (which is something I suspect most folks have not looked at yet) but also between different sublayers (both intra and inter layer).  A further consequence of traditional MPLS sublayering is that the traffic units do not have consistent characteristic information, eg in true sublayering the label should always have a forwarding semantic...this is not true in MPLS and I suspect this problem will also apply to MPLS-TP.

-	PWs => carrying this mistake over into MPLS-TP is almost unforgivable IMO because it is well known as such and for many years.  PWs are a direct consequence of LDP LSP merging which is an obviously banned behaviour in a transport network.  In the MPLS LDP world a PW label is SA proxy to effect demerging since we cannot rely on having a cl-ps client layer, such as IP, where the SA is absolute/explicit in the client traffic unit.  Although 1-hop PWs are plain wrong in MPLS-TP, MS PWs are staggeringly so....since these create a new layer network above MPLS(TP) which now requires a ful set of its own layer network components, eg the PW layer network has its own 'unusual' (I'm trying to be polite) AII etc style of address structuring and signalling.

> I also am personally 
> concerned about re-use of existing technology and standards, 
> where possible.

NH=> Then you should agree with me at least wrt PWs...these don't use the same addressing, signalling, etc components as MPLS-TP....indeed they represent a wholly unnecessary layer network.

Having said that, the idea of re-use without thinking through all its consequences is a mistake in itself.  It is not optimal to try and make one thing try and do every job....we would not build a single type of ship as a river ferry, for carrying oil, for carrying ocean cruise passengers, to do a defence job, etc.  Networking technologies have efficacy limits of scale/scope.  Indeed the 'rule of minimum' in networks is: 3 modes (cl-ps/co-ps/co-cs), 3 external TOS layer network application adaptations (message/file/stream), 2 layer network relationships (client/server and peer-partition) and a BOS section layer that can modulate an EM wave (metallic/optical/radio media).  One needs all these basic components in a networking role that covers the full range of public and private networking services.

On can also observe that since the TOS and BOS layer networks must always be present in all network scenarios, then the real goal for operators is to optimise cost and reliability by removing as many other layer networks that lie between these as possible.  Now observe that MPLS and MPLS-TP are neither TOS nor BOS....so I can compellingly argue they are not even relevant to a transport role since they cannot modulate an EM wave directly and instead always require a proper (usually co-cs mode) BOS layer network technology under them that can....thus it is this layer network that is the transport network and not MPLS-TP....just a fact.

So we need to be quite clear when we talk of reuse wrt its context within the 'rule of minimum' components I pointed out above.  Aside=> I do actually agree with your remark below that there are too many protocols and complexities in networking these days, eg we don't need N different technologies in each network mode.  However, unnecessary complexity and cost can also be a consequence of not recognising the 'rule of minimum', and thus not recognising the efficient limits of scale/scope of one specific technology and trying to make it do things it is not suitable for.

  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"

NH=> If MPLS and MPLS-TP are considered as peers and need to 'interoperate' then we have clearly not understood what providing a transport network is about...I'll come back on this point later when considering peer interworking of non-TOS layer networks.
> 
> > 
> >> 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.
> > 
> 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).

NH=> I agree.  And the main reason is to provide peer level interconnects between different parties in the same layer network.  It is technically quite trivial to prove that the only networks that need this are TOS ones (ie ones that interfaces directly with external message/file/stream applications)....IP and the PSTN are like this, ATM could have been like this....all other technologies are not like this...and this includes MPLS(TP).  We can create peer interconnects in any non-TOS mode/technology if we want of course (and technology pressure group do push for this wrt their favoured technology).  Indeed we can do all manner of quite unnecessary/wrong things 'just because we can' (if the network mode allows it).  However, I would suggest we should try and be a little more wise in spotting such cases and not wasting our time/money on these unnecessary activities.  

>  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?

NH=> I remember it well, indeed I was responsible for some of the design aspects of the E1 frame (eg I designed CRC4 and its multiframe structure)....but this is something different to TOS E-NNI peer interconnects.  We *physically* have to connect even TOS layer networks together at a BOS section layer....but if you really grok what that means we are simply passing a binary bit stream transparently across the DP here, eg we must preserve bit ordering as we cannot make any judgement on the urgency/importance or meaning of higher layer client symbols (ie groups of bits) and there is no CP/MP interoperability.   These are not at all like the E-NNI peer interconnects of the TOS layer networks that define public services like the Internet and the PSTN.

However, I do agree that we should minimise the number of layer network variants (in fact the old co-cs PDH/SDH fixed hierarchy models are bad news, we should be moving to a digital wrapper approach here)...but this is quite different to requiring their peer interworking (being quite careful wrt to what this really means as I noted above).

regards, Neil
<snipped to end>

---

From: <[email-masked]>
Date: Wed, 15 Dec 2010 10:07:35 +0000

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

> From: [email-masked] 
> [mailto:[email-masked]] 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
> Subject: Re: [mpls-tp] R: [mpls] MPLS WG slides from CMCC
> 
> Hi,
> 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!
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of ext BUSI, ITALO (ITALO)
> > To be sure, this is a "emotional" issue for both sides.  However, 
> > there are outstanding concerns on this draft on multiple levels 
> > 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 
> 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.
> > >> draft-
> > bhh
> > >> based on an understanding that draft-bhh WOULD become a 
> standard, 
> > >> that would be an unfortunate misunderstanding.
> > >
> standards (and 
> > 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
> > >
> > >> 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
> > >
> > >> 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.
> > >
> > 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
> > 
> > >
> > > ============
> > >>>> 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
> > >>> draft-bhh-MPLS-TP-OAM-Y1731 provides a set of tools 
> that fits in a 
> > >>> larger toolbox with multiple tools.
> > >>>
> > >>> 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.
> > >>>
> > >>> ===================
> > >>>>> 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.
> > >>>>> Because Draft-bhh and relevant CCSA standard are based on 
> > >>>>> Y.1731, so
> > I
> > >>>>> <mailto:[email-masked]> <mailto:[email-masked]>> 写道：
> > >>>>>
> > >>>>>> <mailto:[email-masked]> <mailto:[email-masked]>>
> > >>>>>> <mailto:[email-masked]>
> > >>>>>> the last bullet states: OAM: "based on Y.1731 and 
> pre- standard 
> > >>>>>> G.8114"
> > >>>>>>

---

From: <[email-masked]>
Date: Wed, 15 Dec 2010 12:02:33 +0000

I seem to remember that pseudo wires were widely implemented as a "de facto" standard while still an internet draft. And this was the case for a considerable length of time.

Andy

Andy Reid
Chief Network Services Strategist
BT Innovate
                                                                                          
Office:	+44 (0)20 8726 3075
Mobile:	+44 (0)7917 025451
Fax :       +44 (0)1277 324015
Email:	[email-masked]
WWW:	http://www.bt.com/

This email contains BT information, which may be privileged or confidential.
It's meant only for the individual(s) or entity named above. If you're not the intended
recipient, note that disclosing, copying, distributing or using this information
is prohibited. If you've received this email in error, please let me know immediately
on the email address above. Thank you.
We monitor our email system, and may record your emails.

British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Ben Niven-Jenkins
> Sent: 14 December 2010 17:17
> To: Huub van Helvoort
> Subject: Re: [mpls] [mpls-tp] MPLS WG slides from CMCC
> 
> Laying the history and various grievances related to 
> draft-bhh aside as they are orthogonal to Chris' point.
> 
> If someone (or some organisation) wishes to ignore that 
> advice then it is a case of caveat emptor.
> 
> Some other SDO normatively referencing an Internet-Draft is 
> not (IMO) justification to make the referenced draft Standards Track.
> 
> Having significant deployment(s) may make it worthwhile to 
> document the technology in an RFC of some kind (but not by 
> itself sufficient to justify a Standards Track RFC IMO)
> 
> >> I don't believe I do. The requirements document just that, 
> >> requirements, not solutions. After RFC5860 was published, a few 
> >> potential solutions to the requirements set out in RFC5860 
> were proposed, one of those is bhh.
> >> automatically becomes a standard. The road to standardization has 
> >> many corpses along it (look at the road to IPng, for example, or 
> >> idr). Just because it responds to RFC5860 does not change the fact 
> >> that a draft is just that, a draft. That draft isn't even 
> accepted as 
> >> a working-group document yet.
> > 
> >> and has decided that that risk is outweighed by whatever benefits 
> >> CMCC will derive from deploying a solution based around draft-bhh, 
> >> even if it does not become a standard. If they have, then good on 
> >> them, do what you need to do to keep your network running (I've 
> >> ventured off the trodden path once or twice myself).
> > 
> > [hvh] because service providers outside of China also want 
> to use this 
> > solution they would like to make it an international standard.
> > 
> 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
> > 
> >> path to standardization in the IETF, especially if other operators 
> >> have a differing opinion of that draft proposal.
> > 
> >>>> 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 
> >>> The service provider can pick a selection of the tools for use in 
> >>>>> Actually, China Mobile has introduced 38,000 PTN 
> equipments based 
> >>>>> on pre-standard G.8114 in 2009. China Mobile will 
> introduce more 
> >>>>> 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
> >>>>> 
> >>>>> 
> >>>>>> <mailto:[email-masked]>" <[email-masked] 
> >>>>>> <mailto:[email-masked]> <mailto:[email-masked]>>
> standard

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 15 Dec 2010 12:24:26 +0000

Yes, however some context is important.

At the time there was clear WG consensus that the drafts were
approximately right, and an expectation by all concerned that any
changes that resulted from WG deliberations would need to be reflected
in the implementations.

Stewart

---

From: "HUANG Feng F" <[email-masked]>
Date: Wed, 15 Dec 2010 20:29:49 +0800

Hi,
    Why " We should aim for technical discussion and do it tool by tool!", providers need a total solution, do you want providers to update their implement products again and again?
B.R.
Feng

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon)
Sent: 2010年12月15日 16:32
To: BUSI ITALO; Christopher LILJENSTOLPE; Huub van Helvoort
Cc: [email-masked]; Ad hoc MPLS-TP; [email-masked]
Subject: Re: [mpls] [mpls-tp] R: MPLS WG slides from CMCC

Hi,
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext BUSI, ITALO (ITALO)
Sent: Wednesday, December 15, 2010 10:28 AM
To: Christopher LILJENSTOLPE; Huub van Helvoort
Cc: [email-masked]; Ad hoc MPLS-TP; [email-masked]
Subject: [mpls-tp] R: [mpls] MPLS WG slides from CMCC

Chris,

Thanks, Italo

> >> requirements,
> 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 
> 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.
> >> based on an understanding that draft-bhh WOULD become a standard, 
> away with "national" or "regional" standards.  However, even in those 
> T1/E1/J1 or the early days of SONET/SDH interworking?  How about the 
> those fairly constrained interoperation issues, there was damage done 
> 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 
> interest of it's constituents.  However, an SDO doing so, in a space 
> 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 
> resistance to the draft in question, if for no other reason than not 
> > this solution they would like to make it an international standard.
> 
> As above
> >
> >> the working group has never guaranteed that draft-bhh would become 
> 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
> 
> >
> > ============
> >>> draft-bhh-MPLS-TP-OAM-Y1731 provides a set of tools that fits in a 
> >>>>> introduce more than 110,000 PTN equipments based on draft-bhh-MPLS-TP-OAM-Y1731 in 2010.
> >>>>>> the last bullet states: OAM: "based on Y.1731 and pre- standard 
> >>>>>> G.8114"
> >>>>>>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 15 Dec 2010 12:46:05 +0000

Andy,

> I seem to remember that pseudo wires were widely implemented as a "de facto" standard while still an internet draft. And this was the case for a considerable length of time.

I think there is a subtle difference. 

PWs were deployed while still an Internet-Draft but those who did so, did so with the risk that the final RFC may not be the same as the Internet-Draft version they had deployed. Those operators that deployed PWs based on Internet-Drafts then have a choice to either remain on their pre-RFC deployment or migrate to an RFC-based deployment.

That is different IMO to a standard from an SDO referencing an Internet-Draft and the fact the reference exists being used as a justification for the Internet-Draft to be progressed as a standard.

The equivalent to the PW scenario here is, IMO, CCSA have referenced draft-bhh as part of one of their standards while draft-bhh is only an Internet-Draft. When the Standards Track solution(s) for MPLS-TP OAM are published as RFCs, CCSA have the choice of keeping their standard unchanged and accept that some component(s) of it may not be an "international standard" or migrating their specification to reference and use the Standards Track solution RFC(s).

Ben

---

From: "HUANG Feng F" <[email-masked]>
Date: Thu, 16 Dec 2010 09:33:58 +0800

Hi,
  
<snipped>
 
> *_I expect that if one presents alternative solutions, it first shows 
> the technical issues it has with the solution the WG is working on and 
> if it has concerns why his concerns cannot be solved out within the 
> scope of the solution the WG is working on. _*
 
Looking at the date of initial publishing...
draft-bhh is the first draft, so all other drafts are alternative...
and as Nurit writes *they* should be showing the technical issues...
 
>The WG is currently developing solutions for the tools…some of them are already in a very good shape…
 
This solution can't satisfy transport requirement, the mpls-tp demo in mpls2010 shows protection switch trigged by draft-cc-cv-rdi is less than 50ms? can Nurit prove it?
by the way, you can track the poll email in ietf mpls wg, when draft-xxx-bfd is polled as workgroup doc, there is no censuses in mpls group!

> *_If this is a technical concern, please refer to my proposal_*! 
> Review the documents the WG is working on and comment! Otherwise it 
> seems a waste of time and we would better focus on progressing the 
> developments of the solutions the WG is working on.

Yes, I waited for Nurit's tecnincal comments for a long time. 
 
B.R.
Feng

________________________________

From: Sprecher, Nurit (NSN - IL/Hod HaSharon) [mailto:[email-masked]] 
Sent: 2010年12月15日 20:45
To: HUANG Feng F; BUSI ITALO; Christopher LILJENSTOLPE; Huub van Helvoort
Cc: [email-masked]; Ad hoc MPLS-TP; [email-masked]
Subject: RE: [mpls] [mpls-tp] R: MPLS WG slides from CMCC

Hi,

The solution Y.1731 proposes for the CC function is NOT the same as proposed to packet loss, although they appear in the same document. Right? And the same for the other set of tools....

Hence the discussion has to be taken tool by tools....and it really does not matter if the set of tools appear to be in the same document or in a set of documents that all together provide the entire set of tools....

I have to admit that I find it very strange…since day 1 we called for this technical discussion but no one that proposes an alternative has done so…and from some unclear reasons the main objection is to do it tool by tool….

The WG is currently developing solutions for the tools…some of them are already in a very good shape…

I expect that if one presents alternative solutions, it first shows the technical issues it has with the solution the WG is working on and if it has concerns why his concerns cannot be solved out within the scope of the solution the WG is working on. 

If this is a technical concern, please refer to my proposal! Review the documents the WG is working on and comment! Otherwise it seems a waste of time and we would better focus on progressing the developments of the solutions the WG is working on.

Best regards,

Nurit

-----Original Message-----
From: ext HUANG Feng F [mailto:[email-masked]] 
Sent: Wednesday, December 15, 2010 2:30 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); BUSI ITALO; Christopher LILJENSTOLPE; Huub van Helvoort
Cc: [email-masked]; Ad hoc MPLS-TP; [email-masked]
Subject: RE: [mpls] [mpls-tp] R: MPLS WG slides from CMCC

Hi,

B.R.

Feng

-----Original Message-----

Sent: 2010年12月15日 16:32

Hi,

Best regadrs,

Nurit

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 16 Dec 2010 11:57:33 +0000

> by the way, you can track the poll email in ietf mpls wg, when draft-xxx-bfd is polled as workgroup doc, there is no censuses in mpls group!

The decision has been made and the chairs have judged consensus as per the IETF's operating procedure, if folks think some injustice was done there is a general appeals process although my opinion is that it doesn't need to invoked in this case.

Personally, I don't think operators are so naive that they will deploy a solution purely because it is standardised and so if draft-bhh is a superior solution and the WG solution does not meet the needs of those operators then they will deploy and use it regardless of its standardisation status. In other words, regardless of what IETF (or any other SDO) says is the "standard" it is still up to the market to decide.

However, in the meantime I don't see repeatedly trying to re-discuss a decision that has already been made without bringing significant new technical arguments to the table as a productive use of our time. It is unlikely to reverse the previous decision and it expends a lot of cycles we could use to improve the WG selected solutions.

So can we draw a line under this discussion and concentrate on progressing the existing MPLS-TP solutions that are WG documents?

Regards
Ben

---

From: John E Drake <[email-masked]>
Date: Thu, 16 Dec 2010 05:15:33 -0800

Um, right.  It is fun though to read everyone putting their own spin on WG consensus and the IETF process.  In particular, the email to which you were replying, although largely incoherent, has a certain perverse charm.

But then I also enjoy watching paint dry.

Maybe it's cultural - is endless whining an ITU thing? 

Sent from my iPhone

> From: [email-masked] [mailto:[email-masked]] On
> Sent: Thursday, December 16, 2010 3:58 AM
> To: HUANG Feng F
> Cc: [email-masked]; Ad hoc MPLS-TP; BUSI ITALO; Huub van Helvoort; mpls-
> [email-masked]
> Subject: Re: [mpls-tp] [mpls] R: MPLS WG slides from CMCC
> 
> 
> > >The WG is currently developing solutions for the tools...some of them
> are already in a very good shape...
> >
> > This solution can't satisfy transport requirement, the mpls-tp demo
> in mpls2010 shows protection switch trigged by draft-cc-cv-rdi is less
> than 50ms? can Nurit prove it?
> > by the way, you can track the poll email in ietf mpls wg, when draft-
> xxx-bfd is polled as workgroup doc, there is no censuses in mpls group!
> 
> The decision has been made and the chairs have judged consensus as per
> the IETF's operating procedure, if folks think some injustice was done
> there is a general appeals process although my opinion is that it
> doesn't need to invoked in this case.
> 
> Personally, I don't think operators are so naive that they will deploy
> a solution purely because it is standardised and so if draft-bhh is a
> superior solution and the WG solution does not meet the needs of those
> operators then they will deploy and use it regardless of its
> standardisation status. In other words, regardless of what IETF (or any
> other SDO) says is the "standard" it is still up to the market to
> decide.
> 
> However, in the meantime I don't see repeatedly trying to re-discuss a
> decision that has already been made without bringing significant new
> technical arguments to the table as a productive use of our time. It is
> unlikely to reverse the previous decision and it expends a lot of
> cycles we could use to improve the WG selected solutions.
> 
> So can we draw a line under this discussion and concentrate on
> progressing the existing MPLS-TP solutions that are WG documents?
> 
> Regards
> Ben
>

---

From: Vivien Sterling <[email-masked]>
Date: Fri, 17 Dec 2010 00:36:17 +0800

Hi Ping,

I should say it's not interesting at all to follow this thread but I'm
confused by your judgement below...

    The WG is currently developing solutions for the tools…some of them are
> already in a very good shape…
>
>>
>> This solution can't satisfy transport requirement, the mpls-tp demo in
>> mpls2010 shows protection switch trigged by draft-cc-cv-rdi is less than
>> 50ms? can Nurit prove it?
>> by the way, you can track the poll email in ietf mpls wg, when
>> draft-xxx-bfd is polled as workgroup doc, there is no censuses in mpls
>> group!
>>
>>
>
> What's the point here? If a provider likes one particular solution very
> much, it can simply put it in the RFI/RFP. Why making the IETF standard
> process a beauty contest?
>
> Curious, are the service providers so insecure of themselves that they must
> have the standardization rubber stamps on this?
>
> IMHO, one of reasons for the success of PWE3 is that a group of operators
> and engineers have taken the chance and worked out a pragmatic solution, and
> have given it a try in the real world. The rest of industry simply followed.
> IETF has been the forum for people to work out the kinks. This is how IETF
> supposes to work. Why can't we follow the same model here? Storming into
> meetings, waving company badges and shouting injustice are not the way to
> get things done.
>

Isn't the MPLS-TP demo mentioned by Haung and the deployment of
some operators a proof of " a group of operators and engineers have taken
the chance and worked out a pragmatic solution, and have given it a try in
the real world"?

What's your point here? What "same model" are you trying to say? I can not
fully understand.

-- 
Cheers,
Vivien

2010/12/16 Ping Pan <[email-masked]>

>
>
> 2010/12/15 HUANG Feng F <[email-masked]>
>
>  Hi,
>>
>> <snipped>
>>
> This logic does not make sense. The goal is to identify the most practical
> and sound solution from many for standardization. Is the publishing date
> that relevant?
>
>
>> This solution can't satisfy transport requirement, the mpls-tp demo in
>> mpls2010 shows protection switch trigged by draft-cc-cv-rdi is less than
>> 50ms? can Nurit prove it?
>> by the way, you can track the poll email in ietf mpls wg, when
>> draft-xxx-bfd is polled as workgroup doc, there is no censuses in mpls
>> group!
>>
>>
>
> What's the point here? If a provider likes one particular solution very
> much, it can simply put it in the RFI/RFP. Why making the IETF standard
> process a beauty contest?
>
> Curious, are the service providers so insecure of themselves that they must
> have the standardization rubber stamps on this?
>
> IMHO, one of reasons for the success of PWE3 is that a group of operators
> and engineers have taken the chance and worked out a pragmatic solution, and
> have given it a try in the real world. The rest of industry simply followed.
> IETF has been the forum for people to work out the kinks. This is how IETF
> supposes to work. Why can't we follow the same model here? Storming into
> meetings, waving company badges and shouting injustice are not the way to
> get things done.
>
> Let's just move on.
>
> 2 cents,
>
> Ping
>
>
>>
>>  ------------------------------
>> *From:* Sprecher, Nurit (NSN - IL/Hod HaSharon) [mailto:
>> [email-masked]]
>> *Sent:* 2010年12月15日 20:45
>> *To:* HUANG Feng F; BUSI ITALO; Christopher LILJENSTOLPE; Huub van
>> Helvoort
>>
>> *Cc:* [email-masked]; Ad hoc MPLS-TP; [email-masked]
>> *Subject:* RE: [mpls] [mpls-tp] R: MPLS WG slides from CMCC
>>
>>  Hi,
>>
>> The solution Y.1731 proposes for the CC function is NOT the same as
>> proposed to packet loss, although they appear in the same document. Right?
>> And the same for the other set of tools....
>>
>> Hence the *discussion* has to be taken *tool by tools*....and it really
>> does not matter if the set of tools appear to be in the same document or in
>> a set of documents that all together provide the entire set of tools....
>>
>> I have to admit that I find it *very strange*…since day 1 we called for
>> this technical discussion but no one that proposes an alternative has done
>> so…and from some unclear reasons the main objection is to do it tool by
>> tool….
>>
>> *I expect that if one presents alternative solutions, it first shows the
>> technical issues it has with the solution the WG is working on and if it has
>> concerns why his concerns cannot be solved out within the scope of the
>> solution the WG is working on. *
>>
>> *If this is a technical concern, please refer to my proposal*! Review the
>> documents the WG is working on and comment! Otherwise it seems a waste of
>> time and we would better focus on progressing the developments of the
>> solutions the WG is working on.
>>
>> Best regards,
>>
>> Nurit
>>
>>
>>
>>
>>
>>     Why " We should aim for technical discussion and do it tool by tool!",
>> providers need a total solution, do you want providers to update their
>> implement products again and again?
>>
>> B.R.
>>
>> Feng
>>
>>
>>
>>
>>
>> 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!
>>