Re: [i2rs] Benoit Claise's No Objection on draft-ietf-i2rs-architecture-13: (with COMMENT)

Thu, 24 Mar 2016 06:05:10 -0700 

Joel,

Thanks, that's helpful.

1. Let's look at the charter

   The I2RS working group works to develop a high-level architecture that
   describes the basic building-blocks necessary to enable the specific
   use
   cases, and that will lead to an understanding of the abstract
   informational models and requirements for encodings and protocols
   for the I2RS interfaces.

2. Let's review the draft abstract

       This document describes the IETF architecture for a standard,
       programmatic interface for state transfer in and out of the Internet
       routing system.  It describes the basic architecture, the components,
       and their interfaces with particular focus on those to be
       standardized as part of the Interface to Routing System (I2RS).

Reading 1., I understand your point of view.
However, I read 2. as this draft is about "we are using pieces X, Y, and Z, in ways A, B, and C, to solve the I2RS problem." 
I reviewed the draft content looking for 1., and could not find it.

Do you understand my confusion?

Regards, Benoit
Benoit, you seem to be looking for a level of specificity in the architecture that the working group never intended. The charter calls for a high level architecture.
I believe your comment calls out an interesting gap in the charter, as there is no document called out which actually says "we are using pieces X, Y, and Z, in ways A, B, and C, to solve the I2RS problem."
We could have tried to use the architecture document for that, but the intention was to use the architecture document to guide the selection of protocol and mechanisms. 

Yours,
Joel

On 3/24/16 6:53 AM, Benoit Claise wrote:

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.

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.
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"?
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

    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"

    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?

Regards, Benoit


_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs


.




_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs

Reply via email to