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

["BRUNGARD, DEBORAH A, ATTLABS" <dbrungard at att.com>]

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
Sent: Thursday, October 02, 2008 12:02 AM
To: BOCCI Matthew
Cc: l2vpn at ietf.org; mpls at ietf.org; ccamp at ietf.org; pwe3 at ietf.org;
mpls-tp at ietf.org
Subject: Re: [mFrom mpls-bounces at ietf.org  Thu Oct  2 06:54:58 2008
Return-Path: <mpls-bounces at ietf.org>
X-Original-To: mpls-archive at megatron.ietf.org
Delivered-To: ietfarch-mpls-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id B4A5428C212;
	Thu,  2 Oct 2008 06:54:58 -0700 (PDT)
X-Original-To: mpls at core3.amsl.com
Delivered-To: mpls at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id E067B3A6AE2;
	Thu,  2 Oct 2008 06:54:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.209
X-Spam-Level: 
X-Spam-Status: No, score=-106.209 tagged_above=-999 required=5
	tests=[AWL=0.391, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4,
	USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id PSIx6l7EOmAM; Thu,  2 Oct 2008 06:54:52 -0700 (PDT)
Received: from mail121.messagelabs.com (mail121.messagelabs.com
	[216.82.245.115])
	by core3.amsl.com (Postfix) with ESMTP id 1D3B728C13E;
	Thu,  2 Oct 2008 06:54:52 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: dbrungard at att.com
X-Msg-Ref: server-14.tower-121.messagelabs.com!1222955663!24373905!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [144.160.20.54]
Received: (qmail 24754 invoked from network); 2 Oct 2008 13:54:23 -0000
Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com)
	(144.160.20.54)
	by server-14.tower-121.messagelabs.com with AES256-SHA encrypted SMTP;
	2 Oct 2008 13:54:23 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1])
	by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id
	m92DsN53002414; Thu, 2 Oct 2008 09:54:23 -0400
Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com
	[135.53.26.19])
	by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id
	m92DsGLY002371; Thu, 2 Oct 2008 09:54:18 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 2 Oct 2008 09:53:30 -0400
Message-ID: <D6CB948F7AFD6F4881D4B4F80C8509AA01208045 at gaalpa1msgusr7e.ugd.att.com>
In-Reply-To: <639AAB99-9B29-40B1-A57D-C3476D87696C at castlepoint.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [mpls] [PWE3] Changes to PW ACH Channel Type allocation policy
Thread-Index: AckkQ71IH8+xzlBPTXyZ2QuPfVC+nQAT4P0w
References: <0458D2EE0C36744BABB36BE37805C29A029C6251 at FRVELSMBS11.ad2.ad.alcatel.com>
	<639AAB99-9B29-40B1-A57D-C3476D87696C at castlepoint.net>
From: "BRUNGARD, DEBORAH A, ATTLABS" <dbrungard at att.com>
To: "Shane Amante" <shane at castlepoint.net>,
	"BOCCI Matthew" <Matthew.Bocci at alcatel-lucent.com>
Cc: l2vpn at ietf.org, mpls at ietf.org, ccamp at ietf.org, pwe3 at ietf.org,
	mpls-tp at ietf.org
Subject: Re: [mpls] [PWE3] Changes to PW ACH Channel Type allocation policy
X-BeenThere: mpls at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>,
	<mailto:mpls-request at ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/mpls>
List-Post: <mailto:mpls at ietf.org>
List-Help: <mailto:mpls-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>,
	<mailto:mpls-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: mpls-bounces at ietf.org
Errors-To: mpls-bounces at ietf.org

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
Sent: Thursday, October 02, 2008 12:02 AM
To: BOCCI Matthew
Cc: l2vpn at ietf.org; mpls at ietf.org; ccamp at ietf.org; pwe3 at ietf.org;
mpls-tp at ietf.org
Subject: Re: [mpls] [PWpls] [PWE3] Changes to PW ACH Channel Type allocation
policy

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

____________________________________E3] Changes to PW ACH Channel Type allocation
policy

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
> 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
_______________________________________________
mpls mailing list
mpls at ietf.org
https://www.ietf.org/mailman/listinfo/mpls


___
mpls mailing list
mpls at ietf.org
https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
mpls at ietf.org
https://www.ietf.org/mailman/listinfo/mpls