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

Linhui Sun <> Tue, 12 July 2016 11:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 445CE12D0F4 for <>; Tue, 12 Jul 2016 04:40:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1ZMunMsXtpJ8 for <>; Tue, 12 Jul 2016 04:40:40 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 913D912D095 for <>; Tue, 12 Jul 2016 04:40:39 -0700 (PDT)
Received: by with SMTP id o80so21580289wme.1 for <>; Tue, 12 Jul 2016 04:40:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eHs7RR/wTYNRGSBT6HjlUbMJg3IMg3VF3uuidjIGo8g=; b=JKeFnyCZ6mrbOYjpyoigkIyHo9jR5ksCxAroTO6deVAvwca+DW2A3NhUciGLuHmdeP slUdUi1zYE2bxcL9UhAGh3Mj1IEotKOTcWaRNBeVVkEMJjQtWphbWGEs7Cir+0fG/uDS jplHeAmWiRfSh4IpI7Zmng0nFcox0h1NHbBBkXRoCtGNRMx9PKPpudiyyYkI/sfsZDp9 hHSjHD7V8s8JSguKvy1XNIcsb1pw0XM4qDdp4LGfG9c2y/xMiDyuST2FfbqyAGB2s5gN mWdCUBmG3V2uP3Glm4C7vv4ar/0MXjPv7S+Fq6Hn4WGfrQsomirAQF4CDroKdHoGS8AZ V6Iw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eHs7RR/wTYNRGSBT6HjlUbMJg3IMg3VF3uuidjIGo8g=; b=CTe4pedstXodPAmfL6n4Fu6FH0uL8Q6/E9tS6ziVav8M6bKXtpohv/0WgKqYwXwqay 5y7XnjpWhKWba9O/XT0M4+h913DiEDdP8zdbmF70PEr0NNZnixjWB/i4wg8uSBF0F6iV weUN4azjntwgxsRPDm60+3UzewWK/e+zPY1zgdSUzM0fQ+rbmMoQuLM5p+mgyP9FqsD+ OipQQ3bljggu6pTxWF4nMUqIgohuyvrPV33H7EiH0q7Vln48j3bPln5k2KKxdLBxcTLV k3Asp1/d3yPDYGw9phuSkD96UkfrluW3Xkf6JA/+hyrhvs3zryh/hYZHdOIZMKvtz7/V acSA==
X-Gm-Message-State: ALyK8tImvIyD+KpfBLBiiNHmhrz4X6izboOpIFpthSQwjV7vHMh9KRWf+JE59O/nRDpNYmmYVSQKkP6RDHbvZA==
X-Received: by with SMTP id l202mr2874680wmg.6.1468323637892; Tue, 12 Jul 2016 04:40:37 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 12 Jul 2016 04:40:18 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Linhui Sun <>
Date: Tue, 12 Jul 2016 19:40:18 +0800
Message-ID: <>
To: Andy Wingo <>
Content-Type: multipart/alternative; boundary=001a1146f61eda19e105376ebc61
Archived-At: <>
Cc: Softwires WG <>
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: Tue, 12 Jul 2016 11:40:43 -0000

Hi Andy,

Thanks for your comments, please see my comments inline with [LH].


2016-07-12 18:31 GMT+08:00 Andy Wingo <>om>:

> 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
> 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.
[LH]: The YANG model just defines a manner to configure and maintain the
binding table. It does not restrict how you actually perform in the data
plane. The point here is that we use the IPv6 info of lwB4 as the list key
of the binding. IMHO, if there does not exist a situation that an IPv6 info
accounts for more than one binding entry, that would be OK.

> 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.
[LH]: It seems that you think this would be the situation that an IPv6 info
of lwB4 is corresponding to two or more binding entries. I don't know why
we need multiple IPv4 addresses for a single lwB4, but IMHO, if you do that
you can also allocate multiple IPv6 addresses to the lwB4. By doing this,
we can still have the guarantee that one IPv6 info is only mapping to an
individual binding entry.

> 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 :)
> Regards,
> Andy
> _______________________________________________
> Softwires mailing list