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

From: [email-masked]
Date: Wed, 06 Aug 2014 18:49:13 -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-03.txt
	Pages           : 22
	Date            : 2014-08-06

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

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

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: Thu, 7 Aug 2014 01:53:35 +0000

This revision should address the WGLC comments. If there are no additional comments, we'll do the language review (thanks Ian for the kind offer), and I'm following up with authors of the 2 IDs mentioned in the text, which have expired, for the proper replacements.

-Dmitry 

-----Original Message-----
From: mif [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, August 6, 2014 6:49 PM
To: [email-masked]
Cc: [email-masked]
Subject: [mif] I-D Action: draft-ietf-mif-mpvd-arch-03.txt

Abstract:

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.

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

---

From: GangChen <[email-masked]>
Date: Fri, 8 Aug 2014 15:41:57 +0800

Hello Dmitry,

I posted the questions in other two threads, but didn't get response.
Could you kindly consider following questions into WGLC comments

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-08-07 9:53 GMT+08:00, Dmitry Anipko <[email-masked]>:
> This revision should address the WGLC comments. If there are no additional
> comments, we'll do the language review (thanks Ian for the kind offer), and
> I'm following up with authors of the 2 IDs mentioned in the text, which have
> expired, for the proper replacements.
>
> -Dmitry
>

---

From: Dmitry Anipko <[email-masked]>
Date: Sun, 10 Aug 2014 03:23:34 +0000

Hi Gang,

for some reason I didn't receive the original email. 

My 2 cents on these questions: PVD architecture, among other things, enables a) consistent use of networking configuration and, in some cases, b) improves selection of the networking configuration. I think 1) below is about selection, while 2) is about consistent use.

For selection, if multiple PVDs advertise the same DNS suffix, there are 2 cases: 1.1 all these PVDs are not trusted, 1.2 some of the PVDs are trusted.
In 1.1, IMO the most reasonable minimal behavior would be to generally ignore the suffix for purposes of the PVD selection, since the information is not trusted. In 1.2, if there is only one such trusted PVD, then this information can be meaningfully used in the PVD selection process. If there is > 1 such trusted PVD, then it is either misconfiguration, or any of these multiple trusted PVDs can be equally used, as far as selection by the suffix is concerned, and other factors (cost, speed etc) may be decisive.

For consistency, I'm not sure I understand the concern: if the specific route happens to be associated with the PVD, which the host already decided to use, then that specific route will affect the route lookup process. If the specific route happens to be in a different PVD, then it will be ignored (same approach as with multiple default routes).

Let me know if this answers your question.

Thank you,
Dmitry

________________________________________
From: GangChen <[email-masked]>
Sent: Friday, August 08, 2014 12:41 AM
To: Dmitry Anipko
Cc: MIF Mailing List
Subject: Re: [mif] FW: I-D Action: draft-ietf-mif-mpvd-arch-03.txt

Hello Dmitry,

1)  Name resolution

2) next hop

BRs

Gang

---

From: GangChen <[email-masked]>
Date: Sun, 10 Aug 2014 15:47:21 +0800

Hi Dmitry,

Thank you for the feedback.

2014-08-10 11:23 GMT+08:00, Dmitry Anipko <[email-masked]>:
> My 2 cents on these questions: PVD architecture, among other things, enables
> a) consistent use of networking configuration and, in some cases, b)
> improves selection of the networking configuration. I think 1) below is
> about selection, while 2) is about consistent use.
>
> For selection, if multiple PVDs advertise the same DNS suffix, there are 2
> cases: 1.1 all these PVDs are not trusted, 1.2 some of the PVDs are trusted.
> In 1.1, IMO the most reasonable minimal behavior would be to generally
> ignore the suffix for purposes of the PVD selection, since the information
> is not trusted. In 1.2, if there is only one such trusted PVD, then this
> information can be meaningfully used in the PVD selection process. If there
> is > 1 such trusted PVD, then it is either misconfiguration, or any of these
> multiple trusted PVDs can be equally used, as far as selection by the suffix
> is concerned, and other factors (cost, speed etc) may be decisive.

RFC6731 doesn't carry PVD information. Let's assume int#1 and int#2 on
a PVD-aware node receive RDNSS Selection DHCPv6 Option and PVD
Container Option respectively. And both are trusted.

