Subject: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt

From: [email-masked]
Date: Wed, 04 Jun 2014 10:44:23 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Interface to the Routing System Working Group of the IETF.

        Title           : Use Cases for an Interface to BGP Protocol
        Authors         : Keyur Patel
                          Rex Fernando
                          Hannes Gredler
                          Shane Amante
                          Russ White
                          Susan Hares
	Filename        : draft-keyupate-i2rs-bgp-usecases-02.txt
	Pages           : 17
	Date            : 2014-06-04

Abstract:
   A network routing protocol like BGP is typically configured and
   analyzed through some form of Command Line Interface (CLI) or
   NETCONF.  These interactions to control BGP and diagnose its
   operation encompass: configuration of protocol parameters, display of
   protocol data, setting of certain protocol state and debugging of the
   protocol.

   Interface to the Routing System's (I2RS) Programmatic interfaces, as
   defined in draft-ietf-i2rs-architecture, provides an alternate way to
   control and diagnose the operation of the BGP protocol.  I2RS may be
   used for the configuration, manipulation, analyzing or collecting the
   protocol data.  This document describes set of use cases for which
   I2RS can be used for BGP protocol.  It is intended to provide a base
   for the solution draft describing a set of interfaces to the BGP
   protocol.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-keyupate-i2rs-bgp-usecases/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-keyupate-i2rs-bgp-usecases-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-keyupate-i2rs-bgp-usecases-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 4 Jun 2014 14:49:29 -0400

Jeff and Ed: 

This updated draft has all the changes that Keyur Patel promised and updates
to the reference the current i2rs internet drafts.  

Would you please do a Working Group adoption call? 

Thank you, 
Sue Hares 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Wednesday, June 04, 2014 1:44 PM
To: [email-masked]
Cc: [email-masked]
Subject: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
 This draft is a work item of the Interface to the Routing System Working
Group of the IETF.

Abstract:

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

---

From: t.petch <[email-masked]>
Date: Thu, 5 Jun 2014 09:35:01 +0100

Sue

Currently you have six authors which is too many for an RFC - someone's
got to go!   For me, this is not just an admin point - when commenting,
I like to have one or two names, no more, as the clear pen holders whom
I can expect to act.  Too often, with so many names, everyone thinks
that someone else will do something and nothing happens, so, in all
seriousness, I oppose adoption until you sort this out amongst
yourselves.

Note too that you have a citation in the Abstract, again not allowed -
this can be surprising difficult to get round but get round it you, one
or more thereof, must.

Tom Petch

----- Original Message -----
From: "Susan Hares" <[email-masked]>
To: <[email-masked]>
Cc: "'Keyur Patel (keyupate)'" <[email-masked]>; "Hannes Gredler"
<[email-masked]>; "Russ White" <[email-masked]>; "'Susan Hares'"
<[email-masked]>; <[email-masked]>
Sent: Wednesday, June 04, 2014 7:49 PM
Subject: [i2rs] FW: I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 5 Jun 2014 04:47:23 -0400

Tom: 

I'm glad to change the citation in the abstract.    On the authors, this was
merge of two drafts. 

Sue  

-----Original Message-----
From: t.petch [mailto:[email-masked]] 
Sent: Thursday, June 05, 2014 4:35 AM
To: Susan Hares; [email-masked]
Cc: 'Keyur Patel (keyupate)'; Hannes Gredler; Russ White; 'Susan Hares';
[email-masked]
Subject: Re: [i2rs] FW: I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt

Sue

Currently you have six authors which is too many for an RFC - someone's
got to go!   For me, this is not just an admin point - when commenting,
I like to have one or two names, no more, as the clear pen holders whom I
can expect to act.  Too often, with so many names, everyone thinks that
someone else will do something and nothing happens, so, in all seriousness,
I oppose adoption until you sort this out amongst yourselves.

Note too that you have a citation in the Abstract, again not allowed - this
can be surprising difficult to get round but get round it you, one or more
thereof, must.

Tom Petch

---

From: Dean Bogdanovic <[email-masked]>
Date: Fri, 6 Jun 2014 20:02:58 +0000

Susan,

Many people don't know what NLRI abbreviation stands for (Network Layer Reachability Information , so writing it out first time would be a good idea. 

Throughout the text, the requirement number sequence is confusing until you get to the very and where all requirements are listed and then it makes sense.

REQ04: The ability to interact with various policies configured on
      the forwarding devices, in order to inform the policies
      implemented by the dynamic routing processes.  This interaction
      should be through existing configuration mechanisms, such as
      NETCONF, and should be recorded in the configuration of the local
      device so operators are aware of the full policy implemented in
      the network from the running configuration.
It is not clear to me if your requirement is that dynamic protocols should impose persistent policies? It says it should be recorded in the configuration of the local device.

I agree that those policies should be visible to operators and other applications, but not sure if dynamic protocols should be allowed to implement persistent policies. IMO, those should be ephemeral policies.
So maybe text should look like this
This interaction should be through existing configuration mechanisms, such as NETCONF, and should be recorded in the running or ephemeral configuration of the local device so operators are aware of the full policy implemented in the network from the running configuration.

I'm trying to see major difference between REQ01/REQ02 and REQ08/REQ09?

In general I'm not sure if changing entries by dynamic protocol in RIB is a good idea. If you plan to change only what is configured on the local device, then that is OK, but if you start changing entries that are pushed from other devices in the network, the system would get unstable. And it looks to me that REQ09 would allow that.

Dean

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 6 Jun 2014 16:57:20 -0400

Dean:

Thank you for the complete review of version 3.   Great review! 

On readability, Jeff Haas suggest putting all the requirements in the front.
Would that make it better?  It's an easy switch (other than listening to
Jeff say "I told you so").   On configuration persistence, you are correct.
My understanding of the feedback from the WG had been write from I2RS
datastore to configuration datastore.  I will go back and review the posts
from the WG and check with co-authors dynamic memory.  If the intent is
empheral store, then we can use a variant of your text. 

On REQ01/02 - (01) Read/write access  versus  (02) notification and REQ08/09
- (08) Write versus (09) read/notify status --- I agree these could be
combined if the WG desires or split on read/write versus notification. Do
you have any preference? 

On the danger of inserting flow specifications, you are right. However, see
IDR's discussion flow specification for choices.  IDRs argues advanced
features are like a rope, chair and whip - one can either hang oneself or
tame a lion.  

Sue 

-----Original Message-----
From: Dean Bogdanovic [mailto:[email-masked]] 
Sent: Friday, June 06, 2014 4:03 PM
To: Susan Hares
Cc: t.petch; <[email-masked]>; Keyur Patel (keyupate); Hannes Gredler; Russ
White; Susan Hares; <[email-masked]>
Subject: Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt

Susan,

Many people don't know what NLRI abbreviation stands for (Network Layer
Reachability Information , so writing it out first time would be a good
idea. 

Throughout the text, the requirement number sequence is confusing until you
get to the very and where all requirements are listed and then it makes
sense.

REQ04: The ability to interact with various policies configured on
      the forwarding devices, in order to inform the policies
      implemented by the dynamic routing processes.  This interaction
      should be through existing configuration mechanisms, such as
      NETCONF, and should be recorded in the configuration of the local
      device so operators are aware of the full policy implemented in
      the network from the running configuration.
It is not clear to me if your requirement is that dynamic protocols should
impose persistent policies? It says it should be recorded in the
configuration of the local device.

I agree that those policies should be visible to operators and other
applications, but not sure if dynamic protocols should be allowed to
implement persistent policies. IMO, those should be ephemeral policies.
So maybe text should look like this
This interaction should be through existing configuration mechanisms, such
as NETCONF, and should be recorded in the running or ephemeral configuration
of the local device so operators are aware of the full policy implemented in
the network from the running configuration.

In general I'm not sure if changing entries by dynamic protocol in RIB is a
good idea. If you plan to change only what is configured on the local
device, then that is OK, but if you start changing entries that are pushed
from other devices in the network, the system would get unstable. And it
looks to me that REQ09 would allow that.

Dean

On Jun 5, 2014, at 4:47 AM, Susan Hares <[email-masked]> wrote:

> Cc: 'Keyur Patel (keyupate)'; Hannes Gredler; Russ White; 'Susan 
> Hares'; [email-masked]
> I like to have one or two names, no more, as the clear pen holders 
> whom I can expect to act.  Too often, with so many names, everyone 
> thinks that someone else will do something and nothing happens, so, in 
> all seriousness, I oppose adoption until you sort this out amongst
yourselves.
> this can be surprising difficult to get round but get round it you, 
> one or more thereof, must.
> 
> Tom Petch
> 
>

---

From: Dean Bogdanovic <[email-masked]>
Date: Sat, 7 Jun 2014 01:50:50 +0000

On Jun 6, 2014, at 4:57 PM, Susan Hares <[email-masked]> wrote:

> Jeff say "I told you so").   
I don't like giving Jeff opportunity to use that sentence, but I'm in agreement with Jeff. Putting the requirement list upfront makes more sense and then you don't have to repeat the whole requirement, you can just list it.

> On configuration persistence, you are correct.
OK
> combined if the WG desires or split on read/write versus notification. Do
My preference would be read/notify and write. The reason is that read/notify are used for operational and analytic purposes and write is an action based on operational and analytical result.

> features are like a rope, chair and whip - one can either hang oneself or
or be mauled by the lion. I've seen so many times by giving the tools to the people, they shot themselves into the foot, so am careful about it. Just talking from experience.

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 10 Jun 2014 14:19:25 -0400

> I don't like giving Jeff opportunity to use that sentence, but I'm in agreement with Jeff. Putting the requirement list upfront makes more sense and then you don't have to repeat the whole requirem…

Married life has taught me that "I told you so" is something better to think
than ever say. :-)

As mentioned elsewhere on-list by me, I think we'll probably end up
summarizing the various requirements to the wiki before we're done.  As long
as they're centralized in the document, I'm not highly concerned about where
they live in that document as long as it contributes to easy reading.

> My preference would be read/notify and write. The reason is that read/notify are used for operational and analytic purposes and write is an action based on operational and analytical result.

A model that may be worth considering is the MIN-ACCESS/MAX-ACCESS form used
by SNMP.  In particular, this lets you distinguish between contents that may
be retrieved (read*) vs. only delivered in notifications
(accessible-for-notify).

-- Jeff

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 11 Jun 2014 21:08:22 -0400

Dean: 

I combined REQ01/02 and REQ08/09.  I've put the requirements in the front of
the text.  Please let know if have any suggestions on these approved
changes.  I wait 24 hours, and then spin the draft. 

On the agreement on REQ04, I cannot find a firm consensus.  I would ask Jeff
Haas or Ed Crabbe to indicate if they think there is a consensus on the WG.
I highlight a few messages below. The document is proposed for WG consensus
so I will change it if the WG has consensus. 

Sue Hares 

Search for Consensus 

=====

Based on your comment, I sent looking for WG Direction regarding BGP or I2RS
putting state.   I cannot find it.  BGP has a Flow specification (RFC5575).
Where do you think those flow specifications end up?  Writing into runtime
configuration state? Writing into something like I2RS running data store?
BGP ORFs might be kept in the BGP state or in associated features
(Add/delete) in BGP, but Flow specifications are targeted toward data flow. 

On the list I could find the following: 

1. I2RS BGP state to configuration - Wes George (operator) makes a comment
that I2RS configuration should not replace current configuration related to
BGP.  

http://www.ietf.org/mail-archive/web/i2rs/current/msg00826.html

2. There is the Architecture Discussion 2: Persistence (ephemeral vs.
permanent) - is the debate for the architecture document regarding keeping
state in the I2RS 

Begin:  

http://www.ietf.org/mail-archive/web/i2rs/current/msg01027.html

Joel's: no state across a reboot:  

http://www.ietf.org/mail-archive/web/i2rs/current/msg01034.html

3. Wes George (operator) makes a comment that I2RS configuration should not
replace current configuration related to BGP.  

http://www.ietf.org/mail-archive/web/i2rs/current/msg00826.html

There is the Architecture Discussion 2: Persistence (ephemeral vs.
permanent)

http://www.ietf.org/mail-archive/web/i2rs/current/msg01027.html

Multiple clients writing to agents (raised by Himanshu Shah) 

http://www.ietf.org/mail-archive/web/i2rs/current/msg01139.html

Jeff (chair hat off) states he does not want to have I2rs changing state
tables come from routing protocols (BGP--> I2RS state).  He also feel
dynamic state tables should be read-only, and not writable as suggested by
the use case. 

http://www.ietf.org/mail-archive/web/i2rs/current/msg01666.html

In the same thread, Sri states the I2RS agent should not provide an
interface to change a table if there is no use-case to support it.  Dynamic
protocols --> I2RS (I2RS read only).  I2RS--> RIB-IM.   Sri states " I am
yet to see a use-case that requires direct manipulation of a single dynamic
routing-protocol-instance specific route table by something other than that
protocol. I don't believe there should be any such case."    However, here
it has been in the BGP use case. 

http://www.ietf.org/mail-archive/web/i2rs/current/msg01671.html

Jeff responds to Sri in tends to agree and does not mention the use case. 

http://www.ietf.org/mail-archive/web/i2rs/current/msg01752.html

Sue Hares 

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

To: Susan Hares

Susan,

Dean

> Subject: Re: [i2rs] FW: I-D Action: 

> draft-keyupate-i2rs-bgp-usecases-02.txt

yourselves.

> Subject: [i2rs] FW: I-D Action: 

> draft-keyupate-i2rs-bgp-usecases-02.txt

>> This updated draft has all the changes that Keyur Patel promised and

> updates

>> This draft is a work item of the Interface to the Routing System

> Working

>>   operation encompass: configuration of protocol parameters, display

> of

>>   protocol data, setting of certain protocol state and debugging of

> the

>>   Interface to the Routing System's (I2RS) Programmatic interfaces,

> as

>>   defined in draft-ietf-i2rs-architecture, provides an alternate way

> to

>>   control and diagnose the operation of the BGP protocol.  I2RS may

> be

>>   used for the configuration, manipulation, analyzing or collecting

> the

>>   I2RS can be used for BGP protocol.  It is intended to provide a

> base

>> Please note that it may take a couple of minutes from the time of

> submission

---

From: Dean Bogdanovic <[email-masked]>
Date: Fri, 13 Jun 2014 18:44:03 +0000

Susan,

Sorry for late reply, but yesterday started a very significant quadrennial event (FIFA World Cup) and Croatia played (and lost with help of the referee).

WRT REQ04, I agree with the posts and here are few thoughts on this

We should try to divide policies into few categories.

1. persistent
There is a set of policies that have to be available from very start on the device. Those policies should be persistent on the device and I see them changing infrequently. IMO, there is no need for I2RS to manage those policies, readonly access is sufficient.
2. transient
Policies that are temporary defining some fwd behavior of device. I can see lot of cases where different applications based on some network conditions want to change forwarding behavior. Those should not be available after reboot.
3. locally defined
by this I mean policies that defined by admin, applications through local I2RS agent. These can be transient and persistent, where I would classify that I2RS agent policies are only transient. Actually after rereading this, I would even consider policies defined by I2RS as remotely defined and therefore transient.
4. remotely defined
by this I mean policies pushed from a different device (policy server, router) via some protocol (DIAMETER, RADIUS, BGP). IMO, those should be always ephemeral.

Dean

On Jun 11, 2014, at 9:08 PM, Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:

Dean:

I combined REQ01/02 and REQ08/09.  I've put the requirements in the front of the text.  Please let know if have any suggestions on these approved changes.  I wait 24 hours, and then spin the draft.

On the agreement on REQ04, I cannot find a firm consensus.  I would ask Jeff Haas or Ed Crabbe to indicate if they think there is a consensus on the WG. I highlight a few messages below. The document is proposed for WG consensus so I will change it if the WG has consensus.

Sue Hares

Search for Consensus
=====
Based on your comment, I sent looking for WG Direction regarding BGP or I2RS putting state.   I cannot find it.  BGP has a Flow specification (RFC5575).  Where do you think those flow specifications end up?  Writing into runtime configuration state? Writing into something like I2RS running data store?  BGP ORFs might be kept in the BGP state or in associated features (Add/delete) in BGP, but Flow specifications are targeted toward data flow.

