Hi Markus, Thank you for the comments. In the Homenet scenario you described, I agree on the substance with what you wrote - if the router can do such formation of explicit PVDs, it should do that to prevent mix-up of configuration. Such text can be added into the section 4, example network configuration and number of PVDs. That said, I don't think it contradicts to 2.3, because Implicit PVDs by definition in 2.2. apply only when there the network is non-PVD aware:
<Quote> It is likely that for a long time there may be networks which do not advertise explicit PVD information, since deployment of any new features in networking protocols is a relatively slow process. When connected to networks, which don't advertise explicit PVD information, PVD-aware node shall automatically create separate PVDs for received configuration. Such PVDs are referred to in this document as "implicit". </quote> So from the host perspective, presence of a router, which can/does advertise PVDs, makes it a scenario with explicit PVDs, and not implicit ones. >>, I don't see the point in non-explicit PVDs coming _to_ hosts except perhaps >>in case of IPv4 My understanding, is that the main reason we introduced the notion of implicit PVD is to be able to handle configurations received on multiple interfaces (which typically are connected to different networks) in the same way as in the case of multiple explicit PVDs, basically to unify and simplify conceptual host implementation. The acknowledged limitation is that we don't know well how to form multiple implicit PVDs on one interface (or form implicit PVDs, spanning multiple interface). >> Also, I'd just rather treat PVD-bind as per-interface or per-address one; if >> we can determine packet doesn't belong to it (outside the application), >> application shouldn't know, and remote node shouldn't know application is >> listening to some other PVD. So connection refused/equivalent. The current text is <quote> If the determined receiving PVD of the packet is not in the allowed subset of PVDs for the particular app/transport API object, the packet should be handled in the same way as if there were no listener (alternatives - error message 'administratively prohibited', or just refer to pre-PVD behavior for legacy behavior for interface-scoped binds). </quiote> It seems the case you described would be where the "allowed subset of PVDs" contains only one PVD. If you think the current text is not sufficient, can you please suggest the change? -Dmitry From: Markus Stenberg [mailto:markus.stenb...@iki.fi] Sent: Sunday, May 4, 2014 11:21 PM To: Dmitry Anipko Cc: Markus Stenberg; mif@ietf.org Subject: Re: [mif] I-D Action: draft-ietf-mif-mpvd-arch-01.txt On 4.5.2014, at 5.51, Dmitry Anipko <dmitry.ani...@microsoft.com<mailto:dmitry.ani...@microsoft.com>> wrote: This revision has changes supposed to address most comments made in London as well as agreed changes from Alper's and Ian's reviews. For reference topologies / propagation of PVD info through intermediate routers from ISP uplinks (e.g. Homenet) more changes are needed, it would be great to see more inputs / discussion on the list around that. After some thinking on this topic, I think that implicit PVDs noted on homenet edge towards ISPs have to be converted to explicit ones to be offered to clients, if no information is to be lost. At least in IPv6 case, IPv4 I'm not sure how it should be even handled, perhaps as fallback PVD-less potentially broken by two+ different NATs connectivity :p As a random example, during the weekend we had a discussion on IRC about some ISPs being sensitive about which source address is used with their DNS server. This information isn't currently propagated in the information available _from_ the ISPs explicitly (it's implicit by definition), yet for even homenet routers to work correctly if there's multiple upstream ISPs, the information needs to be available within the homenet (e.g. 'we got this delegated prefix and this DNS address, use them together') for the DNS resolution to work consistently. Obviously, this can be also fixed by the homenet routers and then presenting just themselves as DNS servers to the clients. As another random example, even if the ISP at end of 3G dongle isn't providing explicit PVD, implicit PVD information should be bundled into explicit one with the extra information available (in this case, that it is not wired connection and has speed roughly of X, perhaps). So I'm not really sure the text in 2.3 is that reasonable, because it seems to assume implicit PVDs are generated (only?) on hosts, but in case of homenet, I don't see the point in non-explicit PVDs coming _to_ hosts except perhaps in case of IPv4 (too much magic related to possibly more than one NAT needs to happen, and I'm not sure we really want to go there). Some other thoughts.. 5.2.3.1: Also, I'd just rather treat PVD-bind as per-interface or per-address one; if we can determine packet doesn't belong to it (outside the application), application shouldn't know, and remote node shouldn't know application is listening to some other PVD. So connection refused/equivalent. Cheers, -Markus
_______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif
