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

From: "George, Wes" <[email-masked]>
Date: Mon, 13 Apr 2015 09:43:43 -0400

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.

---

From: Mark ZZZ Smith <[email-masked]>
Date: Tue, 14 Apr 2015 00:23:04 +0000 (UTC)

Hi Wes,
      From: "George, Wes" <[email-masked]>
 To: v6ops list <[email-masked]> 
Cc: Philip Matthews <[email-masked]> 
 Sent: Monday, 13 April 2015, 23:43
 Subject: Re: [v6ops] draft-ietf-v6ops-design-choices WGLC
   
 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 wheremore manual reconfiguration is the right answer?
/* It seams one of the objections people have is that to use a LL as an eBGP neighbor address you also have to specify the interface name, where as if you used a GUA, the interface is implicit in the BGP configuration, as the binding between the GUA address and interface is somewhere else within the configuration. I think having the both the neighbor address and the interface to use to reach it explicitly specified in the BGP configuration is more robust, as how things are to operate is more obvious (I try to follow a principle of making it obvious how things work, so that if they fail, it is more obvious where to look for the failure.)

/ 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).
/* Which I think is some more evidence that the more explicit and obvious things are, the easier they are to troubleshoot.
/* Regards,Mark.
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 IPv62.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. -----------

_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: "George, Wes" <[email-masked]>
Date: Tue, 14 Apr 2015 12:48:42 -0400

From: Mark ZZZ Smith <[email-masked]<mailto:[email-masked]>>
Reply-To: Mark ZZZ Smith <[email-masked]<mailto:[email-masked]>>
Date: Monday, April 13, 2015 at 8:23 PM
To: "George, Wes" <[email-masked]<mailto:[email-masked]>>, v6ops list <[email-masked]<mailto:[email-masked]>>
Cc: Philip Matthews <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] draft-ietf-v6ops-design-choices WGLC

WG] Interesting view. I'm not convinced of the robustness of that compared with other options since it's also possible to add a comment to the BGP config identifying which interface it's associated with. I think it could be argued either way and this likely comes down to personal preference on your part. However, we're starting to get into a discussion about the relationship between the interface, the BGP session, and the IP, and how tightly bound one should be to the other. We've had a variant of that discussion when talking about how easy/hard renumbering might be since there are IP-address dependent elements of the configuration that exist multiple places instead of being parameterized so that they can be invoked indirectly and only defined one place. It's interesting from a theoretical and philosophical perspective, but I don't know that it helps to improve the document in question.

Thanks,

Wes

---

From: Philip Matthews <[email-masked]>
Date: Tue, 14 Apr 2015 22:30:50 -0400

Wes and Mark (and anyone else)

Would you agree with me that, if one does use LLAs for eBGP endpoints, then:
* One should use LLAs at both ends,  AND
* One should explicitly configure the LLAs at both ends
?

- Philip

PS. Wes: Will do on your "Other comments".  But it seems we are still debating your main point.

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 15 Apr 2015 02:48:26 +0000 (UTC)

Yes and Yes.
More generally it is probably good advice that if you are using a pair of addresses, use addresses of the same scope or type if possible, even though IPv6 can cope with different ones  (e.g., LLs on both ends of an eBGP session, or ULAs or GUAs on both ends of a link rather than a GUA on one end and a ULA on the other.).
I think this ties a bit back to something earlier I discussed about conceptually assigning a prefix to a "link" even though in actuality addresses from within a prefix are assigned to interfaces attached to the link, and not all interfaces need to have addresses from within the prefix. The common implicit assumption in this "assigning prefixes to a link" mental model is that all interfaces attached to the link will have addresses from within the prefix.
Regards,Mark.
      From: Philip Matthews <[email-masked]>
 To: Wes George <[email-masked]>; Mark ZZZ Smith <[email-masked]> 
Cc: v6ops list <[email-masked]> 
 Sent: Wednesday, 15 April 2015, 12:30
 Subject: Re: [v6ops] draft-ietf-v6ops-design-choices WGLC

Wes and Mark (and anyone else)
Would you agree with me that, if one does use LLAs for eBGP endpoints, then:* One should use LLAs at both ends,  AND* One should explicitly configure the LLAs at both ends?
- Philip
PS. Wes: Will do on your "Other comments".  But it seems we are still debating your main point.

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

---

From: Philip Matthews <[email-masked]>
Date: Tue, 14 Apr 2015 23:09:13 -0400

Then perhaps one way to handle this in the draft is to rewrite the section to say "If you use LLAs as endpoint addresses, then here is best practice for how to do it; if you use GUAs as endpoint addresses, then here is best practice for how to do it; and here are the pros and cons of the two approaches".

Just trying to figure out a way forward to something everyone agrees is useful ...

- Philip

On 2015-04-14, at 22:48 , Mark ZZZ Smith wrote:

> Regards,
> Mark.

---

From: Ray Hunter <[email-masked]>
Date: Wed, 15 Apr 2015 08:15:10 +0200

> debating your main point.
If you're going to disucss BGP security in section 2.4.2, you might want 
to add a link to http://www.rfc-editor.org/rfc/rfc7454.txt rather than 
5082 and 5925.

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

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 15 Apr 2015 07:38:31 +0000 (UTC)

That sounds like you're interpreting my suggestion to be BGP specific. I was thinking it is just generally good advice. For example, if you used an LL and a GUA address for something, or a ULA and a GUA, and then later wanted to replace the GUA, you have more work to do. OTOH, if you'd used two LLs for example or two ULAs or two GUAs, you're reducing cross prefix type/scope dependencies.
There are BGP specific considerations that of course should be covered too (as they have been.)
Regards,Mark.
      From: Philip Matthews <[email-masked]>
 To: Mark ZZZ Smith <[email-masked]> 
Cc: Wes George <[email-masked]>; v6ops list <[email-masked]> 
 Sent: Wednesday, 15 April 2015, 13:09
 Subject: Re: [v6ops] draft-ietf-v6ops-design-choices WGLC

Yes and Yes.

---

From: "George, Wes" <[email-masked]>
Date: Wed, 15 Apr 2015 08:47:28 -0400

From: Philip Matthews <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, April 14, 2015 at 10:30 PM
To: "George, Wes" <[email-masked]<mailto:[email-masked]>>, Mark ZZZ Smith <[email-masked]<mailto:[email-masked]>>
Cc: v6ops list <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] draft-ietf-v6ops-design-choices WGLC

WG] yeah, in theory, but this assumes that the other ASN in an eBGP peering is amenable, which in many cases they will not be (I.e. I would tell you to go pound sand and hand you my own GUA to use if you tried to give me a LLA to peer with you on in eBGP), so that recommendation may only be useful for iBGP. I gave similar comments to the authors of 7404 that they were dramatically overselling the popularity of use of LLA, just as I think Mark is here, and I caution you that you're dancing around a potential third rail. There's a reason why 7404 could not achieve consensus without the caveat added to the end of the intro:

   "During WG and IETF last call, the technical correctness of the
   document was reviewed; however, debate exists as to whether to
   recommend this technique.  The deployment of this technique is
   appropriate where it is found to be necessary."

In other words, there was concern that discussing use of LLAs in this manner in an IETF consensus document, even one written as neutrally as possible would be interpreted by those outside of the IETF as "the IETF says to do this". I think the same concern applies here.

* One should explicitly configure the LLAs at both ends
WG] yes. I think my main point supports that recommendation so that it at least shows up in the configuration.

WG] if you do go with your suggested model of discussing considerations around LLAs, then considerations of GUAs, then pros and cons, I think it fits well.

Thanks,
Wes

---

From: joel jaeggli <[email-masked]>
Date: Wed, 15 Apr 2015 08:16:31 -0700

On 4/15/15 5:47 AM, George, Wes wrote:
> To: "George, Wes" <[email-masked]
> <mailto:[email-masked]>>, Mark ZZZ Smith
> <[email-masked] <mailto:[email-masked]>>
> Cc: v6ops list <[email-masked] <mailto:[email-masked]>>
> WG] yeah, in theory, but this assumes that the other ASN in an eBGP
> peering is amenable, which in many cases they will not be (I.e. I would
> tell you to go pound sand and hand you my own GUA to use if you tried to
> give me a LLA to peer with you on in eBGP), so that recommendation may
> only be useful for iBGP. I gave similar comments to the authors of 7404
> that they were dramatically overselling the popularity of use of LLA,
> just as I think Mark is here, and I caution you that you're dancing
> around a potential third rail. There's a reason why 7404 could not
> achieve consensus without the caveat added to the end of the intro: 

As somebody who buys a lot of transit circuits and has built more than a
few PNIs there's really no way I'd accept a LLA numbered transit from a
provider. among other things I have measurement platforms that are going
to want to test the other end of the interface from offlink. for my own
ipam demonstrable uniqueness is good.

We haven't gotten entirely away from the case where ebgp multihop links
exist, for example when you have more than one peering session with the
same provider because the peered router doesn't have a full table. I
expect such things to be terminated on the interface ip since the
loopbacks are for example covered by a router announced over one of
those sessions.

> In other words, there was concern that discussing use of LLAs in this
> manner in an IETF consensus document, even one written as neutrally as
> possible would be interpreted by those outside of the IETF as "the IETF
> says to do this". I think the same concern applies here. 
> 
> WG] if you do go with your suggested model of discussing considerations
> around LLAs, then considerations of GUAs, then pros and cons, I think it
> fits well.
> 
> Thanks,
> Wes
> 
> 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.
> 
>

---

From: Mark ZZZ Smith <[email-masked]>
Date: Thu, 16 Apr 2015 02:26:01 +0000 (UTC)

From: "George, Wes" <[email-masked]>
 To: Philip Matthews <[email-masked]> 
Cc: v6ops list <[email-masked]> 
 Sent: Wednesday, 15 April 2015, 22:47
 Subject: Re: [v6ops] draft-ietf-v6ops-design-choices WGLC

To: "George, Wes" <[email-masked]>, Mark ZZZ Smith <[email-masked]>

<snip>
In other words, there was concern that discussing use of LLAs in this manner in an IETF consensus document, even one written as neutrally as possible would be interpreted by those outside of the IETF as "the IETF says to do this". I think the same concern applies here. 
/ I don't think we should really consider that concern much. There are plenty of useful and informative RFCs that shouldn't have been written published if we were to just target the audience who believe all RFCs are prescriptive. I don't think that "audience" is much of one at all, as their unlikely to spend much if any time reading RFCs. I think the audience we should be targeting is the one who will spend the time reading and considering the contents of RFCs.

* One should explicitly configure the LLAs at both endsWG] yes. I think my main point supports that recommendation so that it at least shows up in the configuration.
PS. Wes: Will do on your "Other comments".  But it seems we are still debating your main point.
WG] if you do go with your suggested model of discussing considerations around LLAs, then considerations of GUAs, then pros and cons, I think it fits well.

Thanks,Wes

---

From: Mark ZZZ Smith <[email-masked]>
Date: Thu, 16 Apr 2015 03:04:10 +0000 (UTC)

From: joel jaeggli <[email-masked]>
 To: "George, Wes" <[email-masked]>; Philip Matthews <[email-masked]> 
Cc: v6ops list <[email-masked]> 
 Sent: Thursday, 16 April 2015, 1:16
 Subject: Re: [v6ops] draft-ietf-v6ops-design-choices WGLC

As somebody who buys a lot of transit circuits and has built more than a
few PNIs there's really no way I'd accept a LLA numbered transit from a
provider. among other things I have measurement platforms that are going
to want to test the other end of the interface from offlink. for my own
ipam demonstrable uniqueness is good.
/ I assume you're describing a link-local only transit link? I wouldn't be advocating that.
/ Choosing to use LLAs instead of also present GUAs for eBGP session end points is actually consistent with the IPv6 src/dest address selection principle of choosing the smallest scope when there are multiple candidate addresses.
/ There are definitely trade-offs if you used LLAs instead of GUAs for eBGP session end points. I like how using LLAs with next-hop self would decouple the eBGP session from the GUA prefix, such that it would be possible to renumber the GUA without disrupting the eBGP session and the traffic that matches the prefixes being announced over the eBGP session, with exception to the traffic matching the prefix for the renumbered GUA itself. Renumbering the GUA on the link is not going to be a common task, but if it is necessary to perform, then the disruption avoided by using LLAs would be significant (e.g., no out of hours work, no significant traffic impact, one less high severity service impact notice etc.)

/ Certainly you'd have to use the GUA addresses for that, as the LL scope is obviously too small to work.

/ Regards,/ Mark.