Subject: Re: [dhcwg] Adoption Call for draft-fkhp-dhc-dhcpv6-pd-relay-requirements - Respond by Jan 14, 2020

From: Naveen Kottapalli <[email-masked]>
Date: Fri, 3 Jan 2020 08:04:18 +0530

Happy new Year.

I support.

Yours,
Naveen

On Sun, 29 Dec 2019, 21:33 Bernie Volz (volz), <[email-masked]> wrote:

> Hello:
>
>
>
> As follow up from the IETF-106 DHC WG meeting, we are initiating the WG
> call for adoption on
> *https://datatracker.ietf.org/doc/draft-fkhp-dhc-dhcpv6-pd-relay-requirements/*
> <https://datatracker.ietf..org/doc/draft-fkhp-dhc-dhcpv6-pd-relay-requirements/>
> (DHCPv6 Prefix Delegating Relay). This document was presented at IETF-106 –
> see
> https://datatracker.ietf.org/meeting/106/materials/slides-106-dhc-dhcpv6-prefix-delegating-relay-00
> .
>
>
>
> This starts the call for Adoption of this document. Please respond by
> January 14, 2020.
>
>
>
> Thanks in advance for your consideration of whether the WG should or
> should not adopt this document as a work item.
>
>
>
> And, Happy New Year!
>
>
>
>    - Tomek & Bernie
>
>
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 8 Jan 2020 01:31:11 +0000

Hi:

A reminder - we are looking for an indication of interest in adopting this work in the DHC WG, or whether anyone is opposed to it.

For the record (with WG chair hat OFF), I support adopting this work. I think this document would help vendors to supply better products and improve subscriber experience for networks in which prefix delegation is used.

  *   Bernie

From: dhcwg <[email-masked]> On Behalf Of Bernie Volz (volz)
Sent: Sunday, December 29, 2019 11:03 AM
To: [email-masked]
Subject: [dhcwg] Adoption Call for draft-fkhp-dhc-dhcpv6-pd-relay-requirements - Respond by Jan 14, 2020

Hello:

As follow up from the IETF-106 DHC WG meeting, we are initiating the WG call for adoption on https://datatracker.ietf.org/doc/draft-fkhp-dhc-dhcpv6-pd-relay-requirements/<https://datatracker.ietf..org/doc/draft-fkhp-dhc-dhcpv6-pd-relay-requirements/> (DHCPv6 Prefix Delegating Relay). This document was presented at IETF-106 - see https://datatracker.ietf.org/meeting/106/materials/slides-106-dhc-dhcpv6-prefix-delegating-relay-00.

This starts the call for Adoption of this document. Please respond by January 14, 2020.

Thanks in advance for your consideration of whether the WG should or should not adopt this document as a work item.

And, Happy New Year!

  *   Tomek & Bernie

---

From: [email-masked]
Date: Wed, 8 Jan 2020 11:05:50 +0100

Hi Bernie,

Thanks for the reminder. I support its adoption (as a co-=author).

Thanks,
Ian

> On 8. Jan 2020, at 02:31, Bernie Volz (volz) <[email-masked]> wrote:
> 
> Hi:
>  
> A reminder – we are looking for an indication of interest in adopting this work in the DHC WG, or whether anyone is opposed to it.
>  
> Bernie
> As follow up from the IETF-106 DHC WG meeting, we are initiating the WG call for adoption onhttps://datatracker.ietf.org/doc/draft-fkhp-dhc-dhcpv6-pd-relay-requirements/ <https://datatracker.ietf...org/doc/draft-fkhp-dhc-dhcpv6-pd-relay-requirements/> (DHCPv6 Prefix Delegating Relay). This document was presented at IETF-106 – seehttps://datatracker.ietf.org/meeting/106/materials/slides-106-dhc-dhcpv6-prefix-delegating-relay-00 <https://datatracker.ietf.org/meeting/106/materials/slides-106-dhc-dhcpv6-prefix-delegating-relay-00>.
>  
> Tomek & Bernie

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 8 Jan 2020 12:00:47 +0100

Hi,
I support it.  I am not a co-author.

In the past I did work with colleagues on an implementation for Relay 
with PD.

Since then I realized that operators offering Internet access with 
DHCPv6-PD might benefit from a server-relay seggregation to accommodate 
a larger number of users and richer applications.

