[mif] Review of mif-mpvd-arch-00

[Dmitry Anipko <[e-mail]>]

Ian thanks for the review.

Sorry for breaking the thread, the original message didn't make to my mailbox for some reason, so I'm replying to a copy-paste from the mailing list archive.

>>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.)

[danipko] OK, assuming there are no objections from the WG members.

>>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.

[danipko] In that scenario, is the expectation that hosts participate in a routing protocol?  Or you're talking about internal HG routers?

>>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)?

[danipko] I think both cases are possible.
In some scenarios existing today (e.g. tethering from a Phone to a Tablet) the configuration, which would be grouped into implicit PVDs, could be re-advertised to other hosts w/o explicit PVD marking. Since MPVD architecture doesn't prohibit such existing scenarios, on the final recepient the same configuration independently could be grouped into an implicit PVD.
Separately, if the re-advertising device is PVD-aware and is capable of forming explicit PVDs from the original implicit based on some OOB information I don't think this is prohibited, but I'm not sure we'd need to specify that either.

>>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.

[danipko] Correct, I will try to make the wording in 2.2 less confusing.

>>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.

[danipko] OK.

>>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.

[danipko] My understanding is that the principle is that the PVD-unaware client should be able to discard all PVD information. It doesn't necessarily mean that it discards the complete packet - e.g. if there is non-PVD information in the same packet. Depending on the protocol, the extension could be done in either way - either by adding PVD info together with non-PVD info into single packet, or by adding more PVD-only packets.
In either case, for that particular protocol, behavior of PVD-unaware client should not be affected. In terms of your example, I think it would be the former, not the latter. Can you elaborate on what you believe is the prolem with the former?

>>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.

[danipko] OK.

>>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.

[danipko] I think there may be confusing wording in the text, because I don't believe it was meant to say this. Can you point to the specific sentences, which you read in this way?

Thank you,
Dmitry