Subject: [homenet] Updates to Homenet Architecture Principles doc

From: Ray Bellis <[email-masked]>
Date: Thu, 12 Jun 2014 12:20:16 +0000

Dear Working Group,

You may have noticed multiple revisions of draft-ietf-homenet-arch posted recently. After many iterations and a ton of work for our Editor In Chief, Tim Chown, all IESG “DISCUSS” positions have been resolved to either “Yes” or “No Objection”, with the exception of one “Abstain” from one of our Routing Area ADs who had requested that the following text be added to section 3.5:

“Routing within the homenet will determine the least cost path across
 the homenet towards the destination address given the source address.
 The path cost will be computed as a linear sum of the metric assigned
 to each link.  The metric may be configured or automatically derived
 per link based on consideration of factors such as worst-case queue
 depth and router processing capabilities.”

The Chairs felt that the first half of this text was unnecessarily prescriptive for this document and did not reflect something the WG had achieved consensus on at this time.  We proposed a compromise that incorporated the latter non-normative half of this text in an earlier paragraph.  On the basis that we understood that this compromise had been accepted by the respective AD, the -14 revision was posted.

After -14 was posted and the AD’s position changed to "No Objection", we noticed that the above paragraph had inadvertently been included, in full, in addition to the latter half included as part of the proposed compromise! At the Chairs’ request, Tim removed the above paragraph in -15, which caused the AD to object as it appeared to him that his text was being removed after the fact.

Later today, Tim will be posting a -16 revision of the document that reinstates the above paragraph, in full, and removes the “compromise” text. On the basis that the new text is a potentially substantive change, our AD has requested that we put the document through one more Working Group Last Call to determine WG consensus on that issue.

In addition, one small change was introduced in the -15 revision based on WG feedback where a reference to Source Specific Multicast [RFC 4607] was introduced, but had not been called out explicitly in London or before. That change is as follows:

Old:
   It is desirable that, subject to the capacities of devices on certain
   media types, multicast routing is supported across the homenet.

New:
   It is desirable that, subject to the capacities of devices on certain
   media types, multicast routing is supported across the homenet,
   including source-specific multicast (SSM) [RFC4607].

The WGLC will commence immediately after the -16 is posted, and will last for two weeks.

We very much want your feedback here, but are not aiming to revisit the document in its entirety. As such, we would like to limit the scope of the WGLC to just the text quoted in this email.

Many thanks,

Ray and Mark

---

From: Markus Stenberg <[email-masked]>
Date: Thu, 12 Jun 2014 15:45:02 +0300

>  depth and router processing capabilities.”

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.

I would just use -15 or replace AD. Are either of those two options?

Cheers,

-Markus

---

From: Ray Bellis <[email-masked]>
Date: Thu, 12 Jun 2014 12:56:05 +0000

[let's try that again, hopefully without b0rked line wrapping]

Dear Working Group,

Old:
 It is desirable that, subject to the capacities of devices on certain   media types, multicast routing is supported across the homenet.

New:

Many thanks,

Ray and Mark

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Jun 2014 09:04:05 -0400

> Specifying routing protocol path cost function in _architecture_ document?

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.

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.

---

From: Markus Stenberg <[email-masked]>
Date: Thu, 12 Jun 2014 16:33:28 +0300

On 12.6.2014, at 16.04, Ted Lemon <[email-masked]> wrote:
> 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

---

From: Mark Townsley <[email-masked]>
Date: Thu, 12 Jun 2014 15:37:44 +0200

To be clear, it is the Routing AD who prosed the text, not Ted (Internet AD). Ted asked that it be run by the WG as he, rightly, considered it substantive and wanted the WG's opinion of it.

- Mark

On Jun 12, 2014, at 3:33 PM, Markus Stenberg <[email-masked]> wrote:

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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Jun 2014 09:59:40 -0400

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

Both of the routing ADs complained about the text in this section.   I do not actually clearly understand their complaints, but after discussing it with Alia (who did not raise a DISCUSS, but was happy to talk with me about it) and with Adrian (who really feels quite discouraged about the whole conversation), the understanding I came away with was that they felt that the document as written was quite open-ended and left available the possibility of doing some things that are Not A Good Idea.

As a routing non-expert, I have no way to evaluate this.   I don't know what the working group wants, and I don't know why the routing ADs are concerned about it.   So when I have a routing AD spend months trying to get the text right, and then get upset when it's changed and move to abstain on the document, my only recourse is to either put my fingers in my ears and hum a tune whilst pretending not to hear, or to ask the working group for help.

I have a lot of respect for the routing ADs, and don't want to just ignore them, so I chose the latter.   There's a lot of knowledge about routing in the working group, and my hope is that in watching you discuss this question, I can come to a better understanding of what to do.   I realize this is a pain in the neck, and I apologize for it--I wish I had a better understanding of the issues so that I could just propose a solution.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 12 Jun 2014 16:34:36 +0200

>> This sounds _way_ too specific to me.

> If you are just going to laugh,

Laugh with us, Ted -- it /is/ rather funny.

(I especially liked the "linear sum" touch.  What's a non-linear sum?)

> This statement should be inclusive of whatever routing protocols the
> working group is inclined to consider,

I'll do my best.  There are at least four issues at hand.

1. Not all routing protocols choose the lowest-metric route -- some
   protocols include in their route selection criteria data that are not
   encoded in the metric.  Examples are BGP flap avoidance, or the
   hysteresis algorithm used by Babel.  One might argue that this is also
   the case of multi-area OSPF (although it is not usually expressed in
   that manner).

   For BGP and OSPF, you probably know more about the subject than I do.
   For Babel, see Section 3.6 of RFC 6126 and Section III.E of

       http://arxiv.org/pdf/1403.3488

   (As far as I know, there is currently no theoretical understanding of
   this kind of techniques.  As far as I've been able to work out, neither
   Sobrinho's routing algebras nor Griffin's semigroups are able to account
   for them.)

   The Arch document MUST NOT specify what kind of data the route
   selection algorithm is allowed to take as input.

2. Many protocols don't compute metrics as a "linear sum" of the link
   costs; as a matter of fact, in many protocols the metric is not a mere
   integer, but an element of a richer algebra.  This is obviously the
   case of BGP (see Griffin and Sobrinho, SIGCOMM 2005), but also of
   Babel, which, when run over a radio link layer with interference
   avoidance enabled, carries a pair of an integer and (roughly speaking)
   a set of interfering radio frequencies.

   The Arch document MUST NOT specify the structure of the metric algebra.
   It SHOULD NOT even imply that the metric being used is modelisable as
   a routing algebra.

3. Finding a satisfactory and implementable metric for radio link layers
   is very much an open research problem.  Many routing protocols just
   punt and expect the link layer to work like an Ethernet, which gets you
   horrible performance in rich layer 3 topologies.  Some mesh routing
   protocols estimate unicast link rate and multicast packet loss and
   combine the two using magic, which tends to choose unusable routes in
   some cases.  There has been a lot of noise around cross-layer
   techniques for the last 10 years or so, but I don't know of
   a production-quality implementation.  (Yeah, I know, I should stop
   complaining and try my hand at it.)

   Please do not underestimate the importance of this point for Homenet --
   how many wired and how many wireless links do you expect there to be in
   a typical home ten years from now?

   The Arch document MUST NOT specify what kind of data the metric
   computation algorithm is allowed to take as input.

4. There exist routing protocols that don't use the notion of a metric at
   all.  We metric-based people like to jestingly call them "longest-path
   routing" algorithms, however we're still keeping an eye open to see if
   anything useful comes out from that line of research.

   The Arch document SHOULD NOT even imply that a metric is being used.

Hope this helps,

-- Juliusz

---

From: "Townsley.net" <[email-masked]>
Date: Thu, 12 Jun 2014 16:54:23 +0200

I think for an arch document, we should talk generally about how a routing protocol could plug into the rest of the system, but stop short of details within the routing protocol itself. If routing experts are concerned the working group is going to go into bad territory with cost metrics, path calculation, etc.  toying around with text here isn't the way to go about solving that. This is not a WG charter document, it's not even normative. 

Bottom line: I would much rather have routing experts on list rather than writing our documents for us one discuss at a time. 

- Mark

(Thumbtyped)

> On Jun 12, 2014, at 3:59 PM, Ted Lemon <[email-masked]> wrote:
>

---

From: Acee Lindem <[email-masked]>
Date: Thu, 12 Jun 2014 14:55:17 +0000

I was involved in this discussion and the statement was merely an attempt
to capture the fact that the existing unicast IGP routing protocols would
meet the homenet requirements with the addition of routing based on
source-address. For example, while BGP would not be precluded, BGP¹s rich
routing policy is not viewed as being required in the homenet.
Thanks,
Acee

---

From: "Townsley.net" <[email-masked]>
Date: Thu, 12 Jun 2014 17:08:14 +0200

Thank you, Acee. 

The very first sentence of section 3.5 contains a very strong statement about using existing protocols. I don't see how expanding this section with detailed routing protocol requirements du jour helps to underscore that point. So, please, let's stop. 

- Mark

(Thumbtyped)

> On Jun 12, 2014, at 4:55 PM, Acee Lindem <[email-masked]> wrote:
>

---

From: Michael Thomas <[email-masked]>
Date: Thu, 12 Jun 2014 08:12:53 -0700

> Bottom line: I would much rather have routing experts on list rather than writing our documents for us one discuss at a time.

That was my problem with other parts of the document: it was *way* too 
prescriptive about particular
technologies. That is wrong for the kind of document. That should be 
hashed out with actual proposed
answers to the architecture document.

Mike

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Jun 2014 11:27:28 -0400

On Jun 12, 2014, at 11:12 AM, Michael Thomas <[email-masked]> wrote:
> That was my problem with other parts of the document: it was *way* too prescriptive about particular
> technologies. That is wrong for the kind of document. That should be hashed out with actual proposed

The architecture document was supposed to say what we were trying to build.   I think it does a pretty good job of that.

"Existing routing protocols" covers a lot of protocols that I think we clearly don't want to use.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 12 Jun 2014 08:32:07 -0700

> "Existing routing protocols" covers a lot of protocols that I think we clearly don't want to use.

If they want to get involved in the fight about the thread count of the 
toilet bolts, there's
a time and place for that.

Mike

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 12 Jun 2014 17:22:49 +0200

> I was involved in this discussion

I'm genuinely sorry to hear that, Acee.

> the statement was merely an attempt to capture the fact that the
> existing unicast IGP routing protocols would meet the homenet
> requirements [...] while BGP would not be precluded, BGP's rich routing
> policy is not viewed as being required in the homenet.

Was it meant to preclude or discourage the following:

  * route selection involving hysteresis;
  * radio interference avoidance;
  * cross-layer metric computation techniques?

If it wasn't, then somebody didn't do their homework.  If it was, then
somebody needs to drop by on this list to explain their position to us.

-- Juliusz

---

From: Acee Lindem <[email-masked]>
Date: Thu, 12 Jun 2014 16:34:10 +0000

-----Original Message-----
From: Juliusz Chroboczek <[email-masked]>
Date: Thursday, June 12, 2014 at 8:22 AM
To: Ericsson <[email-masked]>
Cc: "[email-masked] Group" <[email-masked]>
Subject: Re: [homenet] Updates to Homenet Architecture Principles doc

>I'm genuinely sorry to hear that, Acee.

Comments, debate, and discussion are a normal part of the IETF process.

>somebody needs to drop by on this list to explain their position to us.

As I stated above, it was not meant to preclude additional capabilities
and I agree with the chairs that the document is fine without it.

Thanks,
Acee

---

From: Ray Hunter <[email-masked]>
Date: Thu, 12 Jun 2014 23:20:46 +0200

Here's my 2c worth on Section 3.5

I'm on record as preferring a "common Homenet routing protocol" without 
having any fingers in any particular choice.

I believe there is rough consensus around the choice of 0 or 1 routing 
protocol.

Going through Section 3.5 line by line.

> Routing functionality
>
>    Routing functionality is required when there are multiple routers
>    deployed within the internal home network.  This functionality could
>    be as simple as the current 'default route is up' model of IPv4 NAT,
>    or, more likely, it would involve running an appropriate routing
>    protocol.  Regardless of the solution method, the functionality
>    discussed below should be met.
Fine by me.
>
>    The homenet unicast routing protocol should be based on a previously
>    deployed protocol that has been shown to be reliable and robust, and
>    that allows lightweight implementations, but that does not preclude
>    the selection of a newer protocol for which a high quality open
>    source implementation becomes available.  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.
>
>
Fine by me. Apart from the use of the word "graph" which could be 
overloaded or suggest a preference for link state protocols. 
s/graph/consistent view/ ?
>
>
>    The routing protocol should support the generic use of multiple
>    customer Internet connections, and the concurrent use of multiple
>    delegated prefixes.  A routing protocol that can make routing
>    decisions based on source and destination addresses is thus
>    desirable, to avoid upstream ISP BCP 38 ingress filtering problems.
>    Multihoming support should also include load-balancing to multiple
>    providers, and failover from a primary to a backup link when
>    available.  The protocol however should not require upstream ISP
>    connectivity to be established to continue routing within the
>    homenet.
Fine be me.
>
>    Routing within the homenet will determine the least cost path across
Too explicit IMHO. What is wrong with s/determine the least cost path 
across the homenet towards the destination address given the source 
address /maintain a loop free forwarding path between any given source 
address and destination pair/
>    to each link.
Way too explicit IMHO. EIGRP is a perfectly good routing protocol that 
would be excluded by this requirement as the routing metric is a non 
linear sum of different individual link metrics, including minimum path 
bandwidth.
Not that I'm urging use of EIGRP, but I don't see why it should be 
excluded on these grounds alone.

> The metric may be configured or automatically derived
>    depth and router processing capabilities.
>
It's a may so fine by me.
>    Multiple types of physical interfaces must be accounted for in the
>    homenet routed topology. 
Fine be me.
> Technologies such as Ethernet, WiFi,
>    Multimedia over Coax Alliance (MoCA), etc. must be capable of
>    coexisting in the same environment and should be treated as part of
>    any routed deployment.
Fine be me.
> The inclusion of physical layer
>    characteristics including bandwidth, loss, and latency in path
>    computation should be considered for optimising communication in the
>    homenet.
>
Fine be me.
>    The routing environment should be self-configuring, as discussed
>    previously.  Minimising convergence time should be a goal in any
>    routed environment,
Fine by me.
> but as a guideline a maximum convergence time at
>    most 30 seconds should be the target (this target is somewhat
>    arbitrary, and was chosen based on how long a typical home user might
>    wait before attempting another reset; ideally the routers might have
>    some status light indicating they are converging, similar to an ADSL
>    router light indicating it is establishing a connection to its ISP).
>
Way too explicit IMHO. I don't see why a figure of 30 seconds for 
convergence time is even given. I'm not happy to wait 30 seconds for 
video distribution over Homenet.
Surely acceptable convergence time is a function of user expectations 
relative to the nature of the traffic being carried by the Homenet, 
combined with the available buffering before the user becomes aware of 
any topology change.
>    Homenets may use a variety of underlying link layer technologies, and
>    may therefore benefit from being able to use link metrics if
>    available.  It may be beneficial for traffic to use multiple paths to
>    a given destination within the homenet where available, rather than a
>    single best path.
>
Fine be me. But is totally inconsistent with the sentence above to 
always choose the shortest path. The "shortest path" may not be "the 
best" for all traffic. Again look at the concept behind EIGRP metrics, 
where high bandwidth traffic might be routed over a different route to 
latency sensitive traffic.
>    At most one routing protocol should be in use at a given time in a
>    given homenet.
Definitely agree.
> In some simple topologies, no routing protocol may be
>    needed.
Consistent with the 0 or 1 consensus.
>   If more than one routing protocol is supported by routers in
>    a given homenet, then a mechanism is required to ensure that all
>    routers in that homenet use the same protocol.
>
>
Fine be me. I'd rather just chose one, but this appears to me like 
trying to get a group consisting of more than one economist to agree on 
anything.
>
>
>    An appropriate mechanism is required to discover which router(s) in
>    the homenet are providing the CER function.  Borders may include but
>    are not limited to the interface to the upstream ISP, a gateway
>    device to a separate home network such as a LLN network, or a gateway
>    to a guest or private corporate extension network.  In some cases
>    there may be no border present, which may for example occur before an
>    upstream connection has been established.  The border discovery
>    functionality may be integrated into the routing protocol itself, but
>    may also be imported via a separate discovery mechanism.
>
Fine be me.
>    Ideally, LLN or other logically separate networks should be able
>    exchange routes such that IP traffic may be forwarded among the
>    networks via gateway routers which interoperate with both the homenet
>    and the LLN.  Current home deployments use largely different
>    mechanisms in sensor and basic Internet connectivity networks.  IPv6
>    virtual machine (VM) solutions may also add additional routing
>    requirements.
>
Fine be me. It might be worth adding that we do not expect LLN network 
to act as transit networks between more traditional areas of the Homenet 
if you are going to revise the text anyway.

Ray Bellis wrote:
>
> Dear Working Group,
>
> You may have noticed multiple revisions of draft-ietf-homenet-arch 
> posted recently. After many iterations and a ton of work for our 
> Editor In Chief, Tim Chown, all IESG “DISCUSS” positions have been 
> resolved to either “Yes” or “No Objection”, with the exception of one 
> “Abstain” from one of our Routing Area ADs who had requested that the 
> following text be added to section 3.5:
>
> The Chairs felt that the first half of this text was unnecessarily 
> prescriptive for this document and did not reflect something the WG 
> had achieved consensus on at this time.  We proposed a compromise that 
> incorporated the latter non-normative half of this text in an earlier 
> paragraph.  On the basis that we understood that this compromise had 
> been accepted by the respective AD, the -14 revision was posted.
>
> After -14 was posted and the AD’s position changed to "No Objection", 
> we noticed that the above paragraph had inadvertently been included, 
> in full, in addition to the latter half included as part of the 
> proposed compromise! At the Chairs’ request, Tim removed the above 
> paragraph in -15, which caused the AD to object as it appeared to him 
> that his text was being removed after the fact.
>
> Later today, Tim will be posting a -16 revision of the document that 
> reinstates the above paragraph, in full, and removes the “compromise” 
> text. On the basis that the new text is a potentially substantive 
> change, our AD has requested that we put the document through one more 
> Working Group Last Call to determine WG consensus on that issue.
>
> In addition, one small change was introduced in the -15 revision based 
> on WG feedback where a reference to Source Specific Multicast [RFC 
> 4607] was introduced, but had not been called out explicitly in London 
> or before. That change is as follows:
>
> Old:
> We very much want your feedback here, but are not aiming to revisit 
> the document in its entirety. As such, we would like to limit the 
> scope of the WGLC to just the text quoted in this email.
>
> Many thanks,
>
> Ray and Mark
>

-- 
Regards,
RayH

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 12 Jun 2014 23:56:18 +0200

>> 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.

> overloaded or suggest a preference for link state
> protocols. s/graph/consistent view/ ?

I've already mentioned before that I'd just remove this whole sentence.
The goal of a routing protocol is to provide routes that are useful for
forwarding user traffic.  Whether it does that by building "a graph", "a
consistent view" or through haruspicy is pretty much an implementation
detail.

> Too explicit IMHO.

Multiple problems: inconsistent terminology (cost/metric), assumes the
existence of a metric, assumes that the protocol always chooses least
metric paths.  Just remove this sentence and be done with it.

> What is wrong with s/determine the least cost path across the homenet
> towards the destination address given the source address /maintain
> a loop free forwarding path between any given source address and
> destination pair/

Since we're being picky, this might be understood as excluding OSPF and
RIP, which may cause transient routing loops.  (Exceedingly short-lived in
any half-decent implementation of OSFP, granted.)

> Fine be me.

I think I may have already mentioned that I'm really not sure what this
sentence means.  Does it mean that the routing protocol must be able to
automatically distinguish between wired and wireless links?  Have different
route selection/metric computation strategies depending on the link layer?
On either count, only Babel qualifies, which I'm pretty sure is not what
is intended.

>> but as a guideline a maximum convergence time at most 30 seconds should
>> be the target

> convergence time is even given.

Heh.  If memory serves, RIP(ng) with triggered updates converges in
exactly 30 seconds, worst case.

(Snipped the part about border discovery, which I'm not competent to
comment on.)

> It might be worth adding that we do not expect LLN network to act as
> transit networks between more traditional areas of the Homenet if you
> are going to revise the text anyway.

Hmm... I'm pretty certain that people will use degenerate mesh networks
for transit once they realise it's a neat way to avoid laying wiring
between your home and the shack at the back of the garden.  Not sure about
LLNs, but I'd be nervous about including such language.

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Jun 2014 17:59:44 -0400

> I've already mentioned before that I'd just remove this whole sentence.

I agree.

But what is the routing supposed to accomplish?   Rapid convergence has been mentioned.   Load sharing?   Path redundancy?   I've heard some good suggestions about this section.   I wonder if convergence is possible for the text, as opposed to the routes... :)

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Jun 2014 18:04:46 -0400

> LLNs, but I'd be nervous about including such language.

The point of excluding LLNs is that the text purports to cover routers in the home, and LLNs are routers in the home.   To force LLN routers to provide all the functionality that we are proposing homenet routers will provide would be overly burdensome.   So LLNs are customers of whatever connectivity the homenet routers provide, and are not themselves homenet routers.   Does that make sense?   Does the text need to be clarified?

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 13 Jun 2014 00:19:48 +0200

> But what is the routing supposed to accomplish?

Good point.

The role of the routing protocol is to provide good enough end-to-end
connectivity often enough, where good/often enough is defined by user
expectations.

> Rapid convergence has been mentioned.

That's an implementation technique for achieving "often enough".

(OSPF converges extremely fast, but doesn't offer any guarantees about
what happens before convergence.  Babel converges slower, but is usually
able to route packets correctly before it converges: Babel uses
a different implementation technique to achieve "often enough".)

> Load sharing?

That's an implementation technique for achieving "good enough".

> Path redundancy?

That's an implementation technique for achieving "often enough".

I would suggest that the problems we've been having with the Arch document
are due to describing implementation techniques rather than the expected
result.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 13 Jun 2014 00:24:28 +0200

> So LLNs are customers of whatever connectivity the homenet routers
> provide, and are not themselves homenet routers.

Ah, I see.  This does not preclude an LLN router from implementing support
for Homenet, just makes it explicit that Homenet makes no such requirement
on LLN routers, and makes no concessions to using unmodified LLN routers
for transit.

Sure.

-- Juliusz

---

From: Michael Richardson <[email-masked]>
Date: Thu, 12 Jun 2014 18:44:19 -0400

Ray Bellis <[email-masked]> wrote:
    > You may have noticed multiple revisions of draft-ietf-homenet-arch posted
    > recently. After many iterations and a ton of work for our Editor In Chief, Tim
    > Chown, all IESG “DISCUSS” positions have been resolved to either “Yes” or “No
    > Objection”, with the exception of one “Abstain” from one of our Routing Area
    > ADs who had requested that the following text be added to section 3.5:

wow...

    > The Chairs felt that the first half of this text was unnecessarily prescriptive
    > for this document and did not reflect something the WG had achieved consensus

I agree.

    > In addition, one small change was introduced in the -15 revision based on WG
    > feedback where a reference to Source Specific Multicast [RFC 4607] was
    > introduced, but had not been called out explicitly in London or before. That
    > change is as follows:

    > We very much want your feedback here, but are not aiming to revisit the
    > document in its entirety. As such, we would like to limit the scope of the WGLC
    > to just the text quoted in this email.

I will attempt to read the diffs; but... It Just Doesn't Matter<tm>
better is the enemy of good enough, and it was good enough a year ago.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Thu, 12 Jun 2014 18:46:32 -0400

Ted Lemon <[email-masked]> wrote:
    > Both of the routing ADs complained about the text in this section.   I
    > do not actually clearly understand their complaints, but after
    > discussing it with Alia (who did not raise a DISCUSS, but was happy to
    > talk with me about it) and with Adrian (who really feels quite
    > discouraged about the whole conversation), the understanding I came
    > away with was that they felt that the document as written was quite
    > open-ended and left available the possibility of doing some things that
    > are Not A Good Idea.

Perhaps the actual fears could be made more explicit.

What is it that they are worried homenet might do?

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Jun 2014 21:34:28 -0400

> What is it that they are worried homenet might do?

Heck if I know.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 Jun 2014 16:29:46 +1200

Catching up on this thread (message times are based on NZST, UTC+12):

> This sounds _way_ too specific to me. 

I agree. Discussion of adding metrics together, although
it seems like Routing 101, just seems out of place.

On 13/06/2014 01:59, Ted Lemon wrote:

> the understanding I came away with was that they felt that the 
> document as written was quite open-ended and left available the 
> possibility of doing some things that are Not A Good Idea.

That would be a very valid criticism of WG charter goals. I am
not at all convinced that it's a valid criticism of an Informational
architecture document.

>    computation algorithm is allowed to take as input.

and, I think gave authoritative reasons for that assertion. Basically,
we shouldn't squeeze these very complex arguments into a general
document.

On 13/06/2014 02:55, Acee Lindem wrote:

> source-address.

That's a very fair statement, but that isn't at all what the new paragraph
says.

> we clearly don't want to use.

Yes, but that's very different from defining a rigid approach to metrics.

On 13/06/2014 09:20, Ray Hunter wrote:

> Apart from the use of the word "graph" which could be overloaded
> or suggest a preference for link state protocols.

Why? It's the term of art for both Bellman-Ford and Dijkstra algorithms.

   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 13 Jun 2014 15:26:26 +0900

>  depth and router processing capabilities.”

I agree that this text is needlessly - no, harfmully - prescriptive.
Premature overspecification is a design mistake of the worst kind, and
specifying the implementation details of the routing protocol in an
architecture document is silly. The IESG should know better.

I vote for removing the text and returning the draft to the IESG as WG
consensus, and if the IESG is not happy with that, then ask them to explain
clearly what it is that they are worried about.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 13 Jun 2014 07:40:02 -0400

On Jun 13, 2014, at 2:26 AM, Lorenzo Colitti <[email-masked]> wrote:
> I vote for removing the text and returning the draft to the IESG as WG consensus, and if the IESG is not happy with that, then ask them to explain clearly what it is that they are worried about.

People have already made suggestions for how to fix the text, which I would like implemented.   "The IESG" isn't asking for a change.   Adrian has been trying to negotiate a change for several months, and that resulted in some text that was reluctantly agreed to, but that the chairs felt didn't reflect the working group consensus, which appears to have been a correct evaluation.   The proposed text sucks, and is not what the IESG asked for.   It is just text that was agreed to because the AD who raised the DISCUSS was tired of arguing.   So blaming the IESG for the bad text and demanding that we do something to fix it isn't going to work.   We don't know what the working group wants the text to mean.   That's the problem.

I asked the working group to think about this a little harder because I need your help.   If your answer to this request for help is "no," then you are basically asking _me_ to take on this burden, and I can't.   So please reconsider.   As I said, we've already had some good suggestions.   There is no reason why this has to be hard.

---

From: Markus Stenberg <[email-masked]>
Date: Fri, 13 Jun 2014 15:56:12 +0300

> I asked the working group to think about this a little harder because I need your help.   If your answer to this request for help is "no," then you are basically asking _me_ to take on this burden,…

Problem for me is that I don’t understand what that added text _is_ about. What I _would_ like to do is remove even _more_ from that section, but for some reason that doesn’t sound like direction the routing ADs want to go.

Without understanding the reasoning behind why that text was added, it’s hard to figure how to fix it by anything else than using ‘cut’ tool in text editor.

As an example, http://tools.ietf.org/html/draft-ietf-homenet-hncp-00#section-8.1 has _two_ requirements for a routing protocol. Two. (One could argue for physical media independence, and even the second requirement of zeroconf in that text is arguable because if something else does the magic, you _can_ e.g. use OSPFv3 non-AC perfectly fine given someone provides it with unique IPv4 addreses to use as router IDs). So in IETF level jargon, only MUST is source specific routing support. There’s TON of SHOULDs but I’m not sure they belong in arch document.

That said, if we’re ever to converge on _one_ routing protocol, the set of requirements would be much stricter. But as that discussion hasn’t even started, I don’t see why we should stick _those_ requirements into RFC and freeze them long before discussion even starts.

Cheers,

-Markus

---

From: Ted Lemon <[email-masked]>
Date: Fri, 13 Jun 2014 09:20:26 -0400

> Problem for me is that I don’t understand what that added text _is_ about. What I _would_ like to do is remove even _more_ from that section, but for some reason that doesn’t sound like direction t…

That would be perfectly fine, as long as it says what's needed to be said.

The reasoning behind adding the text was that the ADs wanted to know what the routing paradigm for homenets is intended to be.   The text as presented to the IESG said some things that didn't make sense to them, and didn't make clear to them what was intended.   So taking out text could definitely improve the situation.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 13 Jun 2014 22:27:02 +0900

On Fri, Jun 13, 2014 at 8:40 PM, Ted Lemon <[email-masked]> wrote:

> We don't know what the working group wants the text to mean.   That's the
> problem.
>

No, the problem is that the working group doesn't know what is being asked
for.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 13 Jun 2014 09:38:13 -0400

On Jun 13, 2014, at 9:27 AM, Lorenzo Colitti <[email-masked]> wrote:
> No, the problem is that the working group doesn't know what is being asked for.

We could go around on this all week...

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 13 Jun 2014 22:43:34 +0900

> We could go around on this all week...

No, seriously. Assume I'm an idiot. Can you explain to me, in a couple of
sentences, what the working group is being asked to do here?

---

From: Ted Lemon <[email-masked]>
Date: Fri, 13 Jun 2014 09:46:04 -0400

On Jun 13, 2014, at 9:27 AM, Lorenzo Colitti <[email-masked]> wrote:
> No, the problem is that the working group doesn't know what is being asked for.\

Juliusz Chroboczek's messages yesterday at 22:19 UTC (assuming I did the timezone math right) did a pretty good job of capturing what I've been trying to communicate (thanks, Juliusz!).

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 13 Jun 2014 22:48:51 +0900

On Fri, Jun 13, 2014 at 10:46 PM, Ted Lemon <[email-masked]> wrote:

> Juliusz Chroboczek's messages yesterday at 22:19 UTC (assuming I did the
> timezone math right) did a pretty good job of capturing what I've been
> trying to communicate (thanks, Juliusz!).
>

Not to me they didn't. Seriously - if you understand what we're being asked
to do, and it's simple to explain, then it shouldn't take long for you to
type. Please?

---

From: Ted Lemon <[email-masked]>
Date: Fri, 13 Jun 2014 09:57:08 -0400

On Jun 13, 2014, at 9:48 AM, Lorenzo Colitti <[email-masked]> wrote:
> Not to me they didn't. Seriously - if you understand what we're being asked to do, and it's simple to explain, then it shouldn't take long for you to type. Please?

The working group would presumably like for there to be routing on the homenet.   What problems is the routing supposed to solve?   What things are priorities?   What things aren't priorities?

Clearly we need the routing solution to get packets to the right egress based on source address.   Do we also need it to do load sharing across parallel links, if such links exist?   Is it important to minimize the number of hops?   How long of a delay can there be between changes to the topology (e.g., a router being unplugged) and recovery, assuming that a flow was going through that router?   Is it okay to break a flow in that situation, or does it need to survive the transition?   Does the routing protocol need to be aware of the type of media a given link crosses, and does it need to prefer one media type over another where both are available?

I'm basically making questions up here.   The document should say what the working group wants routing to accomplish.   Right now it's a bit of a kitchen sink, with a lot of (IMHO) inappropriately prescriptive text.

---

From: Tim Chown <[email-masked]>
Date: Fri, 13 Jun 2014 15:09:28 +0100

On 13 Jun 2014, at 14:38, Ted Lemon <[email-masked]> wrote:

> We could go around on this all week…

I must say as the editor of the arch text I am also very confused. I don’t understand what is required in a replacement for the “contentious" paragraph (paragraph 4 of section 3.5), rather than simply removing the paragraph based on strong WG consensus.

In producing the -13, which was pushed out at IETF London, it seemed to me that there was clear WG consensus in that meeting that we should not constrain, witness the minutes at http://www.ietf.org/proceedings/89/minutes/minutes-89-homenet (under Slide 9). This view was reinfroced by comments elsewhere, and by the WG chairs. While it’s possible the WG view may have changed since London, it’s not a big surprise that it hasn’t. That message is why the one reference to link metrics earlier in section 3.5 is clearly qualified by “if supported by the protocol in use”.

As Ray points out, the paragraph added by the Routing ADs does make other some text in other paragraphs (which isn’t so prescriptive) seem out of place. My personal view, which happens to be in line with most (all?) who have commented in the WG is simply to strike the proposed prescriptive paragraph.  The question of course is whether/if Ted can square that off with our routing ADs who have genuine concern in raising the issue… it’s simply that the WG is coming back here and saying “it’s OK, thanks for raising the point, but we’re sure we want to do it this way”.

The -13 also includes other changes in response to discussion at London, as documented in the minutes, e.g. about the zero or one routing protocols. 

Tim

---

From: Mark Townsley <[email-masked]>
Date: Fri, 13 Jun 2014 16:10:57 +0200

> People have already made suggestions for how to fix the text, which I would like implemented.   "The IESG" isn't asking for a change.   Adrian has been trying to negotiate a change for several mont…

If it is truly Adrian alone with an individual opinion not shared by the IESG at all, frankly he should be contributing within the WG as an individual. 

Over and above that though, Adrian has formally Abstained. As in, formally declined not to ballot either for or against this document. He has willingly taken himself out of the game, removing the AD superpowers granted to him in the process. It sounds like he did so with some promise from you that you would try to insert 3 sentences from him. Not 3 sentences from the IESG, but from him, the same guy who formally said he is done being a part of the discussion. 

It would be different if Adrian had said "With these 3 sentences, I will remove my DISCUSS and ballot No Objection or Yes. If the WG doesn't like those sentences then I will continue to DISCUSS it with you or the WG until we reach consensus" That's the whole spirit of a discuss. An Abstain is different, a bit of a double-edged sword. On one hand, the AD is  sending a strong message that he or she doesn't think the document is worthy (and if a document collects enough of these, it doesn't move, I've sat through one of those cases before when I was in your shoes). On the other hand, the Abstaining AD has removed himself or herself from the debate. Rock meet hard place for you, so you have to make a call. Do what your WG is telling you, or respect the wish of an AD that has thrown in the towel with an Abstain position anyway. 

tl;dr: Ted, you've fulfilled your commitment. Respect Adrian's Abstain position and the consensus of the WG at the same time by removing the text, and forwarding the document to the RFC Editor. You could even do it without a new rev, just an RFC Editors note. As I type, the Ballot is clear, all you have to do is push the button.

- Mark

> I asked the working group to think about this a little harder because I need your help.   If your answer to this request for help is "no," then you are basically asking _me_ to take on this burden, and I can't. 

>   So please reconsider.   As I said, we've already had some good suggestions.   There is no reason why this has to be hard.
>

---

From: Tim Chown <[email-masked]>
Date: Fri, 13 Jun 2014 15:13:58 +0100

Hi Ray,

As ever, good commentary.

On the 30 second thing, that was put in after discussion in a homenet session maybe 4-5 IETFs ago. As the text says, it is a “finger in the air number”, but the whole of that “but as a guideline…” part could be removed.

Tim

On 12 Jun 2014, at 22:20, Ray Hunter <[email-masked]> wrote:

> I'm on record as preferring a "common Homenet routing protocol" without having any fingers in any particular choice.
> 
> I believe there is rough consensus around the choice of 0 or 1 routing protocol.
> 
> Fine by me. Apart from the use of the word "graph" which could be overloaded or suggest a preference for link state protocols. s/graph/consistent view/ ?
>> 
>> 
> Too explicit IMHO. What is wrong with s/determine the least cost path across the homenet towards the destination address given the source address /maintain a loop free forwarding path between any given source address and destination pair/
> Way too explicit IMHO. EIGRP is a perfectly good routing protocol that would be excluded by this requirement as the routing metric is a non linear sum of different individual link metrics, including minimum path bandwidth.
> Not that I'm urging use of EIGRP, but I don't see why it should be excluded on these grounds alone.
> 
> Way too explicit IMHO. I don't see why a figure of 30 seconds for convergence time is even given. I'm not happy to wait 30 seconds for video distribution over Homenet.
> Surely acceptable convergence time is a function of user expectations relative to the nature of the traffic being carried by the Homenet, combined with the available buffering before the user becomes aware of any topology change.
> Fine be me. But is totally inconsistent with the sentence above to always choose the shortest path. The "shortest path" may not be "the best" for all traffic. Again look at the concept behind EIGRP metrics, where high bandwidth traffic might be routed over a different route to latency sensitive traffic.
> Fine be me. I'd rather just chose one, but this appears to me like trying to get a group consisting of more than one economist to agree on anything.
>> 
>> 
> Fine be me. It might be worth adding that we do not expect LLN network to act as transit networks between more traditional areas of the Homenet if you are going to revise the text anyway.
> 
> 
> Ray Bellis wrote:
>> 
>> Dear Working Group,
>>

---

From: Tim Chown <[email-masked]>
Date: Fri, 13 Jun 2014 15:16:15 +0100

> better is the enemy of good enough, and it was good enough a year ago.

Well… :)

