[dhcwg] Fwd: WGLC for draft-ietf-dhc-dhcpv6-pd-relay-requirements - respond by August 17th, 2020

ianfarrer@gmx.com Thu, 20 August 2020 14:06 UTC

Return-Path: <ianfarrer@gmx.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91D863A0658; Thu, 20 Aug 2020 07:06:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
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 siEs7ycWRDUc; Thu, 20 Aug 2020 07:05:56 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79ACB3A064A; Thu, 20 Aug 2020 07:05:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1597932320; bh=JTCg0ueA3R192pqPHGJfkFd3YCsHtJ++XM4vYZzFP6o=; h=X-UI-Sender-Class:From:Subject:Date:References:Cc:To; b=OuLLXuX7JH8UrSk2X00SzrMNzsvXpU59m6/ulTFJiiH7irDoylTw2HrarP4ASTpe6 CT6hZAXSIRZBQZCqDG9XHmkkmGi58gWczGVOUTpYrgbqodXpXr+STxZBX48GNvR/KV Ltbb1IU7XOyZoUBb/NjrN2326m++f6j3jCO0fWbc=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.128.43] ([87.78.166.87]) by mail.gmx.com (mrgmx004 [212.227.17.184]) with ESMTPSA (Nemesis) id 1MJVDW-1kOEkC1x5k-00JvkU; Thu, 20 Aug 2020 16:05:20 +0200
From: ianfarrer@gmx.com
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\))
Date: Thu, 20 Aug 2020 16:05:18 +0200
References: <14A3879A-EA9D-46F1-91AF-6F7185CC16DC@fugue.com>
Cc: dhcwg <dhcwg@ietf.org>, dhc-chairs@ietf.org, "Bernie Volz (volz)" <volz@cisco.com>
To: mellon@fugue.com
Message-Id: <E0102FDD-B842-4962-A1C5-A342CF5F0F78@gmx.com>
X-Mailer: Apple Mail (2.3445.104.15)
X-Provags-ID: V03:K1:7mO/jobMN19X+iMugVp3bq9D46HxxNP4CfFO3Y5NNfe3eKGuJ85 rmQFcRvu5eMpCO1FLZSKjQi+wE1wDxshIoTbApckPx2vJcHjNpUOM74TeFy3pUydW8nkBqt DpLZ2NBumZ6pIU4KYwYQNOa8FIRzeASCZwMhmTjtkImEpepB31hvdKDlm5vSkpgwEKVHu5Z KURPe23zJe1TXr3zeo9wA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:2qGazArIuHg=:pGnnaKBg4KI6cOsAf9kNk5 3wHvr1OaYj9lM2/0/8MCq6lH9I1OH1/cMpL3BL2ZBQiy3bb9dyTdRJCHKyMriIXVs22AoWEY3 4RRa6SwDXKZjHlOzv3pUOWF/SLVuuXtFslWe6/8514b/7x4WAroSQQgT1KHApLZujszkiAOYU o/J2ui3/zDCDEEm5O3A+a2NqXEZwCxPOHIlTFmq2b2BoCVCll9kHo3v1eBADZr+eiFXdSp7fU 2bfGRULs4JfvwkRtJZV4X+J9X9wi0iqpW+0zr2zubxhOe0gVtI44LE950hMAODAcL9y1FQ2hd CgscbmbiEr/qy3DJs44nONIkYgFEFp7RvBOWhmljFil8vZS3LUNqMBUCj1mH8BrEDNE/ZCJ+L rcet4DM8H7fvpHumxUnaDOP99wnMt0yRhyGQGFOwpd647ca6EVGO5u1A6zaDlwFaMO57sZT+M 9VpbPOw62jG6ganH5JdztwDsGLHLzeJf/k3TG4VThuUSzrJFhgUaZNoNsHilvhJhwcipAU5nq RhAlaWNCurA7c6nVqQm5damL28EP0plw0T1GgL+0PVWbQs9e1iMl9bToCFPyEnEyLUAmFxD+v fG0MooZaco37zn1wu8C/mI4aCMnPdS1/8YzYWdM/GmbXERuZpv+WNprUIFb0urNbJ90kotSDu v8CnMQu+y2RjcOa5/AzNAmUZfIBPdCI6zcrQYKi/oXYCNG8HVuC51TD3nUT3eDRbSdhFvNY+h i+JbFXidBJu67l4GhKXaGlnNPDDLuPrvU6pF4x7ytO0kP+29RaTzrwhC8yJ4RJ3dC1yfcvyal GZdZgM1Bx1TyzMApJeGKtsdjMUrVaYIU4y+GNRTWVqqTtFr5XT4/beMSDqA3Yx7Gmeeh3ZzZh NTjFljHYBHti8Kj+q4qG/vB8W2ow99nisaNqJeEAh7W7adTDm2SimmCUFDZkrrgYsrySu4CK0 ugiXt24UX1+4y1K711gLxRyWJlCMt84Xbtng29DLcD37JJtLSVfyrHwEx47Ji82Qif7BWyW9j XsvZYzpw4kwcne4KbeYdlLvf09MJZzrC8/1wFGkoevjH2C/9J6/bCzVhpQZAvXziSHBauCRWK 4pcv5eGOtmqAZYEMCeesWOpnCr7oG0WHVcrgQC/gHzLICF6A2ADMBnSFvXql0ShPLeiszedNh fyOr725An+kRvYLVXSgHxXYibmrrjBbClbieteRF9l/gk325pQKbKlbZy2MQ9olKiEyBntwJe jAGcoOkUKjO70Md7Zs/T4M9O1iOAstbHDZB66rQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/UJBWHoCw93KT7bJVXcUY6vq7e-Q>
Subject: [dhcwg] Fwd: WGLC for draft-ietf-dhc-dhcpv6-pd-relay-requirements - respond by August 17th, 2020
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Aug 2020 14:06:01 -0000

