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 <[email protected]>: > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/softwires >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
