Subject: [PWE3] Changes to PW ACH Channel Type allocation policy

From: "BOCCI Matthew" <[email-masked]>
Date: Thu, 25 Sep 2008 17:35:45 +0200

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

---

From: "Nitin Bahadur" <[email-masked]>
Date: Thu, 25 Sep 2008 17:24:27 -0700

I support the first approach. 2nd approach has the pitfall that folks
might not think through and get a channel type. The first approach
forces one to think and justify the need (even if proprietery).

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