Re: [homenet] Updates to Homenet Architecture Principles doc

[Ray Hunter <[e-mail]>]

Tim Chown wrote:
>
> On 13 Jun 2014, at 14:57, Ted Lemon <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>> On Jun 13, 2014, at 9:48 AM, Lorenzo Colitti <[e-mail] 
>> <mailto:[e-mail]>> 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
>     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 
>> prescriptive text.
>
> Well, 3 of the 4 questions seem to be answered, or at least considered 
> if left relatively open.
>
> Tim
>
>>
>> _______________________________________________
>> homenet mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/homenet
>

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