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

[Linhui Sun <[e-mail]>]

Hi Andy,

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

Best,
Linhui

2016-07-12 18:31 GMT+08:00 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.
>
[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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/softwires
>