Susan,
Following find my comments in re this document..
General Comments.
1) There is a need to better define what is meant by the "halfway
point" between completely replacing the distributed control plane and
configuring it all. It would seem to be that this "halfway point" is different
based on what is being programmed. To that end it would be useful to call out
higher level reqs some suggestions.
2) Dissemination Scope of an I2RS Instruction Set ( Block of
instructions intended to be atomic ) - An instruction set may be local or
global in nature as it pertains to affected the distributed control plane when
configured on a network element.
a) A locally scoped instruction set may configure routing
state in the RIB for comparison purposes but that state may not be disseminated
via the distributed control plane.
b) A globally scoped instruction set must configure routing
state in the RIB for comparison purposes and that state is available for
dissemination subject to any other policy.
3) Ephemeral/Persistent Scope of an I2RS Instruction Set
a) Should the instruction set persist? What comes to mind for
me are the "configuration" like changes i.e RT-C, FlowSpec .
4) Liveness/Safety Properties - Would like to see some discussion in re
these items.
5) Uses Cases - I believe addl use cases whose focus is on
configuration like services would be desirable. As an ex.. RT-C..
Specific Comments
C1 - P1 - Para 2
..." Such a system would not interact...." The paragraph uses a routing
and best path selection as an example. I assume that this not limited to this
application but spans configuration like state etc....
C2 - P3 -Para 1
"This represents a "halfway point" ..." This needs a clearer
definition, I would suggest wording regarding how the distributed control
plane will be augmented by the addition of I2RS
C3 - P3 - Para 3
"...Each unique has been" Typo missing the word reqs.
C4 - P3 - Para 5
The reaction to Network Based Attacks may also include other actions
i.e mirror, drop ...I assume you are not limiting the response to the attack to
only re-direct.
C5 - P4 - Para 4 1st Bullet
Can the I2RS agent interact with other tools and get the desired info
in this case available routes in the RIB? In general can I2RS provide a
framework to collect data from multiple sources including directly from a
router, RR, NM?
C6 - P4 - Para 4 2nd Bullet
Need to describe in how state learned via I2RS agent and state learned
via distributed control plane interact across the set of applications ( See
Above General Comments. )
C7 - P5 - Para 4 3rd Bullet
What is the ask for here? Is there a consistent definition of /dev/null
being sought?
C8 - P5 -Para 4 4th Bullet
Not sure what this req is. Is it saying the policies configured via
distributed control plane, local and/or via I2Rs should have some form of id?
Why is this needed if the policy no matter where it is learned is recorded in
the running configuration??
C10 - P5 - Para `1
"In hub and spoke..." There are other hub/spoke solutions i.e Virtual
Hub Rekhter et al...that do not rely on a centralized server.
Jim Uttaro
-----Original Message-----
From: i2rs [mailto:[email protected]] On Behalf Of Dean Bogdanovic
Sent: Sunday, June 15, 2014 9:06 AM
To: Susan Hares
Cc: Jeffrey Haas; <[email protected]>; Russ White; Edward Crabbe; t.petch
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
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
