Benoit:
I'm cycling back to fix the draft-ietf-i2rs-architecture-13.txt. I hope you can help me through your comments as it is important to me that you are in alignment with this architecture as we go forward. Let me provide a high-level answer for your architecture questions. Question 1: Will the architecture provide you the pieces of the NETCONF/RESTCONF that will be used, and how these will be used for I2RS protocol version 1. Answer: No, this is not the goal of the I2RS architecture. The architecture and the requirements were to come as a set of documents along with the protocol strawman. The I2RS requirements documents will specify the requirements, and the protocol strawman will provide a suggested implementation. After that point, it is up to the NETCONF group to provide us with a final proposal for the I2RS protocol based on NETCONF/RESTCONF. The I2RS requirements documents are: 1) Pub-sub requirements - <https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/> draft-ietf-i2rs-pub-sub-requirements-06 (on IESG telechat for 5-5-2016) 2) Traceability - draft-ietf-i2rs-traceability-08.txt (on IESG telechat for 5-5-2016) 3) Ephemeral state requirements - draft-ietf-i2rs-ephemeral-state-06.txt 4) Protocol security requirements - draft-ietf-i2rs-protocol-security-requirements-04.txt (past WG LC, and awaiting shepherd double check of -04.txt) 5) Data flow requirements - [individual draft, will go to WG adoption call next week] draft-hares-i2rs-dataflow-req-04.txt 6) Protocol-strawman - draft-hares-i2rs-protocol-strawman [individual draft, heading toward WG adoption] The security environment is in: <https://datatracker.ietf.org/doc/draft-ietf-i2rs-security-environment-reqs/ > draft-ietf-i2rs-security-environment-reqs-01 (will recycle a WG next week). The requirements describe what needs to be done. The protocol-strawman suggests the pieces. Based on the IETF 95 feedback, items 3-6 are being revised. Question 2: So I2RS will publish a second architecture doc when the requirements are validated and the protocols (transport, config, notifications) are finally selected? Answer: The requirements were check with the NETCONF working group in IETF 93-95. We are progressing the requirements through WG LC and the IESG. During each I2RS WG LC, we will inform the NETCONF working group. We are counting on interaction with the NETCONF protocol. If the IESG wishes a bis of the architecture document, I will be glad to spin that draft after we get the protocol done. The comments below are in red if that helps you read it. Sue Hares From: Benoit Claise [mailto:[email protected]] Sent: Thursday, March 24, 2016 6:54 AM To: Susan Hares; 'The IESG' Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: [i2rs] Benoit Claise's No Objection on draft-ietf-i2rs-architecture-13: (with COMMENT) Sue, >Two of the existing protocols which the > which may be re-used are NETCONF [RFC6241] and RESTCONF > [I-D.ietf-netconf-restconf]. editorial "may be reused". / I will check with RFC editor (some people say reused /re-used). What does it mean? I was hoping that an architecture documents would at least tell me which protocols are used. On my side this architecture is flexible (NETCONF or RESTCONF), on the other side unclear (YANG 1.0 or YANG1.1), and in some cases, a complete specification (for example the notification) Sue: NETCONF and RESTCONF will be supported as part of the I2RS protocols. The architecture does out rule out other data transfer protocols, but says the WG will design I2RS as a higher level protocol that combines other protocols (NETCONF/RESTCONF + x). This is what I could not understand with the draft sentence: "Two of the existing protocols which the which may be re-used are NETCONF [RFC6241] and RESTCONF > [I-D.ietf-netconf-restconf]." Sure many things could be reused. I'm expecting from an architecture document to explain which pieces are used and how they are used. Benoit: See the above. This mechanism is the direction from the AD. In the end, you will be reviewing in the next month the requirements and the protocol strawman for publication. If you wish, you can request all of these documents (architecture, requirements (5), and protocol strawman get published as a bundle. The I2RS requirements documents and protocol strawman will state is if any other protocols will be used for a particular version of I2RS with a particular scope for data modules. Probably, my issue stems from the fact that I2RS produces an architecture before fixing requirements. Benoit: You are correct. I am sorry if this is not what you excepted, but it was my direction from my AD on how to approach this work. At this time, we are closing in on the last of the requirements documents - the requirements for other data flows. draft-hares-i2rs-dataflow-req-02 that gives the potential scope of data flows, but IMO the first version of the I2RS is likely to stay with just NETCONF/RESTCONF with ephemeral state, push pub/sub support, syslog module library, and some yang changes. To handle I2RS Agent failure, the I2RS Agent must use two different notifications. NOTIFICATION_I2RS_AGENT_STARTING: This notification signals to the I2RS Client(s) that the associated I2RS Agent has started. It includes an agent-boot-count that indicates how many times the I2RS Agent has restarted since the associated routing element restarted. The agent-boot-count allows an I2RS Client to determine if the I2RS Agent has restarted. (Note: This notification will be only transmitted to I2RS clients which are know in some way after a reboot.) No comment on "the I2RS Agent must use two different notifications"? Sue: oops - Missed that one Old/ To handle I2RS Agent failure, the I2RS Agent must use two different notifications. New/ To handle these two types of failures, the I2RS agent MUST support two different notifications: a notification for the I2RS agent terminating gracefully, and a notification for the I2RS agent starting up after an unexpected failure. The two notifications are described below followed by the a description of their use in unexpected failures and graceful shutdown Graceful shutdown : In this case, the I2RS agent can do specific limited work as part of the process of being disabled. The I2RS agent must send a NOTIFICATION_I2RS_AGENT_TERMINATING to all its cached I2RS clients. If the I2RS agent restarts after a graceful termination, it will send a NOTIFICATION_I2RS_AGENT_STARTING to each cached I2RS client. This one is clear spec. - editorial: Optionally, a routing element may permit a priority to be to be.... For the case when the I2RS ephemeral state always wins for a data model, if there is an I2RS ephemeral state value it is installed instead of the local configuration state. Again, I read that sentence multiple times, and could not understand it Sue: Reasonable editorial comment. This was added to address another comment, But it looks like we broken something. Text change below. Old/ Optionally, a routing element may permit a priority to be to be configured on the device for the Local Configuration mechanism interaction with the I2RS model. The policy mechanism would compare the I2RS client's priority with that priority assigned to the Local Configuration in order to determine whether Local Configuration or I2RS wins. For the case when the I2RS ephemeral state always wins for a data model, if there is an I2RS ephemeral state value it is installed instead of the local configuration state. The local configuration information is stored so that if/when I2RS client removes I2RS ephemeral state the local configuration state can be restored. / New: Optionally, a routing element may permit a priority to be to be to be to be thank you. Removed configured on the device for the Local Configuration mechanism interaction with the I2RS model. The policy mechanism would compare the I2RS client's priority with that priority assigned to the Local Configuration in order to determine whether Local Configuration or I2RS wins. For the case when the configured priority of the I2RS ephemeral Is higher than the Local Configuration's policy, the The I2RS ephemeral state value it is installed remove "it" Thank you. Removed instead of the local configuration state. The local configuration information is stored so that if/when I2RS client removes I2RS ephemeral state the local configuration state can be restored. / figure 2. "The initial services included in the I2RS architecture are as follows." Are these really the initial services for I2RS. I2RS is really dealing with all these: interfaces, policy, QoS, ... Maybe I should review the I2RS charter? Sue: Our charter is wide, but only ephemeral layer deep. Due to the excellent people in the NETCONF/NETMOD, routing area (rtgwg) and TEAS - we are focusing on allowing ephemeral to be added to any data model. I2RS WG is focused first on the I2RS protocol and protocol independent modules. After this, I2RS purpose is to simply support other WGs in creating data modules with ephemeral state. The I2RS protocol may need to use several underlying transports (TCP, SCTP (stream control transport protocol), DCCP (Datagram Congestion Control Protocol)), with suitable authentication and integrity protection mechanisms Do you really want to have define transports? Sue: We indicate that I2RS will use these protocols. Each protocol we mention has to be then validated with requirements (see protocol security requirement and security environment requirements). So I2RS will publish a second architecture doc when the requirements are validated and the protocols (transport, config, notifications) are finally selected? Sue: See top comment for this one. Regards, Benoit
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
