Re: [v6ops] New version of Design Guidelines draft

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

On 2012-10-24, at 13:44 , Ivan Pepelnjak wrote:

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