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

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 2 Apr 2019 13:53:11 +0000

Hi all,
I have noticed that 8022 has been obsoleted by RFC 8349. But it has exactly the same problem.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]

From: Alexander Vainshtein
Sent: Tuesday, April 2, 2019 3:57 PM
To: [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>
Cc: [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>
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: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]<mailto:[email-masked]>

___________________________________________________________________________

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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 2 Apr 2019 16:44:37 +0000

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 <[email-masked]>
Date: Tuesday, April 2, 2019 at 9:53 AM
To: Acee Lindem <[email-masked]>, Ladislav Lhotka <[email-masked]>
Cc: Routing WG <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Doubts about static routes in RFC 8349 (was: Doubts about static routes in RFC 8022)

Hi all,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Acee, Ladislav and all,

Office: +972-39266302
Cell:      +972-549266302

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 3 Apr 2019 07:13:02 +0000

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: +972-39266302
Cell:      +972-549266302

From: Acee Lindem (acee) <[email-masked]>
Sent: Tuesday, April 2, 2019 7:45 PM
To: Alexander Vainshtein <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: Doubts about static routes in RFC 8349 (was: Doubts about static routes in RFC 8022)

Hi Sasha,

From: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, April 2, 2019 at 9:53 AM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>, Ladislav Lhotka <[email-masked]<mailto:[email-masked]>>
Cc: Routing WG <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Doubts about static routes in RFC 8349 (was: Doubts about static routes in RFC 8022)

Hi all,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: Alexander Vainshtein
Sent: Tuesday, April 2, 2019 3:57 PM
To: [email-masked]' <[email-masked]<mailto:[email-masked]>>; [email-masked]' <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]' <[email-masked]<mailto:[email-masked]>>; [email-masked]' <[email-masked]<mailto:[email-masked]>>
Subject: Doubts about static routes in RFC 8022
Importance: High

Acee, Ladislav and all,

Office: +972-39266302
Cell:      +972-549266302

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 03 Apr 2019 12:33:45 +0200 (CEST)

Hi,

Alexander Vainshtein <[email-masked]> 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

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 3 Apr 2019 10:51:23 +0000

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?

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: Martin Bjorklund <[email-masked]>
Sent: Wednesday, April 3, 2019 1:34 PM
To: Alexander Vainshtein <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [netmod] Doubts about static routes in RFC 8349

Hi,

Alexander Vainshtein <[email-masked]<mailto:[email-masked]>> wrote:

[...]

>            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

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 03 Apr 2019 13:04:58 +0200 (CEST)

Hi,

Alexander Vainshtein <[email-masked]> wrote:
> 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.

> 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

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 3 Apr 2019 11:27:29 +0000

Martin,
Lots of thanks for a prompt response.

My reading of your response is that, if you need multiple static routes with the same destination but different next hops, you configure them as a single route with next-hop-list, but what you see when you retrieve the RIB may be multiple individual routes, each with its own simple next hop. Or it may be something else, since no keys have been defined in the read-only representation of the RIB.

Is my reading correct? 

Office: +972-39266302
Cell:      +972-549266302

-----Original Message-----
From: Martin Bjorklund <[email-masked]> 
Sent: Wednesday, April 3, 2019 2:05 PM
To: Alexander Vainshtein <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [netmod] Doubts about static routes in RFC 8349

Hi,

Alexander Vainshtein <[email-masked]> wrote:
> 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.

Correct.

> 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

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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 3 Apr 2019 11:29:00 +0000

Hi Sasha, Martin, 

Just one clarification below. 

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

    Hi,

    
    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

    

    /martin

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 3 Apr 2019 11:32:53 +0000

Hi Sasha, 

On 4/3/19, 7:27 AM, "Alexander Vainshtein" <[email-masked]> wrote:

    Martin,

    Is my reading correct?

No - you'd see a single route and next-hop-list with the alternatives when it is retrieved. 
 
Thanks,
Acee

    Office: +972-39266302
    Cell:      +972-549266302

    -----Original Message-----
    From: Martin Bjorklund <[email-masked]> 
    Sent: Wednesday, April 3, 2019 2:05 PM
    To: Alexander Vainshtein <[email-masked]>
    Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
    Subject: Re: [netmod] Doubts about static routes in RFC 8349
    
    Hi,

    
    Correct.

    

    /martin

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 3 Apr 2019 11:55:00 +0000

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 <[email-masked]>
Date: Wednesday, April 3, 2019 at 3:14 AM
To: Acee Lindem <[email-masked]>, Ladislav Lhotka <[email-masked]>
Cc: Routing WG <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Doubts about static routes in RFC 8349 (was: Doubts about static routes in RFC 8022)

Acee,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi Sasha,

Hi all,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Acee, Ladislav and all,

Office: +972-39266302
Cell:      +972-549266302

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 03 Apr 2019 13:56:47 +0200 (CEST)

"Acee Lindem (acee)" <[email-masked]> wrote:
> Hi Sasha, 
> 
> On 4/3/19, 7:27 AM, "Alexander Vainshtein"
> <[email-masked]> wrote:
> 
>     Martin,
>     My reading of your response is that, if you need multiple static
>     routes with the same destination but different next hops, you
>     configure them as a single route with next-hop-list, but what you see
>     when you retrieve the RIB may be multiple individual routes, each with
>     its own simple next hop. Or it may be something else, since no keys
>     have been defined in the read-only representation of the RIB.
>     
>     Is my reading correct?
> 

Do you think it would be a violation of the spec if an implementation
expanded this into several route entries?  If yes, is this specified?

/martin

>     > Alexander Vainshtein
>     > <[email-masked]<mailto:[email-masked]>>
>     > wrote:
>     > 
>     > 
>     > 
>     > [...]
>     > 
>     > 
>     > 
>     > > -          Retrieval of such a RIB using YANG requires a stateful
>     > > -          mapper that
>     > 
>     information which is

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 3 Apr 2019 12:20:48 +0000

Hi Martin, 

On 4/3/19, 7:57 AM, "Martin Bjorklund" <[email-masked]> wrote:

Normally, a given RIB client, e.g., static,  would install a single route with one or more next-hops in the global RIB. If present, multiple routes for the same destination would come from different RIB clients. The RIB active route the is the route with the lowest preference value (more preferred). Since the read-only lists do not have indices, I don't see how'd we'd enforce this. However, an implementation supporting any other structure would be highly irregular. 

Thanks,
Acee

    /martin

---

From: Yingzhen Qu <[email-masked]>
Date: Thu, 4 Apr 2019 16:56:01 +0000

Hi Martin,

I agree with what Acee explained. Theoretically it's possible that in operation state an implementation can expand this into several route entries, but that's not how typically a RIB is implemented. One reason is that it will make the routing table look up much harder and inefficient.

Thanks,
Yingzhen

-----Original Message-----
From: rtgwg [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Wednesday, April 03, 2019 5:21 AM
To: Martin Bjorklund <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [netmod] Doubts about static routes in RFC 8349

Hi Martin, 

    

Thanks,
Acee

    /martin

    >     > prefix.  So I think that this design is compatible with the MIB

_______________________________________________
rtgwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtgwg