Subject: [i2rs] standard interfaces within scope for I2RS

From: Andy Bierman <[email-masked]>
Date: Sat, 22 Jun 2013 10:32:53 -0700

Hi,

I just re-read the framework and problem statement drafts.
Only 1 minor issue in the problem statement draft:

The 'I2RS Agent' is shown as a single box in figure 1.

 1) Does this mean the protocol between the "broker" and the
     NEs is proprietary, or just not shown?

 2) Does this mean that an I2RS Client never talks directly to an NE
     or does it mean all I2RS Agent functionality is available on all NEs?

Nit, sec. 6, para 4:
   - the lack of standard data models is the problem of the NETMOD WG,
     not really the NETCONF protocol.
   - s/may help define needed/may require help defining needed/

Andy

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 23 Jun 2013 11:16:42 +0200

I beleive if any thing not shown then they are not allowed by I2RS, if
it is shown then it is the way the I2RS will work to solve the
problem. So I will understand that I2RS client does not talk to NE but
only to the agent, that is why I suggest that we don't show any sign
that the client can talk to any other as long it is out of scope.
Therefore the drawing methodology (figure 1) is : (if out of scope of
the protocol then should not be shown, and if future work of protocol
it may be shown).

AB

---

From: Andy Bierman <[email-masked]>
Date: Sun, 23 Jun 2013 08:59:40 -0700

Hi,

If an I2RS client wants to set up a tunnel between 2 routers
(as a lame example), does it send 1 request to 1 I2RS agent
or 2 requests, 1 to each I2RS agent/router?  If 1 request, is the southbound
protocol between the I2RS agent and at least 1 router proprietary
or part of the standard?

I think this draft should be clear about what is in scope.
It seems to say that the southbound protocol is out of scope.

Andy

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 23 Jun 2013 15:47:25 -0400

I think that the particular example you propose will onot help.
Some tunneling protocols only requrie action at one end to initiate a 
bi-directional tunnel.  I that case, presumably, the I2RS client would 
only need to interact with that one end.  Other protocols require action 
/ configuration at both ends to establish a bi-directional tunnel.  In 
that case, the i2rs client would need to interact with both ends.  (And 
other protocols are even stranger.)

If your question is whether i2rs includes a protocol between i2rs agents 
to coordinate action across boxes, separate from existing protocol 
mechanisms, then I believe that the answer is a clear "no".  There is is 
agent-agent protocol in scope for the i2rs work.

Yours,
Joel

On 6/23/2013 11:59 AM, Andy Bierman wrote:
> On Sun, Jun 23, 2013 at 2:16 AM, Abdussalam Baryun
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     On 6/22/13, Andy Bierman <[email-masked]
>     <mailto:[email-masked]>> wrote:
>      > Hi,
>      >
> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
>

---

From: Andy Bierman <[email-masked]>
Date: Sun, 23 Jun 2013 13:25:13 -0700

On Sun, Jun 23, 2013 at 12:47 PM, Joel M. Halpern <[email-masked]>wrote:

> bi-directional tunnel.  I that case, presumably, the I2RS client would only
> need to interact with that one end.  Other protocols require action /
> configuration at both ends to establish a bi-directional tunnel.  In that
> case, the i2rs client would need to interact with both ends.  (And other
> protocols are even stranger.)
>
No, my question is how many I2Rs agents does a client need to
contact to perform a task that requires changes on multiple routers?

Andy

>> <[email-masked] <mailto:abdussalambaryun@**gmail.com<[email-masked]>>>
>> wrote:
>>
>> ______________________________**_________________
>> i2rs mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/i2rs<https://www.ietf.org/mailman/listinfo/i2rs>
>>
>>

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 23 Jun 2013 21:35:54 +0100

Andy,

> my question is how many I2Rs agents does a client need to

You probably won't like my answer "that depends".

If the effect of the action on router 1 is to cause router 1 to use a
routing/signaling protocol to make things happen in the network, then the answer
may be 1.

If the changes cannot be effected in that way, then the client may need to talk
to multiple routers to make the different things happen on each router.

And in between there lies the case of needing to touch some, but not all routers
because other routers in between are worked on by signaling/routing.

So the answer is 1 <= #agents <= #routers

And that answer is modulo there being only one agent on each router :-)

For (crass) examples of the above I give you:

Set up an LSP using RSVP-TE (just talk to head-end router)
Set up an end-to-end static route (talk to each router)
Set up a multi-segment pseudo-wire (talk to the T-PEs and the S-PEs)

Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 23 Jun 2013 21:54:37 +0100

Hi again Andy,

Answering emails out of order and speaking for myself only...

>     NEs is proprietary, or just not shown?

I think "not shown" and "not considered for the moment". Walking before we run
would tend to suggest that we start with the case of a single client talking to
one or more agents in any single use case.

The concept of brokering between multiple clients talking to the same agent(s)
is definitely something we should have in our architectural view, but it makes
sense (to me) to solve the first piece first and only be aware of the looming
problem of brokering without trying to solve it on day one.

[That said, I should think in my naive protocol architect view of the world,
that the protocol from broker to agent would be the same as the protocol from
client to agent (because otherwise the agent will go mad), and that the protocol
from client to broker will be the same as the protocol from client to agent
(because otherwise the client will go mad). That means that the broker is a form
of proxy.]

>     or does it mean all I2RS Agent functionality is available on all NEs?

I don't know how to interpret "client never talks direct to an NE" because I
can't imagine putting the agent outside the NE. Maybe you are asking whether the
broker is always present between client and agent. If that is your question,
then my answer is a very strong "no".

To the second part of the question, I can imagine that while each agent will
support the full protocol, it will not support all of the data model components.
Crudely, this is the same as MIB module support by different routers all of
which support SNMP.

Ciao,
Adrian

---

From: Andy Bierman <[email-masked]>
Date: Sun, 23 Jun 2013 14:11:42 -0700

> to multiple routers to make the different things happen on each router.

I meant a high-level task performed by the client that requires
routing state to be manually injected on multiple routers,
not via routing protocols.

I am happy to consider the I2RS agent to be running on a single router
and the I2RS client to be the network-level broker.  The API to
specific network-wide services topology or routing can be standardized next.

IMO it is better to start with the core functionality that is expected on
one device
(for some definition of "core" the WG will agree on later).

Andy

And in between there lies the case of needing to touch some, but not all
> routers

---

From: Alia Atlas <[email-masked]>
Date: Tue, 25 Jun 2013 10:01:30 -0400

Hi Andy,

Thanks very much for the feedback.

In my view, I2RS is between the I2RS Agents and I2RS Clients.  An I2RS
Agent is associated with a single Routing element.
The I2RS agent can communicate with many I2RS Clients; an I2RS client can
talk to many I2RS agents.   I don't think that an
I2RS agent talks to other I2RS agents.

A routing element might have an I2RS agent and an I2RS client associated
with it.  For instance, say there's a routing element
that implements BGP and doesn't have a forwarding plane associated with it.
  The associated I2RS agent might support the BGP
service.  The associated I2RS client might be used to communicate to a
different routing element for its RIB service.

If a network application needs routing state at multiple routers, then I
agree with Adrian.  Either the i2RS client talks to each router
individually or the I2RS client talks to a single router to trigger the
distribution of the routing state (i.e. an RSVP-TE LSP, a prefix in OSPF,
etc).

I do hear you on the thoughts about a base core of functionalit y.  What
I'm picturing is that there are basically two types of info-models that
we need to create.  The first type are "per service" info models - where it
applies to a particular routing functionality - whether BGP, OSPF, ISIS,
RIB, PIM, RSVP-TE, etc.   We could use a better term than the overloaded
service - any suggestions?

The second type will be I2RS protocol-related info-models.  This might be
to describe I2RS-related event notifications or to control the role of a
client or to describe the capabilities of the I2RS agent in terms of what
services it supplies.  We haven't really touched on this part yet...

Each routing element may provide a different set of services - and I don't
think we can mandate what those are.  It'll depend on the role of the
routing element in the network.  What I think we can require is a set of
core I2RS protocol-related functionality - so that I2RS clients can learn
what is supported, the associated capabilities, etc.

Focusing on a few services at first, from a WG perspective, does make sense
to me.  I believe that is starting with the RIB information model and the
topology information model.  I think we need a simple BGP info model soon
as well - though I'm not sure if that's being worked on yet.

Regards,
Alia

On Sun, Jun 23, 2013 at 5:11 PM, Andy Bierman <[email-masked]> wrote:

>
>
> On Sun, Jun 23, 2013 at 1:35 PM, Adrian Farrel <[email-masked]>wrote:
>
>> Andy,
>>

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 26 Jun 2013 12:06:04 +0200

I agree with you Andy, I think the draft still is not clear,

AB