Re: [mpls] Retiring ACH TLVs
Eric Gray <eric.gray@ericsson.com> Tue, 21 May 2013 15:41 UTC
Return-Path: <eric.gray@ericsson.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10BF521F9722 for <mpls@ietfa.amsl.com>; Tue, 21 May 2013 08:41:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level:
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtcPIF5ed5Lt for <mpls@ietfa.amsl.com>; Tue, 21 May 2013 08:41:00 -0700 (PDT)
Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 48DE421F9714 for <mpls@ietf.org>; Tue, 21 May 2013 08:41:00 -0700 (PDT)
X-AuditID: c618062d-b7fb56d0000042e1-b0-519b958b6a18
Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 7E.7D.17121.B859B915; Tue, 21 May 2013 17:40:59 +0200 (CEST)
Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0328.009; Tue, 21 May 2013 11:40:56 -0400
From: Eric Gray <eric.gray@ericsson.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "Stewart Bryant (stbryant) (stbryant@cisco.com)" <stbryant@cisco.com>
Thread-Topic: [mpls] Retiring ACH TLVs
Thread-Index: AQHOUsGO0irUVDlgRIKUWSY/7OcnkJkOj7EAgAE6KXA=
Date: Tue, 21 May 2013 15:40:55 +0000
Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF60ADCBC@eusaamb107.ericsson.se>
References: <CAH==cJy6VWoo0vs2u3R=Pu8q6S4EAm=KWAGyvAODEd5GvKNCXg@mail.gmail.com> <025801ce5579$141f9160$3c5eb420$@olddog.co.uk>
In-Reply-To: <025801ce5579$141f9160$3c5eb420$@olddog.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.134]
Content-Type: multipart/alternative; boundary="_000_48E1A67CB9CA044EADFEAB87D814BFF60ADCBCeusaamb107ericsso_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyuXSPt2731NmBBseumFn86LnBbLHi9DNm i1tLV7JanHs6h9GBxWPK742sHjtn3WX3WLLkJ5PHis0rGQNYorhsUlJzMstSi/TtErgyJva8 YC2Yd4yx4ur7XrYGxk1rGLsYOTkkBEwkDkxsYoawxSQu3FvP1sXIxSEkcJRR4s7D11DOckaJ 40tOsIBUsQloSBy7sxaom4NDRKBC4sqBAJAws4CHxOl7J9lBbGEBVYkTS06DDRURUJPYf/oz C4RtJfHxCMhMTg4WoJpTl9uYQMbwCnhLLJ8mDLGqkVFi5e4GsHpOAWuJ7uPLwOoZgY77fmoN E8QucYlbT+YzQRwtILFkz3moB0QlXj7+xwphK0ssebKfBaI+X2LSghlg9bwCghInZz5hmcAo OgvJqFlIymYhKYOI60gs2P2JDcLWlli28DUzjH3mwGMmZPEFjOyrGDlKi1PLctONDDYxAiPw mASb7g7GPS8tDzFKc7AoifO2ak8NFBJITyxJzU5NLUgtii8qzUktPsTIxMEp1cC45cVt1iPu VxUTH/+3mH9w+esKOU25M/MWhP3+bLyya7pX9ZnosJcGpw4VVvznPRzw1D7QWPDcOsEzq2pn HFnrLrhxX4mcTOLbFXy+aqYtKrMS2lZXPjw9RePf1T6dt09/eBzT3btvdXQAU7zflFSdR+Ln Wx/5H9kpsfK+kN3x+yfWTvmk5x8UqMRSnJFoqMVcVJwIALkNAwaOAgAA
Cc: "mpls@ietf.org" <mpls@ietf.org>, 'Lizhong Jin' <lizho.jin@gmail.com>
Subject: Re: [mpls] Retiring ACH TLVs
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 May 2013 15:41:06 -0000
Adrian/Stewart, I believe that past precedence exists in abundance to indicate that - if we produce an RFC that updates RFC 5586, we do not also need to produce an RFC that replaces it for the same purpose. For instance, RFC 5586 was updated by RFC 6423. There are a number of RFCs that change the name space(s) defined in an earlier RFC for IANA's management. I believe that - as long as IANA has an unambiguous understanding of the current applicable state for registries IANA manages - an updating RFC is sufficient. If we were - for some reason - required to replace RFC 5586 at a later date (this might be needed to "advance" the standard, for instance), I assume we would "roll-up" all updates (and errata) that are still applicable. Once an update that removes ACH TLVs has been published (or is near to being published), it should no longer be necessary for folks submitting related drafts to explain why ACH TLVs are not supported. Therefore I support the quicker approach of publishing an RFC to update RFC 5586 and suggest that this is sufficient for now. -- Eric From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Monday, May 20, 2013 12:43 PM To: 'Lizhong Jin' Cc: mpls@ietf.org Subject: Re: [mpls] Retiring ACH TLVs Hi Lizhong, I just went back and checked 5586. In Section 4 it talks about "ACH TLVs if present." And I am working on the assumption that if TLVs are not defined, they will never be present, so the text doesn't actually need updating. In Section 10 there is the IANA work to create the ACH TLV registry and add the column to the ACH Type registry. We are directly instructing IANA to remove that from the registry, and I don't think that 5586 needs to be updated. Our aim was minimal and clear update to 5586 rather than a new revision. If the WG prefers, we could bis 5586 to remove all discussion of the ACH TLV. Thanks, Adrian From: Lizhong Jin [mailto:lizho.jin@gmail.com] Sent: 17 May 2013 06:44 To: mpls@ietf.org<mailto:mpls@ietf.org>; adrian@olddog.co.uk<mailto:adrian@olddog.co.uk> Subject: Re: [mpls] Retiring ACH TLVs Hi, Support, and I like this. But it seems deleting section 3 in RFC5586 is not enough. Other sections in RFC5586 also has the content of ACH TLV. Is it engouth to update by only deleting section 3 described in this draft? Lizhong On Tue, May 7, 2013 at 1:08 PM, Adrian Farrel <adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>> wrote: > Hi, > > ACH TLVs keep popping up and causing Stewart and me trouble. Mainly it is > about explaining why no-one actually wants to use them (i.e., when each new > ACH Type is defined and has a "No TLVs" written for it, we get asked "why > not?"). > > It seems to us that ACH TLVs are an idea that has been rejected. Initially > we thought they might be used (especially for identifiers), but there seems > to be good opinion that handling generic TLVs would be a pain. > > Since I was heavily responsible for insisting that ACH TLVs were included > in RFC 5586, it seems reasonable that I do the work to fix it. > > The I-D below retires ACH TLVs and handles the necessary registry changes. > > Note, of course, that structured data are still possible within individual > ACHs if the protocol spec for an individual ACH decides to have them. > > We're directing this work to the MPLS working group because that is where > 5586 was written. I have BCC'ed PWE3, L2VPN, and BFD for information. > > Thanks for any comments. > > As humble WG contributors we would be enthusiastic to see early WG > adoption and last call :-) > > Thanks, > Adrian > > > -----Original Message----- > > From: internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> [mailto:internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>] > > Sent: 07 May 2013 17:33 > > To: Adrian Farrel; Stewart Bryant > > Subject: New Version Notification for > draft-farbryantrel-mpls-retire-ach-tlv- > > 00.txt > > > > > > A new version of I-D, draft-farbryantrel-mpls-retire-ach-tlv-00.txt > > has been successfully submitted by Adrian Farrel and posted to the > > IETF repository. > > > > Filename: draft-farbryantrel-mpls-retire-ach-tlv > > Revision: 00 > > Title: Retiring TLVs from the Associated Channel Header > of the MPLS > > Generic Associated Channel > > Creation date: 2013-05-07 > > Group: Individual Submission > > Number of pages: 4 > > URL: > http://www.ietf.org/internet-drafts/draft-farbryantrel-mpls-retire- > > ach-tlv-00.txt > > Status: > http://datatracker.ietf.org/doc/draft-farbryantrel-mpls-retire-ach-tlv > > Htmlized: > http://tools.ietf.org/html/draft-farbryantrel-mpls-retire-ach-tlv-00 > > > > > > Abstract: > > The MPLS Generic Associated Channel (G-ACh) is a generalization of > > the applicability of the Pseudowire (PW) Associated Channel Header > > (ACH). RFC 5586 defines the concept of Type-Length-Variable (TLV) > > constructs that can be carried in messages on the G-ACh by placing > > them in the ACH. > > > > No Associated Channel Type yet defined uses a TLV. Furthermore, it > > is believed that handling TLVs in hardware introduces significant > > problems to the fast-path, and since G-ACh messages are intended to > > be processed substantially in hardware, the use of TLVs in > > undesirable. > > > > This document updates RFC 5586 by retiring ACH TLVs and removing the > > associated registry. > > > > > > > > > > The IETF Secretariat > > _______________________________________________ > mpls mailing list > mpls@ietf.org<mailto:mpls@ietf.org> > https://www.ietf.org/mailman/listinfo/mpls > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.ietf.org/mail-archive/web/mpls/attachments/20130516/f560777c/attachment.htm> ------------------------------
- [mpls] Retiring ACH TLVs Adrian Farrel
- Re: [mpls] Retiring ACH TLVs Nitin Bahadur
- Re: [mpls] Retiring ACH TLVs Giles Heron
- Re: [mpls] Retiring ACH TLVs Carlos Pignataro (cpignata)
- Re: [mpls] Retiring ACH TLVs Dan Frost
- Re: [mpls] Retiring ACH TLVs Sam Aldrin
- Re: [mpls] Retiring ACH TLVs George Swallow (swallow)
- Re: [mpls] Retiring ACH TLVs Jeff Tantsura
- Re: [mpls] Retiring ACH TLVs David Allan I
- Re: [mpls] Retiring ACH TLVs Shahram Davari
- Re: [mpls] Retiring ACH TLVs Pablo Frank
- Re: [mpls] Retiring ACH TLVs Yaakov Stein
- Re: [mpls] Retiring ACH TLVs Lizhong Jin
- Re: [mpls] Retiring ACH TLVs Adrian Farrel
- Re: [mpls] Retiring ACH TLVs Adrian Farrel
- Re: [mpls] Retiring ACH TLVs Stewart Bryant
- Re: [mpls] Retiring ACH TLVs Lizhong Jin
- Re: [mpls] Retiring ACH TLVs Eric Gray