Here is my suggestion based on:
draft-atlas-irs-problem-statement section 3
draft-keyupate-irs-bgp-usecases
draft-white-irs-use-case-00.txt section 2
draft-white-irs-use-case-00.txt section 3
draft-white-irs-use-case-00.txt section 4
draft-amante-irs-topology-use-cases
My
My only objection here is the words at least... I think we want to
restrict the charter at this point, not set ourselves up to increase
scope from the start. I think we're looking for an upper bound, not a
baseline.
I understand that important reason, but I prefer not and leave it as
I2RS facilitates real-time or event driven interaction with the
routing system through a collection of control or management
interfaces. These allow information, policies, and operational
parameters to be injected into and retrieved (as read or by
notification) from the
Thus - the framework is the skeleton of what is desired and required in
i2rs, giving the
scope and reasoning. Perhaps it should turn into a requirements draft?
IMHO, this hits the nail on the head.
:-)
Russ
--
riwh...@verisign.com
ru...@riw.us
- If a process wants to inject information at A, then it can simply
participate in the routing protocol in question --so I2RS doesn't really
need to do anything there. In fact, I would argue that injecting
information at A without participating in the protocol could be very
1. Within your Routing Process boxes, I think what you mean by A
is the injection of the same type of raw data the routing process
receives from normal protocol neighbor (e.g., LSAs for OSPF,
paths/NLRI for BGP). By B, I think you mean injecting items that
are the product of the routing
No, but I did try to address at least a partial list in one of the use cases
draft. I think this would really entail building a data model for the entity
officially known as the rib. Is the current YANG model a good solution to the
question? It seems like we should answer that question before
I wouldn't frame the question in terms of the packet header but the routing
table... I don't know that the answer comes out different, but... :-)
That said, I think a good base set would be:
- Dest IP Address
- Next hop IP address
- Outbound interface
- Admin distance
- Some form of tags
-
Actually, several folks talked at lunch, and defining the data model first
might be precisely the wrong thing to do... Let me just throw it out for
discussion--
Is it better to define the information needed to forward a packet as a data
model, so we simply leave the problem of defining a rib,
- Also decoupling of life cycles (e.g. between an application and the
network
functionality) is one problem which needs
to addressed. At the moment in many cases there is (still and
unfortunately) a close relationship between a (network)
service and the configuration of the network
Joel:
However, I do not understand how using I2RS would substantially help
address the actual difficulties. These are not problems that depend upon
topology knowledge, nor are they tasks that are generally driven by
application interfaces. (The VPN case may be an exception to the later.)
Please review draft-keyupdate-irs-bgp-usecases-02 and comment on
whether it should be adopted by I2RS. Detailed technical conversation is
also
most welcome.
I was under the impression that this was being merged with
draft-white-i2rs-use-case... Did we decide to carry all these use cases
My original intent here was to provide a name to something that
aggregated all the routing-instances.
Obviously as many have pointed out, giving it the name of rib was a bad
choice.
So we have 2 choices:
- Remove the top-level object in the grammar (rib) completelyŠand instead
start off
I don't know about the global RIB, but one thing that
should be modeled is the box within which all the RIBs exist.
I would prefer not to get into modeling the physical box, or anything else
that reaches outside the routing system. IMHO, we're already trying to boil
the ocean... We should
A bit. The discussion of treating multiple writers for the same state as
errors
got me worried about this case - from a redundancy perspective, and to a
lesser degree, accountability standpoint.
Given the importance of reliable operation even in the case of client
failures,
I think the
There was a lot of good discussion about this draft. There were
significant
concerns about what parts should remain in the draft (e.g.
configuration related) and what to do with the BGP-related uses cases in
draft-white-i2rs-use-case.
The first question should be --do we want to call it a
If an implementation wants to store the data, more power to them. If
there
is a syslog format or a file dump format defined outside I2RS for
reporting the
data, great.
But I do not want I2RS mandating storage or reporting of the data. That
is not
our job.
Agreed --but I think the question
The on-the-wire representation is insufficient. It doesn't include things
like
time, client identity, transport connection information, etc.
Two points to consider:
1. As I've said elsewhere, we need to focus our scope if we're to make
progress.
2. It seems, to me, that these are actually
I think we should. Because if there is a crash from the Agent, how then
can an admin purge state? There would no longer be a clean way to do
this. I'm trying to think what an operator might like here.
IMHO:
- no heartbeat or any other persistent connection
- if the controller crashes, on
This approach is fine with me, too. I just didn't know if a heartbeat
would be
less desirable than having the Agent maintain a list of interested
Clients.
Okay, I'm lost in the terminology again. :-) I think of the controller as
being the off box device that's doing the injection, while the
Characterizing every possible QoS model is practically impossible. Do you
have any standard model in mind that would be suitable to use as a base ?
I was thinking about something around the diffserv work, possibly RFC4594
figures 3 or 7, perhaps. We might get someone who was more deeply
I think a variety of filtering is possible. I can start creating an
exhaustive
list.but need more input from WG (esp from those who intend on using the
RIB model from a RIB client) on what would be useful to them. Here are a
few possibilities.
Rather than trying to come up with every
At the IETF I2RS interim meeting, I raised the concern about conflicting
set
operations by I2RS clients to different I2RS agents,
Which may end up causing micro-loop or far-side loop.
There's no way, in this sort of architecture, to prevent people from tying a
noose in the rope. :-)
OTOH,
The problem with enforcing consistency in this environment is it would be just
as impossible to attain as it is with a distributed control plane in real time.
It seems, to me, that we can provide an interface, but the controller/software
doing the controlling must do the consistency insurance,
May be I2RS clients need to get ‘permission’ from an orchestrator or
“an I2RS-coordinator” before issuing ‘set’ operations to I2RS agent?
Backing up a little in the thread --this, specifically, is what we want to
avoid. We don't want a lock/release, or a transaction oriented protocol to
I think what I am saying is that (a) there is work going on outside of
I2RS and
we better avoid overlapping activities and (b) I like to remind you that
work
can be split and it is not necessary that I2RS creates all data models on
its
own.
Of course! The first point seems to be to decide
And arguably the most important relationship is between the protocol
network models and the RIB model.
After that, the next most important aspect of the protocol network models
is
their policy modeling.
Agreed -- which is why the RIB model is so important to get right the first
time.
:-)
These might (or might not) be helpful... :-)
Russ
==
I found the opening paragraph a little confusing, or perhaps blunt, in
terms of describing the problem with terminology the average reader might
not understand. Maybe something like:
Service chaining treats a network as a set of services
And the basic premise of I2RS is that there are requirements for the work
that were not addressed properly by the existing configuration protocols.
Otherwise the WG would not even need to discuss protocol modifications.
So the fact that NetConf / YANG works for device configuration does not
But the point is that a more realistic choice should be between these two
choices.
Why?
:-)
Russ
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs
Can you explain how an off-line representation of the data model can be
fast
or slow?
Marshalling can still be fast or slow. I'm not convinced that YANG, being
focused on management, rather than protocol level interaction, doesn't have
a lot of stuff that's not needed, and does have all the
Some thoughts on draft-bitar-i2rs-service-chaining-01...
==
This document describes use cases and I2RS (Information to the Rousting
System) requirements for the discovery and maintenance of services topology
and resources.
==
Rousting/Routing
==
Several networking scenarios involve applying a
I have a question and a potential usecase. I was reading the charter today
and it mentioned some fairly specific usecases. I've been thinking of
another
fairly specific class of usecase that I had hoped I2RS would deliver.
If this new use case would add some specific new capability to the
As mentioned elsewhere, I tend to perceive I2RS's impact on the network as
being similar to that of a routing protocol. If I want something I do to
a given
device to propagate, the state that is injected must either be suitable
for
injection into another routing protocol (redistribute into
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
I would agree with this assessment -- support without the yang model. A more
generic multiple model might be nice if we need the illustration... Yang should
be in a separate draft.
:-)
Russ
On Jul 23, 2014, at 1:37 PM, Joel M. Halpern j...@joelhalpern.com wrote:
I would like to see the
If objects that are always intended to be ephemeral are never going to
conflict (but may lie on top of) local config, there is never a conflict.
There is simply referential integrity issues if the underlying local
config is
deleted and ephemeral config remains.
If the objects are always
It's important to be really cautious and not conflate this as being just
as
simple as static routes. For cases that look just like a routing
protocol, sure.
But some of these cases are closer to extending existing configuration
state,
not injecting new forwarding state.
So the case we're
Policy is dynamically changed in lots of ways. Again, it has to make
sense in
the system.
What we need to do is separate policy from policy instruments... A community
string, metric, etc., is _not_ a policy, it's a policy instrument. In
other words, an I2RS policy can change a community, but
[Don] I agree. We need to define semantics for the datastore and
predictable results for the writable running state or active
configuration. It seems to me if there is priorities and overlap
with various datastores there should be blocking or overriding of
ephemeral data too.
If we stuck
Support adoption as a WG doc.
:-)
Russ
-Original Message-
From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Mach Chen
Sent: Wednesday, November 26, 2014 3:22 AM
To: Susan Hares; i2rs@ietf.org
Cc: 'Jeffrey Haas'; 'Alia Atlas'
Subject: Re: [i2rs] WG Adoption call for
What state do we want to change via I2RS?
The original intent was specifically state in the routing table, not --
As far I know, we wanted to allow i2rs agent to change any supported state
on the device. If that is still the case, then we need to go through the
Or rather, the only
Then we really have to write up use cases, settle on requirements and
decide on the protocol.
The original use case documents covered this specific situation. We decided
to expand the use cases for future use, I think, which then led to trying to
solve all the problems listed there in the
Interesting concept. One thought that might be helpful --
* Firewall
* DDOS/Anti-DOS
* Intrusion Detection System/ Intrusion Prevention System
(IDS/IPS)
* Access control/Authorization/Authentication
I think I would try to frame things in terms of services,
> ideas of store-if-not-best and handling overwrites and so on. There was a
> very clear push back against any such complexity. Feel free to take a read
> through the archive.
IMHO, then, is severely diminished to the point of being non-useful work. If
there is no way to store a "backup
> It is quite clear that caching is not required to meet a <1 second loop.
Given several comments on the list recently that RESTCONF isn't going to be
able to meet these sorts of timers, I'm not certain... Further, I'd like to
see a timer that's tighter than 1sec -- fast reroute needs to happen
Y'all --
After some thought on the entire ownership and subscription issue raised
yesterday in the WG meeting -- to repeat the problem for those who weren't
there... If an application/controller installs state into a particular agent
running on a particular network node, what should we do with
Y'all --
After sleeping on the discussion last night, I think the panes of glass (or
is it pains of glass?? :-) ) is still by and large another expression of
the priority concept within I2RS. The concept does bring up one specific
point of interest, however -- what about backup information? Some
> For example, if state gets over-ridden, but preserved, then even though it
is
> not doing any good, the client which installed the state must still
monitor for
> any related dependenecies so as to not leave incorrect pending state.
> Which also means that a client has to be able to remove state
> The notification to a client that some or all of its data was just overridden
> is a
> separate matter from whether the client wants all or part of its data to be
> removed or altered.
I would argue this should be a SHOULD... The idea would be that any client who
sets state should be
> However, I still feel that we are dealing with a limitation of the YANG
> framework here. I think we are dealing with a use case that was not
really
> foreseen in the YANG design, i.e. that we might run into data that has
> instances that can indeed be authoritatively owned by a server versus
> Allowing caching means that we have to specify additional mechanisms (such
> as read-through and write-through, and returns for successful writes that
do
> not actually take effect, and probably other aspects.)
I don't really see it as "caching..." I'm thinking more of the backup route
> Re the metric 'problem', just to be more precise in what would be needed,
> we are looking a metric that grows or decreases monotonically across the
> whole network.
I assume you mean in the routing space, and not in the controller/client space,
correct? In terms of a distributed protocol?
gmail.com>
> Subject: Re: [i2rs] new I2RS chair: Russ White replacing Jeff Haas
>
> Thanks! It's been a pleasure to serve.
>
> While day-job pressures are having me step back from quite as much IETF for
> a while, that won't last forever. :-)
>
> -- Jeff
>
>
>
Y'all --
Based on the last call started here --
https://www.ietf.org/mail-archive/web/i2rs/current/msg03528.html
it looks like the WG has consensus on adopting:
draft-kini-i2rs-fb-rib-info-model-03
draft-hares-i2rs-fb-rib-data-model-03
draft-hares-i2rs-pkt-eca-data-model-02
as WG docs. Can
>Can you expand on the 2 sorts of RPF checks already out there. And then
> we can figure out which ones we need to include for now. If need be, then
> we can make RPF check into an object as you are suggesting.
Sure -- There is loose (just check to see if you have it in your table at
all)
Y'all --
More comments, this time on draft-ietf-i2rs-traceability-06. These are
minor, but they're related to operation rather than straight nits.
:-)
Russ
==
If the operation timed out, then this field will contain an all-zeroes value
of "-00-00T00:00:00.00". Given that many I2RS
Y'all --
draft-ietf-i2rs-rib-info-model-08 says --
==
Each RIB can be optionally associated with a ENABLE_IP_RPF_CHECK attribute
that enables Reverse path forwarding (RPF) checks on all IP...
==
But there are at least two sorts of RPF checks already, and will probably be
more in the future.
> What do you mean “in your table at all”? The RIB normally only includes the
> best path for each RIB client. RPF is normally only on the best path.
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_data_urpf/configuration/15-s/sec-data-urpf-15-s-book/sec-unicast-rpf-loose.html
This is
> The I2RS provides a framework for registering and for requesting the
> appropriate information for each particular application. The I2RS provides
a
> way for applications to customize network behavior while leveraging the
> existing routing system as desired.
> Sue: Registering and requesting
> The working group has agreed that such priority can always be applied.
> An operator can choose to not to. But an individual model can not say
> "priority does not apply to this model."
I read what Sue has proposed in the opposite way -- that there is a per
model flag that says the operator
> The harm from persisting the data is in terms of robustness, not in terms
of
> interoperability. With multiple interacting clients, and allowance for
lowered
> error checking, things can go wrong.
And in terms of what I2RS is setting out to do -- we're not trying to
configure the box in a
(wg chair hat off) --
> I think the idea of extending I2RS priority to local config operators
(e.g., CLI)
> will still work. Let's take knob 1. Knob 1 is kind of like the on/off
switch. If I
> don't want I2RS to have any effect on operational state, I'd have this
off. In
> the I2RS priority
> Ephemeral-REQ-07: Ephemeral configuration state MUST be able to set a
> priority on local configuration and ephemeral state. Based on this
priority
> implementations MUST be able to provide a mechanism to choose which
> takes precedence. The I2RS Protocol MUST be able to support this
>
> The email subject and the content of the email are different.
> Are you referring to the draft on ephemeral state or on the RIB info
model? I
> presume it is on RIB info model, but will let you clarify it
Ephemeral state! Copy/paste error.
:-)
Russ
I do not know of any ipr related to this draft.
:-)
Russ
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs
> Support WG LC. ODL implementation have improved and matured this draft.
+1 -- support as WG member.
:-)
Russ
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs
Y'all --
The I2RS WG LC on the RIB Informational Model completed on the 15th of
August. We let it run a little long, but it appears the WG has reached
consensus on this document. The next steps for this document are Shepherd
reviews and routing-area reviews prior to submission to the IESG.
Russ
Y'all --
I would like to suggest we add one more next hop type in section 2.4 of
draft-ietf-i2rs-rib-data-model, and sections 2.4 & 7.2 of
draft-ietf-i2rs-rib-info-model to include a nexthop type that tells the
forwarding device to not use a particular next hop without sending traffic
to
Y'all --
There are currently ongoing discussions on the NETMOD
(https://mailarchive.ietf.org/arch/search/?email_list=netmod) and NETCONF
(https://mailarchive.ietf.org/arch/search/?email_list=netconf=w#)
mailing list for rechartering those working groups. The chairs of I2RS would
like to encourage
Y’all –
It looks like all the comments received during the last call have been
addressed, so Sue and I will close this last call now and move the document
forward.
Thanks!
/r
___
i2rs mailing list
i2rs@ietf.org
Y’all –
We currently need shepherds to carry these drafts through to publication—
draft-ietf-i2rs-rib-data-model
draft-ietf-i2rs-rib-info-model
draft-ietf-i2rs-security-environment-req
draft-ietf-i2rs-yang-network-topo
draft-ietf-i2rs-yang-l3-topology
The shepherding job is really
Y'all --
The last call for publication for draft-ietf-i2rs-rib-data-model and
draft-ietf-i2rs-yang-l3-topology started on 11 July; we have received
support in the WG for these drafts from several folks. There were, however,
comments on and changes to the draft, so we will initiate a short (one
Y'all -
I started a last call on draf-ietf-i2rs-security-environment-req-05.txt on
the 4th of June, and received two comments, both stating there was no known
IPR on the draft. It is well past the time to close the last call on this
one, and call it done. The chairs will move forward with
Y'all -
The I2RS WG is starting a last call on draft-ietf-i2rs-yang-network-topo.
This last call will last for two weeks, after which time the WG will select
a shepherd, ask for directorate reviews, and move this document towards
publication. Please respond on list with comments on the draft,
Y'all --
This is to initiate a two week working group last call on
draf-ietf-i2rs-security-environment-req-05.txt. Please send your comments to
the I2RS wg mailing list (i2rs@ietf.org). If you approve of accepting this
document in its latest revision, please note whether or not you have read
the
Y'all --
This is to initiate a two week working group last call on
draf-ietf-i2rs-security-environment-req-05.txt. Please send your comments to
the I2RS wg mailing list (i2rs@ietf.org). If you approve of accepting this
document in its latest revision, please note whether or not you have read
the
77 matches
Mail list logo
