Subject: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-12.txt

From: [email-masked]
Date: Sun, 13 Nov 2016 09:52:13 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Operations of the IETF.

        Title           : Routing-Related Design Choices for IPv6 Networks
        Authors         : Philip Matthews
                          Victor Kuarsingh
	Filename        : draft-ietf-v6ops-design-choices-12.txt
	Pages           : 26
	Date            : 2016-11-13

Abstract:
   This document presents advice on certain routing-related design
   choices that arise when designing IPv6 networks (both dual-stack and
   IPv6-only).  The intended audience is someone designing an IPv6
   network who is knowledgeable about best current practices around IPv4
   network design, and wishes to learn the corresponding practices for
   IPv6.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-v6ops-design-choices-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-design-choices-12

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Philip Matthews <[email-masked]>
Date: Mon, 14 Nov 2016 03:20:39 +0900

Folks:

Victor and I spun out this new version to fix a few small things:

1.  Change title to "Routing-Related Design Choices for IPv6 Networks".  This title change re-enforces the scope of the document. The abstract and introduction have said "routing-related" for a while, but a few readers seem to miss this.  This change has been suggested to us a few times in the past, including by Tim Chown in his review of the document at the behest of the chairs a year ago.

2.  Added pointer to "General Observations" section.  In re-reading Tim's review, we also noticed that he had suggested that we move our section called "General Observations" to the front of the document. The "General Observation" section discusses the fact that many design choices around IPv6 stem from the concepts of link-local addresses and separation between v4 and v6. Victor and I discussed Tim's suggestion, but decided we would leave the "General Observation" section where it was for now, and add a pointer to it in the introduction. Hence we added the following sentences to the introduction:
   "Section 2 presents and discusses a number of design choices. Section 3 discusses some general themes that run through these choices."

3. Fixed the references. There were a number of missing references and missing xrefs in the -10 and -11 versions.  These are now fixed.

Comments on these changes are welcome, including during our presentation this afternoon.

-Philip

On 2016-11-14, at 2:52 , [email-masked] wrote:

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

---

From: Tim Chown <[email-masked]>
Date: Mon, 14 Nov 2016 04:03:04 +0000

Hi,

This document is now looking pretty good, given the latest discussions and updates, and with the explicit routing focus.

I really like the style of presenting pros and cons in the way that you have; it reads very well.

A few comments:

- There’s still a reference to the Experimental NPTv6 RFC 6296. I guess this may remain contentious :)

- The document excludes IPv6 over MPLS in the intro, then seems to discuss it in 2.1.2?

- IPv6 PI is getting easier to get - see https://www.ripe.net/publications/docs/ripe-655#IPv6_PI_Assignments for RIPE region.

You might also want to do a quick sweep of the recently published https://tools.ietf.org/html/draft-ali-ipv6rtr-reqs-00 to check for consistency.

If you’re interested in checking out how the biggest v6 deployment of any UK university is done, which includes routing notes, see http://www.ipv6.org.uk/wp-content/uploads/2016/11/UKIPv6Council-2016-IPv6-deployment-at-Imperial.pdf.

Best wishes,
Tim

On 13 Nov 2016, at 18:20, Philip Matthews <[email-masked]<mailto:[email-masked]>> wrote:

Folks:

-Philip

On 2016-11-14, at 2:52 , [email-masked]<mailto:[email-masked]> wrote:

Abstract:

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

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

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 Nov 2016 17:12:57 +1300

> - There’s still a reference to the Experimental NPTv6 RFC 6296. I guess this may remain contentious :)

Yes. It's like telling people it's a bad idea to stuff beans up their noses,
followed by instructions on how to do it.

> - IPv6 PI is getting easier to get - see https://www.ripe.net/publications/docs/ripe-655#IPv6_PI_Assignments for RIPE region.

Maybe. But we know this is never going to happen for tens of millions of small
businesses, so I think the alternatives have to be presented as neutrally as
possible.

    Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 14 Nov 2016 14:00:43 +0900

> followed by instructions on how to do it.

