Re: Draft IPv6 in an IXP

[Joe Abley <jabley@hopcount.ca>]

On 2008-12-10, at 15:35, Roque Gagliano wrote:

> Draft:
> http://www.ietf.org/internet-drafts/draft-rgaglian-v6ops- 
> v6inixp-00.txt

Thanks for writing this up. Some minor comments follow.

You make the assumption in the document that the exchange is a layer-2  
facility. While this is religion for some, and (I think it would be  
fair to say) the most common infrastructure deployed with the label  
"exchange point" today, there are certainly examples of infrastructure  
that exist to exchange Internet traffic that do not look like this.

Similarly, there are exchange points (a dwindling number, no doubt)  
which do not necessarily function by the connection of peers to a  
single subnet (e.g. ATM fabrics which map individual PVCs directly  
between members, who are free to number the endpoints of the virtual  
circuits in any fashion they see fit).

You might observe near the top of the document that your treatment  
concerns layer-2 exchange points with a common subnet connecting  
participants, rather than proceeding as if no other implementation of  
"exchange point" exists. This would make the context more clear, I  
think, for those who happen to be involved in an exchange point that  
looks different. Observing that this is the most usual meaning of  
"exchange point" at the time of writing would not be unreasonable.

>    When selecting the use of static IIDs, there are different  
> options on
>    how to "intelligently" fill its 64 bits (or 16 hexadecimal
>    characters).  A list of IID selection mechanisms follows:


There is a possible inference there that the four options that follow  
are the only possible ways that an exchange point operator could  
choose a numbering scheme.

It would be better to make it clearer that what you are doing is  
listing four possibilities, and in practice exchange point operators  
are free to choose whatever scheme they like, regardless of whether it  
is listed in this document or not.

In section 4, you say:

>    PTR records for all addresses assigned to members should be  
> included
>    in the IXP reverse zone under "ip6.arpa".

The manner in which reverse DNS in IPv6 is handled has changed once in  
the past. It's slightly difficult to imagine it changing again, but I  
guess you never know. You'd avoid the possibility of this document  
giving out-of-date advice in the future altogether by simply avoiding  
the mention of "ip6.arpa". There is a draft that surely one day will  
be published that you could reference in order to support your  
assertion that reverse DNS is worth doing -- see draft-ietf-dnsop- 
reverse-mapping-considerations-06.txt.

As you describe dual-stack support for various ancillary services an  
exchange point operator might make available to connected  
organisations, you might mention that it's not necessary for any of  
that work to be done as a prerequisite for bilateral IPv6 peering  
across the fabric.

You make mention in a couple of places to extra precautions that  
participants might take when setting up their routers to do v6 peering  
(e.g. disabling router advertisements, setting a common MTU, avoiding  
protocols which generate link-local multicast traffic). It would be  
useful for that advice to be grouped together into a single section, I  
think, so that it is easy to find when someone makes reference to your  
document in the future by way of helping people configure their routers.

Editorially, I find your language in the draft very clear, and easy to  
follow.


Joe