---- Original Message ----- From: "Susan Hares" <[email protected]> To: <[email protected]> Cc: "'Jeffrey Haas'" <[email protected]>; "Edward Crabbe" <[email protected]> Sent: Thursday, June 12, 2014 11:26 PM
> I've posted a version of white-i2rs-use-case-05 with the recommendations at the front of the document. I look forward to additional comments. I appreciate Tom Petch and Dean B.'s comments on these drafts. Sue I am flattered; I am not sure that I deserve such mention. I am more interested in the use cases part of the I-D, seeing requirements and info-model as the next stage when use cases are agreed, and they look fine (perhaps /may Data Centers/many Data Centers/). I note the reference to ISIS which I find significant. My experience is more of OSPF but appreciate that that is rare with Operators. However, both are Link State and so very different to BGP which makes me think about the use of RIB. The NETMOD routing-cfg started with RIBs, dropped them and then reinstated them (after consulting with I2RS), whereas for me, RIBs are BGP (as defined in RFC4271) and OSPF has an equivalent in LSDB, which is very different in detail (as much research as Lada has done across three differing platforms, I am not certain that the NETMOD has sufficient routing expertise to get this perfect:-(. I think you need a definition of RIB, perhaps by a Normative reference to rib-info-model, but for me that leaves unclear the relationship between routing instance, routing protocol and RIB, at least when you get into requirements. Likewise, this I-D is cast in terms of a table identifier and a route process identifier, whereas routing-cfg has routing-instance [name] with router-id, ribs, interfaces, routing-protocols etc I have a sense of two divergent models of what a router is for all the discussions. REQ1 last sentence should probably include removing process REQ2 I think is about source-based routing but it does not quite say that, rather reading as if source or destination routing were equally valid options REQ3 again the wording seems odd - I think you mean that traffic with a given destination (or source?) prefix should be discarded, but that is not what it says REQ4 I find vague, as I do anything with the word policy in it:-( Something concrete (communities, MED, ...) would help REQ6 makes me wonder what is a RIB when it is not local REQ8 seems all embracing (SNMP, DHCP, NTP ...?:-) - I would like something more concrete. Again, I wonder if it is technically possible to present information in a consistent manner given the difference in underlying concepts of protocols. REQ9 - again all embracing and as such, probably impossible, at least as written. Limiting it just to BGP and a link-state protocol, again that seems challenging. REQ10 - policies again, and it is unclear who is doing the time management. Some configuration protocols do have timer-based facilities, but not NETCONF; do you mean here that I2RS must have functionality based on timers (e.g. between 08:00 and 17:00 EDT, route this via Europe and Japan?) Tom Petch > > URL: http://www.ietf.org/internet-drafts/draft-white-i2rs-use-case-05.txt > > Sue Hares > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