The last few months have basically been about bashing through a list of around 80+ IESG comments and discusses. The good news is that this one paragraph is (I really really hope) the last outstanding issue of that list to resolve. 

Tim

---

From: Mark Townsley <[email-masked]>
Date: Fri, 13 Jun 2014 16:20:41 +0200

> I'm basically making questions up here.   The document should say what the working group wants routing to accomplish.   Right now it's a bit of a kitchen sink, with a lot of (IMHO) inappropriately…

Ted, you asked Ray and I to issue a WGLC on a very specific set of text. You are falling into your own trap of going beyond that.

Yes, the document could be improved. In fact, after another year of coding and protocol development, I bet we could write a descriptive architecture document of what actually came out on the other side that is even better than we could today! 

The discussion here has actually been pretty good at tearing apart some of the things NOT to say, it's also made me think more about whether the IESG should keep stats on how much text it removes during a review rather than adds (I'll be asking Jari to include that in his doc stats, and I bet he'll find time to do it - the guy is amazing like that). 

Do we really want to crack open this document again? I really don't trust how the process has been working of late to believe that it would not lead to another round of DISCUSSes and Last Calls.

- Mark

---

From: Tim Chown <[email-masked]>
Date: Fri, 13 Jun 2014 15:25:36 +0100

On 13 Jun 2014, at 14:57, Ted Lemon <[email-masked]> wrote:

> Clearly we need the routing solution to get packets to the right egress based on source address.   Do we also need it to do load sharing across parallel links, if such links exist?   Is it important to minimize the number of hops?  

Para 7 of 3.5:
" It may be beneficial for traffic to use multiple paths to
   a given destination within the homenet where available, rather than a
   single best path."

>  How long of a delay can there be between changes to the topology (e.g., a router being unplugged) and recovery, assuming that a flow was going through that router?   

Para 6 of 3.5:
"Minimising convergence time should be a goal in any
   routed environment, but as a guideline a maximum convergence time at
   most 30 seconds should be the target (this target is somewhat
   arbitrary, and… “

> Is it okay to break a flow in that situation, or does it need to survive the transition?   

Not stated.  Should it be different to the border router resetting?

> Does the routing protocol need to be aware of the type of media a given link crosses, and does it need to prefer one media type over another where both are available?

Para 5 of 3.5:
"Multiple types of physical interfaces must be accounted for in the
   homenet routed topology.  Technologies such as Ethernet, WiFi,
   Multimedia over Coax Alliance (MoCA), etc. must be capable of
   coexisting in the same environment and should be treated as part of
   any routed deployment. The inclusion of physical layer
   characteristics including bandwidth, loss, and latency in path
   computation should be considered for optimising communication in the
   homenet.“

> I'm basically making questions up here.   The document should say what the working group wants routing to accomplish.   Right now it's a bit of a kitchen sink, with a lot of (IMHO) inappropriately…

Well, 3 of the 4 questions seem to be answered, or at least considered if left relatively open.

Tim

---

From: Ted Lemon <[email-masked]>
Date: Fri, 13 Jun 2014 10:29:09 -0400

> Ted, you asked Ray and I to issue a WGLC on a very specific set of text. You are falling into your own trap of going beyond that.

No, Mark, I agreed with Ray that the proposed text needed a last call.   Last calls are not for rubber stamps.   They often produce proposed changes.   This is what I wanted, and why I asked for the last call.   I don't think the text is right as is.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 13 Jun 2014 10:31:41 -0400

> Well, 3 of the 4 questions seem to be answered, or at least considered if left relatively open.

None of the text there looks like requirements, but yes, I agree the text already addresses some of the points I brought up.   Unfortunately, it does a lot of other stuff too.

---

From: Mark Townsley <[email-masked]>
Date: Fri, 13 Jun 2014 17:05:50 +0200

> No, Mark, I agreed with Ray that the proposed text needed a last call.   Last calls are not for rubber stamps.   They often produce proposed changes.   This is what I wanted, and why I asked for th…

Ted, that is not at all what Ray explained to me. In fact, I relaxed the WGLC scoping text we sent to the group vs. what he thought had been agreed between the two of you. But that's neither here nor there - of course any text is up for changing at any time, and WGLCs are not rubber stamps, which is why the text from Adrian is being rejected, just as we said it would be. Let's not put words in my mouth.

I will repeat, I agree some of the text isn't right, and the WG agrees as well. Current thinking has diverged, partially due to the length of time the document has spent sitting in committee. Given the number of comments and compromises up to this point, it is obviously a hornets nest that could unravel any number of past discussions, agreements, and compromises. 

Not all of the text is wrong though, and above all I am hearing "better is the enemy of good enough" comments that I have great sympathy for at this stage.

- Mark

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 14 Jun 2014 08:27:53 +1200

> No, Mark, I agreed with Ray that the proposed text needed a last call.   Last calls are not for rubber stamps.   They often produce proposed changes.   This is what I wanted, and why I asked for th…

There seems to be general agreement that the stuff about metrics
is over-specification. The rest of the text has already got the OK
from the ISEG. So why are we still discussing it? Just delete that
paragraph. The worst that happens is that the document advances with
one IESG abstention against it.

It's prototype implementations and early deployments that will
tell us the right answer, not further debate.

   Brian

---

From: Ted Lemon <[email-masked]>
Date: Fri, 13 Jun 2014 16:44:39 -0400

> tell us the right answer, not further debate.

Again, I didn't ask for "the answer."   I asked for a description of what we want in a routing protocol that isn't so prescriptive.   There's a lot of prescriptive stuff in there, and the reason that the particular paragraph you are proposing we remove got added was to counterbalance it.   E.g., why is there a paragraph about all the routers knowing the whole topology of the network?   Maybe they will, maybe they won't, but why is it specified?   If we don't know what we want, this bit seems awfully specific.   If we do know what we want, why not say what we want?

I think the right answer is to take out more text, but I'm not okay with just taking out the particular paragraph you mentioned, or I would not have asked for the working group's help on this.

---

From: Mark Townsley <[email-masked]>
Date: Sat, 14 Jun 2014 10:04:27 +0200

> I think the right answer is to take out more text, but I'm not okay with just taking out the particular paragraph you mentioned, or I would not have asked for the working group's help on this.

While I agree with Brian here, if you want more text out, so be it. Here's a proposal which 
does that, stopping short of trying to continue word-smithing the document at this stage.  

I simply took section 3.5 from -16, and removed sentences that seemed to me to be overly prescriptive, 
including the paragraph from Adrian. 

Ted, Is that good enough for you?

Removed:

   Using information

Result:

3.5.  Routing functionality

   source implementation becomes available.  

Chown, et al.           Expires December 12, 2014              [Page 28]
 
Internet-Draft            IPv6 Home Networking                 June 2014

   At most one routing protocol should be in use at a given time in a
   given homenet.  In some simple topologies, no routing protocol may be
   needed.  If more than one routing protocol is supported by routers in
   a given homenet, then a mechanism is required to ensure that all
   routers in that homenet use the same protocol.

Chown, et al.           Expires December 12, 2014              [Page 29]
 
Internet-Draft            IPv6 Home Networking                 June 2014

---

From: Ray Hunter <[email-masked]>
Date: Sat, 14 Jun 2014 15:44:26 +0200

Tim Chown wrote:
>
> On 13 Jun 2014, at 14:57, Ted Lemon <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> On Jun 13, 2014, at 9:48 AM, Lorenzo Colitti <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>> Not to me they didn't. Seriously - if you understand what we're 
>>> being asked to do, and it's simple to explain, then it shouldn't 
>>> take long for you to type. Please?
>>
>> The working group would presumably like for there to be routing on 
>> the homenet.   What problems is the routing supposed to solve?   What 
>> things are priorities?   What things aren't priorities?
>>
>> Clearly we need the routing solution to get packets to the right 
>> egress based on source address.   Do we also need it to do load 
>> sharing across parallel links, if such links exist?   Is it important 
>> to minimize the number of hops? 
>
> Para 7 of 3.5:
> "It may be beneficial for traffic to use multiple paths to
>>  How long of a delay can there be between changes to the topology 
>> (e.g., a router being unplugged) and recovery, assuming that a flow 
>> was going through that router? 
>
> Para 6 of 3.5:
>     arbitrary, and…“
>> Does the routing protocol need to be aware of the type of media a 
>> given link crosses, and does it need to prefer one media type over 
>> another where both are available?
>
> Para 5 of 3.5:
>     any routed deployment.The inclusion of physical layer
>> I'm basically making questions up here.   The document should say 
>> what the working group wants routing to accomplish.   Right now it's 
>> a bit of a kitchen sink, with a lot of (IMHO) inappropriately 
>> prescriptive text.
>
>> [email-masked] <mailto:[email-masked]>

OK. Ted asked for additional questions and answers, and I think he has a 
point in that there should be hooks to requirements in the architecture 
that facilitate selection of the correct routing protocol(s) later, 
without unnecessarily limiting the choice.

Here's my contribution after going through a few comparisons texts of 
common routing protocols that I found online. I pose a question, give my 
personal view, and then check if I can find an answer in the current text.

Does the Homenet Architecture require the routing protocol to carry 
arbitrary configuration information?
[my view] No. Assuming the existence of a separate Homenet configuration 
protocol, the routing protocol must facilitate auto-configuration, but 
does not necessarily have to supply configuration to other processes.
[this is not currently explicitly defined the architecture document AFAICS]

Does the Homenet Architecture require the routing protocol to support 
multiple address families?
[my view] No. The Homenet architecture is IPv6 only. Although support 
for IPv4 and other address families may be beneficial, it is not an 
explicit requirement to carry the routing information in the same 
routing protocol.
[this is not currently in the architecture document AFAICS]

Does the Homenet Architecture require the routing protocol to support SADR?
[my view] Yes.
[this is in the current architecture document]

"A routing protocol that can make routing
    decisions based on source and destination addresses is thus
    desirable, to avoid upstream ISP BCP 38 ingress filtering problems."

Does the Homenet Architecture require the routing protocol to be 
tolerant of lossy unstable links?
[my view] Yes.
[this is in the current architecture document]
"Technologies such as Ethernet, WiFi,
    Multimedia over Coax Alliance (MoCA), etc. must be capable of
    coexisting in the same environment and should be treated as part of
    any routed deployment. The inclusion of physical layer
    characteristics including bandwidth, loss, and latency in path
    computation should be considered for optimising communication in the
    homenet."

Does the Homenet Architecture explicitly require use of a distance 
vector or link state algorithms?
[my view] No. The Homenet architecture should be agnostic on this point.
[this is not currently in the architecture document AFAICS]

Does the Homenet Architecture need an EGP or an IGP?
[my view] An IGP.
[this is in the current architecture document]
This implies that internal routing
    functionality is required, and that the homenet's ISP both provides a
    large enough prefix to allocate a prefix to each subnet, and that a
    method is supported for such prefixes to be delegated efficiently to
    those subnets.

Is there a minimum hop count limit that must be supported?
[my view] No. The Homenet architecture is agnostic on this point, 
although use of Homenet in small offices and small enterprise site may 
require higher hop counts.
[this is not currently in the architecture document AFAICS]

Is there a penalty for the protocol being chatty?
[my view] No. LLN is not envisaged to be used as a transit network, and 
as such would be connected by a gateway router.
It is not envisaged that there will be significant limits on bandwidth 
consumption or Homenet routers having to sleep for power efficiency.
[this is not currently in the architecture document AFAICS]

[The current text is in relation to LLN only]

  In general, message
    utilisation should be efficient considering the network technologies
    and constrained devices that the service may need to operate over.

[plus the need for diverse routing metrics to cover a large range of 
bandwidths, but I can't see any requirements on the routing protocol 
itself.]

Is a specific update address preferred?
[my view]   The routing protocol should support both use of unicast and 
multicast updates.
[this is not currently in the architecture document AFAICS although you 
could argue it is covered by]

Further, link layer networking technology is
    poised to become more heterogeneous, as networks begin to employ both
    traditional Ethernet technology and link layers designed for low-
    power and lossy networks (LLNs), such as those used for certain types
    of sensor devices.

Scalability?
[my view] The protocol should scale up to ±50 routers?
[this is not currently in the architecture document AFAICS]

Proprietary protocols allowed or protocols requiring Intellectual 
Property agreements?
[my view] No. Must not be proprietary or be limited by IP.
[this is not currently in the architecture document AFAICS]

Multi-path support?
[my view] yes.
[this is in the current architecture document]
"The inclusion of physical layer
    characteristics including bandwidth, loss, and latency in path
    computation should be considered for optimising communication in the
    homenet."

Resource Consumption Limits?
[my view] Yes. Should be light weight with a small footprint suitable 
for inclusion into consumer products.
[this is not currently in the architecture document AFAICS]

Explicit support for Ad Hoc networks?
[my view] I don't know.
[this is not currently in the architecture document AFAICS]

Make your own mind up whether the current text is sufficient to cover 
all necessary requirements, without being unnecessarily over-specified.

-- 
Regards,
RayH

---

From: Ted Lemon <[email-masked]>
Date: Sat, 14 Jun 2014 09:48:20 -0400

That's really helpful, Ray.   Thanks!

(I don't know the answers to those questions, but they're just the sort of questions I wouldn't have thought to ask, which is why I tossed this back to the working group.)

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 14 Jun 2014 16:25:46 +0200

> [my view]   The routing protocol should support both use of unicast and

Please clarify.  Are you saying that the routing protocol must be able to
run over link layers that don't support link-local multicast?  AFAIK,
link-local multicast is part of the base IPv6 spec.

> [this is in the current architecture document]

Then I think I don't understand what is meant by "multi-path support".  Is
that merely the ability to switch to a better route if one becomes
available?  Or is there something more to it?  Could you please clarify?

-- Juliusz

---

From: Ray Hunter <[email-masked]>
Date: Sat, 14 Jun 2014 17:18:02 +0200

> Juliusz Chroboczek <mailto:[email-masked]>
> 14 June 2014 16:25

Multicast has issues on some link topologies (e.g. where it has to be 
emulated), and in situations where devices attempt to sleep for as long 
as possible. So even though link-local multicast may be part of the IPv6 
base spec, it may be desirable to avoid use of multicast traffic where 
possible. e.g. a routing protocol could perform initial neighbor 
discovery using multicast, but then switch to unicast when maintaining 
individual neighbor associations on the longer term, or for exchanging 
information with specific neighbors.
> available?  Or is there something more to it?  Could you please clarify?
I don't know that there is a single definition.

I interpret the above text as requesting an ability to perform load 
balancing over equal cost paths, potentially taking into account packet 
loss and link quality when selecting which stream to send over which link.
Another possible interpretation of the text would be an ability to route 
packets based on traffic type, e.g. policy based routing of video 
traffic over a different link to FTP.
Or a combination of the above.

If you have a better interpretation or definition then please share.
>
>
> ------------------------------------------------------------------------

-- 
Regards,
RayH

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 14 Jun 2014 17:49:58 +0200

> So even though link-local multicast may be part of the IPv6 base spec,
> it may be desirable to avoid use of multicast traffic where

Ah, I see.  Yes, that makes sense.

> "The inclusion of physical layer characteristics including bandwidth,
> loss, and latency in path computation should be considered for
> optimising communication in the homenet."

> loss and link quality when selecting which stream to send over which link.

I don't.  I interpret that as meaning that the routing protocol should be
able to pick a path using more refined criteria than just hop count.
E.g. to prefer a 1Gb/s link to a 100Mb/s one, or to prefer two wired hops
to a single wireless one.  Doing that is not too difficult, and yields
dramatic performance improvements in some fairly simple, realistic
topologies.

Load sharing is a completely different headache.  Done carelessly, load
sharing causes issues with increased latency and jitter, and causes
intermittent connectivity problems that are very difficult to troubleshoot
if one of the links is unreliable.  It also has ghastly performance if you
balance across wireless links without taking radio interference into account.

While it's certainly an area worth experimenting with, I'd be cautious
about requiring load sharing in Homenet unless somebody knows how to do it
right in the general unadministered case.

-- Juliusz

---

From: Ray Hunter <[email-masked]>
Date: Sun, 15 Jun 2014 12:51:11 +0200

> right in the general unadministered case.
Your interpretation of the current architecture text also seems 
perfectly valid, and is indeed much simpler to implement.

Should the text then rather say "Path selection in Homenet needs to be 
more sophisticated than measuring pure hop count due to the use of 
heterogeneous link technologies, and therefore the routing protocol 
should be capable of utilising multiple link-dependent metrics, such as 
bandwidth, delay, and link reliability", rather than mentioning "optimised"?

IMHO That revised text would provide a very clear selection criteria for 
preferring certain routing protocols over others.

Or do you think the text is OK as is?

-- 
Regards,
RayH

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 15 Jun 2014 18:03:51 +0200

> heterogeneous link technologies, and therefore the routing protocol should
> be capable of utilising multiple link-dependent metrics, such as

I'm happy with either.  The current text leaves it to the protocol people
to decide what "optimising" means, but I also like the way you spell out
the requirement.  If you'll allow me to indulge in some minor nit picking
wrt. your suggested wording:

 - you require "multiple [...] metrics", which is what we do in Babel, but
   we certainly don't wish to prevent somebody from being smart enough to
   design a single metric that works satisfactorily on all link layers;
 - you use "bandwdith" where you mean "throughput" (yeah, I know, I'm
   a pedant);
 - I'm on a personal crusade against the utilisation of the verb "to utilise".

So perhaps something like:

  Due to the use of heterogeneous link technologies, path selection in
  a homenet needs to be more refined than minimising hop count.  The
  homenet routing protocol should be able to select paths according to
  criteria such as latency, throughput, link reliability (e.g. measured
  packet loss) or other performance metrics.

-- Juliusz

---

From: Ray Hunter <[email-masked]>
Date: Mon, 16 Jun 2014 19:23:20 +0200

>    packet loss) or other performance metrics.
I could certainly live with your text, and if the WG ever moved to 
evaluating competing candidate routing protocols against requirements 
derived from the architecture, it could provide a useful and objective 
differentiator, which is possibly something that has been lacking up 
until now. e.g. {BABEL,  EIGRP, full IS-IS .....} might be preferred 
over {OSPFv3....} which might be preferred over {RIPng, HNCP native 
routing, IS-IS (only using cost and default cost=10) , AODV (without 
link quality extensions) ....} on this particular measure of suitability.

-- 
Regards,
RayH

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 16 Jun 2014 20:13:34 +0200

>>    path selection in a homenet needs to be more refined than minimising
>>    hop count.

> {BABEL, EIGRP, full IS-IS .....} might be preferred over {OSPFv3....}

To be fair, there's nothing *in principle* preventing an implementation of
OSPFv3 from encoding interesting stuff within its metric -- there's 16
bits to play with, if memory serves, just like in Babel.  Whether it's
actually doable in practice would require somebody actually doing the work
and trying it out.

Just like SADR.  (ducks)

-- Juliusz

---

From: Acee Lindem <[email-masked]>
Date: Mon, 16 Jun 2014 18:40:04 +0000

> actually doable in practice would require somebody actually doing the work

There is actually an implementation using a composite metric for OSPFv3 MANET. It was never standardized. 

Thanks,
Acee

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 16 Jun 2014 22:09:34 +0200

Hi Mark, participants to homenet WG,

I have some comments, FWIW.

Le 14/06/2014 10:04, Mark Townsley a écrit :
>
> On Jun 13, 2014, at 10:44 PM, Ted Lemon <[email-masked]
>> On Jun 13, 2014, at 4:27 PM, Brian E Carpenter
>> <[email-masked] <mailto:[email-masked]>>
>> wrote:
>> Again, I didn't ask for "the answer."   I asked for a description
>> of what we want in a routing protocol that isn't so prescriptive.
>> There's a lot of prescriptive stuff in there, and the reason that
>> the particular paragraph you are proposing we remove got added was
>> to counterbalance it.   E.g., why is there a paragraph about all
>> the routers knowing the whole topology of the network?   Maybe they
>> will, maybe they won't, but why is it specified?   If we don't know
>> what we want, this bit seems awfully specific.   If we do know what
>> we want, why not say what we want?
>>
>> I think the right answer is to take out more text, but I'm not okay
>>  with just taking out the particular paragraph you mentioned, or I
>>  would not have asked for the working group's help on this.
>>
>
> I simply took section 3.5 from -16, and removed sentences that seemed
> to me to be overlyprescriptive,
>
> whole homenet including attributes such as links, nodes,
> connectivity, and (if supported by the protocol in use) link
> metrics.
>
>
> the homenet towards the destination address given the source
> address. The path cost will be computed as a linear sum of the metric
> assigned to each link.  The metric may be configured or automatically
> derived per link based on consideration of factors such as worst-case
> queue depth and router processing capabilities.
>
>
> The inclusion of physical layer characteristics including bandwidth,
> optimising communication in the homenet.
>
>
> Homenets may use a variety of underlying link layer technologies,
> and may therefore benefit from being able to use link metrics if
> available.  It may be beneficial for traffic to use multiple paths
> to a given destination within the homenet where available, rather
> than a single best path.
>
>
>
> Result:
>
>
>
>
>
>
>
>
>
>
> 3.5
> <http://tools.ietf.org/html/draft-ietf-homenet-arch-16#section-3.5>.
> Routing functionality
>
>
>

Sounds as if there is no lightweight implementations high quality
open source of existing routing protocols?

> decisions based on source and destination addresses

Sounds as if current implementations dont do that?

> is thus desirable, to avoid upstream ISPBCP 38
> <http://tools.ietf.org/html/bcp38>  ingress filtering problems.
> arbitrary, and was chosen based on how long a typical home user
> might wait before attempting another reset; ideally the routers might
> have some status light indicating they are converging, similar to an
> ADSL router light indicating it is establishing a connection to its
> ISP).
>
> given homenet.  In some simple topologies, no routing protocol may
> be needed.

