Re: [Idr] 2 Week WG LC on draft-ietf-idr-as-migration

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

Reminder-

I'm still awaiting feedback (whether from Alvaro or other members of the WG or both) on how to address the remaining concerns blocking this draft from proceeding, about where to add the ASN and how to provide that guidance, whether we integrate a variant of the text below, or something else entirely.

Thanks,

Wes


From: "Alvaro Retana (aretana)" <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, April 29, 2015 at 12:59 PM
To: "George, Wes" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: Idr <[e-mail]<mailto:[e-mail]>>, Jeffrey Haas <[e-mail]<mailto:[e-mail]>>
Subject: Re: 2 Week WG LC on draft-ietf-idr-as-migration (4/9 to 4/23/2105

On 4/29/15, 11:08 AM, "George, Wes" <[e-mail]<mailto:[e-mail]>> wrote:

Wes:

Hi!

Thanks for talking this out with me — I really appreciate the patience.  As you, I would also like to hear more from others; this is an important document!

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

Ok..how about this:

       Internal: the router SHOULD append the configured "Local AS" ASN
       in the AS_PATH attribute either before installing the route or
       before advertising the UPDATE to an iBGP neighbor.  Please see section 3.3.1
       for additional guidance.

Then we would need to add a new 3.3.1 section with a short discussion of pros/cons related to the consistency and loop detection angles.

If this works for you, then we can work on the text that goes there.  [I haven’t looked at Jeff’s text in detail yet.]

Thanks!

Alvaro.

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