Re: [Idr] 2 Week WG LC on draft-ietf-idr-as-migration (4/9 to 4/23/2105

"Alvaro Retana (aretana)" <> Wed, 29 April 2015 16:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5CAD41A88A5 for <>; Wed, 29 Apr 2015 09:59:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1-yzRpny6CJf for <>; Wed, 29 Apr 2015 09:59:07 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 42E871ACCFE for <>; Wed, 29 Apr 2015 09:59:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=12334; q=dns/txt; s=iport; t=1430326747; x=1431536347; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vFyI/QCRUcK+cYoiDqAHdEnZdrvtLGVLwyhw6w2Qx6E=; b=X02ZWNey0cio7N2775Rw7Fn+BoXYT5mYUbfIpoaDM79Upeg0fIQTYWZF wGDjdsBmsL1HCKf6l37K/ywQ96RMFX9kX45oSkPPLIUXH4mbN+G7GCr4S 5lrQGmtqhfoo36aX44SMTAXeK57Y9EVZrPryIePbELcUngeDEuz1qmpQH g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.11,671,1422921600"; d="scan'208,217";a="415779528"
Received: from ([]) by with ESMTP; 29 Apr 2015 16:59:05 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t3TGx4I4002615 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Apr 2015 16:59:04 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Wed, 29 Apr 2015 11:59:04 -0500
From: "Alvaro Retana (aretana)" <>
To: "George, Wes" <>, "" <>
Thread-Topic: 2 Week WG LC on draft-ietf-idr-as-migration (4/9 to 4/23/2105
Thread-Index: AdBzlDcUkdJmp22uTqShwxbVd0A/MgCn6C+AAvhvAQD//+ARgIABZWQA///buYA=
Date: Wed, 29 Apr 2015 16:59:04 +0000
Message-ID: <>
References: <003f01d07394$9b5f1c00$d21d5400$> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_D1667AA1AAA02aretanaciscocom_"
MIME-Version: 1.0
Archived-At: <>
Cc: idr wg <>
Subject: Re: [Idr] 2 Week WG LC on draft-ietf-idr-as-migration (4/9 to 4/23/2105
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: Wed, 29 Apr 2015 16:59:09 -0000

On 4/29/15, 11:08 AM, "George, Wes" <<>> wrote:



Thanks for talking this out with me — I really appreciate the patience.  As you, I would also like to hear more from others; this is an important document!

. . .
WG] . . . several folks in the WG seem to agree that the better solution is to add the AS on receipt so that the route is consistent within the AS in order to avoid loops.

I would prefer to see a definite statement.  If you don’t want to exclude one of the options then pick one (SHOULD — for the "right amount of wiggle room") and then mention the other as an option (MAY).  In the end the effect is the same (no one is excluded), but the answer to “When should I prepend?” is clearer:  do it when you SHOULD (but you MAY also do it at other times).

WG] Well, I'm trying to avoid either re-hashing the apparent disagreement between the vendors, having to discuss deep details about multiple vendors' implementation choices to explain the should vs may and/or being responsible for fixing an existing ambiguity in the BGP spec, especially since at least one of those things is, as you said, the reason that this draft came back to the WG in the first place. Since email is bad at conveying tone, I should be clear that while I am a bit frustrated, I'm not trying to be combative here. It appears to me that there isn't a single right answer to the question you're posing, so I don't really know what the definite statement should be, which is why I didn't make it.

The closest I've found is the last bit of Jeff's April 21 email, but even that is only discussing the gotchas, not making a definite statement:
"The issue has to do with where an implementation does its loop detection.
Some implementations do loop detection at every BGP speaker.  Some do them
only at an ebgp edge.  Some bias this behavior based on local-as being
enabled or not.  How you do your loop detection and when heavily biases your
choice of implementation.  In implementations that only requires local-as at
your ebgp edges but do loop detection at route reflectors/external confederation
routers, adding your local-as as part of import is a problem.

So, consistency isn't only a big deal as part of when/where you do your
local-as prepend, it's also a matter of where you do loop detection.  If
implementations in the absence of some "outside the scope" implementation
were to pedantically implement the base BGP RFC, the migration mechanisms
would be a bit biased to a given solution."

Would something like this text be the right level of background info to provide unambiguous but unbiased guidance without requiring pages of additional discussion? about this:

       Internal: the router SHOULD append the configured "Local AS" ASN
       in the AS_PATH attribute either before installing the route or
       before advertising the UPDATE to an iBGP neighbor.  Please see section 3.3.1
       for additional guidance.

Then we would need to add a new 3.3.1 section with a short discussion of pros/cons related to the consistency and loop detection angles.

If this works for you, then we can work on the text that goes there.  [I haven’t looked at Jeff’s text in detail yet.]