Subject: Re: [RTG-DIR] [netmod] Routing Directorate Comments on draft-ietf-netmod-routing-cfg-15

From: Benoit Claise <[email-masked]>
Date: Thu, 23 Oct 2014 18:52:38 -0700

Hi Lada,

When can we expect the v16 of the draft?
Hopefully before this deadline.

Regards, Benoit
> Acee Lindem <[email-masked]> writes:
>
>> Hi Lada, Thanks for your responses. It seems that you will publish a
>> new revision that covers most of my comments.I will await that update
> Yes. Thanks, Lada
>
>> and review. With respect to only supporting the forwarding model where
>> none of the backup paths are used until all the primaries are
>> unavailable, I will discuss the with a few more people and get back to
>> you.  Thanks, Acee
>>
>> On Jul 8, 2014, at 6:34 AM, Ladislav Lhotka <[email-masked]> wrote:
>>
>>> Hi Acee,
>>>
>>> thank you for the review, my comments are inline.
>>>
>>> Acee Lindem <[email-masked]> writes:
>>>
>>>> Hello,
>>>>
>>>> I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>>>>
>>>> Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.
>>>>
>>>> Document: draft-ietf-netmod-routing-cfg-15
>>>> Reviewer: Acee Lindem
>>>> Review Date: July 8th, 2014
>>>> IETF LC End Date: TBD
>>>> Intended Status: Proposed Standard
>>>>
>>>> Summary: There some issues with the model in the document that need to be addressed prior to publication of this draft.
>>>>
>>>> Fundamental Question: Going forward, how will this YANG data model
>>>> relate to the I2RS RIB information model proposed in
>>>> draft-ietf-i2rs-rib-info-model-03.txt?
>>> After IETF 87, the relevant parts of two models were compared, and this
>>> resulted in several changes and additions in the NETMOD model. Since
>>> then, the I2RS model underwent some changes but the only parameter that
>>> needs to be included in the NETMOD model is route-preference. Other
>>> parameters such as ENABLE_IP_RPF_CHECK or nexthop chains can be added
>>> later via augmentation.
>>>
>>> On the other hand, one of the results of the alignment with I2RS RIB
>>> info model, was the addition of the "id" key to every single route. In
>>> the discussion with I2RS folks, I raised objections against this unique
>>> "id" because it could mean considerable bookkeeping for a RIB containing
>>> ~200K routes, but we eventually agreed to add it to the NETMOD
>>> model. Later, several people repeated my concerns, and I think this "id"
>>> should be removed from the NETMOD model.
>>>
>>>> Major Issues:
>>>>
>>>>        Section 4 & 5.4:  These sections appear to restrict a routing
>>>>        protocol instance to exactly one RIB for each address family
>>>>        that the routing protocol instance supports. RFC 4915, et al,
>>>>        support a single routing protocol instance which may populate
>>>>        multiple RIBs per address family.
>>> This issue was brought up in a recent discussion with people working on
>>> data models for OSPF and ISIS, and the rough consensus is that this
>>> restriction should be lifted. By default, routes from a routing protocol
>>> instance will be installed in all connected RIBs of the corresponding
>>> address family (subject to operator-defined route filters), but data
>>> models for particular protocols can state other rules how connected RIBs
>>> are populated, e.g. using MT-ID.
>>>
>>>>        Section 7: What are the backup next-hops? I guess these are
>>>>        IP-FRR next-hops that are installed by the same source protocol
>>>>        as the primaries? If so, do you have to restrict the forwarding
>>>>        paradigm to not use any backup next-hops as long as primary
>>>>        next-hops are accessible? This would imply that forwarding
>>>>        plane would need to do a fast rehash of the primaries and only
>>>>        use after all primaries are expired. There are other lower
>>>>        overhead forwarding paradigms in use.
>>> In this case we only followed suit of the I2RS RIB info model, see
>>> sections 2.4.2 and 7.2.4 (protection lists) in
>>> draft-ietf-i2rs-rib-info-model-03.
>>>
>>>>       Missing: There is no concept of administrative distance (Cisco,
>>>>       et al) or route preference (gated and Juniper). In my opinion,
>>>>       this is very important since it determine which route is active
>>>>       when the same route is available from multiple protocols.
>>> Yes, route-preference will be added, see above.
>>>
>>>>       Missing: How does one get the best route for a given protocol
>>>>       (which is not necessarily the active route)? Should each
>>>>       protocol have a local RIB as part of its model? I notice that
>>>>       this is not included in the RIP example in Appendix C. Would
>>>>       that need to be part of the run state for the protocol?
>>> Yes, data models for each routing protocol should include necessary
>>> protocol-internal data structures as state data - for example BGP RIB or
>>> link-state database.
>>>
>>>> Minor issues:
>>>>
>>>>      Section 9: Should there be checking to assure the router
>>>>      advertisement mtu does not exceed the ipv6 MTU from RFC 7277?
>>>
>>> Yes, the description of the "link-mtu" leaf should mention this
>>> constraint.  It cannot be done using the "must" statement though because
>>> the "ip:mtu" leaf is optional and the ietf-ip module defines no default
>>> for it (the default depends on interface type).
>>>
>>>>
>>>> Questions:
>>>>         I guess the list routing protocol instances is independent in
>>>>         routing-protocols is independent of definition of the routing
>>>>         protocol itself? Or, would it be expected that the YANG model
>>>>         for the routing protocol itself would be here? If the former,
>>>>         wouldn’t this configuration be better grouped with the routing
>>>>         protocol themselves?
>>> I am not sure I understand the question but data models for individual
>>> routing protocols will be defined in separate YANG modules and will
>>> augment the "routing-protocol" list, both in configuration and state
>>> data. So, configuration parameters for a routing protocol will
>>> eventually appear under "routing-protocol" but will be defined
>>> separately.
>>>
>>>>        In section 9, the placement of the router advertisement
>>>>        configuration seems rather arbitrary and I would have expected
>>>>        it to be grouped with the other interface configuration in RFC
>>>>        7277. I guess placement here is the consensus of the netmod WG.
>>> The advertisements should be sent only by routers, so I think it is
>>> appropriate to have it as a part of router interfaces' config and state
>>> data. Quite often (even at IETF meetings) we can see misconfigured hosts
>>> sending these advertisements.
>>>
>>> Thanks, Lada
>>>
>>>>
>>>> Thanks,
>>>> Acee
>>>>
>>>>
>>> -- 
>>> Ladislav Lhotka, CZ.NIC Labs
>>> PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 24 Oct 2014 09:54:12 +0200

Hi Benoit,

> Hopefully before this deadline.

Yes, I am aware of the deadline on Monday. We’ve been clarifying a couple of things with the routing guys.

Cheers, Lada