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

From: [email-masked]
Date: Thu, 03 Jul 2014 17:54:57 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Multiple Interfaces Working Group of the IETF.

        Title           : Multiple Provisioning Domain Architecture
        Author          : Dmitry Anipko
	Filename        : draft-ietf-mif-mpvd-arch-02.txt
	Pages           : 21
	Date            : 2014-07-03

Abstract:
   This document is a product of the work of MIF architecture design
   team.  It outlines a solution framework for some of the issues,
   experienced by nodes that can be attached to multiple networks.  The
   framework defines the notion of a Provisioning Domain (PVD) - a
   consistent set of network configuration information, and PVD-aware
   nodes - nodes which learn PVDs from the attached network(s) and/or
   other sources and manage and use multiple PVDs for connectivity
   separately and consistently.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-arch/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mif-mpvd-arch-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-mif-mpvd-arch-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Dmitry Anipko <[email-masked]>
Date: Fri, 4 Jul 2014 00:59:23 +0000

The new revision addresses the comments made on the list, and has added examples in the section 4. Thanks Zhen Cao, Ian Farrer and Dapeng Liu for their contributions to the section 4.
 
________________________________________
From: mif <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: Thursday, July 03, 2014 5:54 PM
To: [email-masked]
Cc: [email-masked]
Subject: [mif] I-D Action: draft-ietf-mif-mpvd-arch-02.txt

Abstract:

_______________________________________________
mif mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mif

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 4 Jul 2014 09:07:34 +0200 (CEST)

> The new revision addresses the comments made on the list, and has added examples in the section 4. Thanks Zhen Cao, Ian Farrer and Dapeng Liu for their contributions to the section 4.

Hi,

I'm re-reading the document in its entirety, writing comments as I go 
along:

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.

2.4. Nit: I would like to see some commas in the second sentence for 
easier understanding, for instance:

"For implicit PVDs, the node assigns a locally generated, with a high 
probability of being globally unique, ID to each implicit PVD."

2.5 Nit grammar question (unsure):

"  For implicit PVDs, by default PVD-aware nodes shall including multiple 
IP families into single implicit PVD created for an interface."

Shouldn't that be "shall include"?

3.3 Nit: Up to this, PVDs have been all caps, now there is a "PvD" (unless 
the font/rendering combination in my browser is fooling my eyes). This is 
also in 3.4 and others. The entire document needs to be checked for this?

5.2.2 If an application chooses an explicit source address first, I would 
like to see the traffic sourced from that IP go out through the 
logical/physical interface that IP is associcated with. Example:

You have a PVD that is associcated with your physical ethernet connection 
and a VPN tunnel that goes over your WiFi Internet connection. So the host 
has two PVDs, one "Internet", and one "Corporate", where the Corporate one 
has two interfaces, one physical and one logical. If packets are sourced 
using the VPN based IP address, I would like to see packets src/dst based 
routed to go out the VPN connection and not go directly to the Corporate 
physical connection. So this is *after* source address selection has been 
done. As far as I can tell, there is no text about this.

5.2.3 Nit: "Internet" is a name, thus capital I. It's "Internet" in 5.3.

5.2.4. Nit: "Togetheer"

5.4. I feel 5.4 needs more text, at minimum stating that even though it's 
a known non-perfect solution with connection managers, this problem is out 
of scope for this document. The current text seems to say there is a 
problem, and then... nothing.

