Subject: Re: [mpls-tp] FW: [PWE3] Changes to PW ACH Channel Type allocation policy

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 30 Sep 2008 12:34:16 -0400

While a bit slower than the newer approach proposed, I still prefer the
existing mechanism requiring expert review and IETF consensus.  I don't see
why having to justify the case for a new code point allocation is such a
cumbersome process. The only trouble point I see is where folks might want
to allocate proprietary extension points, in which case consensus may be
difficult to arrive at. In these cases, it might be useful to carve out some
sub-set of the space for such allocations and only require expert review
without IETF consensus for this allocation.

    --Tom

On 9/30/08 12:23 PM, "BOCCI Matthew" <[email-masked]>
wrote:

> The PWE3 chairs would like feedback on proposed changes to the
> allocation policy for the PW ACH codepoint registry. Please see the
> email below, and provide any feedback copying the PWE3 list.
> 
> Best regards
> 
> Matthew
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> BOCCI Matthew
> Sent: 25 September 2008 16:36
> To: [email-masked]
> Subject: [PWE3] Changes to PW ACH Channel Type allocation policy
> 
> 
>  
> The current IANA allocation policy for the PW associated channel type
> registry is by IETF consensus. This policy was chosen in RFC 4385 based
> on WG consensus that since the associated channel exists in the data
> path, and VCCV packets are typically processed by the control processor
> on many PEs, it was prudent for the IETF to maintain strict control over
> what types of channels were allocated and to ensure that they complied
> to the PWE3 architecture.
> 
> However, a need has been identified to provide a more flexible approach
> to allocating code points for VCCV channel types. This has partly arisen
> from the MPLS-TP work, where MPLS would be deployed in a transport
> network and where a much wider range of applications for the PW
> associated channel is envisioned, and partialy from a desire to extend
> the OAM capabilities for regular MPLS. We can support MPLS-TP and
> general MPLS apps with the current policy which requires standards
> action.
> 
> However we are receiving requests to allow proprietary OAM and signaling
> protocols to be used in transport applications, and need to decide on
> the best way forward. We considered providing extension mechanisms
> within the standards track protocols, but believe that the standards
> track protocols would be much cleaner if the proprietary protocols ran
> on their own ACH code points.
> 
> Note that we are talking about vendor protocols here. Other SDOs would
> be required to publish an RFC and would only be allocated an ACH through
> Standards Action.
> 
> There are two ways to address the requests for proprietary protocol ACH
> code points:
> 
> 1) Allow a range of the associated channel type registry to be allocated
> through expert review. Guidelines would be provided for the expert
> reviewer to guide them in assessing the request, which would have to be
> made in the form of an internet draft, while making sure that the
> request is dealt with in a timely and fair manner. This policy would
> include hurdles with regard to security, congestion etc that would be
> derived from those specified in the VCCV design.
> 
> 2) Allow a range of the associated channel type registry to be allocated
> on a first-come-first-served basis. This does not provide the level of
> control that expert review provides, but this is balanced to some degree
> by the fact that the VCCV channel type is indicated in the data path,
> and so a PE can choose to discard or rate limit VCCV packets on an
> unrecognised associated channel.
> 
> Any change to the ACH allocation policy would be outlined in the GE-ACH
> draft, which would update RFC 4385.
> 
> We would appreciate feedback on the list as to which approach the WG
> prefers.
> 
> Regards,
> 
> Stewart and Matthew
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 01 Oct 2008 10:34:29 -0400

Hi Mathew,

I support option 2, since a terminating node that doesn't understand the VCCV channel type can always drop it. This would allow more innovation and faster time to market.

Best regards,
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of BOCCI Matthew
Sent: September-30-08 12:23 PM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [PWE3] FW: Changes to PW ACH Channel Type allocation policy

Best regards

Matthew

-----Original Message-----

Regards,

Stewart and Matthew

---

From: "Vishwas Manral" <[email-masked]>
Date: Wed, 1 Oct 2008 21:17:22 +0530

Hi Matthew,

I would like to propose another option if it is for vendor proprietery
"Channel Type" values in the ACH header. With the number of values of
the channel type being limited and the number of vendors actually a
lot, I would think something in the lines of what the draft below
talks about may make sense:

http://tools.ietf.org/draft-ietf-isis-proprietary-tlv-00

The idea is give a channel type value, for vendor specific
implemntations and further define the structure of the next header
value for such a "channel type" to actually have a Vendor OUI value.

This will allow for unlimited innovation without affecting
interoperability, unlike the other options you have mentioned.

Thanks,
Vishwas

On 10/1/08, Shahram Davari <[email-masked]> wrote:
> Hi Mathew,
>
> I support option 2, since a terminating node that doesn't understand the
> VCCV channel type can always drop it. This would allow more innovation and
> faster time to market.
>
> Best regards,
> Shahram
>
>

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 01 Oct 2008 17:12:51 +0100

Vishwas

We have 65000 units of innovation, and that is without expanding into 
the next
octet which is currently reserved for expansion.

Given that we have not yet run out of UDP ports I don't think we need to 
be concerned
in that regard.

The reason that we have been very cautious in the past is because we don't
want anything that goes on in the ACH straying into the dataplane - for
example  no one using the ACH as a PID and requiring the forwarder to look
at it.

Then when we designed VCCV we had all sorts of concerns over traffic volume
and security of traffic delivered straight to the management processor.

We were very cautious when we standardized the ACH mechanism, there is a
good case for maintaining that caution until we see what people are going
to use it for.

Stewart (speaking as myself)

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 01 Oct 2008 13:21:28 -0400

Stewart,

        I agree with you %100.  It is not the time of approval that will be
the issue in the long run -- I would think an expert review assignment could
be serviced in a couple of weeks to a month (max) anyway. IMHO the real
issue is in how the assignments get implemented later, and precisely as you
say, in the data plane.  The affects here unintentional or intentional, can
be disastrous.

    --Tom (Speaking as my British alter-ego)

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 1 Oct 2008 13:52:47 -0400

I also agree on #1.

Cheers,
Andy

On Tue, Sep 30, 2008 at 3:19 PM, Shah, Himanshu <[email-masked]> wrote:
> I support proposal one - funnelling through expert review of the draft
> proposal.
> And yes turnaround must be quick...
>
> /himanshu
>
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of BOCCI Matthew
> Sent: Tuesday, September 30, 2008 12:23 PM
> Subject: [mpls-tp] FW: [PWE3] Changes to PW ACH Channel Type
> allocationpolicy
>

---

From: Shane Amante <[email-masked]>
Date: Wed, 1 Oct 2008 22:01:48 -0600

Matthew,

Speaking as an operator, (L2VPN WG co-chair hat off), I would also  
prefer the existing mechanism that's already in place: expert review  
and IETF consensus.  After all, there are significant benefits to  
standards-based OAM and signaling protocols.  On the other hand, some  
people may still have a legitimate need to do uncommon things that  
aren't considered mainstream.  In that case, I would rather see a  
(small) subset of codepoints allocated for expert review with no IETF  
consensus (Option #1 below).

-shane

---

From: "BUSI ITALO" <[email-masked]>
Date: Thu, 2 Oct 2008 09:00:55 +0200

I also support option 2

The requirement is to allow a vendor to implement proprietary innovative
features.

Italo

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Shahram Davari
> Sent: Wednesday, October 01, 2008 4:34 PM
> To: BOCCI Matthew; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [PWE3] FW: Changes to PW ACH Channel Type 
> allocation policy
> 
> Hi Mathew,
> 
> I support option 2, since a terminating node that doesn't 
> understand the VCCV channel type can always drop it. This 
> would allow more innovation and faster time to market.
> 
> Best regards,
> Shahram
> 
>

---

From: "BUSI ITALO" <[email-masked]>
Date: Thu, 2 Oct 2008 09:11:27 +0200

Vishwas,

I think this is a good idea

Both this proposal and option 2 (fist-come-first-served) meet the
requirements to make the ACH mechanism extensible.

The advantage of this approach is that we do not have to worry about how
many codepoints we need to allocate for proprietary extensions: we just
need one codepoint.

Italo

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Vishwas Manral
> Sent: Wednesday, October 01, 2008 5:47 PM
> To: Shahram Davari
> Cc: [email-masked]; BOCCI Matthew; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [mpls-tp] [PWE3] FW: Changes to PW ACH Channel 
> Type allocationpolicy
> 
> Hi Matthew,
> 
> understand the

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 02 Oct 2008 08:10:56 +0100

Italo

How does option 1 prevent a vendor implementing proprietary innovative 
features?

Stewart

---

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 2 Oct 2008 12:51:27 +0530

Hi Italo,

I agree and that was my exact aim.

The other added advantage is that there are no interoperability issues
and no bottlenecks of assignments for a particular type.

Thanks,
Vishwas

---

From: Loa Andersson <[email-masked]>
Date: Thu, 02 Oct 2008 10:36:08 +0200

All,

I support option 1.

/Loa

BOCCI Matthew wrote:
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                           [email-masked]

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 02 Oct 2008 08:13:06 -0400

> requirements to make the ACH mechanism extensible.

    How does the existing mechanism not meet the requirement to make an ACH
mechanism extensible?

    --Tom

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 02 Oct 2008 08:58:07 -0400

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. 
2) reduces the load of reviewing by IETF and PWE3 
3) results a faster time to market, since no expert review will be needed
4) provides more codepoint space that the ACH channel type
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.

Best regards,
Shahram

-----Original Message-----
From: Thomas D. Nadeau [mailto:[email-masked]] 
Sent: October-02-08 8:13 AM
To: BUSI ITALO; Vishwas Manral; Shahram Davari
Cc: [email-masked]; BOCCI Matthew; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] [PWE3] FW: Changes to PW ACH Channel Type allocationpolicy

    --Tom

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Thu, 2 Oct 2008 09:53:30 -0400

Agree- and with the strong wording that option #1 is not for
SDOs/Forums. Option 2 (or the 3rd option being discussed), may be viewed
as no bottleneck for vendors on development of proprietary options, but
for operators, it will be an interoperability nightmare.
Deborah  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Shane Amante
Sent: Thursday, October 02, 2008 12:02 AM
To: BOCCI Matthew
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [mpls] [PWE3] Changes to PW ACH Channel Type allocation
policy

Matthew,

-shane

---

From: Shane Amante <[email-masked]>
Date: Thu, 02 Oct 2008 08:43:27 -0600

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

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

---

