Re: [mpls] [PWE3] [mpls-tp] FW: Changes to PW ACH Channel Typeallocationpolicy

[Maarten Vissers <maarten.vissers at huawei.com>]

Sharam,

I agree.

In my understanding the PW ACH Channel Type provides the same function as
the EtherType in Ethernet networks. IEEE provides a means to buy an
EtherType codepoint (http://standards.ieee.org/regauth/ethertype/eth.txt).
The requesting organisation can decide to keep their associated application
private ("Protocl unavailable.") or to make it public.

As far as I understand this EtherType allocation policy is an industry
standard and could be copied for PW ACH Channel Type allocation policy.

Regards,
Maarten

-----Original Message-----
From: pwe3-bounces at ietf.org [mailto:pwe3-bounces at ietf.org] On Behalf Of
Shahram Davari
Sent: 02 October 2008 19:18
To: Thomas D. Nadeau; 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: Re: [PWE3] [mpls-tp] FW: Changes to PW ACH Channel
Typeallocationpolicy

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