Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-pd-relay-requirements

Hi:

Thanks.

Please see BV> below.

- Bernie

-----Original Message-----
From: ianfarrer@gmx.com <ianfarrer@gmx.com> 
Sent: Wednesday, September 9, 2020 5:29 AM
To: Bernie Volz (volz) <volz@cisco.com>; Ole Troan <otroan@employees.org>
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-pd-relay-requirements - respond by August 17th, 2020

Hi Bernie / Ole

Please see inline below. Where there is no additional comment, we’ve adopted Bernie’s suggestions.

Thanks,

> On 19. Aug 2020, at 00:15, Bernie Volz (volz) <volz=40cisco.com@dmarc.ietf.org> wrote:
> 
> Thanks Ole ... I had also flagged that requirement as an issue in my shepherd review as it is not very clear.
> 
> I think the not configured on the relay means that the destination address hasn't been assigned as an address on one of the relay's interfaces.
> 
> I do wonder though what the "normal" router behavior would be - would it not just send the packet back and also send an ICMP redirect? And, why does this needs to be called out specially isn't clear?

[if - Yes, 

The requirement is intended to hand the case where, for whatever reason, the client’s routing traffic towards the delegating relay with a destination in the prefix that it’s been delegated. i.e. something’s wrong with the client’s routing. The obvious exception to this is if the link between the client and delegating relay has a prefix that is part of the delegation (e.g. the PD exclude case). 

The current wording is pretty unclear. How about:

old:
If the relay has an existing route for a delegated prefix via  an interface, and receives ingress traffic on this interface  with a destination address from the delegated prefix (not configured on the relay), then it MUST be dropped.

new:
If the relay has learned a route for a delegated prefix via a given interface, and receives traffic on this interface with a destination address within the delegated prefix (but not directly connected to the relay), then it MUST be dropped.  This is to prevent routing loops.

BV> "(but not directly connected to the relay)" is a bit odd ... perhaps "where this address is not assigned to the relay" (remove the parentheses).
BV> Additional question ... RFC7084 has WPD-5 and they added an (a) about ICMPv6 Destination Unreachable ... do you want to say anything about whether to send ICMPv6 or not (probably not)?

> 
> 
> Anyway, here's my comments for the shepherd review.
> 
> First, I do support this document moving forward.
> 
> Abstract:
> 
> "when the DHCPv6 relay function is not co-located with the DHCPv6 server function" is a bit weird as why would the relay even be needed in this case?

[if - The abstract is now Ted’s suggested wording:

This memo describes operational problems that are known to
    occur when using DHCPv6 relays with Prefix Delegation. These
    problems can prevent successful delegation and in result routing

BV> I think you want s/in result/result in/

    failures. To address these problems, this memo provides necessary
    functional requirements for operating DHCPv6 relays with Prefix
    Delegation.]

> 
> And, "time synchronization between DHCP functional elements" is really not covered much - it translate into O-3 as best I can gather? Just wondering if it is really worth mentioning in the abstract - but that leaves just "rejection of client's messages and other problems". Perhaps reworking this to provide a list of the main problems is worth considering? FYI  - you could add some kind of data recovery/persistence in case of 'crash'/restart?

[if - It did read ’timer syncronization’ - i.e. related to the times present in DHCP messages, but this text is no longer present.]

BV> So, I'm not sure what the plan is with respect to this text? DHCP has a generic time synchronization problem in that everything is relative to when received (not necessarily transmitted) and resolution is seconds and no strong requirement for clocks to tic consistently. This is often why grace periods are applied to lease expiration times (though in most cases, this is probably also not necessary given that the client is probably not there as otherwise it would have renewed).

——

> 
> I'm not so clear why the last paragraph is important. And, it doesn't translate into a requirement? Perhaps one should be added if you think this is worth pointing out (over and above what RFC8415 has). Note that section 3.1 deals more with known messages and 'acting as a server’.

[if - Removed the last paragraph.]

-----

> 
> Would adding something about "or contains an unknown option" be useful to include here ... we don’t want relay's to not forward messages because they don't understand a "new" option? But this is already covered in Section 16 of RFC8415 (see below), so it may not be worth re-enforcing this as RFC8415 is already clear on this. I just raise it for your consideration (feel free to ignore).
> 
>   Clients, relay agents, and servers MUST NOT discard messages that
>   contain unknown options (or instances of vendor options with unknown
>   enterprise-number values).  These should be ignored as if they were
>   not present.  This is critical to provide for future extensions of
>   DHCP.
> 
> I might add that perhaps a new paragraph to this section that reads something like:
> 
> 	Relay implementers are reminded that RFC8415 makes it clear that relays MUST NOT drop
> 	(and hence not relay) packets that either contains message codes (Section 19 of RFC8415)
> 	it may not understand or contain options that it does not understand (Section 16 of RFC8415).
> 
> Or perhaps just add to General Requirements?

[if - removed this as requirement G-2, and now have your suggested ‘Relay implementors are reminded…’ text in the General Requirements intro.]

----

> 
> Section 4
> 
> Comment related to the requirements ... should these be tied back to the earlier sections? In some cases, it seems that requirements were added that aren't directly related to the earlier discussions? Should there be a "See section 3.x" added to identify where the requirement came from?
> 

[if - As the functionality of a delegating relay have not previously been defined, there isn’t a direct mapping between each of the requirements and a problem which has been observed in implementations.  The aim behind this draft is to resolve what we have seen, and hopefully pre-empt other undesirable behaviour.]

BV> Perhaps text in 4.0 should say "To resolve the problems described in Section 3 and pre-empt other undesirable behavior, the following sections"? Or something like that?

---

> 
> Section 4.2:
> I had issues with R-4 ... see Ole's discussion and the top of this message.

[if - See above]

> 

> - Bernie
> 
> -----Original Message-----
> From: otroan@employees.org <otroan@employees.org>
> Sent: Tuesday, August 18, 2020 3:24 AM
> To: Bernie Volz (volz) <volz@cisco.com>
> Cc: dhcwg@ietf.org
> Subject: Re: [dhcwg] WGLC for 
> draft-ietf-dhc-dhcpv6-pd-relay-requirements - respond by August 17th, 
> 2020
> 
> I have read through the document, reading section 4 thoroughly.
> I think it looks fine and ready to advance.
> 
> A comment:
> 
>   R-4:    If the relay has an existing route for a delegated prefix via
>           an interface, and receives ingress traffic on this interface
>           with a destination address from the delegated prefix (not
>           configured on the relay), then it MUST be dropped.
> 
> I struggle to understand what R-4 is trying to say.
> In one sentence it says it has a delegated prefix, then it says "not configured on the relay"...?
> 
> 
> Best regards,
> Ole
> 
> 
> 
>> On 17 Aug 2020, at 19:23, Bernie Volz (volz) <volz=40cisco.com@dmarc.ietf.org> wrote:
>> 
>> Hi … just a friendly reminder. We’ve had very little input to the WGLC.
>> 
>> Tim and I will review the responses and evaluate the WGLC later this week (Friday), so you do have a few more days to respond.
>> 
>> 	• Bernie
>> 
>> From: dhcwg <dhcwg-bounces@ietf.org> On Behalf Of Bernie Volz (volz)
>> Sent: Tuesday, August 11, 2020 8:20 AM
>> To: dhcwg@ietf.org
>> Subject: Re: [dhcwg] WGLC for 
>> draft-ietf-dhc-dhcpv6-pd-relay-requirements - respond by August 17th, 
>> 2020
>> 
>> Hi … just a friendly reminder regarding this WGLC.
>> 
>> Thanks to Ted Lemon for reviewing and commenting!
>> 
>> 	• Bernie
>> 
>> From: Bernie Volz (volz) <volz@cisco.com>
>> Sent: Saturday, August 1, 2020 11:07 AM
>> To: dhcwg@ietf.org
>> Cc: dhc-chairs@ietf.org
>> Subject: WGLC for draft-ietf-dhc-dhcpv6-pd-relay-requirements - 
>> respond by August 17th, 2020
>> 
>> Hi:
>> 
>> The authors believe this document is ready for WGLC. Therefore, the chairs are initiating a WGLC on this document.
>> 
>> Please review this document and provide your comments and whether you support this document moving forward or not by end of day on Monday, August 17th, 2020.
>> 
>> Please see https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-pd-relay-requirements-01.. This is a Standards Track document.
>> 
>> There are no IPR notices filed against this work (as of this writing).
>> 
>> Thank you!
>> 
>> 	• Tim & Bernie
>> 
>> --
>> 
>> From: Naveen Kottapalli <naveen.sarma@gmail.com>
>> Sent: Saturday, August 1, 2020 8:20 AM
>> To: dhcwg@ietf.org; dhc-chairs@ietf.org
>> Subject: Requesting a WGLC of 
>> draft-ietf-dhc-dhcpv6-pd-relay-requirements
>> 
>> Hello chairs,
>> 
>> We, as authors of the draft, are of the opinion that the draft is ready for WGLC.  Can you please check and initiate the same?
>> 
>> Yours,
>> Naveen.
>> _______________________________________________
>> dhcwg mailing list
>> dhcwg@ietf.org
>> https://www.ietf.org/mailman/listinfo/dhcwg
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg