Re: [i2rs] Comments on Ephemeral-REQ-07 (local config vs. ephemeral)
"Susan Hares" <shares@ndzh.com> Thu, 28 July 2016 20:53 UTC
Return-Path: <shares@ndzh.com>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7756412DC21 for <i2rs@ietfa.amsl.com>; Thu, 28 Jul 2016 13:53:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.738
X-Spam-Level: *
X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no autolearn_force=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 MJtjGePim8gD for <i2rs@ietfa.amsl.com>; Thu, 28 Jul 2016 13:52:56 -0700 (PDT)
Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BB0712E0F3 for <i2rs@ietf.org>; Thu, 28 Jul 2016 13:52:56 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.99.68.42;
From: Susan Hares <shares@ndzh.com>
To: 'Yasuhiro Ohara' <yasu@nttv6.jp>, andy@yumaworks.com
References: <eniiljkadm7ncjq8p2nkjn9d.1469003679596@email.android.com> <1d3b708a-f8f3-b1e1-cf1d-bc09a87dba4f@cisco.com> <CABCOCHRA1_ZGChup9UT=NamPX2gPd88e6MtW8MBXB9_1Bw915A@mail.gmail.com> <20160720.131214.916054873597495950.yasu@nttv6.jp>
In-Reply-To: <20160720.131214.916054873597495950.yasu@nttv6.jp>
Date: Thu, 28 Jul 2016 16:52:02 -0400
Message-ID: <44f801d1e911$e4d1b700$ae752500$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQH/VuEYKIxzZp40mTvjQzKAm4tcvQIw3FrnAt9xtjUCT//gN5+YWfUw
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/xYAY2fTrlMhrHl-nOl3Zux8qmTk>
Cc: rwilton@cisco.com, i2rs@ietf.org, jclarke@cisco.com, 7riw77@gmail.com
Subject: Re: [i2rs] Comments on Ephemeral-REQ-07 (local config vs. ephemeral)
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 28 Jul 2016 20:53:00 -0000
Yasuhiro: <developer hat on> In my developer hat, I agree with you and Andy. As an Implementer I have created a mechanism that will easily re-evaluate queue a re-evaluation of all routes which client priority changes. Here's the back structure: Per connection : Session-id - pointer to structure which has 1) customer pointer --> customer-id, priority, opaque id (this is part of a list of clients ordered by customer id, followed by priority) 2) transport pointer ---> transport ID (src IP/src-port/dst IP/dst-port) 3) last rcv action info --> seq #, function (read/write/rpc) 4) last response info --> (read rsp, write rsp, rpc response, 5) notification- seq #, function, Client 1 could have: Client-1, 5, xyz And have a priority change (due to AAA) to Client-1, 3, zzz My client table would have Pointer 1 - Local config, 5, null Pointer 2 - client-1, 8, xyz Pointer 3 - client-1, 3, zzz Pointer 4 - client 3, 6, bbb' My transport table My session ID table would have Entry 1: Customer pointer - pointer 1 Transport-pointer - null Last action info - null Last response info - null Last notification - null Entry 2: Customer pointer - pointer 2 Transport pointer - transport-pointer-1 Last receive action info - 5, write Last response info - 5, write-rsp Last notification - 1, notify-rpc Entry 3: Customer pointer - pointer 3 Transport pointer - transport-pointer-1 Last action info - 6, write Last response info - 6 write-response Last notification - 3, notify write Entry 4: Customer pointer - pointer 4 Transport pointer - transport-pointer-2 Last receive action info - null Last response - null Last notify - null Each route has: Route (A) ---> session-id pointer ---> rt_rtc - route change structure ---> which has pointer to session ID of client requesting change. If the session-id changes because the customer-id changes, then a background process walks the route list comparing customer-pointer, and new customer-pointer. If it find a new customer pointer, then it places a rt_rtc request structure into the route, and links the route to a change structure. If we have 10,000 routes associated with a client, then the background process changes the routes in groups - until all routes on are processed. [A million routes could be handled by the I2RS route updates, but the processing time would exceed the time for a simple BGP - so I think this is not the target for I2RS]. While this background process is running, if a new route write (rpc or write) for a specific route comes - then the route processes the comparison with client route. The rt_rtc change structure would record two changes: a) the initial routes change to new priority b) the new routes change via a client-3 for route-id with a higher priority, then the new route change takes precedence. The I2RS agent, can respond to the I2RS client-3 that the write succeeds. 1) To Entry 4 would add a write sequence #1, response #1] , 2) to Entry 2 Notify (sequence #4) to client-1 that its write has been overwritten by a higher priority client I agree that if you do not re-process the routes associated with an I2RS client, the priority values are out of sync and some comparison fail that should have succeeded. I disagree with the WG decision to not process priority changes to individual routes. If people wanted to indicate that the processing of the priority change did not need to be immediately, I think the background process works. If this is what the WG meant, then I think this is reasonable. One thing the text says, is that ephemeral routes are compared with a priority, and then ephemeral is compared against Local Configuration. Your assignment illustrates the point, so I did not correct it. <developer hat off> <WG chair hat on> The WG had a long discussion, and came to agreement on not processing past routes. However, I am raising the issue for until 8/1/2016 when I will start a 1 week WG LC on the changes put in ephemeral state. Russ White will judge this WG LC since I am a co-author on the ephemeral state draft. <WG hat off> Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Yasuhiro Ohara Sent: Wednesday, July 20, 2016 7:12 AM To: andy@yumaworks.com Cc: rwilton@cisco.com; i2rs@ietf.org; jclarke@cisco.com; shares@ndzh.com; 7riw77@gmail.com Subject: Re: [i2rs] Comments on Ephemeral-REQ-07 (local config vs. ephemeral) I think I tend to agree with Andy. I couldn't read all the draft yet so I may be missing something important, please correct me then. First, I think we definitely is going to need the re-evaluation of all routes when the client priority changes. (I think this is against the WG's discussion today) Given that the priority of Local-config: 5 and of Client-A: 8, suppose we have: A.B.C.D/M nexthop Y, by Client-A, priority 8 (best) A.B.C.D/M nexthop X, by Local-config, priority 5 then Client-A changed its priority to 3. If we don't re-evaluate: A.B.C.D/M nexthop Y, by Client-A, priority 3 (best) A.B.C.D/M nexthop X, by Local-config, priority 5 which is very odd situation to me. [Sue: I agree with this point. My solution processes the priority change. ] With re-evaluation: A.B.C.D/M nexthop X, by Local-config, priority 5 (best) A.B.C.D/M nexthop Y, by Client-A, priority 3 I think this should be the correct behavior. [Sue: I agree with you.] Similar things happen if we have Client-B with priority 6. I think we should have the list of clients in the agent. Client-A: priority 8 Client-B: priority 6 [Sue: I have listed created a list of clients. See my methodology above. ] Then all the client have to do to change his priority is to let the agent know that the change of priority 8->3. [Sue: You have to know which routes are associated with the client. If the client changes the priority, then you have to re-evaluate it. If you are gathering a set of changes per route from multiple clients or from multiple writes, then the route changes structure could be useful. That will be way much less from the huge traffic that we would be needed to change when millions of routes are related to the Client-A. [Sue: Here, we never assumed that the client would send the different priority. We assumed this priority came from AAA changing the priority. Therefore, the real challenge is the processing of the change in priority per route. ] I may be missing the context totally... sorry in the case. [Sue: 90% correct, the only thing not aligned with my answer is the client ID priority is changed by AAA (radius, diameter or some other AAA process). Best regards, Yasu Thank you for the question. From: Andy Bierman <andy@yumaworks.com> Subject: Re: [i2rs] Comments on Ephemeral-REQ-07 (local config vs. ephemeral) Date: Wed, 20 Jul 2016 02:37:51 -0700 Message-ID: <CABCOCHRA1_ZGChup9UT=NamPX2gPd88e6MtW8MBXB9_1Bw915A@mail.gmail.com> > Hi, > > the text in REQ-07 does not say anything about client identity, but > Sue's comments in the NETCONF WG meeting indicate that the client ID > is saved, not the priority. > > This does not seem to work if client priority can change. > If priority is changed, then it seems that all the overlays affected > need to be adjusted so the operational state reflects the new priority. > > It seems to me that I2RS will require per-node storage of a client ID > and a priority to prevent this re-evaluation. > However, if the operator changes a client-ID priority they probably > want all the nodes re-evaluated. This applies to ephemeral-only, not > just local config vs. ephemeral. > > > Andy > > > On Wed, Jul 20, 2016 at 2:18 AM, Joe Clarke <jclarke@cisco.com> wrote: > >> On 7/20/16 05:10, Robert Wilton -X (rwilton - ENSOFT LIMITED at >> Cisco) >> wrote: >> >>> Hi, >>> >>> Sorry, but I can't make the I2RS meeting because I'm presenting at >>> the end of NETCONF. >>> >>> I've spoken to Sue and understand that the requirement isn't >>> changing here - just the text to describe it. >>> >>> I think that I'm OK with this new text. >>> >>> One suggestion: Possibly It might help if the text made it clear >>> that the priotiy resolution applies to the complete set of ephemeral >>> config vs the complete set of local config. I.e. the requirement is >>> not asking for priority resolution between the two config sets on a >>> per datanode basis. >>> >> >> Yes, I had assumed that in my text, but I agree, this should be clear. >> i, >> > > >> Functionally, in my head, I imagine local config to act like an I2RS >> client. Clients don't have a per-data node priority. They have an >> overall priority. >> >> Is this consistent with what you're stating here? >> >> Joe >> >> >>> But I strongly support getting the requirements draft completed, and >>> hence I suspect that whatever text that you agree in the 2nd I2RS >>> meeting will be fine. >>> >>> Thanks, >>> Rob >>> >>> >>> Sent from my XperiaT tablet >>> >>> ---- Joe Clarke (jclarke) wrote ---- >>> >>> On 7/20/16 03:42, Susan Hares wrote: >>> >>>> Joe: >>>> Yes - you are correct. Can you help me state this requirement -07 >>>> better? >>>> >>> >>> What about: >>> >>> Ephemeral-REQ-07: Ephemeral configuration and local configuration >>> MUST each have a priority. This priority will determine whether >>> ephemeral configuration or local configuration take precedence. The >>> I2RS protocol MUST support this mechanism. >>> >>> Is this clear and correct enough? >>> >>> Joe >>> >>> >>>> Sue >>>> >>>> -----Original Message----- >>>> From: Joe Clarke [mailto:jclarke@cisco.com] >>>> Sent: Wednesday, July 20, 2016 3:40 AM >>>> To: Susan Hares; 'Russ White'; i2rs@ietf.org >>>> Subject: Re: [i2rs] Comments on Ephemeral-REQ-07 (local config vs. >>>> ephemeral) >>>> >>>> On 7/20/16 02:18, Susan Hares wrote: >>>> >>>>> <WG hat off> <author hat on> >>>>> >>>>> Here's text that might replace it: >>>>> >>>>> Ephemeral-REQ-07: Ephemeral configuration state MUST be able to >>>>> set a priority on local configuration and ephemeral state. Based >>>>> on this priority implementations MUST be able to provide a >>>>> mechanism to choose which takes precedence. The I2RS Protocol MUST >>>>> be able to support this >>>>> >>>> mechanisms. >>>> >>>>> >>>>> Any thoughts? >>>>> >>>> >>>> I'm a bit confused by the first sentence. I think what you're >>>> stating is that both ephemeral and local configurations MUST have a priority. >>>> This priority will determine whether ephemeral configuration or >>>> local configuration take precedence. The I2RS protocol MUST >>>> support this mechanism. >>>> >>>> Am I correct in my interpretation? >>>> >>>> Joe >>>> >>>> >>>>> Sue >>>>> >>>>> -----Original Message----- >>>>> From: Russ White [mailto:7riw77@gmail.com] >>>>> Sent: Wednesday, July 20, 2016 2:09 AM >>>>> To: 'Joe Clarke'; 'Susan Hares'; i2rs@ietf.org >>>>> Subject: RE: [i2rs] Comments on Ephemeral-REQ-07 (local config vs. >>>>> ephemeral) >>>>> >>>>> >>>>> (wg chair hat off) -- >>>>> >>>>> I think the idea of extending I2RS priority to local config >>>>> operators >>>>>> >>>>> (e.g., CLI) >>>>> >>>>>> will still work. Let's take knob 1. Knob 1 is kind of like the >>>>>> on/off >>>>>> >>>>> switch. If I >>>>> >>>>>> don't want I2RS to have any effect on operational state, I'd have >>>>>> this >>>>>> >>>>> off. In >>>>> >>>>>> the I2RS priority case, by default my local config could will >>>>>> have the >>>>>> >>>>> highest >>>>> >>>>>> priority (let's say that's 255 to make it concrete). In this >>>>>> case no >>>>>> >>>>> ephemeral >>>>> >>>>>> config can win. >>>>>> >>>>> >>>>> I wanted to extend Joe's remarks a bit... On reflection, I >>>>> actually think having priority + "this wins" bits is rather >>>>> confusing, and opens the door to all sorts of strange behavior. >>>>> Say I have two items thus -- >>>>> >>>>> Local config item -- priority 100 >>>>> I2RS config item -- priority 200, don't overwrite bit set >>>>> >>>>> If the higher priority is supposed to win, then which item should >>>>> the operator find in the resulting running config? Should it be >>>>> the I2RS version, because the priority is higher, or the local >>>>> config, because the "don't overwrite" bit is set? There doesn't >>>>> seem to be any clear way to interpret such a situation. >>>>> >>>>> It's better to have a single "thing" that determines which >>>>> configuration among many wins, rather than two. >>>>> >>>>> -r >>>>> >>>>> >>>>> >>>> >>>> >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Robert Wilton
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Joel M. Halpern
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Joe Clarke
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Andy Bierman
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Joel M. Halpern
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Joe Clarke
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Joel M. Halpern
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Joe Clarke
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Joe Clarke
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Joe Clarke
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Susan Hares
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Joe Clarke
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Russ White
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Joel M. Halpern
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Susan Hares
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Joel M. Halpern
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Susan Hares
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Susan Hares
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Juergen Schoenwaelder
- [i2rs] Comments on Ephemeral-REQ-07 (local config… Joe Clarke
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Susan Hares
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Alia Atlas
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Joe Clarke
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Russ White
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Susan Hares
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Susan Hares
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Yasuhiro Ohara
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Juergen Schoenwaelder
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Susan Hares
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Susan Hares
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… jmh.direct
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Juergen Schoenwaelder