Re: [RTG-DIR] Early Routing Directory Review of draft-ietf-babel-information-model-03.txt

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

Hi Barbara,

From: "STARK, BARBARA H" <[e-mail]>
Date: Thursday, October 11, 2018 at 4:52 PM
To: Acee Lindem <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, Routing ADs <[e-mail]>, Routing Directorate <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: Early Routing Directory Review of draft-ietf-babel-information-model-03.txt

Hi Acee,
My comments this go-round have <bhs2>. Thx again.
Barbara

From: Acee Lindem (acee) <[e-mail]>
Hi Barbara,
On Oct 9, 2018, at 3:39 PM, STARK, BARBARA H <[e-mail]<mailto:[e-mail]>> wrote:

Hi Acee,
Thanks so much for your review. My responses are inline, marked with <bhs>.
Barbara

From: Acee Lindem (acee) <[e-mail]<mailto:[e-mail]>>
Sent: Monday, September 24, 2018 11:01 AM
To: [e-mail]<mailto:[e-mail]>; Routing ADs <[e-mail]<mailto:[e-mail]>>
Cc: Routing Directorate <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Early Routing Directory Review of draft-ietf-babel-information-model-03.txt

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<https://urldefense.proofpoint.com/v2/url?u=http-3A__trac.tools.ietf.org_area_rtg_trac_wiki_RtgDir&d=DwQGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=3eO5h8iPuGSNAK1odVHvyRPqygOsRS24bGDgSj5UtBc&m=It6s9TbGYO-ubeFfzjBLtKNx3YASUSsKt-P8ADyhFnU&s=Isq4o7o_2_XSlG9JcDUgMatN3UA3dKC5IW7PhnMfmD0&e=>

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-babel-information-model-03.txt
Reviewer: Acee Lindem
Review Date: September 24th, 2018
IETF LC End Date: Not started yet.
Intended Status: Informational

Summary:
    I don’t believe the document should be continued. Given the lack of precision in the definitions, I’d recommend abandoning the work and going directly to the YANG model. I also have some major concerns.

<bhs> My personal interest is in having a BBF TR-181 data model (DM). I believe it is in the best interest of the overall industry if the TR-181 DM (which I’ve already submitted to BBF for consideration in the next TR-181 issue) and any potential YANG DM were consistent. It is for this reason I’m creating an information model. Personally, I have no intention of spending my effort creating a YANG DM, because all devices my employer would consider managing Babel in are currently managed by BBF TR-069. If I were to abandon this information model effort, I would then only create the TR-181 DM, and leave it to others to figure out how or whether to create a YANG DM. I’m always happy not to do work where others see no value; but I do believe there is value in having consistency between my TR-181 DM and any YANG model that someone else might choose to create. I will soon be putting my draft TR-181 DM on my github site. If the WG did want to abandon this information model effort, it would still be possible to get consistency if whoever creates a YANG DM wanted to simply base the YANG DM on my TR-181 DM. I do think that approach is a bit awkward, though. I also think that approach would make it more difficult to get good review of the information elements. BTW, a couple of the Babel implementations have implemented the information model as an HTML web page (with no configuration of parameters supported). This has provided very useful feedback. These implementers are not experienced in YANG or reading YANG DMs (and neither am I).

This is certainly up to the Babel WG but the information model seems to me to be a wasted step. Additionally, while the information model will be used as a starting point for the actual data model, there is no guarantee that it will follow it by the time it standardized and implemented.

<bhs2> I assume you’re referring to the YANG DM in the last sentence. I’m hopeful we will be able to get someone with YANG expertise to create a YANG DM, but you’re right there’s no guarantee. I’m working on the BBF TR-181 data model and do expect it to track closely to this information model effort, with publication next year. I think we must agree to disagree on the value of this information model. My experiences with the lmap information model (RFC8193) suggested it was valuable to have the information model to drive both the YANG (RFC8194) and TR-181 DMs.

Ok – I think the BBF model would also be a good input to the IETF Babel YANG model.




Comments:
    The summary says it all.

Major Issues:
1.       The abstraction of babel-security-obj is too abstract to be useful. Furthermore, babel-security-trust alludes to certificates signed by CAs. However, if you are using these for routing, it is not clear how the PKI is accessed. It would be infinitely more useful to define what is used for the extant security mechanism (e.g., HMAC).
<bhs> Babel WG has recently adopted WG drafts for a DTLS and an HMAC security mechanism. Both were adopted after the information-model draft you reviewed was published. Both security solutions require credentials, but the types of credentials and how they are used and treated are specific to each solution. Creating information model elements without knowing the details of the eventual security mechanisms was indeed challenging, and was the reason the object was so abstract. It is not the responsibility of the info model to define the security mechanisms – rather the info model must reflect the needs of the security mechanisms the WG selects. Per the drafts, HMAC will use a shared key (no certificate authority or PKI), and DTLS will allow for all credentials allowed by DTLS best practices (RFC 7525). How the PKI is accessed in the case of DTLS-protected Babel is described in the new (as of yesterday) draft-ietf-babel-dtls WG draft. Looking over the babel-security-obj elements in the context of these 2 drafts that now exist, I do think some more descriptive/clarifying detail is needed specific to each of the 2 solutions. However, I want to avoid creating a dependency on either solution, and still think there is value in modeling credential management in a manner that could work for any credential system (used by any security mechanism).

