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

From: [email-masked]
Date: Thu, 04 Sep 2014 18:50:58 -0700

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

        Title           : Design Choices for IPv6 Networks
        Authors         : Philip Matthews
                          Victor Kuarsingh
	Filename        : draft-ietf-v6ops-design-choices-02.txt
	Pages           : 16
	Date            : 2014-09-04

Abstract:
   This document presents advice on the 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:
http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-02

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

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: Thu, 4 Sep 2014 22:07:55 -0400

Folks:

As you can see, Victor and I have just submitted an update to the Design Choices draft.

This is a significant update, with completely re-written text around IGP choice and BGP. The IGP choice section looks more completely at the various options, while the BGP section now considers iBGP as well as eBGP. This update also addresses comments sent to us by Owen DeLong  (thanks, Owen, and sorry that we took so long to address them!).

In terms of draft status, we are thinking that we are getting close to a final version. There are surely problems with the draft that need correcting, but we don't have any plans to add significant new content. So please read this version with that in mind.

Thanks in advance for any comments, and sorry that we have been a bit slow in updating the draft.

Philip

On 2014-09-04, at 21:50 , [email-masked] wrote:

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

---

From: "Heatley, Nick" <[email-masked]>
Date: Fri, 5 Sep 2014 14:34:07 +0000

Hi,
I am assuming these functional elements often found in various broadband networks are out of scope: NAT, DNS, AAA, Address Assignment, Load balancer, Multi-homing? What of Security enforcement such as (but not limited) to IP firewall? 
So if the intention is to leave contents as shown (ok with me) perhaps the title and abstract could be clearer?
Is "IP Transport Design" a common term for the subject matter, or perhaps "IP Router Design"?
Regards,
Nick

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Philip Matthews
Sent: 05 September 2014 03:08
To: v6ops list; Owen DeLong
Cc: Victor Kuarsingh
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-02.txt

Folks:

Philip

On 2014-09-04, at 21:50 , [email-masked] wrote:

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

_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops
NOTICE AND DISCLAIMER
This e-mail (including any attachments) is intended for the above-named person(s).  If you are not the intended recipient, notify the sender immediately, delete this email from your system and do not disclose or use for any purpose.  
 
We may monitor all incoming and outgoing emails in line with current legislation. We have taken steps to ensure that this email and attachments are free from any virus, but it remains your responsibility to ensure that viruses do not adversely affect you. 

EE Limited
Registered in England and Wales
Company Registered Number: 02382161
Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9BW

---

From: "Chettle, Nick" <[email-masked]>
Date: Fri, 5 Sep 2014 15:38:22 +0000

Hi Phillip,

I think this is document pulls a lot of useful best practices together. A
couple of minor points.

   o  It is not often not possible to identify the interface or link (in
      a database, email, etc) by giving just its address without also
      specifying the link in some manner.

I think this should read "often not possible² ?

Additionally, in section 2.1.2 you talk about link-local vs. GUA/ULA for
point-to-point links, it might be useful to reference something on address
assignment here (/64, /126, /127, etc.). I see you¹ve already referenced
RFC5375 in the introduction however it may be worth a second mention here?

Cheers, Nick

On 05/09/2014 03:07, "Philip Matthews" <[email-masked]> wrote:

>This is a significant update, with completely re-written text around IGP
>choice and BGP. The IGP choice section looks more completely at the
>various options, while the BGP section now considers iBGP as well as
>eBGP. This update also addresses comments sent to us by Owen DeLong
>(thanks, Owen, and sorry that we took so long to address them!).
>
>In terms of draft status, we are thinking that we are getting close to a
>final version. There are surely problems with the draft that need
>correcting, but we don't have any plans to add significant new content.
>So please read this version with that in mind.
>
>>submission

Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of British Sky Broadcasting Group plc and Sky International AG and are used under licence. British Sky Broadcasting Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of British Sky Broadcasting Group plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD.

---

From: Philip Matthews <[email-masked]>
Date: Fri, 5 Sep 2014 20:56:43 -0400

Hi Nick:

There are lots of additional topics that could go into this document, but the authors feel that it would be best to leave these to follow-on documents because (a) otherwise the document would get very large, and (b) both authors have had difficulty finding the time to work on this more-limited scope document. 

So the authors feel it would be best to polish up this document and publish it as an RFC. After that, if the WG is interested, other documents could address other areas.

- Philip

---

From: Philip Matthews <[email-masked]>
Date: Fri, 5 Sep 2014 21:07:37 -0400

Nick:

Thanks for the comments.
In my working copy, I have corrected the grammatical error and added the sentence "See also [RFC5375] for IPv6 unicast address assignment considerations." to the end of the section.

Philip

---

From: Philip Matthews <[email-masked]>
Date: Fri, 5 Sep 2014 21:15:27 -0400

Hi Nick:

Just re-read your email and realized that I missed your comments on title and abstract.  But yes, my personal feeling is that the title and abstract describe reasonably well the contents of the document.

Philip

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 9 Sep 2014 09:36:01 +0200 (CEST)

Hi,

In 2.1.1, I'd like to see some text talking about methods where IPv4 and 
IPv6 can be separated by means of protocol based vlans, so end system 
complexity isn't increased, it's only a network change. This way IPv4 and 
IPv6 can have different topology, so that IPv4 choices don't have to 
affect IPv6 choices. In light of recent talk about IPv6 multicast and 
privacy addressing causing problems in networks, we should give guidance 
pointing to the problems of having very large L2 domains.

One article:

http://blog.bimajority.org/2014/09/05/the-network-nightmare-that-ate-my-week/

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Victor Kuarsingh <[email-masked]>
Date: Tue, 09 Sep 2014 08:54:28 -0400

Mikael,

The top portion of the text (in section 2.1.1) describes the concept of 
using two links or two Vlans to separate traffic.

The option of separating IPv4 and IPv6 on links (logical or physical) is 
set as option (b).  We have a brief discussion on the last paragraph on 
some reasons to choose this.  Now before we action any changes, there is 
discussion in the last paragraph which talks about limitations on 
network equipment and device-specific limitations.

If you don't feel that this text is sufficient, then which of the 
following approaches do you think would best get the point across.

(1).  Have a new paragraph(s) which highlight option (b) more and then 
provide a listing of pros/cons (where the pros can then point to items 
you wanted addressed)

(2). Extend the last paragraph to list the issues you highlighted

On that point, these issues will be arguably temporary and resolve over 
time, so if we did highlight issues as noted in the article you listed, 
we should also note that these problems are part of the maturing process 
(no?).

regards,

Victor K

On 2014-09-09, 3:36 AM, Mikael Abrahamsson wrote:
> In 2.1.1, I'd like to see some text talking about methods where IPv4 
> and IPv6 can be separated by means of protocol based vlans, so end 
> system complexity isn't increased, it's only a network change. This 
> way IPv4 and IPv6 can have different topology, so that IPv4 choices 
> don't have to affect IPv6 choices. In light of recent talk about IPv6 
> multicast and privacy addressing causing problems in networks, we 
> should give guidance pointing to the problems of having very large L2 
> domains.
>
> One article:
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 9 Sep 2014 15:12:20 +0200 (CEST)

On Tue, 9 Sep 2014, Victor Kuarsingh wrote:

> Mikael,
>
> The top portion of the text (in section 2.1.1) describes the concept of using 
> two links or two Vlans to separate traffic.

Well, from end system point of view, it's a single vlan, it doesn't need 
to understand the two vlans. So this is somewhat of in-between.

> The option of separating IPv4 and IPv6 on links (logical or physical) is set 
> as option (b).  We have a brief discussion on the last paragraph on some 
> reasons to choose this.  Now before we action any changes, there is 
> discussion in the last paragraph which talks about limitations on network 
> equipment and device-specific limitations.
>
> If you don't feel that this text is sufficient, then which of the following 
> approaches do you think would best get the point across.
>
> provide a listing of pros/cons (where the pros can then point to items you 
> wanted addressed)

I think this is the approach I would prefer. Try to give examples how it 
can be done and pros and cons so the implementor can make an informed 
choice.

---

From: Philip Matthews <[email-masked]>
Date: Tue, 9 Sep 2014 09:41:52 -0400

Mikael:

I agree that the discussion of option (b) in section 2.1.1 could be improved.

It would be helpful if you could send some points that you would like included.  We can then draft something and sent it out.

Philip

On 2014-09-09, at 9:12 , Mikael Abrahamsson wrote:

>> The top portion of the text (in section 2.1.1) describes the concept of using two links or two Vlans to separate traffic.
> 
> Well, from end system point of view, it's a single vlan, it doesn't need to understand the two vlans. So this is somewhat of in-between.
> 
>> The option of separating IPv4 and IPv6 on links (logical or physical) is set as option (b).  We have a brief discussion on the last paragraph on some reasons to choose this.  Now before we action any changes, there is discussion in the last paragraph which talks about limitations on network equipment and device-specific limitations.
>> 
>> If you don't feel that this text is sufficient, then which of the following approaches do you think would best get the point across.
>> 
>> (1).  Have a new paragraph(s) which highlight option (b) more and then provide a listing of pros/cons (where the pros can then point to items you wanted addressed)
> 
> I think this is the approach I would prefer. Try to give examples how it can be done and pros and cons so the implementor can make an informed choice.
> 
> --

---

From: Philip Matthews <[email-masked]>
Date: Thu, 18 Sep 2014 19:11:56 -0400

Mikael:

Victor and I re-reviewed section 2.1.1 in light of your comments. 
Your basic point, that at some times it is necessary to have IPv4 and IPv6 on different VLANs, is the whole point of this section, and neither of us could think of anything useful to add to this section to expand on it more without making the section extremely long.

However, if you have some suggested text, or additional points to add, then please send them to us.

Philip

On 2014-09-09, at 3:36 , Mikael Abrahamsson wrote:

> In 2.1.1, I'd like to see some text talking about methods where IPv4 and IPv6 can be separated by means of protocol based vlans, so end system complexity isn't increased, it's only a network change. This way IPv4 and IPv6 can have different topology, so that IPv4 choices don't have to affect IPv6 choices. In light of recent talk about IPv6 multicast and privacy addressing causing problems in networks, we should give guidance pointing to the problems of having very large L2 domains.
> 
> One article:
>