Re: [homenet] Updates to Homenet Architecture Principles doc

[Tim Chown <[e-mail]>]

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 <[e-mail]> wrote:

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