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

"Alvaro Retana (aretana)" <aretana@cisco.com> Tue, 28 April 2015 21:49 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 B251E1A89F5 for <idr@ietfa.amsl.com>; Tue, 28 Apr 2015 14:49:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5FSicaw6sk1 for <idr@ietfa.amsl.com>; Tue, 28 Apr 2015 14:49:47 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7386A1A8025 for <idr@ietf.org>; Tue, 28 Apr 2015 14:49:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30333; q=dns/txt; s=iport; t=1430257787; x=1431467387; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=cd79w5bK53fTUYpuH/OlwX55UFnL7gnbcTA9uiWAkNE=; b=JVYORvl7xRLv2JfhNRF9bdvJ0Hf70hmU8oscV3lqp7sWbTaf6DNJx4cZ J/cH9u/L8Gf82q+e+g6B0JKN0hbYCM1IhS+H039J4bNk7Pcj6EhZ1q+Ul rNHLrCysnp5bHVJAa3HRNPY6rWYWXXvXv3ZMgzzPIcvGVkY4mzTo4Aw03 Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BTBADm/z9V/5ldJa1SCoJFR4EvBccZCYdXAoE9OBQBAQEBAQEBgQqEIQEBBHkQAgEIOAcHMhQRAQEEAQ0FG4gQx2MBAQEBAQEBAQEBAQEBAQEBAQEBARiKNoEChCIGCwFRB4QtBYZHiHuCI4o/gSONH4Nag1AjgWUiHIFRb4ECBgMXIoEBAQEB
X-IronPort-AV: E=Sophos;i="5.11,666,1422921600"; d="scan'208,217";a="145391596"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-5.cisco.com with ESMTP; 28 Apr 2015 21:49:46 +0000
Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t3SLnk1D000702 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Apr 2015 21:49:46 GMT
Received: from xmb-aln-x15.cisco.com ([169.254.9.76]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Tue, 28 Apr 2015 16:49:46 -0500
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
To: "George, Wes" <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+AAvhvAQD//+ARgA==
Date: Tue, 28 Apr 2015 21:49:45 +0000
Message-ID: <D1656C26.AA776%aretana@cisco.com>
References: <003f01d07394$9b5f1c00$d21d5400$@ndzh.com> <D14DB16F.A4767%aretana@cisco.com> <D1653467.4EEFC%wesley.george@twcable.com>
In-Reply-To: <D1653467.4EEFC%wesley.george@twcable.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.117.15.7]
Content-Type: multipart/alternative; boundary="_000_D1656C26AA776aretanaciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/h-fSrDikdnJbWB8JKh5COu41SmY>
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: Tue, 28 Apr 2015 21:49:50 -0000

On 4/28/15, 3:43 PM, "George, Wes" <wesley.george@twcable.com<mailto:wesley.george@twcable.com>> wrote:

Wes:

Hi!

. . .

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

WG] in the appropriate places in section 3.1 and 3.3, I added "installing the route" to clarify that the behavior that it is prescribes before it sends updates is also done locally. I think this is probably the best compromise between the two different implementations that we can give short of writing a lengthy discussion along the lines of Jeff's email, including discussing this in the context of where one does loop detection, and the fact that it's a SHOULD gives us the right amount of wiggle room. Let me know if you think more changes are necessary.

Honestly, I don’t like this solution.    Your draft shouldn’t cater to a specific implementation, which is why it came back to the WG in the first place.

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

Regardless of which way you go, the text explaining “No Prepend Inbound” can be simplified (for example, in 3.3): s/MUST NOT append the "Local AS" ASN value in the AS_PATH attribute when installing the route or advertising that UPDATE to iBGP neighbors, but/MUST NOT append the "Local AS" ASN value in the AS_PATH attribute, but




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

WG]  Shane and I believe that the current text is correct. Can you explain why you think this needs to be changed?

Yes.

Figure 1 looks like this:

         ------                  ------
       / ISP  A \              / ISP  B \
      | AS 64500 |            | AS 64510 |
       \        /              \        /
        -------                 -------
           |                       |
           |                       |
     ------------             -------------
     |  Cust D  |             |  Cust C   |
     | AS 64499 |             | AS 64496  |
     ------------             -------------

                        Figure 1: Before Migration

So "the AS_PATH toward customer C” (which I interpret as the path to get to C) should be simply 64496 (from B’s point of view).

Note that the rest of the sentence reads: "whereas the same RIB on ISP A' (ISP B routers post-migration) would contain AS_PATH: 64510 64496.”, which corresponds to Figure 2:

                ---------------
              /                \
             |     ISP A'       |
             |     AS 64500     |
              \                /
                ---------------
             /                  \
           /                      \
          |                         |
     ------------             -------------
     |  Cust D  |             |  Cust C   |
     | AS 64499 |             | AS 64496  |
     ------------             -------------

                         Figure 2: After Migration

Where 64510 is the Local AS.




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

WG] you have a valid point, but we aren't exactly sure what a better word would be – tool? Switch? Feature? Option?
We thought feature sounded too vendor-y, and option was already used to identify subsets of the features we're standardizing. FWIW, 4271 uses capability in a similar way, I.e. capitalization is important to disambiguate between the two. I've left it as-is for now, because I'm not convinced that any of the alternatives I've suggested actually works well enough to change it globally.

Mechanism..?

As I said before, just trying to make the text clearer.   No one else mentioned this item (that I know), so it may be clear to everyone else.


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

WG] Shane and I disagree. We think that global vs local is useful, because there is a notion of a global BGP config that applies to all neighbors vs things that are neighbor-specific i.e. Local to a given neighbor.

I see where you’re coming from.  It would be nice to clarify then what you mean by global and local, maybe in the “Documentation Note” section.


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

WG] I removed the vendor-specific part from the abstract and intro, but I believe that the other part that you suggest removing in your second bullet above is important. We can't force vendors to implement exactly what's documented here, especially retroactively, so I think it's reasonable to acknowledge this fact.

We can’t force vendors to implement anything exactly as documented, for any case.  But we don’t call that out in all documents.

It’s nit..  I don’t think that it’s needed, but it’s just a nit.


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

WG] we think that the second paragraph is documenting existing practice/implementations deployed in the field for the purpose of context and background and think it should remain in place, and thus the proposed changes to the third paragraph are duplicative.

The first paragraph says that ""Local AS" and "No Prepend Inbound", only modify the AS_PATH Attribute received…”, which seems to me to be the same thing as (in the second paragraph) ""Local AS" and "No Prepend Inbound” does not concurrently modify the AS_PATH Attribute for BGP UPDATEs that are transmitted”.  IOW, first you say that only received is modified, and then later say that outbound is not, which of course leads to the problem.

To me the second paragraph was the repetitive one and the illustration of the problem would be enough without talking about existing implementations.

Again, just a nit.


Thanks!

Alvaro.