There might be obstacles in achieving that, however.  These obstacles 
might not come from the DHCPv6 nor PD technology nor DHCP standards. 
They might come from the architecture of IPv6 which still imposes a 64 
limit, which effectively limits the genericity of the prefix length in 
DHCPv6-PD.

I hope these things will advance  hand in hand and wish all the best to 
the pd-relay-requirements draft.

Alex

Le 08/01/2020 à 11:05, [email-masked] a écrit :
>> On 8. Jan 2020, at 02:31, Bernie Volz (volz) <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hi:
>> A reminder – we are looking for an indication of interest in adopting 
>> this work in the DHC WG, or whether anyone is opposed to it.
>> For the record (with WG chair hat OFF), I support adopting this work. 
>> I think this document would help vendors to supply better products and 
>> improve subscriber experience for networks in which prefix delegation 
>> is used.
>>
>>   * Bernie
>>
>> *From:*dhcwg <[email-masked] 
>> <mailto:[email-masked]>>*On Behalf Of*Bernie Volz (volz)
>> *Sent:*Sunday, December 29, 2019 11:03 AM
>> *To:[email-masked] <mailto:[email-masked]>
>> *Subject:*[dhcwg] Adoption Call for 
>> draft-fkhp-dhc-dhcpv6-pd-relay-requirements - Respond by Jan 14, 2020
>> Hello:
>> As follow up from the IETF-106 DHC WG meeting, we are initiating the 
>> WG call for adoption 
>> onhttps://datatracker.ietf.org/doc/draft-fkhp-dhc-dhcpv6-pd-relay-requirements/ 
>> <https://datatracker.ietf...org/doc/draft-fkhp-dhc-dhcpv6-pd-relay-requirements/>(DHCPv6 
>> Prefix Delegating Relay). This document was presented at IETF-106 – 
>> seehttps://datatracker.ietf.org/meeting/106/materials/slides-106-dhc-dhcpv6-prefix-delegating-relay-00.
>> [email-masked] <mailto:[email-masked]>

---

From: Richard Patterson <[email-masked]>
Date: Wed, 8 Jan 2020 19:22:21 +0000

Likewise, as a co-author and a service provider, I think this will become a
useful document and support its adoption.

On Wed, 8 Jan 2020 at 10:06, <[email-masked]> wrote:

> A reminder – we are looking for an indication of interest in adopting this
> work in the DHC WG, or whether anyone is opposed to it.
>
> For the record (with WG chair hat OFF), I support adopting this work. I
> think this document would help vendors to supply better products and
> improve subscriber experience for networks in which prefix delegation is
> used.
>
>
>    - Bernie
>
>
> *From:* dhcwg <[email-masked]> *On Behalf Of *Bernie Volz (volz)
> *Sent:* Sunday, December 29, 2019 11:03 AM
> *To:* [email-masked]
> *Subject:* [dhcwg] Adoption Call for
> https://datatracker.ietf.org/doc/draft-fkhp-dhc-dhcpv6-pd-relay-requirements/
> <https://datatracker.ietf...org/doc/draft-fkhp-dhc-dhcpv6-pd-relay-requirements/>
>  (DHCPv6 Prefix Delegating Relay). This document was presented at
> IETF-106 – see

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 08 Jan 2020 20:30:29 +0100

Having observed the same problems in several deployments, I also support this document.

Regards,

Jordi

@jordipalet

El 8/1/20 20:22, "dhcwg en nombre de Richard Patterson" <[email-masked] en nombre de [email-masked]> escribió:

Likewise, as a co-author and a service provider, I think this will become a useful document and support its adoption.

Hi Bernie,

Thanks,

Ian

Hi:

·         Bernie

Hello:

As follow up from the IETF-106 DHC WG meeting, we are initiating the WG call for adoption onhttps://datatracker.ietf.org/doc/draft-fkhp-dhc-dhcpv6-pd-relay-requirements/ (DHCPv6 Prefix Delegating Relay). This document was presented at IETF-106 – seehttps://datatracker.ietf.org/meeting/106/materials/slides-106-dhc-dhcpv6-prefix-delegating-relay-00.

And, Happy New Year!

·         Tomek & Bernie

_______________________________________________ dhcwg mailing list [email-masked] https://www.ietf.org/mailman/listinfo/dhcwg 

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: <[email-masked]>
Date: Thu, 9 Jan 2020 09:35:27 +0000

Hi Bernie, all,

I support.