In that case and since you don’t want to define what it is or tie it to any authentication mechanism, I don’t see the babel-credentials-object being any more useful than a string. Perhaps you could explain by example how this abstraction would be populated for both HMAC and DTLS.

<bhs2> Yes, agree. I found the information model format limiting wrt expressing this. I think YANG supports the modeling of commands, as does TR-181. But I didn’t know how to do talk about commands in this simplistic syntax. In TR-181, we handle credentials by allowing them to be added or deleted, but only certain metadata can be read. I’ll add more and see if I can find a good way to express this.
Ok.



2.       While the descriptive text says that some objects MUST be configured, there is no precise specification of which are configurable and which are not.

<bhs> The Overview section provides a complete (non-normative) list of all (potentially) configurable data elements. Each of these data elements has normative language as the last sentence in the description of the data element (either “MAY be configurable” or “MUST be configurable if implemented”). It’s been suggested to me that people used to YANG may find this a confusing way of expressing configurability, and that the meaning of “MAY/MUST be configurable” is not obvious to them. “MAY/MUST be configurable” for me meant that a generic DM would define it as read/write. If it “MAY be configurable”, then a specific protocol implementation could choose to make it read-only, even though the generic DM defines it as read/write. The suggestion was to change how this is expressed by adding a column to the objects with “ro” or “rw” for each parameter. Explain in the Notation section that “ro” means the parameter is read-only, and “rw” means the parameter is read-write. Where an implementation can choose to expose a “rw” parameter as “ro”, this will be noted in that parameter’s description as “An implementation MAY choose to expose this parameter as read-only (ro).” In the Overview, I would change “Following is a list of the data elements that an implementation can choose to allow to be configurable:” to “Most parameters are read-only. Following is a list of the data elements that are not required to be read-only:”.

3.       The contents and structure of babel-hello-ucast-history and babel-hello-mcast-history is incomprehensible. Why aren’t these objects represented as lists with the format of the list elements defined?
<bhs> Agreed. The description is being improved in the next draft revision, based on feedback already received from the WG. They aren’t lists because they are precisely reflecting the mechanism described in babel-rfc6126bis (the protocol specification). The implementers felt this already-implemented history was useful and thought it would be good to allow it to be expressed via the info model. Not all implementers implement this.

4.       The “Security Considerations” section discussion is woefully inadequate – it basically says that configuration must be secured. This is another reason to go to the YANG model where all this is defined.
<bhs> TR-069 and TR-369 also secure configuration of TR-181 data elements. When someone else creates a YANG DM, I expect it will have whatever security is provided by YANG (or NETCONF/RESTCONF). The current implementations that provide read-only display of data elements via HTML are not securing their web pages – but that is not an issue in a prototype. I would certainly suggest that all HTML pages in commercial products require users to login prior to display. The information model is not in a position to require or guarantee this, however. A YANG DM and its security capabilities would have no applicability to TR-069/TR-181/TR-369 or HTML web pages, so I’m not sure I understand how a YANG model would provide security for any of these other mechanisms.


What I mean is that the YANG models have a template for both over security of the data model and listing out the security exposures for various parameters. All this has is a one-liner mandating a secure manner.


   Any mechanism or protocol that is

   used to transmit this information or allow for its configuration is

   also responsible for ensuring this is done so in a secure manner.

It would probably be better to say it is in the scope of the data models (either IETF for BBF).



<bhs2> OK. Will do.



Ok. I’ll take a look at the update.



Thanks

Acee



Thanks,

Acee







Minor Issues:

1.       The format for the object descriptions is hard to consume. It would be preferable to use complete sentences and mixed rather than a continuous stream of lowercase separate by semi-colons.
<bhs> OK. Will do.

2.       Why isn’t there an IPv4 multicast address in babel-constant-obj?
<bhs> It was removed per request of babel routing protocol authors and implementers. No-one was implementing IPv4 transport of babel, and everyone felt it was completely unnecessary.

3.       It is unclear how babel-txcost and babel-rxcost are derived. This should either be specified or there should be an appropriate reference to the section in the base specification.
<bhs> OK. Will provide reference to base spec (section 3.4.3 of the current babel-rfc6126bis draft).

