Re: [v6ops] draft-ietf-v6ops-design-choices WGLC

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

It's a little unclear who said what given the way text was quoted, so I'm just replying to the snippet of text I think is relevant inline below with WG], and then a few other LC comments follow below it.

Thanks,

Wes


/ I value predictability and robustness. Having a eBGP session very specifically tied to an interface tightly couples the eBGP session and the traffic for the prefixes that eBGP session is announcing. The small amount of extra effort required to change a session to a different interface creates further opportunity to catch errors. In some cases, the actual error might be minor, but the consequences of them can be very significant outages.

WG] That is true whether you use a LL or a GUA if you use the interface IP address for eBGP peering instead of loopback multi hop. What's your point in favor of LLN here? Also, what errors are you talking about catching where more manual reconfiguration is the right answer?

/ LLs don't have to be tied to specific hardware addresses, they can be statically set if this is a concern, and hopefully in the future, RFC7217 will be implemented for them in routers, as this is one of the specific use cases for them.

WG] it's worse than that. If you don't statically set LL addresses, they don't show up in the interface configuration, and because they're only locally significant, you have an awful time if you want to actually find the router or interface that is associated with the next-hop (say when chasing a next-hop rewrite problem), because you can't find it in the routing table, and you can't grep through a config repository for the address, and it likely won't be in DNS. The closest you might be able to get is to grep for the address and find the router with the other side of the iBGP session, but this won't work for eBGP because there is no relationship between the neighbor addresses like there is with GUA (+1 / -1).

Philip you may want to add something like this in 2.4.2 (or in 2.1.2 since it's not just relevant to BGP.)

Other comments:
You may want to add a reference to RFC 7439 in 2.4.1 last bullet about MPLS and IPv6
2.4.2: 5925 is not MD5. It obsoleted MD5, but it is properly referred to as TCP AO, so it'd be better to say "MD5 (RFC2385), which while still in wide use, has been obsoleted by TCP AO (RFC5925)"



Anything below this line has been added by my company’s mail server, I have no control over it.
-----------


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