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
