---- Original Message -----
From: "Jeffrey Haas" <[email protected]>
To: "t.petch" <[email protected]>
Cc: "Jeffrey Haas" <[email protected]>; <[email protected]>
Sent: Tuesday, June 10, 2014 2:41 PM
> Tom,
>
> Thanks for the comments.
>
> On Tue, Jun 10, 2014 at 12:12:35PM +0100, t.petch wrote:
> > but reading Architecture, the examples I see are ones that seem to
fall
> > within the remit of NETCONF (being config) as and when a suitable
data
> > model has been defined (e.g. for OSPF or BGP). Initially I had
thought
> > of several things that I2RS might do but these have been ruled out,
>
> It'd help if you listed the ones in question. Some of these things
may be
> part of the work that is left currently out of scope to attempt to
constrain
> the WG to things we have decided to get done first. (Don't bite off
more
> than you can chew.)
e.g.
6.2.3. Reversion "In all such cases, the state will revert to what it
would have been without the I2RS; that state is generally whatever was
specified via the CLI, NETCONF, SNMP, etc."
which seems to say that C(LI)/N(ETCONF)/S(NMP) set it to X, I2RS sets it
to Y then disappears so it reverts to X, for all values of 'it' - i.e.
'it' is what NETCONF would call config and so could have been set by
NETCONF, no need for I2RS!
6.3. Interactions with Local Config "Changes may originate from either
Local Config or from I2RS."
Taking Local Config to be what NETCONF/YANG calls 'config' then again,
nothing there it seems that C/N/S cannot do
6.4.2" o writing policy information such as interface attributes that
are
specific to the routing protocol or BGP policy that may indirectly
manipulate attributes of routes carried in BGP.
o writing routes or prefixes to be advertised via the protocol"
I had assume that I2RS might write to an IGP LSDB or BGP Adj-RIB but the
I-D goes on to say
" direct modification of the link-state database MUST NOT be allowed"
(which I have seen on the list w.r.t. the BGP RIB).
or
8" The interaction of state installed via the I2RS and via a router's
configuration needs to be clearly defined."
which again implies that I2RS and C/N/S are writing to the same data.
The examples of data that can be changed are few, such as
"For example, the interaction with OSPF might include modifying the
local routing element's link metrics, announcing a locally-attached
prefix, .."
which leaves me wondering, do you expect an OSPF YANG model to be unable
to change a link metric:-)
Whereever I look, I struggle to see what I2RS will write that C/N/S will
not.
If I2RS were aiming at a higher level, say specifying policy and have
the system translate that into actual config changes I would understand
that, but I do not see I2RS going that far, rather when I2RS says
policy, I think it means changing a community (config again) or some
such ie more of an implementation detail than a high level strategy.
Tom Petch
>
> > either on the list or in this I-D, so I am left wondering what it
is
> > that I2RS will do that NETCONF potentially cannot.
>
> The longer term question and netconf/yang continue to evolve (perhaps
with
> impetus from our use cases) will generally be what work belongs in
various
> groups. Yang modules are being proposed in the various working groups
to
> cover protocol specific configuration and general management. This is
> great! The question then becomes, where does I2RS fit into that sort
of
> picture.
>
> One of the reasons I think nailing down specific requirements (as Jim
Uttaro
> raised in a separete response) has come down to the somewhat nebulous
> ability to interact with functionality that is either not quite a fit
for
> standard config/query or interact with models that are one or more
levels of
> abstraction above a given protocol component.
>
> The degenerate case - the ability to ephemerally inject static routing
> information - certainly seems like work that could be done outside of
I2RS.
> Definitely so if it is decided that the ephemeral model is something
that
> becomes core to netconf/restconf. (The question of how this is
represented
> in the data model is the longer question.)
>
> Where the use cases start getting more substance are when we get
somewhat
> more abstract:
> - An API to the traffic engineering state in a routing system. This
is not
> just the OSPF, IS-IS or BGP-LS TEDBs, it's a summary view. Which
working
> group produces that model if done on a per-protocol basis?
> - A policy layer on top of BGP. That's perhaps in-scope for IDR or
GROW.
> As you definitely know (:-) ) such a policy layer will interact with
a lot
> of non-BGP components and potentially other databases.
> - A management layer to provision VPN instances (service layer
routing).
> Does that work get done in IDR? MPLS? L2/L3VPN?
>
> And of course, there's the whole matter of how do you bring together
> contributors with expertise in modeling, operations and the mix of
routing
> and other protocols in question and where do you do it? From the
first BoF,
> it was clear there are a lot of people who want to work on the things
that
> fall in these nebulous gaps between working groups.
>
> I2RS is here to be the big tent to let us gather people under to do
that
> sort of work. Maintaining enough focus to make progress on a
constrained
> number of items is the main early challenge. A survey of the use case
> documents should definitely suggest there's a lot more that people
would
> like to work on.
>
>
> > I do find the I-D quite hard to follow as the terminology seems
> > inconsistent - the word 'state' is much used but it is unclear to me
if
> > the term can be given a single definition in this context; and even
if
> > it can, the word seems an unfortunate choice since the IETF Ops Area
has
> > given it a precise definition which is at odds with its use here.
>
> Are there specific edits you would suggest to clarify the document?
>
> -- Jeff
>
> _______________________________________________
> i2rs mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
