Re: [PWE3] [mpls-tp] FW: Changes to PW ACH Channel Type allocation policy]
Stewart Bryant <stbryant@cisco.com> Thu, 02 October 2008 18:39 UTC
Return-Path: <pwe3-bounces@ietf.org>
X-Original-To: pwe3-archive@megatron.ietf.org
Delivered-To: ietfarch-pwe3-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAE4028C253; Thu, 2 Oct 2008 11:39:09 -0700 (PDT)
X-Original-To: pwe3@core3.amsl.com
Delivered-To: pwe3@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6779F3A6AD0; Thu, 2 Oct 2008 11:39:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 A6SevXXZ6n2t; Thu, 2 Oct 2008 11:39:07 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 0562B3A69F0; Thu, 2 Oct 2008 11:39:05 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.33,352,1220227200"; d="eml'208?scan'208,208,217";a="21485391"
Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 02 Oct 2008 18:39:24 +0000
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m92IdOOl012775; Thu, 2 Oct 2008 20:39:24 +0200
Received: from dhcp-gpk02-vlan300-64-103-65-109.cisco.com (dhcp-gpk02-vlan300-64-103-65-109.cisco.com [64.103.65.109]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m92IdNuK014332; Thu, 2 Oct 2008 18:39:23 GMT
Message-ID: <48E51561.1070103@cisco.com>
Date: Thu, 02 Oct 2008 19:39:29 +0100
From: Stewart Bryant <stbryant@cisco.com>
User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707)
MIME-Version: 1.0
To: pwe3 <pwe3@ietf.org>, "ccamp@ietf.org" <ccamp@ietf.org>, "l2vpn@ietf.org" <l2vpn@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
Content-Type: multipart/mixed; boundary="------------010408070202020501030202"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=13920; t=1222972764; x=1223836764; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20<stbryant@cisco.com> |Subject:=20Re=3A=20[mpls-tp]=20[PWE3]=20FW=3A=20Changes=20 to=20PW=20ACH=20Channel=20Type=20allocation=0A=20policy] |Sender:=20; bh=Dv5J3vONJLVQ25Z2+UHWxj8KjakAvj18vkfpDbYxBM4=; b=KiQtw71g4R9JlJusKd1uofrnFGTsRX1zdiZD0C2IGRh8x/iw7mJPB8y5LM B4fq+XIHOoOCJ70uZLn/xPKx1JUUrRi3qd7UJt5xIBaZA6vPMDzDSMNGi9Yp PFlTQY3dFl;
Authentication-Results: ams-dkim-1; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; );
Cc: Mike Shand <mshand@cisco.com>
Subject: Re: [PWE3] [mpls-tp] FW: Changes to PW ACH Channel Type allocation policy]
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: stbryant@cisco.com
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/pwe3>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe>
Sender: pwe3-bounces@ietf.org
Errors-To: pwe3-bounces@ietf.org
Since a reference was made to extension mechanisms proposed to the ISIS WG, and since there seemed to be some enthusiasm for it, to the point where there was a suggestion that we might follow the same model, I asked my college Mike Shand for some history and background and what happened next. Please see the attached email for his answer. I guess I have to ask whether there are lessons to be learned from ISIS that we need to take into account here: i.e. is experimental the way to go, and should we place significant restriction on what you can do on an experimental codepoint? Stewart
--- Begin Message ---Stewart Bryant wrote:--- End Message ---This draft was replaced by
Subject:Re: [mpls-tp] [PWE3] FW: Changes to PW ACH Channel Type allocation policy From:"Vishwas Manral" <vishwas.ietf@gmail.com> Date:Wed, 1 Oct 2008 21:17:22 +0530 To:"Shahram Davari" <davari@tpack.com>
To:"Shahram Davari" <davari@tpack.com> CC:"l2vpn@ietf.org" <l2vpn@ietf.org>, BOCCI Matthew <Matthew.Bocci@alcatel-lucent.com>, "mpls@ietf.org" <mpls@ietf.org>, "ccamp@ietf.org" <ccamp@ietf.org>, "mpls-tp@ietf.org" <mpls-tp@ietf.org>, "pwe3@ietf.org" <pwe3@ietf.org>
Hi Matthew, I would like to propose another option if it is for vendor proprietery "Channel Type" values in the ACH header. With the number of values of the channel type being limited and the number of vendors actually a lot, I would think something in the lines of what the draft below talks about may make sense: http://tools.ietf.org/draft-ietf-isis-proprietary-tlv-00" rel="nofollow">http://tools.ietf.org/draft-ietf-isis-proprietary-tlv-00
http://tools.ietf.org/html/draft-ietf-isis-experimental-tlv" rel="nofollow">http://tools.ietf.org/html/draft-ietf-isis-experimental-tlv because the working group did not want to sanction true vendor proprietary extensions, but wanted to limit them to those which could be described as experimental. A requirement was added that any such extension SHOULD be documented in an experimental RFC. There were also strict limitations that the presence of an experimental TLV MUST NOT cause a router to calculate a different route. It was also forbidden to use the TLV as a means for carrying general application data. GENAPP should be used for such purposes. A particular constraint in IS-IS is that the number space available for TLVs is limited to 255. However, despite all this, the draft expired in November 2005 and there has been no subsequent desire to resurrect it. MikeThe idea is give a channel type value, for vendor specific implemntations and further define the structure of the next header value for such a "channel type" to actually have a Vendor OUI value. This will allow for unlimited innovation without affecting interoperability, unlike the other options you have mentioned. Thanks, Vishwas On 10/1/08, Shahram Davari <davari@tpack.com> wrote: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@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of BOCCI Matthew Sent: September-30-08 12:23 PM To: pwe3@ietf.org; mpls-tp@ietf.org; mpls@ietf.org; ccamp@ietf.org; l2vpn@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@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of BOCCI Matthew Sent: 25 September 2008 16:36 To: pwe3@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@ietf.org https://www.ietf.org/mailman/listinfo/pwe3" rel="nofollow">https://www.ietf.org/mailman/listinfo/pwe3 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3" rel="nofollow">https://www.ietf.org/mailman/listinfo/pwe3 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3" rel="nofollow">https://www.ietf.org/mailman/listinfo/pwe3_______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp" rel="nofollow">https://www.ietf.org/mailman/listinfo/mpls-tp
_______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3
- Re: [PWE3] [mpls-tp] FW: Changes to PW ACH Channe… Stewart Bryant
- Re: [PWE3] [mpls] [mpls-tp] FW: Changes to PW ACH… Francesco Fondelli