Re: [Idr] Adrian Farrel's Abstain on draft-ietf-idr-as-migration-03: (with COMMENT)
"George, Wes" <wesley.george@twcable.com> Fri, 20 February 2015 00:29 UTC
Return-Path: <wesley.george@twcable.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ABB71A1AA4; Thu, 19 Feb 2015 16:29:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.225
X-Spam-Level:
X-Spam-Status: No, score=0.225 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Wr7BiLU2BLz; Thu, 19 Feb 2015 16:29:29 -0800 (PST)
Received: from cdcipgw02.twcable.com (cdcipgw02.twcable.com [165.237.91.111]) by ietfa.amsl.com (Postfix) with ESMTP id 687481A0387; Thu, 19 Feb 2015 16:29:28 -0800 (PST)
X-SENDER-IP: 10.136.163.15
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="5.09,611,1418101200"; d="scan'208";a="219893215"
Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdcipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 19 Feb 2015 19:19:41 -0500
Received: from PRVPEXVS10.corp.twcable.com ([10.136.163.41]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Thu, 19 Feb 2015 19:29:27 -0500
From: "George, Wes" <wesley.george@twcable.com>
To: Adrian Farrel <adrian@olddog.co.uk>, The IESG <iesg@ietf.org>
Date: Thu, 19 Feb 2015 19:29:24 -0500
Thread-Topic: Adrian Farrel's Abstain on draft-ietf-idr-as-migration-03: (with COMMENT)
Thread-Index: AdBMpEf0u/QHNA/ZR+eaM7XDxdzQ7Q==
Message-ID: <D10B9264.4471F%wesley.george@twcable.com>
References: <20150219142542.32426.43010.idtracker@ietfa.amsl.com>
In-Reply-To: <20150219142542.32426.43010.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.8.150116
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/5og7X31i7vKuCXGjsK6sY-ZmUkU>
Cc: "morrowc@ops-netman.net" <morrowc@ops-netman.net>, "idr@ietf.org" <idr@ietf.org>, "draft-ietf-idr-as-migration.all@ietf.org" <draft-ietf-idr-as-migration.all@ietf.org>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>
Subject: Re: [Idr] Adrian Farrel's Abstain on draft-ietf-idr-as-migration-03: (with COMMENT)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Feb 2015 00:29:31 -0000
Snipped where possible. My comments below inline with WG] On 2/19/15, 9:25 AM, "Adrian Farrel" <adrian@olddog.co.uk> wrote: >The document seems to address four topics: >- Requirements for and circumstances of AS migration >- Behavior needed from a BGP system when migrating AS numbers >- Mechanisms that a BGP implementation can use to provide the > behavior >- Description of the mechanisms and configuration options contained in > specific implementations > >As Alvaro wrote: > >> o The Introduction is very tentative about the purpose: it wants to >> document de facto standards for future implementations and so >> that new features (BGPSec) take them into consideration..but it is >> not expecting all implementation to follow exactly (at least not the >> existing ones). My question is: should this be Informational instead >> of Standard? WG] See my response to Pete's DISCUSS. Frankly, this document exists because we got told early on in the life of the SIDR document that we needed to standardize the behavior (in IDR) before we could really tell SIDR that they weren't allowed to break it with BGPSec and propose a solution. That made sense to me, because while BGPSec is the current concern, there's no guarantee that there won't be other changes to BGP in the future that might need to take this behavior into account. So we split the AS migration stuff into its own document, and the SIDR document focuses exclusively on how to make BGPSec work with AS Migration. I'm not sure what that really translates to from a document status (or even a content) perspective between these two parallel drafts. I'm just going with consensus thus far. > >The third bullet is somewhat suspect. Maybe it is an advisory appendix, >but the list of ways to provide the function is unbounded and there is >no requirement for interoperability. I am not sure that publshing this >information is a great benefit. Maybe it is not harmful although it >might tend to reduce innovation and give vendors and operators >expectations about mechanisms that should be used within >implementations. WG] As noted elsewhere, this is a locally specific implementation, so interop isn't required. Consistency of behavior is useful, but I'm not convinced that we're going to be able to force that by being more generic and more prescriptive, nor am I convinced that there is much innovation to be had here such that we'd stifle it. IETF has a decision point here: do we document the desired behavior as if no implementations currently exist and then reserve any acknowledgment of the existing implementations for an implementation report or appendix, or do we acknowledge that we're documenting existing behaviors as something like the union of the features provided across the different vendor-specific implementations? There is precedent for documenting one vendor's implementation of something when they want to make it available to other implementers, but I'm not aware of any precedent for this when it's multiple vendors such as this document, especially when none of the vendors in question are authors. IMO, the problem with the first choice is that we now find ourselves in the situation where we are essentially telling vendors that their existing implementations are not compliant with our ex post facto standard, and I'm not sure that has any real benefit. As people are fond of saying, IETF isn't the protocol police, but when customers ask vendors for support of a certain feature, if there's an RFC that documents it, they often refer to it in shorthand as "support for RFCnnnn" with the expectation that it will be fully supported without having to explain every possible part of the desired feature or behavior. This draft took a more pragmatic view, "...Rough consensus and running code." and all that... > >I find the final bullet very suspect. It goes beyond an implementation >report and enters into the world of sales. While the document makes no >explicit analysis of the pros and cons of the different implementations, >described, there is a lot between the lines. Furthermore, by not >documenting the mechanisms in other implementations, the document gives >the false impression that the three implementations described are the >benchmark for AS migration. It might be possible to move this material >to an appendix or a separate implementation document, but as the authors >note, much or all of the information can be found on the websites of the >companies concerned, and I think that is where it should stay. WG] IDR requires implementation/interop reports. Given that this is a bit of a "cart before horse" situation, where we are documenting existing implementations, I think some mention of the vendor-specific implementations is necessary. The info can be found on the websites, but given that at least one of those links had gone 404 in the time since the initial draft was written and had to be updated, I do not hold much hope that the URIs will actually be useful references as this document ages. Whether that means we need more info in the document instead is open for discussion. As to "you used C and J in your examples but not A or H or..." - There are representatives from all of those vendors present at IETF and AFAIK participating in IDR, and they are more than welcome to contribute text to address the concern around unequal discussion of each vendor-specific implementation within the draft. No slight or endorsement was intended. That said, I am not convinced that a complete documentation of every vendor's flavor of this is useful or appropriate, and your comments seem to agree. The authors chose examples based on what we were familiar with. Already we struggled with the issue of terminology, because I got reviews from folks at both C and J who got cross if I used the other's term or didn't document the behavior exactly as they implemented it, but it didn't make sense to invent completely new terms just to avoid using one of the pre-existing terms. Additionally, because this behavior was initially vendor-specific, there is a non-trivial amount of overlap between implementations. Basically, an operator looked at a feature provided by one vendor and told another either "do it like that" or "do it mostly like that, but give me this additional optimization". We tried to split the difference with the normative text. So I guess the question is whether or not this document stands alone/is useful with just the normative text and much less in the way of examples to tie it to the existing implementations. Randy's comments seem to say yes (though he was commenting more specifically on the business drivers). I will go with consensus on the matter. >Here are the minor comments and nits... WG] These will be addressed. Thanks, Wes This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
- [Idr] Adrian Farrel's Abstain on draft-ietf-idr-a… Adrian Farrel
- Re: [Idr] Adrian Farrel's Abstain on draft-ietf-i… Susan Hares
- Re: [Idr] Adrian Farrel's Abstain on draft-ietf-i… Alia Atlas
- Re: [Idr] Adrian Farrel's Abstain on draft-ietf-i… Alvaro Retana (aretana)
- Re: [Idr] Adrian Farrel's Abstain on draft-ietf-i… George, Wes
- Re: [Idr] Adrian Farrel's Abstain on draft-ietf-i… Alvaro Retana (aretana)
- Re: [Idr] Adrian Farrel's Abstain on draft-ietf-i… Adrian Farrel
- Re: [Idr] Adrian Farrel's Abstain on draft-ietf-i… Jeffrey Haas