Re: [homenet] Updates to Homenet Architecture Principles doc

[Markus Stenberg <[e-mail]>]

On 12.6.2014, at 16.04, Ted Lemon <[e-mail]> wrote:
> On Jun 12, 2014, at 8:45 AM, Markus Stenberg <[e-mail]> wrote:
>> This sounds _way_ too specific to me. Like a lot of the document by now.
>> Specifying routing protocol path cost function in _architecture_ document?
>> Ha ha.
> If you are just going to laugh, then I'm not going to approve the document, and you should definitely ask nomcom to replace me if you feel that is the right thing to do.   I would prefer that we have a discussion about what the text should say, but that’s entirely up to you.

Well, I’m just concerned that discussion led to the text as agreed consensus. (At least judging by Ray’s account.)

As I’m not privy to that, I’m not assigning blame, but I find the outcome just .. funny.

So why not laugh? It’s better than crying. Supposedly extends your lifespan too.

> What I would like to see as feedback is a clear statement of what the routing paradigm is, not agreement that the text as currently written is correct.   This statement should be inclusive of whatever routing protocols the working group is inclined to consider, but it should be selective enough that it says what the working group actually wants, and doesn't cover all possible routing protocols.   I very much do not want the working group to fight out the routing protocol question right now, but I think it’s possible to get this text to a point where it satisfies the DISCUSS it was supposed to satisfy.

Why do we need to do that? Specifying it in extreme detail effectively favors some protocols, either intentionally or not.

Even before this latest update, I found the routing way overspecified and possibly in wrong direction; for example, I am currently using mostly Babel as a routing protocol for my homenet-related things, and it’s not link-state.

So, as a text diff..

-Using information
-distributed through the routing protocol, each node in the homenet
-should be able to build a graph of the topology of the whole homenet
-including attributes such as links, nodes, connectivity, and (if
-supported by the protocol in use) link metrics.

.. and so on.

and link metrics show up more in the text too. 99% of typical homes care about one _bit_ of link information - whether it’s wired or not, and if wired, prefer that.

I still wouldn’t want to specify that in an arch draft.

Then again, perhaps we should rename this draft _the solution specification_ draft, because there’s lots of places that lean that way already.

Source address-aware RIP would probably be sufficient for a homenet use case if PA/other stuff is done elsewhere (HNCP, hierarchical PD, CNP, you name it).

Looking at the homenet routing as blank slate (ignoring the arch draft), here’s what I think matters:

- source specific (=> can deal with multiple ISPs)
- not tied to L2
- can do unicast IPv[46] routes  (multicast would be nice too but typically separate protocol)

what’s helpful:

- fast initial/incremential convergence of state (not in arch draft currently)
- some minimalist metrics (not mandatory either)

If we compare this list to what’s in arch draft, we’re already very diverged. I’m not trying to fight the windmill and get rid of cruft in arch draft, but I am not happy about AD comments (/discussions somewhere?) adding even more of it.

I provided my feedback. Care to enlighten us why your stance is that we _do_ need insanely verbose specification of routing paradigm?

Cheers,

-Markus