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

[Jeffrey Haas <[e-mail]>]

[feeling too lazy to trim too much]

The "gotcha" I point out below is a big one: It tells you that behavior of
when you prepend is only half the problem and when you do loop detection is
the other half.  If we're going to get hung up in pedantic land (not your
fault, Wes), this means that we should hold the document and take the
appropriate surveys about loop detection.  Consistency of the behavior with
a given AS is critical - and thus has a bias towards similar behaviors from
vendors.

If you decide to make a recommendation about one behavior or the other,
you're going to reduce this to a popularity contest.  While WG participants
may feel strongly about their particular implementation of when they
prepend, they may not like what the deep introspection into the security
and operational impacts of when loop detection is done means.

The text below, which notes that both are acceptable options, but choose
based on when loop detection is done would support the right part of such a
discussion.  I'm supportive of adding appropriate text.


-- Jeff (and people wonder why we're hesitant to document long working hacks)

On Tue, May 12, 2015 at 03:47:33PM -0400, George, Wes wrote:
> 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.