Re: Opinion requested: Independent submission of draft-sarikaya-6man-sadr-overview-11

Philip Homburg <pch-ipv6-ietf-3@u-1.phicoh.com> Thu, 22 September 2016 09:01 UTC

Return-Path: <pch-bF054DD66@u-1.phicoh.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DBFD12D9EE for <ipv6@ietfa.amsl.com>; Thu, 22 Sep 2016 02:01:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
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 c6Gj9hR-NFkj for <ipv6@ietfa.amsl.com>; Thu, 22 Sep 2016 02:01:31 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo6-he.hq.phicoh.net [IPv6:2001:470:d16a:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id D3F7512D9D9 for <ipv6@ietf.org>; Thu, 22 Sep 2016 02:01:29 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1bmzsl-0000FtC; Thu, 22 Sep 2016 11:01:27 +0200
Message-Id: <m1bmzsl-0000FtC@stereo.hq.phicoh.net>
To: ipv6@ietf.org
Subject: Re: Opinion requested: Independent submission of draft-sarikaya-6man-sadr-overview-11
From: Philip Homburg <pch-ipv6-ietf-3@u-1.phicoh.com>
Sender: pch-bF054DD66@u-1.phicoh.com
In-reply-to: Your message of "Thu, 22 Sep 2016 05:33:22 +0000 ." <E87B771635882B4BA20096B589152EF643ED58F1@eusaamb107.ericsson.se>
Date: Thu, 22 Sep 2016 11:01:25 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/N7hIKr_zH0ss-9qu2A41S4QBmMs>
Cc: Suresh Krishnan <suresh.krishnan@ericsson.com>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Sep 2016 09:01:33 -0000

In your letter dated Thu, 22 Sep 2016 05:33:22 +0000 you wrote:
>Hi all,
>   The draft describing a problem space overview for Source Address Dependent 
>Routing and Source Address Selection for IPv6 Hosts available at
>
>https://tools.ietf.org/html/draft-sarikaya-6man-sadr-overview-11
>
>has been submitted through the Independent stream for publication.

I find this a rather confusing draft.

It seems to combine a number of ideas in a random way.

That starts in Section 2, where, at least to me, the scenarios appear in a
random order. For readability it would be nice if the most basic scenarios are
described first and gradually build up to more complex versions.

For me it helps to keep host behavior separate from router behavior. Trying
to think about all the complexity of hosts at the same time as thinking about
all the different ways to configure routers doesn't really help.

So it is best to focus on the host-router protocols and describe where they
are currently lacking.

Looking at the problem from a host point of view: source address selection is
to a large degree independent of next hop router selection. I.e., the
source address is selected first, and then with dest/src routing the source
is taken into account to select the next hop router.

I think it would help to make this split explicit in the draft. In simple
cases, source selection is almost trivial (two prefixes that are equivalent
from the perspective of the host), but next hop selection still requires
the source address.

In other cases, source address selection is complex, but doesn't really make
next hop selection more complex.

Based on this it is possible to define what information the host needs, both 
for source address selection and for next hop selection.

If I ignore source address selection for the moment, then in many cases
a host already has all the information it needs for dest/src routing.

Even in the redirect ping-pong case, the host can just extract the source
address from the copy of the original packet.

So in a lot of cases, there is no need to change bits on the wire, we just
need to redefine how hosts should behave.

Then what remains (as far as I know only the lack of a PIO option when a host
gets its address from DHCPv6) can be addressed.