Re: [Idr] Adrian Farrel's Abstain on draft-ietf-idr-as-migration-03: (with COMMENT)

"George, Wes" <> Fri, 20 February 2015 00:29 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4ABB71A1AA4; Thu, 19 Feb 2015 16:29:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.225
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6Wr7BiLU2BLz; Thu, 19 Feb 2015 16:29:29 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 687481A0387; Thu, 19 Feb 2015 16:29:28 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.09,611,1418101200"; d="scan'208";a="219893215"
Received: from unknown (HELO ([]) by with ESMTP/TLS/RC4-MD5; 19 Feb 2015 19:19:41 -0500
Received: from ([]) by ([]) with mapi; Thu, 19 Feb 2015 19:29:27 -0500
From: "George, Wes" <>
To: Adrian Farrel <>, The IESG <>
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: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, "" <>, "" <>, "" <>
Subject: Re: [Idr] Adrian Farrel's Abstain on draft-ietf-idr-as-migration-03: (with COMMENT)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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" <> 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

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



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.