Subject: Re: [homenet] Medius: additional DHCPv6 (PD) options needed?

From: Ted Lemon <[email-masked]>
Date: Sat, 3 Aug 2013 21:49:34 +0200

On Jul 31, 2013, at 3:57 PM, Michael Richardson <[email-masked]> wrote:
> If time is of such an essence here,  then it's more important that the option
> be emitted in Medius capable CER devices, and that it declare "Medius"
> or ">Medius" clearly, than that we know what exactly an Interior Router needs to
> *do* when it sees that.

I bet if you put your mind to it you could have a spec for this option through the process in six weeks or less.   I will do my part to advance it quickly once it reaches the IESG.  Why not start now instead of prognosticating about how long it will take?  ;)

---

From: Michael Richardson <[email-masked]>
Date: Sat, 03 Aug 2013 16:31:17 -0400

> I bet if you put your mind to it you could have a spec for this option
    > through the process in six weeks or less.   I will do my part to
    > advance it quickly once it reaches the IESG.  Why not start now instead
    > of prognosticating about how long it will take?  ;)

Chris, if you want me to, I'll start the draft.

---

From: Chris Grundemann <[email-masked]>
Date: Mon, 5 Aug 2013 13:43:08 +0000

Michael, there is already a draft in place (CER_ID)[1], and it is already
referenced in the HIPnet draft[2]. If this is the needed direction, I see
no reason to start over - do you?

Cheers,
~Chris

[1] - https://tools.ietf.org/html/draft-donley-dhc-cer-id-option-01
[2] - https://tools.ietf.org/html/draft-grundemann-hipnet-00#section-4.1

On 3/Aug/13 22:31 GMT+02:00, "Michael Richardson" <[email-masked]> wrote:

>    >> If time is of such an essence here,  then it's more important that
>the
>    >> option

---

From: Ted Lemon <[email-masked]>
Date: Mon, 5 Aug 2013 10:37:30 -0400

I think the configuration model here needs more thought.   The hipnet document talks about heuristics for figuring out that it's at the edge, but e.g. the /48 heuristic seems like it won't work.

What I would like to see is something like Fred Baker's draft (draft-baker-homenet-prefix-assignment-01), for any router that could be a CER.   Fred's document has a few omissions that would need to be dealt with:

(1) It doesn't describe how DHCP relay works.   A non-CER relays to the CER, the IP address of which it got in the CER option.   If the non-CER knows of more than one CER, it relays to all CERs.
(2) A router can be both CER and non-CER, in a multihoming situation, in which case it both answers and relays all DHCP messages.   This is slightly weird, but the DHCP protocol allows multiple servers to respond, so it should be okay.
(3) routers that get multiple offers of different prefixes have to configure both prefixes, not just one, so that multihome prefixes propagate into the network.   This is not what RFC3315 and RFC 3633 advise; doing what they advise will result in a network that is multihomed at the edge, but not in the center.
(4) routers that relay DHCP messages sniff for routes on the replies, and use them to populate their routing tables.
(5) Fred's draft suggests that two routers advertising prefixes on the same link is an error, and that one of the routers needs to let the other win, but this misses the dual-home dual-CER case, where the prefixes being advertised are from different providers.   So the draft needs to be narrowed to the case where both prefixes come from the same provider, which probably means that prefixes need to be labeled as to the provider with a new DHCP option.
(6) I'm probably missing some routing subtlety here.

This sounds complicated, but I think it's simpler than it sounds.   However, I think the current state of the CER and hipnet specs is _too_ simple, and will not actually work.   You have to solve the problem that Fred's draft solves, and Fred's draft is actually pretty close.

---

From: "Townsley.net" <[email-masked]>
Date: Mon, 5 Aug 2013 12:46:58 -0500

Chris, what must be done to ensure that at least the cable labs eRouters with DHCPv6 PD have the CER ID built in from day one?  

- Mark

(Thumbtyped)

On 5 août 2013, at 08:43, Chris Grundemann <[email-masked]> wrote:

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

---

From: Ole Troan <[email-masked]>
Date: Tue, 6 Aug 2013 12:47:59 +0200

Ted, et al,

> This sounds complicated, but I think it's simpler than it sounds.   However, I think the current state of the CER and hipnet specs is _too_ simple, and will not actually work.   You have to solve t…

please read http://datatracker.ietf.org/doc/draft-arkko-homenet-prefix-assignment/
before we start building spanning trees with DHCP.

I'm in favour of hipnet as an intermediate step for a restricted topology. e.g. two routers in series,
with only one CER (that can potentially be multi-homed).

I'm not in favour of using hipnet for the general problem of an arbitrary topology.

