Re: [homenet] Working Group Last Call for draft-ietf-homenet-arch-07
Teco, [...] 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. are the problems clearly understood at this point? written down? 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. that's not SADR. SADR is about _forwarding_ of packets. [...] 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 (plugplay) network part and mif takes the hosts. I think we have a fair idea of how to deal with the home network being multi-homed. i.e. two or more connections to the Internet. we also have a decent idea of how to deal with multi-homing to non-congruent networks, see draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-05 I'm not quite sure what problem multiple provisioning domains is trying to solve outwith that. cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Working Group Last Call for draft-ietf-homenet-arch-07
On Mar 21, 2013, at 1:51 AM, Teco Boot t...@inf-net.nl wrote: 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 (plugplay) network part and mif takes the hosts. @Ted: can you guide us here? There's a third alternative: help MIF to get it right. The work is certainly in MIF's charter, and homenet has bitten off a pretty big chunk, so duplicate work is worth avoiding. At the same time, I think MIF is in fact crucial to homenet, so if you want to see homenet succeed it's in your interests to help with the work MIF is doing as well. I'm hearing a lot of useful thinking about the MIF architecture here, which I would like to see captured in the MIF architecture document. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Working Group Last Call for draft-ietf-homenet-arch-07
Hi Ole, Op 21 mrt. 2013, om 09:13 heeft Ole Troan o...@cisco.com het volgende geschreven: Teco, [...] 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. are the problems clearly understood at this point? written down? We have RFC6418 and RFC4477. Maybe we need to write down the multiple DHCP server problem (homenet with set of CPE devices attach to different provides, each with incompatible DHCP info). v6ops-ipv6-multihoming-without-ipv6nat-05 points towards the problem, section 7.3. Policy collision consideration. However, in the abstract it says: ... We conclude that DHCPv6 based solutions are suitable to solve the multihoming issues, described in this document, while NPTv6 may be required as an intermediate solution. May I say I think DHCPv6 and NPTv6 don't fix the problems? Maybe they make live even harder for right shaped MIF hosts. 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. that's not SADR. SADR is about _forwarding_ of packets. The troan-homenet-sadr is written for routers. It applies to hosts with multiple interfaces or single interface with multiple next-hop routers as well: same problem, can use same solution. For both cases, RFC6724 hosts need a little luck to make best guesses. So for me, Source Address Dependent Routing (SADR) and source address-based routing (out of multihoming-without-ipv6nat-05) are two names for same animal. [...] 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 (plugplay) network part and mif takes the hosts. I think we have a fair idea of how to deal with the home network being multi-homed. i.e. two or more connections to the Internet. Yes, we can deal with routing: do something with source address. we also have a decent idea of how to deal with multi-homing to non-congruent networks, see draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-05 I'm not quite sure what problem multiple provisioning domains is trying to solve outwith that. I don't think we decided how to deal with disjunct config options (DHCPv6 or learned via other means), on how we can relay this info over a homenet to a MIF host, without losing any functionality. draft-boot-homenet-brdp-00 deals with it. It provides MIF hosts pointers to the border router, where for each provisioning domain there is a prefix and a border router with an address within that prefix. So an aware host can get all it wants to know. Teco ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Working Group Last Call for draft-ietf-homenet-arch-07
Ole, 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. 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. And of course the legacy stuff is out there. Re-reading sections on multihoming (3.2.4, also 3.4.4), there is enough room for solution space. I would expect some more guidelines form an architecture, but now there are no constrains on what we may work out. That's fine. May I suggest to add MPTCP (RFC 6824) at bottom of 3.2.4? Teco Op 4 mrt. 2013, om 13:04 heeft Ole Troan o...@cisco.com het volgende geschreven: Teco, Reading the homenet-arch, I can't find how multi-addressed hosts are guided to prefer one address over another. I think such facility is beneficial in multi-homed homenets. the intention is to propagate the SAS/DAS policy given with draft-ietf-6man-addr-select-opt, and more specific routes learn on the border, combined with source address dependent forwarding. as well as rule 5.5 of 6724. This will work when every access router is a DHCP server, right? What if no DHCP or DHCP-relay? Do we generate this option out of routing information? Or some other zero-config magic? I don't think there is any intention of creating SAS/DAS policy on the fly. I was only thinking of passing that along to hosts. the homenet will using SADR ensure that BCP38 rules are satisfied. nothing more. I'm not sure what you mean by the DHCP question. DHCP has an option to pass SAS/DAS policy to hosts. I'm not suggesting DHCP is used to propagate that information around between routers in the home net. that's in solution space though. there is already a reference to the multihoming-without-ipv6nat document. do you have ideas of anything else we should add to the architecture document? Maybe it is my reservations on the current suggested solutions. I don't understand why we don't make use of ND. Then, access routers can provide whatever they wish, from whatever source and the host can ignore or take some benefits. again I don't quite understand what you mean. which protocol is used to convey network information to the hosts doesn't much matter in my view... cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Working Group Last Call for draft-ietf-homenet-arch-07
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. 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. I don't think the homenet should get into the policy part of this, but rather just provide some simple tools/infrastructure. 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. 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. And of course the legacy stuff is out there. Re-reading sections on multihoming (3.2.4, also 3.4.4), there is enough room for solution space. I would expect some more guidelines form an architecture, but now there are no constrains on what we may work out. That's fine. May I suggest to add MPTCP (RFC 6824) at bottom of 3.2.4? agree. cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Working Group Last Call for draft-ietf-homenet-arch-07
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 (plugplay) 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
Re: [homenet] Working Group Last Call for draft-ietf-homenet-arch-07
Hi Ray, Thanks as ever for the comments, which I have integrated and commented on below On 23 Feb 2013, at 18:40, Ray Hunter v6...@globis.net wrote: As requested I have read draft-ietf-homenet-arch-07. Thanks everyone for the effort so far. IMHO I think the document is in very good shape, but that we're not quite there yet (which I guess means I'm obliged to supply comments on why I think that's the case). The main thrust of my comments below is an underlying feeling that we haven't yet fully got a handle on the boundary at the ISP/customer interface the homenet/Internet interface, and that this will bite us later. I also think there's quite a bit of room to tighten up on nomenclature. e.g. home network v. homenet. ISP uplink v. Customer Internet connections. Border v. CER v. Border CER. Perhaps rather surprisingly, homenet is not defined anywhere. regards, RayH Detailed comments === Section 1 s/While at the time of writing some complex home network topologies exist, but most are/ While at the time of writing some complex home network topologies exist, most are / s/like to avoid such/like to avoid, such/ s/IPv6 with an eye/IPv6, with an eye/ s/can not be affected by new /cannot be modified by new / /[RFC6204] defines basic requirements for customer edge routers (CERs). The scope of this text is the internal homenet, and thus specific features on the CER are out of scope for this text./ I find this particular formulation confusing. Perhaps /[RFC6204] defined basic requirements for customer edge routers (CERs), which has recently been updated with the definition of requirements for specific transition tools on the CER in RFC 6204-bis [I-D.ietf-v6ops-6204bis] i.e. DS-Lite [RFC6333] and 6rd [RFC5969]. Such detailed specification of CER devices is considered out of scope of this architecture document, and we assume that any required update of the CER device specification as a result of adopting this architecture will be handled as separate and specific updates to these existing documents./ Section 1.1. /CER: Customer Edge Router. A border router at the edge of the homenet./ I regularly read Homenet BR or Border Router on this list used interchangeably with CER. Are they different? Equivalent? Or do we need to change our behaviour/definitions? We assume that the CER has an interface to one or more ISPs, and to one or more internal subnets. See section 3.2 where topology is discussed. This is my biggest worry. Do we have a good handle on the interface at the border? The text talks about demarcation: Demarcation of the CER. The CER(s) may or may not be managed by the ISP. If the demarcation point is such that the customer can provide or manage the CER, its configuration must be simple. Both models must be supported. Does the set of End-User network(s) in Section 3 map 1:1 with a homenet? I don't think so: it includes the CER. What is a Service Provider Network? The rest of the Internet that isn't in the homenet? Wouldn't harm to copy some more definitions from 6204. Fair point, some of that has been copied. We don't use language like 'end-user network' in this text though; instead we use 'homenet'. Section 2.1 s/This is discussed later in the document./This is discussed in Section 3.7./ /border router(s)/ See comment on 1.1 Border Router v Customer Edge Router? Added to the definitions. /There will also be the need to discover which routers in the homenet are the border router(s) by an appropriate mechanism. Here, there are a number of choices. These include an appropriate service discovery protocol, or the use of a well-known name, resolved by some local name service. Both might have to deal with handling more than one router responding in multihomed environments./ Above paragraph does not make sense to me. Seems to be a context shift in the middle of the paragraph. How is a name service related to discovery of a border router? We're not suggesting all CER's have to be called a particular hostname? Deleted, as it's covered under routing. /2.2. Global addressability and elimination of NAT/ Strictly speaking, NAT won't be eliminated entirely. IPv4 will still use NAT. IPv6 never had NAT. How about just /2.2. Global addressability/ s/The end-to-end communication that is potentially enabled with IPv6/ The possibility for direct end-to-end communication on the Internet that will be restored by the introduction of IPv6/ The Internet architecture always was, and still is, direct end-to-end communication. We just temporarily lost the ability to do it due to lack of addresses. Indeed. The elmination of NAT part has been left in though. s/on the firewall/ on any firewall/ Section 2.3 s/Default Address Selection for IPv6[I-D.ietf-6man-rfc3484bis]/ Default Address Selection for Internet Protocol Version 6 (IPv6) [RFC6724]/ s/We
Re: [homenet] Working Group Last Call for draft-ietf-homenet-arch-07
Ultimately, I would like to see a host in a homenet with multiple prefixes have at least the same information for guiding source address selection as a host which is directly connected to multiple networks with multiple interfaces. - Mark On Mar 4, 2013, at 9:09 AM, Teco Boot wrote: Reading the homenet-arch, I can't find how multi-addressed hosts are guided to prefer one address over another. I think such facility is beneficial in multi-homed homenets. Teco Op 12 feb. 2013, om 16:00 heeft Ray Bellis het volgende geschreven: This email marks the commencement of Working Group Last Call for draft-ietf-homenet-arch-07. The WGLC will end on Monday March 4th. Ray and Mark. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Working Group Last Call for draft-ietf-homenet-arch-07
Reading the homenet-arch, I can't find how multi-addressed hosts are guided to prefer one address over another. I think such facility is beneficial in multi-homed homenets. Teco Op 12 feb. 2013, om 16:00 heeft Ray Bellis het volgende geschreven: This email marks the commencement of Working Group Last Call for draft-ietf-homenet-arch-07. The WGLC will end on Monday March 4th. Ray and Mark. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Working Group Last Call for draft-ietf-homenet-arch-07
Teco, Reading the homenet-arch, I can't find how multi-addressed hosts are guided to prefer one address over another. I think such facility is beneficial in multi-homed homenets. the intention is to propagate the SAS/DAS policy given with draft-ietf-6man-addr-select-opt, and more specific routes learn on the border, combined with source address dependent forwarding. as well as rule 5.5 of 6724. that's in solution space though. there is already a reference to the multihoming-without-ipv6nat document. do you have ideas of anything else we should add to the architecture document? cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Working Group Last Call for draft-ietf-homenet-arch-07
As requested I have read draft-ietf-homenet-arch-07. Thanks everyone for the effort so far. IMHO I think the document is in very good shape, but that we're not quite there yet (which I guess means I'm obliged to supply comments on why I think that's the case). The main thrust of my comments below is an underlying feeling that we haven't yet fully got a handle on the boundary at the ISP/customer interface the homenet/Internet interface, and that this will bite us later. I also think there's quite a bit of room to tighten up on nomenclature. e.g. home network v. homenet. ISP uplink v. Customer Internet connections. Border v. CER v. Border CER. Perhaps rather surprisingly, homenet is not defined anywhere. regards, RayH Detailed comments === Section 1 s/While at the time of writing some complex home network topologies exist, but most are/ While at the time of writing some complex home network topologies exist, most are / s/like to avoid such/like to avoid, such/ s/IPv6 with an eye/IPv6, with an eye/ s/can not be affected by new /cannot be modified by new / /[RFC6204] defines basic requirements for customer edge routers (CERs). The scope of this text is the internal homenet, and thus specific features on the CER are out of scope for this text./ I find this particular formulation confusing. Perhaps /[RFC6204] defined basic requirements for customer edge routers (CERs), which has recently been updated with the definition of requirements for specific transition tools on the CER in RFC 6204-bis [I-D.ietf-v6ops-6204bis] i.e. DS-Lite [RFC6333] and 6rd [RFC5969]. Such detailed specification of CER devices is considered out of scope of this architecture document, and we assume that any required update of the CER device specification as a result of adopting this architecture will be handled as separate and specific updates to these existing documents./ Section 1.1. /CER: Customer Edge Router. A border router at the edge of the homenet./ I regularly read Homenet BR or Border Router on this list used interchangeably with CER. Are they different? Equivalent? Or do we need to change our behaviour/definitions? This is my biggest worry. Do we have a good handle on the interface at the border? Does the set of End-User network(s) in Section 3 map 1:1 with a homenet? I don't think so: it includes the CER. What is a Service Provider Network? The rest of the Internet that isn't in the homenet? Wouldn't harm to copy some more definitions from 6204. Section 2.1 s/This is discussed later in the document./This is discussed in Section 3.7./ /border router(s)/ See comment on 1.1 Border Router v Customer Edge Router? /There will also be the need to discover which routers in the homenet are the border router(s) by an appropriate mechanism. Here, there are a number of choices. These include an appropriate service discovery protocol, or the use of a well-known name, resolved by some local name service. Both might have to deal with handling more than one router responding in multihomed environments./ Above paragraph does not make sense to me. Seems to be a context shift in the middle of the paragraph. How is a name service related to discovery of a border router? We're not suggesting all CER's have to be called a particular hostname? /2.2. Global addressability and elimination of NAT/ Strictly speaking, NAT won't be eliminated entirely. IPv4 will still use NAT. IPv6 never had NAT. How about just /2.2. Global addressability/ s/The end-to-end communication that is potentially enabled with IPv6/ The possibility for direct end-to-end communication on the Internet that will be restored by the introduction of IPv6/ The Internet architecture always was, and still is, direct end-to-end communication. We just temporarily lost the ability to do it due to lack of addresses. s/on the firewall/ on any firewall/ Section 2.3 s/Default Address Selection for IPv6[I-D.ietf-6man-rfc3484bis]/ Default Address Selection for Internet Protocol Version 6 (IPv6) [RFC6724]/ s/We discuss such challenges in multihoming later in this document./ We discuss such challenges of multihoming in Section 3.3.1./ Section 2.4 s/Despite this counter-argument, while setting a network up there may be a period with no connectivity/ /pDespite this counter-argument, there may be a period with no connectivity while setting up a network/ s/when the ULA destination lies within a /48 ULA prefix known to be used within the same homenet./ when the ULA source and destination addresses lie within a single /48 ULA prefix known to be used within the same homenet. However, it should be noted that even if it were known that multiple /48 ULA prefixes are in use within a single homenet (perhaps because multiple homenet routers each independently auto-generate a /48 ULA prefix and then share routing information), utilising a ULA source address and a ULA destination address from two disjoint /48 ULA prefixes is not preferred
Re: [homenet] Working Group Last Call for draft-ietf-homenet-arch-07
I went through the draft, and noticed an instance of the word hoemnet in section 2.4. Otherwise I think this is now in good shape for publication. Regards Brian On 12/02/2013 15:00, Ray Bellis wrote: This email marks the commencement of Working Group Last Call for draft-ietf-homenet-arch-07. The WGLC will end on Monday March 4th. Ray and Mark. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