10. Nit: there is a " , " (space before comma" in the middle of 
"tampering" section. Both of the last two sections seems to be lacking a 
":" or a "." after the initial section identifier. "Rogue configuration 
source A compromised" for example.

Apart from this I feel the document is in good shape and I support its 
publication.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Dmitry Anipko <[email-masked]>
Date: Mon, 7 Jul 2014 22:34:46 +0000

Hello Mikael,

Thank you for reading the draft and providing feedback.

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

>>2.4. Nit: I would like to see some commas in the second sentence for easier understanding, for instance:
>>"For implicit PVDs, the node assigns a locally generated, with a high probability of being globally unique, ID to each implicit PVD."

Will do.

>>"  For implicit PVDs, by default PVD-aware nodes shall including multiple IP families into single implicit PVD created for an interface."

You're correct, will change.

>>3.3 Nit: Up to this, PVDs have been all caps, now there is a "PvD" (unless the font/rendering combination in my browser is fooling my eyes). This is also in 3.4 and others. The entire document needs to be checked for this?

Will change to PvD across the doc (since V doesn't map to a separate word).

>>5.2.2 If an application chooses an explicit source address first, I would like to see the traffic sourced from that IP go out through the logical/physical interface that IP is associcated with. Example:
>>You have a PVD that is associcated with your physical ethernet connection and a VPN tunnel that goes over your WiFi Internet connection. So the host has two PVDs, one "Internet", and one "Corporate", where the Corporate one has two interfaces, one >>physical and one logical. If packets are sourced using the VPN based IP address, I would like to see packets src/dst based routed to go out the VPN connection and not go directly to the Corporate physical connection. So this is *after* source address >>selection has been done. As far as I can tell, there is no text about this.

I'll add text, that if the application has explicitly specified a source address, then for the subsequent operations on the specified API object, a matching PvD should be used, provided that use of that PvD by that application is allowed by the host configuration.

>>5.2.3 Nit: "Internet" is a name, thus capital I. It's "Internet" in 5.3.

Will change.

>>5.4. I feel 5.4 needs more text, at minimum stating that even though it's a known non-perfect solution with connection managers, this problem is out of scope for this document. The current text seems to say there is a problem, and then... nothing.

My understanding is that the text starting with "Although connection managers solve some  connectivity problems, they rarely address the network selection problems.." was a reflection on that, with implication that the present draft shall improve the situation by providing to the hosts tools and guidance to make better network selection decisions. Will it address your comment if I add such sentence explicitly? 

>>10. Nit: there is a " , " (space before comma" in the middle of "tampering" section. Both of the last two sections seems to be lacking a ":" or a "." after the initial section identifier. "Rogue configuration source A compromised" for example.

Will add ":"s and fix the other thing.

-Dmitry

-----Original Message-----
From: Mikael Abrahamsson [mailto:[email-masked]] 
Sent: Friday, July 4, 2014 12:08 AM
To: Dmitry Anipko
Cc: [email-masked]
Subject: Re: [mif] FW: I-D Action: draft-ietf-mif-mpvd-arch-02.txt

Hi,

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.

2.4. Nit: I would like to see some commas in the second sentence for easier understanding, for instance:

"For implicit PVDs, the node assigns a locally generated, with a high probability of being globally unique, ID to each implicit PVD."

"  For implicit PVDs, by default PVD-aware nodes shall including multiple IP families into single implicit PVD created for an interface."

3.3 Nit: Up to this, PVDs have been all caps, now there is a "PvD" (unless the font/rendering combination in my browser is fooling my eyes). This is also in 3.4 and others. The entire document needs to be checked for this?

5.2.2 If an application chooses an explicit source address first, I would like to see the traffic sourced from that IP go out through the logical/physical interface that IP is associcated with. Example:

You have a PVD that is associcated with your physical ethernet connection and a VPN tunnel that goes over your WiFi Internet connection. So the host has two PVDs, one "Internet", and one "Corporate", where the Corporate one has two interfaces, one physical and one logical. If packets are sourced using the VPN based IP address, I would like to see packets src/dst based routed to go out the VPN connection and not go directly to the Corporate physical connection. So this is *after* source address selection has been done. As far as I can tell, there is no text about this.

5.2.4. Nit: "Togetheer"

5.4. I feel 5.4 needs more text, at minimum stating that even though it's a known non-perfect solution with connection managers, this problem is out of scope for this document. The current text seems to say there is a problem, and then... nothing.

10. Nit: there is a " , " (space before comma" in the middle of "tampering" section. Both of the last two sections seems to be lacking a ":" or a "." after the initial section identifier. "Rogue configuration source A compromised" for example.

Apart from this I feel the document is in good shape and I support its publication.

---

From: Markus Stenberg <[email-masked]>
Date: Tue, 15 Jul 2014 12:42:22 +0300

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

> 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 wa…

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

---

From: Dmitry Anipko <[email-masked]>
Date: Tue, 22 Jul 2014 01:35:26 +0000

Hello Markus,

Thank you for the comments.

>> 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.
Host 
|
Router - ISP1
|
ISP2
>> 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.)

[danipko] I think the text was written with the assumption in mind that different PvDs can provide different addresses, which should be the case in IPv6, and in some topologies with IPv4. If you have a proposal  that works for the topology you described, where presumably the Router performs address assignment (and does NATing?), please feel free to describe it. 

>> I'm still not happy with mixed mode definition in 2.2 - it explicitly _does_ limit to one implicit PvD per link.

[danipko] I will change the text to further clarify that multiple implicit are allowed.

>> What's wrong with IPv4/IPv6 PvDs being distinct in any case? Given good multi-PvD support, what's the problem?

[danipko] My understanding is that in order for things like DHCPv6 prefix policy option to work, the respective IPv4 and IPv6 connectivity need to be considered within a context of the single PvD. Having IPv4 and IPv6 from the same administrator to be in different PvDs seems to increase complexity, and e.g. break the scenario with the prefix policy, while the benefits of putting in different PvDs are unclear. Can you elaborate on why you think the default of putting IPv4 and IPv6 into separate implicit ones makes more sense than into single implicit one?

>> Does the explicit PvD ID have to be really globally unique or just low chance of collision (like ULA or the implicit PvD)?

[danipko]  IIRC there was a discussion in London on this question, but I don't believe there was any better proposal for the arch doc compared to the current wording. My 2 cents is that I would not object to change the current wording to something like "or otherwise, an ID with high probability of being unique", if that has consensus. For those types of PvD IDs (to be defined in a separate design doc), where the ID is tied to e.g. DNS suffix and a cert, global uniqueness would be assured through those means (an attacker can try to fake the ID, but it won't be trusted, and hence the PvD may be ignored by the host).

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

[danipko]  OK.

-Dmitry

-----Original Message-----
From: Markus Stenberg [mailto:[email-masked]] 
Sent: Tuesday, July 15, 2014 2:42 AM
To: Dmitry Anipko
Cc: Markus Stenberg; Mikael Abrahamsson; [email-masked]
Subject: Re: [mif] I-D Action: draft-ietf-mif-mpvd-arch-02.txt

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?

2.4:

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:

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

---

From: GangChen <[email-masked]>
Date: Wed, 23 Jul 2014 23:17:30 +0800

Hi Dmitry,

As we presented in MIF-HE, it's suggested to consider the relation of
MPVD and RFC6731, RFC4191.

I posted the message before on the list as the below for your information.

Is there any conclusion if PVD rules conflict with RFC6731 and RFC4191?

Two particular cases are:

1)  Name resolution

Let's say, host A receives RDNSS Selection DHCPv6 Option with domain
name of example.com on interface 1.
It also receives PVD-ID of example.com on interface 2.

If the host A makes query for a.example.com, which interface should be selected

2) next hop

draft-ietf-mif-mpvd-arch-01 states:

   For each obtained destination
   address, the node shall perform a next-hop lookup among routers,
   associated with that PVD.

BRs

Gang

2014-07-04 8:54 GMT+08:00, [email-masked] <[email-masked]>:
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>