| Thanks Andy for your comment, sorry for the delay.
Please see answers inline. On Jan 18, 2010, at 11:08 PM, Andy Davidson wrote: On 18 Jan 2010, at 16:00, Fred Baker wrote: This is to initiate a two week working group last call of draft-ietf-v6ops-v6inixp-04.txt. Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list.
We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make.
I think it will be interesting to folk building IXPs, sure let's do work on this document.
3 - Addressing Plans - part 2 - the author may like to describe that 32-bit ASN will require spanning across multiple biglets in the ipv6 address - the example possibly suggests that the ASN encoding will neatly fit into one portion of the address, and this is not true.
I had that comment for the previous example using the decimal representation. What about adding: "In this case a maximum of 8 characters will be needed to represent 32 bits ASNs."
6 - Route servers - md5 should be considered - I think this advice should be taken out, as this recommendation is not generally accepted, and the functioning/configuration of a route-server is well outside the scope of this document.
the idea was to name the variants of security configurations that are normally configured. However, if there is consensus on removing this text, I see no problem.
6 - Route servers - we may like to publish some information on v6 filtering to promote good hygiene between route-server peers.
Missing - link local address recommendations - Right now on an IXP operational mailing list, some folk are making observations about link local addressing used by IXP participants, and a recommendation may follow. It may be sensible to explicitly forbid traffic for link local protocols other than ND.
I believe that is the information included in section 4.1 (4.1. Multicast Support and Monitoring for ND at an IXP).
Do you have particular comments on this section?
I am pleased to see the reference to ra-guard, as an operator of l2 services I am looking forward to being able to roll this out to all of my ports facing ixp participants and LAN access users !
Good!.
Thanks again, Roque. |