Subject: [i2rs] Comments to draft-ietf-i2rs-architecture-02.txt

From: Linda Dunbar <[email-masked]>
Date: Wed, 26 Feb 2014 00:56:11 +0000

Alia, et al,

Here are my comments and questions to the draft-ietf-i2rs-architecture-02.txt:

-          Last paragraph of Section 1, Typo "tivial example". Do you mean "trivial example"?

-          Section 3.2 (Extensibility): This section is more on justifying the scope of I2RS than the architecture.

-          Section 3.3 (Model - Driven ...): what is "model-driven architecture and protocol(s)"? is Yang model a valid one? Or Netconf?

-          Section 6.2.1 (I2RS Agent Failure)

o   Unexpected failure: it is very likely under the "unexpected failure" that the I2RS agent loses its records of clients. A more reasonable way is for I2RS agent to broadcast its status (e.g. restart), to let the Clients to re-subscribe if they need to.

-          6.4.2 (IGP, BGP, ..):

o   The first bullet says "Directly writing to these protocol-specific RIBs or databases is out of scope for I2RS."

o   The information model defined by draft-ietf-i2rs-rib-info-model-02 has "route", nexthop", modifying them can impact the result of those protocol-specific RIBs.

o   The last paragraph seems to say that local route attributes can be changed, e.g. link metrics, local attachment, however, information received from other nodes (LSA) can't be modified, is it correct?

o   Then, all those local attributes can also be modified by CLI, correct?

-          6.4.5: this section is more like the requirement for Informational model. I don't see how  they impact the architecture.

-          Which entity does the cross check if policies to one Routing Element from different Clients are contradicting with each other?

o    Page 8 states that two clients can't attempt to write (modify) the same piece of information.  Does it mean two clients can't write (modify) "Tunnel nexthops" or "weighted lists" (defined by draft-ietf-i2rs-rib-info-model-02)? What if two clients need to modify "Tunnel nexthops" for some prefixes (e.g. two different applications for one virtual network)?

o   How to guarantee it?

-          Who checks policies to multiple routing elements are contradicting to each other?

-          Today's router can be configured/ changed by CLI, or NETCONF, monitored by SNMP, how is "I2RS" agent different from those entities?

-          What if clients need to re-direct traffic on attributes that are not in the RIB?

Linda Dunbar

---

From: Scott Brim <[email-masked]>
Date: Wed, 26 Feb 2014 05:17:26 -0500

On Feb 25, 2014 7:56 PM, "Linda Dunbar" <[email-masked]> wrote:
> o   Unexpected failure: it is very likely under the "unexpected failure"
that the I2RS agent loses its records of clients. A more reasonable way is
for I2RS agent to broadcast its status (e.g. restart), to let the Clients
to re-subscribe if they need to.

The problem is: who should an agent broadcast its failure to? How does it
know where the active clients are for particular services? There are some
security concerns here.  If non-volatile memory is not good enough, then a
policy server could be used as a knowledgeable intermediary (many of your
comments imply capabilities in policy servers), but that just pushes the
problem around, it doesn't make it go away.

Scott

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 26 Feb 2014 14:38:33 +0000

Questions inserted below:

From: Scott Brim [mailto:[email-masked]]
Sent: Wednesday, February 26, 2014 4:17 AM
To: Linda Dunbar
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [i2rs] Comments to draft-ietf-i2rs-architecture-02.txt

> o   Unexpected failure: it is very likely under the "unexpected failure" that the I2RS agent loses its records of clients. A more reasonable way is for I2RS agent to broadcast its status (e.g. rest…

The problem is: who should an agent broadcast its failure to? How does it know where the active clients are for particular services? There are some security concerns here.  If non-volatile memory is not good enough, then a policy server could be used as a knowledgeable intermediary (many of your comments imply capabilities in policy servers), but that just pushes the problem around, it doesn't make it go away.

[Linda] How does the client initially found the I2RS agent and establish the connection? Is it by management intervention? Clients can use the same approach. If it is by management intervention, the I2RS agent can simply report the "restart status" to the "system" that associates clients with I2RS agents.

Scott

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 26 Feb 2014 11:05:15 -0500

Linda, I am not following your answer to Scott's question.  Further in line.

On 2/26/14, 9:38 AM, Linda Dunbar wrote:
> *From:*Scott Brim [mailto:[email-masked]]
> *Sent:* Wednesday, February 26, 2014 4:17 AM
> *To:* Linda Dunbar
> *Cc:* [email-masked]; [email-masked];
> [email-masked]
> *Subject:* Re: [i2rs] Comments to draft-ietf-i2rs-architecture-02.txt
>
>
>  > o   Unexpected failure: it is very likely under the “unexpected
> failure” that the I2RS agent loses its records of clients. A more
> reasonable way is for I2RS agent to broadcast its status (e.g. restart),
> to let the Clients to re-subscribe if they need to.
>
> The problem is: who should an agent broadcast its failure to? How does
> it know where the active clients are for particular services? There are
> some security concerns here.  If non-volatile memory is not good enough,
> then a policy server could be used as a knowledgeable intermediary (many
> of your comments imply capabilities in policy servers), but that just
> pushes the problem around, it doesn't make it go away.
>
> [Linda] How does the client initially found the I2RS agent and establish
> the connection? Is it by management intervention? Clients can use the
> same approach. If it is by management intervention, the I2RS agent can
> simply report the “restart status” to the “system” that associates
> clients with I2RS agents.

I2RS clients do not find I2RS Agents.  I2RS Agents are contacted by I2RS 
Clients.  The closest they come to "finding" is if the I2RS Agent 
registers for notifications, then the I2RS Client will later send that 
I2RS Agent notifications.  But that is dynamic information created by 
the I2RS Agent.

So the I2RS Agent has no means to broadcast the restart to all I2RS 
Clients.  Unless of course it has persistent storage of I2RS state.  In 
which case it would not need to broadcast the information.

Yours,
Joel

>
> Scott
>
>
>
> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
>

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 26 Feb 2014 16:17:14 +0000

Joel, 

-----Original Message-----

I2RS clients do not find I2RS Agents.  I2RS Agents are contacted by I2RS Clients.  The closest they come to "finding" is if the I2RS Agent registers for notifications, then the I2RS Client will later send that I2RS Agent notifications.  But that is dynamic information created by the I2RS Agent.

[Linda] I meant to ask "at the very beginning, where does the I2RS clients get the information on which I2RS agent to register for notification"? 
Is it by some management entity? If yes, then when the I2RS agent restarts, the I2RS agent should send a notification to this "management entity", instead depending on the I2RS agent's non-volatile DB. It is possible during the time that this I2RS agent is down, the client is reassigned to a different agent. 

Linda

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 26 Feb 2014 11:22:51 -0500

Linda, (think you for trimming.)

On 2/26/14, 11:17 AM, Linda Dunbar wrote:
> Joel,
>
> --- Joel Halpern wrote ---
> > I2RS clients do not find I2RS Agents.  I2RS Agents are contacted by
> > I2RS Clients.  The closest they come to "finding" is if the I2RS
> > Agent registers for notifications, then the I2RS Client will later
> > send that I2RS Agent notifications.  But that is dynamic information
> > created by the I2RS Agent.
>
> [Linda] I meant to ask "at the very beginning, where does the I2RS
> clients get the information on which I2RS agent to register for
> notification"? Is it by some management entity? If yes, then when the
> I2RS agent restarts, the I2RS agent should send a notification to
> this "management entity", instead depending on the I2RS agent's
> non-volatile DB. It is possible during the time that this I2RS agent
> is down, the client is reassigned to a different agent.

I2RS Clients locate I2RS agents by many means.  We are not mandating 
them.  For example, an I2RS agent may start by using local means to find 
its local router.  It can then use I2RS mechanisms to get the topology. 
  Based on that, and the service it wants to provide, it can then select 
which I2RS agents to register with and what events to register for.  But 
that is only one example.  It may be that some other entity (a PCE for 
example) provides the needed topology information. Or any number of 
other deployment models.  The I2RS Agent failure notification mechanism 
ought not be dependent upon the I2RS client deployment and management 
strategy.

Yours,
Joel

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 26 Feb 2014 16:35:41 +0000

Joel, 

Agree that "I2RS Clients locate I2RS agents by many means". 
For each method, there must be a coordinator (or system) to facilitate the association. My main point is let the "restart status" being sent to this "coordinator", instead depending on the I2RS agent's non-volatile DB. It is possible during the time that this I2RS agent is down, the client is reassigned to a different agent.

Linda

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Wednesday, February 26, 2014 10:23 AM
To: Linda Dunbar; [email-masked]
Subject: Re: [i2rs] Comments to draft-ietf-i2rs-architecture-02.txt

On 2/26/14, 11:17 AM, Linda Dunbar wrote:
> I2RS agent restarts, the I2RS agent should send a notification to this 
> "management entity", instead depending on the I2RS agent's 

I2RS Clients locate I2RS agents by many means.  We are not mandating them.  For example, an I2RS agent may start by using local means to find its local router.  It can then use I2RS mechanisms to get the topology. 
  Based on that, and the service it wants to provide, it can then select which I2RS agents to register with and what events to register for.  But that is only one example.  It may be that some other entity (a PCE for
example) provides the needed topology information. Or any number of other deployment models.  The I2RS Agent failure notification mechanism ought not be dependent upon the I2RS client deployment and management strategy.

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 26 Feb 2014 11:44:30 -0500

Since
1) There is no requirement for such a coordinator.  (The fact that I 
personally expect it to be rare is irrelevant.)
2) Such a coordinator if used is not known a-priori to the I2RS Agents

I do not see that the I2RS Agent behvior can make use of this to 
simplify the restart notification behavior.  I would love to simplify 
that.  But this does not seem to do what is needed.

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 26 Feb 2014 17:42:23 +0000

Joel, 

What you stated is OK.  Maybe you can soften requirement on I2RS agent to remember everything after restart. Many things can happen while the agent is down. The information in the agent's non-volatile DB may be stale. 

Can authors address the other issues I raised in my original comments? 

Linda
-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Wednesday, February 26, 2014 10:45 AM
To: Linda Dunbar; [email-masked]
Subject: Re: [i2rs] Comments to draft-ietf-i2rs-architecture-02.txt

Since
1) There is no requirement for such a coordinator.  (The fact that I personally expect it to be rare is irrelevant.)
2) Such a coordinator if used is not known a-priori to the I2RS Agents

I do not see that the I2RS Agent behvior can make use of this to simplify the restart notification behavior.  I would love to simplify that.  But this does not seem to do what is needed.

On 2/26/14, 11:35 AM, Linda Dunbar wrote:
>    Based on that, and the service it wants to provide, it can then 
> select which I2RS agents to register with and what events to register 
> for.  But that is only one example.  It may be that some other entity 
> (a PCE for