4.       It is unclear how ECMP routes are supported in babel-routes-obj.
<bhs> I don’t think ECMP routing has been discussed in the context of Babel, or that any of the implementations support it. This might be an interesting discussion to have. But I think ECMP routes are supported in babel-routes-obj as is. For ECMP, I would expect to see multiple babel-routes-obj entries with the same babel-route-prefix (prefix for which this route is advertised) to have babel-route-selected = true (route is currently being used for forwarding and is being advertised). I’m not sure what else would need to be expressed specific to Babel. Since ECMP isn’t dependent on which (if any) routing protocol is being used, I would expect most aspects of ECMP (e.g, ECMP supported and enabled) to be modeled external to Babel or any other routing protocol. If my thinking on ECMP modeling is too simplistic, please point me to references for education.

5.       If is implementation-specific how babel-route-calculated-metric is calculated, shouldn’t there be some indication of the algorithm used? It seems all Babel routers in the domain should be using a similar algorithm.
<bhs> Agree, an indication is needed. There’s no requirement for all Babel routers to use the same or even similar algorithm. At the top level babel-information-obj is the babel-metric-comp-algorithms list, which identifies the supported algorithms. But I think there needs to be a parameter per interface that identifies which of the supported algorithms is being used for that interface. Note that different algorithms are likely to be used depending on whether the link is wireless, ethernet, or other. Another possible way to model would be to have a separate object that says which algorithm is used for which link type. Perhaps I should ask the WG which model they prefer.

Nits:

1.       Inconsistent uppercase and lowercase reference to “Babel”. See diff.
<bhs> OK. Will do.
2.       Use US English spelling of “neighbor” consistently.
<bhs> OK. Will do.

ACEE-M-G2HR:Desktop acee$ diff draft-ietf-babel-information-model-03.txt.orig draft-ietf-babel-information-model-03.txt
18c18
<    implementation (via a management protocol such as netconf) to report
---
>    implementation (via a management protocol such as NETCONF) to report
97,98c97,98
<    that can be used to created management protocol data models (such as
<    a netconf [RFC6241] YANG data model).
---
>    that can be used to create management protocol data models (such as
>    a NETCONF [RFC6241] YANG data model).
101,102c101,102
<    model is focused on reporting status of the Babel protocol, and very
<    little of that is considered mandatory to implement (conditional on a
---
>    model is focused on reporting Babel protocol operational state, and very
>    little of that is considered mandatory to implement (contingent on a
104c104
<    parameters may be configurable; however, it is up to the Babel
---
>    parameters may be configurable. However, it is up to the Babel
134,135c134,136
<    the minimal number of values, and n is the maximum.  The symbol * for
<    n means no upper bound.
---
>    the minimun number of list elements and n indicates the maximum number
>    of list elements.  The symbol * for n means there no defined limit on
>    the number of list elements.
210c211
<    o  enable/disable babel
---
>    o  enable/disable Babel
229c230
<    o  Interface: enable/disable babel on this interface
---
>    o  Interface: enable/disable Babel on this interface
262c263
<          }babel-information-obj;
---
>          } babel-information-obj;
266,269c267,269
<
<       babel-enable: if true, the babel implementation is running; if
<       false, the babel implementation is not currently running; MAY be
<       configurable to allow babel to be started or stopped
---
>       babel-enable: if true, the Babel implementation is running; if
>       false, the Babel implementation is not currently running; MAY be
>       configurable to allow Babel to be started or stopped
318c318
<          }babel-constants-obj;
---
>          } babel-constants-obj;
355c355
<          }babel-interfaces-obj;
---
>          } babel-interfaces-obj;
366,367c366,367
<       babel-interface-enable: if true, babel sends and receives messages
<       on this interface; if false, babel messages received on this
---
>       babel-interface-enable: if true, Babel sends and receives messages
>       on this interface; if false, Babel messages received on this
407,408c407,408
<       babel-message-log-enable: if true, logging of babel messages
<       received on this interface is enabled; if false, babel messages
---
>       babel-message-log-enable: if true, logging of Babel messages
>       received on this interface is enabled; if false, Babel messages
489c489
<       link layer; the rxcost is sent to a neighbour in each IHU
---
>       link layer; the rxcost is sent to a neighbor in each IHU
492c492
<       the neighbour table: the statistics kept in the neighbour table
---
>       the neighbor table: the statistics kept in the neighbor table
516c516
<          }babel-security-obj;
---
>          } babel-security-obj;
578c578
<          }babel-routes-obj;
---
>          } babel-routes-obj;
635c635
<        }babel-credential-obj;
---
>        } babel-credential-obj;
645c645
<        }babel-log-obj;
---
>        } babel-log-obj;
659c659
<    expose babel route filtering rules by adding a route filtering object
---
>    expose Babel route filtering rules by adding a route filtering object

Thanks,
Acee