Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt
t.petch <ietfc@btconnect.com> Tue, 17 June 2014 09:39 UTC
Return-Path: <ietfc@btconnect.com>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 018FD1A033C for <i2rs@ietfa.amsl.com>; Tue, 17 Jun 2014 02:39:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.301
X-Spam-Level:
X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3forwvXY4Ajv for <i2rs@ietfa.amsl.com>; Tue, 17 Jun 2014 02:39:13 -0700 (PDT)
Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0076.outbound.protection.outlook.com [213.199.154.76]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75AF31A0337 for <i2rs@ietf.org>; Tue, 17 Jun 2014 02:39:12 -0700 (PDT)
Received: from DBXPRD0610HT002.eurprd06.prod.outlook.com (157.56.252.181) by AMSPR07MB050.eurprd07.prod.outlook.com (10.242.81.24) with Microsoft SMTP Server (TLS) id 15.0.969.15; Tue, 17 Jun 2014 09:39:09 +0000
Message-ID: <022701cf8a0f$8ba93b20$4001a8c0@gateway.2wire.net>
From: "t.petch" <ietfc@btconnect.com>
To: Dean Bogdanovic <deanb@juniper.net>, Susan Hares <shares@ndzh.com>
References: <20140604174423.25048.19110.idtracker@ietfa.amsl.com> <005101cf8025$b7cc2b70$27648250$@ndzh.com> <010001cf8099$1c8ba860$4001a8c0@gateway.2wire.net> <004301cf809a$c5d6a090$5183e1b0$@ndzh.com> <8368317D-0E4F-4D6A-8B5C-9366E0F5FC1C@juniper.net> <00ce01cf85da$ce8b8ad0$6ba2a070$@ndzh.com> <41EEF4CB-4694-4617-B2BF-71F89237AB1D@juniper.net> <017b01cf8751$5e9e3100$1bda9300$@ndzh.com> <F09CEB8D-4FBB-463D-97EB-96BB2A0C773D@juniper.net>
Date: Tue, 17 Jun 2014 10:35:46 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [157.56.252.181]
X-ClientProxiedBy: AM3PR07CA006.eurprd07.prod.outlook.com (10.242.16.46) To AMSPR07MB050.eurprd07.prod.outlook.com (10.242.81.24)
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:
X-Forefront-PRVS: 0245702D7B
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(13464003)(199002)(189002)(24454002)(377454003)(377424004)(51704005)(31966008)(74662001)(42186005)(50226001)(105586001)(64706001)(104166001)(33646001)(81342001)(86362001)(4396001)(93916002)(20776003)(15202345003)(47776003)(101416001)(14496001)(61296003)(85306003)(77156001)(77096002)(87286001)(44736004)(93886003)(74502001)(15975445006)(87976001)(62966002)(21056001)(95666004)(50466002)(81816999)(46102001)(19580405001)(19580395003)(83322001)(1941001)(50986999)(88136002)(81686999)(76176999)(83072002)(80022001)(66066001)(77982001)(81542001)(89996001)(85852003)(99396002)(102836001)(44716002)(92726001)(79102001)(23746002)(62236002)(92566001); DIR:OUT; SFP:; SCL:1; SRVR:AMSPR07MB050; H:DBXPRD0610HT002.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en;
Received-SPF: None (: btconnect.com does not designate permitted sender hosts)
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com;
X-OriginatorOrg: btconnect.com
Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/ghVaOrkAhNmmZfQV-0H-1P2goIg
Cc: i2rs@ietf.org, Susan Hares <skh@ndzh.com>, rex@cisco.com, "Keyur Patel (keyupate)" <keyupate@cisco.com>, Hannes Gredler <hannes@juniper.net>, Russ White <russw@riw.us>
Subject: Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Jun 2014 09:39:16 -0000
----- Original Message ----- From: "Dean Bogdanovic" <deanb@juniper.net> To: "Susan Hares" <shares@ndzh.com> 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 <shares@ndzh.com<mailto:shares@ndzh.com>> 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:i2rs-bounces@ietf.org<mailto:bounces@ietf.org>] On Behalf Of Dean Bogdanovic Sent: Friday, June 13, 2014 2:44 PM To: Susan Hares Cc: <i2rs@ietf.org<mailto:i2rs@ietf.org>>; Susan Hares; <rex@cisco.com<mailto:rex@cisco.com>>; 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 <shares@ndzh.com<mailto:shares@ndzh.com>> 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:deanb@juniper.net<http://juniper.net>] Sent: Friday, June 06, 2014 4:03 PM To: Susan Hares Cc: t.petch; <i2rs@ietf.org<mailto:i2rs@ietf.org>>; Keyur Patel (keyupate); Hannes Gredler; Russ White; Susan Hares; <rex@cisco.com<mailto:rex@cisco.com>> 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 <shares@ndzh.com<mailto:shares@ndzh.com>> 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:ietfc@btconnect.com<http://btconnect.com>] > Sent: Thursday, June 05, 2014 4:35 AM > To: Susan Hares; i2rs@ietf.org<mailto:i2rs@ietf.org> > Cc: 'Keyur Patel (keyupate)'; Hannes Gredler; Russ White; 'Susan > Hares'; rex@cisco.com<mailto:rex@cisco.com> > 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" <shares@ndzh.com<mailto:shares@ndzh.com>> > To: <i2rs@ietf.org<mailto:i2rs@ietf.org>> > Cc: "'Keyur Patel (keyupate)'" <keyupate@cisco.com<mailto:keyupate@cisco.com>>; "Hannes Gredler" > <hannes@juniper.net<mailto:hannes@juniper.net>>; "Russ White" <russw@riw.us<mailto:russw@riw.us>>; "'Susan Hares'" > <skh@ndzh.com<mailto:skh@ndzh.com>>; <rex@cisco.com<mailto:rex@cisco.com>> > 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:i2rs-bounces@ietf.org<mailto:bounces@ietf.org>] On Behalf Of >> internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> >> Sent: Wednesday, June 04, 2014 1:44 PM >> To: i-d-announce@ietf.org<mailto:i-d-announce@ietf.org> >> Cc: i2rs@ietf.org<mailto:i2rs@ietf.org> >> 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 >> i2rs@ietf.org<mailto:i2rs@ietf.org> >> https://www.ietf.org/mailman/listinfo/i2rs >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org<mailto:i2rs@ietf.org> >> https://www.ietf.org/mailman/listinfo/i2rs >> > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org<mailto:i2rs@ietf.org> > https://www.ietf.org/mailman/listinfo/i2rs <draft-keyupate-i2rs-bgp-usecases-03.txt><draft-keyupate-i2rs-bgp-usecas es-03.txt.pdf>
- [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecas… internet-drafts
- [i2rs] FW: I-D Action: draft-keyupate-i2rs-bgp-us… Susan Hares
- Re: [i2rs] FW: I-D Action: draft-keyupate-i2rs-bg… t.petch
- Re: [i2rs] FW: I-D Action: draft-keyupate-i2rs-bg… Susan Hares
- Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-us… Dean Bogdanovic
- Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-us… Susan Hares
- Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-us… Dean Bogdanovic
- Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-us… Jeffrey Haas
- Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-us… Susan Hares
- Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-us… Dean Bogdanovic
- Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-us… Susan Hares
- Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-us… Dean Bogdanovic
- Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-us… t.petch
- Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-us… Dean Bogdanovic
- Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-us… Joel M. Halpern
- Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-us… Susan Hares