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" <ru...@riw.us> 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 > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
