Re: [mpls-tp] [PWE3] FW: Changes to PW ACH Channel Type allocationpolicy
"Thomas D. Nadeau" <tom.nadeau@bt.com> Thu, 02 October 2008 12:13 UTC
Return-Path: <l2vpn-bounces@ietf.org>
X-Original-To: l2vpn-archive@megatron.ietf.org
Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED12828C1F4; Thu, 2 Oct 2008 05:13:34 -0700 (PDT)
X-Original-To: l2vpn@core3.amsl.com
Delivered-To: l2vpn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C94F43A6CC3; Thu, 2 Oct 2008 05:13:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.952
X-Spam-Level:
X-Spam-Status: No, score=-0.952 tagged_above=-999 required=5 tests=[AWL=0.580, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067]
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 8S5kOLTHZo4X; Thu, 2 Oct 2008 05:13:32 -0700 (PDT)
Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 59E9F3A6CB0; Thu, 2 Oct 2008 05:13:32 -0700 (PDT)
Received: from E03MVZ2-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Oct 2008 13:13:08 +0100
Received: from 217.32.164.172 ([217.32.164.172]) by E03MVZ2-UKDY.domain1.systemhost.net ([193.113.30.120]) via Exchange Front-End Server mail.bt.com ([193.113.197.26]) with Microsoft Exchange Server HTTP-DAV ; Thu, 2 Oct 2008 12:13:07 +0000
User-Agent: Microsoft-Entourage/12.12.0.080729
Date: Thu, 02 Oct 2008 08:13:06 -0400
Subject: Re: [mpls-tp] [PWE3] FW: Changes to PW ACH Channel Type allocationpolicy
From: "Thomas D. Nadeau" <tom.nadeau@bt.com>
To: BUSI ITALO <Italo.Busi@alcatel-lucent.it>, Vishwas Manral <vishwas.ietf@gmail.com>, Shahram Davari <davari@tpack.com>
Message-ID: <C50A3312.E217%tom.nadeau@bt.com>
Thread-Topic: [mpls-tp] [PWE3] FW: Changes to PW ACH Channel Type allocationpolicy
Thread-Index: Ackj3Q1bqBGtuyWETZaWG4drFEnw4AAf+XvQAArRnjg=
In-Reply-To: <6FD21B53861BF44AA90A288402036AB40193F737@FRVELSMBS21.ad2.ad.alcatel.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 02 Oct 2008 12:13:08.0615 (UTC) FILETIME=[3B51F970:01C92488]
Cc: l2vpn@ietf.org, BOCCI Matthew <Matthew.Bocci@alcatel-lucent.com>, mpls@ietf.org, ccamp@ietf.org, mpls-tp@ietf.org, pwe3@ietf.org
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <l2vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/l2vpn>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe>
Sender: l2vpn-bounces@ietf.org
Errors-To: l2vpn-bounces@ietf.org
On 10/2/08 3:11 AM, "BUSI ITALO" <Italo.Busi@alcatel-lucent.it> wrote: > Vishwas, > > I think this is a good idea > > Both this proposal and option 2 (fist-come-first-served) meet the > requirements to make the ACH mechanism extensible. How does the existing mechanism not meet the requirement to make an ACH mechanism extensible? --Tom > The advantage of this approach is that we do not have to worry about how > many codepoints we need to allocate for proprietary extensions: we just > need one codepoint. > > Italo > >> -----Original Message----- >> From: mpls-tp-bounces@ietf.org >> [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Vishwas Manral >> Sent: Wednesday, October 01, 2008 5:47 PM >> To: Shahram Davari >> Cc: l2vpn@ietf.org; BOCCI Matthew; mpls@ietf.org; >> ccamp@ietf.org; mpls-tp@ietf.org; pwe3@ietf.org >> Subject: Re: [mpls-tp] [PWE3] FW: Changes to PW ACH Channel >> Type allocationpolicy >> >> 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 >> >> The 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 >>> _______________________________________________ >>> pwe3 mailing list >>> pwe3@ietf.org >>> https://www.ietf.org/mailman/listinfo/pwe3 >>> >>> >>> >>> _______________________________________________ >>> pwe3 mailing list >>> pwe3@ietf.org >>> https://www.ietf.org/mailman/listinfo/pwe3 >>> >> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp >>
- RE: [PWE3] FW: Changes to PW ACH Channel Type all… Shahram Davari
- FW: [PWE3] Changes to PW ACH Channel Type allocat… BOCCI Matthew
- RE: [mpls-tp] FW: [PWE3] Changes to PW ACH Channe… Shah, Himanshu
- Re: [mpls-tp] FW: [PWE3] Changes to PW ACH Channe… Thomas D. Nadeau
- Re: [PWE3] FW: Changes to PW ACH Channel Type all… Vishwas Manral
- Re: [mpls-tp] [PWE3] FW: Changes to PW ACH Channe… Stewart Bryant
- Re: [mpls-tp] [PWE3] FW: Changes to PW ACH Channe… Thomas D. Nadeau
- Re: [PWE3] [mpls-tp] FW: Changes to PW ACH Channe… Andrew G. Malis
- Re: [PWE3] Changes to PW ACH Channel Type allocat… Shane Amante
- RE: [PWE3] FW: Changes to PW ACH Channel Type all… BUSI ITALO
- RE: [mpls-tp] [PWE3] FW: Changes to PW ACH Channe… BUSI ITALO
- Re: [mpls] [PWE3] FW: Changes to PW ACH Channel T… Stewart Bryant
- Re: [mpls-tp] [PWE3] FW: Changes to PW ACH Channe… Vishwas Manral
- Re: [mpls] FW: [PWE3] Changes to PW ACH Channel T… Loa Andersson
- Re: [mpls-tp] [PWE3] FW: Changes to PW ACH Channe… Thomas D. Nadeau
- RE: [mpls-tp] [PWE3] FW: Changes to PW ACH Channe… Shahram Davari
- RE: [mpls] [PWE3] Changes to PW ACH Channel Type … BRUNGARD, DEBORAH A, ATTLABS
- Re: [mpls-tp] [PWE3] FW: Changes to PW ACH Channe… Shane Amante
- Re: [PWE3] [mpls-tp] FW: Changes to PW ACH Channe… Loa Andersson
- Re: [mpls-tp] [PWE3] FW: Changes to PW ACH Channe… Vishwas Manral
- Re: [mpls-tp] [PWE3] FW: Changes to PW ACH Channe… Shane Amante
- RE: [mpls-tp] [PWE3] FW: Changes to PW ACH Channe… Shahram Davari
- RE: [mpls-tp] [PWE3] FW: Changes to PW ACH Channe… BOCCI Matthew
- Re: [mpls] [mpls-tp] [PWE3] FW: Changes to PW ACH… Huub van Helvoort
- RE: [mpls-tp] [mpls] [PWE3] Changes to PW ACH Cha… julien.meuric
- Re: [mpls] [mpls-tp] [PWE3] FW: Changes to PW ACH… Lou Berger
- Re: [mpls-tp] [PWE3] FW: Changes to PW ACH Channe… Thomas D. Nadeau
- RE: [mpls-tp] [PWE3] FW: Changes to PW ACH Channe… Shahram Davari
- RE: [Bulk] Re: [PWE3] [mpls-tp] FW: Changes to PW… Shahram Davari
- Re: [mpls-tp] [PWE3] FW: Changes to PW ACH Channe… Ben Niven-Jenkins
- Re: [mpls-tp] [PWE3] FW: Changes to PW ACH Channe… Ben Niven-Jenkins
- Re: [Bulk] Re: [PWE3] [mpls-tp] FW: Changes to PW… Thomas D. Nadeau
- Re: [mpls-tp] [PWE3] FW: Changes to PW ACH Channe… Shane Amante
- RE: [mpls-tp] [mpls] [PWE3] Changes to PW ACH Cha… BUSI ITALO
- RE: [mpls] [PWE3] FW: Changes to PW ACH Channel T… BUSI ITALO
- RE: [mpls-tp] [PWE3] FW: Changes to PW ACH Channe… BUSI ITALO
- Re: [mpls] [PWE3] FW: Changes to PW ACH Channel T… Stewart Bryant
- RE: [mpls-tp] [PWE3] FW: Changes to PW ACH Channe… BUSI ITALO
- RE: [mpls] [PWE3] FW: Changes to PW ACH Channel T… BUSI ITALO
- RE: [PWE3] [mpls-tp] FW: Changes to PW ACH Channe… Sprecher, Nurit (NSN - IL/Hod HaSharon)
- Re: [PWE3] [mpls-tp] FW: Changes to PW ACH Channe… Luca Martini
- RE: [Bulk] Re: [PWE3] [mpls-tp] FW: Changes to PW… Shahram Davari
- RE: [PWE3] [mpls-tp] FW: Changes to PW ACH Channe… BUSI ITALO
- RE: [PWE3] [mpls-tp] FW: Changes to PW ACH Channe… BUSI ITALO
- Re: [mpls] FW: [PWE3] Changes to PW ACH Channel T… Tom Petch
- RE: [PWE3] [mpls-tp] FW: Changes to PW ACH Channe… Shahram Davari
- RE: [mpls] [PWE3] [mpls-tp] FW: Changes to PW ACH… Eric Gray
- Re: [mpls] FW: [PWE3] Changes to PW ACH Channel T… Sam Aldrin
- RE: [mpls-tp] [mpls] [PWE3] Changes to PW ACH Cha… BRUNGARD, DEBORAH A, ATTLABS
- Re: [mpls-tp] [mpls] [PWE3] Changes to PW ACH Cha… Thomas D. Nadeau
- RE: [PWE3] [mpls-tp] [mpls] Changes to PW ACH Cha… Shahram Davari
- Re: [mpls-tp] [mpls] [PWE3] Changes to PW ACH Cha… Shane Amante
- Re:Changes to PW ACH Channel Type allocation poli… Loa Andersson
- RE: [mpls-tp] FW: [PWE3] Changes to PW ACH Channe… Annamaria Fulignoli
- RE: [mpls] [mpls-tp] [PWE3] FW: Changes to PW ACH… Annamaria Fulignoli
- Re: [mpls] [PWE3] [mpls-tp] FW: Changes to PW ACH… Luca Martini
- RE: [PWE3] [mpls-tp] FW: Changes to PW ACH Channe… Maarten Vissers
- RE: [PWE3] [mpls-tp] FW: Changes to PW ACH Channe… Maarten Vissers
- RE: [PWE3] [mpls-tp] FW: Changes to PW ACH Channe… Alexander Vainshtein
- RE: [mpls] [PWE3] [mpls-tp] FW: Changes to PW ACH… julien.meuric