Re: [homenet] [v6ops] default LAN routing protocol for IPv6 CE router

[Sander Steffann]

Hi,

> I also agree that requirements and use cases seem the next logical step. I'd 
> be willing to document the ones that we are contemplating. It would be useful 
> to have someone more familiar with DSL/Fiber residential deployments do so 
> there as well.

I'll check the residential ISPs I'm working for.
Sander

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] [homegate] HOMENET working group proposal

[Sander Steffann]

>> In the context of the HOMENET working group, one imagines that restoring 
>> general end-to-end reachability is arguably a worthy goal.
> 
> +1


+1

Sander

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Homenet strawman slides

[Sander Steffann]

Hi,

>> For IPv6, I'm not sure what they should do, but I have some ideas.  
>> Basically, the router should advertise as a default router with a single ULA 
>> prefix and a DNS server at the router's ULA interface address with RFC 6106 
>> and optionally RFC 3736.  When the DNS query signals PPPoE to establish the 
>> WAN link, the DHCPv6 client will ask for a IA_PD and update the prefix 
>> advertised on the LAN accordingly.
> 
> "Update" or just advertise the new global prefix alongside the ULA?

Alongside. The ULA addresses should be stable so that they can always be used 
internally, independent on the link to the ISP.

- Sander



smime.p7s
Description: S/MIME cryptographic signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Mixing DNS in with routing information

[Sander Steffann]

Hi,

> I'm also nervous about both DNS authorisation
> and DNS authentication.  Who is allowed to make 
> which DNS advertisements and how do I authenticate 
> the received DNS advertisement as both valid and 
> authorised ?


Yes. The routing protocol saying 'please use this address to resolve 
google.com' might cause some problems... With DNSSEC in place it can still 
cause a denial of service when unsigned or invalidly signed data is returned.

Met vriendelijke groet,
Sander Steffann



___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Mixing DNS in with routing information

[Sander Steffann]

> No more than a DHCPv6 server saying "please use this DNS server for 
> everything". Right?

Right.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] regarding recursive DHCPv6-PD (and architecture document)

[Sander Steffann]

HI,

> So let's just say that giving a single /64 to the home is incompatible with 
> homenet architecture, and we need more addresses. I'm fine with that.

Yes please. I think some ISPs *need* to get a signal like this.
Sander

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] RFC: dhcpv4 to slaac DNS naming scheme

[Sander Steffann]

Op 15 feb. 2014, om 11:35 heeft Lorenzo Colitti  het 
volgende geschreven:

> Which ones are those, though? I mean - we can certainly write this up as is, 
> but if it doesn't work on Windows, Mac OS, or iOS, then... how much use will 
> it be in the real world? Given that homenet device implementation resources 
> are not unlimited, perhaps we should try to define things that have more 
> impact on devices that people use.

+1
Sander

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] RFC: dhcpv4 to slaac DNS naming scheme

[Sander Steffann]

Hi,

Op 15 feb. 2014, om 11:44 heeft Simon Kelley  het 
volgende geschreven:
> On 15/02/14 10:35, Lorenzo Colitti wrote:
>> On Sat, Feb 15, 2014 at 6:23 PM, Simon Kelley > > wrote:
>> 
>>This technique is useful for all the _existing_ systems that only do
>>EUI64 SLAAC, I don't think it's something we should do going forward.
>> 
>> 
>> Which ones are those, though? I mean - we can certainly write this up as
>> is, but if it doesn't work on Windows, Mac OS, or iOS, then... how much
>> use will it be in the real world?
> 
> The obvious answer is Android, which is what it was originally implemented 
> for. I think the three platforms you mention have have DHCPv6 support, 
> Android doesn't, or at least didn't: I'm not sure about the latest releases.

If Android is the only OS that benefits from this mechanism then I don't think 
this belongs in Homenet... Or in the IETF. We should develop interoperable 
solutions here. Sorry if I sound a bit harsh. This might have been an 
interesting solution many years ago, but not today. I think today this needs to 
be further integrated with maybe ND / DAD monitoring to make it work with 
non-EUI64 addresses.

Cheers,
Sander

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Single or Multiple Routing Protocols in Homenet

[Sander Steffann]

Hi,

> (Note: supporting multiple routing protocols here doesn't mean they need run 
> at the same time, just more choices.)

No, it does mean that everybody suddenly has to implement multiple protocols. 
In a homenet devices must *just work*. Burdening the home user with such 
choices doesn't make sense. And it means that when there are multiple protocols 
to choose from the devices will have to implement all of them. Having multiple 
protocols to support makes the implementors work much harder.

This is a VERY bad idea.
Sander

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Single or Multiple Routing Protocols in Homenet

