Subject: [v6ops] New Version Notification for draft-patterson-intarea-ipoe-health-01.txt

From: Richard Patterson <[email-masked]>
Date: Tue, 12 Jun 2018 12:11:01 +0100

A new version of draft-patterson-intarea-ipoe-health has been posted.

The major change since -00, is the inclusion and preference of BFD
Echo as the health check mechanism when available.
The draft now has an informational reference to Broadband Forum's
TR-146 document which also discusses this problem.

The authors believe that this draft builds on the method suggested in
TR-146 in the following ways:
- Prefers BFD Echo, but allows for ARP/ND methods when not available.
- Defaults to DHCP renew as an action, but specifies optional
alternative actions to expedite recovery.
- Provides a DHCP Option to allow network administrators to signal
parameters dynamically to CEs.

On 12/06/2018, 10:11, "[email-masked]"
<[email-masked]> wrote:

    A new version of I-D, draft-patterson-intarea-ipoe-health-01.txt
    has been successfully submitted by Richard Patterson and posted to the
    IETF repository.

    Name:draft-patterson-intarea-ipoe-health
    Revision:01
    Title:IPoE Client Health Checking
    Document date:2018-06-12
    Group:Individual Submission
    Pages:12
    URL:
https://www.ietf.org/internet-drafts/draft-patterson-intarea-ipoe-health-01.txt
    Status:
https://datatracker.ietf.org/doc/draft-patterson-intarea-ipoe-health/
    Htmlized:
https://tools.ietf.org/html/draft-patterson-intarea-ipoe-health-01
    Htmlized:
https://datatracker.ietf.org/doc/html/draft-patterson-intarea-ipoe-health
    Diff:
https://www.ietf.org/rfcdiff?url2=draft-patterson-intarea-ipoe-health-01

    Abstract:
       PPP over Ethernet clients have the functionality to detect path
       unavailability by using PPP Keepalives.  IP over Ethernet does not
       have this functionality, and it's not specified when an IP over
       Ethernet client should consider its WAN connectivity down, unless
       there is a physical layer link down event.

       This document describes a way for IP over Ethernet clients to achieve
       connectivity validation, similar to that of PPP over Ethernet, by
       using BFD Echo, or ARP and Neighbor Discovery functions.

    Please note that it may take a couple of minutes from the time of submission
    until the htmlized version and diff are available at tools.ietf.org.

    The IETF Secretariat

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Tue, 12 Jun 2018 15:06:34 +0000

Hi Richard,

"4.3.  Behaviour 2: Expire Lease"

Typo: Behavior

- Is this option an attempt for the lease RENEW-al but not using RENEW?
- If not, what is the benefit of not sending RELEASE? 
- If yes, is DHCPv6 client going to send the same address in SOLICIT? Is DHCPv6 client going to unicast SOLICIT to the same DHCPv6 server, if OPTION_UNICAST was set for the lease?

Thanks,
Dusan.

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of Richard
> Patterson
> Sent: Tuesday, June 12, 2018 7:11 AM
> To: [email-masked] list <[email-masked]>
> Subject: [v6ops] New Version Notification for draft-patterson-intarea-ipoe-
> health-01.txt
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_internet-2Ddrafts_draft-2Dpatterson-2Dintarea-2Dipoe-
> 2Dhealth-
> 2D01.txt&d=DwIGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iC
> rhIoUWB8YLZU23029sMQGQ2kY&m=EBdxMMCB_3bhRx7Mk5RhobLPuxgDn
> mbU6VSjpN4g1BY&s=bjBu9v7AUFYPKnWlcbMcpVAUCBAQAQkjarrZ0rAAUM
> s&e=
>     Status:
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dpatterson-2Dintarea-2Dipoe-
> 2Dhealth_&d=DwIGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3
> iCrhIoUWB8YLZU23029sMQGQ2kY&m=EBdxMMCB_3bhRx7Mk5RhobLPuxgD
> nmbU6VSjpN4g1BY&s=dpxyyPBoO4A6BEutg0KaTT2q1PFWSUd9xsjOPqel58s
> &e=
>     Htmlized:
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__tools.ietf.org_html_draft-2Dpatterson-2Dintarea-2Dipoe-2Dhealth-
> 2D01&d=DwIGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhI
> oUWB8YLZU23029sMQGQ2kY&m=EBdxMMCB_3bhRx7Mk5RhobLPuxgDnmb
> U6VSjpN4g1BY&s=ThEknV5dGWD2dWjPit9UcR0zTReSLb_HDbhDFN6SyCU&e
> =
>     Htmlized:
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_html_draft-2Dpatterson-2Dintarea-2Dipoe-
> 2Dhealth&d=DwIGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3i
> CrhIoUWB8YLZU23029sMQGQ2kY&m=EBdxMMCB_3bhRx7Mk5RhobLPuxgD
> nmbU6VSjpN4g1BY&s=wL3Cutrjzfyx5SLpM8qVzG4FHPxZoUkqzriELn3kuLM&
> e=
>     Diff:
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dpatterson-2Dintarea-2Dipoe-
> 2Dhealth-
> 2D01&d=DwIGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhI
> oUWB8YLZU23029sMQGQ2kY&m=EBdxMMCB_3bhRx7Mk5RhobLPuxgDnmb
> U6VSjpN4g1BY&s=cxcZ0tpDBRZc1iXSIKE9riKY-d6uMoShAsUvtPxFVTE&e=
> 
>     Abstract:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_v6ops&d=DwIGaQ&c=BFpWQw8bsuKp
> l1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=EBd
> xMMCB_3bhRx7Mk5RhobLPuxgDnmbU6VSjpN4g1BY&s=geRPXtDiGajRjqb31
> HRjp1le3zrflYjy6yhXPDSBouc&e=

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 12 Jun 2018 15:31:56 +0000

