"Acee Lindem (acee)" <a...@cisco.com> writes: > Hi Lada, NETMOD WG members, > > There are actually a number of changes that we would like to > see in the ietf-routing model: > > - Remove routing-instances since ietf-routing since it will be > “mounted” at different points in the device hierarchy dependent > on the device requirements.
Agreed. > > - Collapse it into one module supporting different address families > rather 3 modules (base, IPv4, and IPv6). This is possible, but we would have to introduce a mechanism for implementations supporting only one of them. It seems to me that it is easier to select modules for base + any combination of address families, and each family module inserts appropriate stuff to right places - and there is quite a bunch of them. What you are proposing probably means the (single) module would have if-features or whens in all those places. > > - Remove the ND (RFC 4861) Router Advertisement protocol since it > doesn’t need to be here. Well, RFC 4861 says: "A router MUST allow for the following conceptual variables to be configured by system management." So I don't think they can be considered optional. We could perhaps move them to a submodule so that they don't clutter the main module. > > - Support at least the next hop enhancements in > https://tools.ietf.org/html/draft-acee-rtgwg-yang-rib-extend-00 They can be added via augments, and many potential users of the routing module (hosts and simple routers) don't support them. > > - Include at least ECMP in the static route configuration. Same as in the previous case: ietf-routing provides a choice node for next-hops in both RIBs and static routes, and ECMP is explicitly mentioned as a candidate for augmentation. Why is it such a big a problem? > > - Structure consistent with the operational state recommendation. > Even w/o having the final recommendation, this model seems to > branch between config and state at way too high a level. Could you outline the concrete changes that you propose here? The most significant part of state data in this module is the list of RIBs, and I don't see any way how it can be bundled with configuration somewhere deeper in the hierarchy. Lada > > Thanks, > Acee > > > On 2/26/16, 8:36 AM, "netmod on behalf of Ladislav Lhotka" > <netmod-boun...@ietf.org on behalf of lho...@nic.cz> wrote: > >>Hi, >> >>as a part of synchronization of the routing data models that are being >>developed by the NETMOD and RTG working groups, the authors of >>draft-ietf-netmod-routing-cfg propose to remove the routing-instance >>level in the data hierarchy, and leave it to structural-mount/YSDL to >>provide a top level structure. >> >>Schematically, the configuration and state data subtrees of ietf-routing >>would be reduced to something like this: >> >>module: ietf-routing >> +--ro routing-state >> | +--ro router-id? yang:dotted-quad >> | +--ro interfaces >> | | +--ro interface* if:interface-state-ref >> | +--ro routing-protocols >> | | +--ro routing-protocol* [type name] >> | | ... >> | +--ro ribs >> | +--ro rib* [name] >> | ... >> +--rw routing >> +--rw router-id? yang:dotted-quad >> +--rw description? string >> +--rw routing-protocols >> | +--rw routing-protocol* [type name] >> | ... >> +--rw ribs >> +--rw rib* [name] >> ... >> >>Are there any objections to this change? >> >>Thanks, >> >>Acee and Lada >> >>-- >>Ladislav Lhotka, CZ.NIC Labs >>PGP Key ID: E74E8C0C >> >> >> >> >>_______________________________________________ >>netmod mailing list >>netmod@ietf.org >>https://www.ietf.org/mailman/listinfo/netmod > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
