Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-01.txt

Section 2.1

It might also be worth addressing that the sometimes perceived disadvantage of combining IPv4/IPv6 on the same link of generating additional link utilization is not an issue in most case as the vast majority of cases where IPv6 bandwidth utilization increases show a corresponding decrease in IPv4 utilization by the same host. 

I don’t disagree with the conclusion drawn, but I spend quite a bit of time debunking this argument among people who are new to IPv6.

Section 2.2

The claim that "it is not possible to identify the interface or link (in a database, email, etc.) just by giving its address” seems specious to me. Unless you have a problem of duplicate MAC addresses or overlapping LL addresses within your network (generally you should not), the LL address is an adequate unique identifier.

Further, I am unconvinced that it is “difficult-to-impossible” to implement DNS names for LL addresses. While it is true that LL ip6.arpa zones are very localized in scope, an organization wishing to do so could maintain an organization-wide central registry of LL addresses and corresponding ip6.arpa entries without great difficulty if they chose to do so.

An additional disadvantage which is an implication of the second one mentioned, but is, IMHO, worthy of its own bullet point:

o	In cases of parallel point to point links, it is impossible to determine which of the parallel links was taken when attempting to
	troubleshoot unless one sends packets directly between the two attached link-locals on the specific interfaces. Since many
	network problems behave differently for traffic to/from a router than for traffic through the router(s) in question, this can pose
	a significant hurdle to some troubleshooting scenarios.

Section 2.4

I’m not sure why this is being discussed separately for eBGP vs. iBGP. The implications are identical IMHO.

Further, I note that iBGP is not discussed at all. Suggest rewriting the document to change all references to eBGP to be simply BGP and discuss differences between iBGP and eBGP in additional detail where applicable.

o	In some implementations, it is not possible to carry IPv4 routes over an IPv6 session.

o	Multi-vendor interoperability for multi-family BGP sessions is not especially well tested and interoperability problems have been
	encountered in some combinations.

Section 2.5

Routes learned via eBGP and being announced over iBGP are not a case of route redistribution, a term which is generally taken to mean the transferring of routes from one protocol to another. eBGP and iBGP are not different protocols and do not maintain separate RIBs. They are, slightly different behaviors of a single routing protocol depending on whether the peer-as number matches the local as-number (iBGP) or not (eBGP). In fact, multi-hop eBGP is nearly indistinguishable in its behavior from iBGP.

“If one is configuring parallel eBGP sessions for IPv4 and IPv6 routes, then using link-local addresses for the IPv6 session introduces an extra difference between the two sessions which could otherwise be avoided” — I’m unclear on what this difference that could be avoided is. The two sessions will, by virtue of the different address families have different addresses expressed in different address formats. Is there some additional difference implied by a LL address of which I am unaware?

Since section 2.5 is specified for eBGP only, I’m not sure where the most appropriate place to add this would be, but I believe it is worth noting:

o	iBGP using link local addresses is utterly impractical in most situations because most iBGP sessions are multi hop by virtue of termination on the loopback interface.

o	Using LL eBGP would, thus introduce an additional inconsistency in the management techniques for eBGP which is also a potential source of confusion and error.

Section 2.6

Last bullet… In addition: At the time of writing, these extensions are not widely supported by all vendors.

I hope these suggestions are useful in your development of this draft. Sorry for making my comments so late. This is the first time I have had time to review the proposal in detail.

Owen

On Mar 6, 2014, at 11:00 AM, Philip Matthews <philip_matthews@magma.ca> wrote:

> Folks:
> 
> It has been a while since an update to this document has been published, and I apologize for that.  However, thanks to much help from Victor (who is now a co-author) and some prodding today by John, a new revision is now ready. Both Victor and I were very busy in the last few months and were not able to get a revision out in time for this week's meeting.
> 
> Originally, the plan was to expand the document with a bunch of additional topics. Both Victor and I have ideas, but what we lack is time to work on them. So we are now thinking of keeping the list of topics covered to what is in this version, and covering new topics somewhere else. With this plan, the hope is that we can finish this WG document in a timely manner.
> 
> As always, comments are most welcome.
> 
> - Philip
> 
> 
> 
> On 2014-03-06, at 18:44 , internet-drafts@ietf.org wrote:
> 
>> 
>> 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-01.txt
>> 	Pages           : 13
>> 	Date            : 2014-03-06
>> 
>> 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-01
>> 
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-design-choices-01
>> 
>> 
>> 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/
>> 
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops