Hi Sue, Thanks for the review, comments below. Bob > Reviewer: Susan Hares > Review result: Has Issues > > ack, Steve,Jeffrey, and Bob: > > Thank you for taking on this important revision to the document. I > hope my comments help to improve the document so this important change > can ge deployed. Thanks > > I have reviewed this as part of the routing directorate review. This > review should be treated as any IETF LC comments. > > Sue Hares > > RTG-DIR Review > > Status: I have three concern plus editorial nits. > > #1 - Concern 1 is technical regarding the interaction with the MTU > option in ND/SEND plus > ditorial nits. See the comments below. I am not an ND/SEND Expert, > please have an imoplementer look at the requirements. > > Concern: I cannot tell how this interacts with the ND/SEND protocol in > the following areas below. > 1) Neighbor Unreachability Detection is used for all paths between > hosts > and neighboring nodes, including host-to-host, host-to-router, and > router-to-host communication. > > If the source node is on the link and the destination node > available > through the router, and the router is in the process of sending a > MTU option to increase the size? How does your algorithm work? I believe what will happen is that the host will use the new MTU in any new connections it establishes. Existing connections will continue with preview MTU. I also note, that this would be a very rare event as most LANs do not dynamically change their MTU. > > Are the packetization layer notified? > Is the original value a stale notification over time? > You indicate it MUST NOT be done in less than 5 minutes, and that > 10 minutes is the norm. > > Is 10 minutes really the best response time for this particular > case? > Or did I miss something in your draft? See above. > > > 2) Assume the same situation as #1, but the > router sends an MTU option to decrease the size. > > In this case, the router is sending information that > the MTU has changed, but the first indication for the > end system is based on a Packet-too-Big Message after sending. I think receiving PTB messages would be the likely result for existing connections. The host would respond by reducing it’s packet size. New connections would use the new MTU. As above, this should be a very rare occurrence. > > > 3) For a multicast packet (3000 bytes), assume that > the multicast path reaches two different routers (router-a > and router-b). Assume the on-link MTU is 3500 bytes, but the > previous router-A and router-B MTU is 2500 bytes. > > Router-a responds to the packet with 10ms sending a > MTU option that changes the MTU to support this packet. Router-B sends > a redirect > for multicast address to Router-A after 30 ms. > > What happens to your path calculation? > Is this again, the 5 minutes (minimum) and 10 minute normal to > reset this value. The host would use the lowest MTU it received and act accordingly. This is described in the fifth paragraph of Section 3. > > 4) What happens if the ND process is instantiated by > SEND protocol, and the host does not contain the appropriate > certification information to timely updates? > > Again, the host guessing at the appropriate value? I don’t follow this? Please explain. This seems more about a question about SEND, and not rfc1981bis. > > > #2 - Concern 2 - How does SEND's implementation of MTU option. > mitigate or have no effect on this MTU. Is there a recommendation > that should be made in section 6. Again, please ask a SEND expert > for review. It works the same. SEND secures ND, it still uses ND. The SEND RFC doesn’t even reference RFC1981. > > #3 - Concern 3 - content of document > > This document has two parts: protocol requirements and implementation > requirements. > 8 paragraphs (1 page) indicates the IPv6 specification and 6 pages > gives the implementation? > > Why did this get split in to 2 documents? Even if this was a bis, > document would it not > be better to provide minimal specification for the protocol change and > a larger document > with implementation information. > > I'm fine with the WG/ADs deciding, this is the way the document has to > go forward -- but the question should be asked. The working groups intent in doing this bis document was to make a few changes to fix a problem related to a change in RFC2460bis, remove mention of RH0 because it was deprecated earlier, and a few other small changes. It was not to do a major rewrite of the document (or as you suggest, split it into two documents). The alternative was just to file an errata on RFC1981. This document is very widely implemented. I don’t think splitting the document into two would improve anything, and very likely create confusion for the current implementations. > > Editorial nits: > #1 nit - section 5.2 page 8, paragraph beginning > > Old /Note: if the / > New/Note: If the/ > > #2 nit - section 5.2 page 9 paragraph begin > > Old /Note: even if/ > New /Note: Even if/ > > #3 nit - section 5.3 page 10 paragraph beginning > > Old /Note: an implementation/ > New/Note: An implementation/ > > Noted. Thanks.
Attachment:
signature.asc
Description: Message signed with OpenPGP