+1. I'd prefer to remove this citation.

> > - IPv6 PI is getting easier to get - see https://www.ripe.net/
> publications/docs/ripe-655#IPv6_PI_Assignments for RIPE region.
>

Host addressing is out of scope for this draft, so it doesn't matter so
much, but if we're talking about multihoming we should note that the best
approach for smaller networks is multihoming using PA addresses via
source+destination based routing. That is is being pursued in the homenet
and routing working groups.

---

From: Tim Chown <[email-masked]>
Date: Mon, 14 Nov 2016 05:18:17 +0000

On 14 Nov 2016, at 05:00, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:

Host addressing is out of scope for this draft, so it doesn't matter so much, but if we're talking about multihoming we should note that the best approach for smaller networks is multihoming using PA addresses via source+destination based routing. That is is being pursued in the homenet and routing working groups.

So as per the mic comment the design choices draft could/should distinguish between multihoming and change of provider scenarios.

Tim

---

From: Philip Matthews <[email-masked]>
Date: Wed, 16 Nov 2016 13:48:04 +0900

On 2016-11-14, at 14:18 , Tim Chown wrote:

>> On 14 Nov 2016, at 05:00, Lorenzo Colitti <[email-masked]> wrote:
>> 
>> On Mon, Nov 14, 2016 at 1:12 PM, Brian E Carpenter <[email-masked]> wrote:

I know some people don't like it. But, as has been mentioned a couple of times this week, some operators are doing it. 

Anyway, someone orally proposed a re-wording of this sentence at the meeting that people seemed to find not too bad.  I have forgotten the details, but will pull it from the recording. 

>> businesses, so I think the alternatives have to be presented as neutrally as

We will look at the new policies and see if some tweaks to the wording is appropriate. However, I agree with Brian that millions of small businesses are unlikely to get PI space. It may be easier, but you still must apply, and convince the RIR that you qualify, and then pay the annual fee.  The only way I could see this happening for mom-and-pop florist is if someone does all the work on their behalf.  And ... do we really want millions of small businesses to get PI space??? "News at 11 -- Global routing tables hit the 10 million routes mark".

> So as per the mic comment the design choices draft could/should distinguish between multihoming and change of provider scenarios. 

I thought we did, but will look at this again.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 16 Nov 2016 14:03:23 +0900

On Wed, Nov 16, 2016 at 1:48 PM, Philip Matthews <[email-masked]>
wrote:
>
> do we really want millions of small businesses to get PI space??? "News at
> 11 -- Global routing tables hit the 10 million routes mark".
>

If you discuss this topic in this draft, then please discuss
draft-bowbakova-rtgwg-enterprise-pa-multihoming-01 , since that (or
something like that) is the real solution to the problem.

---

From: Tim Chown <[email-masked]>
Date: Wed, 16 Nov 2016 05:07:29 +0000

On 16 Nov 2016, at 05:03, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Nov 16, 2016 at 1:48 PM, Philip Matthews <[email-masked]<mailto:[email-masked]>> wrote:
do we really want millions of small businesses to get PI space??? "News at 11 -- Global routing tables hit the 10 million routes mark".

If you discuss this topic in this draft, then please discuss draft-bowbakova-rtgwg-enterprise-pa-multihoming-01 , since that (or something like that) is the real solution to the problem.

+1

Again, the text can differentiate the case of multihoming (use Jen & co's work) vs the case of resilience to a change of ISP.

Tim

---

From: Mark Smith <[email-masked]>
Date: Wed, 16 Nov 2016 17:58:28 +1100

Hi,

[email-masked]> wrote:
> I know some people don't like it. But, as has been mentioned a couple of
times this week, some operators are doing it.
>
> Anyway, someone orally proposed a re-wording of this sentence at the
meeting that people seemed to find not too bad.  I have forgotten the
details, but will pull it from the recording.

Thinking about the new version, and the above, I think there may still be
some scope issues.

If this is purely about local IPv6 routing configuration in a local
network, then I think the discussion of the differences and issues of
ULA/PI/PA is irrelevant. The choice is a link-local only scheme or one
which also uses > link local scope addresses.

ULA vs PI vs PA only matters if the network is connected to the Internet,
which is more of an external routing issue and more of one that is
significant to hosts, although there is the issue of allowing external
traceroutes inwards, and some ICMPv6 outbound with source addresses that
don't get dropped by martian filters.

(I'd agree that most routed IPv6 networks will be connected to the
Internet, but it is not a requirement. If that is currently an unstated
assumption and context for the whole document, then I think it should be
stated.)

Also, if it is a snapshot if what is happening now, then it could discuss
pros and cons of what people are doing, however if it provides advice, then
it is crossing over into BCP sort of territory, and what people are
currently doing might not be good examples of what to do. (I too agree that
mentioning NPTv6 like it has been comes across as tacit approval of it
("I'll just leave this here <wink>" seems like missing text.))

Regards,
Mark.

>>>
>>>>
>>>> > - IPv6 PI is getting easier to get - see
https://www.ripe.net/publications/docs/ripe-655#IPv6_PI_Assignments for
RIPE region.
> We will look at the new policies and see if some tweaks to the wording is
appropriate. However, I agree with Brian that millions of small businesses
are unlikely to get PI space. It may be easier, but you still must apply,
and convince the RIR that you qualify, and then pay the annual fee.  The
only way I could see this happening for mom-and-pop florist is if someone
does all the work on their behalf.  And ... do we really want millions of
small businesses to get PI space??? "News at 11 -- Global routing tables
hit the 10 million routes mark".
>>
>>
>> So as per the mic comment the design choices draft could/should
distinguish between multihoming and change of provider scenarios.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 16 Nov 2016 16:57:05 +0900

+1

> (I too agree that mentioning NPTv6 like it has been comes across as tacit
> approval of it ("I'll just leave this here <wink>" seems like missing
> text.))
>
+1, it should be deleted. I can't think of any use case where it would make
sense to use NPT66 for router addresses.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 17 Nov 2016 08:51:32 +1300

> something like that) is the real solution to the problem.

Agreed (not to mention RFC 7157 and the RFC of draft-ietf-6man-multi-homed-host
that will be published this week). We're close to making multi-PA viable.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 17 Nov 2016 08:45:44 +1300

Regards
   Brian Carpenter

> sense to use NPT66 for router addresses.

Yes. The fact that people are using it is *not* a reason for publicising
a bad practice.

   Brian

---

From: Victor Kuarsingh <[email-masked]>
Date: Thu, 17 Nov 2016 01:06:23 -0500

On 2016-11-16 1:58 AM, Mark Smith wrote:
>
> >
>
> Thinking about the new version, and the above, I think there may still 
> be some scope issues.
>
Not sure I agree with this statement.  Given that there is a difference 
in expected behavior in various use cases, discussing it is relevant. In 
designing multiple networks in the past, we considered the differences 
of these address types each time.  Such considerations occurred applying 
IPv6 to Cable Access, Core networks, Mobile Core networks, Mobile RANs 
networks, Video networks, Business Networks, Enterprise networks and 
data centers. So that to me signifies relevance.

GUA vs. ULA - it's relevant if you expect to reach (or be reached) by 
hosts outside your network
PI vs PA - it's relevant as the work needed during address block 
acquisition and potentially if renumbering is needed.

> ULA vs PI vs PA only matters if the network is connected to the 
> Internet, which is more of an external routing issue and more of one 
> that is significant to hosts, although there is the issue of allowing 
> external traceroutes inwards, and some ICMPv6 outbound with source 
> addresses that don't get dropped by martian filters.
>
Operationally speaking, it's not just the technical characteristics of 
the address that are relevant when choosing addresses.  The life cycle 
of the address is also a part of the consideration.

> Internet, but it is not a requirement. If that is currently an 
> unstated assumption and context for the whole document, then I think 
> it should be stated.)
>