For the routing part, the draft may clarify that it focuses on the client-facing interface and not the one covered, e.g., in https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-prefix-pool-opt-03.

Cheers,
Med

De : dhcwg [mailto:[email-masked]] De la part de Bernie Volz (volz)
Envoyé : dimanche 29 décembre 2019 17:03
À : [email-masked]
Objet : [dhcwg] Adoption Call for draft-fkhp-dhc-dhcpv6-pd-relay-requirements - Respond by Jan 14, 2020

Hello:

And, Happy New Year!

  *   Tomek & Bernie

---

From: [email-masked]
Date: Thu, 9 Jan 2020 10:51:46 +0100

Hi Med,

The intro has the following text. Doesn’t this cover it?

   The mechanisms for the redistribution of remote routes learnt via
   DHCP PD is out of scope of the document.  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.

Thanks,
Ian

> On 9. Jan 2020, at 10:35, <[email-masked]> <[email-masked]> wrote:
> 
> Hi Bernie, all,
>  
> I support.
>  
> For the routing part, the draft may clarify that it focuses on the client-facing interface and not the one covered, e.g., in https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-prefix-pool-opt-03 <https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-prefix-pool-opt-03>.
>                                                      
> Cheers,
> Med
>  
> As follow up from the IETF-106 DHC WG meeting, we are initiating the WG call for adoption onhttps://datatracker.ietf.org/doc/draft-fkhp-dhc-dhcpv6-pd-relay-requirements/ <https://datatracker.ietf..org/doc/draft-fkhp-dhc-dhcpv6-pd-relay-requirements/> (DHCPv6 Prefix Delegating Relay). This document was presented at IETF-106 – see https://datatracker.ietf.org/meeting/106/materials/slides-106-dhc-dhcpv6-prefix-delegating-relay-00 <https://datatracker.ietf.org/meeting/106/materials/slides-106-dhc-dhcpv6-prefix-delegating-relay-00>.
>

---

From: <[email-masked]>
Date: Thu, 9 Jan 2020 10:41:45 +0000

Hi Ian,

That is a good start but I prefer if the text is more explicit, e.g.:

OLD:

   DHCP PD is out of scope of the document.

NEW:

   The mechanisms for a relay to inject aggregated routes on its network-facing interface

   based on prefixes learnt via DHCP-PD from a server are out of scope of the document.

Thank you.

Cheers,

Med

De : [email-masked] [mailto:[email-masked]]
Envoyé : jeudi 9 janvier 2020 10:52
À : BOUCADAIR Mohamed TGI/OLN
Cc : Bernie Volz (volz); [email-masked]
Objet : Re: [dhcwg] Adoption Call for draft-fkhp-dhc-dhcpv6-pd-relay-requirements - Respond by Jan 14, 2020

Hi Med,

Thanks,
Ian

On 9. Jan 2020, at 10:35, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:

Hi Bernie, all,

I support.

Cheers,
Med

De : dhcwg [mailto:[email-masked]] De la part de Bernie Volz (volz)
Envoyé : dimanche 29 décembre 2019 17:03
À : [email-masked]<mailto:[email-masked]>
Objet : [dhcwg] Adoption Call for draft-fkhp-dhc-dhcpv6-pd-relay-requirements - Respond by Jan 14, 2020

Hello:

As follow up from the IETF-106 DHC WG meeting, we are initiating the WG call for adoption onhttps://datatracker.ietf.org/doc/draft-fkhp-dhc-dhcpv6-pd-relay-requirements/<https://datatracker.ietf..org/doc/draft-fkhp-dhc-dhcpv6-pd-relay-requirements/> (DHCPv6 Prefix Delegating Relay). This document was presented at IETF-106 – see https://datatracker.ietf.org/meeting/106/materials/slides-106-dhc-dhcpv6-prefix-delegating-relay-00.

And, Happy New Year!

  *   Tomek & Bernie

_______________________________________________
dhcwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 10 Jan 2020 10:11:36 +0100

I forgot to say we wrote a draft about a Problem Statement in 2013:

draft-petrescu-relay-route-pd-problem-00.txt:
>    The operation of a prefix delegation procedure with the DHCPv6
>    protocol may need route setup and maintenance at the Delegating
>    Router, Requesting Router and on the entity on which the Relay agent
>    is implemented.  This document describes the problem of routing
>    during DHCPv6 prefix delegation, and is illustrated by ADSL-type and
>    cellular-type of topologies which may use Relays; we refer to section
>    14 of RFC 3633 which mentions the need of 'a protocol or other out of
>    band communication to add routing information for delegated
>    prefixes'.  Based on this problem, a number of requirements from the
>    service providers are described.

