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

["George, Wes" <[e-mail]>]

Alvaro – A few outstanding items that we may need to discuss inline below. I've posted a –05 that I believe addresses your comments and snipped them out of my response, except where noted below.

Thanks,

Wes


From: "Alvaro Retana (aretana)" <[e-mail]<mailto:[e-mail]>>
Date: Monday, April 13, 2015 at 4:50 PM
To: "George, Wes" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "John G. Scudder" <[e-mail]<mailto:[e-mail]>>, Idr <[e-mail]<mailto:[e-mail]>>, Susan Hares <[e-mail]<mailto:[e-mail]>>
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.  [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.


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?

 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.

 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.

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.

 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.

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

WG] I'm not inclined to explicitly disallow it unless someone can think of a failure case we're trying to avoid. One would think that most implementers would be smart enough to do the right thing here, especially in light of our guidance in a few sentences about what to do if you successfully establish a BGP session with the global ASN

 1.  3.3 s/using the local ASN configured/using the “Local AS”

WG] we are not referring to the command "Local AS" but rather the actual autonomous system number provided as a parameter for the local (neighbor-specific) config, so I think the original text is more accurate.



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