Hi Lada, Helen, On 5/25/16, 9:58 AM, "Ing-Wher (Helen) Chen" <[email protected]> wrote:
>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? I can’t think a single uint32 metric should handle the superset of cases. > >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.) 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 >leaf... 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 > >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
