Re: [netmod] Doubts about static routes in RFC 8349 (was: Doubts about static routes in RFC 8022)

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

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 <[e-mail]>
Date: Wednesday, April 3, 2019 at 3:14 AM
To: Acee Lindem <[e-mail]>, Ladislav Lhotka <[e-mail]>
Cc: Routing WG <[e-mail]>, "[e-mail]" <[e-mail]>
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: [phone]
Cell:      [phone]
Email:   [e-mail]

From: Acee Lindem (acee) <[e-mail]>
Sent: Tuesday, April 2, 2019 7:45 PM
To: Alexander Vainshtein <[e-mail]>; [e-mail]
Cc: [e-mail]; [e-mail]
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 <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, April 2, 2019 at 9:53 AM
To: Acee Lindem <[e-mail]<mailto:[e-mail]>>, Ladislav Lhotka <[e-mail]<mailto:[e-mail]>>
Cc: Routing WG <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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: [phone]
Cell:      [phone]
Email:   [e-mail]<mailto:[e-mail]>

From: Alexander Vainshtein
Sent: Tuesday, April 2, 2019 3:57 PM
To: '[e-mail]' <[e-mail]<mailto:[e-mail]>>; '[e-mail]' <[e-mail]<mailto:[e-mail]>>
Cc: '[e-mail]' <[e-mail]<mailto:[e-mail]>>; '[e-mail]' <[e-mail]<mailto:[e-mail]>>
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: [phone]
Cell:      [phone]
Email:   [e-mail]<mailto:[e-mail]>


___________________________________________________________________________

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.
___________________________________________________________________________