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

From: Luca Martini <[email-masked]>
Date: Thu, 02 Oct 2008 11:38:43 -0600

Matthew,

I support option #1, as the expert review process is very quick, and I 
cannot believe that having somebody write a few lines in a draft , and a 
week's delay can impede innovation. When we created this channel we were 
worried about improper traffic , like a full IP routed channel , or a 
new PW inside the ACH. I believe that in , most instances that is not 
the intention of the designer, however sometime an expert review will 
help in guide the designer in the proper direction.
The expert review is by no means intended from stopping anybody from 
getting an allocation from this range, it is only to advise , and 
prevent duplication of allocated code points. We should be able to write 
expert guidelines to satisfy the requirement of an expedite allocation, 
while still having a reasonable documentation.

Thanks.
Luca

BOCCI Matthew wrote:
>  
> 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
>   

_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3