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

[Dean Bogdanovic <[e-mail]>]

On Jun 17, 2014, at 5:35 AM, t.petch <[e-mail]> wrote:

> ----- Original Message -----
> From: "Dean Bogdanovic" <[e-mail]>
> To: "Susan Hares" <[e-mail]>
> 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?
why not? Isn't the point of automation to be able to reliably repeat actions over and 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.
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.
> 
> Just a thought.
> 
> Tom Petch
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Dean
> 
> On Jun 13, 2014, at 5:49 PM, Susan Hares
> <[e-mail]<mailto:[e-mail]>> 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:[e-mail]<mailto:[e-mail]>] On
> Behalf Of Dean Bogdanovic
> Sent: Friday, June 13, 2014 2:44 PM
> To: Susan Hares
> Cc: <[e-mail]<mailto:[e-mail]>>; Susan Hares;
> <[e-mail]<mailto:[e-mail]>>; 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).
> 
> 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
> <[e-mail]<mailto:[e-mail]>> 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.
> 
> 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-----
> From: Dean Bogdanovic [mailto:[e-mail]<http://juniper.net>]
> Sent: Friday, June 06, 2014 4:03 PM
> To: Susan Hares
> Cc: t.petch; <[e-mail]<mailto:[e-mail]>>; Keyur Patel
> (keyupate); Hannes Gredler; Russ White; Susan Hares;
> <[e-mail]<mailto:[e-mail]>>
> 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.
> 
> 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
> 
> 
> On Jun 5, 2014, at 4:47 AM, Susan Hares
> <[e-mail]<mailto:[e-mail]>> wrote:
> 
>> 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:[e-mail]<http://btconnect.com>]
>> Sent: Thursday, June 05, 2014 4:35 AM
>> To: Susan Hares; [e-mail]<mailto:[e-mail]>
>> Cc: 'Keyur Patel (keyupate)'; Hannes Gredler; Russ White; 'Susan
>> Hares'; [e-mail]<mailto:[e-mail]>
>> 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
>> 
>> 
>> ----- Original Message -----
>> From: "Susan Hares" <[e-mail]<mailto:[e-mail]>>
>> To: <[e-mail]<mailto:[e-mail]>>
>> Cc: "'Keyur Patel (keyupate)'"
> <[e-mail]<mailto:[e-mail]>>; "Hannes Gredler"
>> <[e-mail]<mailto:[e-mail]>>; "Russ White"
> <[e-mail]<mailto:[e-mail]>>; "'Susan Hares'"
>> <[e-mail]<mailto:[e-mail]>>;
> <[e-mail]<mailto:[e-mail]>>
>> Sent: Wednesday, June 04, 2014 7:49 PM
>> Subject: [i2rs] FW: I-D Action:
>> draft-keyupate-i2rs-bgp-usecases-02.txt
>> 
>> 
>>> 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:[e-mail]<mailto:[e-mail]>] On
> Behalf Of
>>> [e-mail]<mailto:[e-mail]>
>>> Sent: Wednesday, June 04, 2014 1:44 PM
>>> To: [e-mail]<mailto:[e-mail]>
>>> Cc: [e-mail]<mailto:[e-mail]>
>>> 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.
>>> 
>>>       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<http://tools.ietf.org>.
>>> 
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>> 
>>> _______________________________________________
>>> i2rs mailing list
>>> [e-mail]<mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/i2rs
>>> 
>>> _______________________________________________
>>> i2rs mailing list
>>> [e-mail]<mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/i2rs
>>> 
>> 
>> 
>> _______________________________________________
>> i2rs mailing list
>> [e-mail]<mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/i2rs
> 
> <draft-keyupate-i2rs-bgp-usecases-03.txt><draft-keyupate-i2rs-bgp-usecas
> es-03.txt.pdf>
> 
> 
>