Subject: [i2rs] Agenda for IETF 91 - Honolulu uploaded

From: Jeffrey Haas <[email-masked]>
Date: Sun, 9 Nov 2014 18:42:11 -0500

Working Group,

My apologies for the late upload of the agenda.  Your chairs crossed streams
about who had the token to do the post. :-)

The agenda for this session has been kept intentionally limited.  The
mailing list has been generally quiet aside from the discussion surrounding
the netmod interim in New York City earlier this year.  The goal for this
meeting is to try to reach some closure on this core issue or, if not
closure, to advance the discussion in a productive fashion.

One item I would like to proactively draw the working group's attention to
is the mount-point drafts:
http://tools.ietf.org/html/draft-clemm-netmod-mount-02
http://tools.ietf.org/html/draft-voit-netmod-peer-mount-requirements-00
(Note that Cisco has asserted IPR against these drafts.)
These drafts, while not specifically targeting I2RS use cases, cover some of
the same underlying issues as the I2RS ephemeral state requirements.

That said, there's been a lot of productive i2rs related work happening
elsewhere.  Examples include i2rs use case implementation details against
other protocols and work on topology models.  Authors of i2rs related drafts
are encouraged to discuss things on the mailing lists to keep the work
fresh.  We believe we should be requesting adoption for some of these drafts
soon.

-- Jeff

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 10 Nov 2014 08:34:23 +0100 (CET)

> the same underlying issues as the I2RS ephemeral state requirements.

Jeff, can you elaborate?  I don't understand how the mount technique
is related to I2RS ephemeral state.  mount is a way to incorporate
data from some datastore into another, and this seems to be orthogonal
to I2RS requirements for ephemeral state.

/martin

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 10 Nov 2014 11:14:05 -0500

Martin,

> to I2RS requirements for ephemeral state.

The main reason to draw I2RS attention to the draft is not that it intends
to solve the ephemeral state issue but that the remote-mount technique runs
into the same consistentcy issues that were problematic for ephemeral state
systems when the ephemeral state had become out of sync with the local
static config.

The remote-mount draft suggests an "eventual consistency" model.  While that
concept is not directly analogous to our likely solution space, the need of
the system to be able to deal with temporary inconsistency is one that has
good use when talking about our ephemeral state problems.

A second thing that I found useful about the draft is that, should I2RS
decide to not permit overriding of configuration state via ephemeral state,
the mount-point concept provides some use cases to demonstrate what you
could do.  The ability to override hasn't been explicitly accepted as
something we *must* do in I2RS and has been a source of something that makes
things hard.

-- Jeff

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 10 Nov 2014 19:39:32 +0100

Hi,

back in October I asked on the NETMOD mailing list how state is merged
into the configuration if I mount a remote datastore and whether that
resembles ephemeral state as discussed in I2RS. The response I got was
a "this depends on the logic of the specific application" answer. I
hope that I2RS will go for more precisely defined semantics.

/js

On Mon, Nov 10, 2014 at 11:14:05AM -0500, Jeffrey Haas wrote:
> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>