Subject: [i2rs] drafts planned to ask for WG adoption

From: Alia Atlas <[email-masked]>
Date: Fri, 12 Jul 2013 15:41:38 +0000

Ed and I plan to ask about consensus for working group adoption for the following drafts:

draft-atlas-i2rs-problem-statement-01  (to be published later today/Monday)
draft-atlas-i2rs-architecture-01 (to be published later today/Monday)
draft-keyupdate-i2rs-bgp-usecases-02 (just published)
draft-nitinb-i2rs-rib-info-model-01  (to be published Monday)

We intend to conclude the WG adoption discuss on August 12.  Please read and focus on these drafts.
We hope there will be other drafts ready to consider for WG adoption - but this is the first clear set.

Thanks,
Alia

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 12 Jul 2013 13:29:02 -0400

Looking at this draft, it has a number of very helpful use cases.
I support adopting this draft by the working group.

I do have two questions about one aspect of the content.  Section 2 on 
BGP configuration describes a number of complicated problems in current 
BGP configuration.
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.)
More importantly, these seem to be configuration operations which should 
be essentially permanent and fully integrated with the basic 
configuration of the device.  My understanding is that I2RS is not 
intended to supplant that base configuration.  Possibly I am confused in 
this regard?

Thank you,
Joel

> Ed and I plan to ask about consensus for working group adoption for the
...
> draft-keyupdate-i2rs-bgp-usecases-02 (just published)
...

---

From: "Russ White" <[email-masked]>
Date: Mon, 15 Jul 2013 08:15:44 -0400

Joel:

> address the actual difficulties.  These are not problems that depend upon
> topology knowledge, nor are they tasks that are generally driven by
> be essentially permanent and fully integrated with the basic configuration
of
> the device.  My understanding is that I2RS is not intended to supplant
that
> base configuration.  Possibly I am confused in this regard?

I think you bring up an important point here... It seems, to me, that I2RS
got off to a good start with only dealing with one specific area of use
cases --where knowledge of the topology is important, and hence interaction
would primarily be with the routing system at the layer 3 forwarding table.
It seems, to me (anyway), that we've since moved into the realm of
"configuring anything that has to do with routing," which means replacing
existing mechanisms rather than simply supplementing what's already there
with "new stuff." 

I.e., we're trying to boil the ocean, and, "the ocean ain't gonna be
boiled."

By moving into the "pure" configuration space, we've opened up the same
argument space that has plagued MIBs verses YANG verses ... for years. Which
has made for some entertaining reading, to be certain, but... I'm not
certain we should have slipped our scope to take on such a huge problem so
quickly.

Maybe we should try and regain some focus here. If we can solve the problem
no-one else solves (interaction with the routing system, beginning with the
simple stuff, like just interacting with the layer 3 forwarding table), then
we can branch out and start looking at routing policy, and then out into
other things, like provisioning, etc. At each step of the way, we should
seriously consider what "new thing" we can bring to the table, to make
certain we're not just putting the second bake on the potatoes.

Just my 2c. --feel free to disagree, or to just tell me I'm all wet.

:-)

Russ