Re: [mif] I-D Action: draft-ietf-mif-mpvd-arch-02.txt

[Markus Stenberg <[e-mail]>]

.. back from my vacation, also rereading from scratch.

On 8.7.2014, at 1.34, Dmitry Anipko <[e-mail]> wrote:
>>> 2.3. Does the current writing prohibit that multiple implicit PVDs are formed on a single interface, for instance if RAs are seen from two or more routers on the same link, each announcing non-overlapping address space and DNS resolvers? I would like to see a PVD being formed for each of these to also allow for source based routing to send packets / use each resolver depending on what source address based on these RAs are being used.
> IIRC the WG discussed this question on a couple of occasions, and my understanding of consensus is: while there is no intent to prohibit multiple implicit PvDs on an interface, there is no clear way how to enable the implicit PvDs with finer granularity either. The text was supposed to reflect such position by saying "By default, implicit PVDs are limited... If additional information is available to the host through mechanisms out of scope of this document, the host may form implicit PVDs with different granularity".  Do you think this needs more elaboration in the text? (such as e.g. including your example into that section; this may open questions though such as e.g., how to make sure that IPv6 & IPv4 from the same router do not end up in different PvDs)

Comments:

2.1/…/5.2.3.1: 

Is this meant to be IPv6-only? Because most typical hosts allow only one IPv4 address per interface, and that leads to NATs and all sorts of fun stuff. 2.5 refers to dual stack, and there’s references to IPv4, but e.g. 5.2.3.1 example using the address as determinant of PvD sounds bit stretched unless you really can provision multiple IP addresses for v4 too.

How is this supposed to work with IPv4, and say, 2 ISPs and one VPN connection? (I can guess, but document doesn’t really say.)

Diagram:

Host 
|
Router - ISP1
|
ISP2


2.2/2.3:

I’m still not happy with mixed mode definition in 2.2 - it explicitly _does_ limit to one implicit PvD per link. What’s wrong with IPv4/IPv6 PvDs being distinct in any case? Given good multi-PvD support, what’s the problem? Same thing with 2.3 too - why not have implicits be next hop based by default?

(Similarly in 2.5 - it seems to confuse interface and next hop :-p)

2.4:

Does the explicit PvD ID have to be really globally unique or just low chance of collision (like ULA or the implicit PvD)? Constructing one that is globally unique _and_ human readable may be tricky. Is there some construction here that (for average human) is human readable and guaranteed to be globally unique? FQDN or AS# or something derived from prefix do not really count here I think. And some combination of $MEGACORP and $SERVICE is not guaranteed to be unique either.

The point I’m trying to make is that e.g. ’LameISP SlowSpeed’ is human readable, but has just ’some’ global uniqueness guarantee. slowspeed.lamepsi.example.com can be made globally unique, but at expense of readability.

7.1: 

Not really serious comment as such, but I think there’s some heartwarming trust here towards ISP that actually uses ’trust’ mechanism with a customer not to do evil things ;-)

My nits:

2.3: s/one interfaces/one interface/

3.3: [refs to X and Y]

4: the section title is bit misleading I think - I’d just remove ‘and number of PVDs’

4.1/4.2: ‘- one’ - I’d just remove the -, or better yet, rework out the parentheses too..

Cheers,

-Markus