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.
- Opinion requested: Independent submission of draf… Suresh Krishnan
- Re: Opinion requested: Independent submission of … Philip Homburg
- Re: Opinion requested: Independent submission of … Suresh Krishnan
- Re: Opinion requested: Independent submission of … Philip Homburg
- Re: Opinion requested: Independent submission of … Mikael Abrahamsson
- Re: Opinion requested: Independent submission of … Brian E Carpenter
- Re: Opinion requested: Independent submission of … Suresh Krishnan