Alex

Le 08/01/2020 à 12:00, Alexandre Petrescu a écrit :
>>> I think this document would help vendors to supply better products 
>>> and improve subscriber experience for networks in which prefix 
>>> delegation is used.
>>>
>>>   * Bernie
>>>

---

From: [email-masked]
Date: Fri, 10 Jan 2020 15:22:02 +0100

Hi Med,

No problem with updating the wording, but suggest that the word ‘aggregated’ is removed, as this excludes the
case of ‘advertise every individual delegated’ prefix as soon as you learn it’. However, the ‘based on’ in the wording
includes the aggregation case as well:

old:

new:
The mechanisms for a relay to inject routes, on its network-facing interface
based on prefixes learnt from a server via DHCP-PD are out of scope of the document.

Thanks,
Ian

> On 9. Jan 2020, at 11:41, <[email-masked]> <[email-masked]> wrote:
> 
> Hi Ian,
>  
> On 9. Jan 2020, at 10:35, <[email-masked] <mailto:[email-masked]>> <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Bernie, all,
>  
> I support.
>  
> De : dhcwg [mailto:[email-masked] <mailto:[email-masked]>] De la part de Bernie Volz (volz)
> À : [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dhcwg <https://www.ietf.org/mailman/listinfo/dhcwg>

---

From: <[email-masked]>
Date: Fri, 10 Jan 2020 15:07:35 +0000

Hi Ian,

I see your point, but I think there is a value in calling out explicitly the aggregation case because injecting individual routes may be suboptimal and some mechanisms to aggregate routes is thus needed.

What about “The mechanisms for a relay to inject routes (including aggregated ones) …”?

Cheers,
Med

Envoyé : vendredi 10 janvier 2020 15:22

Hi Med,

old:

new:

Thanks,
Ian

On 9. Jan 2020, at 11:41, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ian,

OLD:

NEW:

Thank you.

Cheers,

Med

De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Envoyé : jeudi 9 janvier 2020 10:52
À : BOUCADAIR Mohamed TGI/OLN
Cc : Bernie Volz (volz); [email-masked]<mailto:[email-masked]>
Objet : Re: [dhcwg] Adoption Call for draft-fkhp-dhc-dhcpv6-pd-relay-requirements - Respond by Jan 14, 2020

Hi Med,

Thanks,
Ian

Hi Bernie, all,

I support.

Cheers,
Med

Hello:

And, Happy New Year!

  *   Tomek & Bernie

---

From: <[email-masked]>
Date: Fri, 10 Jan 2020 15:55:17 +0000

Hi Med,

OK, let’s go with that.

Cheers,
Ian

From: dhcwg <[email-masked]> On Behalf Of [email-masked]
Sent: Friday, January 10, 2020 4:08 PM
To: [email-masked]
Cc: [email-masked]; Bernie Volz (volz) <[email-masked]>
Subject: Re: [dhcwg] Adoption Call for draft-fkhp-dhc-dhcpv6-pd-relay-requirements - Respond by Jan 14, 2020

Hi Ian,

Cheers,
Med

Hi Med,

old:

new:

Thanks,
Ian

Hi Ian,

OLD:

NEW:

Thank you.

Cheers,

Med

Hi Med,

Thanks,
Ian

Hi Bernie, all,

I support.

Cheers,
Med

Hello:

And, Happy New Year!

  *   Tomek & Bernie

---

From: Erik Kline <[email-masked]>
Date: Tue, 14 Jan 2020 17:03:55 -0800

I support adoption.

I am confused about some things though.  Specifically related to 3.4 and
4.1 G-5.  Should the delegating relay support a client moving from one
interface to another (presumably this just means honoring a request with
previously allocated IA_PDs in it, updating the routes accordingly)?  I
guess, what's the guidance for supporting a duplicate versus detecting a
migration?

[nits]
S2.1: s/should be understand/should be understood/

S2.1: s/specificcally/specifically/

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 24 Jan 2020 14:57:39 +0000

Hi:

This document has been adopted by the DHC WG.

The authors are requested to publish the draft-ietf-dhc-*-00 version.

Thanks.

  *   Tomek & Bernie

Hello:

And, Happy New Year!

  *   Tomek & Bernie