[Sander Steffann]

Hi,

Op 1 jun. 2014, om 12:50 heeft Gert Doering  het volgende 
geschreven:

> On Sun, Jun 01, 2014 at 10:47:03AM +0200, Pierre Pfister wrote:
>> So even if most will agree that supporting multiple routing protocol is a 
>> madness in the general case. 
>> It?s not that hard to ?support it? while requiring one single routing 
>> protocol as mandatory in home networks.
>> And whenever we want to move to another protocol, maybe in 20 years, it will 
>> allow transitioning softly.
> 
> Having multiple routing protocols and select between them is already 
> permitted by the current HNCP draft (for example).
> 
> The question was more whether "add ISIS today" would bring a benefit to
> homenet, and I still maintain "no" - to the contrary, it is harmful - as
> you said, we can be happy if CPE vendors get one protocol right.

+1

I personally don't really care about which protocol that should be (I have some 
preferences, but "getting one protocol right" outweighs all those preferences 
by a huge margin) as long as we design something that is easy enough for CPE 
vendors to implement correctly so that for the home user everything just works.

Needing to implement multiple protocols, having to negotiate with other devices 
which of those protocols to use, network flaps because a device was added to 
the network that doesn't support the protocol that the other devices agreed 
upon etc. don't help in this regard.

Please remember: the end goal is to create a situation for home users that just 
works and works reliably, not to design the most fancy and cool combination of 
protocols possible...

Cheers,
Sander

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Single or Multiple Routing Protocols in Homenet

[Sander Steffann]

Hi Tim,

> Just as a reminder, here is what we converged on at IETF89 for text in the 
> homenet arch. The “zero or one” protocol message was clear. I don’t recall a 
> clear answer on whether to pass config info via the routing protocol or a 
> separate protocol, but as HNCP shapes up as a proposal I suspect the 
> tradeoffs will become clearer towards an answer there.
> 
>  "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."

Sounds good, and I see the need for having the possibility to introduce a new 
routing protocol in the future so that we can evolve if/when necessary. 
However, having multiple routing protocols will be disruptive in some ways. 
When a homenet consists of devices that all support the new protocol then 
connecting an older device that doesn't support it will force the whole network 
to switch to the old protocol. While this may be unavoidable when designing 
HomenetNG, it is not something we should be causing today.

Cheers,
Sander

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Source Address Dependent Routing - draft-sarikaya-6man-sadr-overview-00

[Sander Steffann]

> My opinion is that homenet shouldn't require new functionality in the host 
> stack for it to work, but if we can present suggestions for enhancements in 
> the host stack that makes things work better, and also enhance homenet to 
> take advantage of enhancements in host stacks to make things work better, I'm 
> all for that.
> 
> But our baseline is that a 10 year old host stack should work out of the box 
> with homenet, and I don't see us changing that.

+1 to all of the above
Sander

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Let's make in-home ULA presence a MUST !?

[Sander Steffann]

> I haven't even mentioned source address selection, as that doesn't come
> into play for a singlehomed homenet - but as soon as the homenet gets
> multihomed, applications would benefit a LOT from doing intelligent
> source address selection.  Like in presenting users a selection menu
> "use ISP? -> SpaceNet, HE.NET, don't care" and picking the appropriate
> source address.
> 
> Yes, there's quite a bit of specifications missing to be able to do that
> (like, how do I find a label to stick onto an address I find on my 
> interface), but for a *homenet*, this is the way it needs to be - nobody
> will fiddle with the router to do "http goes to SpaceNet, bittorrent goes
> to HE.NET", but if the application can do it, it greatly empowers users.

Indeed. And some devices like mobile phones already allow the user to say "only 
sync my photo album when on Wifi".

One thing that does worry me is every application developer having to re-invent 
the code for all of this (find labels, actually implement the networking code 
correctly etc). I think a standard API should be available for all of this. 
Otherwise all operating system vendors and distributions will come up with 
something completely different which will make it even harder for the 
application developers to do the right thing.

Cheers,
Sander

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Let's make in-home ULA presence a MUST !?

[Sander Steffann]

Hi,

> Op 14 okt. 2014, om 18:27 heeft Ted Lemon  het volgende 
> geschreven:
> 
> On Oct 14, 2014, at 11:22 AM, Sander Steffann  wrote:
>> One thing that does worry me is every application developer having to 
>> re-invent the code for all of this (find labels, actually implement the 
>> networking code correctly etc). I think a standard API should be available 
>> for all of this. Otherwise all operating system vendors and distributions 
>> will come up with something completely different which will make it even 
>> harder for the application developers to do the right thing.
> 
> It would be helpful if you could participate in the MIF working group, which 
> is working on solving this problem.

