Subject: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (ends Aug 12)

From: Alia Atlas <[email-masked]>
Date: Wed, 24 Jul 2013 17:52:04 -0400

Please review draft-atlas-i2rs-architecture-01 and comment on whether it
should be adopted by I2RS.  Detailed technical conversation is also most
welcome.

Authors: Are you aware of any IPR that applies to
draft-atlas-i2rs-architecture-01? Is so, has this IPR been disclosed in
compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more
details).

This WG call for adoption will complete on August 12.

Thanks,
Alia

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 24 Jul 2013 18:01:52 -0400

As a co-author, I do think this is ready for working group adoption and 
improvement.
Also, I do not know of any IPR that applies to this document.

Yours,
Joel M. Halpern

On 7/24/13 5:52 PM, Alia Atlas wrote:
> compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for
> more details).
>
> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
>

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 24 Jul 2013 18:04:06 -0400

As a co-author, I also am not aware of any IPR that applies to this draft. 

Like Joel, I feel this draft is ready for WG adoption. 

Sue 

From: [email-masked] [mailto:[email-masked]] On Behalf Of Alia
Atlas
Sent: Wednesday, July 24, 2013 5:52 PM
To: [email-masked]
Subject: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01
(ends Aug 12)

Thanks,
Alia

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 24 Jul 2013 18:05:50 -0400

I think this is ready for working group adoption. 

	I do not know of any IPR that applies to this document.

	--Tom

> Please review draft-atlas-i2rs-architecture-01 and comment on whether it should be adopted by I2RS.  Detailed technical conversation is also most welcome.
> 
> Authors: Are you aware of any IPR that applies to draft-atlas-i2rs-architecture-01? Is so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>

---

From: <[email-masked]>
Date: Thu, 25 Jul 2013 10:06:16 +0200

Hi,

>From my point of view the draft is ready for WG adoption.

  regards

    Nic

________________________________
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Alia Atlas
Gesendet: Mittwoch, 24. Juli 2013 23:52
An: [email-masked]
Betreff: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (ends Aug 12)

Thanks,
Alia

---

From: "George, Wes" <[email-masked]>
Date: Thu, 25 Jul 2013 16:40:01 -0400

I have some concerns about 6.1 in terms of whether it could be interpreted as a definite statement of direction that we'll be building a new protocol rather than identifying one to modify for use here, which I think is in conflict with section 5 of the problem statement.

I agree that cobbling together several protocols that weren't meant to be integrated isn't necessarily a good solution when compared with a single protocol, so I think this may be a wording problem in the current text, rather than a philosophical disagreement, but it's worth confirming that before we adopt this draft. If I'm right that it's just a wording issue, it may be as simple as adding the same words from the problem statement:

         "Whether such a protocol is built upon extending
   existing mechanisms or requires a new mechanism requires further
   investigation."

Otherwise I think it's in good shape.

Thanks,

Wes George

