Dean: Thank you for those comments in March.
-----Original Message----- From: Dean Bogdanovic [mailto:[email protected]] Sent: Tuesday, June 17, 2014 9:28 AM To: Susan Hares Cc: t.petch; <[email protected]>; Jeffrey Haas; Edward Crabbe; Russ White Subject: Re: [i2rs] draft-white-i2rs-use-case-05.txt has been posted Susan, I sent you my comments to this draft back in March and this was your reply :-) http://www.ietf.org/mail-archive/web/i2rs/current/msg01319.html. Thank you for the reply to my questions. I apologize. I missed sending you're a reply. I will reply on that mail thread. My co-authors and I are working on a revision based on your comments. Dean On Jun 15, 2014, at 4:52 PM, Susan Hares <[email protected]> wrote: > Dean: > > Please look at the > http://datatracker.ietf.org/doc/draft-zhang-i2rs-mbb-usecases/ > > It provides the mobile backhaul use case. If you want to suggest > changes, I'm a co-author. > > Sue > > -----Original Message----- > From: Dean Bogdanovic [mailto:[email protected]] > Sent: Sunday, June 15, 2014 9:06 AM > To: Susan Hares > Cc: t.petch; <[email protected]>; Jeffrey Haas; Edward Crabbe; Russ White > Subject: Re: [i2rs] draft-white-i2rs-use-case-05.txt has been posted > > Susan, > > I like the new format much better. It makes the reading more clear > from beginning. I disagree with REQ10. REQ10 implies that the i2rs > will store data in persistent storage. > > I have another use case for the draft, mobile backhaul. Currently > governments are preparing to release some new spectrum bands for > public usage. It will be a very different approach, as the lease > period will be significantly reduced from 15 years to hours. Idea is > to use small cells with this new spectrum to respond to increasing > demand from mobile users in that geographical area, like a sports, > music venue or certain city areas that get very populated during > certain peak hours. In such cases, mobile backhaul has to be able to > respond to such increase in demand and that will require changing of > forwarding policies in the backhaul. I2RS is a very good match for > that task and following requirements should be listed: REQ01, REQ02, REQ07, REQ08, REQ09. > > Dean > > On Jun 13, 2014, at 9:06 AM, "Russ White" <[email protected]> > wrote: > >> >>> 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:-(. >> >> There are two different "RIBs," at least in theory -- vendor >> implementations may vary. To try and separate things out, let's >> describe a few tables, see if that's a complete description, and then >> try > to name these things. >> >> - There is the set of all the reachability information received by >> any given process. I would correlate this to the BGP-RIB-IN, or the >> LSDB in OSPF or IS-IS. >> >> - There is the set of best paths determined by the particular process. >> I would correlate this to the SPT in OSPF or IS-IS, and the BGP best >> path table. >> >> - There is the set of paths actually installed in the local device >> memory, and off of which the local forwarding tables are built. Each >> process running on the device installs reachability information into >> this table, and there is some arbitration method within each >> implementation designed to determine which process "wins," when there >> are multiple installs for the same destination, as well as "callbacks" >> for when routes are removed, and even perhaps "backup routes," and >> the > like. >> >> - There is the set of forwarding table entries actually used for >> forwarding traffic. Note there may be two layers of these, but they >> typically include mac header rewrites, tunnel headers, and the like >> -- none of which any of the "ribs" described above would contain >> (they would only contain a next hop, not the actual rewrite information). >> >> If there are any I've missed, please feel free to add them in. This >> draft is supposed to be addressing use cases that are centered on the >> third one above in a "generic" way (not specific to some routing >> protocol, > etc.). >> >>> REQ1 last sentence should probably include removing process >> >> I'm fine with including this, but I can't think of a use case off the >> top of my head... >> >>> 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 >> >> It intends to say that both source and destination routing are >> equally valid options from the perspective of installed stuff into >> the RIB (#3 > above). >> >>> 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 >> >> This is akin to remote triggered black holes -- a route to interface >> null0, which can be targeted either through the source (source >> routing) or the destination. >> >>> REQ4 I find vague, as I do anything with the word policy in it:-( >> Something >>> concrete (communities, MED, ...) would help >> >> This isn't really MED (that would fall into the BGP use cases draft), >> but rather mostly focused on setting the next hop, backup routes, >> source routes, and other places where you might forward based on >> things like port numbers, etc. >> >>> REQ6 makes me wonder what is a RIB when it is not local >> >> I suppose it could be remote in some way. Think of the RIB of a >> virtual router that then installs routes using OpenFlow into a remote >> switch -- is the RIB remote, or the FIB? I don't really know... I >> guess it might make more sense just to take the word "local" out here. >> >>> 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. >> >> This is actually restricted to the RIB (#3 above) by the context of >> the draft, but it might be useful to add some restrictive language here. >> >>> 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. >> >> Again, this is implied to be restricted to the RIB (#3 above) by the >> context of the draft. Adding some restrictive language here might be >> useful, or it might be overkill (your choice :-) ). >> >>> 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?) >> >> Time based processing here generally means, "last route installed >> wins, given all equal preferences otherwise," or perhaps, "time is >> the tiebreaker." This area might need work, as this makes the final >> state non-atomic (order dependent). The problem is there's no way to >> ensure everyone is using different preference levels, etc. Any >> thoughts here welcome. >> >> :-) >> >> Russ >> >> _______________________________________________ >> i2rs mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
