Minutes for I2RS at interim-2015-i2rs-2

Meeting Minutes Interface to the Routing System (i2rs) WG
Title Minutes for I2RS at interim-2015-i2rs-2
State Active
Other versions plain text
Last updated 2015-01-22

Meeting Minutes

   I2RS Interim 2015-01-22

Sue Hares
Jeffrey Haas
Eric Voit
Ignas Bagdonas
Xufeng Liu
Don Fedyk
Carlos Pignataro
Alex Clemm
Dan Romascanu
Sriganesh Kini
Cary Fitzgerald
Alberto Prieto
Dean Bogdanovic
Kent Watsen


Design teams on the wiki. Let chairs know if you want to join team

Presenting: Carlos Pignataro
Ignas: Re: resources required for logging, there may be a long delay between
operation request
 and response.  How do you log the request? Log immediately, or after it
Carlos: I think this is addressed in slide 8. Let me know if that is not the

Slide 9 - granularity. See RFC 3339
Dean: Using nanoseconds, what do you expect to get? The drifts across multiple
systems will be outside the granularity for inter-system comparison. It will be
very precise, but hard to put together. Carlos: nanosecond good for correlating
in-agent but not across systems.  For systems
 that can do this, lets take advantage of it. Main point is we need to specify
Jeff: issues about presentation formats. Human readable is nice - we should
make it an option. Use 32.32 format to allow in-system and inter-system
correlation. Ignas: Correlation context - in agent. Used in perspective of
multiple requests within an
 agent rather than between agents.
Jeff: Difference is in-system correlation vs. inter-system.
Ignas: we are in agreement.

Slide 11
Jeff: Long running transactions need transaction id. Tracing can use this.
Our I2RS protocol is specified as asynchronous,
We need to be submit a transaction and then the routing system
must say "I've got it as a valid transaction", and then
respond later "this is done now."
Due to this, the I2RS protocol will require a transaction id.
This transaction id would be useable here.
Kent: This is correct. The bulk-transfer and interactive CLI presentation
and long-run transaction share this requirements. I sent an email
to the netconf group that described this problem.
The hope is that the solution to this problem would be from restconf
and netconf.
Kent: Bulk transfer and interactive cli drafts/long running requests.
 All of these share commonality of request/response. Put together reqs to
 netconf in mail. Not a lot of response in the wg. Solution will hopefully be
 applicable to both.

Slide 12:
Jeff: We will not be able to fully complete the traceability document until
 completed long-running transactions.
Carlos: How do we want to address this for now?

Sue: Are you asking about the technical or process piece?
Carlos: What type of text should we add?
Jeff: Likely a opaque text string is sufficient?
Sue: Problem statement should be added as pointer into document. Leave
editorial note. Carlos: Makes sense to me.

Next steps:
Asking for WGLC next ietf? This is a simple document.
Sri: Field, actor-id is first place that it is defined. Last interim -
discussed broker model/secondary id? We should reconcile the terminology?
Carlos: Good point. Let me see if we are referring to actor-id as secondary
identifier.  We will take care of this. Kent: Just forwarded email to i2rs
related to this.  There has been no discussion about it since that mail. Sue:
Do you think the reqs should be done in i2rs and solution in netconf? Kent:
Seems reasonable.

[Pub-sub model]
Presenting: Eric Voit

Dean: When you say yang data stores, this is the data that is l on the yang
data that was created? Eric: Correct. Dean: Do you have to be notified when the
yang data is changing? Eric: There is certainly version control on the yang
models. What we're trying to understand
 is if individual objects in a model is changing.  Frequent changes on specific
 objects. This requires good hygiene on version-ing of individual models.
Dean: I understand, thanks.


Eric: Want to make this a WG draft.  Would like feedback.
Jeff: I think this captures our requirements and should be adopted.
Sue: Me too.
Dean: Also agreed.
Don Fedyk: If a request is resource intensive, what are the rate limiting
mechanisms? One valid response is a partial response, then indication that you
have exceeded. Eric: That would be a good thing in requirements document, along
with the mechanism
 in the technology doc.  We have not pointed out how to do the analysis. Point
 for progressing the document.
Alberto: We are considering two mechanisms, when pub gets request, the client
gets an indication what can be fulfilled at subscription time.  Ongoing, the
publisher provides indication how things may change.  E.g. suspended. Eric:
What does exhausted means will vary depending on objects, etc. Want to put
together a quick demo code of how such a mechanism would work. Can demo at a
future meeting? Sue: I would be interested. Kent: The initial transport focus
was netconf, assuming also restconf. Wondering about other transports. If
netconf/restconf is the control channel, but the subscription was something
that was binary - that is the data plane. For the transports do you mean just
the data? Eric: Just the data. Kent: I agree with that. Since the mechanism may
use other data transports than netconf, that means that group aside than
netconf may also have to be involved? Eric: There may be the ability to change
the transports.
 We have not identified how to jump between transports¬Ě.
 Not asserting how that would look like today.
Xufeng: Subscription - per client basis? Clients interested in different
portions of tree, they may get different kind of notifications? Eric:
Subscriber will target the specific nodes of interest.  Clients may vary on
what they are interested in. Kent: In the reqs doc, like to see non-functional
requirements such as max number of clients that will be supported?  If the
requirement is supporting some number, that may impact implementations. Eric:
Can consider it.  Negotiation pattern can help with this. Different limits for
different boxes. Jeff: SNMP has counter examples. Proxies may help. Not a
common use pattern in SNMP.  May need to suggest that this pattern be
considered in our reqs doc? Eric: With a highly resource intensive stream, it
may be useful to a multicast transport. We have not quantified this issue yet. 
We must address this issue. We'd love to have additional authors and help.
Jeff: As long as the subscription mechanism looks like netconf or restconf, we
have the ability to specify data models.  We have the ability to use middle
boxes to proxy this data. If we gather routing statistics from router A and
router b. For example, if you use interfaces from one box and a second box; the
middle box must be able to distinguish between the two boxes. This must be
handled as the "meta" data outside the stream. Eric: We have multiple systems
going to the subscription service. We are trying to get the right boundaries so
that we can handle the boundaries of the middle box service.

Sue: Will begin a WG adoption for this on the list. Please send chairs your
comments. Should happen in a week.