Some deployments of IPv6 homenets with multiple IP subnets dont run 
routing protocols, but static routing.  I've discovered that recently 
with much enthusiasm.  Maybe it's just a first step, but I havent seen 
documented this simple and numerous existing deployments.

> If more than one routing protocol is supported by routers
> in a given homenet, then a mechanism is required to ensure that all

Ok.

> <http://tools.ietf.org/html/draft-ietf-homenet-arch-16#page-30>
> device to a separate home network such as a LLN network, or a
> gateway to a guest or private corporate extension network.  In some
> cases there may be no border present, which may for example occur
> before an upstream connection has been established.  The border
> discovery functionality may be integrated into the routing protocol
> itself, but may also be imported via a separate discovery mechanism.

One simple mechanism to achieve it is to adiministratively assign 
coherently the default route in all the routers.  This may sound less 
sophisticated than saying "discovery" but could work.

Maybe a simpler requirement would be a "default-route distribution 
protocol", like in Router Renumbering, rather than a routing protocol 
which includes a border discovery.

> networks via gateway routers which interoperate with both the
> homenet and the LLN.  Current home deployments use largely different

This paragraph may read inconsistent by some reader (me).

I can see many sensors in home.  But the power requirements are much 
lesser than e.g. an outdoors deployments - indoors there is even IP over 
220V (PLC) so power is plenty.  There would be little reason to run an 
LLN in home.

Additionally, I think virtual machines (like in virtualization, or jvm) 
typically require much more power than real but small routers.

My two cents worth,

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 16 Jun 2014 22:12:09 +0200

> dramatic performance improvements in some fairly simple, realistic

I agree.  We did that in a lab experiment with OSPF on 
Ethernet/Bluetooth/WiFi and by defining new metrics.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 16 Jun 2014 22:17:17 +0200

>    packet loss) or other performance metrics.

I agree.  Some of the new performance metrics which are unaccounted for, 
but present in deployments, is the quantity of radio energy in the air. 
  This is a real customer issue for which current deployed solutions are 
on/off knobs (I want a knob to turn off all WiFi in my home, turn off 
all cellular in my home, turn off all Bluetooth in my home, etc).  More 
sophisticated solutions would involve metrics which quantify this and 
compare meaningfully.  An example is the DAS parameter for mobile phones.

Alex

---

From: Gert Doering <[email-masked]>
Date: Mon, 16 Jun 2014 22:18:00 +0200

Hi,

> documented this simple and numerous existing deployments.

This is not a "homenet" as per this architecture document.  The key is
"it needs to work for your parents, without you driving over and 
setting it up for them".

I know people that have BGP routing with PI space at home, but the fact
that it's "at home" does not make it a *homenet*.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 17 Jun 2014 16:39:46 +0200