>    - If yes, is DHCPv6 client going to send the same address in SOLICIT? Is DHCPv6 client going to unicast SOLICIT to the same DHCPv6 server, if OPTION_UNICAST was set for the lease?
 
SOLICITs must not be unicast.

See https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-13#section-16:

   A server MUST discard any Solicit, Confirm, Rebind or Information-
   request messages it receives with a layer-3 unicast destination
   address.

A client can certainly include the address it previously had in a Solicit (though most likely if the same server is present, that is not necessary as the server will likely use the existing address). There are also privacy considerations for including this in the Solicit (since the client may have moved to a different network).

- Bernie

On 6/12/18, 11:06 AM, "v6ops on behalf of Mudric, Dusan (Dusan)" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Richard,

    Typo: Behavior

    Thanks,
    Dusan.
    
    _______________________________________________
    v6ops mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/v6ops

---

From: Richard Patterson <[email-masked]>
Date: Tue, 12 Jun 2018 16:57:28 +0100

Hi Dusan,

Thanks for the review, responses in-line:

> "4.3.  Behaviour 2: Expire Lease"
[RP] Isn't British spelling accepted as long as it's consistent
throughout the document?  I can s/behaviour/behavior/ if required.

> - Is this option an attempt for the lease RENEW-al but not using RENEW?
[RP] This action is for when the subscriber state in the network has
been lost, regular RENEWs will likely be dropped by the network, until
the network can authenticate the IPoE Client again, which is usually
done based on a DHCPv4 DISCOVER or DHCPv6 SOLICIT.

> - If not, what is the benefit of not sending RELEASE?
[RP]  A Release instructs the DHCP server to relinquish the lease
entirely.  Avoiding this step allows a client to potentially rebind
the previously leased IP/prefix, which can reduce the customer
experience impact when operating with dynamic leases.

> - If yes, is DHCPv6 client going to send the same address in SOLICIT? Is DHCPv6 client going to unicast SOLICIT to the same DHCPv6 server, if OPTION_UNICAST was set for the lease?
[RP] This document relies on existing DHCP messaging, and we don't
want to adjust that behaviour.  I don't believe anything in 3315
specifies that a SOLICIT could be unicast following a lease
expiration?  I believe OPTION_UNICAST is for just in-life messaging as
opposed to server discovery, but I could be wrong.
The client can include the previously leased prefix in the REQUEST,
the server may accept it if it's available, or NAK it.

To simplify adoption we've attempted to reuse existing functionality
where possible, hence the use or ARP/ND and just adjusting the T1/T2
timers to trigger the usual DHCP processes.

Given the above, Dusan, do you think the wording in the draft needs
clarification?

-Richard

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Tue, 12 Jun 2018 18:27:10 +0000

Hi Richard,

Even if the intention is not to change the existing DHCPv6 protocol "on the wire", I think you need to clarify a bit the section " 4.3.  Behaviour 2: Expire Lease". For example, the goal is to keep the existing lease even with the new solicitation. 

For client to keep the existing lease, the DHCPv6 server and lease selection algorithm needs to change after ADVERTISE. If the server preference has changed, the client should not select the server with the highest OPTION_PREFERENCE, but rather the one that issued the current lease. Considering the lease will not be RELEASE-d, the server will not offer the lease for the new solicitation. The client should use Server Identifier to select the preferred server.

If the server that issued the lease is not the most preferred any more, the client should ignore the OPTION_UNICAST from the most preferred server, and should unicast REQEST, with the existing lease, to the server that issued the lease, or multicast REQUEST.

Regards,
Dusan.

> From: Richard Patterson [mailto:[email-masked]]
> Sent: Tuesday, June 12, 2018 11:57 AM
> To: [email-masked] list <[email-masked]>; Mudric, Dusan (Dusan)
> <[email-masked]>
> Subject: Re: [v6ops] New Version Notification for draft-patterson-intarea-
> ipoe-health-01.txt
> 
> Hi Dusan,
> 
> > - If yes, is DHCPv6 client going to send the same address in SOLICIT? Is
> DHCPv6 client going to unicast SOLICIT to the same DHCPv6 server, if
> OPTION_UNICAST was set for the lease?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 13 Jun 2018 07:04:21 +0200 (CEST)

On Tue, 12 Jun 2018, Mudric, Dusan (Dusan) wrote:

> lease. Considering the lease will not be RELEASE-d, the server will not 
> offer the lease for the new solicitation. The client should use Server

Hm, I am not an DHCPv6 expert, but in my experience if I power off a 
device with an active lease, power it on again, it comes up again and does 
SOLICIT, it will get the same prefix back that it had before the power 
off (it does not provide any prefix information in the solicit).

What am I missing here?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Wed, 13 Jun 2018 15:01:55 +0000

I expect the server to deliver the same prefix, if the client is using PD to create the addresses. But I would not expect the server to offer the address already in use, unless the server check the client identifier and is able to figure out which address is used by the client.

Dusan

> From: Mikael Abrahamsson [mailto:[email-masked]]
> Sent: Wednesday, June 13, 2018 1:04 AM
> To: Mudric, Dusan (Dusan) <[email-masked]>
> Cc: Richard Patterson <[email-masked]>; [email-masked] list
> <[email-masked]>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 14 Jun 2018 05:41:47 +0200 (CEST)

Why would it not check the client identifier?

On Wed, 13 Jun 2018, Mudric, Dusan (Dusan) wrote:

> I expect the server to deliver the same prefix, if the client is using 
> PD to create the addresses. But I would not expect the server to offer 
> the address already in use, unless the server check the client 
> identifier and is able to figure out which address is used by the 
> client.
>
> Dusan
>