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

From: KwangKoog Lee <[email-masked]>
Date: Thu, 1 Aug 2013 17:24:40 +0900

I also support WG adoption and agree with other members' comments.
Also, I have a small comment about the Sec. 6.1.

"Whatever transport is used for the data exchange, it must also support
suitable congestion control mechanisms."

Instead of this sentence, I think it needs to mention that I2RS protocol
messages must be treated by the highest proirity even if the control
network is under a congestion situation so that the communication is very
highly reliable between I2RS client and I2RS agent.
I think congestion control is little bit risky to I2RS operation because
those messages have very impotant information and also problem
statement document already mentions that responsiveness and reliability of
i2rs is important.
Thanks.

Sincerely,
Kwnag-koog Lee (Ph.D)
KT (Korea Telecom)

On Wed, Jul 31, 2013 at 8:14 PM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

>
> On Jul 31, 2013, at 12:57 PM, Joe Marcus Clarke <[email-masked]> wrote:
>
> Section 2:
>
> read scope: ...
>
> write scope: ...
>
> JMC: Should there be an event or notification scope in addition to read
> and write?
>
>
> +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.
>
> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
>
>

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 1 Aug 2013 05:07:43 -0400

I have the draft and support its adoption.

Some comments:
1) ForCES model can support different levels of granularities. Yes,
original intent
was to do datapath control-southbound interfaces; but it is very usable in wide
range of applications that desire a model. Example, if you attended the ForCES
meeting you may have seen a demo where ForCES was used to model VMs
doing arbitrary network functions where the ForCES was then used to orchestrate
that infrastructure.

2) I think we may end up needing more clarity on the transport. Merely saying
you'd use congestion-aware transport and spelling out desire for different
levels of reliability is insufficient. An I2RS agent is a proxy;
reliability and congestion
control need to take into consideration those two requirements above the
transport layer.

3) identity/roles
It would be useful to specify some sample space of common practise.

cheers,
jamal

On Wed, Jul 24, 2013 at 5:52 PM, Alia Atlas <[email-masked]> wrote:
> 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: Sriganesh Kini <[email-masked]>
Date: Mon, 12 Aug 2013 10:58:12 -0700

Support WG adoption.

---

From: Edward Crabbe <[email-masked]>
Date: Tue, 13 Aug 2013 09:35:16 -0700

I2RSers;

Yesterday ended the poll for wg adoption of this draft.  Although there
seems to be sufficient support to warrant adoption, and there do not
seem to be any show-stoppers, I haven't seen any responses on the list
from Alia yet.

Alia should respond to comments and update the draft
as warrranted before we finalize the process.  I believe she's in the
midst of doing just that.

cheers,
   -ed

---

From: Alia Atlas <[email-masked]>
Date: Tue, 13 Aug 2013 14:44:26 -0400

Hi Carlos,

Thanks for the review and comments.  I apologize for the delay in
responding.  I took some vacation after IETF.

On Sun, Jul 28, 2013 at 6:06 PM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> 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?
>
[Alia] True - I've removed "and forwarding data"

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

[Alia] I see them as grouped into "routing and signaling" and definitely
part of I2RS.  The problem-statement draft (not a WG draft yet) clearly
states:
"In addition to interfaces to the RIB layer, there is a need to configure
the various routing and signaling protocols with differing dynamic state
based upon application-level policy decisions." and the framework draft
that this architecture replaces had a slightly larger section on use-cases
and examples.

What is your specific concern and how would you want to see the reach and
scope confined in the architecture draft?

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

[Alia]  First, the I2RS clients should be I2RS agents.  I've fixed that.
 Second, these are a bit further reaching.  For instance, learning about
link up/down events, subscribing to counters for when they go over a
particular threshold, etc.  Basically, to provide the information necessary
for a network application's feedback loop, information outside of the
routing system may be necessary to read/learn.  The exact details will
depend on the use-cases and proposed info-models.

Do you think that a text change is needed?  If so, what would you suggest?

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

[Alia] Sure, it's clear that the broker model is of interest.  I'll add in

   secondary identity:  An I2RS Client may supply a secondary opaque
identity that is not interpreted by the I2RS Agent. An example use is when
the I2RS Client is a go-between for multiple
applications and it is necessary to track which application has
requested a particular operation.

> 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).
>

[Alia] Yes, tracking the attribution of operations allows aspects like
accounting and troubleshooting.  I've modified the sentence to end:

...identifier that can be provided by the I2RS client to the I2RS agent for
purposes of tracking
attribution of operations to support functionality such as 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"?
>

[Alia] Sure - I'll upgrade it to "should indicate".  This is a question of
supporting the broker model of an I2RS client for ease of troubleshooting.

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

[Alia] Tunnels aren't interfaces - but the details of what should be in the
topology depends on the topology info-model and isn't specified in the
architecture.

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

[Alia] BGP is already mentioned as a protocol that will need an info-model.
 I guess I think of this section as discussing the transport LSPs and
associated protocols as compared to the MPLS services.  The MPLS services
are part of routing and should be included too.  I've changed the text in
Sec 5.4.3 to read:

"The I2RS agent will need to interact with the protocols that create
transport LSPs (e.g. LDP and RSVP-TE) as well as protocols (e.g. BGP,
LDP) that provide MPLS-based services (e.g. pseudowires, L3VPNs,
L2VPNs, etc)."

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

[Alia] There may be cases of data streams that don't require a reliable
underlying transport.  I'm thinking about providing statistics streams.   I
am concerned about the issues with timely delivery that can arise with TCP
- but I think that what transport protocol is appropriate will depend a bit
on what data is being delivered.

Thanks again for the detailed review and questions,

Alia

Thanks,
>
> -- Carlos.
>
>
> On Jul 24, 2013, at 11:52 PM, Alia Atlas <[email-masked]> wrote:
>

---

From: Alia Atlas <[email-masked]>
Date: Tue, 13 Aug 2013 16:01:40 -0400

Hi Joe,

Thanks for the detailed review and suggestions.  Responses are in-line.

Alia

On Wed, Jul 31, 2013 at 6:57 AM, Joe Marcus Clarke <[email-masked]>wrote:

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

[Alia] Yes, I've removed the "and forwarding data".  I do still think that
there is forwarding data that might need to be read, but not written.

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

[Alia] For the I2RS Agent to properly handle a collision, it does need to
store the client identifier.  I think that is clear in Sec 5.2 "Simply, the
I2RS agent stores who did what operation to which entity." and the details
in Sec 6.8 are "The current recommendation is to have a simple priority
associated with each I2RS clients, and the highest priority change remains
in effect. In the case of priority ties, the first client whose attribution
is associated with the data will keep control."  We already have a
reference to Sec 6.8 right there - and that section is where the details
are discussed.  What specific additional verbiage do you think would be
useful?   The priority is a knob to allow overwriting of other
applications' state - though needing to is considered an error. :-)

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

[Alia] I think it is folded into the read scope.  If we find the need for
such a term later on, then we can add it.

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

[Alia] What do you have in mind?  The I2RS client will have a security role
and its scope.  The I2RS client needs to vet the applications that it is a
broker for.  The opaque ID can be something that is meaningful to that I2RS
client.   Basically, I2RS is providing the identity and security for
between the I2RS client and the I2RS agent.  I don't see it as practical or
appropriate to try and define how the I2RS client and its applications
interact; I know the broker/controller model is popular and so we do need
enough to help support traceability to a secondary ID, but I'm not sure
what is needed or appropriate beyond that.

> 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:
>
>    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.
>

[Alia] Sure - thanks for the rewritten text.  I don't find it significantly
different in terms of its reach - but if you think it is clearer, I'm happy
to update it.

> 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
>

[Alia] Sure - I2RS protocol is fine.

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

[Alia] I'll put in: "An I2RS Client may register for notifications when
state that was
applied by a particular I2RS Client is modified or removed."  That is
slightly different since it allows an I2RS Client to learn about the
changes to state from itself or from a different I2RS Client.

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

[Alia] I think that "writing routes or prefixes to be advertised via the
protocol" describes a new route being learned.   I'd prefer not to put OSPF
neighbor removal in as an example.  It raises the questions about what is
configuration vs. ephemeral data and the I2RS scope.  If you have a good
use-case that requires it, then I'd be quite interested in seeing it.

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

[Alia] I am happy to add in an editor's note for more discussion - but we
should start that conversation now on the list - because the WG does have
quite tight deadlines for milestones.

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

[Alia] Removed the interface - thanks.

> Section 6.1:
>
> That protocol may use several underlying transports (TCP,
>    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.
>

[Alia] Yes - DCCP is clearly the wrong choice for a control channel - but
it may be
good for delivering statistics.   I think we'll have different transport
options depending on the requirements of a particular data model or
section.  Since you are the second person to be confused by that section,
I've added the following sentence:

"These different transports can support different types of
communication (e.g. control, reading, notifications, and information
collection) and different sets of data."

 Let me know if that helps or if you have better ideas for wording.

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

[Alia] Hmm, this ties into the discussion about how we want to handle
redundancy and recovery for clients.   It's also a bit of a tautology - a
client is solely identified by its identity.    I have changed it to say
that "Each I2RS Client will have a unique identity" - but  that just helps
clarify the intent.

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

[Alia] Changed to "A client may or 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).
>

[Alia] The scoping is a question - and that will depend on what the
use-cases we consider need and what the related information and data models
need to be.  If you look at the draft-bitar-i2rs-service-chaining-00, it
does ask for things like CPU load.  I do think there is a real need to be
able to get back thresholded and filtered information.  You probably heard
Ed's personal thoughts about a single protocol as well...   So - I don't
think the architecture needs to restrict the data in scope - particular in
a section that is talking about communication patterns - but as a WG, we
need to keep a tight focus that still provides sufficient information to
fully solve the desired use-cases.

Thanks again for your review and suggestions,
Alia

> 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: Alia Atlas <[email-masked]>
Date: Tue, 13 Aug 2013 16:06:24 -0400

in-line as ever

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

[Alia] I think about the read scope as including the event or notification
scope - at least unless and until we have to have the extra complexity of
terminology.  I don't see where or why read scope and notification scope
need to be separate concepts??

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

[Alia] In the terminology section??  If we needed notification scope, ok -
but I don't see an argument for it to be separated...

Alia

---

From: Alia Atlas <[email-masked]>
Date: Tue, 13 Aug 2013 16:11:48 -0400

Hi KwangKoog Lee,

I do hear your concern about the transport and congestion control.
 Different DSCPs may make sense for the I2RS protocol; the control part
with write operations makes sense to have at a high priority.   However,
getting the RIB updates as an information stream may not want to have the
same priority.
Congestion control is likely to be needed to handle congested situations
that may occur.  For instance, consider how I2RS and BGP should interact in
terms of QoS.

I do have concerns about the head-of-line blocking that happens with TCP
given congestion, but I think there are both other transports and that
multiple transport channels can be used.

Thanks,
Alia

---

From: Alia Atlas <[email-masked]>
Date: Tue, 13 Aug 2013 16:26:23 -0400

Hi Jamal,

Thanks for your comments.  Responses in-line.

Alia

> doing arbitrary network functions where the ForCES was then used to

[Alia] You have been talking about ForCES as being applicable for quite a
while.  It would be interesting to read a draft that does the
compare/contrast for I2RS as well as the data-model for the RIB info model.
  There are also concerns about duplicating data models in different
technologies and issues around tool-chain availability and automation.

> control need to take into consideration those two requirements above the

[Alia] Yes, the transport needed depends on the communication pattern being
used and that ties to the data-models as well.  I think we need a protocol
requirements draft that describes some of this in more detail.  I have the
idea that I2RS would have a default transport - and then some information
streams may only be available over a different transport channel - or the
client could request data across a different transport channel and so on.

> It would be useful to specify some sample space of common practise.

[Alia] Sure - I think this has to come out of the security space.  I've
heard suggestions about looking at the NetConf Access Control Model
(RFC6536).  I believe that Wes George was looking at some ideas and there
were a number of security-related folks interested at the WG meeting.

Regards,
Alia

> more

---

From: Alia Atlas <[email-masked]>
Date: Tue, 13 Aug 2013 17:18:40 -0400

I believe I have now responded to all the comments on
draft-atlas-i2rs-architecture-01.  I have updated the draft and submitted
it as draft-atlas-i2rs-architecture-02.

Please take a look at the differences and see if your suggestions and
concerns have been addressed.

Thanks,
Alia

---

From: t.petch <[email-masked]>
Date: Wed, 14 Aug 2013 10:24:05 +0100

----- Original Message -----
From: "Alia Atlas" <[email-masked]>
To: "Joe Marcus Clarke" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, August 13, 2013 9:01 PM

> On Wed, Jul 31, 2013 at 6:57 AM, Joe Marcus Clarke
<[email-masked]>wrote:
<snip>
> that "Each I2RS Client will have a unique identity" - but  that just
helps

I think that this nicely encapsulates a confusion between identity and
identifier.  Identifiers identify.  Objects, in a very generic sense,
have identity.  Thus if a human being is an instance of an object, they
may be identified, based on context, by SSN, passport number, name, name
and date of birth, cell phone number etc; all could be valid
identifiers: but equally, a cell phone number could be the identifier of
a cell phone, which is associated with a function and multiple people,
while the cell phone could also be identified by its IMEI so the
determination of what is an identity, may take some consideration.  This
is often critical in security; you have a secure channel but with what?
Is the identifier sufficient proof of the identity?

Working with routers, you usually have multiple identifiers; the SNMP
sysName is not (usually) the OSPF 32 bit router id, while the BGP
Identifier (note, identifier) is different again.

Identifiers exist within a namespace, with rules about syntax,
uniqueness and so on (even if this are not made explicit).

The revised I-D contains
" A secondary  identity is merely a unique, opaque identifier ..."
and
"An I2RS Client may supply a secondary opaque  identity .. "

I think that most uses of the word "identity" in this I-D are actually
referring to "identifier" but at the same time, given that almost all
routers have multiple identifiers (as above), then this issue, of the
difference between identity and identifier needs making explicit in this
I-D.

Tom Petch

(p.s. if you have multiple virtual routers in one physical router, how
many identities are there? Discuss.)

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 14 Aug 2013 05:57:54 -0400

The virtual router question is an interesting one.  I believe that the 
answer is "it depends".
On the one hand there is a base device.  There may or may not need to be 
capability for I2RS access to that entity.
Then there are the individual virtual routers.  My inclination would be 
to use separate I2RS clients, each with a separate I2RS identity and 
identifier.  But there appears to be enough flexibility in the modeling 
that we are discussing that one could probably model it as one I2RS 
agent with various pieces and parts.  In which case that one agent has 
only one identity and one identifier.

Yours,
Joel

On 8/14/13 5:24 AM, t.petch wrote:
> "An I2RS Client may supply a secondary opaque  identity .."
>

---

From: Joe Marcus Clarke <[email-masked]>
Date: Wed, 14 Aug 2013 13:41:28 -0400

On 8/13/13 4:01 PM, Alia Atlas wrote:
> [Alia] For the I2RS Agent to properly handle a collision, it does need
> to store the client identifier.  I think that is clear in Sec 5.2
> "Simply, the I2RS agent stores who did what operation to which entity."
> and the details in Sec 6.8 are "The current recommendation is to have a
> simple priority associated with each I2RS clients, and the highest
> priority change remains in effect. In the case of priority ties, the
> first client whose attribution is associated with the data will keep
> control."  We already have a reference to Sec 6.8 right there - and that
> section is where the details are discussed.  What specific additional
> verbiage do you think would be useful?   The priority is a knob to allow
> overwriting of other applications' state - though needing to is
> considered an error. :-)

When I first read this, I wanted something stronger to prevent clients
from writing to the same piece of data.  I think the forward references
are fine if perhaps a bit late in the text.  But my ask was to
strengthen the language to say "must not write."

> [Alia] I think it is folded into the read scope.  If we find the need
> for such a term later on, then we can add it.

This section talks about "terminology" used in the draft.  However,
"read scope" as terminology is not used anywhere.  The concept of
_reading_ data is, however, quite prevalent.  In the same way, the draft
talks about "notification" in a number of contexts.  As such, I feel
there is enough distinction there to warrant calling out what is meant
by a notification scope.

"notification scope: The set of events and associated information that
will be sent northbound by the I2RS Agent to I2RS Clients.  Clients have
the ability to register for specific events, but must do so given the
access restrictions of their associated read scope."

> [Alia] What do you have in mind?  The I2RS client will have a security
> role and its scope.  The I2RS client needs to vet the applications that
> it is a broker for.  The opaque ID can be something that is meaningful
> to that I2RS client.   Basically, I2RS is providing the identity and
> security for between the I2RS client and the I2RS agent.  I don't see it
> as practical or appropriate to try and define how the I2RS client and
> its applications interact; I know the broker/controller model is popular
> and so we do need enough to help support traceability to a secondary ID,
> but I'm not sure what is needed or appropriate beyond that. 

After listening to the working group session and based on other threads,
this text is now clearer to me.  To summarize my feeling, I don't think
I2RS should mandate a northbound Client protocol, but we need a unique
way to identify the specific Client that obtained access.  This means
that even in a load-balancing or HA case, there must be a way to
uniquely identify the Client that communicate with the Agent.  The
northbound actor driving the Client should also be identifiable, but
that is outside the scope of this document.

> changes to state from itself or from a different I2RS Client.  

WFM, thanks.

> protocol" describes a new route being learned.   I'd prefer not to put
> OSPF neighbor removal in as an example.  It raises the questions about
> what is configuration vs. ephemeral data and the I2RS scope.  If you
> have a good use-case that requires it, then I'd be quite interested in
> seeing it.   

I was specifically asking about an _event_ use case.  Very simply if we
learn/lose a route, I'd want my Client to be notified so I can perhaps
react to it to install another route or remove a route I have previously
installed (e.g., a failover/failback use case).

Additionally, if a peer is otherwise reachable, but stops participating
in OSPF, BGP, etc., I would like I2RS to notify my Client as I may not
know about this any other way (though I could be flooded with route
delete events, it's good to correlate that to a peer going away).

> [Alia] I am happy to add in an editor's note for more discussion - but
> we should start that conversation now on the list - because the WG does
> have quite tight deadlines for milestones.  

Fair enough.

> [Alia] Yes - DCCP is clearly the wrong choice for a control channel -
> but it may be
> section.  Since you are the second person to be confused by that
> section, I've added the following sentence:
> 

That works.

> use-cases we consider need and what the related information and data
> models need to be.  If you look at the
> draft-bitar-i2rs-service-chaining-00, it does ask for things like CPU
> load.  I do think there is a real need to be able to get back
> thresholded and filtered information.  You probably heard Ed's personal
> thoughts about a single protocol as well...   So - I don't think the
> architecture needs to restrict the data in scope - particular in a
> section that is talking about communication patterns - but as a WG, we

My concerns comes from a desire not to have I2RS become a common
API/protocol for things that SNMP or NETCONF or some other potential
data collection scheme is used for.  So I agree we need a tight focus
and potentially a litmus test for what should be adopted as collectable
data via I2RS.  As it stands now, I think someone could argue for any
kind of data and present a use case for it (e.g., latency, interface
errors, location).  So the statement I made was more around the lines of
should I2RS stay pure to routing and routed topology or should we really
open the door to other data that is not specifically related to routing?

Joe

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 14 Aug 2013 13:48:41 -0400

Depending upon how one reads RFCs, declaring that having two writers is 
an error is a MUST NOT write.
But we are also trying to recognize that no matter how many MUST NOT 
statements we produce, things happen.  So we are trying to define the 
handling.  I can live with precedence.  I can live with "the item does 
not change".  But I do think it is helpful for us to be explicit about 
the behavior in this far-to-likely error case.

Yours,
Joel

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 14 Aug 2013 18:12:37 +0000

Joel,

On Aug 14, 2013, at 5:57 AM, Joel M. Halpern <[email-masked]> wrote:

> The virtual router question is an interesting one.  I believe that the answer is "it depends".
> On the one hand there is a base device.  There may or may not need to be capability for I2RS access to that entity.

It seems to me that this is dependent on whether the device is part of the routing system -- not whether it is physical or virtual. Does it have a RIB, participates in routing, and an interface to routing? If the answer is yes, then I2RS needs access (whether the base device or an individual virtual one).

> Then there are the individual virtual routers.  My inclination would be to use separate I2RS clients, each with a separate I2RS identity and identifier.

I agree with this (assuming you meant to write "I2RS agent" or "I2RS server" instead of "I2RS client") -- basically, if it is a node in the topology, it needs its I2RS identity.

>  But there appears to be enough flexibility in the modeling that we are discussing that one could probably model it as one I2RS agent with various pieces and parts.  In which case that one agent has only one identity and one identifier.
> 

I think there's potentially more than this, namely: proposed I2RS topology information models support node aggregation / virtual topologies. Shouldn't each node at a different level of the hierarchy have its own identity (and identifier)?

Thanks,

-- Carlos.

---

From: Jakob Heitz <[email-masked]>
Date: Wed, 14 Aug 2013 18:14:01 +0000

Or say: "must write atomically".

Here is one way:
In the WRITE message, put the value you want to write, as well as the value that you think that the parameter currently has.
You can get the value "you think it has" from a previous READ, then you repeat that in your WRITE message.
The target of the WRITE will refuse to write your value and return an error if the value was not what you thought it was.

Another way:
READ with reservation. When you READ, then set a reservation.
When anyone WRITEs the same parameter, it kills all reservations.
When you WRITE, the target system checks if you have a reservation and refuses to write if you don't and returns an error.

Or you can write lock the parameter.

--
Jakob Heitz.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Joel M. Halpern
> Sent: Wednesday, August 14, 2013 10:49 AM
> To: Joe Marcus Clarke
> Cc: [email-masked]; Alia Atlas
> Subject: Re: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01
> (ends Aug 12)
> 
> Depending upon how one reads RFCs, declaring that having two writers is an
> error is a MUST NOT write.
> handling.  I can live with precedence.  I can live with "the item does not
> change".  But I do think it is helpful for us to be explicit about the behavior in
> this far-to-likely error case.
> 
> Yours,
> Joel
> 
> 
> >> [Alia] For the I2RS Agent to properly handle a collision, it does
> >> need to store the client identifier.  I think that is clear in Sec
> >> 5.2 "Simply, the I2RS agent stores who did what operation to which
> entity."
> >> and the details in Sec 6.8 are "The current recommendation is to have
> >> a simple priority associated with each I2RS clients, and the highest
> >> control."  We already have a reference to Sec 6.8 right there - and
> >> that section is where the details are discussed.  What specific additional
> > from writing to the same piece of data.  I think the forward
> > references are fine if perhaps a bit late in the text.  But my ask was
> > to strengthen the language to say "must not write."
> >
> >>
> >>
> >>      Section 2:
> >>
> >>      read scope: ...
> >>
> >>      write scope: ...
> >>
> > _reading_ data is, however, quite prevalent.  In the same way, the
> > draft talks about "notification" in a number of contexts.  As such, I
> > feel there is enough distinction there to warrant calling out what is
> > meant by a notification scope.
> >
> > will be sent northbound by the I2RS Agent to I2RS Clients.  Clients
> > have the ability to register for specific events, but must do so given
> > the access restrictions of their associated read scope."
> >
> >>
> >>      Section 3.4:
> >>
> >> [Alia] What do you have in mind?  The I2RS client will have a
> >> security role and its scope.  The I2RS client needs to vet the
> >> applications that it is a broker for.  The opaque ID can be something that is
> meaningful
> >> security for between the I2RS client and the I2RS agent.  I don't see
> >> it as practical or appropriate to try and define how the I2RS client
> >> and its applications interact; I know the broker/controller model is
> >> popular and so we do need enough to help support traceability to a
> >> secondary ID, but I'm not sure what is needed or appropriate beyond
> that.
> >
> > After listening to the working group session and based on other
> > threads, this text is now clearer to me.  To summarize my feeling, I
> > don't think I2RS should mandate a northbound Client protocol, but we
> > need a unique way to identify the specific Client that obtained
> > access.  This means that even in a load-balancing or HA case, there
> > must be a way to uniquely identify the Client that communicate with
> > the Agent.  The northbound actor driving the Client should also be
> > identifiable, but that is outside the scope of this document.
> >
> >>      Section 5.2.2:
> >>
> >> [Alia] I'll put in: "An I2RS Client may register for notifications
> >> when state that was applied by a particular I2RS Client is modified
> >> or removed."  That is slightly different since it allows an I2RS
> >> Client to learn about the changes to state from itself or from a
> >> different I2RS Client.
> >
> > WFM, thanks.
> >
> >>
> >>      Section 5.4.2:
> >>
> >> OSPF neighbor removal in as an example.  It raises the questions
> >> about what is configuration vs. ephemeral data and the I2RS scope.
> >> If you have a good use-case that requires it, then I'd be quite
> >> interested in seeing it.
> >
> > I was specifically asking about an _event_ use case.  Very simply if
> > we learn/lose a route, I'd want my Client to be notified so I can
> > perhaps react to it to install another route or remove a route I have
> > previously installed (e.g., a failover/failback use case).
> >
> > Additionally, if a peer is otherwise reachable, but stops
> > participating in OSPF, BGP, etc., I would like I2RS to notify my
> > Client as I may not know about this any other way (though I could be
> > flooded with route delete events, it's good to correlate that to a peer going
> away).
> >
> >>
> >>
> >>
> >>      Section 5.4.4:
> >>
> >> [Alia] I am happy to add in an editor's note for more discussion -
> >> but we should start that conversation now on the list - because the
> >> WG does have quite tight deadlines for milestones.
> >
> > Fair enough.
> >
> >>      Section 6.1:
> >>
> >> section that is talking about communication patterns - but as a WG,
> >> we need to keep a tight focus that still provides sufficient
> >> information to fully solve the desired use-cases.
> >
> > and potentially a litmus test for what should be adopted as
> > collectable data via I2RS.  As it stands now, I think someone could
> > argue for any kind of data and present a use case for it (e.g.,
> > latency, interface errors, location).  So the statement I made was
> > more around the lines of should I2RS stay pure to routing and routed
> > topology or should we really open the door to other data that is not
> specifically related to routing?
> >
> > Joe
> >
> >>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 14 Aug 2013 18:22:58 +0000

Thanks for all the responses, Alia.

Please find some follow-ups inline.

On Aug 13, 2013, at 2:44 PM, Alia Atlas <[email-masked]> wrote:

> Hi Carlos,
> 
> Thanks for the review and comments.  I apologize for the delay in responding.  I took some vacation after IETF.
> 
> 
> On Sun, Jul 28, 2013 at 6:06 PM, Carlos Pignataro (cpignata) <[email-masked]> wrote:
> I also take the chance to share some questions and provide some review feedback (with "CMP"):
> 
> CMP: "and forwarding data"? Ultimately the interface will influence forwarding, but is it focused on it?
> 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.
> 
> [Alia] I see them as grouped into "routing and signaling" and definitely part of I2RS.  The problem-statement draft (not a WG draft yet) clearly states: 
> "In addition to interfaces to the RIB layer, there is a need to configure the various routing and signaling protocols with differing dynamic state based upon application-level policy decisions." and the framework draft that this architecture replaces had a slightly larger section on use-cases and examples.
> 
> What is your specific concern and how would you want to see the reach and scope confined in the architecture draft?
>  

Perhaps simply by aligning with the problem statement wording, in terms of "routing and signaling". Or is the "signaling" piece confined to label distribution?

> 
>    I2RS Client:   ...  It interacts with the I2RS clients to collect information
> 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".
> 
> [Alia]  First, the I2RS clients should be I2RS agents.  I've fixed that.  Second, these are a bit further reaching.  For instance, learning about link up/down events, subscribing to counters for when they go over a particular threshold, etc.  Basically, to provide the information necessary for a network application's feedback loop, information outside of the routing system may be necessary to read/learn.  The exact details will depend on the use-cases and proposed info-models.
> 

Thanks for the clarification -- this works.

> 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.
> 
>    secondary identity:  An I2RS Client may supply a secondary opaque identity that is not interpreted by the I2RS Agent. An example use is when the I2RS Client is a go-between for multiple
> CMP: It seems to me that the identity of an application is also critical for Accounting (and troubleshooting).
> 
> [Alia] Yes, tracking the attribution of operations allows aspects like accounting and troubleshooting.  I've modified the sentence to end:
> 
> ...identifier that can be provided by the I2RS client to the I2RS agent for purposes of tracking
> attribution of operations to support functionality such as accounting and troubleshooting.
> 
> [Alia] Sure - I'll upgrade it to "should indicate".  This is a question of supporting the broker model of an I2RS client for ease of troubleshooting.
>  
> 
> CMP: Tunnels are some times key elements in a topology. Are tunnels considered as "interfaces" or should those be called out explicitly?
> 
> [Alia] Tunnels aren't interfaces - but the details of what should be in the topology depends on the topology info-model and isn't specified in the architecture.
>  

Fair enough -- I agree it's not within the scope here, but I do thing that tunnels require some looking into.

> 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.
> 
> [Alia] BGP is already mentioned as a protocol that will need an info-model.  I guess I think of this section as discussing the transport LSPs and associated protocols as compared to the MPLS services.  The MPLS services are part of routing and should be included too.  I've changed the text in Sec 5.4.3 to read:
> 
> [Alia] There may be cases of data streams that don't require a reliable underlying transport.  I'm thinking about providing statistics streams.   I am concerned about the issues with timely delivery that can arise with TCP - but I think that what transport protocol is appropriate will depend a bit on what data is being delivered.
>  

Blanked Ack for all the edits and fixes. Thanks much!

-- Carlos.
PS: and thanks for not responding earlier, others were on vacation as well :-)

> > 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: "Joel M. Halpern" <[email-masked]>
Date: Wed, 14 Aug 2013 14:24:16 -0400

write-locks / atomic writes are an interesting quesiton, but probably 
should not be thought about as part of the multiple writers case.  The 
multiple writers case is:
A writes value X.
B decides to write value Y.
How clever do we want to be about handling this.
The answer we have proposed is "as simpleminded as we can get away with."
The specifics we chose are
1) this is an error case
2) there are priorities which determine which value ends up in effect.

Atomic writes could come up when there is a race, but more likely would 
come up when there are system effects which would change this value when 
it is not pinned by I2RS.

Yours,
Joel

---

From: Alia Atlas <[email-masked]>
Date: Wed, 14 Aug 2013 14:27:00 -0400

I'd discussed the problem of depending on read values to write - whether
the same value or a different one - with Ron Bonica a while ago.

I rather like your WRITE operation idea - where one could generalize to be
able to specify other parameters as well.  Thus, it could be WRITE X <-p if
Y=n and Z=m - or the simple X <- p if X==q.

Alia

On Wed, Aug 14, 2013 at 2:14 PM, Jakob Heitz <[email-masked]>wrote:

> In the WRITE message, put the value you want to write, as well as the
> value that you think that the parameter currently has.
> The target of the WRITE will refuse to write your value and return an
> error if the value was not what you thought it was.
>
> Another way:
> When you WRITE, the target system checks if you have a reservation and
> refuses to write if you don't and returns an error.
>
> not
> > >>         happen, but are considered error cases that should be
> resolved by
> > the
> > >>      versus any information from the network element (e.g., it does
> not
> > cover
> > >>      CPU statistics).
> > >>
> > >>

---

From: Alia Atlas <[email-masked]>
Date: Wed, 14 Aug 2013 15:11:25 -0400

Joe,

I'm cutting old stuff out and just responding in-line to the rest....

> strengthen the language to say "must not write."

 [Alia] I don't really see that saying "must not write" instead of "should
not write" makes any meaningful improvement.  We've said in the
architecture that it should be considered an error.   I, personally, think
that SHOULD applies more than MUST; the system behavior will be well
understood in either event if the I2RS agent detects the collision.  If
multiple clients do try and write the same value, it will not be
catastrophic nor result in I2RS failing.  Thus, I think should is more
accurate.

> access restrictions of their associated read scope."

[Alia] Sure - if you care about it that much.   However, I think that
notification scope is
"The set of events and associated information that the I2RS Client can
request be pushed by the I2RS
Agent.  I2RS Clients have the ability to register for specific events
and information streams, but must do so given the access restrictions
of their notification scope."

I'll put this in the next version of the draft.

> that is outside the scope of this document.

[Alia] I think that there can be a number of ways to uniquely identify a
client beyond its I2RS Client Identifier.  The question is whether we need
"client identity", "sub-client identity" and "secondary identity".  Does
"secondary identity" also need a "secondary sub-identity" to account for
redundancy or load-balancing on the part of the application using the I2RS
Client as a broker?   Perhaps this is better discussed in the redundancy
thread?

> delete events, it's good to correlate that to a peer going away).

[Alia] Oh, yes - I missed that this was for events!   Sorry!  I'll add:
"* subscribing to an information stream of route changes
 * receiving notifications about peers coming up or going down"

> open the door to other data that is not specifically related to routing?

[Alia] Some routing use-cases need data that isn't purely "routing and
signaling".  Do we force them to use another protocol or do
screen-scraping?  I don't know the correct answer - and I'm not sure the WG
does either.  Given that it is I2RS, I think the emphasis on routing can be
assumed?

Alia

---

From: Alia Atlas <[email-masked]>
Date: Wed, 14 Aug 2013 15:18:14 -0400

Hi Carlos,

Responses in-line with stuff agreed and no longer relevant cut for easier
reading.

On Wed, Aug 14, 2013 at 2:22 PM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> Perhaps simply by aligning with the problem statement wording, in terms of
> "routing and signaling". Or is the "signaling" piece confined to label
> distribution?
>

[Alia] Sure - happy to change the "Routing" to "Routing and Signaling" in
the description and in the figure.

> [Alia] Tunnels aren't interfaces - but the details of what should be in
> the topology depends on the topology info-model and isn't specified in the
> architecture.
>
>
>

[Alia] Absolutely - I'd suggest talking to Joel Halpern, Jan Medved, Adrian
Farrell, Tom Nadeau, and others interested in the topology info-model.

> PS: and thanks for not responding earlier, others were on vacation as well
:-)  I hope yours was fun too!   The Pergamon Museum was amazing.

Alia

---

From: Alia Atlas <[email-masked]>
Date: Wed, 14 Aug 2013 15:19:52 -0400

Joel,

I agree - but I do think the atomic writes is interesting for handling
write decisions based upon dynamic state that could be changed.  Something
to think about for a later version perhaps - and unrelated to the multiple
writers of the same data case.

Alia

On Wed, Aug 14, 2013 at 2:24 PM, Joel M. Halpern <[email-masked]>wrote:

> come up when there are system effects which would change this value when it
> is not pinned by I2RS.
>
> Yours,
> Joel
>
>
>>> Subject: Re: [i2rs] Call for Adoption by WG:
>>> draft-atlas-i2rs-architecture-**01
>>> (ends Aug 12)
>>>
>>>>>       JMC:  Previously I had commented that one event that should be
>>>>>
>>>> supported
>>>
>>>>>       JMC: Consider adding an example for an event such as a new route
>>>>>
>>>> being
>>>
>>>>>          including knobs which affect local path computation and queue
>>>>>
>>>> control
>>>
>>>>>          between the I2RS Agent and the network element, in order to
>>>>>
>>>> provide
>>>
>>>>> draft-bitar-i2rs-service-**chaining-00, it does ask for things like
>>>>> CPU
>>>>>  ______________________________**_________________
>>> i2rs mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/**listinfo/i2rs<https://www.ietf.org/mailman/listinfo/i2rs>
>>>
>>
>>