From: Loa Andersson <[email-masked]>
Date: Thu, 02 Oct 2008 17:21:24 +0200

<chair hat off>

makes great sense, thanks Shane!

</chair hat off>

/Loa

-- 
Loa Andersson

---

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 2 Oct 2008 21:12:22 +0530

Hi Shane,

> to run contrary to that goal.

Thanks for the detailed mail regarding your point of view.

So if I got you right, your opposition to the idea I proposed is based
on the fact that you are against allowing any proprietary ACH code
points as they would not be *standard based*. The options mentionend
by Matthew are however to address the request for *proprietary
extensions*. Am I missing the point altogather?

Thanks,
Vishwas

---

From: Shane Amante <[email-masked]>
Date: Thu, 02 Oct 2008 10:04:03 -0600

Vishwas,

> extensions*. Am I missing the point altogather?

Please note that I did not exclude Matthew's proposal #1 in the response 
you quoted above.  However, I did recommend that if the consensus was to 
adopt Matthew's proposal #1 I would rather see it modified, so only a 
(small) subset of codepoints (not the whole range of ACH's) were 
designated for "proprietary use", (still with expert review).  Please 
refer back to my first e-mail on this subject, where my position should 
be more clear:
http://www.ietf.org/mail-archive/web/pwe3/current/msg09945.html

-shane

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 02 Oct 2008 12:05:36 -0400

Hi Shane,

Please see my response in-line. 

Best regards,
Shahram

-----Original Message-----
From: Shane Amante [mailto:[email-masked]] 
Sent: October-02-08 10:43 AM
To: Shahram Davari
Cc: BUSI ITALO; Vishwas Manral; [email-masked]; BOCCI Matthew; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] [PWE3] FW: Changes to PW ACH Channel Type allocationpolicy

[Shahram] OTOH it encourages more innovation and differentiation by vendors.

[Shahram] Not if the inventing vendor is not willing to do so.

This is false.  There is no shortage on ACH channel types today.
[Shahram] You are correct. 16-bit is sufficient enough.

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

---

From: "BOCCI Matthew" <[email-masked]>
Date: Thu, 2 Oct 2008 18:50:56 +0200

Shane,

We are not proposing changing the allocation policy for the whole
registry here. We can allocate, say, 1024 channel types by the new
method, and leave the rest for IETF consensus.

Regards

Matthew 

> Sent: 02 October 2008 17:04
> To: Vishwas Manral
> Cc: Shahram Davari; BUSI ITALO; [email-masked]; BOCCI 
> Matthew; [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]
> >> joint ITU-T/IETF effort surrounding MPLS-TP to create an 
> environment 
> >> in which MPLS-TP could seamlessly interoperate within 
> (existing) MPLS 
> >> 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.
> > 
> Please note that I did not exclude Matthew's proposal #1 in 
> the response you quoted above.  However, I did recommend that 
> if the consensus was to adopt Matthew's proposal #1 I would 
> rather see it modified, so only a
> (small) subset of codepoints (not the whole range of ACH's) 
> were designated for "proprietary use", (still with expert 
> review).  Please refer back to my first e-mail on this 
> subject, where my position should be more clear:

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 02 Oct 2008 09:52:07 +0200

Hi Vishwas,

I support your proposal as well.

Your proposal is in fact in line with the way the vendor
specific codepoint is used in ITU-T Y.1731.

One of the objectives of the MPLS-TP JWT is to align with Y.1731
so this perfectly matches the objective.

Cheers, Huub.

=================================================

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...

---

From: <[email-masked]>
Date: Thu, 2 Oct 2008 17:18:17 +0200

Hi.

I must agree with Deborah and Shane.

Option #3 hides the complexity behind a (useless) hierarchy and is
clearly not desired. Option #2 would create an explicit non standard
range and is not what we expect from the IETF.
As a result, since changing the former process seems already committed,
option #1 remains the better compromise.

Regards,

Julien

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of BRUNGARD, DEBORAH A, ATTLABS

-----Original Message-----

Matthew,

-shane

---

From: Lou Berger <[email-masked]>
Date: Thu, 02 Oct 2008 11:13:02 -0400

Shane,
         Your comments make a lot of sense to me.  Particularly your 
last point.

Lou

At 10:43 AM 10/2/2008, Shane Amante wrote:
>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.
>
>
>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.
>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 02 Oct 2008 12:43:31 -0400

I agree with %100 of Shane's comments. One bit to add below:

> Cc: BUSI ITALO; Vishwas Manral; [email-masked]; BOCCI Matthew; [email-masked];

    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

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

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 02 Oct 2008 13:17:58 -0400

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:[email-masked]] 
Sent: October-02-08 12:44 PM
To: Shahram Davari; Shane Amante
Cc: [email-masked]; [email-masked]; BOCCI Matthew; [email-masked]; [email-masked]; Vishwas Manral; [email-masked]; BUSI ITALO
Subject: Re: [mpls-tp] [PWE3] FW: Changes to PW ACH Channel Type allocationpolicy

    --Tom

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 2 Oct 2008 13:24:20 -0400

By the way I suggest using more polite language.

-shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Thomas D. Nadeau
Sent: October-02-08 12:44 PM
To: Shahram Davari; Shane Amante
Cc: [email-masked]; [email-masked]; BOCCI Matthew; [email-masked];
[email-masked]; [email-masked]; BUSI ITALO
Subject: [Bulk] Re: [PWE3] [mpls-tp] FW: Changes to PW ACH Channel Type
allocationpolicy

    --Tom

>> The 2nd method has the first 3 advantages only, and the first method has
none
>> of these advantages.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 02 Oct 2008 18:28:29 +0100

If the process is going to be changed I would vote for Option #1 (expert
review).

Ben

>     --Tom (Speaking as my British alter-ego)

I hope that's not me ;-))

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 02 Oct 2008 18:29:49 +0100

> [Shahram] OTOH it encourages more innovation and differentiation by vendors.

Which is fine until you run a multi-vendor network.

Ben

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 02 Oct 2008 14:06:12 -0400

I suggest listening more closely to potential customers.

    --Tom

---

From: Shane Amante <[email-masked]>
Date: Thu, 02 Oct 2008 13:34:26 -0600

Matthew,

> method, and leave the rest for IETF consensus.

OK, thanks for the clarification.  That makes sense.  Still, my 
preferences are unchanged from my original e-mail:
http://www.ietf.org/mail-archive/web/pwe3/current/msg09945.html
(In short, if there is wide consensus that we need to change the 
allocation process, then I'd prefer a small range of ACH's be allocated 
with Expert Review, only).

-shane (speaking only for himself)

---

From: "BUSI ITALO" <[email-masked]>
Date: Fri, 3 Oct 2008 09:38:47 +0200

Julien, Tom, Shane and Deborah,

it looks like you have a common position regarding interoperability
issues of proprietary protocols.

I can understand your issues with proprietary protocols because, by
definition, they do not interoperate.

However please note that all proprietary protocols by default must be
disabled and enabled if and only if it is known that all the nodes that
need to process the proprietary packets are capable to support the
proprietary protocol. As such you can simply never enable any
proprietary protocol.

I fail to understand how the allocation policy of ACH codepoints for
proprietary use can change the management issues from your point of
view.

Italo

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of [email-masked]
> Sent: Thursday, October 02, 2008 5:18 PM
> To: [email-masked]; [email-masked]; BOCCI Matthew
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: RE: [mpls-tp] [mpls] [PWE3] Changes to PW ACH 
> Channel Typeallocationpolicy
> 
> Hi.
> 
> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf  
> > Of
> > BOCCI Matthew
> >
> > on many PEs, it was prudent for the IETF to maintain strict 
> control  
> > over
> > There are two ways to address the requests for proprietary 
> protocol  
> > ACH
> > code points:
> >
> > reviewer to guide them in assessing the request, which 
> would have to  
> > be
> > Any change to the ACH allocation policy would be outlined 
> in the GE- 
> > ACH

---

From: "BUSI ITALO" <[email-masked]>
Date: Fri, 3 Oct 2008 09:56:27 +0200

Stewart,

as far as I can understand from RFC 4446, a vendor can be prevented
implementing proprietary innovative features by simply disapproving its
codepoint request.

Italo

> From: Stewart Bryant [mailto:[email-masked]] 
> Sent: Thursday, October 02, 2008 9:11 AM
> To: BUSI ITALO
> Cc: Shahram Davari; BOCCI Matthew; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [mpls] [PWE3] FW: Changes to PW ACH Channel Type 
> allocation policy
> 
> BUSI ITALO wrote:
> > I also support option 2
> >

---

From: "BUSI ITALO" <[email-masked]>
Date: Fri, 3 Oct 2008 09:57:47 +0200

See my reply to the same question made by Stewart

Italo

> Sent: Thursday, October 02, 2008 2:13 PM
> >> On Behalf Of
> >>> To: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked];
> >>> [email-masked]
> >> On Behalf Of
> >> control over
> >> protocol ACH
> >> would have to be
> >> in the GE-ACH

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 03 Oct 2008 09:08:39 +0100

Clearly the expert can decline, otherwise there would be no point in then
bing in the process.

However it is expected that they behave reasonably and within the policy
guidelines stated in the RFC, and in the event that you disagree with their
decision, you can appeal to the IESG.

Stewart

BUSI ITALO wrote:
>>> The requirement is to allow a vendor to implement 
>>>       
>> proprietary innovative
>>     
>>> features.
>>>
>>> Italo
>>>
>>>   
>>>       
>> Italo
>>

---

From: "BUSI ITALO" <[email-masked]>
Date: Fri, 3 Oct 2008 10:11:15 +0200

See my comments in line marked with [ib] 

> From: Shahram Davari [mailto:[email-masked]] 
> Sent: Thursday, October 02, 2008 6:06 PM
> To: Shane Amante
> Cc: BUSI ITALO; Vishwas Manral; [email-masked]; BOCCI 
> Subject: RE: [mpls-tp] [PWE3] FW: Changes to PW ACH Channel 
> Type allocationpolicy
> 
> Hi Shane,
> 
> Cc: BUSI ITALO; Vishwas Manral; [email-masked]; BOCCI 

[ib] I fully agree with Shaharm. This is exactly the objective of the
requirement to allow vendor proprietary extensions.

> *slightly* 

[ib] I agree that the codepoint space is big enough and the codepoint
exhaustion is not a real issue.

However, with both option 1 and 2, we still have an open point to decide
how many codepoints we need to reserve for proprietary use and this is
not an easy task.

Option 3 has the advantage that we just need to allocate a single
codepoint.

> > The 2nd method has the first 3 advantages only, and the 
> first method has none of these advantages.
> 
> 
> environment in 
> signaling, 
> [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.
> 

[ib] I agree. Standard actions is definitely the preferred approach to
enhance the technology and MUST be pursed as much as possible.
BTW this is why we are all spending huge efforts to progress standard
activities.
However there are cases where multi-vendor interoperability is not an
issue/requirement and fast time to market is a key requirement, where
standard action is not appropriate.

---

From: "BUSI ITALO" <[email-masked]>
Date: Fri, 3 Oct 2008 10:23:08 +0200

I think that everybody has a different view about the meaning of "behave
reasonably".

Any guideline you can write to describe what is a reasonable behavior is
open to different interpreation.

I can appeal to the IESG and to whatever authority to enforce a
reasonable behavior but this will end up in an endless discussion.

Endless discussions are against fast time to market.

Italo

> Sent: Friday, October 03, 2008 10:09 AM
> To: BUSI ITALO

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Fri, 3 Oct 2008 10:45:47 +0200

" it encourages more innovation and differentiation by vendors". 
If there are some innovations (which is of course encouraged), why not
pushing it to be a standard behavior? 
I am pretty sure SPs will be happier to see it working in multi vendor
environment than as a proprietary solution that is supported by one
vendor only.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext BUSI ITALO
Sent: Friday, October 03, 2008 11:11
To: Shahram Davari; Shane Amante
Cc: [email-masked]; [email-masked]; BOCCI Matthew; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [PWE3] [mpls-tp] FW: Changes to PW ACH ChannelType
allocationpolicy

---

From: Luca Martini <[email-masked]>
Date: Thu, 02 Oct 2008 12:17:15 -0600

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

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 2 Oct 2008 16:25:01 -0400

Hi Luca,

Are you saying that method 1 does not require IETF consensus? If so then
method 1 and 2 are essentially the same except that in Method 1, applicants
are forced to file for patent before writing the drafts (since writing a
draft is a form of public disclosure) asking for code points. While in the
2nd method they can choose not to file any patents or file patents
afterwards. 

Regards,
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Luca
Martini
Sent: October-02-08 2:17 PM
To: Shahram Davari
Cc: [email-masked]; BOCCI Matthew; [email-masked]; [email-masked];
[email-masked]; BUSI ITALO; Shane Amante; [email-masked]
Subject: [Bulk] Re: [PWE3] [mpls-tp] FW: Changes to PW ACH Channel Type
allocationpolicy

Shahram,

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.
> Cc: [email-masked]; [email-masked]; BOCCI Matthew; [email-masked];
[email-masked]; Vishwas Manral; [email-masked]; BUSI ITALO
none

---

From: "BUSI ITALO" <[email-masked]>
Date: Fri, 3 Oct 2008 09:08:33 +0200

Luca,

Reading your mail, I understand that Expert Review is just providing an
advice and cannot enforce the requestor.

However, this is in contradiction from what I can understand reading RFC
4446 and in particulare the statement saying that "The expert reviewing
the request MUST approve or disapprove ...".

My understanding of RFC 4446 is that the experts can disapprove the
request and avoid the requestor using the ACH for its own proprietary
protocol.

Could you please clarify whether I am misunderstanding you or RFC 4446?

Thanks, Italo

> From: Luca Martini [mailto:[email-masked]] 
> Sent: Thursday, October 02, 2008 8:17 PM
> To: Shahram Davari
> Cc: Thomas D. Nadeau; Shane Amante; [email-masked]; 
> [email-masked]; BOCCI Matthew; [email-masked]; 
> Subject: Re: [PWE3] [mpls-tp] FW: Changes to PW ACH Channel 
> Type allocationpolicy
> 
> Shahram,
> > 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
> >
> >
> > Cc: [email-masked]; [email-masked]; BOCCI Matthew; 
> [email-masked]; [email-masked]; Vishwas Manral; 
> [email-masked]; BUSI ITALO
> Matthew; [email-masked];
> >>> 1) Allows vendors to not expose their proprietary 
> techniques to their
> >>> competitors.
> >>>       
> >>> 5) only one VCCV ACH channel type needs to be configured 
> in each box for
> >>> vendor specific filtering
> >>>
> methods. But we should

---

From: "BUSI ITALO" <[email-masked]>
Date: Fri, 3 Oct 2008 09:13:41 +0200

Luca,

I fully agree with you that using an ACH for implementing a new PW type
for a very vendor specific protocol is a very bad idea.

However, I think that the best way to avoid people running proprietary
PW within a ACH is not to overload experts with these requests but to
clearly document that a vendor that wishes to implement a new PW type
for a very vendor specific protocol MUST define a new PW type.

Italo

---

From: "Tom Petch" <[email-masked]>
Date: Fri, 3 Oct 2008 09:33:56 +0200

Option 1

It is the simplest and does the job (as far as I can see into the future).

Tom Petch

----- Original Message -----
From: "BOCCI Matthew" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Tuesday, September 30, 2008 6:23 PM
Subject: [mpls] FW: [PWE3] Changes to PW ACH Channel Type allocation policy

---

From: "Shahram Davari" <[email-masked]>
Date: Fri, 3 Oct 2008 07:39:42 -0400

Hi Nurit,

Good question. There are many reasons why a vendor may not want to
standardize its proprietary protocol. Including commercial benefits, product
differentiation, or simply trying a new unproven protocol for some time
before they are confident it works in various network situations.

In any case, I think your question is out of the scope here, since we are
clearly debating how to allocate code points for proprietary use. In other
words we have already accepted that people need proprietary extensions.

Regards,
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Sprecher, Nurit (NSN - IL/Hod HaSharon)
Sent: October-03-08 4:46 AM
To: ext BUSI ITALO; Shahram Davari; Shane Amante
Cc: [email-masked]; [email-masked]; BOCCI Matthew; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [PWE3] [mpls-tp] FW: Changes to PW ACH ChannelType
allocationpolicy

-----Original Message-----

> techniques to their competitors. 
>

---

From: "Eric Gray" <[email-masked]>
Date: Fri, 3 Oct 2008 08:36:46 -0500

Luca,

	The practical reality is that expert review gives the 
designated "expert" (or experts) the same level of control 
of assignment as IESG review gives ADs over RFC publication.
While it is possible to push something through against the
"wishes" of an expert (who does in fact have more than the
ability to "advise" the requesting individual/organization),
the process can be quite confrontational and tedious.

--
Eric Gray
Principal Engineer
Ericsson  

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Luca Martini
> Sent: Thursday, October 02, 2008 2:17 PM
> To: Shahram Davari
> Cc: Thomas D. Nadeau; [email-masked]; BOCCI Matthew; 
> [email-masked]; [email-masked]; [email-masked]; BUSI ITALO; 
> [email-masked]
> Subject: Re: [mpls] [PWE3] [mpls-tp] FW: Changes to PW ACH 
> ChannelType allocationpolicy
> 
> Shahram,

---

From: Sam Aldrin <[email-masked]>
Date: Fri, 3 Oct 2008 01:55:11 -0700

Agree on #1.

-sam
On Sep 30, 2008, at 9:23 AM, BOCCI Matthew wrote:

> Behalf Of

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Fri, 3 Oct 2008 10:52:15 -0400

Hi Italo,

