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

From: Jeff Tantsura <[email-masked]>
Date: Mon, 4 Mar 2019 13:08:26 -0800

Dear RTGWG,

The draft has been adopted.
Authors, please publish the draft as the working group document.

Cheers,
Jeff and Chris
On Feb 15, 2019, 11:18 AM -0800, Jeff Tantsura <[email-masked]>, wrote:
> 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

---

From: Yingzhen Qu <[email-masked]>
Date: Mon, 4 Mar 2019 21:09:50 +0000

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].

Thanks,
Yingzhen

On 2/19/19, 4:26 AM, "tom petch" <[email-masked]> 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-masked]>
    To: "RTGWG" <[email-masked]>; "Routing WG" <[email-masked]>;
    <[email-masked]>
    Sent: Friday, February 15, 2019 7:18 PM
    Subject: WG Adoption for "RIB YANG Data Model" -
    draft-acee-rtgwg-yang-rib-extend

    > individual that has contributed to the document.

    ------------------------------------------------------------------------
    --------

    > _______________________________________________
    > rtgwg mailing list
    > [email-masked]
    > https://www.ietf.org/mailman/listinfo/rtgwg
    >

---

From: tom petch <[email-masked]>
Date: Tue, 5 Mar 2019 12:08:05 +0000

----- Original Message -----
From: "Yingzhen Qu" <[email-masked]>
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].

Um; not sure what the WG Chairs will make of that.  It is -09 that has
been approved by the WG and so I would expect to see
draft-ietf-rtgwg-yang-rib-extend-00.txt
with text identical apart from name to
draft-acee-rtgwg-yang-rib-extend-09.txt
However, resolving that issue is above my pay grade!

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.

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.

Tom Petch

> [YQ]: We're still using "preference" consistent with RFC 8349. The
term, "admin distance",  is only included parenthetically for
explanation.
> [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.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 5 Mar 2019 15:10:40 +0000

Hi Tom,

On 3/5/19, 7:08 AM, "tom petch" <[email-masked]> wrote:

    ----- Original Message -----
    From: "Yingzhen Qu" <[email-masked]>
    Sent: Monday, March 04, 2019 9:09 PM

    

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. 

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). 

Thanks,
Acee
    
    Tom Petch

---

From: tom petch <[email-masked]>
Date: Thu, 7 Mar 2019 12:48:27 +0000

Yimgzhen

Looking at
draft-ietf-rtgwg-yang-rib-extend
I would like a reference for FRR since the current text confused me; I
have also responded to Acee about this.

I would like a reference for
         description "Additional Application-Specific Route tag";
as I do not know what you mean:-(

The YANG import statements need reference clauses e.g.
   import ietf-inet-types {
     prefix inet;
     reference "RFC6991: Common YANG Data Types";
   }

/Ipv4/IPv4/

      name: ietf-acl namespace: urn:ietf:params:xml:ns:yang:ietf-rib-
      extension prefix: ietf-rib-ext reference: RFC XXXX
puzzles me

Tom Petch

---

From: tom petch <[email-masked]>
Date: Thu, 7 Mar 2019 12:48:26 +0000

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

>     address your comments, please see my detailed response below
starting
<snip>
> 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.
> 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

>     >     One is terminology, which caused some discussion in the
production
>     of
>     >     the original YANG routing module.  When I see the
terminology
>     used, e.g.
>     >     other manufacturers see it and would like to see their
agreement
>     that
>     >     More technically, I wonder at the specification of repair
routes.
>     One
>     >     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
>     >        +--ro id          string                     <---------
"id" is
>     defined here.
>     >     Related to this, is there any requirement for repair routes
to
>     exist or
>     >     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