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

["Acee Lindem (acee)" <[e-mail]>]

Hi Sasha, Martin, 

Just one clarification below. 

On 4/3/19, 7:05 AM, "Martin Bjorklund" <[e-mail]> wrote:

    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.

The way multiple alternatives are supported is via the existing RFC 8349 next-hop-list list.
This is keyed with an index. What the augmentation provides is a way to specify a
preference for each next hop so that either ECMP or primary/backup uses case can
be supported. It is clear I need to expand the descriptive text for these augmentations
in the draft-ietf-rtgwg-yang-rib-extend. 

Thanks,
Acee
    
    
    > 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.
    > ___________________________________________________________________________