RE: Review of draft-ietf-6man-rfc1981bis-04

["Susan Hares" <[e-mail]>]

Bob: 

Thank you for your response.    I'm pulling up the remaining questions to the top here.  All my questions were about corner cases and "what ifs" - which is just the result of being a reviewer of a long-implemented specification. 

1) I thought the IPv6 LAN was targeted for new mobile networks or sensor networks.   If so, it may be in the future that the wireless connections would want to change the MTU on a network to increase the ability to change the MTU.   If you're answer is, we'll make the timer adjustment when these technology use it in this way, this is a fine answer. 

2) On, your comment: 
> 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. 
Did I miss this in the draft?   Just to sharpen my knowledge of this draft.  

3) The question #4 - I was trying to determine what the interaction between the SEND with an MTU size option, and this update to RFC1918.   It appears in the specification these two functions are interacting.   Is this my imagination?  If not, just for my own information - where do I find this in the specification.   

Thanks, 

Sue 


-----Original Message-----
From: Bob Hinden [mailto:[e-mail]] 
Sent: Monday, March 6, 2017 8:39 PM
To: Susan Hares
Cc: Bob Hinden; [e-mail]; IPv6 List; IETF; [e-mail]
Subject: Re: Review of draft-ietf-6man-rfc1981bis-04

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.