Hi Lada, On 3/7/16, 8:45 AM, "Ladislav Lhotka" <lho...@nic.cz> wrote:
>"Acee Lindem (acee)" <a...@cisco.com> writes: > >> Hi Lada, >> >> On 3/4/16, 8:00 AM, "Ladislav Lhotka" <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. >> >> Okay - I’ve also heard requirements from an SP for access devices with >> only IPv6. However, is a separate module required for this? > >An IPv6-only system should not have IPv4-related nodes in the schema. As >I wrote, alternatives are > >(a) define features for individual address families >(b) include configuration of address families, and then use "when" >statements to control the schema. We have the ip-address type that supports both… Couldn’t we use this type and have the server simply return an error if a route is configured for an unsupported address family? Should the ietf-yang-types module be re-published with ip-address removed? I guess don’t see this as a major point. > >We also have to consider other families that may be added, even some >that don't exist yet. Agreed. These can be added through augmentation. > >> ietf-yang-types has the type ip-address supporting both AFs. Does >> supporting one or the other AF or both need to be enforced with separate >> modules? For IPv4, we are going to need to support IPv6 next-hops (refer >> to RFC 5549). >> >> >>> >>>> >>>> >>>>> >>>>>> >>>>>> - 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. >> >> But it says nothing about the organization of the YANG modules ;^) > >No, but currently there is no way to say that if module X is implemented, >then >module Y has to be implemented, too. > >> >>> 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. >> >> Why wouldn’t RA be in a separate draft with all the other RFC 4861 >> protocols? > >It could, and we could hope that some mechanism will be established later >for >specifying module dependencies and prerequisites. It's IMO needed >anyway. ARP and ACLs are also needed anyway, that doesn’t mean they need to be included in this draft. Acee > >Lada > >> >> >> >>> >>>> >>>> >>>> >>>>> >>>>>> >>>>>> - 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 >> > >-- >Ladislav Lhotka, CZ.NIC Labs >PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