1. I2RS BGP state to configuration - Wes George (operator) makes a comment that I2RS configuration should not replace current configuration related to BGP.

2. There is the Architecture Discussion 2: Persistence (ephemeral vs. permanent) - is the debate for the architecture document regarding keeping state in the I2RS
Begin:
http://www.ietf.org/mail-archive/web/i2rs/current/msg01027.html

3. Wes George (operator) makes a comment that I2RS configuration should not replace current configuration related to BGP.
http://www.ietf.org/mail-archive/web/i2rs/current/msg00826.html

There is the Architecture Discussion 2: Persistence (ephemeral vs. permanent)
http://www.ietf.org/mail-archive/web/i2rs/current/msg01027.html

Jeff (chair hat off) states he does not want to have I2rs changing state tables come from routing protocols (BGP--> I2RS state).  He also feel dynamic state tables should be read-only, and not writable as suggested by the use case.
http://www.ietf.org/mail-archive/web/i2rs/current/msg01666.html

In the same thread, Sri states the I2RS agent should not provide an interface to change a table if there is no use-case to support it.  Dynamic protocols --> I2RS (I2RS read only).  I2RS--> RIB-IM.   Sri states " I am yet to see a use-case that requires direct manipulation of a single dynamic routing-protocol-instance specific route table by something other than that protocol. I don't believe there should be any such case."    However, here it has been in the BGP use case.
http://www.ietf.org/mail-archive/web/i2rs/current/msg01671.html

Sue Hares