int#1 receives RDNSS Selection DHCPv6 Option with domain name of example.com
int#2 receives PVD-ID named as example.com.

As far as trust and suffix are concerned, should it be equally used?

> For consistency, I'm not sure I understand the concern: if the specific
> route happens to be associated with the PVD, which the host already decided
> to use, then that specific route will affect the route lookup process. If
> the specific route happens to be in a different PVD, then it will be ignored
> (same approach as with multiple default routes).

A network provision a PVD-aware node that targeting to 2001::1 should
only take int#1. However, the int#2 on the node receives RA carry
Route Information Option indicating 2001::1 with high priority.

Should the node ignore int#2 and select int#1?

Gang

---

From: Dmitry Anipko <[email-masked]>
Date: Wed, 13 Aug 2014 01:17:10 +0000

Hi Gang,

>> RFC6731 doesn't carry PVD information. Let's assume int#1 and int#2 on a PVD-aware node receive RDNSS Selection DHCPv6 Option and PVD Container Option respectively

Right, I was implying that the association with PvD is done in the ways defined in the respective documents, currently being worked on, such as the container option.

>>As far as trust and suffix are concerned, should it be equally used?

As I tried to describe in my previous mail, IMO the answer depends on the trust of the host to the individual PvD-IDs. See the arch draft section 7.2 for discussion of the trust to PvDs. If your concern specifically is about the case where both PvDs are trusted, and the question is which of the two PvDs in this case should be used for example.com destinations, we can add more text on that. IMO - perhaps the DHCP option should win since the admin has made explicit effort to provide RDNSS information, but probably either way may be fine given that the host trusts to both PvDs (and the choice can be based on other factors). 

>>A network provision a PVD-aware node that targeting to 2001::1 should only take int#1. However, the int#2 on the node receives RA carry Route Information Option indicating 2001::1 with high priority.

I don't think that the specific route should be a direct factor in PvD selection. Once a PvD is chosen due to other factors (cost/speed/connectivity tests/name based policies + trusted PvDs etc.), then within that PvD the specific route provides useful information. Across the PvDs, the specific routes are no different from default routes - there is no direct way to infer, which one is "better" or "makes more sense", since they are provisioned by different administrators, who may have completely different ideas of what is "better". 

-Dmitry

-----Original Message-----
From: GangChen [mailto:[email-masked]] 
Sent: Sunday, August 10, 2014 12:47 AM
To: Dmitry Anipko
Cc: MIF Mailing List
Subject: Re: [mif] FW: I-D Action: draft-ietf-mif-mpvd-arch-03.txt

Hi Dmitry,

2014-08-10 11:23 GMT+08:00, Dmitry Anipko <[email-masked]>:
> improves selection of the networking configuration. I think 1) below 
> is about selection, while 2) is about consistent use.
>
> ignore the suffix for purposes of the PVD selection, since the 
> information is not trusted. In 1.2, if there is only one such trusted 
> PVD, then this information can be meaningfully used in the PVD 
> selection process. If there is > 1 such trusted PVD, then it is either 
> misconfiguration, or any of these multiple trusted PVDs can be equally 
> used, as far as selection by the suffix is concerned, and other factors (cost, speed etc) may be decisive.

RFC6731 doesn't carry PVD information. Let's assume int#1 and int#2 on a PVD-aware node receive RDNSS Selection DHCPv6 Option and PVD Container Option respectively. And both are trusted.

> For consistency, I'm not sure I understand the concern: if the 
> specific route happens to be associated with the PVD, which the host 
> already decided to use, then that specific route will affect the route 
> lookup process. If the specific route happens to be in a different 
> PVD, then it will be ignored (same approach as with multiple default routes).

A network provision a PVD-aware node that targeting to 2001::1 should only take int#1. However, the int#2 on the node receives RA carry Route Information Option indicating 2001::1 with high priority.

Gang

>> This revision should address the WGLC comments. If there are no 
>> additional comments, we'll do the language review (thanks Ian for the 
>> kind offer), and I'm following up with authors of the 2 IDs mentioned 
>> in the text, which have expired, for the proper replacements.
>>
>> -Dmitry
>>
>> 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.
>>