Lada: Thanks for the pointer to text.
Sue Hares -----Original Message----- From: Ladislav Lhotka [mailto:[email protected]] Sent: Tuesday, June 17, 2014 11:45 AM To: Susan Hares Cc: t.petch; Jeffrey Haas; [email protected]; Edward Crabbe Subject: Re: [i2rs] draft-white-i2rs-use-case-05.txt has been posted Hi Sue, as for RIB, I'd suggest to use the definition from draft-ietf-netmod-routing-cfg-15, section 5.3 (and 5.2), or at least one that's compatible with it. We actually agreed on this definition previously with the guys working on the RIB info model. Thanks, Lada On 17 Jun 2014, at 17:23, Susan Hares <[email protected]> wrote: > 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
