Re: [v6ops] New version of Design Guidelines draft

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: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of
> Philip Matthews
> Sent: Monday, October 22, 2012 8:29 PM
> To: v6ops@ietf.org list
> Subject: [v6ops] New version of Design Guidelines draft
> 
> 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
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops