Martin, Lots of thanks for an interesting input.
I have noticed that Appendix A in RFC 8349<https://tools.ietf.org/html/rfc8349#appendix-A> defines the key for static IPv4 and IPv6 unicast routes as “destination-prefix”. draft-ietf-rtgwg- yang-rib-extend<https://tools.ietf.org/html/draft-ietf-rtgwg-yang-rib-extend-01> claims that it augments the model defined in 8349, therefore, to the best of my understanding, it uses the same key for station IPv4 and IPv6 unicast routes. At the same time Appendix A in this draft does not define any keys for the read-only RIB. Can you explain this controversy? Regards, and lots of thanks in advance, Sasha Office: +972-39266302 Cell: +972-549266302 Email: [email protected] -----Original Message----- From: Martin Bjorklund <[email protected]> Sent: Wednesday, April 3, 2019 1:34 PM To: Alexander Vainshtein <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: [netmod] Doubts about static routes in RFC 8349 Hi, Alexander Vainshtein <[email protected]<mailto:[email protected]>> wrote: [...] > 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 Note that the "route" list in the rib doesn't have any keys. This means that you can report several entries with the same destination prefix. So I think that this design is compatible with the MIB design. /martin ___________________________________________________________________________ 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
