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

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

> -----Original Message-----
> From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On
> Behalf Of Ben Niven-Jenkins
> Sent: Thursday, December 16, 2010 3:58 AM
> To: HUANG Feng F
> Cc: mpls@ietf.org; Ad hoc MPLS-TP; BUSI ITALO; Huub van Helvoort; mpls-
> tp@ietf.org
> Subject: Re: [mpls-tp] [mpls] R: MPLS WG slides from CMCC
> 
> 
> On 16 Dec 2010, at 01:33, HUANG Feng F wrote:
> 
> > >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
> 
> _______________________________________________
> mpls-tp mailing list
> mpls-tp@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls-tp