Topic: I2RS Protocol requirements
Agenda:
Attendees:
Susan Hares, Jeff Haas
Joel Halpern, Ignas Bagdonas, Jie Dong, Yuji Tochio, Jan Medved, Andy Bierman, Linda Dunbar
0. Agenda Bashing [22:00-20:05]
1. Overview of I2RS Requirements [Sue Hares] [22:05-22:30]
Discussion:
Sue: We will walk through ephemeral protocol requiremens
Jeff: These first slides are context.
Sue: I will revise the slides to indicate this for others.
Dean: The occluding case is complex, but if you just use overriding it is much simplier.
Jeff: I agree.
Dean: I would avoid having config over ephemeral.
Jeff: One possible decision for the protocol design team.
Dean: I would drop config over ephemeral, and only do ephemeral over config.
Jeff: These first slides are only introductory, and I think this is a good idea
Linda: You mentioned that ephemeral state survive restart.
Jeff: Thinking about IPv6 that resembles operational state,
Joel: We can never get that i2RS will exist before configuration state.
Jeff: The requirements do not use this combination.
Linda: Can you make this clear in the draft?
Sue: Any text suggestions are helpful. Let's review the actual draft.
Some of this may be new text.
... After Ephemeral-REQ-01
Sue After Requirement 1, Linda does this answer your concern?
Linda: You have address my concern on this.
After Ephemeral-REQ-03
Jeff: For requirement 3, this is a completely new thing for NETCONF.
Sue: We are missing Ephemeral-REQ-05 which deals with what
it meanst that data is ephemeral. The data must be able to have the
property of writable or not and ephemeral or not.
Dean: Ephemeral-REQ-06 - how is this different than config.
[Scribe notes: It may be different]
Joel: You are not dealing with config, you are creating writeable by ephemeral.
Jeff: In a NETCONF sense, to say Config TRUE, it means
- a) to write something in writeable running
- b) that it is stored in the data store.
For emphemeral we need something that
a) writeable
b) ephemeral
Linda: You have writeable and non-writable.
Ephemeral is under write/unwriteable.
Joel: This is different than what ephemeral-REQ-05 and ephemeral-REQ-06 state.
LInda: You are stating that the last 4 (writeable/non-writeable, operational state, configuration).
Joel: We state that you have to be able to do everything you can do in the rest.
Linda: In ephemeral, you have write-able and non-writeable.
Joel: You can create the ephemeral state in configuration that exists,
and you can readable.
Jeff: In NETCONF terms, it is a configuration false node.
Sue: Configuration
Jie: Is Ephemeral operational state writable?
Jeff: The operational state is also ephemeral state, if the box goes away then it goes away.
Joel: Operational state is non-writable.
Jeff: Some NETCONF proposal was to have writeable operationa state.
Joel: If NETCONF makes operational being writeable, I2RS will not fight that.
However, it is not a requirement?
Req-08:
Dean: How will the secondary identity get passed?
Jeff: There is a proposal that it will part of the Meta data or the RPC.
Joel: The primary identity or the secondary identity?
Dean: The secondary can be pass in by
Joel: We are opened to a workable solution (??Sue: Not sure I got it all)
Sue: We had a long discussion at IETF94.
The security people indicate that we are sending identifiers and not identities.
The I2RS is ok with a client having just one identity. It may be changed,
but if it is changed - the client must handle the changes in priority or
secondary identity. The secondary identity is just for tracing.
REQ-09 / REQ-10:
Sue: Any other questinons?
Jan: What is the original client?
Sue: It is the lower priority guy that overwritten with the higher priority values.
Jeff: This the implication of the collision
Jan: My observation that keeping track of the priorities. It might to make it optional.
All these nice things add functionality, but our real concern is to make this simple.
Joel: I do not know how to do this?
Sue: The netconf server prevents it.
Joel: I would need details of something prevents and how fit.
Sue: the protocol DT is looking to see if we can prevent and handle the collisoins.
REQ-11/REQ-12
Andy: Kent pointed that if you have unique priorities, you cannot have ties.
Joel: That sound out like interesting idea.
Sue: This would take complexity out of the system.
Andy: Depending on how valiation works, it not so much first wins as
If there is validation, you can have another configuration.
Joel: This focused on actual collision of writes, and not indirect validation.
Andy: NETCONF will require validation.
Joel: We should let the protocol design team handle the validation.
Req-13:
Jan: I'm not sure I understand what is written here.
Sue: It appears I failed to reword it correctly. Does anyone else want to
restate this point.
Joel: The complexity of atomicity and roll-backs should be avoided.
Classical SNMP could not meet these requires.
If there are message that carry only one operation,
this may have a differnet set of problems.
Jan: We must allow bulk operations.
Joel: I would expect that you should send multiple operations in one message.
If you get multiple protocols, then these batch.
Jan: In Yang this becomes a little muddled, if the list in a PUT operatoins.
If the list has 1000 entries, is it 1000 operations or 1 operations.
Sue: You are right we need to have bulk operatoins.
Andy: The operation can one or many? I think that any thing under
other any perform all or none. Is too complex.
Joel: I think we have examples of the other case. The errors can help
state where you stop.
Andy: We had this from the start, and it was not implemented.
Joel: The client needs to know what the error is.
Andy: The trade-off is performance versus state.
Joel: If you have an all or none, then the server will have download.
Sue: Thank you for the good feedback, this decision will belong to the design team.
Jan: I would argue keeping it close to NETCONF. It will make it easier to deploy.
Otherwise, we will have trouble implementing.
Joel: This is a good argument for this point.
Andy: There is no ordering of the edits in NETCONF.
Jan: Again, making it different than NETCONF will
Joel: I think REQ-13 need to be looked at by the dexign team.
Jan: We must be close to NETCONF to get enough traction in the ecosystem.
Joel: I think the protocol design team should look at NETCONF/RESTCONF to give
Jan: This is a fair example.
Pub/Sub Requirements (jeff)
- pub-sub-req-1 - no comments
- pub-sub-req-2 - the "real-time" should be defined by models.
- pub-sub-req-3 -
- Joel: Did the security people approve of the insecure proocol.
- Andy: It raised an eyebrow, and people had closed networks.
SNMP did not get the security group to approve of closed networks.
- Sue: Closed networks is for the environment, The selection of insecure protocols is a model based
issue. I refered to telemetry and this convinced the security reviewer.
We could start with just netconf, and do telemetry as a second set.
- Andy: Model based use puts this in a separate equation. I see where the security people will allow this state.
- Jeff: How do we configure this in a model?
This takes it backs to the protocol.
If THRIFT or other protocols are used, may not have the secure transport.
If NETCONF is used, we will have just the secure protocol.
2. Review of NETCONF feedback on Requirements [22:30-22:40] planned
[23:20-23:25] actual
Security and NETCONF review of the security,
and we had disagreements on whether REQ-8 and REQ-12 are security functions.
SEC-DIR reviewer said "yes" and NETCONF said "no"
On insecure connection, sec-dir reviewer was ok with an insecure protocol with the caveat that it was model driven, and must be reviewed by sec-dir. An example of model driven is telemetry.3
3. Discussion of Open issues [22:40-23:25]
4. Closing of meeting [23:25-23:30]
virtual blue sheets
http://etherpad.tools.ietf.org:9000/p/i2rs-Sept-2-2015-v-Bluesheet
Minutes for the interim
http://etherpad.tools.ietf.org:9000/p/i2rs-Sept-2-2015-Interim-Minutes
Questions for the Virtual Interim
The following discussion points:
1) It is been said that the highest priority differences between
I2RS and NETCONF are the following things:
a) Quick Feedback loop for applications,
b) Being able to tie ephemeral to config
What do you think?
Discussion:
2) How much feedback do you want in your applications?
Discussion:
3) Should I2RS allow data transfer on an insecure protocol?
a) If so, what restrictions should be placed on the
data models allowing data transfer?
b) Should the data transfer over insecure protocol
be limited to just publication or subscription data?
Discussion:
4) What data should the ephemeral data models be able to
refer to in order to do constraint checking?
The options are:
a) ephemeral to configuration state,
b) ephemeral to operational state (for example, an LSP-ID
for an LSP that is created)
c) ephemeral configuration to ephemeral configuration
Examples could be:
a) I2RS RIB model referring to the I2RS topology model
b) I2RS BGP model referring to I2RS RIB
d) ephemeral configuration to ephemeral "protocol" state
I2RS RIB route configuration referencing
I2RS Topology model to check the summary of
learned logical paths
Discussion:
5) Do you think the protocol security requirement
are adequate for the protocol?
Discussion:
6) Have we missed anything in the requirements?
What are your 3 top priority requirements?
Discussion: