----- Original Message ----- From: "Susan Hares" <[email protected]> To: "'t.petch'" <[email protected]>; "'Ladislav Lhotka'" <[email protected]> Cc: "'Jeffrey Haas'" <[email protected]>; <[email protected]>; "'Edward Crabbe'" <[email protected]> Sent: Tuesday, June 17, 2014 4:53 PM
> Tom: > > Thank you for the pointer to your earlier message. What do you think of > Lada's suggestion of > "draft-ietf-netmod-routing-cfg-15, section 5.3 (and 5.2)"? Sue I lost the argument against that definition on the NETMOD list so I expect I would lose it again on the I2RS list:-( But I would commend to you the taxonomy of Russ as in http://www.ietf.org/mail-archive/web/i2rs/current/msg01794.html where he talks of two different RIBs but has yet to say which they are; for me, it is the one I tagged A that is a RIB. Lada would I think be closer to C, but Lada's definition allows multiple RIBs per address family as, sort of, does draft-ietf-i2rs-rib-info-model, which Russ does not yet mention. Then again the BGP RFC have a clear view of a RIB which for me is A. So, I think that achieving consensus on what a RIB is and is not is the biggest challenge facing I2RS and that understanding I-Ds will be more difficult without it. Tom Petch > Sue > > -----Original Message----- > From: t.petch [mailto:[email protected]] > Sent: Tuesday, June 17, 2014 11:33 AM > To: Susan Hares; 'Ladislav Lhotka' > Cc: 'Jeffrey Haas'; [email protected]; 'Edward Crabbe' > Subject: Re: [i2rs] draft-white-i2rs-use-case-05.txt has been posted > > Sue > > Probably best to do it yourself. I did offer a reprise of previous IETF > work in > > http://www.ietf.org/mail-archive/web/netmod/current/msg07022.html > > but it did not gain traction in NETMOD, so I would not expect it to here. > > Tom Petch > > ----- Original Message ----- > From: "Susan Hares" <[email protected]> > To: "'t.petch'" <[email protected]>; "'Ladislav Lhotka'" > <[email protected]> > Cc: "'Jeffrey Haas'" <[email protected]>; <[email protected]>; "'Edward Crabbe'" > <[email protected]> > Sent: Tuesday, June 17, 2014 4:23 PM > Subject: RE: [i2rs] draft-white-i2rs-use-case-05.txt has been posted > > > > 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
