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

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

From: "Alvaro Retana (aretana)" <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, April 28, 2015 at 5:49 PM

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.

WG] I don't understand how that caters to a specific implementation, especially since 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?



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

WG] Ok, that seems to be a potentially useful change. Does it address your problem though? I'm kind of at a loss on how to address this better (which is why I'm frustrated, not because I don't appreciate the feedback), and could use some feedback from some other WG folk on the new text or ways to fix it without dramatically expanding the scope of the discussion in this document.

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

WG] Ah. That's the issue. It's not the path to get TO C. It's the path ANNOUNCED by B toward C. Since it's looking like there's one more revision coming, I'll  clarify that.


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.

WG] no, but typically we're not retroactively standardizing something that’s already implemented, so it's not necessary to call it out in all documents.

Thanks
Wes

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