Re: [netmod] Doubts about static routes in RFC 8349

[Martin Bjorklund <[e-mail]>]

Hi,


Alexander Vainshtein <[e-mail]> 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: [phone]
> 
> Cell:      [phone]
> 
> Email:   [e-mail]
> 
> 
> 
> -----Original Message-----
> From: Martin Bjorklund <[e-mail]>
> Sent: Wednesday, April 3, 2019 1:34 PM
> To: Alexander Vainshtein <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [netmod] Doubts about static routes in RFC 8349
> 
> 
> 
> Hi,
> 
> 
> 
> Alexander Vainshtein <[e-mail]<mailto:[e-mail]>> 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.
> ___________________________________________________________________________