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

Andy Wingo <> Wed, 13 July 2016 15:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 949C012D821 for <>; Wed, 13 Jul 2016 08:17:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2UTGAwMvsL6n for <>; Wed, 13 Jul 2016 08:17:55 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B4A7A12D795 for <>; Wed, 13 Jul 2016 08:17:55 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id B9EAD26064 for <>; Wed, 13 Jul 2016 11:17:54 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=from:to :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=sasl; bh=i0M+STU/FGY6Dp8cNaY7V3CRybM=; b=Zs3soa 6cygOER+WPrL3Z5j7JWEiXK89q9YiszfXCsQtUw/pPa4e2TLtUvXh0kAw2U7zfG5 hOE9Lo2wryDdFXO7ItlBeh8QWbR6qp5G0zfoKcUAO9xSgK/pdSkRVUwzABTdecE8 KiezIaFJDZj3gQoyxiiEEK2Lq0FaCkj0IyE/w=
Received: from (unknown []) by (Postfix) with ESMTP id B173E26063 for <>; Wed, 13 Jul 2016 11:17:54 -0400 (EDT)
Received: from rusty (unknown []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 0EAD826062 for <>; Wed, 13 Jul 2016 11:17:53 -0400 (EDT)
From: Andy Wingo <>
References: <>
Date: Wed, 13 Jul 2016 17:17:51 +0200
In-Reply-To: <> (Andy Wingo's message of "Tue, 12 Jul 2016 12:31:51 +0200")
Message-ID: <>
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: F8ABD430-490C-11E6-879D-28A6F1301B6D-02397024!
Archived-At: <>
Subject: Re: [Softwires] ietf-softwire: IPv4 + PSID primary key for lw4over6 binding
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: softwires wg discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Jul 2016 15:17:57 -0000

Hello list,

I reply to my own message since I have been spending time specifying an
implementation of this module recently on the AFTR side and I just can't
shake the thought that the YANG module organization is wrong.

_From the AFTR perspective_, identifying binding table entries by the B4
IPv6 address is the wrong thing.  It is not sufficient, it is not
necessary, and it is not appropriate.

Not sufficient: in the data plane, when encapsulating, you don't know
the B4 IPv6 address.  You identify the softwire by the IPv4+port.  You
can use this same strategy to identify the softwire in the decapsulation

Not necessary: Because you can identify the softwire by IPv4+PSID, and
because the binding table can be quite big (millions of entries), if you
can avoid duplicating this table just to allow binding table entries to
be looked up by IPv6, that would be good.  ietf-softwire seems to
require this reverse mapping; when a configuration agent gets a request
to set


to 1, you would need a table keyed by IPv6 address.

Not appropriate: consider, say we get this "set the PSID of the softwire
127:10:20:30:40:50:60:128 to 1" request, and we actually do manage to
locate the binding entry for this softwire.  To validate that the change
is consistent, we only need to do one thing: check that this
IPv4/PSID/psid-offset/psid-length doesn't overlap with any other
softwire.  We don't need to validate anything about the IPv6 address of
the softwire.  This again hints that it's the IPv4+PSID that should be
the key, and probably that within each IPv4 address, all softwires have
the same psid-offset/psid-length.  The natural way to identify and
manage softwires from an AFTR perspective is by IPv4 and PSID.

If the YANG module remains how it is, that's fine -- it just means that
we're going to have to serialize all changes through one part of the
configuration agent so that we can keep our IPv6->softwire mapping in
precise sync with the IPv4,port->softwire map used by the data plane.