Part two, on the specific Q. Tom Petch
----- Original Message ----- From: "Russ White" <[email protected]> Sent: Friday, June 13, 2014 2:06 PM <snip> > > 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... Nor can I , but the first sentence talks of instal and remove, the last sentence only of instal; I would like the two to be in line. > > 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). I would reword it to say "source based routes, and destination based routes" (unless you mean 'source-and-destination based routes') > > 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. Again, it is a matter of wording, I am guessing that what you mean is "The ability to install a route for a given prefix to a null 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. OK, I did not really think MED but wanted something concrete:-) Again, adding a few words makes such a difference, such as "The ability to interact with various policies configured on the forwarding devices, such as by changing the next hop, backup routes and such like, ...." > > 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. Yes, WFM > > 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. Yes please - I think that when you move from the context of a discussion of a specific revision of a specific I-D on a WG mailing list to a published I-D, then what was clear may become too vague to convey the intended meaning > > > 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. Tom Petch > > :-) > > Russ > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
