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

["BUSI ITALO" <Italo.Busi at alcatel-lucent.it>]

I also support option 2

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

Italo

> -----Original Message-----
> From: pwe3-bounces at ietf.org [mailto:pwe3-bounces at ietf.org] On 
> Behalf Of Shahram Davari
> Sent: Wednesday, October 01, 2008 4:34 PM
> To: BOCCI Matthew; pwe3 at ietf.org; mpls-tp at ietf.org; 
> mpls at ietf.org; ccamp at ietf.org; l2vpn at ietf.org
> 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
> 
> 
> -----Original Message-----
> From: pwe3-bounces at ietf.org [mailto:pwe3-bounces at ietf.org] On 
> Behalf Of BOCCI Matthew
> Sent: September-30-08 12:23 PM
> To: pwe3 at ietf.org; mpls-tp at ietf.org; mpls at ietf.org; 
> ccamp at ietf.org; l2vpn at ietf.org
> Subject: [PWE3] FW: Changes to PW ACH Channel Type allocation policy
> 
> 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: pwe3-bounces at ietf.org [mailto:pwe3-bounces at ietf.org] On 
> Behalf Of
> BOCCI Matthew
> Sent: 25 September 2008 16:36
> To: pwe3 at ietf.org
> 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
> pwe3 at ietf.org
> https://www.ietf.org/mailman/listinfo/pwe3
> _______________________________________________
> pwe3 mailing list
> pwe3 at ietf.org
> https://www.ietf.org/mailman/listinfo/pwe3
> 
> 
> 
> _______________________________________________
> 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