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

["Acee Lindem (acee)" <[e-mail]>]

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

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

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