"Acee Lindem (acee)" <a...@cisco.com> writes: > Hi Lada, > > On 3/3/16, 8:01 AM, "Ladislav Lhotka" <lho...@nic.cz> wrote: > >>"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. > > Are there planned implementations required YANG models where only IPv4 or > IPv6 are supported? Maybe way off in the future, when you and I are both > sitting on a beach drinking beer there will be IPv6 only products but I > don’t see it happening soon. >
Maybe some experts in the embedded area could comment on this, but I believe in both 6LoWPAN and ZigBee IPv6-only networks are commonplace. > > >> >>> >>> - 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. > > I don’t disagree - but why are they grouped with the main RIB and infra > draft? Router Advertisement should be with the other RFC 4861 protocols. > It is out of place here. The idea is that any device that implements ietf-routing is required to support these configuration variables, which is what 4861 says. With a mechanism like Andy's packages we would have more flexibility, but for the time being the best solution seems to be to move RA stuff to a submodule. > > > >> >>> >>> - 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. > > Are there hosts that don’t support at least ECMP? I am not sure. If there is consensus that ECMP is really ubiquitous, then we can add it. > >> >>> >>> - 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? > > It is not but as long as we are changing the model, we might as well > handle the predominant use cases. My concern is that other groups may come up with their favourite cases. Any new stuff increases the likelihood that bugs or inadequacies will be discovered in the module after it is published, but then it will be a problem due to the draconian module update rules. So I'd prefer to keep this module really skinny. > > >> >>> >>> - 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. > > I guess we will discuss this in upstate call next week. However, no matter > what solution we come up with, it seems keeping the derived state closer > to intended/applied config is better. OK. Lada > > Thanks, > Acee > > >> >>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 > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
