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

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 <ping@pingpan.org>

>
>
> 2010/12/15 HUANG Feng F <Feng.f.Huang@alcatel-sbell.com.cn>
>
>  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...
>>
>>
>
> 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?
>
>
>>  >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.
>
> Let's just move on.
>
> 2 cents,
>
> Ping
>
>
>>
>> > *_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:
>> nurit.sprecher@nsn.com]
>> *Sent:* 2010年12月15日 20:45
>> *To:* HUANG Feng F; BUSI ITALO; Christopher LILJENSTOLPE; Huub van
>> Helvoort
>>
>> *Cc:* mpls@ietf.org; Ad hoc MPLS-TP; mpls-tp@ietf.org
>> *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:Feng.f.Huang@alcatel-sbell.com.cn]
>> Sent: Wednesday, December 15, 2010 2:30 PM
>> To: Sprecher, Nurit (NSN - IL/Hod HaSharon); BUSI ITALO; Christopher
>> LILJENSTOLPE; Huub van Helvoort
>> Cc: mpls@ietf.org; Ad hoc MPLS-TP; mpls-tp@ietf.org
>> Subject: RE: [mpls] [mpls-tp] R: MPLS WG slides from CMCC
>>
>>
>>
>> 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: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of
>> Sprecher, Nurit (NSN - IL/Hod HaSharon)
>>
>> Sent: 2010年12月15日 16:32
>>
>> To: BUSI ITALO; Christopher LILJENSTOLPE; Huub van Helvoort
>>
>> Cc: mpls@ietf.org; Ad hoc MPLS-TP; mpls-tp@ietf.org
>>
>> Subject: Re: [mpls] [mpls-tp] R: 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
>>
>>
>> _______________________________________________
>> mpls mailing list
>> mpls@ietf.org
>> https://www.ietf.org/mailman/listinfo/mpls
>>
>>
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>
>