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

["Susan Hares" <[e-mail]>]

Joel: 

 

I will need to resolve this before I can provide a final for the RFC editor.
Here's the way I understand these issues: 

 

1) draft-ietf-i2rs-architecture-13.txt - is a high-level architecture with
building blocks. 

2) It provides only general ideas on we are using "X, Y, and Z" in ways "A,
B, and C" to 

solve the "I2RS problem". 

 

3) detailed requirements on what the I2RS protocol and interface should be
are contained in 

   the i2rs requirements set 

.         Pub/sub requirements - draft-ietf-i2rs-pub-sub-requirements-06
(at IESG publication) 

.         Traceability requirements - draft-ietf-i2rs-traceability-08 (at
IESG publication) 

.         Protocol Security requirements -
draft-ietf-i2rs-protocol-security-requirements-03

.         Ephemeral State requirements - draft-ietf-i2rs-ephemeral-state-05

.         Data Flow Requirements  - draft-hares-i2rs-dataflow-req-03

.         I2RS security requirements for environment -
draft-ietf-i2rs-security-environment-reqs-01

 

The protocol strawman is the proposal for using "X, Y, and Z" in ways "A,B,
and C" in order

to solve the I2RS problem. 

 

4) The architecture document and use cases were useful in creating the key
informational models: 

 

1)      I2RS RIB Information model 

2)      I2RS FB-RIB informational model (under WG Adoption) 

3)      I2RS generic network model (
<https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/>
draft-ietf-i2rs-yang-network-topo-02) - which has formed the basis for most
of the I2RS, TEAS and CCAMP ideas on models. 

 

Therefore, I think we followed the charter. 

 

What we really need to revise is the abstract.  To bring the expectations
for the architecture closer to task 1. 

 

How about changing the abstract to:  

 

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 high-level architecture, the building 

blocks of this high-level architecture, and their interfaces with 

particular focus on those to be standardized

as part of the Interface to Routing System (I2RS).

 

Sue 

 

-----Original Message-----
From: Joel M. Halpern [mailto:[e-mail]] 
Sent: Thursday, March 24, 2016 9:07 AM
To: Benoit Claise; Susan Hares; 'The IESG'
Cc: [e-mail]; [e-mail]; [e-mail];
[e-mail]; [e-mail]
Subject: Re: [i2rs] Benoit Claise's No Objection on
draft-ietf-i2rs-architecture-13: (with COMMENT)

 

Now I understand your confusion.

Putting aside the abstract, I thought we were focused om task 1 (from the
charter) in writing.  I think we probably crept into task 2, resulting in a
document which is confusing about its scope.

 

Not sure how to resolve this.

Yours,

Joel

 

On 3/24/16 9:03 AM, Benoit Claise wrote:

> 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

>>>  <mailto:[e-mail]> [e-mail]

>>>  <https://www.ietf.org/mailman/listinfo/i2rs>
https://www.ietf.org/mailman/listinfo/i2rs

>>> 

>> .

>> 

>