"Yingzhen Qu (yiqu)" <y...@cisco.com> writes: > Hi Lada, > > For ECMP, we can actually define the next-hop as a list, so if there is > only one element in the list it¹s the simple next-hop case, and for ECMP > there are multiple elements in the list. RIB is more complete by adding > ECMP support.
We already had ECMP nexthops in rev. 16 (look for "multipath-entry"): https://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-16 They were removed along with other fancy next-hops in the interest of finishing this data model soon/ever. I still think ECMP can be easily added via augments, but if there is consensus that ECMP is really ubiquitous, we can put that stuff back, perhaps conditionally using a feature (as it was in rev. 16). Lada > > Thanks, > Yingzhen > > On 3/4/16, 5:00 AM, "netmod on behalf of Ladislav Lhotka" > <netmod-boun...@ietf.org on behalf of lho...@nic.cz> wrote: > >>"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 > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
