FYI, answers from Joel Halpern on my questions to the architecture document. Thanks Joel. -Linda
From: Joel Halpern [mailto:[email protected]] Sent: Wednesday, February 26, 2014 1:12 PM To: Linda Dunbar; [email protected] Subject: RE: Comments to draft-ietf-i2rs-architecture-02.txt Replies to other comments, from what I understand of our and the WGs intent. Feel free to copy this to the I2RS list. I have not done so since you sent it directly to the authors. Yours, Joel ________________________________ From: Linda Dunbar [mailto:[email protected]] Sent: Wednesday, February 26, 2014 10:30 AM To: [email protected]<mailto:[email protected]> Subject: FW: Comments to draft-ietf-i2rs-architecture-02.txt Alia, et al, Here are my comments and questions to the draft-ietf-i2rs-architecture-02.txt: - Last paragraph of Section 1, Typo "tivial example". Do you mean "trivial example"? - Section 3.2 (Extensibility): This section is more on justifying the scope of I2RS than the architecture. <jmh> Extensibility, and the need for it, is a central archtiectural property. It wil affect many aspects of the protocol design. In terms of "scope" including it hee helps us keep the scope tight, as we can reasoanbly says that the extensibility will allow us to deal with other things later. </jmh> - Section 3.3 (Model - Driven ...): what is "model-driven architecture and protocol(s)"? is Yang model a valid one? Or Netconf? <jmh>The protocol behavior needs to be driven by the models. This applies whether the data model is YANG, ForCES, or UML.</jmh> - Section 6.2.1 (I2RS Agent Failure) o Unexpected failure: it is very likely under the "unexpected failure" that the I2RS agent loses its records of clients. A more reasonable way is for I2RS agent to broadcast its status (e.g. restart), to let the Clients to re-subscribe if they need to. <jmh ...discussed on list... </jmh> - 6.4.2 (IGP, BGP, ..): o The first bullet says "Directly writing to these protocol-specific RIBs or databases is out of scope for I2RS." o The information model defined by draft-ietf-i2rs-rib-info-model-02 has "route", nexthop", modifying them can impact the result of those protocol-specific RIBs. o The last paragraph seems to say that local route attributes can be changed, e.g. link metrics, local attachment, however, information received from other nodes (LSA) can't be modified, is it correct? o Then, all those local attributes can also be modified by CLI, correct? <jmh>As far as I can tell, there is no inconsistency here. The Protocol RIBs (the OSPF RIB, the BGP in-RIB, etc...) can not be directly written by I2RS. Writing that makes a mess. On the other hand, I2RS can write the policies the protocol use with these. But the RIB referenced in the rib-info-model is not one of those protocol RIBs. It is the commonr rib abstraction by which the various protocol decisions are reconciled. Changes to it affect the protocol behaviors if they import routes, but do not directly change the RIBs they have itnernally. We do not get to tell rotuer vendors which knobs to expose in CLI. Nor are we conducting a survey to confirm that all these knobs are already exposed. </jmh> - 6.4.5: this section is more like the requirement for Informational model. I don't see how they impact the architecture. <jmh>We had a debate on whether this text belongs here or somewhere else. It needs to be captured and agreed by the WG. Moving it somewhere else will delay other work. On the other hand, I fully agree that it is a weak fit here.</jmh> - Which entity does the cross check if policies to one Routing Element from different Clients are contradicting with each other? o Page 8 states that two clients can't attempt to write (modify) the same piece of information. Does it mean two clients can't write (modify) "Tunnel nexthops" or "weighted lists" (defined by draft-ietf-i2rs-rib-info-model-02)? What if two clients need to modify "Tunnel nexthops" for some prefixes (e.g. two different applications for one virtual network)? <jmh> This has been discussed extesnively on the list. Each model will define its view of what the atomic set of objects are. Colliding on those objects is an error. i2RS does not provide reliable or strong means to manage such collisions. The applications will have to cope with the colissions. If two clients need to modify the Tunnel nexthop for the same prefixes, then one of them will succeed, the other will fail. He will get a notice. And he will have to cope with it. The I2RS agent is not going to try to guess the intent of the human who directed the application to use the I2RS Agents to cause the collision. And indirect collisions, which are likely, are simply not something we are going to attempt to detect or prevent. </jmh> o How to guarantee it? <jmh>The I2RS agent enforces direct collision policy.</jmh> - Who checks policies to multiple routing elements are contradicting to each other? <jmh>No one. The basic premise of I2RS is that if the operator wants to shoot himself in the foot, it is his foot to shoot. If someone wants to build tools for consistency checking, go ahead. it is not part of the WG effort.</jmh> - Today's router can be configured/ changed by CLI, or NETCONF, monitored by SNMP, how is "I2RS" agent different from those entities? <jmh>The I2RS Problem statement deals with the question of why the existing mechanisms as currently used are insufficient. It may be that existing protocols (NETCONF, ForCES, ...) can be used in some fashion to meet the requirements. In any case, that is not aprt of the archtiecture document's job. </jmh> - What if clients need to re-direct traffic on attributes that are not in the RIB? <jmh>With regard to information that is not modeled in I2RS models, it is expected that the vendor will provide extensions to the information (and data) models that are used with I2RS. So they can provide additional capabilities to the customer. The Extensibility and Model Driven archtiecture should make this easy to deploy. With regard to traffic redirection, there is work ongoing on the policy based routing model, which would be aimed at addressing that need.</jmh> Linda Dunbar
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
