Hi,
Alexander Vainshtein <alexander.vainsht...@ecitele.com> wrote: > 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”. Right (to be precise, the key is defined in the YANG models in section 8 and 9). > 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. Correct. > At the same time Appendix A in this draft does not define any keys > for the read-only RIB. > > Can you explain this controversy? Not sure there's a controversy. The static route list is how you configure static routes, and the RIB is the operational state of all routes (static and others). Two different things. The MIB had a single table to show routes and write routes. I don't think the persistency of the routes you wrote into the MIB was defined; perhaps these can be viewed as being "static". /martin > > > > Regards, and lots of thanks in advance, > > Sasha > > > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: alexander.vainsht...@ecitele.com > > > > -----Original Message----- > From: Martin Bjorklund <m...@tail-f.com> > Sent: Wednesday, April 3, 2019 1:34 PM > To: Alexander Vainshtein <alexander.vainsht...@ecitele.com> > Cc: a...@cisco.com; lho...@nic.cz; netmod@ietf.org; rt...@ietf.org > Subject: Re: [netmod] Doubts about static routes in RFC 8349 > > > > Hi, > > > > Alexander Vainshtein > <alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>> > 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 netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