From: [email-masked] [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: Wednesday, July 24, 2013 5:52 PM
To: [email-masked]
Subject: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (ends Aug 12)

Thanks,
Alia

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Alia Atlas <[email-masked]>
Date: Thu, 25 Jul 2013 16:56:29 -0400

Wes,

I'll be happy to add the suggested words.  Personally,  I hope we can
modify an existing protocol...

Alia
On Jul 25, 2013 4:40 PM, "George, Wes" <[email-masked]> wrote:

>  I have some concerns about 6.1 in terms of whether it could be
> interpreted as a definite statement of direction that we’ll be building a
> new protocol rather than identifying one to modify for use here, which I
> think is in conflict with section 5 of the problem statement. ****
>
> I agree that cobbling together several protocols that weren’t meant to be integrated isn’t necessarily a good solution when compared with a single protocol, so I think this may be a wording problem in the current text, rather than a philosophical disagreement, but it’s worth confirming that before we adopt this draft. If I’m right that it’s just a wording issue, it may be as simple as adding the same words from the problem statement: ****
>
>          “Whether such a protocol is built upon extending****
>
>    existing mechanisms or requires a new mechanism requires further****
>
>    investigation.“****
>
> ** **
>
> Otherwise I think it’s in good shape.****
>
> ** **
>
> Thanks,****
>
> ** **
>
> Wes George****
>
> ** **
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Alia Atlas
> *Sent:* Wednesday, July 24, 2013 5:52 PM
> *To:* [email-masked]
> *Subject:* [i2rs] Call for Adoption by WG:
> draft-atlas-i2rs-architecture-01 (ends Aug 12)****
>
> ** **
>
> Alia****
> ------------------------------
> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or subject to
> copyright belonging to Time Warner Cable. This E-mail is intended solely
> for the use of the individual or entity to which it is addressed. If you
> are not the intended recipient of this E-mail, you are hereby notified that
> any dissemination, distribution, copying, or action taken in relation to
> the contents of and attachments to this E-mail is strictly prohibited and
> may be unlawful. If you have received this E-mail in error, please notify
> the sender immediately and permanently delete the original and any copy of
> this E-mail and any printout.
>

---

From: Jon Mitchell <[email-masked]>
Date: Thu, 25 Jul 2013 18:13:17 -0400

Support adoption but also agree with Wes's suggestion.

-Jon

On Jul 25, 2013, at 4:40 PM, "George, Wes" <[email-masked]> wrote:

> I have some concerns about 6.1 in terms of whether it could be interpreted as a definite statement of direction that we’ll be building a new protocol rather than identifying one to modify for use here, which I think is in conflict with section 5 of the problem statement.
> I agree that cobbling together several protocols that weren’t meant to be integrated isn’t necessarily a good solution when compared with a single protocol, so I think this may be a wording problem in the current text, rather than a philosophical disagreement, but it’s worth confirming that before we adopt this draft. If I’m right that it’s just a wording issue, it may be as simple as adding the same words from the problem statement: 
>          “Whether such a protocol is built upon extending
>    investigation.“
> Otherwise I think it’s in good shape.
>  
> Thanks,
>  
> Wes George
>  
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sun, 28 Jul 2013 22:06:23 +0000

I support I2RS adoption of this document.

This is a very solid start with a very well written individual draft.

I also take the chance to share some questions and provide some review feedback (with "CMP"):

        An Architecture for the Interface to the Routing System
                    draft-atlas-i2rs-architecture-01

1.  Introduction

   The I2RS, and therefore this document, are specifically focused on an
   interface for routing and forwarding data.

CMP: "and forwarding data"? Ultimately the interface will influence forwarding, but is it focused on it?

1.2.  Architectural Overview

   Routing:   This block represents that portion of the Routing Element
      that implements part of the Internet routing system.  It includes
      not merely standardized protocols (i.e. IS-IS, OSPF, BGP, PIM,
      RSVP-TE, LDP, etc.), but also the RIB Manager layer.

CMP: Things like LDP and RSVP-TE are counted as "routing". It is not clear to me that we might want to lump it together here, and frankly what the scope for these things is. I suspect it might be worth clarifying the reach and scope of these.

   I2RS Client:   ...  It interacts with the I2RS clients to collect information
      from the routing and forwarding system.  

CMP: I also wonder whether these references to interaction with the "Forwarding system" refer to MPLS dataplane encap or are further reaching, and how. For example, creating a Tunnel would not be "forwarding".

2.  Terminology

   identity:   A client is associated with exactly one specific
      identity.  State can be attributed to a particular identity.  It
      is possible for multiple communication channels to use the same
      identity; in that case, the assumption is that the associated
      client is coordinating such communication.

CMP: It seems to me that the "client identity" is necessary, but sometimes not sufficient. I recall seeing an "Application Identity" somewhere in this document, and wonder if that concept should not be elevated in the requirement priority.

3.4.  Authorization and Authentication

   I2RS clients may be operating on behalf of other applications.  While
   those applications' identities are not need for authorization, each
   application should have a unique opaque identifier that can be
   provided by the I2RS client to the I2RS agent for purposes of
   tracking attribution of operations.

CMP: It seems to me that the identity of an application is also critical for Accounting (and troubleshooting).

4.  Network Applications and I2RS Client

   When an I2RS Client interacts with multiple network applications,
   that I2RS Client is behaving as a go-between and may indicate this to
   the I2RS Agents by, for example, specifying a secondary opaque
   identity to allow improved troubleshooting.

CMP: Should this be stronger than a "may indicate"?

4.1.  Example Network Application: Topology Manager

   One example of such an application is a Topology Manager.  Such an
   application includes an I2RS client which uses the I2RS protocol to
   collect information about the state of the network.  The Topology
   Manager would collect device and interface state from devices it
   interacts with directly. 

CMP: Tunnels are some times key elements in a topology. Are tunnels considered as "interfaces" or should those be called out explicitly?

5.4.1.  Unicast and Multicast RIB and LFIB

   Network elements concerned with routing IP maintain IP unicast RIBs.
   Similarly, there are RIBs for IP Multicast, and a Label Information
   Base (LIB) for MPLS.

and

5.4.3.  MPLS

   The I2RS Agent will need to interact with the knobs that policy
   attributes that control LDP operation as well as RSVP-TE based LSPs.

CMP: While I think that programmatically interfacing with MPLS information is useful, the case is not clearly described in the problem statement, nor it seems to be captured comprehensively here. Section 5.4.3 includes only a big broad statement, but it's not clear which elements of label distribution protocols (i.e., BGP also seems missing here) are relevant to I2RS.

6.1.  Protocol Structure

   protocol.  That protocol may use several underlying transports (TCP,
   SCTP, DCCP), with suitable authentication and integrity protection

CMP: Doesn't I2RS need a reliable underlying transport? Why DCCP?

Thanks,

-- Carlos.

---

From: Joe Marcus Clarke <[email-masked]>
Date: Wed, 31 Jul 2013 06:57:12 -0400

> This WG call for adoption will complete on August 12.

I support adoption, but I do have some comments below (see JMC)

Section 1:

JMC: Does an interface to the forwarding set the bar too broadly?
Should this instead be an interface to the layer 3 forwarding data?  Do
we want to exclude this altogether in light of ForCES?

Section 1.2:

As can also be seen in Figure 1, an I2RS Agent may communicate with
   multiple clients.  Each client may send the agent a variety of write
   operations.  The handling of this situation has been a source of
   discussion in the working group.  In order to keep the protocol
   simple, the current view is that two clients should not be attempting
   to write (modify) the same piece of information.  Such collisions may
   happen, but are considered error cases that should be resolved by the
   network applications and management systems.

JMC: I think more verbiage is needed around how to detect collisions.
This is key to security considerations.  Saying "clients should not" is
not strong enough to keep our potential attackers.  If each operation is
tagged with an identifier that is unique to a client, then it will be
possible to determine if the current client is trying to overwrite data
from a previous client.  This could fold into authz as well where there
is a permission to allow global override of other application's state.

Section 2:

read scope: ...

write scope: ...

JMC: Should there be an event or notification scope in addition to read
and write?

Section 3.4:

JMC: The opaque ID might make it hard to accurately attribute changes.
I2RS should mandate a way to ensure traceability back to a client that
made the change or was granted access.

Section 4.1:

JMC: I found the text here a bit confusing and potentially overreaching
for the I2RS scope.  I attempted to rewrite it.

OLD:

One example of such an application is a Topology Manager.  Such an
   application includes an I2RS client which uses the I2RS protocol to
   collect information about the state of the network.  The Topology
   Manager would collect device and interface state from devices it
   interacts with directly.  It also collects routing configuration and
   operation data from those devices.  Most importantly, it collects
   information about the routing system, including the contents of the
   IGP (e.g. IS-IS or OSPF) and BGP data sets.  This information is
   provided to the I2RS client using the I2RS data models and protocols.

   The Topology Manager may be an integral part of an application.  It
   would build internal data structures, and use the collected data to
   drive applications like path computations or anomalous routing
   detection.  Alternatively, the Topology manager could combine the
   I2RS collected data with other information, abstract the result, and
   provide a coherent picture of the network state over another
   interface.  That interface might use the same I2RS protocols, and
   could use extensions of the I2RS data models.  Developing such
   mechanisms is outside the initial scope of the I2RS work.

NEW:

One example of such an application is a Topology Manager.  A Topology
Manager includes an I2RS client that uses the I2RS data models and
protocol to collect information about the state of the network by
communicating directly with one or more I2RS agents.  From these I2RS
agents, the Topology Manager collects routing configuration and
operational data.  Most importantly, it collects information about the
routing system, including the contents of the IGP (e.g., IS-IS or OSPF)
and BGP data sets.

The Topology Manager may be embedded as a component of a larger
application.  It would construct internal data structures and use the
collected data to drive functions such as path computations or anomalous
routing detection.  Alternatively, the Topology Manager could combine
the I2RS-collected data with other information, abstract a composite
set, and provide a coherent picture of the network state accessible via
another interface.  That interface might use the same I2RS protocol and
could use extensions to the I2RS data models.  Developing such
mechanisms is outside the initial scope of the I2RS work.

Section 5.2.1:

An I2RS client applies changes via the I2RS interface based on policy
   and other application inputs...

JMC: I2RS interface is redundant, perhaps I2RS protocol

Section 5.2.2:

An I2RS Agent may decide that some state should no longer be applied.
   An I2RS Client may instruct an Agent to remove state it has applied.
   In all such cases, the state will revert to what it would have been
   without the I2RS; that state is generally whatever was specified via
   the CLI, NetConf, SNMP, etc.  I2RS Agents will not store multiple
   alternative states, nor try to determine which one among such a
   plurality it should fall back to.  Thus, the model followed is not
   like the RIB, where multiple routes are stored at different
   preferences.

JMC:  Previously I had commented that one event that should be supported
and perhaps documented here is that if the agent decides to revert the
application can be notified that its state has been reverted.  This
might also be useful if another client overrides some portion of another
client's state (this is covered in Section 6.8, but might be useful to
mention here as well).  Perhaps add at the end of Section 5.2.2:

  "A client may choose to be notified whenever its state is reverted
either by another client or by the I2RS agent."

Section 5.4.2:

(Bulleted list of examples)

JMC: Consider adding an example for an event such as a new route being
learned or an OSPF neighbor removal.

Section 5.4.4:

Many network elements have separate policy and QoS mechanisms,
   including knobs which affect local path computation and queue control
   capabilities.  These capabilities vary widely across implementations,
   and I2RS cannot model the full range of information collection or
   manipulation of these attributes.  A core set does need to be
   included in the I2RS data models and in the expected interfaces
   between the I2RS Agent and the network element, in order to provide
   basic capabilities and the hooks for future extensibility.

JMC: I think this either needs an editor's note for more discussion or
perhaps QoS in general should be out of scope.

Section 6.1:

As a result, this architecture views the I2RS interface
   as an interface supporting a single control and data exchange
   protocol.

JMC: Another instance of I2RS interface.

Section 6.1:

That protocol may use several underlying transports (TCP,
   SCTP, DCCP), with suitable authentication and integrity protection
   mechanisms.  Whatever transport is used for the data exchange, it
   must also support suitable congestion control mechanisms.

JMC: I think Carlos (or someone) mentioned this, but I'm not sure DCCP
is ideal for I2RS since we likely do want reliable order of delivery.

Section 6.4:

Each I2RS Client will have an identity; it can also have secondary
   identities to be used for troubleshooting.

JMC: Each application will have a _unique_ identity.

Section 6.5:

JMC: Perhaps some normative language here to indicate a client may not
maintain a persistent connection, but they may choose to do so as well.

OLD:

A client does not need to maintain an active communication channel
   with an agent.

NEW:

A client may not maintain...

Section 6.7:

One of the other important aspects of the I2RS is that it is intended
   to simplify collecting information about the state of network
   elements.

JMC: I think this needs to be more specific to routing information
versus any information from the network element (e.g., it does not cover
CPU statistics).

Joe

-- 
Joe Marcus Clarke, CCIE #5384,         |          |
SCJP, SCSA, SCNA, SCSECA, VCP        |||||      |||||
Distinguished Services Engineer ..:|||||||||::|||||||||:..
Phone: +1 (919) 392-2867         c i s c o  S y s t e m s
Email: [email-masked]

----------------------------------------------------------------------------

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 31 Jul 2013 11:14:22 +0000

> JMC: Should there be an event or notification scope in addition to read

+1 to this point. I think that it should also include some words about pub/sub. 

Section 6.6 covers some of this though, so perhaps a forward reference.

Thanks,

-- Carlos.