Re: [mpls] FW: [PWE3] Changes to PW ACH Channel Type allocation policy
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



All,

I support option 1.

/Loa

BOCCI Matthew 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: 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
> _______________________________________________
> mpls mailing list
> mpls at ietf.org
> 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:  loa.andersson at acreo.se
                                           loa at pi.nu
_______________________________________________
mpls mailing list
mpls at ietf.org
https://www.ietf.org/mailman/listinfo/mpls



Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.