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

"George, Wes" <> Tue, 21 April 2015 19:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C78B21A8A5F for <>; Tue, 21 Apr 2015 12:26:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 2.926
X-Spam-Level: **
X-Spam-Status: No, score=2.926 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id M7_-cmNvgkkD for <>; Tue, 21 Apr 2015 12:26:16 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5741A1B2A53 for <>; Tue, 21 Apr 2015 12:26:15 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.11,617,1422939600"; d="scan'208,217";a="677028002"
Received: from unknown (HELO ([]) by with ESMTP/TLS/RC4-MD5; 21 Apr 2015 15:10:08 -0400
Received: from ([]) by ([]) with mapi; Tue, 21 Apr 2015 15:26:14 -0400
From: "George, Wes" <>
To: "Alvaro Retana (aretana)" <>, "" <>
Date: Tue, 21 Apr 2015 15:26:15 -0400
Thread-Topic: 2 Week WG LC on draft-ietf-idr-as-migration (4/9 to 4/23/2105
Thread-Index: AdB8aQgvi8SCNzpRSSeSOBg1Sogvuw==
Message-ID: <>
References: <003f01d07394$9b5f1c00$d21d5400$> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_D15C183E4E361wesleygeorgetwcablecom_"
MIME-Version: 1.0
Archived-At: <>
Cc: Susan Hares <>, 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: Tue, 21 Apr 2015 19:26:19 -0000

Alvaro, thanks for the review, a few comments below inline:

From: "Alvaro Retana (aretana)" <<>>
Date: Monday, April 13, 2015 at 4:50 PM
To: "George, Wes" <<>>, "<>" <<>>
Cc: "John G. Scudder" <<>>, Idr <<>>, Susan Hares <<>>
Subject: Re: 2 Week WG LC on draft-ietf-idr-as-migration (4/9 to 4/23/2105

I do have one item that I think may be above “minor”: when using “Local AS”, when should the ASN be prepended?  When sending eBGP-received UPDATEs to iBGP neighbors (as it is specified currently), OR, then receiving those eBGP UPDATEs?  If it is not done when receiving, then the AS_PATH will be inconsistent in the AS (the border router will have a shorter AS_PATH).  I think this can lead to inconsistent route selection (given that the attributes are inconsistent inside the AS), but that of course may be mitigated by the fact that the application of Local AS may be towards stub networks in many (but not all) cases.   I would really like to hear others’ (beyond the authors) opinions.

WG] So it seems like we got only one opinion from Juan (though it was couched in terms of "C does this better than J") that we should change this and recommend appending when receiving, rather than when sending in order to maintain route consistency. This makes sense to me. Since Alvaro asked for other opinions, any opinions to the contrary before I assume that the WG supports this and make the change to the draft? Maybe someone from Juniper that has explanation on why they do it the other way, or was Juan mistaken in that assumption?

Minor Issues:

This document should be marked as updating rfc4271 because of the processing of the UPDATEs (section 3.3).

WG] Happy to make that change, but the reason that it wasn't there is that this isn't mandatory to implement. It's not globally changing the behavior of UPDATEs, but rather documenting how they change when this specific optional feature set is invoked. Someone recently gave me guidance on a different draft that it isn't always appropriate to have a draft update an old RFC if the new thing isn't mandatory to implement as a part of the old RFC I.e. A formal update in the metadata means that the two (or more) RFCs together represent a complete BGP implementation, while only implementing the original RFC (the one being updated) would be an incomplete implementation. I don't know if there is an official stance on this as far as the RFC series is concerned, so I'm open to do it either way, need guidance on how to proceed.

WG] some of these are a little more than nits given that you're suggesting removing whole paragraphs. I'll take them under advisement and consultation with my co-author.



Anything below this line has been added by my company’s mail server, I have no control over it.

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.