-----Original Message-----
From: Dean Bogdanovic [mailto:[email-masked]<http://juniper.net>]
Sent: Friday, June 06, 2014 4:03 PM
To: Susan Hares
Cc: t.petch; <[email-masked]<mailto:[email-masked]>>; Keyur Patel (keyupate); Hannes Gredler; Russ White; Susan Hares; <[email-masked]<mailto:[email-masked]>>
Subject: Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt

Susan,

Dean

On Jun 5, 2014, at 4:47 AM, Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:

> From: t.petch [mailto:[email-masked]<http://btconnect.com>]
> To: Susan Hares; [email-masked]<mailto:[email-masked]>
> Hares'; [email-masked]<mailto:[email-masked]>
> all seriousness, I oppose adoption until you sort this out amongst yourselves.
>
> From: "Susan Hares" <[email-masked]<mailto:[email-masked]>>
> To: <[email-masked]<mailto:[email-masked]>>
> Cc: "'Keyur Patel (keyupate)'" <[email-masked]<mailto:[email-masked]>>; "Hannes Gredler"
> <[email-masked]<mailto:[email-masked]>>; "Russ White" <[email-masked]<mailto:[email-masked]>>; "'Susan Hares'"
> <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>>
>> From: i2rs [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
>> [email-masked]<mailto:[email-masked]>
>> To: [email-masked]<mailto:[email-masked]>
>> Cc: [email-masked]<mailto:[email-masked]>
>> until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
>>
>> [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

<draft-keyupate-i2rs-bgp-usecases-03.txt><draft-keyupate-i2rs-bgp-usecases-03.txt.pdf>

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 13 Jun 2014 17:49:35 -0400

Dean:

Thank you for your thoughtful answer.  I was looking for it, but I'm glad
you watched Croatia (I'm sorry about Croatia's loss). 

I agree with the types of policies and the status: persistent, transient,
and ephemeral.  However, do we ever let I2RS upon a command transfer
policies to the persistent storage?  This what I read in REQ04.    In
reading the email, I'm not sure how to summarize the WG's approach.  My
answer would be "no", but if this is a WG document the answer needs to come
from the WG.

Sue 

From: i2rs [mailto:[email-masked]] On Behalf Of Dean Bogdanovic
Sent: Friday, June 13, 2014 2:44 PM
To: Susan Hares
Cc: <[email-masked]>; Susan Hares; <[email-masked]>; t.petch; Keyur Patel
(keyupate); Hannes Gredler; Russ White
Subject: Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt

Susan, 

Sorry for late reply, but yesterday started a very significant quadrennial
event (FIFA World Cup) and Croatia played (and lost with help of the
referee).

1. persistent

There is a set of policies that have to be available from very start on the
device. Those policies should be persistent on the device and I see them
changing infrequently. IMO, there is no need for I2RS to manage those
policies, readonly access is sufficient.

2. transient

Policies that are temporary defining some fwd behavior of device. I can see
lot of cases where different applications based on some network conditions
want to change forwarding behavior. Those should not be available after
reboot. 

3. locally defined

by this I mean policies that defined by admin, applications through local
I2RS agent. These can be transient and persistent, where I would classify
that I2RS agent policies are only transient. Actually after rereading this,
I would even consider policies defined by I2RS as remotely defined and
therefore transient.

4. remotely defined

by this I mean policies pushed from a different device (policy server,
router) via some protocol (DIAMETER, RADIUS, BGP). IMO, those should be
always ephemeral.

Dean

On Jun 11, 2014, at 9:08 PM, Susan Hares <[email-masked]> wrote:

Dean:

 

Sue Hares

Search for Consensus

=====

 <http://www.ietf.org/mail-archive/web/i2rs/current/msg00826.html>
http://www.ietf.org/mail-archive/web/i2rs/current/msg00826.html

Begin: 

 <http://www.ietf.org/mail-archive/web/i2rs/current/msg01027.html>
http://www.ietf.org/mail-archive/web/i2rs/current/msg01027.html

 <http://www.ietf.org/mail-archive/web/i2rs/current/msg01034.html>
http://www.ietf.org/mail-archive/web/i2rs/current/msg01034.html

 <http://www.ietf.org/mail-archive/web/i2rs/current/msg00826.html>
http://www.ietf.org/mail-archive/web/i2rs/current/msg00826.html

 <http://www.ietf.org/mail-archive/web/i2rs/current/msg01027.html>
http://www.ietf.org/mail-archive/web/i2rs/current/msg01027.html

 <http://www.ietf.org/mail-archive/web/i2rs/current/msg01139.html>
http://www.ietf.org/mail-archive/web/i2rs/current/msg01139.html

 <http://www.ietf.org/mail-archive/web/i2rs/current/msg01666.html>
http://www.ietf.org/mail-archive/web/i2rs/current/msg01666.html

 <http://www.ietf.org/mail-archive/web/i2rs/current/msg01671.html>
http://www.ietf.org/mail-archive/web/i2rs/current/msg01671.html

 <http://www.ietf.org/mail-archive/web/i2rs/current/msg01752.html>
http://www.ietf.org/mail-archive/web/i2rs/current/msg01752.html

Sue Hares

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

From: Dean Bogdanovic [mailto:deanb@ <http://juniper.net> juniper.net]

To: Susan Hares

Cc: t.petch; <[email-masked]>; Keyur Patel (keyupate); Hannes Gredler; Russ
White; Susan Hares; < <mailto:[email-masked]> [email-masked]>

Susan,

Dean

> From: t.petch [mailto:ietfc@ <http://btconnect.com> btconnect.com]

> Hares';  <mailto:[email-masked]> [email-masked]

yourselves.

> From: "Susan Hares" < <mailto:[email-masked]> [email-masked]>

> Cc: "'Keyur Patel (keyupate)'" < <mailto:[email-masked]>
[email-masked]>; "Hannes Gredler"

> < <mailto:[email-masked]> [email-masked]>; "Russ White" <
<mailto:[email-masked]> [email-masked]>; "'Susan Hares'"

> < <mailto:[email-masked]> [email-masked]>; < <mailto:[email-masked]>
[email-masked]>

>> From: i2rs [mailto:i2rs- <mailto:[email-masked]> [email-masked]] On
Behalf Of

>>  <mailto:[email-masked]> [email-masked]

>> To:  <mailto:[email-masked]> [email-masked]

>>  <https://datatracker.ietf.org/doc/draft-keyupate-i2rs-bgp-usecases/>

>>  <http://tools.ietf.org/html/draft-keyupate-i2rs-bgp-usecases-02>

>>  <http://www.ietf.org/rfcdiff?url2=draft-keyupate-i2rs-bgp-usecases-02>

>> until the htmlized version and diff are available at
<http://tools.ietf.org> tools.ietf.org.

>>  <ftp://ftp.ietf.org/internet-drafts/>

>>  <https://www.ietf.org/mailman/listinfo/i2rs>

>>  <https://www.ietf.org/mailman/listinfo/i2rs>

>  <https://www.ietf.org/mailman/listinfo/i2rs>

<draft-keyupate-i2rs-bgp-usecases-03.txt><draft-keyupate-i2rs-bgp-usecases-0
3.txt.pdf>

---

From: Dean Bogdanovic <[email-masked]>
Date: Fri, 13 Jun 2014 22:06:31 +0000

Susan,

My answer  to your question
do we ever let I2RS upon a command transfer policies to the persistent storage?

My initial answer is no. And reason is security. Network admins want to know exact state of the device after rebooting. If we want to allow transfer of policies, then we would have to define roles and which roles would be allowed to do that transfer. We are making things more complex, when there are existing mechanisms for admins to do that.

Dean

On Jun 13, 2014, at 5:49 PM, Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:

Dean:
Thank you for your thoughtful answer.  I was looking for it, but I’m glad you watched Croatia (I’m sorry about Croatia’s loss).

I agree with the types of policies and the status: persistent, transient, and ephemeral.  However, do we ever let I2RS upon a command transfer policies to the persistent storage?  This what I read in REQ04.    In reading the email, I’m not sure how to summarize the WG’s approach.  My answer would be “no”, but if this is a WG document the answer needs to come from the WG.

Sue

From: i2rs [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Dean Bogdanovic
Sent: Friday, June 13, 2014 2:44 PM
To: Susan Hares
Cc: <[email-masked]<mailto:[email-masked]>>; Susan Hares; <[email-masked]<mailto:[email-masked]>>; t.petch; Keyur Patel (keyupate); Hannes Gredler; Russ White
Subject: Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt

Susan,

1. persistent

Dean

Dean:

Sue Hares

Search for Consensus
=====

Sue Hares

-----Original Message-----
From: Dean Bogdanovic [mailto:[email-masked]<http://juniper.net>]
Sent: Friday, June 06, 2014 4:03 PM
To: Susan Hares
Cc: t.petch; <[email-masked]<mailto:[email-masked]>>; Keyur Patel (keyupate); Hannes Gredler; Russ White; Susan Hares; <[email-masked]<mailto:[email-masked]>>
Subject: Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt

Susan,

Dean

---

From: t.petch <[email-masked]>
Date: Tue, 17 Jun 2014 10:35:46 +0100

----- Original Message -----
From: "Dean Bogdanovic" <[email-masked]>
To: "Susan Hares" <[email-masked]>
Sent: Friday, June 13, 2014 11:06 PM

Susan,

My answer  to your question
do we ever let I2RS upon a command transfer policies to the persistent
storage?

My initial answer is no. And reason is security. Network admins want to
know exact state of the device after rebooting. If we want to allow
transfer of policies, then we would have to define roles and which roles
would be allowed to do that transfer. We are making things more complex,
when there are existing mechanisms for admins to do that.

<tp>
The counter argument to this is having got it right once, for some,
perhaps large, instantiation of an I2RS it, do you want to have to do it
all over again?

That is, I agree that after reboot, an operator should know that the box
is in the state defined by the NETCONF startup configuration datastore
with nothing added but that there may be a valid case for saying that
all the changes downloaded by I2RS remain stored, but not applied, eg in
a candidate I2RS datastore, which can then be copied to the running I2RS
datastore when the operator is satisfied that the time is right.

Just a thought.

Tom Petch

Dean

On Jun 13, 2014, at 5:49 PM, Susan Hares
<[email-masked]<mailto:[email-masked]>> wrote:

Dean:
Thank you for your thoughtful answer.  I was looking for it, but I’m
glad you watched Croatia (I’m sorry about Croatia’s loss).

I agree with the types of policies and the status: persistent,
transient, and ephemeral.  However, do we ever let I2RS upon a command
transfer policies to the persistent storage?  This what I read in REQ04.
In reading the email, I’m not sure how to summarize the WG’s approach.
My answer would be “no”, but if this is a WG document the answer needs
to come from the WG.

Sue

From: i2rs [mailto:[email-masked]<mailto:[email-masked]>] On
Behalf Of Dean Bogdanovic
Sent: Friday, June 13, 2014 2:44 PM
To: Susan Hares
Cc: <[email-masked]<mailto:[email-masked]>>; Susan Hares;
<[email-masked]<mailto:[email-masked]>>; t.petch; Keyur Patel (keyupate);
Hannes Gredler; Russ White
Subject: Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt

Susan,

Sorry for late reply, but yesterday started a very significant
quadrennial event (FIFA World Cup) and Croatia played (and lost with
help of the referee).

1. persistent
There is a set of policies that have to be available from very start on
the device. Those policies should be persistent on the device and I see
them changing infrequently. IMO, there is no need for I2RS to manage
those policies, readonly access is sufficient.
2. transient
Policies that are temporary defining some fwd behavior of device. I can
see lot of cases where different applications based on some network
conditions want to change forwarding behavior. Those should not be
available after reboot.
3. locally defined
by this I mean policies that defined by admin, applications through
local I2RS agent. These can be transient and persistent, where I would
classify that I2RS agent policies are only transient. Actually after
rereading this, I would even consider policies defined by I2RS as
remotely defined and therefore transient.
4. remotely defined
by this I mean policies pushed from a different device (policy server,
router) via some protocol (DIAMETER, RADIUS, BGP). IMO, those should be
always ephemeral.

Dean

On Jun 11, 2014, at 9:08 PM, Susan Hares
<[email-masked]<mailto:[email-masked]>> wrote:

Dean:

I combined REQ01/02 and REQ08/09.  I've put the requirements in the
front of the text.  Please let know if have any suggestions on these
approved changes.  I wait 24 hours, and then spin the draft.

On the agreement on REQ04, I cannot find a firm consensus.  I would ask
Jeff Haas or Ed Crabbe to indicate if they think there is a consensus on
the WG. I highlight a few messages below. The document is proposed for
WG consensus so I will change it if the WG has consensus.

Sue Hares

Search for Consensus
=====
Based on your comment, I sent looking for WG Direction regarding BGP or
I2RS putting state.   I cannot find it.  BGP has a Flow specification
(RFC5575).  Where do you think those flow specifications end up?
Writing into runtime configuration state? Writing into something like
I2RS running data store?  BGP ORFs might be kept in the BGP state or in
associated features (Add/delete) in BGP, but Flow specifications are
targeted toward data flow.

1. I2RS BGP state to configuration - Wes George (operator) makes a
comment that I2RS configuration should not replace current configuration
related to BGP.

2. There is the Architecture Discussion 2: Persistence (ephemeral vs.
permanent) - is the debate for the architecture document regarding
keeping state in the I2RS
Begin:
http://www.ietf.org/mail-archive/web/i2rs/current/msg01027.html

3. Wes George (operator) makes a comment that I2RS configuration should
not replace current configuration related to BGP.
http://www.ietf.org/mail-archive/web/i2rs/current/msg00826.html

Jeff (chair hat off) states he does not want to have I2rs changing state
tables come from routing protocols (BGP--> I2RS state).  He also feel
dynamic state tables should be read-only, and not writable as suggested
by the use case.
http://www.ietf.org/mail-archive/web/i2rs/current/msg01666.html

In the same thread, Sri states the I2RS agent should not provide an
interface to change a table if there is no use-case to support it.
Dynamic protocols --> I2RS (I2RS read only).  I2RS--> RIB-IM.   Sri
states " I am yet to see a use-case that requires direct manipulation of
a single dynamic routing-protocol-instance specific route table by
something other than that protocol. I don't believe there should be any
such case."    However, here it has been in the BGP use case.
http://www.ietf.org/mail-archive/web/i2rs/current/msg01671.html

Jeff responds to Sri in tends to agree and does not mention the use
case.
http://www.ietf.org/mail-archive/web/i2rs/current/msg01752.html

Sue Hares

-----Original Message-----
From: Dean Bogdanovic [mailto:[email-masked]<http://juniper.net>]
Sent: Friday, June 06, 2014 4:03 PM
To: Susan Hares
Cc: t.petch; <[email-masked]<mailto:[email-masked]>>; Keyur Patel
(keyupate); Hannes Gredler; Russ White; Susan Hares;
<[email-masked]<mailto:[email-masked]>>
Subject: Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt

Susan,

Throughout the text, the requirement number sequence is confusing until
you get to the very and where all requirements are listed and then it
makes sense.

It is not clear to me if your requirement is that dynamic protocols
should impose persistent policies? It says it should be recorded in the

I agree that those policies should be visible to operators and other
applications, but not sure if dynamic protocols should be allowed to
implement persistent policies. IMO, those should be ephemeral policies.
So maybe text should look like this
This interaction should be through existing configuration mechanisms,
such as NETCONF, and should be recorded in the running or ephemeral
configuration of the local device so operators are aware of the full
policy implemented in the network from the running configuration.

In general I'm not sure if changing entries by dynamic protocol in RIB
is a good idea. If you plan to change only what is configured on the
local device, then that is OK, but if you start changing entries that
are pushed from other devices in the network, the system would get
unstable. And it looks to me that REQ09 would allow that.

Dean

yourselves.
> Cc: "'Keyur Patel (keyupate)'"
<[email-masked]<mailto:[email-masked]>>; "Hannes Gredler"
> <[email-masked]<mailto:[email-masked]>>; "Russ White"
<[email-masked]<mailto:[email-masked]>>; "'Susan Hares'"
>> until the htmlized version and diff are available at
tools.ietf.org<http://tools.ietf.org>.
>> ftp://ftp.ietf.org/internet-drafts/

<draft-keyupate-i2rs-bgp-usecases-03.txt><draft-keyupate-i2rs-bgp-usecas
es-03.txt.pdf>

---

From: Dean Bogdanovic <[email-masked]>
Date: Tue, 17 Jun 2014 13:25:31 +0000

> perhaps large, instantiation of an I2RS it, do you want to have to do it
why not? Isn't the point of automation to be able to reliably repeat actions over and over again?
> datastore when the operator is satisfied that the time is right.
I don't want to have multiple data stores in I2RS. I have recommended RESTCONF for I2RS and one of the main reasons for that was single data store, which makes config management very easy, as there is only one config.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 17 Jun 2014 12:14:21 -0400

I REALLY do not want I2RS getting into writing persistent storage.  It 
creates many complications in implementing I2RS and in maintaining 
system state.  it also interacts interestingly with configuration 
maintenance.  (Yes, I2RS itself itneracts interestingly there, but at 
least that does not affect the reboot state.)

Yours,
Joel

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 17 Jun 2014 13:16:41 -0400

Joel, Tom and Dean: 

I've released draft-keyupate-i2rs-bgp-usecases-03.txt as an updated, but it
does not any fixes to the requirements that you-all and Lada suggested.
Since we are commenting on text that is not online, I've updated the online
text. My very high level summary of the issues are: 

1) Use cases have specified write between I2RS and configuration store; and
this should be removed from the next version of
draft-keyupate-i2rs-bgp-usecases-03.txt

2) The requirements as specified in draft-keyupate-i2rs-bgp-usecases-03.txt
overlap. 

Although I think we all agree on #1, I will start a separate mail topic on
each of these questions. 

Thank you for all your comments, 

Sue Hares 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Tuesday, June 17, 2014 12:14 PM
To: t.petch; Dean Bogdanovic; Susan Hares
Cc: [email-masked]; Susan Hares; [email-masked]; Keyur Patel (keyupate);

I REALLY do not want I2RS getting into writing persistent storage.  It
creates many complications in implementing I2RS and in maintaining system
state.  it also interacts interestingly with configuration maintenance.
(Yes, I2RS itself itneracts interestingly there, but at least that does not
affect the reboot state.)

Yours,

Joel

> From: "Dean Bogdanovic" < <mailto:[email-masked]> [email-masked]>

> To: "Susan Hares" < <mailto:[email-masked]> [email-masked]>

> My initial answer is no. And reason is security. Network admins want 

> to know exact state of the device after rebooting. If we want to allow 

> transfer of policies, then we would have to define roles and which 

> roles would be allowed to do that transfer. We are making things more 

> complex, when there are existing mechanisms for admins to do that.

> perhaps large, instantiation of an I2RS it, do you want to have to do 

> it all over again?

> That is, I agree that after reboot, an operator should know that the 

> box is in the state defined by the NETCONF startup configuration 

> datastore with nothing added but that there may be a valid case for 

> saying that all the changes downloaded by I2RS remain stored, but not 

> applied, eg in a candidate I2RS datastore, which can then be copied to 

> the running I2RS datastore when the operator is satisfied that the time is
right.

> < <mailto:[email-masked]%3cmailto:[email-masked]>
[email-masked]<mailto:[email-masked]>> wrote:

> Thank you for your thoughtful answer.  I was looking for it, but I'm 

> glad you watched Croatia (I'm sorry about Croatia's loss).

> In reading the email, I'm not sure how to summarize the WG's approach.

> My answer would be "no", but if this is a WG document the answer needs 

> From: i2rs [ <mailto:[email-masked]%3cmailto:[email-masked]%3e>
mailto:[email-masked]<mailto:[email-masked]>] On 

> Cc: < <mailto:[email-masked]%3cmailto:[email-masked]>
[email-masked]<mailto:[email-masked]>>; Susan Hares; 

> < <mailto:[email-masked]%3cmailto:[email-masked]>
[email-masked]<mailto:[email-masked]>>; t.petch; Keyur Patel 

> Subject: Re: [i2rs] I-D Action: 

> There is a set of policies that have to be available from very start 

> on the device. Those policies should be persistent on the device and I 

> see them changing infrequently. IMO, there is no need for I2RS to 

> manage those policies, readonly access is sufficient.

> Policies that are temporary defining some fwd behavior of device. I 

> can see lot of cases where different applications based on some 

> network conditions want to change forwarding behavior. Those should 

> not be available after reboot.

> router) via some protocol (DIAMETER, RADIUS, BGP). IMO, those should 

> be always ephemeral.

> < <mailto:[email-masked]%3cmailto:[email-masked]>
[email-masked]<mailto:[email-masked]>> wrote:

> On the agreement on REQ04, I cannot find a firm consensus.  I would 

> ask Jeff Haas or Ed Crabbe to indicate if they think there is a 

> consensus on the WG. I highlight a few messages below. The document is 

> proposed for WG consensus so I will change it if the WG has consensus.

> I2RS running data store?  BGP ORFs might be kept in the BGP state or 

> in associated features (Add/delete) in BGP, but Flow specifications 

> are targeted toward data flow.

> comment that I2RS configuration should not replace current 

> configuration related to BGP.

> 3. Wes George (operator) makes a comment that I2RS configuration 

> should not replace current configuration related to BGP.

> Jeff (chair hat off) states he does not want to have I2rs changing 

> state tables come from routing protocols (BGP--> I2RS state).  He also 

> feel dynamic state tables should be read-only, and not writable as 

> suggested by the use case.

> states " I am yet to see a use-case that requires direct manipulation 

> of a single dynamic routing-protocol-instance specific route table by 

> From: Dean Bogdanovic [ <mailto:[email-masked]%3chttp://juniper.net%3e>
mailto:[email-masked]<http://juniper.net>]

> Cc: t.petch; < <mailto:[email-masked]%3cmailto:[email-masked]>
[email-masked]<mailto:[email-masked]>>; Keyur Patel 

> < <mailto:[email-masked]%3cmailto:[email-masked]>
[email-masked]<mailto:[email-masked]>>

> Subject: Re: [i2rs] I-D Action: 

> Many people don't know what NLRI abbreviation stands for (Network 

> Layer Reachability Information , so writing it out first time would be 

> a good idea.

> Throughout the text, the requirement number sequence is confusing 

> until you get to the very and where all requirements are listed and 

> then it makes sense.

> should impose persistent policies? It says it should be recorded in 

> the configuration of the local device.

> < <mailto:[email-masked]%3cmailto:[email-masked]>
[email-masked]<mailto:[email-masked]>> wrote:

>> I'm glad to change the citation in the abstract.    On the authors,

> this was

>> From: t.petch [ <mailto:[email-masked]%3chttp://btconnect.com%3e>
mailto:[email-masked]<http://btconnect.com>]

>> To: Susan Hares;  <mailto:[email-masked]%3cmailto:[email-masked]>

>> Hares';  <mailto:[email-masked]%3cmailto:[email-masked]>
[email-masked]<mailto:[email-masked]>

>> Currently you have six authors which is too many for an RFC -

> someone's

>> got to go!   For me, this is not just an admin point - when

> commenting,

>> thinks that someone else will do something and nothing happens, so, 

>> in all seriousness, I oppose adoption until you sort this out amongst

>> Note too that you have a citation in the Abstract, again not allowed 

>> - this can be surprising difficult to get round but get round it you, 

>> From: "Susan Hares" < <mailto:[email-masked]%3cmailto:[email-masked]>
[email-masked]<mailto:[email-masked]>>

>> To: < <mailto:[email-masked]%3cmailto:[email-masked]>
[email-masked]<mailto:[email-masked]>>

> < <mailto:[email-masked]%3cmailto:[email-masked]>
[email-masked]<mailto:[email-masked]>>; "Hannes Gredler"

>> < <mailto:[email-masked]%3cmailto:[email-masked]>
[email-masked]<mailto:[email-masked]>>; "Russ White"

> < <mailto:[email-masked]%3cmailto:[email-masked]>
[email-masked]<mailto:[email-masked]>>; "'Susan Hares'"

>> < <mailto:[email-masked]%3cmailto:[email-masked]>
[email-masked]<mailto:[email-masked]>>;

> < <mailto:[email-masked]%3cmailto:[email-masked]>
[email-masked]<mailto:[email-masked]>>

>>> From: i2rs [ <mailto:[email-masked]%3cmailto:[email-masked]%3e>
mailto:[email-masked]<mailto:[email-masked]>] 

>>> On

>>>  <mailto:[email-masked]%3cmailto:[email-masked]>

>>> To:  <mailto:[email-masked]%3cmailto:[email-masked]>
[email-masked]<mailto:[email-masked]>

>>> Cc:  <mailto:[email-masked]%3cmailto:[email-masked]>

>>>    operation encompass: configuration of protocol parameters, 

>>> display

>>>    defined in draft-ietf-i2rs-architecture, provides an alternate 

>>> way

> tools.ietf.org< <http://tools.ietf.org> http://tools.ietf.org>.

>>>  <mailto:[email-masked]%3cmailto:[email-masked]>

>>>  <mailto:[email-masked]%3cmailto:[email-masked]>

>>  <mailto:[email-masked]%3cmailto:[email-masked]>

> <draft-keyupate-i2rs-bgp-usecases-03.txt><draft-keyupate-i2rs-bgp-usec

>  <mailto:[email-masked]> [email-masked]

i2rs mailing list

 <mailto:[email-masked]> [email-masked]