Hi,
I’ve just posted an updated version of draft-ietf-softwire-yang. This has taken
quite some time to produce and is quite a significant update from -01.
The most notable changes in this version:
1, There are now 3 models as this follows intended function much more cleanly
than the previous approach:
* CE Model (MAP-E/T, lw4o6)
* BR Model (MAP-E/T, lw4o6)
* Common Model (groupings of functions used by CE and BR)
2, The CE model is now structured to work with the ietf-interfaces YANG model -
the softwire is defined as config for building a tunnel interface. This allows
us to use it for getting necessary configuration described in other models such
as ietf-routing. It is also in line with the way that the tunnel interface is
configured in CE devices.
3, Where there is duplication, configuration nodes have been removed in favour
of referencing other YANG models - e.g. referencing ietf-nat for NAT and PSID
configuration in the CE.
4, Better descriptions, improved counters and a lot of other little fix ups.
One question that the authors have been discussing is the approach to defining
‘binding’ type softwires (lw4o6, MAP EA=0). This is the current, relevant text
in Sec 2:
Within the BR and CE modules, the YANG "feature" statement is used to
distinguish which of the different softwire mechanism(s) is relevant
for a specific element's configuraiton. For each module, a choice
statement is included for either 'binding' or 'algorithmic'. Binding
is used for configuring Lightweight 4over6, whereas Algorithmic is
used for configuring MAP-T or MAP-E.
+---------------------+-----------+---------------+
| S46 Mechanism | ce-type? | data-plane? |
+---------------------+-----------+---------------+
| Lightweight 4over6 | binding | n/a |
| MAP-E | algorithm | encapsulation |
| MAP-T | algorithm | translation |
+---------------------+-----------+---------------+
A proposed change is to cover the ‘binding’ cases of MAP configuration here as
well - a suggestion for how this section could read is:
Within the BR and CE modules, the YANG "feature" statement is used to
distinguish which of the different softwire mechanism(s) is relevant
for a specific element's configuraiton. For each module, a choice
statement is included for either 'binding' or 'algorithmic'. Binding
is used for configuring Lightweight 4over6 or MAP with EA=0 (with or
without PSID) softwires (described in [RFC7597] Appendix A Examples 4
and 5). Algorithmic is used for MAP-T or MAP-E 'mesh' (EA>0, no
PSID) configuration.
+-------------------------------+-----------+---------------+
| S46 Mechanism | ce-type? | data-plane? |
+-------------------------------+-----------+---------------+
| Lightweight 4over6 / MAP EA=0 | binding | n/a |
| MAP-E Mesh | algorithm | encapsulation |
| MAP-T Mesh | algorithm | translation |
+-------------------------------+-----------+---------------+
Obviously, if we were to go this way, then other parts of the draft would need
to be updated in line.
As ever, any comments, suggestions etc. appreciated.
Thanks,
Ian
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires