[Softwires] ietf-softwire: IPv4 + PSID primary key for lw4over6 binding

Andy Wingo <wingo@igalia.com> Tue, 12 July 2016 10:31 UTC

Return-Path: <wingo@igalia.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 71BBF12D0DB for <softwires@ietfa.amsl.com>; Tue, 12 Jul 2016 03:31:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id p4R0v2tjWe6l for <softwires@ietfa.amsl.com>; Tue, 12 Jul 2016 03:31:57 -0700 (PDT)
Received: from sasl.smtp.pobox.com (pb-sasl1.pobox.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8202412B017 for <softwires@ietf.org>; Tue, 12 Jul 2016 03:31:57 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown []) by pb-sasl1.pobox.com (Postfix) with ESMTP id 5B80620566 for <softwires@ietf.org>; Tue, 12 Jul 2016 06:31:55 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to :subject:date:message-id:mime-version:content-type; s=sasl; bh=P 4k9W9sYrDcLPoZMzCKpaECJJ88=; b=gKgVSpZfyiiLH+2UtkHWzNHyjtQA8Cek8 gOHOQf3oEuCBaZbZfmkTh/JT7H50jKPjmf4JMdE/2SwhFyObop0BUUoBLSETq7WY EwGepIJ2Wz9CP7IxBseFtDmyF9F+EvM7AzvbFGrDKl9xMGQewAEWiNC4XwTz+ZoQ sF0BtavA0c=
Received: from pb-sasl1.nyi.icgroup.com (unknown []) by pb-sasl1.pobox.com (Postfix) with ESMTP id 3FE0F20564 for <softwires@ietf.org>; Tue, 12 Jul 2016 06:31:55 -0400 (EDT)
Received: from rusty (unknown []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pb-sasl1.pobox.com (Postfix) with ESMTPSA id 6B08720563 for <softwires@ietf.org>; Tue, 12 Jul 2016 06:31:54 -0400 (EDT)
From: Andy Wingo <wingo@igalia.com>
To: softwires@ietf.org
Date: Tue, 12 Jul 2016 12:31:51 +0200
Message-ID: <877fcrcfl4.fsf@igalia.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Pobox-Relay-ID: DA531850-481B-11E6-966A-C1836462E9F6-02397024!pb-sasl1.pobox.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/jBwMPUeSxF9zCfJCl-iLiTvcPKg>
Subject: [Softwires] ietf-softwire: IPv4 + PSID primary key for lw4over6 binding
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/softwires/>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Jul 2016 10:31:59 -0000

Hello list,

I have a change request for the draft-sun-softwire-yang-05 Internet
Draft that defines a standard YANG model for lightweight 4-over-6
binding tables.

This is my first post here, so allow me to introduce myself.  Together
with some colleagues at Igalia we have made an open source
implementation of the AFTR component of a lightweight 4-over-6
deployment based on the Snabb toolkit for building software switches and
other network functions.  This lwAFTR implementation is gradually
wending its way upstream to https://github.com/snabbco/snabb.

To take a packet and look up a softwire in the binding table, the AFTR
only has to look at one thing: the combination of the IPv4 address and
port.  In the encapsulation direction you get this directly from the L3
header.  In the decapsulation direction you get it from the encapsulated
payload.  When decapsulating you also have to check that the B4 and BR
addresses match the entries in the table, but you don't have to maintain
a separate table that maps IPv6 B4 address to softwire: you just have
the one IPv4+PSID-to-softwire table, along with a little side table that
can map IPv4+port to PSID.

OK, cool.  Just one table, great.  However, draft-sun-softwire-yang-05
specifies a different hierarchy:

  module: ietf-softwire
     +--rw softwire-config
        +--rw binding {binding}?
           +--rw br {br}?
              +--rw enable?                          boolean
              +--rw br-instances
                 +--rw br-instance* [id]
                    +--rw binding-table-versioning
                    |  +--rw binding-table-version?  uint64
                    |  +--rw binding-table-date?     yang:date-and-time
                    +--rw id                         uint32
                    +--rw name?                      string
                    +--rw softwire-num-threshold     uint32
                    +--rw tunnel-payload-mtu         uint16
                    +--rw tunnel-path-mru            uint16
                    +--rw binding-table
                       +--rw binding-entry* [binding-ipv6info]
                          +--rw binding-ipv6info     union
                          +--rw binding-ipv4-addr    inet:ipv4-address
                          +--rw port-set
                          |  +--rw psid-offset       uint8
                          |  +--rw psid-len          uint8
                          |  +--rw psid              uint16
                          +--rw br-ipv6-addr         inet:ipv6-address
                          +--rw lifetime?            uint32

This is figure 2 from section 5.2 (Lightweight 4over6 Tree Diagrams).
This YANG schema would make it necessary to map from B4 address to
softwire in some cases, which would be inefficient and not necessary
from a data-plane point of view.

Additionally, this mapping prevents one B4 from having multiple
softwires.  It seems to me that one CPE could very well have multiple
slices of IPv4 addresses.

Lightweight 4-over-6 maps a part of the IPv4 space to a set of B4s in
such a way that one IPv4+port pair will map to one B4, but the reverse
of that is not necessarily true: one B4 may map to many IPv4+port
pairs.  The natural way (to my mind) to implement a lwAFTR is to key
your table by IPv4+PSID or IPv4+port, and I think that's probably the
most natural way to manage it too -- IPv4 is after all the scarce
resource.  Allowing one CPE to have multiple softwires can allow an
operator to dynamically add capacity for a customer, on-demand.

For all these reasons IMHO the binding-table subtree should look like:

           +--rw binding-table
              +--rw binding-ipv4* [ipv4-addr]
                 +--rw ipv4-addr            inet:ipv4-address
                 +--rw psid-offset          uint8
                 +--rw psid-len             uint8
                 +--rw binding-entry* [psid]
                    +--rw psid              uint16
                    +--rw binding-ipv6info  union
                    +--rw br-ipv6-addr      inet:ipv6-address
                    +--rw lifetime?         uint32

OK, I drew it how I like it ;) This is an additional restriction where
each IPv4 address corresponds in a one-to-one way with the "offset" and
"len" PSID parameters.  If this restriction is feasible, it is certainly
a simplification from the implementation point of view.  Otherwise if
you allow each entry to have its own offset and len parameters, when you
add a binding table entry it is difficult to validate that no other
entry overlaps with that new PSID without doing a binding-table lookup
for each port covered by that PSID.

Thoughts are very welcome :)