Re: WG Adoption for "RIB YANG Data Model" - draft-acee-rtgwg-yang-rib-extend

[tom petch <[e-mail]>]

----- Original Message -----
From: "Acee Lindem (acee)" <[e-mail]>
Sent: Tuesday, March 05, 2019 3:10 PM

> Hi Tom,
>
> On 3/5/19, 7:08 AM, "tom petch" <[e-mail]> wrote:
>
>     ----- Original Message -----
>     From: "Yingzhen Qu" <[e-mail]>
>     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" <[e-mail]> 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" <[e-mail]>
>     >     To: "RTGWG" <[e-mail]>; "Routing WG"
>     <[e-mail]>;
>     >     <[e-mail]>
>     >     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
>     >     > [e-mail]
>     >     > https://www.ietf.org/mailman/listinfo/rtgwg
>     >     >
>     >
>     >
>     >
>     >
>
>
>
>