> "it needs to work for your parents, without you driving over and

I suppose parents will likely ask the IPv6 specialists something like this:
- should I click on '6rd' or '6to4' or on 'DHCPv6' or on 'PPPoE'?
- should I click on ULA or not?
- should I click on private addresses or not?
- should I click on Delegate inside when using Delegate from outside,
   or not?
- what should I fill in as next-hop address?
- what does "dotted-decimal notation" mean with IPv6 addresses?
(these are examples from existing consumer equipment for in-house)

Little chances are there that parents will ask whether to use BGP or 
OSPF or please design a protocol for me. (haven't seen these options on 
consumer equipment GUIs).

I agree.

Alex

---

From: Tim Chown <[email-masked]>
Date: Tue, 17 Jun 2014 17:11:38 +0100

Hi Ray,

I like your questions, and I think many of your own suggested answers to your questions are in line with what I believe the WG has assumed in its discussions. I find myself in agreement with most (and perhaps all) of them.  But obviously I can’t speak for the WG, only my perception of WG consensus as the document editor.

I would say we did shy away from a specific answer on a separate configuration protocol in London, but since then HNCP has evolved. I agree the multi-path clarification is needed.

I think Alex is heading into too much detail, when we are trying to avoid that (what Ray describes are general principles).

I’m talking with Ted and the chairs on the approach to take.  Expect news soon :)

