Hi Ole, Op 20 mrt. 2013, om 23:38 heeft Ole Troan <o...@cisco.com> het volgende geschreven:
> Teco, > >> Still I am puzzled how we can support multiple provisioning domains with >> multi-addressed hosts in a homenet. May I reference to the discussion in mif? >> http://www.ietf.org/proceedings/86/slides/slides-86-mif-1.pdf >> >> For providing information on provisioning domains, we might look into DHCP >> _and_ ND. I think both can and should be supported. I think one of the >> problems is how to merge or multiplex information from/for these >> provisioning domains. Has DHCP a kind of ProvisioningDomain_ID on each (serf >> of) data element(s)? On SAS/DAS policy, how to create such automatically in >> network elements? If we can't on the fly, it might be irrelevant for homenet. > > unmanaged and policy are at different ends of the scale. I don't know how you > can do anything automatic with that. So we face a problem here... That's why I think it is a bad idea to merge information from different provisioning domains into a single service. Multiplexing looks better, then policies from provisioning domains can be transferred to the mif hosts without mangling. That brings me to the concept that provisioning domains are identified by (IPv6) prefixes and each prefix has its own configuration channel, either DHCP or ND. With BRDP, my proposal is that the ND BRDP "border prefix" or "provision domain ID" is also the DHCP server address, so aware mif hosts can get policies from it. > > in the homenet prototype I was talking about we implemented > draft-bhandari-dhc-class-based-prefix-04. > where we attached a "colour" to each address prefix. this could then be used > as a handle for SAS/DAS or for the application. OK, I missed this. I have my doubts on the proposed class encoding / coloring scheme. > I don't think the homenet should get into the "policy" part of this, but > rather just provide some simple tools/infrastructure. Hmm. I also prefer simple tools/infrastructure. But let's try to solve some problems, or at least we shall not block solving later on. > >> I agree SADR is a major part of the right solution. Source address indicates >> the provision domain, at least for IPv6. Hosts need to be updated and mif >> should take the lead here. But mif only can take the job if the network >> supports multiple provisioning domains well, e.g. SADR. Updated hosts need >> SADR as well. > > I've always seen SADR as a network function. hosts would do RFC6724. SADR on hosts is used quite often, where redundant links are in place. > > there would be some gain in being able to signal hosts with routing > information. not sure what that should be, unless we would just have hosts > participate in the IGP. The IP stack of many host operating systems are able to route. So if we implement SADR on routers, hosts will have the code also one day. I'm not so comfortable on having hosts running the routing deamon. That's why I came on the BRDP based routing idea, where all nodes in the edge network act equivalent: route the packets with destinations external to the edge network to the right border router. Works with all routing protocols. Works for mif hosts. Only the Prefix_to_BorderRouter_table is needed, with some SADR forwarding logic. Back to the draft-ietf-homenet-arch WGLC: this provisioning domain topic is not addresses very well. Question is if we will address it, hand it over to mif, or cooperate where we focus on the (plug&play) network part and mif takes the hosts. @Ted: can you guide us here? Teco _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