It is much more than a codepoint and ensuring the nodes are provisioned
correctly - which is in itself difficult - especially in large networks.
Here's just a partial list of additional concerns from an operator:
- proprietary protocols perpetuate the use of vendor islands - good for
a vendor/bad for an operator;-(
- each protocol, proprietary or not, for an operator requires testing of
the protocol itself, not just if it works as it should, but also
development and testing of failure scenarios, and the negotiation with
the vendor for fixes. And if it's proprietary, an operator is on their
own for determining bugs, determining the correct fix, testing the fix,
etc, etc.
- OS development - this is probably the biggest hit on time for
deployment and most costly (and it's not just for deployment, it
continues for the lifetime).

Which is why we have standards. I'm sure the others can add many more
(still on my first coffee here) and take a look back over Shane's mails.
Deborah

-----Original Message-----
From: BUSI ITALO [mailto:[email-masked]] 
Sent: Friday, October 03, 2008 3:39 AM
To: [email-masked]; BRUNGARD, DEBORAH A, ATTLABS;
[email-masked]; BOCCI Matthew
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: [mpls-tp] [mpls] [PWE3] Changes to PW ACH Channel
Typeallocationpolicy

Italo

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 03 Oct 2008 11:02:39 -0400

> (still on my first coffee here) and take a look back over Shane's mails.

    Nothing to add here; hits the nail right on the head.

    --Tom

---

From: "Shahram Davari" <[email-masked]>
Date: Fri, 03 Oct 2008 11:23:34 -0400

Hi Deborah,

Your concerns are valid, but irrelevant to the discussion at hand. I think it is understood that IETF wants to allow Proprietary protocols and the issue is how to allocate the code points. So there debating whether proprietary protocols are good or bad is not going to make any difference here.  

But just to give you my opinion, lots of great innovations start as proprietary and eventually if they are good they would probably find their way to standard. Juts take a look at Cisco Tag Switching. It started as proprietary but later was standardized as MPLS.

Best regards,
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of BRUNGARD, DEBORAH A, ATTLABS
Sent: October-03-08 10:52 AM
To: BUSI ITALO
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [PWE3] [mpls-tp] [mpls] Changes to PW ACH Channel Typeallocationpolicy

Hi Italo,

-----Original Message-----
From: BUSI ITALO [mailto:[email-masked]] 
Sent: Friday, October 03, 2008 3:39 AM
To: [email-masked]; BRUNGARD, DEBORAH A, ATTLABS;

Italo

---

From: Shane Amante <[email-masked]>
Date: Fri, 03 Oct 2008 09:47:51 -0600

>     Nothing to add here; hits the nail right on the head.

Ditto.

-shane

---

From: Loa Andersson <[email-masked]>
Date: Mon, 06 Oct 2008 12:12:33 +0200

All,

most IETF lists has a limit to how many recipients they allow on a
single mail. If we just keep responding to the last mail with a
"reply to all" the recipients list keep building up and actions by
list administrators is needed to let your mail be forwarded to the
list(s).

I've three suggestions:

1. We keep *discussion* of this just to the pwe3-list, now we all know
   that is is going on and are able to follow it on that list
2. when the pwe3 wg chairs make the consensus call they send it to all
   the lists it was originally sent to
3. We all make it a habit to prune the recipients-list to what is
   necessary (please make the assumption that people sending mails to
  IETF-lists are subscribed to the lists).

/Loa

Maarten Vissers wrote:
> Ben,
> 
> Also in case of a multi-vendor network there should be no issue. The new
> functionality is present only in the UNI-N ports (i.e. where the service is
> mapped into the PW). When you deploy such new functionality in UNI-N ports
> contained in Network Termination devices you can deploy those NT devices
> from one vendor. The main network now only has to carry the MS-PW between
> the NT devices at the edge of the network. The main network is as such
> agnostic to the new functionality.
> 
> The use of NT devices to support new (non standard) services not only allows
> differentiation by vendors, but also differentiation by operators. Operators
> wanting to differentiate their service offerings can ask a NT device vendor
> to add their operator specific service to the NT device.
> 
> Regards,
> Maarten
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ben
> Niven-Jenkins
> Sent: 02 October 2008 19:30
> Subject: Re: [PWE3] [mpls-tp] FW: Changes to PW ACH Channel Type
> allocationpolicy
> 
>> From: Shane Amante [mailto:[email-masked]] Shahram Davari 
>> wrote:
>>> Hi,
>>>

-- 
Loa Andersson

---

From: "Annamaria Fulignoli" <[email-masked]>
Date: Mon, 6 Oct 2008 12:34:34 +0200

Hi Matthew,
I support option 2.

Best Regards
Annamaria 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of BOCCI Matthew
Sent: martedì 30 settembre 2008 18.23
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [mpls-tp] FW: [PWE3] Changes to PW ACH Channel Type allocationpolicy

The PWE3 chairs would like feedback on proposed changes to the allocation policy for the PW ACH codepoint registry. Please see the email below, and provide any feedback copying the PWE3 list.

Best regards

Matthew

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of BOCCI Matthew
Sent: 25 September 2008 16:36
To: [email-masked]
Subject: [PWE3] Changes to PW ACH Channel Type allocation policy

The current IANA allocation policy for the PW associated channel type registry is by IETF consensus. This policy was chosen in RFC 4385 based on WG consensus that since the associated channel exists in the data path, and VCCV packets are typically processed by the control processor on many PEs, it was prudent for the IETF to maintain strict control over what types of channels were allocated and to ensure that they complied to the PWE3 architecture.

However, a need has been identified to provide a more flexible approach to allocating code points for VCCV channel types. This has partly arisen from the MPLS-TP work, where MPLS would be deployed in a transport network and where a much wider range of applications for the PW associated channel is envisioned, and partialy from a desire to extend the OAM capabilities for regular MPLS. We can support MPLS-TP and general MPLS apps with the current policy which requires standards action.

However we are receiving requests to allow proprietary OAM and signaling protocols to be used in transport applications, and need to decide on the best way forward. We considered providing extension mechanisms within the standards track protocols, but believe that the standards track protocols would be much cleaner if the proprietary protocols ran on their own ACH code points.

Note that we are talking about vendor protocols here. Other SDOs would be required to publish an RFC and would only be allocated an ACH through Standards Action.

There are two ways to address the requests for proprietary protocol ACH code points:

1) Allow a range of the associated channel type registry to be allocated through expert review. Guidelines would be provided for the expert reviewer to guide them in assessing the request, which would have to be made in the form of an internet draft, while making sure that the request is dealt with in a timely and fair manner. This policy would include hurdles with regard to security, congestion etc that would be derived from those specified in the VCCV design.

2) Allow a range of the associated channel type registry to be allocated on a first-come-first-served basis. This does not provide the level of control that expert review provides, but this is balanced to some degree by the fact that the VCCV channel type is indicated in the data path, and so a PE can choose to discard or rate limit VCCV packets on an unrecognised associated channel.

Any change to the ACH allocation policy would be outlined in the GE-ACH draft, which would update RFC 4385.

We would appreciate feedback on the list as to which approach the WG prefers.

Regards,

Stewart and Matthew

---

From: "Annamaria Fulignoli" <[email-masked]>
Date: Mon, 6 Oct 2008 17:25:46 +0200

Hi Matthew,
I also prefer the method that Wishwas proposed;
that for the several reasons yet clearly exposed in the mails below.
Besides, is it possible to "recognize" it as a possible third solution 
and add it to the two ones you proposed in your first mail ?

Thanks,BR.

Annamaria  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Huub van Helvoort
Sent: giovedì 2 ottobre 2008 9.52
To: Vishwas Manral
Cc: [email-masked]; [email-masked]; BOCCI Matthew; [email-masked]; [email-masked]; [email-masked]; BUSI ITALO
Subject: Re: [mpls] [mpls-tp] [PWE3] FW: Changes to PW ACH ChannelType allocationpolicy

Hi Vishwas,

Your proposal is in fact in line with the way the vendor specific codepoint is used in ITU-T Y.1731.

One of the objectives of the MPLS-TP JWT is to align with Y.1731 so this perfectly matches the objective.

Cheers, Huub.

