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

[Shane Amante <shane at castlepoint.net>]

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.


> 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.


> 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.


> 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.

-shane (speaking only for himself, not as co-chair)
_______________________________________________
mpls mailing list
mpls at ietf.org
https://www.ietf.org/mailman/listinfo/mpls