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

"Alvaro Retana (aretana)" <aretana@cisco.com> Mon, 13 April 2015 20:50 UTC

Return-Path: <aretana@cisco.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 43B761A1A27 for <idr@ietfa.amsl.com>; Mon, 13 Apr 2015 13:50:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.611
X-Spam-Level:
X-Spam-Status: No, score=-12.611 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xrOUyePLRui for <idr@ietfa.amsl.com>; Mon, 13 Apr 2015 13:50:42 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E56C71A0378 for <idr@ietf.org>; Mon, 13 Apr 2015 13:50:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24405; q=dns/txt; s=iport; t=1428958242; x=1430167842; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=yKowrHRUAb5aiZKZsa2Iaf/sn8rLUV60itacV6Y85/o=; b=ZZB4AETVaT5dKQkr4jSqPV2MigmYBEr919JIK1G46eB+hv4On3tTl9ml vh7W+jcGVCT6eoehSvK9o3bnH6jbTO7ZbqmxUHwRHjk3BWJUx/bCQKtth xN3WRCX5WbhyztHLU1NVPGZxwbML0sdMrpKXAtrtC0I49WoDQindb4Nht c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BtBQDhKixV/5ldJa1cgkVHgS4FzGYCgT1MAQEBAQEBfoQgAQEEcgcQAgEIOAcHMhQRAQEEAQ0FiCrNMwEBAQEBAQEBAQEBAQEBAQEBAQEBAReLK4R8B4QtBY5yghqKD4EdgzeJDocKIoNvb4ECBjx/AQEB
X-IronPort-AV: E=Sophos;i="5.11,572,1422921600"; d="scan'208,217";a="411876793"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 13 Apr 2015 20:50:40 +0000
Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t3DKoeFx003073 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Apr 2015 20:50:40 GMT
Received: from xmb-aln-x15.cisco.com ([169.254.9.6]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Mon, 13 Apr 2015 15:50:40 -0500
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
To: "wesley.george@twcable.com" <wesley.george@twcable.com>, "amante@apple.com" <amante@apple.com>
Thread-Topic: 2 Week WG LC on draft-ietf-idr-as-migration (4/9 to 4/23/2105
Thread-Index: AdBzlDcUkdJmp22uTqShwxbVd0A/MgCn6C+A
Date: Mon, 13 Apr 2015 20:50:40 +0000
Message-ID: <D14DB16F.A4767%aretana@cisco.com>
References: <003f01d07394$9b5f1c00$d21d5400$@ndzh.com>
In-Reply-To: <003f01d07394$9b5f1c00$d21d5400$@ndzh.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.117.15.4]
Content-Type: multipart/alternative; boundary="_000_D14DB16FA4767aretanaciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/q7Huis_RFsT69SS7Vy7-rRzlnHk>
Cc: Susan Hares <shares@ndzh.com>, idr wg <idr@ietf.org>
Subject: Re: [Idr] 2 Week WG LC on draft-ietf-idr-as-migration (4/9 to 4/23/2105
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: Mon, 13 Apr 2015 20:50:45 -0000

On 4/10/15, 9:45 AM, "Susan Hares" <shares@ndzh.com<mailto:shares@ndzh.com>> wrote:

Hi!

<AD Hat on>

This is a 2 week WG LC on draft-ietf-as-migration.  As discussed in the IETF 92 session, the feedback on this draft ask for a few changes in format and generalization of implementation terms.  The authors and shepherd believe this has been accomplish with draft-ietf-as-migration-04.txt.   This WG LC is to determine if these revisions are acceptable to the IDR WG.

I believe that the updated document is almost where we want it to be.  In general, there is some tentative language and other things I would like fixed (most minor or nits).  Please see my comments below.

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.  [My comments #3 and #7 in the Minor section below are related to this.]

I support this document moving forward.

Wes/Shane:  Thanks for the work on this!

Alvaro.


[BTW, it may look like a lot of comments, but most of them are editorial.]

Minor Issues:

  1.  3.1 s/Within the Loc-RIB on ISP B prior to the migration, the AS_PATH toward customer C would appear as: 64510/Within the Loc-RIB on ISP B prior to the migration, the AS_PATH toward customer C would appear as: 64496
  2.  The word “capability” is used in several places.  While it is used correctly (from a language point of view), I think it may cause confusion with a BGP Capability (for example: “the "Internal BGP AS Migration"  capability is enabled on all iBGP sessions on that device”).  I know that in this case there is no negotiation of capabilities; just trying to make the text clearer.
  3.  3.1 (see comment #7 below) (second paragraph): s/when advertising UPDATES received from customer C/when receiving UPDATES from customer C
  4.  3.2 s/CE-A would have seen an AS_PATH of: 64496 64510 64500/CE-A would have seen an AS_PATH of: 64500 64510 64496
  5.  3.3 "Implementations MAY support a more flexible model..”  I like this, but I wonder about the relationship of this “MAY” with the “MUST NOT” in "BGP router MUST NOT use the ASN configured globally within the BGP process”.  It sounds as if there’s a contradiction: MUST NOT use it, but you MAY.  I think this contradiction can be easily solved by using “SHOULD NOT” instead of “MUST NOT”.
  6.  This document should be marked as updating rfc4271 because of the processing of the UPDATEs (section 3.3).
  7.  3.3 (See comment #3 above) "the router MUST append the configured "Local AS" ASN in the AS_PATH attribute before advertising the UPDATE to an iBGP neighbor.”  If the Local AS is not appended to the incoming UPDATE, then the border router will have a different AS_PATH than the rest of the network (which is the reason for my comment #3 above).  If you think this is a valid comment, then there are a couple of places that should be cleaned up.
  8.  3.3 I think that the “MUSTs” in the Local AS description should be “SHOULD” given that you later define the options.
  9.  4.2
     *   It may be clearer if instead of "globally configured” and "locally configured”, “New_ASN” and “Old_ASN” (or something to that effect) are used.
     *   In 3.3 you talked about the mechanism being available per-neighbor.  Do we need that same granularity here?

Nits:

  1.  Intro:
     *   Take this ("and may be vendor-specific in exact implementation”) out.
     *   s/These mechanisms are local to a given BGP Speaker and do not require negotiation with or cooperation of BGP neighbors. The deployment of these mechanisms do not need to interwork with one another to accomplish the desired results, so slight variations between existing vendor implementations exist, and will not necessarily be harmonized due to this document. However, it is necessary. . ./These mechanisms are local to a given BGP Speaker and do not require negotiation with or cooperation of BGP neighbors.  It is necessary. . .
  2.  3.1 Take out "usually configured on a per-neighbor basis."
  3.  3.2 s/legacy AS, (AS64510)./legacy AS (AS64510).
  4.  3.2 Delete the second paragraph, which starts with “In some existing implementations”.   Then for the third paragraph: s/[Third paragraph]/A tertiary mechanism, referred to as "Replace Old AS” is used to prevent routers from appending the globally configured ASN in outbound BGP UPDATEs toward directly attached eBGP neighbors that are using the "Local AS” mechanism.  Instead, only the ASN specified using “Local AS" will be prepended in the outbound BGP UPDATE toward the customer's network, restoring the AS_PATH length to what it what was before AS Migration occurred.
  5.  3.3 Delete the first paragraph.
  6.  3.3 s/These mechanisms/The mechanisms introduced in this section
  7.  3.3  Is “peer-group” a well known construct for any implementation?  If it is, then no change is needed..if not, then maybe saying a “group of peers” might work.
  8.  3.3 "When the "Local AS” capability is used, a local ASN will be provided in the configuration that is different from the globally-configured ASN of the BGP router.”  Do you want to provide some guidance here?  SHOULD/MUST it be different?  I guess there’s no real harm (from the point of view of the mechanisms defined) if it is the same..  [Later in the paragraph it says "MUST NOT use the ASN configured globally”, so I guess it is implicit that it has to be different or nothing should happen.]
  9.  3.3 s/using the local ASN configured/using the “Local AS”
  10. 4.1 s/iBGP session, (using identical ASNs)/iBGP session (i.e. using identical ASNs)
  11. 4.1 This sub-section is titled “BGP Alias”, but the mechanism is called "Internal BGP AS Migration”.  Either name is fine with me; you may want to title the section using the same name as the feature, or (if not using alias) with a more descriptive title.
  12. Ordering: Put Section 9 in an actual appendix.  It might be nice to put the Acks after the Security Considerations.