On 19 Jun 2014, at 11:19, t.petch <[email protected]> wrote: > ----- 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:-(
Actually, you didn’t lose that argument in NETMOD! As you know, the routing-cfg draft then had been using the term “routing table” for some time. However, an action item from IETF 87 was "to harmonize things with the information model defined by the I2RS working group” [1]. One of the results of this harmonisation was the change “routing table” -> “RIB”. IMO, whatever names are chosen, it is important to define the terms properly. I understand Sue’s proposal aims at this direction, and I certainly hope it won’t lead to a de-harmonisation with NETMOD terms. Lada [1] http://www.ietf.org/proceedings/87/minutes/minutes-87-netmod > > 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 >>> >> >> > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
