Hi, I have reviewed of the current draft. Overall, I think it’s a great document.
Below are some comments and questions. Cheers, Ian Section 2.1 It could be worth making the point that the specific mechanism by which a PvD is learnt is not related to the PvD itself. (i.e. that PvDs are globally scoped on the host and there is no 'DHCP learnt PvD table', 'RA learnt PvD table' etc.) Section 2.2 i) (Raised in London) For mobile, if there's a WLAN and a 4G bearer, then assuming that they are in different implicit PvDs is probably a good starting point. Likewise, it works for a HGW which is essentially a 2-port router (LAN side/WAN side). Where it breaks down is if the HGW is actually a multi-port router, which is the where the Homenet architecture is going. In this case, an upstream interface to the SP is one PvD, but the other interfaces (in all likelihood) belong to the same PvD. Could the logic for identifying implicit PvDs be improved for multi-port router? e.g. if routing advertisements from the same routing protocol (e.g. OSPF LSA with the same Area-ID) were received on more than one interface, these could be put into the same implicit PVD. There's probably some other mechanisms that could be used as well. ii) Do implicit PVDs only have local scope, or could they be advertised to other hosts (where they would be explicit)? Should these be at the interface level, or is finer granularity necessary (e.g. at the prefix level)? iii) Alignment between sections 2.2 and 2.3 (raised in London). 2.2 describes creating implicit PvDs for configuration raised on multiple interfaces. 2.3 states 'Implicit PVDs are limited to network configuration information received on a single interface.' I guess that the 2.3 wording is meant to be correct. Section 2.4 IMHO, It would be better to say 'locally generated with a high probability of being globally unique' rather than 'locally generated globally unique' as ensuring actual global uniqueness here is cumbersome and unnecessary. Section 3.3 "Extensions and RAs should be defined in such a manner than unmodified hosts (i.e. hosts not aware of PvDs) will continue to function as well as they did before the PvD information got added." Does this mean that (to use a DHCP example), if an IA_PD is received with some associated PvD information, and the client is not PvD aware, then it should ignore the PvD information and use the delegated prefix (which is how it would work if you sent multiple PDs at the moment), or should it discard PDs with PVD info altogether? I think it's got to be the second of the two, otherwise something that is currently a problem continues to be a problem. 3.4 By default, a configuration source SHOULD provide information related to all provisioning domains without expecting the client to select the PvD(s) it requires. Is the word 'select' correct in this sentence? In context, 'request' would be a better word. This section also implies that PVD information should be encoded in such a way that just the PVD info could be discarded, but the provisioned information is retained by the client. See 3.3 comment above. _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif
