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

[Dean Bogdanovic <[e-mail]>]

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

> 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").   
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.
> 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. 
OK
> 
> 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? 
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.

> 
> 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.  
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.
> 
> Sue 
> 
> -----Original Message-----
> From: Dean Bogdanovic [mailto:[e-mail]] 
> Sent: Friday, June 06, 2014 4:03 PM
> To: Susan Hares
> Cc: t.petch; <[e-mail]>; Keyur Patel (keyupate); Hannes Gredler; Russ
> White; Susan Hares; <[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]> 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]]
>> Sent: Thursday, June 05, 2014 4:35 AM
>> To: Susan Hares; [e-mail]
>> Cc: 'Keyur Patel (keyupate)'; Hannes Gredler; Russ White; 'Susan 
>> Hares'; [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]>
>> To: <[e-mail]>
>> Cc: "'Keyur Patel (keyupate)'" <[e-mail]>; "Hannes Gredler"
>> <[e-mail]>; "Russ White" <[e-mail]>; "'Susan Hares'"
>> <[e-mail]>; <[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]] On Behalf Of 
>>> [e-mail]
>>> Sent: Wednesday, June 04, 2014 1:44 PM
>>> To: [e-mail]
>>> Cc: [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.
>>> 
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>> 
>>> _______________________________________________
>>> i2rs mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/i2rs
>>> 
>>> _______________________________________________
>>> i2rs mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/i2rs
>>> 
>> 
>> 
>> _______________________________________________
>> i2rs mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/i2rs
> 
>