On 13 Jun 2014, at 13:49, t.petch <[email protected]> wrote: > ---- 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.
Sounds like recurring deja vu: - http://www.ietf.org/mail-archive/web/i2rs/current/msg00554.html - http://www.ietf.org/mail-archive/web/i2rs/current/msg00586.html Lada > > 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
