| Joe,
Thanks for the comments. On Dec 16, 2008, at 12:26 PM, Joe Abley wrote: 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.
So, I would say that I am supposing an ethernet switch fabric, yes. I can refer to that in the introduction as: The document assumes an Ethernet switch fabric, algthouh other layer 2 devices can be deployed.
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.
good point. 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.
well the document is currently expired.
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 meant that the operator might be unaware that the participant are exchanging IPv6 sessions using link local. 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.
thanks. |