Hi Sasha, Although we are providing the same or better functionality, we never had mimicking the RFC 4292 MIB structure as a requirement. IMO, this would be a mistake since SNMP doesn’t allow nesting of tables while YANG, OTOH, supports arbitrary nesting of schema. We really must exploit this key advantage in our models.
Thanks, Acee From: Alexander Vainshtein <[email protected]> Date: Wednesday, April 3, 2019 at 3:14 AM To: Acee Lindem <[email protected]>, Ladislav Lhotka <[email protected]> Cc: Routing WG <[email protected]>, "[email protected]" <[email protected]> Subject: RE: Doubts about static routes in RFC 8349 (was: Doubts about static routes in RFC 8022) Acee, Lots of thanks for a prompt response with a highly relevant pointer. I will read draft-ietf-rtgwg-yang-rib-extend<https://tools.ietf.org/html/draft-ietf-rtgwg-yang-rib-extend-01> and probably send more questions. Meanwhile, could you please explain the rationale for changing the data model that has been defined in RFC 4292 (where both the destination prefix and the next hop have been parts of the index in the appropriate MIB table) ? The side effect of this change is that it is not backward-compatible with multiple existing RFC 4292-compliant RIB implementations: - Retrieval of such a RIB using YANG requires a stateful mapper that merges multiple RIB entries with the same destination prefix and different “simple” NH into a single entry with the next-hop-list - Configuration of a single static route that uses the next-hop-list requires a mapper that splits such a list into multiple 4292-compliant routes (simpler than merge, but still non-trivial IMHO). Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: [email protected] From: Acee Lindem (acee) <[email protected]> Sent: Tuesday, April 2, 2019 7:45 PM To: Alexander Vainshtein <[email protected]>; [email protected] Cc: [email protected]; [email protected] Subject: Re: Doubts about static routes in RFC 8349 (was: Doubts about static routes in RFC 8022) Hi Sasha, You are correct that there is no per-next-hop preference in the current model. However, this is included in the augmentation in draft-ietf-rtgwg-yang-rib-extend. Thanks, Acee From: Alexander Vainshtein <[email protected]<mailto:[email protected]>> Date: Tuesday, April 2, 2019 at 9:53 AM To: Acee Lindem <[email protected]<mailto:[email protected]>>, Ladislav Lhotka <[email protected]<mailto:[email protected]>> Cc: Routing WG <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Doubts about static routes in RFC 8349 (was: Doubts about static routes in RFC 8022) Hi all, I have noticed that 8022 has been obsoleted by RFC 8349. But it has exactly the same problem. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: [email protected]<mailto:[email protected]> From: Alexander Vainshtein Sent: Tuesday, April 2, 2019 3:57 PM To: '[email protected]' <[email protected]<mailto:[email protected]>>; '[email protected]' <[email protected]<mailto:[email protected]>> Cc: '[email protected]' <[email protected]<mailto:[email protected]>>; '[email protected]' <[email protected]<mailto:[email protected]>> Subject: Doubts about static routes in RFC 8022 Importance: High Acee, Ladislav and all, I have serious doubts regarding the data model for static routes in RFC 8022. As I see it, the data model defined in this document does not support multiple routes with common destination, different next hops and different route preferences. This is because only route destination is considered as the key in the RIB in Appendix A of RFC 8022., while route preference is a per-route read-only leaf in the data model. In particular (and this was my original problem) , it is possible to configure a static route with multiple next hops (using the next-hop-list construct) using the data model defined in RFC 8022, but all the next hops in this construct would have the same preference. AFAIK, many (if not all) deployed implementations support ability to configure static routes with the same destination, different next hops and different preferences, so that one of these next hops would act as a protection of the other. For the reference, this problem does not exist in the standard MIB for the RIB (RFC 4292), because it includes both the route destination and its next hop in the list of indices in the corresponding MIB. What, if anything, did I miss? Regards, and lots of thanks in advance, Sasha Office: +972-39266302 Cell: +972-549266302 Email: [email protected]<mailto:[email protected]> ___________________________________________________________________________ This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. ___________________________________________________________________________ ___________________________________________________________________________ This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. ___________________________________________________________________________
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
