Re: [mpls] [mpls-tp] [PWE3] Changes to PW ACH Channel Typeallocation policy

[<julien.meuric at orange-ftgroup.com>]

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: mpls-tp-bounces at ietf.org [mailto:mpls-tp-bounces at ietf.org] On
Behalf Of BRUNGARD, DEBORAH A, ATTLABS

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: mpls-bounces at ietf.org [mailto:mpls-bounces at ietf.org] On Behalf Of
Shane Amante

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


On Sep 30, 2008, at 10:23 AM, 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
>
> 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
_______________________________________________
mpls-tp mailing list
mpls-tp at ietf.org
https://www.ietf.org/mailman/listinfo/mpls-tp
_______________________________________________
mpls mailing list
mpls at ietf.org
https://www.ietf.org/mailman/listinfo/mpls