Subject: [netmod] static routes in draft-ietf-netmod-routing-cfg-15

From: Dean Bogdanovic <[email-masked]>
Date: Wed, 25 Jun 2014 13:51:29 +0000

Hi,

While reading routing-cfg, looking at the static route model
 augment "/rt:routing/rt:routing-instance/rt:routing-protocols/"
          + "rt:routing-protocol/rt:static-routes" {
      ...
      container ipv4 {
        description
          "Configuration of a 'static' pseudo-protocol instance
           consists of a list of routes.";
        list route {
          key "id";
          ordered-by "user";
          description
            "A user-ordered list of static routes.";
          leaf id {
            type uint32 {
              range "1..max";
            }
            description
              "Unique numeric identifier of the route.

               This value is unrelated to system-assigned 'id'
               parameters of routes in RIBs.";
          }

got confused that each static route is identified by an "id". Originally thought it could be metric, but after reading description, wasn't sure. 

Lada explained that the id is used in case same prefixes are configured, but have different metric. So why not use prefix and preference as unique identifier? One could even argue that the base spec only needs to use prefix as the key, and if an implementation supports multiple static routes for the same prefix they can extend as an optional feature.

There was an email exchange on this topic offline and we are curious what does the WG think about this "id"?

Dean

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 25 Jun 2014 18:47:47 +0200

> Lada explained that the id is used in case same prefixes are configured, but have different metric. So why not use prefix and preference as unique identifier? One could even argue that the base spe…

YANG needs to specify key(s) for configuration lists, so we have to do it for static routes in ietf-routing, and this key cannot be changed or augmented from other modules.

Under these conditions, I am afraid we don’t have any natural key(s) that would be universally acceptable. All systems use some additional parameters, be they called preference, metric or administrative distance, but the problem is that, depending on the system, they may be specified (i) per route, (ii) per destination prefix, or (iii) per protocol instance.

For Linux, the key would be the triple (dest. prefix, TOS, preference).

So, while I don’t like the “id” key at all, I don’t see what else could be done. On the other hand, static routes are usually not defined in excessive quantities, so an extra parameter probably doesn’t matter.

Another important thing to note is that the “id” parameter of routes in RIBs (state data) is unrelated to the “id” of static routes. It was added recently as a part of “harmonization” with I2RS RIB info model (state lists don’t have to have keys).    

Lada

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 25 Jun 2014 19:02:58 +0000

Lada,

> -----Original Message-----
> From: Ladislav Lhotka [mailto:[email-masked]]
> Sent: Wednesday, June 25, 2014 12:48 PM
> To: Dean Bogdanovic
> Cc: [email-masked]; Jeffrey (Zhaohui) Zhang
> Subject: Re: static routes in draft-ietf-netmod-routing-cfg-15
> 
> 
> > got confused that each static route is identified by an "id".
> Originally thought it could be metric, but after reading description,
> wasn't sure.
> >
> > Lada explained that the id is used in case same prefixes are
> configured, but have different metric. So why not use prefix and
> preference as unique identifier? One could even argue that the base spec
> only needs to use prefix as the key, and if an implementation supports
> multiple static routes for the same prefix they can extend as an
> optional feature.
> 
> YANG needs to specify key(s) for configuration lists, so we have to do
> it for static routes in ietf-routing, and this key cannot be changed or
> augmented from other modules.
> 
> Under these conditions, I am afraid we don't have any natural key(s)
> that would be universally acceptable. All systems use some additional
> parameters, be they called preference, metric or administrative distance,
> but the problem is that, depending on the system, they may be specified
> (i) per route, (ii) per destination prefix, or (iii) per protocol
> instance.

What's the difference between "route" ((i) above) and "destination prefix" ((ii) above)?
(iii) is irrelevant here - we're talking about "static-route", which is a "protocol instance" and does not need to be in the key for the static route entries.

> For Linux, the key would be the triple (dest. prefix, TOS, preference).

To me, routes with different TOS behavior could go into different RIBs; or, just put the TOS in the prefix part. Then you're left with (prefix, preference) - exactly what we were proposing as the key.

> 
> So, while I don't like the "id" key at all, I don't see what else could
> be done. On the other hand, static routes are usually not defined in
> excessive quantities, so an extra parameter probably doesn't matter.
> 
> Another important thing to note is that the "id" parameter of routes in
> RIBs (state data) is unrelated to the "id" of static routes. It was
> added recently as a part of "harmonization" with I2RS RIB info model
> (state lists don't have to have keys).

That's yet another separate discussion that is going on offline now. We'll loop back here when it's ready.

Jeffrey

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 26 Jun 2014 11:51:56 +0200

> What's the difference between "route" ((i) above) and "destination prefix" ((ii) above)?

Quagga can set distance either for a protocol

  distance <number>

or selectively

  distance <number> A.B.C.D/M

> (iii) is irrelevant here - we're talking about "static-route", which is a "protocol instance" and does not need to be in the key for the static route entries.

It is relevant. If we introduce preference as a route attribute in ietf-routing (as it is e.g. in JUNOS or BIRD), then implementations that don't have it (use only per-protocol distance) would be out of luck.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 26 Jun 2014 14:11:04 +0200

> Lada explained that the id is used in case same prefixes are configured, but have different metric. So why not use prefix and preference as unique identifier? One could even argue that the base spe…

Back to Dean's proposal. What I think we could do is this:

1. Add "preference" leaf to the configuration and state data of "routing-protocol".

2. Define a new feature, "route-prerefence" and a new route attribute, "preference", dependent on that feature.

So, systems supporting per-route preferences will support that feature and use "preference" under "routing-protocol" as the default value for routes originated by the protocol instance.
And systems having only pre-protocol administrative distance won't support the feature and will use "preference" under "routing-protocol" as the administrative distance.

That said, I think we still can't remove the "id" from static routes because:

- some systems allow routes with the same dest. prefix and preference to appear in the same routing table;

- future modules may define new attributes for route selection (e.g. ToS), but these cannot be used as a part of the list key once the key is defined in ietf-routing.

Lada

---

From: <[email-masked]>
Date: Thu, 26 Jun 2014 13:41:42 +0000

Hi,

Some comments inline

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Ladislav Lhotka
Sent: Thursday, June 26, 2014 14:11
To: Dean Bogdanovic; [email-masked]
Cc: Jeffrey (Zhaohui) Zhang
Subject: Re: [netmod] static routes in draft-ietf-netmod-routing-cfg-15

Dean Bogdanovic <[email-masked]> writes:

> Hi,
>
> While reading routing-cfg, looking at the static route model  augment 
> "/rt:routing/rt:routing-instance/rt:routing-protocols/"

[SLI] Yes but some routing protocol are using multiple sets of preference (external vs internal routes for example), why not letting preference configuration, state for the protocol to the protocol itself ?
For ISIS model, I defined preference and external-preference leafs.

2. Define a new feature, "route-prerefence" and a new route attribute, "preference", dependent on that feature.
[SLI]
Setting of preference for static routes is definitively a need for configuration

For the operational state of RIB, adding preference information to the route is also useful.
Regarding the operational state of RIB, what kind of RIB model do we expect ?
do we want to display all routes in RIB (from all sources), or only used ones (lowest preference) ? If we authorize implementors to push all available routes , may be there is a need for a new leaf
in route container to flag best routes.

Stephane

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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 26 Jun 2014 13:50:42 +0000

Lada,

> Sent: Thursday, June 26, 2014 5:52 AM
> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic
> Cc: [email-masked]
> Subject: RE: static routes in draft-ietf-netmod-routing-cfg-15
> 

I was asking the difference between "route" and "destination prefix". I guess a "route" means a particular entry (e.g. those with different nexthops or in a broader context - from different protcools) for a prefix. Is that correct?

> 
> > (iii) is irrelevant here - we're talking about "static-route", which
> is a "protocol instance" and does not need to be in the key for the
> static route entries.
> 
> It is relevant. If we introduce preference as a route attribute in ietf-
> routing (as it is e.g. in JUNOS or BIRD), then implementations that
> don't have it (use only per-protocol distance) would be out of luck.

We are talking about specifying static routes. If an implementation does not support multiple static route entries for the same prefix (e.g. using different nexthops), then the "preference" or whatever we call it would be a fixed value say 0. If the implementation does support that, then it must provide a preference for each entry.

Jeffrey

> > To me, routes with different TOS behavior could go into different RIBs;
> or, just put the TOS in the prefix part. Then you're left with (prefix,
> preference) - exactly what we were proposing as the key.
> >
> >>
> >> > There was an email exchange on this topic offline and we are
> curious
> >> what does the WG think about this "id"?
> >> >
> >> > Dean
> >> >
> >> >
> >>
> >> --

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 26 Jun 2014 14:06:26 +0000

Lada,

We have been talking about between two static route entries for the same prefix, say <10.0.0.0/24, nh1> and <10.0.0.0/24, nh2>, which one should be preferred.

While we used "preference" wording, that has nothing to do with the protocol "preference" or "admin distance".

All that we need, is to specify how to order those two entries (that are for the same prefix). Call it "metric" or whatever. Even "index" is better than "id".

But don't use that to order all static routes. Just use that to order static route entries for the same prefix. In other words, all the static route entries should be keyed on (prefix, index), not index alone.

Jeffrey

> Sent: Thursday, June 26, 2014 8:11 AM
> So, systems supporting per-route preferences will support that feature
> and use "preference" under "routing-protocol" as the default value for
> routes originated by the protocol instance.
> And systems having only pre-protocol administrative distance won't
> support the feature and will use "preference" under "routing-protocol"
> as the administrative distance.
> 
> - future modules may define new attributes for route selection (e.g.
> ToS), but these cannot be used as a part of the list key once the key is
> defined in ietf-routing.
> 
> Lada
> 
> 
> 
> >

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 26 Jun 2014 16:22:37 +0200

> I was asking the difference between "route" and "destination prefix". I guess a "route" means a particular entry (e.g. those with different nexthops or in a broader context - from different protcoo…

Destination prefix is one of the attributes of a route.

> We are talking about specifying static routes. If an implementation does not support multiple static route entries for the same prefix (e.g. using different nexthops), then the "preference" or what…

It makes little sense to introduce “preference” just for discriminating among configured static routes with the same destination prefix. Backup routes or multi-path routing can be configured using “next-hop-list”.

However, this doesn’t mean that each destination prefix must always be unique in the list of static routes. Future modules may introduce new static route attributes, e.g. for policy routing it could be “tos”, and then it would make a very good sense to configure multiple static routes with the same destination prefix but different ToS values.

While static routes can be augmented with a new parameter such as “tos”, such a parameter cannot be added to the list key.

Lada

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 26 Jun 2014 14:46:01 +0000

Lada,

> It makes little sense to introduce "preference" just for discriminating
> among configured static routes with the same destination prefix. Backup
> routes or multi-path routing can be configured using "next-hop-list".

If those all have the same "preference"/"weight"/"priority"/"whatever", sure use next-hop-list. But if you want to prefer nh1 over nh2, then you can either use different static route entries with "index", or as you said still use next-hop-list but give different priorities to each nexthop in the list.

Some implementations may prefer one way or another. If I take a step back and agree to simply use next-hop-list, then to me we can simply use prefix itself to identify the routes. More below.

> 
> However, this doesn't mean that each destination prefix must always be
> unique in the list of static routes. Future modules may introduce new
> static route attributes, e.g. for policy routing it could be "tos", and
> then it would make a very good sense to configure multiple static routes
> with the same destination prefix but different ToS values.

A better way would be to augment it so TOS becomes part of the prefix.

Jeffrey

> 
> While static routes can be augmented with a new parameter such as "tos",
> such a parameter cannot be added to the list key.

> Sent: Thursday, June 26, 2014 10:23 AM
> To: Jeffrey (Zhaohui) Zhang
> Cc: Dean Bogdanovic; [email-masked]
> >>>> it for static routes in ietf-routing, and this key cannot be
> changed
> >> or
> > I was asking the difference between "route" and "destination prefix".
> I guess a "route" means a particular entry (e.g. those with different
> nexthops or in a broader context - from different protcools) for a
> prefix. Is that correct?
> 
> > We are talking about specifying static routes. If an implementation
> does not support multiple static route entries for the same prefix (e.g.
> using different nexthops), then the "preference" or whatever we call it
> would be a fixed value say 0. If the implementation does support that,
> then it must provide a preference for each entry.
> 
> It makes little sense to introduce "preference" just for discriminating
> among configured static routes with the same destination prefix. Backup
> routes or multi-path routing can be configured using "next-hop-list".
> 
> However, this doesn't mean that each destination prefix must always be
> unique in the list of static routes. Future modules may introduce new
> static route attributes, e.g. for policy routing it could be "tos", and
> then it would make a very good sense to configure multiple static routes
> with the same destination prefix but different ToS values.
> 
> While static routes can be augmented with a new parameter such as "tos",
> such a parameter cannot be added to the list key.
> 
> Lada
> 
> >
> > Jeffrey
> >
> >>
> >> Lada
> >>
> >>>
> >>>>
> >>>> Another important thing to note is that the "id" parameter of
> routes
> >> in

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 26 Jun 2014 16:46:59 +0200

> For ISIS model, I defined preference and external-preference leafs.

Yes, that was the idea, and in fact other modules are also expected to add other attributes to static routes via augmentation, e.g. for policy routing. The whole point of this discussion is whether we can find a more natural key for the list of static routes.

> in route container to flag best routes.

The RIBs in the data model contain all routes, not only the active ones. How these RIBs are used is system-dependent.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 26 Jun 2014 16:57:57 +0200

Jeffrey, Dean,

we should move this long discussion towards some resolution. It might be helpful if you propose concrete changes to the current module(s).

Thanks, Lada

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 26 Jun 2014 15:01:07 +0000

Lada,

My proposal is to remove ID and just use prefix.
For future extensions like TOS, just augment to include TOS in the prefix.

Jeffrey

> Sent: Thursday, June 26, 2014 10:58 AM
> we should move this long discussion towards some resolution. It might be
> helpful if you propose concrete changes to the current module(s).
> 
> Thanks, Lada
> 
> > If those all have the same "preference"/"weight"/"priority"/"whatever",
> sure use next-hop-list. But if you want to prefer nh1 over nh2, then you
> can either use different static route entries with "index", or as you
> said still use next-hop-list but give different priorities to each
> nexthop in the list.
> >
> > Some implementations may prefer one way or another. If I take a step
> back and agree to simply use next-hop-list, then to me we can simply use
> prefix itself to identify the routes. More below.
> >
> >>
> >>>>>> preference as unique identifier? One could even argue that the
> base
> >>>> spec
> >>>>>> YANG needs to specify key(s) for configuration lists, so we have
> to
> >>>> do
> >>>>> That's yet another separate discussion that is going on offline
> now.
> >>>> We'll loop back here when it's ready.
> >>>>>
> >>>>> Jeffrey
> >>>>>
> >>>>>>
> >>>>>> Lada
> >>>>>>
> >>>>>>>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 27 Jun 2014 09:00:13 +0200

> For future extensions like TOS, just augment to include TOS in the prefix.

I do not understand how that would work / look like. Can you sketch
such a solution?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 27 Jun 2014 12:04:44 +0200

> For future extensions like TOS, just augment to include TOS in the prefix.

No way. ToS was just an example, other modules may add other parameters such as "preference" or "source-address". We can't expect the destination prefix to be unique.

One thing that *might* be possible is to have the following key in static routes:

  key "destination-prefix id"

It would be especially useful if optional keys are introduced in YANG 1.1 (see issue Y09). The "id" would then be used as an auxiliary distinguisher for routes that have the same destination-prefix, otherwise it could have the default value.

Lada

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 27 Jun 2014 11:46:30 +0000

Lada,

> Sent: Friday, June 27, 2014 6:05 AM
> No way. ToS was just an example, other modules may add other parameters
> such as "preference" or "source-address". We can't expect the
> destination prefix to be unique.

Things like "TOS", "source-address" could be considered as part of the prefix. In the base spec, we simply say the key is prefix. For a particular implementation that needs more than the plain old 32-bit or 128-bit v4/v6 address, they can augment that to include addition parameters in the prefix.

For things like "preferences", in an earlier email you were saying that you don't need multiple entries - you just need to have a nexthop list, so I was taking a step back and follow your argument.

For even more other things, please see below.

>   key "destination-prefix id"

That's exactly what I was proposing earlier (to consider preference/metric factors) but then I took a step back to follow your argument that for preference/metric king of things, using a nexthop list would work.

Now if there are even more complicated situations where it is not feasible to augment the prefix, yes we could use an "id" that is only relevant in the context of a particular prefix; however again that id (not the raw parameters behind the id) could be considered as part of the prefix. Therefore, for the base spec, using prefix itself works well and is preferred. An implementation may be able to simply use the base model, or may have to define their own extensions.

> 
> It would be especially useful if optional keys are introduced in YANG
> 1.1 (see issue Y09). The "id" would then be used as an auxiliary
> distinguisher for routes that have the same destination-prefix,
> otherwise it could have the default value.

That's another option, but I still prefer the base spec just uses the prefix.

Jeffrey

> >> > If those all have the same
> "preference"/"weight"/"priority"/"whatever",
> >> >> However, this doesn't mean that each destination prefix must
> always
> >> be
> >> >> On 26 Jun 2014, at 15:50, Jeffrey (Zhaohui) Zhang
> <[email-masked]>
> >> >> wrote:
> >> >>
> >> >>> Lada,
> >> >>>
> >> >>>>>> parameters, be they called preference, metric or
> administrative
> >> >>>> distance,
> >> >>>>> What's the difference between "route" ((i) above) and
> "destination
> >> >>>> prefix" ((ii) above)?
> >> >>>>
> >> >>>> It is relevant. If we introduce preference as a route attribute
> in
> >> >> ietf-
> >> >> using different nexthops), then the "preference" or whatever we
> call
> >> it
> >> >> However, this doesn't mean that each destination prefix must
> always
> >> be
> >> >>>>> To me, routes with different TOS behavior could go into
> different
> >> >> RIBs;
> >> >>>>>> So, while I don't like the "id" key at all, I don't see what
> else
> >> >>>> could
> >> >>>>>> be done. On the other hand, static routes are usually not
> defined
> >> >> in
> >> >>>>>> RIBs (state data) is unrelated to the "id" of static routes.
> It
> >> was

---

From: <[email-masked]>
Date: Fri, 27 Jun 2014 11:49:09 +0000

Hi,

I'm wondering if the current model for RIB is the right one. Maybe there was already discussions on this in the past, so sorry to come back to it , if it's the case ...

Currently the model is to have list of routes. Each route containing nexthop and prefix information.
So if I have the following routes :
10.0.0.0/8 ISIS preference 20, metric 100
10.0.0.0/8 OSPF preference 15, metric 500

I would have two route entries in routes with a single nexthop in it for each.

If I have :
10.0.0.0/8 Static nexthop 1
10.0.0.0/8 Static nexthop 2

I would have a single route entry with a nexthop-list.

This is not really displaying how RIBs are working today. Moreover it tends to mix how FIB works and how RIB works,  generally we have for RIB :
A single prefix entry followed by a list of paths : some are primary, some are protecting (LFA or MRT ...), some are only hidden path (less preferred protocol preference). When multipath is enabled, all primaries are used for Loadbalancing.

Why not using this model , so with the example, I would have a single route entry with next-hop-list as next-hop-options. Nexthop-list would have one primary nexthop, and one backup nexthop. Moreover I'm not sure about what "backup" means, especially if you have a FRR nexthop, would it be "backup" ? I think a new enum may be required for next-hop-classifiers to differentiate "hidden routes" (less preferred) from protecting routes (LFA ...), both are sort of backup routes ...

Using this system the key of routes can be the destination prefix.
Next-hop-content need then more to be a path-list.
To index path-list, all attributes may require to be taken into account.

Thoughts ?

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Ladislav Lhotka
Sent: Friday, June 27, 2014 12:05
To: Jeffrey (Zhaohui) Zhang
Cc: [email-masked]
Subject: Re: [netmod] static routes in draft-ietf-netmod-routing-cfg-15

Lada  

>> we should move this long discussion towards some resolution. It might 
>> be helpful if you propose concrete changes to the current module(s).
>> 
>> Thanks, Lada
>> 
>> On 26 Jun 2014, at 16:46, Jeffrey (Zhaohui) Zhang 
>> <[email-masked]>
>> wrote:
>> 
>> > Lada,
>> >
>> sure use next-hop-list. But if you want to prefer nh1 over nh2, then 
>> you can either use different static route entries with "index", or as 
>> you said still use next-hop-list but give different priorities to 
>> each nexthop in the list.
>> >
>> back and agree to simply use next-hop-list, then to me we can simply 
>> use prefix itself to identify the routes. More below.
>> >
>> >>
>> >> unique in the list of static routes. Future modules may introduce 
>> >> new static route attributes, e.g. for policy routing it could be 
>> >> "tos",
>> and
>> >>>>>> configured, but have different metric. So why not use prefix 
>> >>>>>> and preference as unique identifier? One could even argue that 
>> >>>>>> the
>> base
>> >>>> spec
>> >>>>>> multiple static routes for the same prefix they can extend as 
>> >>>>>> an optional feature.
>> >>>>>>
>> >>>>>> (i) per route, (ii) per destination prefix, or (iii) per 
>> >>>>>> protocol instance.
>> >>>>>
>> >> I guess a "route" means a particular entry (e.g. those with 
>> >> different nexthops or in a broader context - from different 
>> >> protcools) for a prefix. Is that correct?
>> >>
>> >>>> is a "protocol instance" and does not need to be in the key for 
>> >>>> the static route entries.
>> >>>>
>> >>>> routing (as it is e.g. in JUNOS or BIRD), then implementations 
>> >>>> that don't have it (use only per-protocol distance) would be out of luck.
>> >>>
>> >> would be a fixed value say 0. If the implementation does support 
>> >> that, then it must provide a preference for each entry.
>> >>
>> >> unique in the list of static routes. Future modules may introduce 
>> >> new static route attributes, e.g. for policy routing it could be 
>> >> "tos",
>> and

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 27 Jun 2014 14:50:39 +0200

> I would have a single route entry with a nexthop-list.

A system supporting the “multipath-routes” feature can use “next-hop-list” in its routes.

On the other hand, I assume that two routes with the same destination prefix obtained from different protocols will remain separate because they may be passed to a route filter and treated differently by it.

> This is not really displaying how RIBs are working today. Moreover it tends to mix how FIB works and how RIB works,  generally we have for RIB :

FIB (= table containing active routes) is not part of this data model because we also need to support systems such as Linux that uses route cache.

> Why not using this model , so with the example, I would have a single route entry with next-hop-list as next-hop-options. Nexthop-list would have one primary nexthop, and one backup nexthop. Moreover I'm not 

Because nobody proposed it so far.

> sure about what "backup" means, especially if you have a FRR nexthop, would it be "backup" ? I think a new enum may be required for next-hop-classifiers to differentiate "hidden routes" (less preferred) from protecting routes (LFA ...), both are sort of backup routes ...
> 

For lists in state data keys are optional.

Lada

---

From: <[email-masked]>
Date: Fri, 27 Jun 2014 13:21:58 +0000

> A system supporting the "multipath-routes" feature can use "next-hop-list" in its routes.

>On the other hand, I assume that two routes with the same destination prefix obtained from different protocols will remain >separate because they may be passed to a route filter and treated differently by it.

[SLI] Regarding route filters, I have one concern regarding the approach for multiple routes for the same prefix in route list.

Consider that you have a RIP learned route 10/8 at RtrX
RtrX has a "default RIP route-filter" to export RIP routes from connected RIB to RIP neighbors.

So it's expected that 10/8 learned RIB route is advertised to neighbors.

Now, I had a static route to 10/8 on RtrX with highest preference than RIP protocol.

The 10/8 is expected to not be exported anymore because only best routes can be exported from RIB and best route is not a RIP one.

That's why I found the model confusing to have different route entries for a specific destination. The notion of best path per destination is quite critical to be present in the model and we need to be able to retrieve all paths for a specific destination prefix.
The other way to do it, would be to add "active"/"best" leaf in the route list.

Best Regards,

Stephane

-----Original Message-----
From: Ladislav Lhotka [mailto:[email-masked]] 
Sent: Friday, June 27, 2014 14:51
To: LITKOWSKI Stephane SCE/IBNF
Cc: Jeffrey (Zhaohui) Zhang; [email-masked]
Subject: Re: [netmod] static routes in draft-ietf-netmod-routing-cfg-15

> I would have a single route entry with a nexthop-list.

A system supporting the "multipath-routes" feature can use "next-hop-list" in its routes.

> Why not using this model , so with the example, I would have a single 
> route entry with next-hop-list as next-hop-options. Nexthop-list would 
> have one primary nexthop, and one backup nexthop. Moreover I'm not

Lada 

>>> we should move this long discussion towards some resolution. It 
>>> might be helpful if you propose concrete changes to the current module(s).
>>> 
>>> Thanks, Lada
>>> 
>>> you can either use different static route entries with "index", or 
>>> as you said still use next-hop-list but give different priorities to 
>>>>>>>>>>      + "rt:routing-protocol/rt:static-routes" {  ...
>>>>>>>>>>  container ipv4 {
>>>>>>>>>>    description
> ______________________________________________________________________
> ___________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
> exploites ou copies sans autorisation. Si vous avez recu ce message 
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 27 Jun 2014 16:10:33 +0200

> The other way to do it, would be to add "active"/"best" leaf in the route list.

If I understand you correctly, you’d prefer to have a RIB as a list keyed with destination prefixes and each entry containing a list of routes for that prefix with the active route being tagged.

Lada

---

From: <[email-masked]>
Date: Fri, 27 Jun 2014 14:59:44 +0000

> If I understand you correctly, you'd prefer to have a RIB as a list keyed with destination prefixes and each entry containing a list of routes for that prefix with the active route being tagged.

[SLI] The major point is to be able to identify the easily the "route-type" : best, non best.

-----Original Message-----
From: Ladislav Lhotka [mailto:[email-masked]] 
Sent: Friday, June 27, 2014 16:11
To: LITKOWSKI Stephane SCE/IBNF
Cc: Jeffrey (Zhaohui) Zhang; [email-masked]
Subject: Re: [netmod] static routes in draft-ietf-netmod-routing-cfg-15

On 27 Jun 2014, at 15:21, <[email-masked]> <[email-masked]> wrote:

> Consider that you have a RIP learned route 10/8 at RtrX RtrX has a 
> "default RIP route-filter" to export RIP routes from connected RIB to RIP neighbors.
> 

If I understand you correctly, you'd prefer to have a RIB as a list keyed with destination prefixes and each entry containing a list of routes for that prefix with the active route being tagged.

Lada

>> route entry with next-hop-list as next-hop-options. Nexthop-list 
>> would have one primary nexthop, and one backup nexthop. Moreover I'm 
>> not
> 
>>>> sure use next-hop-list. But if you want to prefer nh1 over nh2, 
>>>> then you can either use different static route entries with 
>>>> "index", or as you said still use next-hop-list but give different 
>>>> priorities to each nexthop in the list.
>>>>> 
>>>> back and agree to simply use next-hop-list, then to me we can 
>>>> simply use prefix itself to identify the routes. More below.
>>>>> 
>>>>>> 
>>>>>>>>>> and preference as unique identifier? One could even argue 
>>>>>>>>>> that the
>>>> base
>>>>>>>> spec
>>>>>> does not support multiple static route entries for the same 
>>>>>> prefix
>>>> (e.g.
>>>>>>>>>> added recently as a part of "harmonization" with I2RS RIB 
>>>>>>>>>> info
>>>>>> model
>> _____________________________________________________________________
>> _ ___________________________________________________
>>

---

From: Dean Bogdanovic <[email-masked]>
Date: Fri, 27 Jun 2014 15:13:18 +0000

> [SLI] The major point is to be able to identify the easily the "route-type" : best, non best.

no, that is not a good idea. You can have protection and load balance preference. If you just use route-type best, then how will you do load balancing between different routes? You should be able to add weight to each route and based on that weight do load balancing between them.

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 27 Jun 2014 17:22:44 +0200

> no, that is not a good idea. You can have protection and load balance preference. If you just use route-type best, then how will you do load balancing between different routes? You should be able t…

This is I guess what the next-hop-list is intended for?

Lada

---

From: <[email-masked]>
Date: Fri, 27 Jun 2014 16:42:51 +0000

Weight is something else ...
And you need "best" flag as well as weight setting.
Maybe best is not a good name ... and active is better. When doing ECMP or UECMP, both are active with same weight (ECMP) or different weight (UECMP)

-----Original Message-----
From: Dean Bogdanovic [mailto:[email-masked]] 
Sent: Friday, June 27, 2014 17:13
To: LITKOWSKI Stephane SCE/IBNF
Cc: Ladislav Lhotka; Jeffrey (Zhaohui) Zhang; [email-masked]
Subject: Re: [netmod] static routes in draft-ietf-netmod-routing-cfg-15

>>> Why not using this model , so with the example, I would have a 
>>> single route entry with next-hop-list as next-hop-options. 
>>> Nexthop-list would have one primary nexthop, and one backup nexthop. 
>>> Moreover I'm not
>> 
>>>>>>> unique in the list of static routes. Future modules may 
>>>>>>> introduce new static route attributes, e.g. for policy routing 
>>>>>>> it could be "tos",
>>>>> and
>>>>>>> then it would make a very good sense to configure multiple 
>>>>>>> static
>>>>> routes
>>>>>>> While static routes can be augmented with a new parameter such 
>>>>>>> as
>>>>> "tos",
>>>>>>>>>>> On 25 Jun 2014, at 15:51, Dean Bogdanovic 
>>>>>>>>>>> <[email-masked]>
>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> Hi,
>>>>>>>>>>>> 
>>>>>>>>>>>> While reading routing-cfg, looking at the static route 
>>>>>>>>>>>> model augment "/rt:routing/rt:routing-instance/rt:routing-protocols/"
>>>>>>>>>>>>     consists of a list of routes.";  list route {
>>>>>>>>>>>>    key "id";
>>>>>>>>>>>>    ordered-by "user";
>>>>>>>>>>>>    description
>>>>>>>>>>> only needs to use prefix as the key, and if an 
>>>>>>>>>>> implementation
>>>>>>>>> supports
>>>>>>>>>>> multiple static routes for the same prefix they can extend 
>>>>>>>>>>> as an optional feature.
>>>>>>>>>>> 
>>>>>>>>>>> Under these conditions, I am afraid we don't have any 
>>>>>>>>>>> natural
>>>>> key(s)
>>>>>>>>>>> but the problem is that, depending on the system, they may 
>>>>>>>>>>> be
>>>>>>>>> specified
>>>>>>>>>> (iii) is irrelevant here - we're talking about 
>>>>>>>>>> "static-route",
>>>>> which
>>>>>>>>> is a "protocol instance" and does not need to be in the key 
>>>>>>>>> for the static route entries.
>>>>>>>>> 
>>>>>>>>> It is relevant. If we introduce preference as a route 
>>>>>>>>> attribute in
>>>>>>> ietf-
>>>>>>> unique in the list of static routes. Future modules may 
>>>>>>> introduce new static route attributes, e.g. for policy routing 
>>>>>>> it could be "tos",
>>>>> and
>>>>>>> then it would make a very good sense to configure multiple 
>>>>>>> static
>>>>> routes
>>>>>>> While static routes can be augmented with a new parameter such 
>>>>>>> as
>>>>> "tos",
>>>>>>>>>>> Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --
>>> ____________________________________________________________________
>>> _ _ ___________________________________________________
>>> 
>>> confidentielles ou privilegiees et ne doivent donc pas etre 
>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu 
>>> ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>>

---

From: Dean Bogdanovic <[email-masked]>
Date: Fri, 27 Jun 2014 17:03:19 +0000

Stephane,

active is better attribute.

Dean