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

[Andy Wingo <[e-mail]>]

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 :)

Regards,

Andy