Hi Ted,

Many thanks for the review.  In addition to Naveen’s comments from 1/8, please see below.

Cheers,
Ian


> 
> In the introduction:
> 
>> Multi-hop relaying is also not considered as the functionality is solely required by a DHCP relay agent that is co-located with the first-hop router that the DHCPv6 client requesting the prefix is connected to
> 
> I didn’t actually see anything in this document that wouldn’t work for stacked relays.


[if - Rewritten to:

    Multi-hop DHCPv6 relaying is not affected, as the requirements
    in this document are solely applicable to the DHCP relay agent
    co-located with the first-hop router that the DHCPv6 client
    requesting the prefix is connected to, no changes to any
    subsequent relays in the path are needed.
]


> 
> 3.1, you introduce the concept here that the delegating router has a “lease”.  This is actually a new concept and should probably be explained. I assume that what’s meant here by “lease” is “route”. Routes can have preferred and valid lifetimes. Does it make sense to just use the term “route” rather than “lease?”  Is there information _other_ than routes bound to these leases?  It seems like you used the term “lease” in 4.1, but then switch to “prefixes and associated next-hops” in 4.2, but you probably mean the same thing in both cases, so defining the term here would help.

[if - In addition to the route for the delegated prefix, the relay also holds information about the client that it is delegated to (client-DUID, IAID) and timers for the delegation.

We use the term ‘lease entry’ in the text as it is a record of the relay relevant info contained in the prefix lease, not just a routing entry. What about the following:

old:
   For example, the delegating router already has an active PD lease
   entry for an existing client on a port.

new:
   For example, the delegating router already has an active PD lease
   entry bound to the client DUID of an existing client on a port.
]

> 
> G-1, you should word this in a way that doesn’t make the reader wonder if encapsulating the message is okay. Obviously that’s the intent, but it would be worth removing that doubt by saying so explicitly. Also, do you mean “delegating router” or “delegating relay?” It doesn’t make sense to me if you really meant “delegating router.”

[if - The above change to the wording for multi-hop relaying above should clear this up.

Delegating router should be delegating relay. Changed.]


> 
> G-6, is a /60 one prefix or sixteen?

[if - One.

Actually, this raised an interesting point about scalability of prefix routing entries in the relay if every shorter prefix is rendered into a set of component /64 (I have a vague memory of seeing this happen somewhere). What about adding an R-5 with:


The delegating relay’s routing entry MUST use the prefix length for the delegated prefix as given in the IA_PD.
]

> 
> G-8, why “at least 8” and not “at least 16” or “at least 4”? Are these /64s, or /56’s, or doesn’t matter?  I ask because one model for doing this would be to just allocate /64s piecemeal to clients that request them, and to layer delegating routers to make the routing work, rather than delegating a whole /56 or /48 to each customer.  Is that what you have in mind?

[if - Originally, the text just said that there should be a configurable limit without suggesting a value. Bernie’s review suggested that a default number should be given and we hit on 8 for want of a better value:

https://mailarchive.ietf.org/arch/msg/dhcwg/sk-IM5gSQPrIistauhD3defIMEo/

Also see comment above.]


> 
> S-1 doesn’t completely solve the problem: there is no required behavior. Do you mean that the relay MUST do one of the two proposed solutions, and MAY do both, or do you really intend to leave this as a potential gap?

[if - S-1 only gives a RECOMMENDED and then 2 possible solutions. RECOMMENDED was used here as some relay devices can be fairly simple wouldn’t be able to implement either of the options.

Suggest that RECOMMENDED in the S-1 text is changed to read:

"the relay SHOULD implement at least one of the following:”

and then remove the MAY/SHOULD from the proposed solution wording.]


> 
> S-3 why MAY and not SHOULD?

[OK]

> 
> O-2: how does this interact with active leasequery?

[if - It doesn’t, AFAICT. I haven’t actually seen a relay which implements active lease query, but the intention behind the requirement is to allow the operator to manually fix sync problems between the relay/server when they occur. Active leasequery may help reduce the occurrences of such problems, but doesn’t offer a mechanism whereby the removal of a lease binding entry on a relay could be used to signal to the server that the client’s lease is released.]

> 
> Thanks for working on this (authors)! Let me know if what I said doesn’t make sense. :)
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg