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 protected]] > Sent: Wednesday, May 25, 2016 8:28 AM > To: Ing-Wher (Helen) Chen <[email protected]>; draft-ietf-ospf- > [email protected]; [email protected]; draft-acee-rtgwg-yang- > [email protected]; [email protected]; > [email protected] > Subject: Re: identical RIB augmentations in OSPF and ISIS YANG models > > "Ing-Wher (Helen) Chen" <[email protected]> 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 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
