Lada and Tom: You've convinced me that I should define the term RIB and FIB in the draft-white-i2rs-use-case-05. Would you like to suggest any text? Otherwise give me a day or so to come up with text for this draft.
Sue -----Original Message----- From: i2rs [mailto:[email protected]] On Behalf Of t.petch Sent: Tuesday, June 17, 2014 4:55 AM To: Ladislav Lhotka Cc: Jeffrey Haas; [email protected]; Edward Crabbe; Susan Hares Subject: Re: [i2rs] draft-white-i2rs-use-case-05.txt has been posted ----- Original Message ----- From: "Ladislav Lhotka" <[email protected]> To: "t.petch" <[email protected]> Sent: Friday, June 13, 2014 1:11 PM > > On 13 Jun 2014, at 13:49, t.petch <[email protected]> wrote: > > ---- Original Message ----- > > From: "Susan Hares" <[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 or, once again with feeling, http://www.ietf.org/mail-archive/web/netmod/current/msg07022.html Tom Petch > > 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 > >> > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