> Also, if it is a snapshot if what is happening now, then it could 
> discuss pros and cons of what people are doing, however if it provides 
> advice, then it is crossing over into BCP sort of territory, and what 
> people are currently doing might not be good examples of what to do. 
> (I too agree that mentioning NPTv6 like it has been comes across as 
> tacit approval of it ("I'll just leave this here <wink>" seems like 
> missing text.))
>

I would think the designer would be able to take the information 
supplied in the draft and connect it to their needs.  Some networks are 
connected to the Internet, some are not, the designer would know that.  
I am not sure speculating as to how many or why networks may or may not 
be connected to the Internet is something we can correctly document.

> Mark.

regards,

Victor K

> https://www.ripe.net/publications/docs/ripe-655#IPv6_PI_Assignments 
> for RIPE region.
> >>>>
> > We will look at the new policies and see if some tweaks to the 
> wording is appropriate. However, I agree with Brian that millions of 
> small businesses are unlikely to get PI space. It may be easier, but 
> you still must apply, and convince the RIR that you qualify, and then 
> pay the annual fee.  The only way I could see this happening for 
> mom-and-pop florist is if someone does all the work on their behalf.  
> And ... do we really want millions of small businesses to get PI 
> space??? "News at 11 -- Global routing tables hit the 10 million 
> routes mark".
> >
> >>> Host addressing is out of scope for this draft, so it doesn't 
> matter so much, but if we're talking about multihoming we should note 
> that the best approach for smaller networks is multihoming using PA 
> addresses via source+destination based routing. That is is being 
> pursued in the homenet and routing working groups.
> >>
> >>
> >> [email-masked] <mailto:[email-masked]>
> > [email-masked] <mailto:[email-masked]>

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 17 Nov 2016 16:18:12 +0900

On Thu, Nov 17, 2016 at 3:06 PM, Victor Kuarsingh <[email-masked]> wrote:

> Not sure I agree with this statement.  Given that there is a difference in
> expected behavior in various use cases, discussing it is relevant. In
> designing multiple networks in the past, we considered the differences of
> these address types each time.  Such considerations occurred applying IPv6
> to Cable Access, Core networks, Mobile Core networks, Mobile RANs networks,
> Video networks, Business Networks, Enterprise networks and data centers.
> So that to me signifies relevance.
>
I still don't see how any of that applies to IP addresses assigned to
routers, which is explicitly the only class of IP address discussed in this
draft.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 18 Nov 2016 08:30:13 +1300

> routers, which is explicitly the only class of IP address discussed in this

ULA vs GUA for routers does impact what people outside your network can learn
from traceroute results, I guess. But in general, the connection is that an
operator is likely to choose a router addressing policy that is a subset of
the overall addressing policy. (I can't think of any reason that would be
a requirement, however. On the other, address *stability* for routers might
be a requirement, which would suggest ULA or PI, even if you use PA for hosts.)

   Brian

---

From: Victor Kuarsingh <[email-masked]>
Date: Tue, 22 Nov 2016 10:29:50 -0500

On 2016-11-17 2:18 AM, Lorenzo Colitti wrote:
> On Thu, Nov 17, 2016 at 3:06 PM, Victor Kuarsingh <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Not sure I agree with this statement.  Given that there is a
>     difference in expected behavior in various use cases, discussing
>     it is relevant. In designing multiple networks in the past, we
>     considered the differences of these address types each time.  Such
>     considerations occurred applying IPv6 to Cable Access, Core
>     networks, Mobile Core networks, Mobile RANs networks, Video
>     networks, Business Networks, Enterprise networks and data
>     centers.  So that to me signifies relevance.
>
> routers, which is explicitly the only class of IP address discussed in 
> this draft.

All of these networks have routers, which need IP addresses.  I don't 
think there is a clear default answer, so the designer needs to choose 
addresses from the types available.  Given there is more then one 
option, I don't see how it's not relevant.

Is there harm in providing a clear set of options to the designers? To 
me, providing information to a designer is helpful.  They can chose what 
they need/want.

regards,

Victor K