Tim

On 14 Jun 2014, at 14:44, Ray Hunter <[email-masked]> wrote:

> 
> 
> Tim Chown wrote:
>> 
>> On 13 Jun 2014, at 14:57, Ted Lemon <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> On Jun 13, 2014, at 9:48 AM, Lorenzo Colitti <[email-masked] <mailto:[email-masked]>> wrote:
> OK. Ted asked for additional questions and answers, and I think he has a point in that there should be hooks to requirements in the architecture that facilitate selection of the correct routing protocol(s) later, without unnecessarily limiting the choice.
> 
> 
> Here's my contribution after going through a few comparisons texts of common routing protocols that I found online. I pose a question, give my personal view, and then check if I can find an answer in the current text.
> 
> 
> Does the Homenet Architecture require the routing protocol to carry arbitrary configuration information?
> [my view] No. Assuming the existence of a separate Homenet configuration protocol, the routing protocol must facilitate auto-configuration, but does not necessarily have to supply configuration to other processes.
> Does the Homenet Architecture require the routing protocol to support multiple address families?
> [my view] No. The Homenet architecture is IPv6 only. Although support for IPv4 and other address families may be beneficial, it is not an explicit requirement to carry the routing information in the same routing protocol.
> Does the Homenet Architecture require the routing protocol to be tolerant of lossy unstable links?
> [my view] Yes.
> Does the Homenet Architecture explicitly require use of a distance vector or link state algorithms?
> [my view] No. The Homenet architecture is agnostic on this point, although use of Homenet in small offices and small enterprise site may require higher hop counts.
> [my view] No. LLN is not envisaged to be used as a transit network, and as such would be connected by a gateway router.
> It is not envisaged that there will be significant limits on bandwidth consumption or Homenet routers having to sleep for power efficiency.
> [plus the need for diverse routing metrics to cover a large range of bandwidths, but I can't see any requirements on the routing protocol itself.]
> 
> 
> 
> [my view]   The routing protocol should support both use of unicast and multicast updates.
> [this is not currently in the architecture document AFAICS although you could argue it is covered by]
> 
> Proprietary protocols allowed or protocols requiring Intellectual Property agreements?
> [my view] Yes. Should be light weight with a small footprint suitable for inclusion into consumer products.
> Make your own mind up whether the current text is sufficient to cover all necessary requirements, without being unnecessarily over-specified.
> 
> -- 
> Regards,
> RayH
>

---

From: "ietfdbh" <[email-masked]>
Date: Tue, 17 Jun 2014 13:38:10 -0400

> From: homenet [mailto:[email-masked]] On Behalf Of Alexandru
> Petrescu
[...]
> (these are examples from existing consumer equipment for in-house)
Wow! What parents!
Mine would be more likely to ask "how do I turn this on?"

David Harrington
[email-masked]
+1-603-828-1401

---

From: joel jaeggli <[email-masked]>
Date: Tue, 17 Jun 2014 10:48:26 -0700

>> - should I click on Delegate inside when using Delegate from outside,

So if you use a current IPv6 supporting CPE, normally you do nothing.

very occasionally you need to tick a box to enable it.

It is a mistake to assume that end users should be exposed to the
selection of transition technologies and that would ever be appropriate
in the general case.

---

From: Tim Chown <[email-masked]>
Date: Tue, 17 Jun 2014 18:59:37 +0100

Hi,

> selection of transition technologies and that would ever be appropriate

I agree, this conversation is heading into the weeds here, at least for closing off the arch text.

Tim

---

From: Ray Hunter <[email-masked]>
Date: Tue, 17 Jun 2014 20:02:56 +0200

> Tim Chown <mailto:[email-masked]>
> 17 June 2014 18:11
> Hi Ray,
>
> I like your questions, and I think many of your own suggested answers 
> to your questions are in line with what I believe the WG has assumed 
> in its discussions. I find myself in agreement with most (and perhaps 
> all) of them.
Glad to read that.
>  But obviously I can’t speak for the WG, only my perception of WG 
> consensus as the document editor.
I certainly don't claim to speak for the WG : I just hope my 
contribution moves the discussion on in a constructive way.
>
> I would say we did shy away from a specific answer on a separate 
> configuration protocol in London, but since then HNCP has evolved.
ACK.
> I agree the multi-path clarification is needed.
ACK.
>
> I think Alex is heading into too much detail, when we are trying to 
> avoid that (what Ray describes are general principles).
>
Thanks.

-- 
Regards,
RayH

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 20 Jun 2014 15:33:15 +0200

Le 14/06/2014 15:44, Ray Hunter a écrit :
[...]
> [this is not currently explicitly defined the architecture document AFAICS]

I agree a routing protocol in-house would not need to carry parameters 
such as printer's name.

> [this is not currently in the architecture document AFAICS]

I think the routing protocol must unconditionally support IPv6 natively 
and, if needed in some cases, IPv4.

> [this is in the current architecture document]

I think the routing protocol specs should include fields for source 
addresses (in addition to the traditional next-hop addresses), in order 
to facilitate source-and-destination rule matching in the routing 
tables.  But I dont think the routing protocol would implement anything 
more than carrying fields specific to sources.

>     desirable, to avoid upstream ISP BCP 38 ingress filtering problems."

I doubt the routing _protocol_ makes decisions about that.

>     computation should be considered for optimising communication in the

Certainly yes.

But this mentioning of MoCA makes wonder about a document IP-over-MoCA, 
which wouldn't be developped here, but would be necessary.

If IP does not run over MoCA then the coexistence statement above would 
make little sense.

Then, for the metric parameters, in addition to bandwidth, loss and 
latency, some parameters such as link energy consumption, or radiated 
energy, would make sense.

> [this is not currently in the architecture document AFAICS]

Yes, I agree.

Any one of distance-vector, link-state, path-vector or any combination, 
should be selectable.  A particular existing routing protocol should not 
be discarded solely on grounds of its link-state or distance-vector 
characteristic.  It's invalid to say "in-house routing can not be 
satisfied by a link-state protocol".

And there are other such characteristics: on-demand vs triggered, 
proactive vs reactive.

I agree.

> [this is not currently in the architecture document AFAICS]

I agree, and I'd go as far as citing numbers.

A typical in-house network would use 1, 3 to maximum 5 hops between any 
two most distanced nodes (hop limit decremented 5 times max).  It would 
link typical maximum of 255 uniquely IP-addressable interfaces.

A SOHO and small enterprise would require higher hop counts.

> [this is not currently in the architecture document AFAICS]

Yes, but chattiness in-house may translate into higher electricity bill.

Some people go as far as switching off the entire electricity when 
leaving home.  Adding a new protocol reads maybe as adding something new 
to switch off.

> bandwidths, but I can't see any requirements on the routing protocol

Yes, diverse routing metrics (more metrics than the existing bandwidth, 
hop-count, link "quality").

I agree.

>     power and lossy networks (LLNs), such as those used for certain types

I agree, but the phrasing could be improved.

BEcause it reads as if LLNs dont use Ethernet technology, whereas the 
802.15.4 LLN link does involve Ethernet headers.

> [this is not currently in the architecture document AFAICS]

I agree, this needs to be mentioned.  There is another question above 
mentioning number of hops, which could also be about scalability.

> [this is not currently in the architecture document AFAICS]

Hmm... this is difficult to discuss.  But one is obviously aware that 
IPR (Intelectual Property Rights) is tagged on a number of widely used 
routing protocols.

>     computation should be considered for optimising communication in the

I think multi-path means something along the lines of MP-TCP?  (not sure 
what multipath is in the context of e.g. OSPF).

> [this is not currently in the architecture document AFAICS]

Yes, I agree.

> [this is not currently in the architecture document AFAICS]

There could be an architectural requirement about the support of 
dynamically changing networks, but not sure about ad-hoc networks.

Maybe we could say something about proactive/reactive protocols (a term 
typically used in ad-hoc network discussions), or about the link 
characteristics of radio links (also often used in ad-hoc network 
discussions).

> all necessary requirements, without being unnecessarily over-specified.

I would see a requirement about DHCP Relay-Server discovery and 
configuration but I am not sure how to formulate it at architectural level.

I see the need to plug an 802.11ac Access Point on an in-house network, 
it self-configures from the existing DHCP Servers and then delivers IPv6 
addresses to Clients.

This is a 'research' kind of functionality.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 20 Jun 2014 15:48:37 +0200

Le 20/06/2014 15:44, Gert Doering a écrit :
> Hi,
>
> On Fri, Jun 20, 2014 at 03:33:15PM +0200, Alexandru Petrescu wrote:
> I see a very strong need for you to read up on the homenet drafts *before*
> trying to add your valuable input.
>
> Really.  90% of what you have written is either covered by the drafts already,
> or fully out of scope.  You are wasting people's time.
>
> Gert Doering
>          -- NetMaster
>

Sorry about that - please ignore that email.

Alex