Re: [mpls] [Bulk] Re: [PWE3] [mpls-tp] FW: Changes to PW ACH Channel Type allocationpolicy

["Shahram Davari" <davarish at yahoo.com>]

By the way I suggest using more polite language.

-shahram

-----Original Message-----
From: pwe3-bounces at ietf.org [mailto:pwe3-bounces at ietf.org] On Behalf Of
Thomas D. Nadeau
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; pwe3 at ietf.org; BUSI ITALO
Subject: [Bulk] Re: [PWE3] [mpls-tp] 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