Subject: Re: [netmod] identical RIB augmentations in OSPF and ISIS YANG models

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 25 May 2016 14:28:23 +0200

"Ing-Wher (Helen) Chen" <[email-masked]> writes:

> Hello,
>
> I notice that the OSPF and ISIS YANG models
> (<https://tools.ietf.org/html/draft-ietf-ospf-yang-04> and
> <https://tools.ietf.org/html/draft-ietf-isis-yang-isis-cfg-08>) each
> defines its own augmentation to
> /rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route that adds metric,
> tag and route-type to the OSPF and ISIS YANG models.

Both IS-IS and OSPF define route-type but each uses a different enumeration
type, so presumably their semantics are different as well. So I am not
sure it is a good idea to define a common route-type in
ietf-routing. What would be its type?

I remember there was already a similar discussion about metric,
too. Different protocols use metrics with different ranges and
semantics, so the conclusion then was to leave the definition of metric
to each protocol.

Route tag is uint32 in all cases, so it could be added to ietf-routing.

Lada

>
> Separately, I notice that the RIB extension YANG model (<https://tools.ietf.org/html/draft-acee-rtgwg-yang-rib-extend-01>) also defines a similar augmentation to /rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route that adds metric and tag (but not route-type).
>
> Since it looks like the metric/tag/route-type augmentation is common to most routing protocols, may I suggest that these attributes, metric, tag, and route-type, be placed in the (base) routing YANG model (<https://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-21>) instead of individual routing protocols or even the RIB extension model?
>
> Thanks,
> Helen

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

---

From: "Ing-Wher (Helen) Chen" <[email-masked]>
Date: Wed, 25 May 2016 13:58:59 +0000

Hi Lada,

"metric" in this case is the operational state metric (or cost) of a route, and
has identical definitions in in all three drafts (OSPF, ISIS, and RIB extension).
(They're all defined to be type uint32, with no range or default value.)  I
understand that each protocol might define and configure the metric (or
cost) of a link differently, but shouldn't the operational state,
/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/ospf:metric or
/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/isis:metric or
/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/rib-ext:metrc , be
comparable and with the same semantics so that RIB can determine the
best route?

For route-type, is it possible to define the type as an identityref, and let
each protocol define identities?  (Similar to how 
/rt:routing/rt:routing-protocols/rt:routing-protocol/rt:type is defined to be
type identityref.)

For route-tag, I missed that ISIS defines is as a leaf-list instead of a leaf...

Thanks,
Helen

> -----Original Message-----
> From: Ladislav Lhotka [mailto:[email-masked]]
> Sent: Wednesday, May 25, 2016 8:28 AM
> To: Ing-Wher (Helen) Chen <[email-masked]>; draft-ietf-ospf-
> [email-masked]; [email-masked]; draft-acee-rtgwg-yang-
> [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: identical RIB augmentations in OSPF and ISIS YANG models
> 
> type, so presumably their semantics are different as well. So I am not sure it
> is a good idea to define a common route-type in ietf-routing. What would be
> its type?
> 
> I remember there was already a similar discussion about metric, too.
> Different protocols use metrics with different ranges and semantics, so the
> conclusion then was to leave the definition of metric to each protocol.
> 
> > Separately, I notice that the RIB extension YANG model
> (<https://tools.ietf.org/html/draft-acee-rtgwg-yang-rib-extend-01>) also
> defines a similar augmentation to /rt:routing-
> state/rt:ribs/rt:rib/rt:routes/rt:route that adds metric and tag (but not route-
> type).
> >
> > Since it looks like the metric/tag/route-type augmentation is common to
> most routing protocols, may I suggest that these attributes, metric, tag, and
> route-type, be placed in the (base) routing YANG model
> (<https://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-21>) instead of
> individual routing protocols or even the RIB extension model?
> >
> > Thanks,
> > Helen
> 
> --

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 25 May 2016 14:09:03 +0000

Hi Lada, Helen, 

>comparable and with the same semantics so that RIB can determine the

I can’t think a single uint32 metric should handle the superset of cases.

>/rt:routing/rt:routing-protocols/rt:routing-protocol/rt:type is defined

That is a good idea. Trying to define all the possible route-types a
priori is an exercise in futility.

>For route-tag, I missed that ISIS defines is as a leaf-list instead of a

This is not widely implemented (if at all) although I have draft for OSPF
supporting multiple tags per prefix. Is it possible to support a single
tag in the ietf-routing and support an augmentation to support multiples
(without it being too ugly)?

Thanks,
Acee

>>sure it

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 25 May 2016 14:12:37 +0000

Sigh… 

>I can’t think a single uint32 metric should handle the superset of cases.

I think a single uint32 metric should handle the superset of cases for the
global RIB.