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
Dean On Jun 15, 2014, at 4:52 PM, Susan Hares <sha...@ndzh.com> 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:de...@juniper.net] > Sent: Sunday, June 15, 2014 9:06 AM > To: Susan Hares > Cc: t.petch; <i2rs@ietf.org>; 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" <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