border discovery is tricky. you can define some heuristics, but without some sort of security protocol it is going to be trial and error. in the eRouter case it is trivial of course.

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Tue, 6 Aug 2013 08:36:32 -0400

> before we start building spanning trees with DHCP.

Ole, this comment is not constructive.   It's really frustrating to make a technical suggestion that I think will improve the implementation, and get back a response like this.   I've read Jari's draft, and I think it's potentially a good idea.   However, the hipnet guys seem to feel that it's not mature enough yet, so they want to go forward with an intermediate solution.

I would like that intermediate solution to not be obviously broken, so I'm suggesting that what is defined in the hipnet document be fleshed out to the point where someone could actually implement it.   That's why I made the suggestion I made.

If you think it was a bad suggestion, either because something bad will happen if it is implemented, or because there is a better alternative, then make your case.   Don't just make vague references to spanning trees and claim that that's what I'm proposing, when it is not.

If your point is that a network built the way I described will be more brittle than one done with OSPF, I think you are right, and I would prefer the OSPF model, when and if it is advanced as a standard.   But it's not baked yet, and the hipnet guys want something now.   We can do this now, with very little additional glue, and it will be better than what we have, and will not badly break a homenet once you guys have finished defining what a homenet is.

To be clear, a remark like this is absolutely useless:

> I'm in favour of hipnet as an intermediate step for a restricted topology. e.g. two routers in series, with only one CER (that can potentially be multi-homed).

You aren't making a technical argument here.   Maybe there's a technical argument for the conclusion you are stating, but you have not expressed it.   Instead, you appear to be marking territory: "I can accept hipnet as long as it's obviously limited and will break in obvious ways when customers plug hipnet routers together in any topology other than this."

So if you think there's a good reason for doing things the way you have said, _and_ you can think of a way to specify this so that it breaks predictably, _and_ the hipnet guys agree to do what you have said, then we can talk.   Otherwise, I would like it if we could make the hipnet router spec tight enough to avoid blatant brokenness.

The cascading centralized prefix delegation model definitely has problems.   There will be cases where the end user has to power cycle all the routers to win.   I don't like this.   I think it's a sufficient sales pitch for homenet that we don't need to worry that a hipnet router will be "good enough" and prevent further work on homenet.   I just want old hipnet routers to not break homenets, and this allows that to happen.

As an example of what I am talking about, suppose you have a homenet router on the edge, then a non-relaying hipnet router, then a homenet router.   How does the leaf homenet router discover the existence of the edge homenet router?   I think it doesn't.   It's an island.   With a relaying hipnet router, the leaf router can discover the edge router with a DHCP option and use that to bootstrap OSPF around the hipnet router.   To me this capability seems like a win, but you are arguing that it is a lose.   Why?

---

From: Ole Troan <[email-masked]>
Date: Tue, 6 Aug 2013 15:43:04 +0200

Ted,

> If you think it was a bad suggestion, either because something bad will happen if it is implemented, or because there is a better alternative, then make your case.   Don't just make vague reference…

how do you then propose to deal with a topology with loops?
http://tools.ietf.org/html/draft-grundemann-homenet-hipnet-01 seems to be building a spanning tree.

a spanning tree will work, it will just not use the links in network effectively. depending on topology.
I'd also be interested to see what convergence times you are seeing in hipnet.

cheers,
Ole

---

From: Chris Grundemann <[email-masked]>
Date: Tue, 6 Aug 2013 16:30:13 +0000

On 5/Aug/13 11:46 MDT, "Townsley.net" <[email-masked]> wrote:

>
>Chris, what must be done to ensure that at least the cable labs eRouters
>with DHCPv6 PD have the CER ID built in from day one?

Well, I think we first need to review the current CER draft and ensure
that it meets all of our needs. Assuming that it does we would want to
advance the CER_ID draft in DHC and also make the option mandatory for
eRouters (this can be done in the CableLabs specification).

~Chris

---

From: Michael Richardson <[email-masked]>
Date: Tue, 06 Aug 2013 12:47:33 -0400

> [1] - https://tools.ietf.org/html/draft-donley-dhc-cer-id-option-01

Thanks. I was unaware of that, as I guess I didn't follow the references.

I want to suggest that in addition to the CER_ID, that the CER device
announce a revision, e.g. Medius, that it is at.

I'd like the non-CER routers to also emit this ID, stating that they are not
the CER, and giving their revision.  Ideally, they would also signal upwards
as well.

--
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Ted Lemon <[email-masked]>
Date: Tue, 6 Aug 2013 13:35:48 -0400

> the CER, and giving their revision.  Ideally, they would also signal upwards

Michael, did you read my reply about this?   Your response to Chris suggests that you didn't grok it, if so.