Re: Draft IPv6 in an IXP

[bill fumerola <billf@mu.org>]

[ N.B. i wrote this last wednesday and haven't had time to update it to
incorporate or remove suggestions made by other WG members. nor have
i completed it, but since this document is being discussed i thought i
would just send out what i had. ]

On Wed, Dec 10, 2008 at 02:35:21PM -0600, Roque Gagliano wrote:
> working in another project I wrote a document about options for  
> implementing IPv6 in an IXP. I submit this information as an Internet  
> Draft and I wanted to get feedback from this working group.
> 
> Draft:
> http://www.ietf.org/internet-drafts/draft-rgaglian-v6ops-v6inixp-00.txt
> 

this review is not a complete review, nor do i agree w/ everything that
i have not disagreed with below. i'm including both grammatical and
technical nits. if this document is going to go further (either as a WG
item or individual publication), i'll commit to reviewing it further.

all sections:
- half the sections end with a trailing period, half do not. they
  shouldn't as they are not sentences.
- there is no table of contents.

section 2:
"The Switch Fabric is a Layer 2 device"
not really. the switch fabric may be more than one switch. there may
be repeaters, multiple sites connected over a metro LAN, and much more
complex configurations. use words that refer to Ethernet and LANs more
generically, etc. avoid wording that implies there is One Switch. the
important point here is that IPv6 IXPs run on IPv6 over Ethernet [RFC2464]
and not (say) IPv6 over ATM [RFC2492].

"classic configurations":
section 2 may/may not be implemented as a VLAN, it could be a physically
 separate LAN
could include a third section: .1q trunks (which avoids the need for
 twice as many physical ports)

VLANs provide a _logical_, not physical separation

s/On the other side// ("On the other hand" is the English idiom)

"In the dual-stack model, statistical analysis on traffic can easily
separate traffic by EtherType."

"access mode ports into tagged" = "untagged ports into tagged ports"
   access mode is a cisco-ism


from section 3, IID selection:

       *  IPv6 Address: 2001:DB8::6449:6000:0000:0001/64 or its
              equivalent representation 2001:DB8::6:4496:1/64

those are not equivalent:
2001:DB8::6449:6000:0000:0001 = 2001:DB8::6449:6000:0:1
2001:DB8::6:4496:1/64 = 2001:0db8:0000:0000:0000:0006:4496:0001


   4.  A forth approach might be based on IXP the membership ID for that
          provider.

"fourth"

   The current practice that applies to IPv4 about publishing IXP
   allocations to the DFZ (Default Free Zone) should also applies to the
   IPv6 allocation

"should also apply" or "also applies"

   A good practice is to have IPv6 reachability information carried over
   sessions established also on top of the IPv6 IP/TCP stack and
   independently of the IPv4 sessions.

clumsy wording, i had to read it twice to realize you meant "peer IPv4
SAFI information over IPv4 peers and IPv6 SAFI information over IPv6
peers", which is not the wording i'd suggest either..

   The Router-Server or Looking Glass external service should be
   available for external IPv6 access, either by an IPv6 enabled web
   page or an IPv6 enabled console server.

"route server"
s/external// as "external" and "internal" don't mean much here
".. an IPv6-enabled HTTP server and/or terminal reachable via TELNET or
SSH" with appropriate references to what those are

i don't know what section 6 is trying to accomplish. either make a full
blown list of what statistical and monitoring services IXPs should make
available or ignore the topic altogether. if there were serious
differences in those services between IPv4 and IPv6, it'd be worth
mentioning - but there really aren't. any protocol that has had a
refresh to support IPv6 would be appropriate, i suppose.


section 7: 
repeat: "it's important to market the fact [...]. Marketing is also important."
"and if possible via" ==> "and, if possible, via"
"If the website [...]" ==> "Along with ASN and IPv4 address(es), list
  participants' IPv6 address(es) in the membership roster."
"ASN's" => "ASNs"

section 8:
s/as was already mentioned// -- it's either worth mentioning again, or
it's not. no need to dwell on that.
s/reduced to/limited to/
"ICMPv6 neighbor discovery" => "ICMPv6 Neighbor Discovery"
"could be monitored" => "should be monitored"
"bad behaviors or configured problems" like what? enumerate these.
"This traffic" => "The link-local multicast traffic on this link"
"RFC 4861 [RFC4861]" => "[RFC4861]"


section 11, The author should refer to himself as "The author"


-- bill