----- Original Message ----- From: "Acee Lindem (acee)" <[email protected]> Sent: Tuesday, March 05, 2019 3:10 PM
> Hi Tom, > > On 3/5/19, 7:08 AM, "tom petch" <[email protected]> wrote: > > ----- Original Message ----- > From: "Yingzhen Qu" <[email protected]> > Sent: Monday, March 04, 2019 9:09 PM > > > Hi Tom, > > > > Thanks for your review and comments. We have submitted version -10 to > address your comments, please see my detailed response below starting > with [YQ]. > <snip> > > So, you say repair path is optional - which I understand - but my point > was slightly different, namely when a repair path is specified, then > does it have to conform to other details in the model? As it stands, an > IPv4 path could be a backup to an IPv6, or an Ethernet interface could > be backup to ATM! YANG allows you to impose constraints, which is > probably overused in IETF modules, but I wondered if anything would be > appropriate here. > > This is not protection of an interface, it is a next-hop protecting a route if the primary goes down. Hence, it would be unwise to attempt to impose any constraints. > > One difficulty I have is the absence of references in the I-D. When you > talk of repair paths, what do you mean? RFC7490, RFC5286.... ? This is > a general comment, that there should be references IMHO for all the > functions that this I-D specifies and there are none. One to resolve > post-adoption. > > From the standpoint of the RIB, we don't want to limit the backup to any one computational technique. However, we could reference the IP FRR framework document (RFC 5714). <tp> Acee The I-D explicitly mentions The loop-free alternate (LFA) Fast Reroute (FRR) There is no reference but I would have assumed RFC7490 from that text. If you mean RFC5714, then I think you need an explicit referece. Tom Petch > > Thanks, > Acee > > Tom Petch > > > > > > Thanks, > > Yingzhen > > > > On 2/19/19, 4:26 AM, "tom petch" <[email protected]> wrote: > > > > Two uncertainties strike me. > > > > One is terminology, which caused some discussion in the production > of > > the original YANG routing module. When I see the terminology > used, e.g. > > admin distance, I immediately think of one manufacturer so I > wonder how > > other manufacturers see it and would like to see their agreement > that > > the terminology makes sense for them (even if everyone here is of > > course contributing as an individual). > > [YQ]: We're still using "preference" consistent with RFC 8349. The > term, "admin distance", is only included parenthetically for > explanation. > > > > > > More technically, I wonder at the specification of repair routes. > One > > thought is placement, it is described as > > "Augment a route with a list of repair-paths."; > > which is not strictly true since it augments > > augment "/rt:routing/rt:ribs/rt:rib/" + > "rt:routes" > > i.e. the container and not a route therein (which is the case for > the > > augmentation with a tag). I am unsure where a list of repair > routes > > belongs in the schema - it seems to me that it could be anywhere. > > [YQ]: this was done based on WG's suggestion (sorry, forgot who made > it) to make the model "slim". The list of repair paths is at "routes" > level with an "id", at each "route" level, a repair path is reference > this "id". By doing so, if a bunch of routes are using the same repair > path, so they can just reference the same id instead of repeating the > whole repair path multiple times. > > See below tree diagram for an example: > > augment /rt:routing/rt:ribs/rt:rib/rt:routes: > > +--ro repair-route* [id] > > +--ro id string <--------- "id" is > defined here. > > +--ro next-hop > > | +--ro outgoing-interface? if:interface-state-ref > > | +--ro next-hop-address? inet:ip-address > > +--ro metric? uint32 > > augment /rt:routing/rt:ribs/rt:rib/rt:routes/rt:route > > /rt:next-hop/rt:next-hop-options/rt:simple-next-hop: > > +--ro repair-path? > > -> /rt:routing/ribs/rib/routes/repair-route/id > <-------------------referenced here. > > > > Related to this, is there any requirement for repair routes to > exist or > > be valid i.e.is this missing a few 'must' or such like statements? > > [YQ]: repair path is optional, so no "must" statement is needed. > > > > While I am at it, the reference in the YANG module to RFC8242 > should be > > RFC8342 IMHO. And the YANG module is version 1.1 so the reference > in > > the Introduction must be RFC7950; I cannot understand this I-D > using > > only RFC6020. > > [YQ]: fixed. > > > > Tom Petch > > > > > > ----- Original Message ----- > > From: "Jeff Tantsura" <[email protected]> > > To: "RTGWG" <[email protected]>; "Routing WG" > <[email protected]>; > > <[email protected]> > > Sent: Friday, February 15, 2019 7:18 PM > > Subject: WG Adoption for "RIB YANG Data Model" - > > draft-acee-rtgwg-yang-rib-extend > > > > > > > Dear RTGWG, > > > > > > The authors have requested the RTGWG to adopt > > draft-acee-rtgwg-yang-rib-extend > > > as the working group documents. > > > > > > The authors have addressed the comments raised. > > > > > > Please indicate support or no-support by March 3rd, 2019. > > > > > > If you are listed as a document author or contributor please > > > respond to this email stating of whether or not you are aware of > > > any relevant IPR. The response needs to be sent to the RTGWG > > > mailing list. The document will not advance to the next stage > > > until a response has been received from each author and each > > > individual that has contributed to the document. > > > > > > Cheers, > > > Jeff > > > > > > > > > ------------------------------------------------------------------ > ------ > > -------- > > > > > > > _______________________________________________ > > > rtgwg mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/rtgwg > > > > > > > > > > > > > > > _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
