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
