Re: [mpls] [PWE3] [mpls-tp] FW: Changes to PW ACH ChannelType allocationpolicy

["Eric Gray" <eric.gray at ericsson.com>]

Luca,

	The practical reality is that expert review gives the 
designated "expert" (or experts) the same level of control 
of assignment as IESG review gives ADs over RFC publication.
While it is possible to push something through against the
"wishes" of an expert (who does in fact have more than the
ability to "advise" the requesting individual/organization),
the process can be quite confrontational and tedious.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: mpls-bounces at ietf.org [mailto:mpls-bounces at ietf.org] On 
> Behalf Of Luca Martini
> Sent: Thursday, October 02, 2008 2:17 PM
> To: Shahram Davari
> Cc: Thomas D. Nadeau; mpls at ietf.org; BOCCI Matthew; 
> ccamp at ietf.org; l2vpn at ietf.org; pwe3 at ietf.org; BUSI ITALO; 
> mpls-tp at ietf.org
> Subject: Re: [mpls] [PWE3] [mpls-tp] FW: Changes to PW ACH 
> ChannelType allocationpolicy
> 
> Shahram,
> the point of expert review is not to prevent vendor specific OAM 
> methods. It is to prevent duplication, and guide implementors in the 
> right direction.
> For example , if somebody needs a new PW type , for a very vendor 
> specific protocol , say Apollo DDS ( I was the last recorded user of 
> that ;-) ), but asks for an ACH type instead , the expert can 
> advise to 
> use a new pw type. In the end there is no enforcement method, so any 
> vendor can do anything they want. The only part we can do 
> here , is have 
> some sane documentation of the methods we put in the registry. ( 
> documentation could be as short a a line , or as long as a draft )
> 
> Luca
> 
> 
> Shahram Davari wrote:
> > No one asked for IETF rubber stamping. I asked for a 
> mechanism (code point assignment) that easily implement 
> vendor specific methods. I don't see any reason why IETF 
> should review and approve a vendor specific method. If IETF 
> doesn't want to see any vendor specific method, then it 
> doesn't need to allocate any code points. However, if IETF 
> wants to encourage vendor specific protocols then it must do 
> so in a way that makes it easy for vendors to use it.
> >
> > -Shahram
> >
> >
> > -----Original Message-----
> > From: Thomas D. Nadeau [mailto:tom.nadeau at bt.com] 
> > Sent: October-02-08 12:44 PM
> > To: Shahram Davari; Shane Amante
> > Cc: l2vpn at ietf.org; mpls at ietf.org; BOCCI Matthew; 
> ccamp at ietf.org; mpls-tp at ietf.org; Vishwas Manral; 
> pwe3 at ietf.org; BUSI ITALO
> > Subject: Re: [mpls-tp] [PWE3] FW: Changes to PW ACH Channel 
> Type allocationpolicy
> >
> >
> >
> >     I agree with %100 of Shane's comments. One bit to add below:
> >
> >   
> >> Hi Shane,
> >>
> >> Please see my response in-line.
> >>
> >> Best regards,
> >> Shahram
> >>
> >>
> >> -----Original Message-----
> >> From: Shane Amante [mailto:shane at castlepoint.net]
> >> Sent: October-02-08 10:43 AM
> >> To: Shahram Davari
> >> Cc: BUSI ITALO; Vishwas Manral; l2vpn at ietf.org; BOCCI 
> Matthew; mpls at ietf.org;
> >> ccamp at ietf.org; mpls-tp at ietf.org; pwe3 at ietf.org
> >> Subject: Re: [mpls-tp] [PWE3] FW: Changes to PW ACH Channel Type
> >> allocationpolicy
> >>
> >> Shahram Davari wrote:
> >>     
> >>> Hi,
> >>>
> >>> I also prefer the method that Wishwas proposed. This has 
> many advantages:
> >>>
> >>> 1) Allows vendors to not expose their proprietary 
> techniques to their
> >>> competitors.
> >>>       
> >>  From the POV of an operator, this is actually a 
> substantial disadvantage.
> >>
> >> [Shahram] OTOH it encourages more innovation and 
> differentiation by vendors.
> >>     
> >
> >     That is hogwash. Customers encourage vendors to 
> innovate not standards
> > bodies. Standards bodies help encourage and foster 
> interoperability of a
> > common specification. The latter is the important point 
> Shane is making (as
> > am I and others who are the customers in this equation). We 
> don't want to
> > encourage proprietary implementations for the sake of proprietary
> > implementations; we want to encourage them to ultimately 
> interoperate on a
> > common specification. However, if your goal as a vendor is to create
> > proprietary implementations you are free to do so, but you 
> do not need the
> > IETF unless you are looking for some sort of rubber stamp 
> of approval.
> >
> >     --Tom
> >
> >
> >   
> >   
> >>> 2) reduces the load of reviewing by IETF and PWE3
> >>>       
> >> OTOH, the benefit of such reviews by the IETF and PWE3 is when
> >> "commonality" among similar applications are discovered they can be
> >> standardized, rather kept proprietary.
> >>
> >> [Shahram] Not if the inventing vendor is not willing to do so.
> >>
> >>
> >>     
> >>> 3) results a faster time to market, since no expert 
> review will be needed
> >>>       
> >> True, to some extent.  But, IMHO, I would much rather see 
> a *slightly*
> >> slower process involving a careful expert review and/or 
> IETF consensus
> >> to make sure we're not: a) unnecessarily duplicating work; 
> and, b) at
> >> the same time, encouraging more standards-based approach.
> >>
> >>
> >>     
> >>> 4) provides more codepoint space that the ACH channel type
> >>>       
> >> This is false.  There is no shortage on ACH channel types today.
> >> [Shahram] You are correct. 16-bit is sufficient enough.
> >>
> >>
> >>     
> >>> 5) only one VCCV ACH channel type needs to be configured 
> in each box for
> >>> vendor specific filtering
> >>>
> >>> The 2nd method has the first 3 advantages only, and the 
> first method has none
> >>> of these advantages.
> >>>       
> >> Also, let's take a step back here.  Wasn't the whole point with the
> >> joint ITU-T/IETF effort surrounding MPLS-TP to create an 
> environment in
> >> which MPLS-TP could seamlessly interoperate within (existing) MPLS
> >> environments?  I thought a fundamental part of that work 
> is striving
> >> towards creating a *standards-based* MPLS-TP data-plane, 
> OAM, signaling,
> >> etc. mechanisms.  IMO, Vishwas' proposal and Matthew's 
> proposal #2 seems
> >> to run contrary to that goal.
> >>
> >> [Shahram] off course we should all encourage standards 
> methods. But we should
> >> provide a fast and reasonable procedure for vendor 
> specific protocols that
> >> don't affect interoperability. I worry that in first 
> method competitors may
> >> vote down code point requests for commercial reasons.
> >>
> >> -shane (speaking only for himself, not as co-chair)
> >>
> >>
> >>
> >>     
> >
> >
> >
> >
> > _______________________________________________
> > pwe3 mailing list
> > pwe3 at ietf.org
> > https://www.ietf.org/mailman/listinfo/pwe3
> >   
> 
> _______________________________________________
> mpls mailing list
> mpls at ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
> 
_______________________________________________
mpls mailing list
mpls at ietf.org
https://www.ietf.org/mailman/listinfo/mpls