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

Dmitry Anipko <Dmitry.Anipko@microsoft.com> Sat, 10 May 2014 02:51 UTC

Return-Path: <Dmitry.Anipko@microsoft.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 737221A00FE for <mif@ietfa.amsl.com>; Fri, 9 May 2014 19:51:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gx0mNVU3_opF for <mif@ietfa.amsl.com>; Fri, 9 May 2014 19:51:53 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0242.outbound.protection.outlook.com [207.46.163.242]) by ietfa.amsl.com (Postfix) with ESMTP id EBE721A011D for <mif@ietf.org>; Fri, 9 May 2014 19:51:50 -0700 (PDT)
Received: from SN2PR03MB077.namprd03.prod.outlook.com (10.255.175.153) by SN2PR03MB079.namprd03.prod.outlook.com (10.255.175.155) with Microsoft SMTP Server (TLS) id 15.0.939.12; Sat, 10 May 2014 02:51:44 +0000
Received: from SN2PR03MB077.namprd03.prod.outlook.com ([169.254.14.84]) by SN2PR03MB077.namprd03.prod.outlook.com ([169.254.14.84]) with mapi id 15.00.0939.000; Sat, 10 May 2014 02:51:43 +0000
From: Dmitry Anipko <Dmitry.Anipko@microsoft.com>
To: Markus Stenberg <markus.stenberg@iki.fi>
Thread-Topic: [mif] I-D Action: draft-ietf-mif-mpvd-arch-01.txt
Thread-Index: AQHPZ0rueEqsYx5Jz0inW8N3612uOJsvyYyegAG8QgCAB5zvwA==
Date: Sat, 10 May 2014 02:51:43 +0000
Message-ID: <e423e57ead744358a5ee3361bcb2b15d@SN2PR03MB077.namprd03.prod.outlook.com>
References: <20140504034218.19850.94379.idtracker@ietfa.amsl.com> <41ec8ac06a624cc1b89756c3d89626f4@SN2PR03MB077.namprd03.prod.outlook.com> <CD22AA7E-C413-4043-9EC4-28117C495DF6@iki.fi>
In-Reply-To: <CD22AA7E-C413-4043-9EC4-28117C495DF6@iki.fi>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:80e0:ee43::2]
x-forefront-prvs: 02070414A1
x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(428001)(199002)(189002)(377454003)(51444003)(52024003)(45914002)(24454002)(21056001)(76576001)(15975445006)(19609705001)(81342001)(20776003)(99286001)(64706001)(50986999)(54356999)(80022001)(76176999)(15202345003)(74316001)(19625215002)(79102001)(81542001)(4396001)(99396002)(2656002)(76482001)(33646001)(87936001)(19300405004)(92566001)(86362001)(83072002)(85852003)(16236675002)(19580395003)(77982001)(46102001)(74662001)(101416001)(31966008)(19580405001)(74502001)(83322001)(24736002)(3826001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB079; H:SN2PR03MB077.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (: microsoft.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Dmitry.Anipko@microsoft.com;
Content-Type: multipart/alternative; boundary="_000_e423e57ead744358a5ee3361bcb2b15dSN2PR03MB077namprd03pro_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/mif/KNbXYOEfF7yFWOrWu1fgicf-Qt8
Cc: "mif@ietf.org" <mif@ietf.org>
Subject: Re: [mif] I-D Action: draft-ietf-mif-mpvd-arch-01.txt
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif/>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 10 May 2014 02:51:59 -0000

Hi Markus,

Thank you for the comments. In the Homenet scenario you described, I agree on the substance with what you wrote - if the router can do such formation of explicit PVDs, it should do that to prevent mix-up of configuration. Such text can be added into the section 4, example network configuration and number of PVDs. That said, I don't think it contradicts to 2.3, because Implicit PVDs by definition in 2.2. apply only when there the network is non-PVD aware:

<Quote>
   It is likely that for a long time there may be networks which do not
   advertise explicit PVD information, since deployment of any new
   features in networking protocols is a relatively slow process.

   When connected to networks, which don't advertise explicit PVD
   information, PVD-aware node shall automatically create separate PVDs
   for received configuration.  Such PVDs are referred to in this
   document as "implicit".
</quote>

So from the host perspective, presence of a router, which can/does advertise PVDs, makes it a scenario with explicit PVDs, and not implicit ones.

>>, I don't see the point in non-explicit PVDs coming _to_ hosts except perhaps in case of IPv4

My understanding, is that the main reason we introduced the notion of implicit PVD is to be able to handle configurations received on multiple interfaces (which typically are connected to different networks) in the same way as in the case of multiple explicit PVDs, basically to unify and simplify conceptual host implementation. The acknowledged limitation is that we don't know well how to form multiple implicit PVDs on one interface (or form implicit PVDs, spanning multiple interface).

>> Also, I'd just rather treat PVD-bind as per-interface or per-address one; if we can determine packet doesn't belong to it (outside the application), application shouldn't know, and remote node shouldn't know application is listening to some other PVD. So connection refused/equivalent.

The current text is
<quote>

  If the determined receiving PVD of the packet is not in the allowed

   subset of PVDs for the particular app/transport API object, the

   packet should be handled in the same way as if there were no listener

   (alternatives - error message 'administratively prohibited', or just

   refer to pre-PVD behavior for legacy behavior for interface-scoped

   binds).
</quiote>

It seems the case you described would be where the "allowed subset of PVDs" contains only one PVD. If you think the current text is not sufficient, can you please suggest the change?

-Dmitry

From: Markus Stenberg [mailto:markus.stenberg@iki.fi]
Sent: Sunday, May 4, 2014 11:21 PM
To: Dmitry Anipko
Cc: Markus Stenberg; mif@ietf.org
Subject: Re: [mif] I-D Action: draft-ietf-mif-mpvd-arch-01.txt

On 4.5.2014, at 5.51, Dmitry Anipko <Dmitry.Anipko@microsoft.com<mailto:Dmitry.Anipko@microsoft.com>> wrote:
This revision has changes supposed to address most comments made in London as well as agreed changes from Alper's and Ian's reviews.

For reference topologies / propagation of PVD info through intermediate routers from ISP uplinks (e.g. Homenet) more changes are needed, it would be great to see more inputs / discussion on the list around that.

After some thinking on this topic, I think that implicit PVDs noted on homenet edge towards ISPs have to be converted to explicit ones to be offered to clients, if no information is to be lost. At least in IPv6 case, IPv4 I'm not sure how it should be even handled, perhaps as fallback PVD-less potentially broken by two+ different NATs connectivity :p

As a random example, during the weekend we had a discussion on IRC about some ISPs being sensitive about which source address is used with their DNS server. This information isn't currently propagated in the information available _from_ the ISPs explicitly (it's implicit by definition), yet for even homenet routers to work correctly if there's multiple upstream ISPs, the information needs to be available within the homenet (e.g. 'we got this delegated prefix and this DNS address, use them together') for the DNS resolution to work consistently.  Obviously, this can be also fixed by the homenet routers and then presenting just themselves as DNS servers to the clients.

As another random example, even if the ISP at end of 3G dongle isn't providing explicit PVD, implicit PVD information should be bundled into explicit one with the extra information available (in this case, that it is not wired connection and has speed roughly of X, perhaps).

So I'm not really sure the text in 2.3 is that reasonable, because it seems to assume implicit PVDs are generated (only?) on hosts, but in case of homenet, I don't see the point in non-explicit PVDs coming _to_ hosts except perhaps in case of IPv4 (too much magic related to possibly more than one NAT needs to happen, and I'm not sure we really want to go there).

Some other thoughts..

5.2.3.1:

Also, I'd just rather treat PVD-bind as per-interface or per-address one; if we can determine packet doesn't belong to it (outside the application), application shouldn't know, and remote node shouldn't know application is listening to some other PVD. So connection refused/equivalent.

Cheers,

-Markus