Re: [homenet] list of questions on routing section (was: Updates to Homenet Architecture Principles doc)

[Alexandru Petrescu <[e-mail]>]

Le 14/06/2014 15:44, Ray Hunter a écrit :
[...]
> 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]

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

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

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

> Does the Homenet Architecture require the routing protocol to support SADR?
> [my view] Yes.
> [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.

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

I doubt the routing _protocol_ makes decisions about that.

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

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.

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

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.

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

I agree.

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

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.

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

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.

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

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

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

I agree.

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

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.

> Scalability?
> [my view] The protocol should scale up to ±50 routers?
> [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.

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

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.

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

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

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

Yes, I agree.

> Explicit support for Ad Hoc networks?
> [my view] I don't know.
> [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).

> Make your own mind up whether the current text is sufficient to cover
> 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

>