Will do :)
Sander

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Let's make in-home ULA presence a MUST !?

[Sander Steffann]

Hi James,

> Consider a hypothetical router that has the regular automatic default 
> behavior of commissioning a new standalone network while discovering any 
> existing networks that it already possesses the credentials to join. Now 
> consider what happens when devices of this category are continually losing 
> and regaining their connectivity with the rest of the wireless network in the 
> home. Let's imagine this happens many times per hour. How many days does it 
> take before all your constrained-resource hosts have no space left in their 
> route tables for all the deprecated but still valid ULA prefixes?

Does it have to be a *new* standalone network (ULA prefix)? The router could 
just generate a ULA prefix once and reuse it whenever it needs to, right? 
Generating a new prefix on every connect/disconnect would indeed cause a mess...

Cheers,
Sander

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Let's make in-home ULA presence a MUST !?

[Sander Steffann]

Hi Ralph,

>> In particular, you appear to be arguing as if ULAs and GUAs are treated 
>> identically by IPv6 stacks, but they are not.
> 
> Really?  In what way are they not treated identically by IPv6 stacks?

ULA space does have a separate entry in the policy table of RFC 6724 
(https://tools.ietf.org/html/rfc6724#section-2.1)

Chees,
Sander

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Let's make in-home ULA presence a MUST !?

[Sander Steffann]

Hi Ted,

> My point was that homenets should have ULAs, and should not use GUAs for 
> local communication, because GUAs can be flash renumbered, and the use of 
> them on the local wire has the potential to cause disruptions on the local 
> wire that could be prevented by using ULAs.   And that there is no real 
> downside to having ULAs on the local network.

I am starting to agree.

I think we should see if we can come up with a good way to manage the ULAs when 
splitting/merging/etc networks though. If we can't find something good for that 
then the solution might be worse than the original problem.

Cheers,
Sander

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Let's make in-home ULA presence a MUST !?

[Sander Steffann]

Hi,

> Op 16 okt. 2014, om 15:22 heeft Lorenzo Colitti  het 
> volgende geschreven:
> 
> Per the table in http://tools.ietf.org/html/rfc6724#section-2.1 it will pick 
> the GUA as a destination address, and per Rule 6, it will choose the GUA to 
> connect to it.

Do you know if anything implements 
http://tools.ietf.org/html/rfc6724#section-10.6 (a site-specific policy entry 
for the local ULA prefix)?

Cheers,
Sander

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Routing protocol comparison document

[Sander Steffann]

Hi Ted,

> Op 19 feb. 2015, om 19:49 heeft Ted Lemon  het volgende 
> geschreven:
> 
> I don't know.   Homenet multicast is an open issue.   But I don't think this 
> use case represents a serious problem, because as far as I can tell streaming 
> video is not done using multicast in practice anyway.

Sorry, bad assumption. I just finished working on a TV streaming project for an 
ISP and there is lots of multicast there. All live TV channel streams to STBs 
are multicast and this is a common setup amongst ISPs.

Cheers,
Sander

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Routing protocol comparison document

[Sander Steffann]

Hi Barbara,

> OTT video does not use multicast. IPTV deployments do use multicast. Those 
> that I'm aware of require use of the provider-supplied CE router, which has 
> an IGMP proxy (and MLD proxy if IPv6 multicast is supported) for LAN-to-WAN 
> multicast management. Where Wi-Fi distribution of these multicast streams is 
> supported, it is only done on a dedicated (and highly managed and somewhat 
> proprietary) Wi-Fi network, that is distinct from the general-purpose (and 
> not "professionally" managed) Wi-Fi network. The LAN interfaces of the 
> provider-supplied CE router do tend to have IGMP/MLD snooping, to keep from 
> flooding the general-purpose network interfaces with large multicast streams. 
> There may also be a coax networking interface. If there is, this also tends 
> to be dedicated and highly managed. Where Ethernet is used for distribution 
> of multicast, it is done so that the provider STBs are all attached to the 
> provider CE router via the same Ethernet port (and no other devices use that 
> port) and the
 re are no intervening routers. I mentioned at the last IETF that I expect some 
"home networks" to have managed and unmanaged segments. I don't consider the 
dedicated, managed segments to be part of the homenet domain. I would hope that 
the provider-supplied CE router would support homenet on its general purpose 
network interfaces. 
> 
> I'd be curious to learn about multicast IPTV deployments that allow users to 
> supply their own CE routers and send multicast streams on network segments 
> that are also used for general-purpose home networking (especially 
> general-purpose Wi-Fi networks). 

The above is correct. Provider-supplied CPEs are currently necessary and 
intermediate routers are not supported. The TV streams can be on a separate 
VLAN. But this is what is currently done because of the difficulty of doing it 
over the regular home network. It doesn't mean we should design Homenet in the 
same way. I'd rather see that providers supply Homenet routers to their 
customers and that the multicast TV streams just work.

Cheers,
Sander

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Routing Protocol in HNCP

[Sander Steffann]

Hi Brian,

> If that makes sense (for any value of IsBabeliS) I don't think we have a 
> problem.
> I would suggesting adding text near the beginning stating that HNCP is 
> agnostic
> about the routing protocol, but that a single routing protocol must be used.

And that "single routing protocol" is ... ???

This basically just ignores the problem that a routing protocol must be chosen 
and might even open the door to vendor A saying "our single routing protocol is 
X" and vendor B saying "our single routing protocol is Y". This decision has to 
be made at some point...

Cheers,
Sander

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Sander Steffann]

Hi,

> What's wrong with picking a routing protocol that will handle both
> unreliable homenet links *and* a perfectly stable topology, in preference
> to a protocol that you seem to imply wants a "stable environment"?
> 
> Babels will work perfectly well on a totally loss-free wired topology.

+1

> [..]
>> One group sees the homenet consisting of a bunch of "ad-hoc" wifi links 
>> with dubious quality and working part of the time, another group sees the 
>> homenet consisting of (fairly) reliable links that can be used for real 
>> time communication and high speed communication that works "all the time". 
>> These visions are not compatible, the requirements that fall out of these 
>> visions are not compatible, and this is why we have this stale-mate.
> 
> We seem to have one routing protocol that handle both variants without
> any drawbacks, and another one which seems to be only suited for one
> variant of homenet.  Why is the decision difficult?

I agree.
Sander

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Sander Steffann]

Hi,

> Op 26 jul. 2015, om 03:07 heeft Ted Lemon  het volgende 
> geschreven:
> 
> Thanks, but the working group is not confused as to whether IS-IS could be 
> made to work.   We understand that it could be made to work.   One active 
> participant in the working group has an open source implementation.   It 
> works.   It lacks a feature we want, but that feature could be added.   
> However, adding that feature would be a new research project, which would 
> require a substantial game of catch-up.   That is why there is a controversy 
> about this in the working group.   Otherwise I would be wholeheartedly 
> supporting IS-IS—I fought against the consideration of Babel back when it 
> first came up, on the grounds that we already had good candidates, and have 
> no personal stake in its winning other than that I now think it would get us 
> across the finish line faster, if we were allowed to use it.

I think this is a good summary. We seem to have something that works well for 
what we need. I am sure we can come up with something even better, but at some 
point we need to realise that good enough is good enough. As an ISP I want to 
reach the point where I can actually deliver homenet-capable products to my 
customers.

Cheers,
Sander

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Sander Steffann]

Hi,

> My point was simply that the IETF has multiple of … pretty much everything 
> else … the reason why things work is that somebody (an operator group, an 
> industry alliance/forum, …) figure out what is MTI — for their context — and 
> then do that.
> 
> I am simply wondering out loud why that would not, also, work here? 

Because a homenet doesn't have an operator, let alone an operator group or 
alliance. For managed networks the operator can decide what protocol to use. 
For unmanaged networks that have to work for people who don't have any clue 
about networking there is nobody to make that choice: it just has to work.

And if we leave it to CPE vendor alliances the chance of getting them all to 
implement the same protocol are pretty bad. I don't want to end up in a 
situation where products have to be labelled with Homenet-BABEL® and/or 
Homenet-ISIS® logo's etc... And then we'll need products that support multiple 
protocols, and then we need redistribution between those protocols, and then we 
end up in a nightmare situation where weird routing loops happen, the homenet 
breaks for unknown reasons (because there is no operator to solve them) etc etc.

A homenet is supposed to be simple to implement, simple to operate (just plug 
it in), fool-proof etc. All this complexity if very much unwanted and would 
defeat (destroy) the whole homenet effort.

Cheers,
Sander

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] Despair

[Sander Steffann]

Hi,

All these discussions about the routing protocol are making me despair... What 
the *** is wrong here in the IETF? What happened to producing working solutions 
and specs? All this discussion about which routing protocol is capable of doing 
what, "my protocol is as good as yours", bashing each other's ideas, twisting 
each others words. People, this is just pathetic. There are dozens of routing 
protocols that could be made to work in homenet. But we already have one that 
is working today. With time there will always be new ideas and improvements. 
And if we keep waiting for that we never get anything done. Do we want a 
'perfect' protocol in years or do we want a good solution today? We have what 
we need: let's move on...

