I2RS interim June 1, 2016
Agenda:
The agenda is simply a discussion of I2RS Ephemeral State requirements.
The presentation is online, and it is expected people will view the presentation
before the meeting.
Description: Ephemeral State Update Review
Streaming recording link:
https://ietf.webex.com/ietf/ldr.php?RCID=47311823b09d78f541a6276705b18795
Download recording link:
https://ietf.webex.com/ietf/lsr.php?RCID=d57e5e4c6ba68521d21dd33971d3b58d
presentation:
https://www.ietf.org/proceedings/interim/2016/06/01/i2rs/slides/slides-interim-2016-i2rs-9-0.pdf
Discussion of I2RS Ephemeral State (Rough notes)
1. Do you think Ephemeral-REQ-05 covers the resource constraint
issue discussed on the list and at IETF-95?
Discussion:
- Joel: Looks like something we discussed at IETF.
- Jeff: We should drop this from the document, and it is an implementation detail.
- Andy: There are too many I2RS requirements that deal into details like this. This
- Joel: I can live with removal. The WG asked for this on the list, and the WG.
- Jeff: We can not put in things which are impossible. We can put in something that suggests reasonable constraints.
- Andy: The Yang push draft has priority already
- Jeff: Perhaps we can consider dropping it as already covered?
- Sue: Need to ask the mail list.
- Don: Think this should be captured.
- Andy: SHOULD? (2119?)
- Sue: Good reason to not have it is it's hard to implement.
- Andy: What is required for interop. What's required for super-fast/fast. Let market work out what's "fast enough"
- Sue: *points to constraints* - we need to decide if these things cover what we're talking about.
- Alia: I think we're looking for RECOMMENDED.
- Andy: *agrees*
- Sue: I will change to RECOMMEND.
- Jeff: Is the current text overspecified?
- Andy: At some point we need to write the protocol, and decide on the trade-offs. How routers do their own resource management is very implementations specific? I would defer to someone who is working on the code at this time.
- Jeff: The long list of things
- "Ephemeral-REQ-05":
- "The I2RS Agent SHOULD have the ability to constraints for OAM functions operating to limit CPU processing, datarate across a transport, the rate of publication of data in a subscription, and logging rates; and the I2RS Agent SHOULD have the ability to prioritize some of the management data flows between the I2RS Agent and I2RS Client."
- The best approach is to prioritize stuff in the yang pub/sub.
- Andy: It would be unusual for the NETCONF
- Sue: I think this was for the OAM function.
- Jeff: Certainly for notification streams, it is obvious that you can generate too much data. If you are doing a get operation you can get too much "data".
- Andy:
- Jeff: We should tighten this down to notifications?
- Andy: Are you not concerned about logging?
- Jeff: This depends the implementation.
- Sue: The discussion at IETF was regarding OAM.
- Jeff: The idea of the function. For example, the prioritization of a firewall rule may take resource - but that is what you want. The BFD may have processing. For the purposes of this document, priority should be a feature. [note: Missed some of the comments].
- Sue/Andy Discussion:
- Don: I recommend we keep this one.
Summarize. Sue will propose a new form of Ephemeral-REQ-05 to the list.
2. Does Ephemeral-REQ-06 provide the Yang requirements in
a clear fashion? Do you have any suggestions for alternative text?
Joel: I will be take
Andy: It works on data in the i2rs datastore. Has nothing to do with modules, submodules, etc. Only means something on a data node in the ephemeral datastore.
Sue: I2RS rib module. It's defined as a ephemeral rib module.
Andy: You have to tag individual data nodes. You have to tag parent of sub-tree.
Jeff: Point is to have inheritance, similar to how config true applies to children.
Joel: You're demanding us to solve this markup before we've agreed what it looks like.
Andy: The text doesn't make sense in a yang context. Ephemeral rpcs, etc.
Joel: It isn't clear that an rpc needs to be marked ephemeral in the same way that the yang does. You could remove the e.g. since doesn't impact the requirements.
Sue: Requirement is module, submodule, components, schema node. Is that clear, Andy?
Andy: It's fine.
Joel: What about req-07 (insecure?)
Sue: Can do that now.
Summarize: Sue will reduce Ephemeral-REQ-06, and send to list for comment.
2.5
REQ-07:
Joel: We can just remove the last sentence.
Sue:
Ephemeral-REQ-07: Yang MUST have a way to indicate in a data model
that nodes have the following properties: ephemeral, writable/not-
writable, and status/configuration.
Last sentence:
Yang must also have a way to
specify on a module or submodule level whether the data MAY
optionally flow across an non-secure transport.
Jeff: The only case we have talked about is pub/sub.
Joel: I agree with this point.
Jeff: I think we can drop it out if we check pub/sub.
Sue: WFM.
#2.
Jeff: In this bullet point, whether this is a protocol
operation, it is a detail.
Sue: Shall we remove it.
#3.
Sue: Does it add anything.
Jeff: It does not add anything.
#4.
Jeff: Is this being too restricted?
Andy: No rationale exist for why this needed? No transports will be added soon.
Jeff: Do we have any situations where we could end up in non-secure transport.
Andy: We have
Jeff: We can drop this bullet point.
#5
Jeff: This is co vere
Joel: This should be removed.
#6
Jeff: I believe we need to retain this one. A long term is whether this is configuration or protocol option.
Joel: I believe it is better to leave it here.
Jeff: Do we need to state this is protocol or configuration?
Sue: Is this going to help?
Jeff: If you leave this as is, this
Joel: it does not mathc
Jeff: The I2RS protocol requirements are rolled into NETCONF/RESTCONF.
Joel: I'll send it to the list in the next few minutes.
Sue: I'd be glad to add a line that indicates it is configuration.
Jeff: I will suggest something.
Sue: Would you like it put in a different section.
Jeff: We need a new subsection. I'll propose.
#7
Sue/Jeff: Discussion - Should we leave it out or leave it to the discussion?
Jeff: Andy - do you have any feeling regarding this?
Summary: Gone from this section, but added to new section.
#8 -
Joel: We need to have this.
Jeff: This is covered by the architecture and the yang push change.
#9 - drop
Summary:
Replace #1 with Joels.
Keep #8 -
Jeff will move #6 and #7 to different section and restate.
3. Do you think any of the Ephemeral-REQ-08 NETCONF Changes
are not necessary? If so, what changes would you leave out?
Do the "policy-knobs" seem useful to you?
4. Do you think any of the Ephemeral-REQ-09 RESTCONF changes
are not necessary? If so, what changes would you leave out?
Do we need all the features (yang module library, call-home,
server)?
Same disposition of comments.
5. Do you think the pub/sub requirements are sufficient?
(PUB-SUB-REQ-01, PUB-SUB-REQ-02)
Sue: These indicate that the pub/sub and filter?
Jeff: Are the PUB/SUB is datastore specific?
Andy: I do not belief it is in there.
Jeff: #2 - says that we should provide this against the conceptual datastores.
Do we expect this to be covered by current work?
Sue: I will prefer to leave in the requirements.
Jeff: Leave in now.
6. Do you think we should remove or keep the second sentence
from Ephemeral-REQ-04?
Ephemeral-REQ-04: Ephemeral state MAY refer to non-ephemeral state
for purposes of implementing constraints. The designer of ephemeral
state modules are advised that such constraints may impact the speed
of processing ephemeral state commits and should avoid them when
speed is essential.
Discussion:
Joel: Remove 2nd sentence.
Jeff: Agreed.
Sue: I will remove
7. Do you have any concerns about Ephemeral-REQ-01?
Ephemeral-REQ-01: I2RS requires ephemeral state; i.e. state that does
not persist across reboots. If state must be restored, it should be
done solely by replay actions from the I2RS client via the I2RS
agent. Ephemeral state may consist of ephemeral configuration or
ephemeral operational state, or both.
Joel: There is no such thing as ephemeral operational state. All operational state is ephemeral.
Sue: How do you differentiate it?
Joel: All op state doesn't persist across reboots.
Sue:
(lots of discussion).
Jeff: There is one case where this not true (get operation). It returns the
the union of "config false" nodes.
Joel: They are talking about the "config false" nodes.
Jeff: The netconf verbage is confusing the point.
Joel: We should leave it to netmod. If we do not know what operational state,
then we should leave it alone.
Summary: We will remove the second sentence,
and change the first sentence to
Ephemeral-REQ-01: I2RS requires ephemeral configuration state; i.e. state that does
not persist across reboots. If state must be restored, it should be
done solely by replay actions from the I2RS client via the I2RS
agent.
8. Do you have an concern about Ephemeral-REQ-02:
Ephemeral-REQ-02: Non-ephemeral state MUST NOT refer to ephemeral
state for constraint purposes; it SHALL be considered a validation
error if it does.
9. Do you have any concerns about Ephemeral-REQ-03 or Ephemeral-REQ-04?
Ephemeral-REQ-03: Ephemeral state must be able to utilized temporary
operational state (e.g. MPLS LSP-ID or a BGP IN-RIB) as a
constraints.
Ephemeral-REQ-04: Ephemeral state MAY refer to non-ephemeral state
for purposes of implementing constraints. The designer of ephemeral
state modules are advised that such constraints may impact the speed
of processing ephemeral state commits and should avoid them when
speed is essential.
https://ietf.webex.com/ietf/j.php?MTID=m163079dec821ba49f3eec1f97b52006f
Join by phone
1-877-668-4493 Call-in toll free number (US/Canada)
1-650-479-3208 Call-in toll number (US/Canada)