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

Mikael Abrahamsson <> Fri, 04 July 2014 07:07 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 009661B2C27 for <>; Fri, 4 Jul 2014 00:07:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.602
X-Spam-Status: No, score=-4.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id erbJsFpDAMZT for <>; Fri, 4 Jul 2014 00:07:36 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 035651B2C21 for <>; Fri, 4 Jul 2014 00:07:36 -0700 (PDT)
Received: by (Postfix, from userid 501) id 69B08A1; Fri, 4 Jul 2014 09:07:34 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1404457654; bh=cOXAgpUVtIvVHR/tavka3rUbYyzUx5Qj20JSh0MlHOQ=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=3SzWlukoSntIAavCHxBM0avPMG0GkNGyEe9+vQgp1Q93mQR/NMjnUOu2MK+l5bf5H ZYFs5tViUcauGYPBhPsx5vCgKkP7WcMkG+gGF6I/8P4iAbhQJysJ6a1Un5HgFwkae7 DOG59kr+pSGvs0bQR6UORVJgxy4+nVLCUkvmoYLM=
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6222E9F; Fri, 4 Jul 2014 09:07:34 +0200 (CEST)
Date: Fri, 4 Jul 2014 09:07:34 +0200 (CEST)
From: Mikael Abrahamsson <>
To: Dmitry Anipko <>
In-Reply-To: <>
Message-ID: <>
References: <> <>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: "" <>
Subject: Re: [mif] FW: I-D Action: draft-ietf-mif-mpvd-arch-02.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiple Interface Discussion List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 04 Jul 2014 07:07:38 -0000

On Fri, 4 Jul 2014, Dmitry Anipko wrote:

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


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

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 

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 

Mikael Abrahamsson    email: