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

[Alia Atlas <[e-mail]>]

Joe,

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

On Wed, Aug 14, 2013 at 1:41 PM, Joe Marcus Clarke <[e-mail]>wrote:

> On 8/13/13 4:01 PM, Alia Atlas wrote:
> >     Section 1.2:
>
> 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 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.


> >
> >
> >     Section 2:
> >
> >     read scope: ...
> >
> >     write scope: ...
> >
> >     JMC: Should there be an event or notification scope in addition to
> read
> >     and 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] 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.

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

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


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

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

[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