Subject: [dhcwg] Comments on some aspects on draft-yeh-dhc-dhcpv6-prefix-pool-opt-08

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 07 Sep 2012 14:44:49 +0200

DHC WG,

Comments on some aspects on this draft.

> When a routing protocol is enabled on the network-facing interface
> of the PE router, all the routes directing to the customer networks
> are advertised in the ISP network.  This will make the number of
> route entries in the routing table on the ISP router be unacceptable
> large. Hence, it is desirable to aggregate the routes directing to
> the customer networks on the PE router.

In general, I can visualize the problem, and I believe more things about it:

- it could be better described with an example and a topology which
   pictures many routes (like in 1, 2 ... n).  This is just a comment,
   not necessarily should be done.  (Graphs are already drawn which is
   good already in the draft.)

- but if we do and draw pictures we may realize that the problem is
   exhibited in cases where the default route may not be given enough
   importance.

For example, if the Relay has a single default route and is statically
in charge of a short prefix (many subprefixes) then there is no problem
of Relay advertising too many routes - only one.  And of course, if it
is not possible to have the Relay in charge of a single short prefix
then ultimately one ends up with many specific routes advertised to the
network and with the need to reduce them.

One alternative solution may be to have a mechanism by which the Relay
itself first executes Requesting Router (before being a Relay) to obtain
that short prefix, at which point we no longer talk 'snooping'.  This
could be the Prefix Pool Option without snooping.

Alex

---

From: Ole Trøan <[email-masked]>
Date: Mon, 10 Sep 2012 11:02:59 +0200

Alex,

[...]

> could be the Prefix Pool Option without snooping.

I'm more in favour of that too. the Relay acts as a DHCP client and requests a 
"static route / prefix pool / aggregate route" whatever we choose to call that option.

you would still need snooping to populate the RIB in the Relay itself though.

cheers,
Ole

---

From: "JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK)" <[email-masked]>
Date: Mon, 10 Sep 2012 15:03:06 +0530

Hi,

I am in favor of this approach as well.

--
Shree

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of Ole
>Trøan
>Sent: Monday, September 10, 2012 2:33 PM
>To: Alexandru Petrescu
>Cc: [email-masked]
>Subject: Re: [dhcwg] Comments on some aspects on draft-yeh-dhc-dhcpv6-prefix-
>pool-opt-08
>
>Alex,
>
>[...]
>
>> itself first executes Requesting Router (before being a Relay) to
>> obtain that short prefix, at which point we no longer talk 'snooping'.
>> This could be the Prefix Pool Option without snooping.
>

---

From: Leaf yeh <[email-masked]>
Date: Mon, 10 Sep 2012 09:53:36 +0000

Alex - > One alternative solution may be to have a mechanism by which the Relay 
> This could be the Prefix Pool Option without snooping.
Ole - I'm more in favour of that too. the Relay acts as a DHCP client and requests a "static route / prefix pool / aggregate route" whatever we choose to call that option.

The above sounds the mechanism introduced in 'draft-ietf-dhc-dhcpv6-tunnel-01' (https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-tunnel/ ), to introduce DHCPv6 client on the PE router particularly for the aggregation route (or prefix pool). But draft (OPTION_PREFIX_POOL) only use the similar existing tech, bulk leasequery, for the case of power cycle occurred on the relay.

Draft (OPTION_PREFIX_POOL) proposes the solution called 'Piggyback', which has the benefit to make it easier to sync the 'status' of prefix pools (or aggregation routes) on the relay with that indicated on the server.

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ole Tr?an
Sent: Monday, September 10, 2012 5:03 PM
To: Alexandru Petrescu
Cc: [email-masked]
Subject: Re: [dhcwg] Comments on some aspects on draft-yeh-dhc-dhcpv6-prefix-pool-opt-08

Alex,

[...]

> This could be the Prefix Pool Option without snooping.

I'm more in favour of that too. the Relay acts as a DHCP client and requests a "static route / prefix pool / aggregate route" whatever we choose to call that option.

cheers,
Ole