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

Bob Hinden <bob.hinden@gmail.com> Tue, 07 March 2017 01:38 UTC

Return-Path: <bob.hinden@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25AB6129A80; Mon, 6 Mar 2017 17:38:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7A8wqTqxGT6I; Mon, 6 Mar 2017 17:38:43 -0800 (PST)
Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DACD5129860; Mon, 6 Mar 2017 17:38:42 -0800 (PST)
Received: by mail-wm0-x229.google.com with SMTP id n11so78064479wma.1; Mon, 06 Mar 2017 17:38:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=oB/79nhduDwV115IhdiiKWmzAQ9yKp4XgoyRrPkHMKc=; b=iBW6rik3k6kEnWd5lzYvPZ2MkAR/SFKAdB1TVask6nMLGofCdtsZ97iRz3i8LV4r2y 3MN5+fes4M142dtg4EvVBTsionqXRaAQOou1ZfbxmZQRBMVNRRkZeoWQVcFwjA0oRK0D RQDumnAW4QbsjOwxyLz3+zTThzxjMUhPwSrEiepJq0djcxkbP7zqoq2Rlg6JdOuZNrOr NAufZ8c0Scc+6Vyc1d+GNSf3BdaXXSnCJ1x4gIGGhGHeeylsxYtt+EBleHNjHA4RdUma 6AX0CkKKbRld+miXw4tUyvj2eNNhh+77XQnMCZPnVkuENSpGYfWrbckpfeQWNG2Owh7W Clsw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=oB/79nhduDwV115IhdiiKWmzAQ9yKp4XgoyRrPkHMKc=; b=cK8WAylRgvjwFrZ8XUlCODTPQ7y89KK+hzFzioW/goRe/uuCEWgPgqLIdpjUu4kmmT dPqi1NugQMvo+0k8t2QgQtJmZ0Yc7QP4RffTG6C8T87K1MTlPh1A3Uf01ge4B/de412D 5dJvpWS1twHNnaz+ozUWAk/Fw5jjyxVmbE7A7mlTdWEdJyDKtGgwN3/4kTleQZfBILHQ og/Z8jrmMdhlTdrF1hyBC0gL8DjV7MaoIPltxZhPb1XCHVE46f9mfxAYHIpjkqjbhypf ohcF+RZ2Pc0e6XulmhCshdtd8e1dBvmJqmctN9C1ntmHFJbFfu6f+FQd2jGRHhCuMwMm Y54Q==
X-Gm-Message-State: AMke39mTCktvfhYYBQ+hCRPpl33m7m+zG9chng6vaFkmIJ07RbQl/bFNxY+0Kud5oXqUUg==
X-Received: by 10.28.129.212 with SMTP id c203mr15194567wmd.19.1488850721378; Mon, 06 Mar 2017 17:38:41 -0800 (PST)
Received: from ?IPv6:2601:647:4d01:db10:f96e:fb7:ae30:96cb? ([2601:647:4d01:db10:f96e:fb7:ae30:96cb]) by smtp.gmail.com with ESMTPSA id 40sm29025664wry.22.2017.03.06.17.38.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Mar 2017 17:38:40 -0800 (PST)
From: Bob Hinden <bob.hinden@gmail.com>
Message-Id: <FD5C174D-080B-4D59-88EB-ADE08AAA2D73@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_6B728FC0-4A7A-4D8D-BCC1-5F5BCA1AE842"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: Review of draft-ietf-6man-rfc1981bis-04
Date: Mon, 6 Mar 2017 17:38:33 -0800
In-Reply-To: <148864769030.23464.9110014115039938058.idtracker@ietfa.amsl.com>
To: Susan Hares <shares@ndzh.com>
References: <148864769030.23464.9110014115039938058.idtracker@ietfa.amsl.com>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/sgfmm2p3-YnHahDnn54c1jrZErU>
Cc: IPv6 List <ipv6@ietf.org>, ops-dir@ietf.org, Bob Hinden <bob.hinden@gmail.com>, IETF <ietf@ietf.org>, draft-ietf-6man-rfc1981bis.all@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Mar 2017 01:38:46 -0000

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.