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

Naveen Kottapalli <naveen.sarma@gmail.com> Fri, 07 August 2020 03:45 UTC

Return-Path: <naveen.sarma@gmail.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 748063A0DE1; Thu, 6 Aug 2020 20:45:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 (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 4PiqUjZiU-T5; Thu, 6 Aug 2020 20:45:36 -0700 (PDT)
Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 E98353A0DDC; Thu, 6 Aug 2020 20:45:35 -0700 (PDT)
Received: by mail-il1-x133.google.com with SMTP id x1so670512ilp.7; Thu, 06 Aug 2020 20:45:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mdAn+N4fcp29b9l3xHg7JVNON7OWSBmeYL/LMquk9HE=; b=dX74eJjYysSOkWthSOohw0ncHKjOM4R60VkEIvF0M139ig0LgnQuq4NBhdP9qMw/gE 2TAWNzwrcU7xeFfFJ3owGW0jSnQ9JLq+gfQ8nP1QcRfvfgy0VN7fAsU3egdglGKE8wVp aMv+T/wtPUUIirX8OS+lNeyPXjpIw/9CTK3NNrXJC1TfVnCgtmTlG3No9jZP2OluYwa9 wuxWoOBK1F+MTY7JnPncr/tgQ/3226br8BhMQulKPkQ0F4ZfyqDwr/ssehmED4mUvcrj mgGz5sbFE9jjAERnPZ3s9Pto/HyoCjILZ/drDvcjOLAoA0NW7tI2e7Tzbmjb42qQde1x Djxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mdAn+N4fcp29b9l3xHg7JVNON7OWSBmeYL/LMquk9HE=; b=NYZ+fkBvHvm3Hk8AtyVoy/+Sb6rOrLxZOadbRNIuYhK7eNwmMyFZHXxEzmAKVpC3Kj YR20UJ2CQbhGryagMzOq5D39yi1NKNPboOfqNo83wUXhbQbQ8jhkb38h1qzoIXKiaAg2 dP4WlJxNKFjT3eMja1YyyFULA0ydUNOwEL34VhtQA12vV/4U4PG0banPf12G9vlR0aKC dQ2N8Qk2xDEsgmwI6c7f4+p7sWKHYMbm9hBnj1RpnHDNxLYaGwtE1BS4a73t8hUTIuKy Y3CeCoxWLrkn3AGoDIj4tX2hefYYtsoqYTETT7UObIpTlD5chr+7RCW0bknFNlHqPM2n qIpA==
X-Gm-Message-State: AOAM530TrM0Bpph0LS0TbaUDxRjomp8mk912dvDbPTdzpru1Iu1YwiLR xMoJFOqJKVj5+eUSbKZoCO67fKZzpZxN47Leoro=
X-Google-Smtp-Source: ABdhPJy086RBAAoq/AyHWodKlQDGizV5l66s1bZd5V3SxKEdWO3VvRGFqzrT53o91yNEJf21GimmPodmBf6/G2whpFk=
X-Received: by 2002:a92:d5d0:: with SMTP id d16mr2661372ilq.114.1596771935170; Thu, 06 Aug 2020 20:45:35 -0700 (PDT)
MIME-Version: 1.0
References: <BN7PR11MB254783295780CA79CDA1FAB3CF4F0@BN7PR11MB2547.namprd11.prod.outlook.com> <14A3879A-EA9D-46F1-91AF-6F7185CC16DC@fugue.com> <CANFmOtnpopk7Jcav=d5Boio6yZfZcsr1KTepnOYgQoDk0X56pw@mail.gmail.com>
In-Reply-To: <CANFmOtnpopk7Jcav=d5Boio6yZfZcsr1KTepnOYgQoDk0X56pw@mail.gmail.com>
From: Naveen Kottapalli <naveen.sarma@gmail.com>
Date: Fri, 7 Aug 2020 09:15:25 +0530
Message-ID: <CANFmOtmi99ib5a571QZyhwa45Y4v6RorkYpDhmRzZLg1MDiq1A@mail.gmail.com>
To: Ted Lemon <mellon@fugue.com>
Cc: "Bernie Volz (volz)" <volz@cisco.com>, dhcwg@ietf.org, dhc-chairs@ietf.org
Content-Type: multipart/alternative; boundary="000000000000fbb67005ac416ff0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/-OJig2ajnjvcglURYK31WdScqac>
Subject: Re: [dhcwg] 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: Fri, 07 Aug 2020 03:45:39 -0000

Hello Ted,

Thanks a lot for the review.  Please find comments inline.

Yours,
Naveen

>
> On Sat, 1 Aug 2020 at 22:04, Ted Lemon <mellon@fugue.com> wrote:
>
>> I think the document is important, and I support advancement. Some
>> observations:
>>
>> The abstract is quite long and doesn’t accomplish the purpose of telling
>> the reader why they should read the document. Suggestion:
>>
>> This memo describes operational problems that are known to occur when
>> using DHCPv6 relay with Prefix Delegation. These problems can prevent
>> successful delegation and in result routing failures.To address these
>> problems, this memo provides necessary functional requirements for
>> operating DHCPv6 relay with Prefix Delegation. It is recommended that any
>> network operator that is using DHCPv6 prefix delegation with relays should
>> ensure that these requirements are followed on their networks.
>>
>> Naveen] Will change the text as suggested.
>
>> 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.
>>
>> In 2.1, it would be nice to have references here, if you can find stable
>> pointers:
>> > In CableLabs DOCSIS environments, the Cable Modem Termination System
>> (CMTS) would be considered a delegating relay with respect to Customer
>> Premises Devices (CPEs).  A Broadband Network Gateway (BNG) in a DSL based
>> access network may be a delegating relay if it does not implement a local
>> DHCPv6 server function.
>>
>> Naveen] Will update.
>>
>
>
>> 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.
>>
>
>
>> Naveen]  Yes.  A mapping of route, incoming interface, lease timers,
>> etc., will be maintained against the lease.  Also, changed the prefixes to
>> leases in 4.2 as well.
>>
>
>
>> 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."
>>
>
> Naveen] Changed from delegating router to delegating relay
>
>>
>> G-2, you might consider framing this as “the relay MUST NOT discard
>> messages because it doesn’t recognize one or more options in that message.”
>>
>> Naveen] Done
>
>
>> G-5, I think by “device” you mean delegating relay; if so, should say so
>> explicitly, because otherwise it’s a bit confusing. I suppose part of the
>> problem is that you are saying that interfaces implement the delegating
>> relay function, which seems weird. Maybe “A delegating relay may have one
>> or more interfaces on which it acts as a relay, as well as one or more
>> interfaces on which it does not (for example, in an ISP, it might act as a
>> relay on all southbound interfaces, but not on the northbound interfaces).
>> The relay SHOULD allow the same client identifier… etc
>>
>
> Naveen] Changed accordingly.
>
>>
>> G-6, is a /60 one prefix or sixteen?
>>
>
> Naveen] One.
>
>>
>> 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?
>>
>
> Naveen] It can be either /56 or /48.  The same lease that is given by the
> server will be maintained here.  There is not much logic behind the number
> 8.  Since the lease context information consumes memory, the reasonable
> number we came up with is 8.
>
>>
>> R-2, do you need to specify that in addition to maintaining access
>> control lists, the router needs to block packets from invalid sources?  The
>> term “access control list” is not used in BCP-38. Is there a more recent
>> reference that explains this, or does it need to be explained here?
>>
>
> Naveen]  Changed accordingly.
>
>>
>> R-4, is the goal to prevent routing loops? I’m not clear on why this
>> needs to be said.
>>
>
> Naveen] Yes.  This is added to be more explicit.
>
>>
>> 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?
>>
>
> Naveen] The idea is that relays MAY implement at least one of them to
> mitigate risk of reboot.
>
>>
>> S-3 why MAY and not SHOULD?
>>
>
> Naveen] Changed
>
>>
>> O-2: how does this interact with active leasequery?
>>
>
> Naveen] This is an operational requirement at delegating relay node to
> clear the active bindings through CLI or REST API or any other means.
>
>>
>> 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
>>
>