Subject: [v6ops] New version of Design Guidelines draft

From: Philip Matthews <[email-masked]>
Date: Mon, 22 Oct 2012 14:28:49 -0400

Folks:

I have just posted a new version (-01) of the Design Guidelines draft:
     https://datatracker.ietf.org/doc/draft-matthews-v6ops-design-guidelines/  OR
     http://tools.ietf.org/html/draft-matthews-v6ops-design-guidelines-01

This version is pretty much a complete rewrite of the document. It incorporates all the tremendous feedback that I received by email and during the lengthy discussion at IETF-84 in Vancouver. Many thanks to the many, many people who gave me feedback. I spent quite a few hours going through my emails and listening to the audio recording in an effort to capture everyone's feedback. If you feel I somehow forgot or mis-interpreted your comment, please let me know.

This version of the document is somewhat more definite in some of its recommendations than the previous version. For design choices where I felt that the comments received overwhelming favored one option, the new version reflects this sentiment. For example, I felt there was a strong consensus at the last WG meeting that operators should mix IPv4 and IPv6 traffic on a single logical link wherever possible, though I noted that device limitations may require separating them in some cases (e.g. to get good traffic statistics).

Comments on this new version are most welcome.

- Philip

---

From: "Ivan Pepelnjak" <[email-masked]>
Date: Wed, 24 Oct 2012 19:44:53 +0200

Philip,

Two more gotchas to add to your list:

Section 2.4
===========
Combined eBGP sessions have inherent next-hop problems. 

With next-hop-self (which is usually what eBGP sessions have to use), the next hop advertised in a BGP update gets derived from the address family of the endpoints of the BGP session, which means that if you use IPv4-only eBGP session, the routers advertise IPv6 prefixes with IPv4-mapped IPv6 next hops. Junos gracefully recovers by allowing you to configure ::FFFF:x.y.z.w addresses on interfaces, Cisco IOS doesn't allow that and thus requires usage of route maps to set IPv6 next hops.

The reverse situation (IPv4 over IPv6 session - RFC 5549) is even worse, see https://ripe65.ripe.net/archives/video/49/ for details, don't think anyone has implemented it yet.

Section 2.5
===========
When using BGP-over-LLA, Cisco IOS makes the interface name part of BGP neighbor name. If you have to move the cable to another interface (example: interface failure), you have to reconfigure all the BGP neighbors (there's no "rename" functionality in Cisco IOS).

Kind regards,
Ivan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Philip Matthews
> Sent: Monday, October 22, 2012 8:29 PM
> To: [email-masked] list
> Subject: [v6ops] New version of Design Guidelines draft
> 
> Folks:
> 
> This version is pretty much a complete rewrite of the document. It
> incorporates all the tremendous feedback that I received by email and
> during the lengthy discussion at IETF-84 in Vancouver. Many thanks to the
> many, many people who gave me feedback. I spent quite a few hours going
> through my emails and listening to the audio recording in an effort to
> capture everyone's feedback. If you feel I somehow forgot or mis-
> interpreted your comment, please let me know.
> 
> This version of the document is somewhat more definite in some of its
> recommendations than the previous version. For design choices where I felt
> that the comments received overwhelming favored one option, the new
> version reflects this sentiment. For example, I felt there was a strong
> consensus at the last WG meeting that operators should mix IPv4 and IPv6
> traffic on a single logical link wherever possible, though I noted that
> device limitations may require separating them in some cases (e.g. to get
> good traffic statistics).
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Philip Matthews <[email-masked]>
Date: Thu, 25 Oct 2012 13:30:53 -0400

Hi Ivan:

Thanks very much for your comments.
Both comments are very good  -- I will add them to the next revision of the document.

- Philip

---

From: KK Chittimaneni <[email-masked]>
Date: Sat, 27 Oct 2012 13:48:00 -0700

Hey Philip,

A very nice read, this revision is looking pretty good.

Cheers,
KK

On Mon, Oct 22, 2012 at 11:28 AM, Philip Matthews
<[email-masked]>wrote:

> capture everyone's feedback. If you feel I somehow forgot or
> mis-interpreted your comment, please let me know.
>
> that the comments received overwhelming favored one option, the new version
> reflects this sentiment. For example, I felt there was a strong consensus
> at the last WG meeting that operators should mix IPv4 and IPv6 traffic on a
> single logical link wherever possible, though I noted that device
> limitations may require separating them in some cases (e.g. to get good
> traffic statistics).
>