Cheers,
Sander

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Despair

[Sander Steffann]

Hi Mikael,

> As far as I can tell, we have two, of which one is well known in the IETF, 
> has a working group that is well attended with people from different 
> organisations, has 20+ implementations total and has 20+ years of experience 
> and shown extendability, and has multiple extensive commercial testing suites 
> against which implementations can be validated.
> 
> The other one is experimental, doesn't have a working group, and seems to 
> have more of a FOSS/Linux style development model with a single "real" 
> implementation. Some might say this is better than what the IETF does, but 
> others do not.

Ok, so this discussion is more about following established procedure and about 
age of the protocol then. Glad to finally see the real arguments on the table :)

Cheers,
Sander

PS: yes, I know I am exaggerating, but we need to break out of this deadlock

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Sander Steffann]

Hi,

> Op 10 aug. 2015, om 10:20 heeft Lorenzo Colitti  het 
> volgende geschreven:
> 
> Personally I doubt that in the market segment we're talking about (which 
> includes many vendors that just take open source implementations, integrate 
> them, and ship them) vendors will understand or care about the difference 
> between an experimental RFC and a standards track RFC. Though of course, not 
> being one of those vendors, my opinion is in no way authoritative.

The CPE vendor that I worked with on IPv6 features definitely wouldn't care as 
long as they could sell a 'cool feature' to their customers.

> Op 10 aug. 2015, om 10:23 heeft Erik Kline  het volgende 
> geschreven:
> 
>> Whilst not wanting to de-rail any effort to standardise Babel (since I
>> firmly believe it should be standardised), I'd like to hear the WG's
>> view on having part of our Homenet stack be on Experimental Track
>> instead of PS.  E.g., would it affect vendors' willingness to implement
>> Homenet, etc?
> 
> +1
> 
> Especially if that got us to a place where 2-3 years from now we could
> publish {D,H}NCPbis incorporating lessons learned and whatnot as a
> Proposed Standard, I think that would be a perfectly acceptable
> outcome.

+1

Sander

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Routing Design Team outcome and next steps

[Sander Steffann]

> Op 27 okt. 2015, om 12:18 heeft Lorenzo Colitti  het 
> volgende geschreven:
> 
> Hear, hear!
> 
> We have spent far too much time arguing about this, and I am happy we have a 
> conclusion. A big thank you to the chairs for calling making this call. I 
> strongly agree that given the dynamics of the home networking market, there 
> needs to be one, and only one, routing protocol. I don't see anything else 
> working in the real world.
> 
> Personally, I happen to think that babel is the best choice, not so much 
> because of the protocol itself but because of the current availability of 
> solid, freely-licensed, small-footprint implementations. But IS-IS would have 
> been fine as well; so would OSPF, if there had been an implementation, and 
> even HNCP fallback would have fine. At the end of the day it doesn't really 
> matter which one we choose, as long as we choose one.
> 
> Let's hope that this will stop the arguments and we can all get on with 
> implementation and deployment.

Well said, +1 to all of the above

Cheers,
Sander

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] homenet-babel-profile: determining link type

[Sander Steffann]

Hi Barbara,

> Should we really only suggest that the router dynamically probe the quality 
> of wireless links? Or would it make sense to suggest dynamic probing of all 
> links, because assuming the entire path between 2 routers uses a single 
> physical layer technology may not be a good assumption?

Good point. My gut feeling is that the percentage of cases where that 
assumption would be wrong is small but significant enough that we should 
consider probing all links.

Anybody with better (=any) data?

Cheers,
Sander

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] primary / secondary configuration

[Sander Steffann]

> Op 18 jun. 2019, om 17:03 heeft Ted Lemon  het volgende 
> geschreven:
> 
> On Jun 18, 2019, at 10:56 AM, Daniel Migault  
> wrote:
>> I am also questioning on whether we should provide some sort of 
>> recommendations for the UI. While we are not UI designers, I believe some 
>> properties could be interesting for designers, and those may be helpful to 
>> be provided.
> 
> The trouble that we have gotten into repeatedly in this working group is that 
> we write the specification in anticipation of an implementation, rather than 
> on the basis of experience doing an implementation.   We have a fantastic 
> testbed for this: OpenWRT.   I am at this point somewhat expert in doing 
> OpenWRT builds.   Rather than speculating about what we need to say, why not 
> do an implementation, see how it works, and then do a writeup based on what 
> we learned?   We’re already talking about doing this at the Hackathon.

Running code is always a good teacher
Sander



signature.asc
Description: Message signed with OpenPGP
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet