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