>> The advantage of this approach is that we do not have to worry about 
>> how many codepoints we need to allocate for proprietary extensions: 
>> we just need one codepoint.
>>
>> Italo
>>
>>> I would like to propose another option if it is for vendor 
>>> proprietery "Channel Type" values in the ACH header. With the number 
>>> of values of the channel type being limited and the number of 
>>> vendors actually a lot, I would think something in the lines of what 
>>> the draft below talks about may make sense:
>>>
>>>> on WG consensus that since the associated channel exists in the 
>>>> data path, and VCCV packets are typically processed by the
>>> control processor
>>>> within the standards track protocols, but believe that the 
>>>> standards track protocols would be much cleaner if the proprietary
>>> protocols ran
>>>> request is dealt with in a timely and fair manner. This policy 
>>>> would include hurdles with regard to security, congestion etc
>>> that would be

--
================================================================
                   http://www.van-helvoort.eu/ ================================================================
Always remember that you are unique...just like everyone else...

---

From: Luca Martini <[email-masked]>
Date: Fri, 03 Oct 2008 08:53:29 -0600

Eric,

This is true, but it all depends on the Expert guidelines we setup.
We can easily put in place a rule that mitigates this problem.

Luca

Eric Gray wrote:
>>>>> I also prefer the method that Wishwas proposed. This has 
>>>>>           
>> many advantages:
>>     
>>>>  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
>>     
>>> implementations; we want to encourage them to ultimately 
>>>       
>> interoperate on a
>>     
>>> 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
>>>
>>>
>>>   
>>>   
>>>       
>>>>> 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
>>     
>> first method has none
>>>> 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
>>     
>>>> provide a fast and reasonable procedure for vendor 
>>>>         
>> specific protocols that
>>     
>>>> don't affect interoperability. I worry that in first 
>>>>         
>> method competitors may
>>

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 06 Oct 2008 09:39:59 +0200

Ben,

Regards,
Maarten

-----Original Message-----

Ben

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 06 Oct 2008 09:49:26 +0200

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Shahram Davari
Sent: 02 October 2008 19:18
To: Thomas D. Nadeau; Shane Amante
Cc: [email-masked]; [email-masked]; BOCCI Matthew; [email-masked];
[email-masked]; [email-masked]; BUSI ITALO
Subject: Re: [PWE3] [mpls-tp] FW: Changes to PW ACH Channel
Typeallocationpolicy

-Shahram

-----Original Message-----
From: Thomas D. Nadeau [mailto:[email-masked]]
Sent: October-02-08 12:44 PM
To: Shahram Davari; Shane Amante
Cc: [email-masked]; [email-masked]; BOCCI Matthew; [email-masked];
[email-masked]; Vishwas Manral; [email-masked]; BUSI ITALO
Subject: Re: [mpls-tp] [PWE3] FW: Changes to PW ACH Channel Type
allocationpolicy

    --Tom

none

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 6 Oct 2008 10:27:08 +0200

Maarten and all,
Please see some comments inline below. The unrelated text has been snipped to improve readability.

Regards,
        Sasha
> Behalf Of Maarten Vissers
> Sent: Monday, October 06, 2008 9:49 AM
> To: 'Shahram Davari'; 'Thomas D. Nadeau'; 'Shane Amante'
> Cc: [email-masked]; [email-masked]; 'BOCCI Matthew';
> [email-masked]; [email-masked]; [email-masked]; 'BUSI ITALO'
> Subject: Re: [PWE3] [mpls-tp] FW: Changes to PW ACH Channel Type allocation policy
>
> 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 organization can decide to keep their associated application
> private ("Protocol unavailable.") or to make it public.
>
> As far as I understand this Ethertype allocation policy is an industry
[Sasha] IMHO and FWIW your description of the IEEE process is somewhat inaccurate.
I am not an expert in the field, and Shahram (and others) will probably provide a much more accurate description
of the process, but still:

1. As you've mentioned, IEEE *SELLS* its Ethertype codepoints - at USD $2,500 per a *PUBLIC* codepoint.
    AFAIK, the IETF does not charge anybody  for its codepoints (hopefully this will not result in any bright ideas:-)

2. There is no such thing as a *PRIVATE* Ethertype codepoint at IEEE  (at least, I did not find any references
    on their Web site). AFAIK, the only private values you can obtain from IEEE are OUIs,
    and you must pay USD $1,650/year per private OUI to maintain privacy (that on top of USD $2,000 per a public OUI)

3. IEEE still requires description of the protocol before it approves your registration request, and it takes at least 90
    days before a new code point is granted. (From my experience when dealing with other SDOs IEEE requires an approved
    protocol spec lacking just the new Ethertype value in order to grant a new Ethertype codepoint.)

On top of all that, the most important issue here is that ACH has never been intended to be a new multiprotocol network layer.
This point has been raised already by the others.

Unfortunately your analogy between the ACH type and Ethertype only strengthens the suspicions that this can easily happen with an over-relaxed codepoint allocation policy.

... snipped to the end...

---

From: <[email-masked]>
Date: Thu, 9 Oct 2008 18:36:26 +0200

Hi Maarten.

That might be true sometimes, but the IETF allocation policy is not the
limiting factor in that kind of processes... ;-)

Regards,

Julien

-----Original Message-----
Maarten Vissers

[...]

The use of NT devices to support new (non standard) services not only
allows
differentiation by vendors, but also differentiation by operators.
Operators
wanting to differentiate their service offerings can ask a NT device
vendor
to add their operator specific service to the NT device.

Regards,
Maarten