From nobody Sun Nov 1 04:35:30 2015 Return-Path: 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 476FE1B7F98 for ; Sun, 1 Nov 2015 04:35:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 IuCTo8a02MMO for ; Sun, 1 Nov 2015 04:35:27 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 521811B7F97 for ; Sun, 1 Nov 2015 04:35:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=698; q=dns/txt; s=iport; t=1446381327; x=1447590927; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=XX7vzeHliVr+Cw382e3zibiyud4E6eVbeqRZdrRd36k=; b=R0fRCwmb0OG6aI4a8VdPWbPtqwsx1fiBqkGLVXGk1LvNxJQEiGkhARUB tECo1u92NZeMcRy6A04Q1cMkhbQuRLWYQUNgVXRsnliNKeUy2tUtlVMYt LgN0HoJvGrEIgdargCT8gMwmL7Vzzr5YVmhWhp6KiL1bBdLF+//1gqahE A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ABAgDcBTZW/5pdJa1egzvAcwENgVqDQYJOCgKBFzgUAQEBAQEBAYEKhDYBAQQ4QAEQCw4KCRYPCQMCAQIBRQYBDAgBAYgswXsBAQEBAQEBAQEBAQEBAQEBAQEBGoZ3hH6JQAEEjhGIMo0liRmTIR8BAUKEIiCGMgEBAQ X-IronPort-AV: E=Sophos;i="5.20,229,1444694400"; d="scan'208";a="203905149" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-8.cisco.com with ESMTP; 01 Nov 2015 12:35:26 +0000 Received: from [10.24.13.135] ([10.24.13.135]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id tA1CZPpv023338; Sun, 1 Nov 2015 12:35:25 GMT To: Susan Hares , i2rs@ietf.org References: <01bd01d1117e$c7db3b00$5791b100$@ndzh.com> From: Joe Clarke Organization: Cisco Systems, Inc. Message-ID: <5636070D.2010500@cisco.com> Date: Sun, 1 Nov 2015 07:35:25 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <01bd01d1117e$c7db3b00$5791b100$@ndzh.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: 'Jeffrey Haas' , 'Alia Atlas' Subject: Re: [i2rs] WG LC on Requirements X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2015 12:35:28 -0000 On 10/28/15 08:47, Susan Hares wrote: > In October we had WG LC on 4 requirements documents > > draft-ietf-i2rs-ephemeral-state-02.txt > > draft-ietf-i2rs-protocol-security-requirements-01.txt > > draft-ietf-i2rs-pub-sub-requirements-03.txt > > draft-ietf-i2rs-traceability-03.txt > > The pub-sub and traceability were WG LC in June 2015. > > All the requirements will go to the IESG at the same time > > so this check was to see if there was any inconsistency in > > the requirements. I haven't seen in from the traceability standpoint, but I may have missed something. There may be some that shake out of the protocol discussions, so we'll track those as needed. Joe From nobody Sun Nov 1 11:32:12 2015 Return-Path: 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 E37A11A88F5 for ; Sun, 1 Nov 2015 11:32:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.055 X-Spam-Level: X-Spam-Status: No, score=-99.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] 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 j0atuyOZnIY2 for ; Sun, 1 Nov 2015 11:32:09 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71F4C1A88F3 for ; Sun, 1 Nov 2015 11:32:09 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=133.93.81.236; From: "Susan Hares" To: "'Joe Clarke'" , References: <01bd01d1117e$c7db3b00$5791b100$@ndzh.com> <5636070D.2010500@cisco.com> In-Reply-To: <5636070D.2010500@cisco.com> Date: Sun, 1 Nov 2015 14:32:02 -0500 Message-ID: <005101d114db$fcfb3550$f6f19ff0$@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: AQLS71/auU8LmNi+zxBbu4XZKcAJcQIuSX5ynHJWivA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' , 'Alia Atlas' Subject: Re: [i2rs] WG LC on Requirements X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2015 19:32:11 -0000 Joe: Thank you for the message on the traceability. I'll see what Alex has to say about the Topology discussion. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joe Clarke Sent: Sunday, November 01, 2015 7:35 AM To: Susan Hares; i2rs@ietf.org Cc: 'Jeffrey Haas'; 'Alia Atlas' Subject: Re: [i2rs] WG LC on Requirements On 10/28/15 08:47, Susan Hares wrote: > In October we had WG LC on 4 requirements documents > > draft-ietf-i2rs-ephemeral-state-02.txt > > draft-ietf-i2rs-protocol-security-requirements-01.txt > > draft-ietf-i2rs-pub-sub-requirements-03.txt > > draft-ietf-i2rs-traceability-03.txt > > The pub-sub and traceability were WG LC in June 2015. > > All the requirements will go to the IESG at the same time > > so this check was to see if there was any inconsistency in > > the requirements. I haven't seen in from the traceability standpoint, but I may have missed something. There may be some that shake out of the protocol discussions, so we'll track those as needed. Joe _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Sun Nov 1 22:39:22 2015 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 45EE41B488D; Sun, 1 Nov 2015 22:39:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.7.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151102063920.32368.61195.idtracker@ietfa.amsl.com> Date: Sun, 01 Nov 2015 22:39:20 -0800 Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-03.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 06:39:20 -0000 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 : A YANG Data Model for Routing Information Base (RIB) Authors : Lixing Wang Hariharan Ananthakrishnan Mach(Guoyi) Chen Amit Dass Sriganesh Kini Nitin Bahadur Filename : draft-ietf-i2rs-rib-data-model-03.txt Pages : 61 Date : 2015-11-01 Abstract: This document defines a YANG data model for Routing Information Base (RIB) that aligns with the I2RS RIB information model. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-i2rs-rib-data-model-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-rib-data-model-03 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 nobody Mon Nov 2 16:39:40 2015 Return-Path: <7riw77@gmail.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 A16691AC3CD for ; Mon, 2 Nov 2015 16:39:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_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 sV_MdmtLZws3 for ; Mon, 2 Nov 2015 16:39:35 -0800 (PST) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (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 70E491AC3C3 for ; Mon, 2 Nov 2015 16:39:35 -0800 (PST) Received: by pabfh17 with SMTP id fh17so1414984pab.0 for ; Mon, 02 Nov 2015 16:39:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:thread-index:content-language; bh=EQd/qNKu2NWfyKMPTWR7AiiTo/Q0NNptDfpgQn5EBmM=; b=NEMK6J8CcmSjsLgeYMwB3yZwGs7xcGxAOPjWcnhIYkV0KKS3+GWLtzstRUaKJ1Zd6w zjQ5WUwkdV/c/Cr+FUljgJ0gt5VUPxeloDRNPHMsyhnxQqNi2DRQ+9OMvkHo4WYH66Bx +0foJJd/kZLOWOymbr2yDrQd7CkI5kZ7MH9TnihuNc9w1zIjKPL7B8/YnKYJHU28vTED ux9MRclZemI8czhLtLfXDUGGr32NdEDRgr0c+8fdYqUEdxk3DKSjU0jPHymFiNzcu8Kv HeTLUieTHvEilhv2DNBnIvp1hVL5EfOmtA4xePwSeP4BYOnhq5r//kGfI33rcCfcCbdA 9oEg== X-Received: by 10.66.123.9 with SMTP id lw9mr30386034pab.119.1446511175081; Mon, 02 Nov 2015 16:39:35 -0800 (PST) Received: from Russ (t20010c4000003024a97c923879188b9b.v6.meeting.ietf94.jp. [2001:c40:0:3024:a97c:9238:7918:8b9b]) by smtp.gmail.com with ESMTPSA id cs7sm6227844pad.35.2015.11.02.16.39.33 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Nov 2015 16:39:34 -0800 (PST) From: "Russ White" <7riw77@gmail.com> To: Date: Mon, 2 Nov 2015 19:39:28 -0500 Message-ID: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdEVzsrVAPkcLKtgTqWb+FvT7oZZYw== Content-Language: en-us Archived-At: Subject: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 00:39:36 -0000 Y'all -- After sleeping on the discussion last night, I think the panes of glass (or is it pains of glass?? :-) ) is still by and large another expression of the priority concept within I2RS. The concept does bring up one specific point of interest, however -- what about backup information? Some vendor RIBs, for instance, allow a routing process to install not only the best path as calculated by the process -- but if the process fails to install, some RIB implementations allow the process to place the route in the "backup pool." This allows the local RIB process to drop to the "second best path," in terms of priority, so the local RIB doesn't need to query the routing processes to switch in the case of a withdraw or change in topology. To convert this to I2RS terms, it does seem worthwhile to me to have the capability for a local agent to accept an install instruction for some particular ephemeral state, and if the install fails, to hold that state for future use. This would apply to any sort of ephemeral data, including that which is configured locally on the network device. Rather than trying to think of this as "panes of glass," though, this would convert it to simply a backup list of lower priority items the local agent can use in the case of the failure of the highest priority item currently in use. The nice thing about this view is that it doesn't require a lot of changes at the protocol level. The only thing that needs to be available is the option for an agent to send three different types of answers to an install request -- 1. This ephemeral state was installed and is now being used. 2. This ephemeral state was rejected/not installed -- with potential codes for why (out of range parameter, etc.) 3. This ephemeral state was not installed, but is being held as a backup. Using these semantics, the actual implementation of such a feature is up to the local agent. It might be that some agents don't know how to hold backup information, or that it doesn't make any sense to hold some sorts of information in a backup list. This is fine -- the install can just be rejected without further note. Locally configured information could simply be treated as an item on the backup list, such that the priorities can be considered as always in deciding what to install when any particular action is taken. It seems, to me, that this is a simpler way to consider the same problem set, and reduces to an actual protocol mechanism that appears (?) to be fairly simple, and leaves as much flexibility as possible for any given agent implementation. Thoughts? :-) Russ From nobody Mon Nov 2 16:49:15 2015 Return-Path: <7riw77@gmail.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 4A1E31AC3F4 for ; Mon, 2 Nov 2015 16:49:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_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 t1peRP4xS-bj for ; Mon, 2 Nov 2015 16:49:13 -0800 (PST) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (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 5FA6E1AC3F0 for ; Mon, 2 Nov 2015 16:49:13 -0800 (PST) Received: by pacfv9 with SMTP id fv9so1595208pac.3 for ; Mon, 02 Nov 2015 16:49:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:thread-index:content-language; bh=0tLZ931s1zXW1QdmSCAJa78v6R/EJ/QstX2qlxg8TQ0=; b=JDi4NEU1B7hcYGSC16VjhxEO55YmPMHl9AzpCTz4RYefbfgwnDW4l1GaB4ssZhLIns /4LGBNn+FWjHYSn7RAUyrdDnV7zBbim1b2myDlnOjmjWO8EvTdSiqwdn9/MiHSdkGf26 s0fAKjk6MZI3YiMpdiDXawjfRMh1EtA7e7F5hEXnegrogjI/RMPl+y2jOHpKp1OQ1ipj z2HoGZPH9FUugWALQ5LtSuiRwTONaZ6oXKkp22dFgA65cXs3WYlG9okiIRoFqdio+rdq IRpHB/1jF4AFS53+7K2ncgUPLgSpTgH7ekjQ1g5MlDIkNBVi5cTD0+Bw+R/5qvxiHuXV lEhQ== X-Received: by 10.67.3.66 with SMTP id bu2mr4976913pad.70.1446511753100; Mon, 02 Nov 2015 16:49:13 -0800 (PST) Received: from Russ (t20010c4000003024a97c923879188b9b.v6.meeting.ietf94.jp. [2001:c40:0:3024:a97c:9238:7918:8b9b]) by smtp.gmail.com with ESMTPSA id ea5sm26125980pbc.92.2015.11.02.16.49.12 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Nov 2015 16:49:12 -0800 (PST) From: "Russ White" <7riw77@gmail.com> To: Date: Mon, 2 Nov 2015 19:49:06 -0500 Message-ID: <00cf01d115d1$73765ca0$5a6315e0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdEV0CXx69e2m0PhTXO3QDOWmk66OQ== Content-Language: en-us Archived-At: Subject: [i2rs] Ownership and Subscription X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 00:49:14 -0000 Y'all -- After some thought on the entire ownership and subscription issue raised yesterday in the WG meeting -- to repeat the problem for those who weren't there... If an application/controller installs state into a particular agent running on a particular network node, what should we do with the notifications, etc.? Should the agent maintain some sort of "ownership" of the item in some way, so the agent can notify the owner/installer when their information is overwritten? Or should such notifications simply be pub/sub, where anyone (including the owner) can subscribe to changes in the item? I actually think the answer is both... IMHO, the agent should maintain a "who installed this" set of bits, but do nothing with these bits other than maintain them and include them in any notifications. These "bits" don't need to be anything complicated -- any sort of nonce would do, somehow calculated so there is little chance of the bits being replicated between controllers (a problem to be solved later, probably, or outside the confines of the protocol definition). My thinking is this -- when something is installed in the local ephemeral state by the agent, then the process might look like -- 1. The install signal is received 2. The priorities are examined, and the specific state installed 3. The installer is automatically subscribed to the notifications (the installer can decide to be removed from the pub/sub, but subscription should be on by default) 4. If the installer's state is overwritten, it receives a notification 5. This notification contains the "owner bits," which is really just shorthand for the installer to quickly check to see if "I installed this" Local policy in the controller might use this information in different ways. It's really just a bit of shorthand to help the controllers process things more efficiently, rather than real "ownership bits" in the more traditional sense. This seems like it solves the problems at hand -- ownership only implies subscription because the subscribe happens by default, but it's not really attached to the "ownership bits." It also, however, provides a shortcut for the "owner" to know what's going on with "their" installed state. Thoughts? :-) Russ From nobody Mon Nov 2 17:08:54 2015 Return-Path: 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 07AA41ACD35 for ; Mon, 2 Nov 2015 17:08:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 I4WiVn3pNImP for ; Mon, 2 Nov 2015 17:08:52 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 712A51ACC88 for ; Mon, 2 Nov 2015 17:08:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 5F523240E4C; Mon, 2 Nov 2015 17:08:52 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (122x210x83x163.ap122.ftth.ucom.ne.jp [122.210.83.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id D563B24079E; Mon, 2 Nov 2015 17:08:51 -0800 (PST) To: Russ White <7riw77@gmail.com>, i2rs@ietf.org References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> From: "Joel M. Halpern" Message-ID: <56380923.1050301@joelhalpern.com> Date: Mon, 2 Nov 2015 20:08:51 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 01:08:54 -0000 We discussed storing backup ephemeral state. There are a number of issues that arise if we permit that. For example, if state gets over-ridden, but preserved, then even though it is not doing any good, the client which installed the state must still monitor for any related dependenecies so as to not leave incorrect pending state. Which also means that a client has to be able to remove state it has created, even though that state has been over-ridden. And probably has to be able to create state which won't take effect. Which in turns means that you need to be able to read your own effects and the current state separately. In general, earlier working group discussion found this to add a lot of complexity. So our agreement for now is that there is no storing of non-effecting state by I2RS. Caching or other performance improvements are for future study. Yours, Joel On 11/2/15 7:39 PM, Russ White wrote: > Y'all -- > > After sleeping on the discussion last night, I think the panes of glass (or > is it pains of glass?? :-) ) is still by and large another expression of > the priority concept within I2RS. The concept does bring up one specific > point of interest, however -- what about backup information? Some vendor > RIBs, for instance, allow a routing process to install not only the best > path as calculated by the process -- but if the process fails to install, > some RIB implementations allow the process to place the route in the "backup > pool." This allows the local RIB process to drop to the "second best path," > in terms of priority, so the local RIB doesn't need to query the routing > processes to switch in the case of a withdraw or change in topology. > > To convert this to I2RS terms, it does seem worthwhile to me to have the > capability for a local agent to accept an install instruction for some > particular ephemeral state, and if the install fails, to hold that state for > future use. This would apply to any sort of ephemeral data, including that > which is configured locally on the network device. Rather than trying to > think of this as "panes of glass," though, this would convert it to simply a > backup list of lower priority items the local agent can use in the case of > the failure of the highest priority item currently in use. > > The nice thing about this view is that it doesn't require a lot of changes > at the protocol level. The only thing that needs to be available is the > option for an agent to send three different types of answers to an install > request -- > > 1. This ephemeral state was installed and is now being used. > 2. This ephemeral state was rejected/not installed -- with potential codes > for why (out of range parameter, etc.) > 3. This ephemeral state was not installed, but is being held as a backup. > > Using these semantics, the actual implementation of such a feature is up to > the local agent. It might be that some agents don't know how to hold backup > information, or that it doesn't make any sense to hold some sorts of > information in a backup list. This is fine -- the install can just be > rejected without further note. Locally configured information could simply > be treated as an item on the backup list, such that the priorities can be > considered as always in deciding what to install when any particular action > is taken. > > It seems, to me, that this is a simpler way to consider the same problem > set, and reduces to an actual protocol mechanism that appears (?) to be > fairly simple, and leaves as much flexibility as possible for any given > agent implementation. > > Thoughts? > > :-) > > Russ > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Mon Nov 2 17:13:39 2015 Return-Path: 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 E81521ACD49 for ; Mon, 2 Nov 2015 17:13:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 KtnB2W7Ea-OU for ; Mon, 2 Nov 2015 17:13:36 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C3D21ACD60 for ; Mon, 2 Nov 2015 17:13:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 05B4C1C0134; Mon, 2 Nov 2015 17:13:32 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (122x210x83x163.ap122.ftth.ucom.ne.jp [122.210.83.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 7C8CB1C049B; Mon, 2 Nov 2015 17:13:31 -0800 (PST) To: Russ White <7riw77@gmail.com>, i2rs@ietf.org References: <00cf01d115d1$73765ca0$5a6315e0$@gmail.com> From: "Joel M. Halpern" Message-ID: <56380A3B.3060008@joelhalpern.com> Date: Mon, 2 Nov 2015 20:13:31 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <00cf01d115d1$73765ca0$5a6315e0$@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [i2rs] Ownership and Subscription X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 01:13:38 -0000 In order to apply the priority mechanism, we effectively have to retain the information for ephemeral state about who installed it. This is particularly true given the agreement that all clients will have unique priorities. Given that, it seems simple and useful to always include that installer in the list of people who receive a notification that the modification has been over-written. For one thing, that avoids any kind of race condition where the over-ride could occur before the creator has a chance to add his notification request. In particular, remember that we architecturally consider such over-writes to be an error. The priority mechanism makes no pretense of correctness. Rather, it tries to produce predictability. So notifying the participants in an error of the problem seems necessary. Which is why the architecture document mandates it. Yours, Joel On 11/2/15 7:49 PM, Russ White wrote: > Y'all -- > > After some thought on the entire ownership and subscription issue raised > yesterday in the WG meeting -- to repeat the problem for those who weren't > there... If an application/controller installs state into a particular agent > running on a particular network node, what should we do with the > notifications, etc.? Should the agent maintain some sort of "ownership" of > the item in some way, so the agent can notify the owner/installer when their > information is overwritten? Or should such notifications simply be pub/sub, > where anyone (including the owner) can subscribe to changes in the item? > > I actually think the answer is both... IMHO, the agent should maintain a > "who installed this" set of bits, but do nothing with these bits other than > maintain them and include them in any notifications. These "bits" don't need > to be anything complicated -- any sort of nonce would do, somehow calculated > so there is little chance of the bits being replicated between controllers > (a problem to be solved later, probably, or outside the confines of the > protocol definition). My thinking is this -- when something is installed in > the local ephemeral state by the agent, then the process might look like -- > > 1. The install signal is received > 2. The priorities are examined, and the specific state installed > 3. The installer is automatically subscribed to the notifications (the > installer can decide to be removed from the pub/sub, but subscription should > be on by default) > 4. If the installer's state is overwritten, it receives a notification > 5. This notification contains the "owner bits," which is really just > shorthand for the installer to quickly check to see if "I installed this" > Local policy in the controller might use this information in different ways. > It's really just a bit of shorthand to help the controllers process things > more efficiently, rather than real "ownership bits" in the more traditional > sense. > > This seems like it solves the problems at hand -- ownership only implies > subscription because the subscribe happens by default, but it's not really > attached to the "ownership bits." It also, however, provides a shortcut for > the "owner" to know what's going on with "their" installed state. > > Thoughts? > > :-) > > Russ > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Mon Nov 2 17:27:23 2015 Return-Path: <7riw77@gmail.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 5205A1ACEF3 for ; Mon, 2 Nov 2015 17:27:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_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 z9TBg5w3Yd5P for ; Mon, 2 Nov 2015 17:27:16 -0800 (PST) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (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 693C71ACED3 for ; Mon, 2 Nov 2015 17:27:16 -0800 (PST) Received: by pabfh17 with SMTP id fh17so2524284pab.0 for ; Mon, 02 Nov 2015 17:27:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=qoymEm3Zc4y9MlPeitNtlqZZwPMnZ5xfuOaBILI/eTA=; b=XxAVQSGjLseBdTMqSKrYeZjj6B+PKsViXG73vFMzemXtj9aVA9+Lm7TVxK20JBXMim egjdrzJq2tyIDeEHjmO1lREgFEG7zkMdKRGq05A8ic2mq+CGUUY7JyJX16GaNfftRWcc 0MZ/paJir/8atu3Sgj8rRfg0e2GM58fOr3JgmwJLebpF3GJaz9adg5ptMCAytxhzly2K k5RpvRQ8gf07+zPHWu0s0Z+Zzga773ZH8dHFus7UbuOv6YxcNogNcSxZjq59EgoY/BCL Eq+AYlxq8jbnUS50XyT+5Z4haVv32u+xqUexCPqZaf0dw0AWt3n6RWCJV6rHvrNT7YCN xzXw== X-Received: by 10.68.170.101 with SMTP id al5mr30877147pbc.38.1446514035985; Mon, 02 Nov 2015 17:27:15 -0800 (PST) Received: from Russ (t20010c4000003024a97c923879188b9b.v6.meeting.ietf94.jp. [2001:c40:0:3024:a97c:9238:7918:8b9b]) by smtp.gmail.com with ESMTPSA id ku1sm26267132pbc.47.2015.11.02.17.27.14 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Nov 2015 17:27:15 -0800 (PST) From: "Russ White" <7riw77@gmail.com> To: "'Joel M. Halpern'" , References: <00cf01d115d1$73765ca0$5a6315e0$@gmail.com> <56380A3B.3060008@joelhalpern.com> In-Reply-To: <56380A3B.3060008@joelhalpern.com> Date: Mon, 2 Nov 2015 20:27:09 -0500 Message-ID: <010a01d115d6$c41721d0$4c456570$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJnM+C7uUvbHKk7SEbsRDqJeBdn3ALpIyG9nUX7zKA= Content-Language: en-us Archived-At: Subject: Re: [i2rs] Ownership and Subscription X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 01:27:17 -0000 > In order to apply the priority mechanism, we effectively have to retain the > information for ephemeral state about who installed it. This is particularly > true given the agreement that all clients will have unique priorities. If all clients must have unique priorities, why do we need to use this information in the priority mechanism? > Given that, it seems simple and useful to always include that installer in the > list of people who receive a notification that the modification has been over- > written. For one thing, that avoids any kind of race condition where the > over-ride could occur before the creator has a chance to add his notification > request. It is useful -- I'm not arguing that we shouldn't do this _by default_, only that we shouldn't make this mechanism separate from any other pub/sub. It would seem to be easier to have one mechanism that's common, rather than multiples... I would say -- mandate it by default, but allow the client to turn it off if it wants after the state has been installed. This keeps the mechanism the same across all clients. :-) Russ From nobody Mon Nov 2 17:28:35 2015 Return-Path: <7riw77@gmail.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 CCDAD1AD362 for ; Mon, 2 Nov 2015 17:28:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_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 nuI-zCEoFGgO for ; Mon, 2 Nov 2015 17:28:30 -0800 (PST) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (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 928851AE4CB for ; Mon, 2 Nov 2015 17:28:29 -0800 (PST) Received: by pacfv9 with SMTP id fv9so2568888pac.3 for ; Mon, 02 Nov 2015 17:28:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=w18w53sZ0MSwaflhDyEKXAK4JRILFOXNsQp1t19sTCA=; b=Gfe4sguXaRvF/NL/n1K9TVvW06SsrJOjZaxECAVtoek2piyiofFIHOZoWgEhkOPV6l 3OZLDa0Q9nKpyhofbiq3WnIujEDVXeg4pzzaBui/O7jkYG+aQUVyoUQK9eMaBGrj1hnH dWP90PH9nnuY1V6z+qEwZBPqgG6gdjESJzw2Je3Zhm8wOegGrei5jrtlPWNLmJcQGPS9 ubb+V5lrioskKhtA+zZ9Gxy3gETKtCT66ivOl6KJHQ9m4HeIYYUvjTqAEgh2TQv6Oo66 Gr/AWCGXuVaaI4Zs6LMbOe6JyCCyCfey2KDypwaMN4//9UX2MXQSiq5HrLizUfer5iT6 DWUQ== X-Received: by 10.66.220.2 with SMTP id ps2mr30138739pac.145.1446514109204; Mon, 02 Nov 2015 17:28:29 -0800 (PST) Received: from Russ (t20010c4000003024a97c923879188b9b.v6.meeting.ietf94.jp. [2001:c40:0:3024:a97c:9238:7918:8b9b]) by smtp.gmail.com with ESMTPSA id lo9sm26360172pab.19.2015.11.02.17.28.28 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Nov 2015 17:28:28 -0800 (PST) From: "Russ White" <7riw77@gmail.com> To: "'Joel M. Halpern'" , References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <56380923.1050301@joelhalpern.com> In-Reply-To: <56380923.1050301@joelhalpern.com> Date: Mon, 2 Nov 2015 20:28:22 -0500 Message-ID: <010b01d115d6$efe1c3b0$cfa54b10$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLwMtmz+XLO8+uQ7j5WaenA2rWXRwHWsxrtnDyST6A= Content-Language: en-us Archived-At: Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 01:28:31 -0000 > For example, if state gets over-ridden, but preserved, then even though it is > not doing any good, the client which installed the state must still monitor for > any related dependenecies so as to not leave incorrect pending state. > Which also means that a client has to be able to remove state it has created, > even though that state has been over-ridden. And probably has to be able > to create state which won't take effect. Which in turns means that you need > to be able to read your own effects and the current state separately. I would think this should be a client specific implementation detail... I don't see why, from a protocol level, it should be disallowed, when the changes involved would be minor (or at least it seems to me?). :-) Russ From nobody Mon Nov 2 17:51:33 2015 Return-Path: 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 63CD91A00B0 for ; Mon, 2 Nov 2015 17:51:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 iE8KIP6-UYkL for ; Mon, 2 Nov 2015 17:51:30 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 627041A0026 for ; Mon, 2 Nov 2015 17:51:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4F61C240E4C; Mon, 2 Nov 2015 17:51:30 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (122x210x83x163.ap122.ftth.ucom.ne.jp [122.210.83.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id D5B1A240754; Mon, 2 Nov 2015 17:51:29 -0800 (PST) To: Russ White <7riw77@gmail.com>, i2rs@ietf.org References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <56380923.1050301@joelhalpern.com> <010b01d115d6$efe1c3b0$cfa54b10$@gmail.com> From: "Joel M. Halpern" Message-ID: <56381321.9060502@joelhalpern.com> Date: Mon, 2 Nov 2015 20:51:29 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <010b01d115d6$efe1c3b0$cfa54b10$@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 01:51:31 -0000 Allowing caching means that we have to specify additional mechanisms (such as read-through and write-through, and returns for successful writes that do not actually take effect, and probably other aspects.) So we agreed that was for future consideration, as it is by no means minor. Yours, Joel On 11/2/15 8:28 PM, Russ White wrote: > >> For example, if state gets over-ridden, but preserved, then even though it > is >> not doing any good, the client which installed the state must still > monitor for >> any related dependenecies so as to not leave incorrect pending state. >> Which also means that a client has to be able to remove state it has > created, >> even though that state has been over-ridden. And probably has to be able >> to create state which won't take effect. Which in turns means that you > need >> to be able to read your own effects and the current state separately. > > I would think this should be a client specific implementation detail... I > don't see why, from a protocol level, it should be disallowed, when the > changes involved would be minor (or at least it seems to me?). > > :-) > > Russ > > From nobody Mon Nov 2 17:52:47 2015 Return-Path: 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 32A141A00C3 for ; Mon, 2 Nov 2015 17:52:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 YA5qp1G99u1w for ; Mon, 2 Nov 2015 17:52:45 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41F1E1A00A1 for ; Mon, 2 Nov 2015 17:52:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 2F0C71C0487; Mon, 2 Nov 2015 17:52:45 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (122x210x83x163.ap122.ftth.ucom.ne.jp [122.210.83.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 9926C1C0318; Mon, 2 Nov 2015 17:52:44 -0800 (PST) To: Russ White <7riw77@gmail.com>, i2rs@ietf.org References: <00cf01d115d1$73765ca0$5a6315e0$@gmail.com> <56380A3B.3060008@joelhalpern.com> <010a01d115d6$c41721d0$4c456570$@gmail.com> From: "Joel M. Halpern" Message-ID: <5638136C.6030801@joelhalpern.com> Date: Mon, 2 Nov 2015 20:52:44 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <010a01d115d6$c41721d0$4c456570$@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [i2rs] Ownership and Subscription X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 01:52:46 -0000 I would indeed expect to use the same mechanisms for delivering the error notifications as for all other notificaitons. And I suppose one could allow a client to unsubscribe from such notifications. But it actually seems to encourage dangerous behavior to do so. And adds extra complexity. Yours, Joel On 11/2/15 8:27 PM, Russ White wrote: > >> In order to apply the priority mechanism, we effectively have to retain > the >> information for ephemeral state about who installed it. This is > particularly >> true given the agreement that all clients will have unique priorities. > > If all clients must have unique priorities, why do we need to use this > information in the priority mechanism? > >> Given that, it seems simple and useful to always include that installer in > the >> list of people who receive a notification that the modification has been > over- >> written. For one thing, that avoids any kind of race condition where the >> over-ride could occur before the creator has a chance to add his > notification >> request. > > It is useful -- I'm not arguing that we shouldn't do this _by default_, only > that we shouldn't make this mechanism separate from any other pub/sub. It > would seem to be easier to have one mechanism that's common, rather than > multiples... I would say -- mandate it by default, but allow the client to > turn it off if it wants after the state has been installed. This keeps the > mechanism the same across all clients. > > :-) > > Russ > > > > From nobody Mon Nov 2 18:02:23 2015 Return-Path: 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 5474D1A1A73 for ; Mon, 2 Nov 2015 18:02:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_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 12z-q7Pz1EvR for ; Mon, 2 Nov 2015 18:02:20 -0800 (PST) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (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 2E1CF1A1AB3 for ; Mon, 2 Nov 2015 18:02:20 -0800 (PST) Received: by lfgh9 with SMTP id h9so2384426lfg.1 for ; Mon, 02 Nov 2015 18:02:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fN2Ru37uD8l+fM9BW9OyZj4siaLf0t8FmpXcf9KA4iI=; b=avZqEX0gn7qy+UbRNDZO8d28A4jvjx0Ukuc2vpp1fdJR3XfZtEzv8HAuIEovuxxhat tM17M7Sy39I8TgyAhOUSujB0pcusVMMYKW2/87wcd69unViEKv8d5InQ9AJCXQj2mPCt lnyOGw/FpAq+NyHqPG+R1SgVNIBTUGWW3NehuqJH1UGDUa1QSWOeRAOX+aBgsguS82cQ oLnl6A8bpRJNOerxFKZt2zy4FWuVAMMlyHUyKl/KKB0K/d9uJ4NJPmzNFpMUrKan3cDm D9pTDp3HACttTVtp12qlPVDt6vSv9YIpUnr8tlQ74KfFLpuBlKh6iryKxitkK3WWc2mA jbcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fN2Ru37uD8l+fM9BW9OyZj4siaLf0t8FmpXcf9KA4iI=; b=LQFJRqXpt3qh1LW+uivAPOZE0lK3ceVJmx69gOpbIbhZNnubciy4mV07qFNR1JmKXK 8WDr30gxsba79CYSRoWFJvOcq33W4u4PcrQfyGxSk+jyVeDkiO9P90chCgGk9utBMC3Z QtouI0vyo5yCMArsZy5Nev1XJB/Uqj1VmcnYqF5YtPeYZw1v5PLeYRMzLlNztEx/eBE6 9ViWESQeSYep9SgbQ0DXXGPKkb2GHjXn7UtxiNAlrbEsqXJEWIFxf+mhHNmHII6oYnLK 1ySoiAOEv+vqoQsT5B9b5ahCSuyFDj5/f9l72EEhNviOg8VZ3mNFgOM8+2hPMTd2lxnS D3Zg== X-Gm-Message-State: ALoCoQlWTMrsFH0jT/JGXsdpv9fW0xbLXQVOtUSnhvfKx3TQLbml5xo6sLK3Qu37M4I2SHy6WrB+ MIME-Version: 1.0 X-Received: by 10.112.161.168 with SMTP id xt8mr11539838lbb.88.1446516138438; Mon, 02 Nov 2015 18:02:18 -0800 (PST) Received: by 10.112.144.106 with HTTP; Mon, 2 Nov 2015 18:02:18 -0800 (PST) In-Reply-To: <010b01d115d6$efe1c3b0$cfa54b10$@gmail.com> References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <56380923.1050301@joelhalpern.com> <010b01d115d6$efe1c3b0$cfa54b10$@gmail.com> Date: Mon, 2 Nov 2015 18:02:18 -0800 Message-ID: From: Andy Bierman To: Russ White <7riw77@gmail.com> Content-Type: multipart/alternative; boundary=001a11c3cb369807e50523994817 Archived-At: Cc: "i2rs@ietf.org" , "Joel M. Halpern" Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 02:02:22 -0000 --001a11c3cb369807e50523994817 Content-Type: text/plain; charset=UTF-8 On Mon, Nov 2, 2015 at 5:28 PM, Russ White <7riw77@gmail.com> wrote: > > > For example, if state gets over-ridden, but preserved, then even though > it > is > > not doing any good, the client which installed the state must still > monitor for > > any related dependenecies so as to not leave incorrect pending state. > > Which also means that a client has to be able to remove state it has > created, > > even though that state has been over-ridden. And probably has to be able > > to create state which won't take effect. Which in turns means that you > need > > to be able to read your own effects and the current state separately. > > I would think this should be a client specific implementation detail... I > don't see why, from a protocol level, it should be disallowed, when the > changes involved would be minor (or at least it seems to me?). > > I am not sure I understand edit collision processing. The proposals is that the ephemeral datastore contains data from 1 or more clients. The data from different clients is non-overlapping (for some definition of that). I will avoid running config + ephemeral leaf-override for now. Assume the data model is entirely for I2RS: container foo { leaf A { type int32; } leaf B { type int32; } } 1) client-worst set /foo/A to 42 { "foo": { "A":42 } } 2) client-best sets /foo/B to 7 { "foo": { "B":7 } } 3) Is client-best going to knock out data owned by client-worst? what happens to /foo/A? Q1) Is this a collision because /foo is written by both clients? if not, does client-best own /foo and /foo/A, and client-worst owns /foo/B? If yes, then step (2) is effectively a PUT, no matter what method is really used Q2) what notifications are sent to client-worst, if any (depending on answer to Q1) (client-worst either lost ownership of /foo or /foo and /foo/A) Consider that A and B can be arbitrary subtrees, not just leafs. How are the edit collision boundaries specified? Simple YANG overlap will cause lots of deletions. More granular/complex boundary specification would help avoid such deletions where the 2 clients could actually co-exist. > :-) > > Russ > > Andy > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --001a11c3cb369807e50523994817 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Nov 2, 2015 at 5:28 PM, Russ White <7riw77@gmail.com> wrote:

> For example, if state gets over-ridden, but preserved, then even thoug= h it
is
> not doing any good, the client which installed the state must still monitor for
> any related dependenecies so as to not leave incorrect pending state.<= br> > Which also means that a client has to be able to remove state it has created,
> even though that state has been over-ridden.=C2=A0 And probably has to= be able
> to create state which won't take effect.=C2=A0 Which in turns mean= s that you
need
> to be able to read your own effects and the current state separately.<= br>
I would think this should be a client specific implementation detail... I don't see why, from a protocol level, it should be disallowed, when the=
changes involved would be minor (or at least it seems to me?).


I am not sure I understand edit collis= ion processing.
The proposals is that the ephemeral datastore con= tains data
from 1 or more clients.=C2=A0 The data from different = clients is non-overlapping
(for some definition of that).

I will avoid running config + ephemeral leaf-override for= now.
Assume the data model is entirely for I2RS:

<= /div>
=C2=A0 container foo {
=C2=A0 =C2=A0 =C2=A0leaf A { typ= e int32; }
=C2=A0 =C2=A0 =C2=A0leaf B { type int32; }
= =C2=A0 }

1) client-worst set /foo/A to 42 =C2=A0 = =C2=A0{ "foo": { "A":42 } }

2)= client-best sets /foo/B to 7 =C2=A0 =C2=A0 =C2=A0 { "foo": { &qu= ot;B":7 } }

3) Is client-best going to knock = out data owned by client-worst?
=C2=A0 =C2=A0what happens to /foo= /A?

Q1) Is this a collision because /foo is writte= n by both clients?
=C2=A0 if not, does client-best own /foo and /= foo/A, and client-worst owns /foo/B?
=C2=A0 If yes, then step (2)= is effectively a PUT, no matter what method is really used

<= /div>
Q2) what notifications are sent to client-worst, if any (dependin= g on answer to Q1)
(client-worst either lost ownership of /foo or= /foo and /foo/A)

Consider that A and B can be arb= itrary subtrees, not just leafs.

How are the edit = collision boundaries specified?
Simple YANG overlap will cause lo= ts of deletions.
More granular/complex boundary specification wou= ld help
avoid such deletions where the 2 clients could actually c= o-exist.


=C2=A0
:-)

Russ



Andy

=C2=A0
_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

--001a11c3cb369807e50523994817-- From nobody Mon Nov 2 18:05:59 2015 Return-Path: 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 AED0E1A0122 for ; Mon, 2 Nov 2015 18:05:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 OysL3ESF2gu7 for ; Mon, 2 Nov 2015 18:05:56 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2BAD1A8701 for ; Mon, 2 Nov 2015 18:05:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 6E1CC240E4C; Mon, 2 Nov 2015 18:05:38 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (122x210x83x163.ap122.ftth.ucom.ne.jp [122.210.83.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id F2299240470; Mon, 2 Nov 2015 18:05:31 -0800 (PST) To: Andy Bierman , Russ White <7riw77@gmail.com> References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <56380923.1050301@joelhalpern.com> <010b01d115d6$efe1c3b0$cfa54b10$@gmail.com> From: Joel Halpern Direct Message-ID: <56381667.6070606@joelhalpern.com> Date: Mon, 2 Nov 2015 21:05:27 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 02:05:57 -0000 What we side with regard to the atomicity of collisions was that the model needed to specify that. So if the model writer concludes that the leaves A and B in your example are so closely coupled that bad things will happen if different people write different parts, then they can say the container is the granularity. Usually, I would expect the leaf to be the granularity. We do not expect the I2RS agent (or the underlying system) to guess the granularity. Yours, Joel On 11/2/15 9:02 PM, Andy Bierman wrote: > > > On Mon, Nov 2, 2015 at 5:28 PM, Russ White <7riw77@gmail.com > > wrote: > > > > For example, if state gets over-ridden, but preserved, then even > though it > is > > not doing any good, the client which installed the state must still > monitor for > > any related dependenecies so as to not leave incorrect pending state. > > Which also means that a client has to be able to remove state it has > created, > > even though that state has been over-ridden. And probably has to > be able > > to create state which won't take effect. Which in turns means > that you > need > > to be able to read your own effects and the current state separately. > > I would think this should be a client specific implementation > detail... I > don't see why, from a protocol level, it should be disallowed, when the > changes involved would be minor (or at least it seems to me?). > > > I am not sure I understand edit collision processing. > The proposals is that the ephemeral datastore contains data > from 1 or more clients. The data from different clients is non-overlapping > (for some definition of that). > > I will avoid running config + ephemeral leaf-override for now. > Assume the data model is entirely for I2RS: > > container foo { > leaf A { type int32; } > leaf B { type int32; } > } > > 1) client-worst set /foo/A to 42 { "foo": { "A":42 } } > > 2) client-best sets /foo/B to 7 { "foo": { "B":7 } } > > 3) Is client-best going to knock out data owned by client-worst? > what happens to /foo/A? > > Q1) Is this a collision because /foo is written by both clients? > if not, does client-best own /foo and /foo/A, and client-worst owns > /foo/B? > If yes, then step (2) is effectively a PUT, no matter what method is > really used > > Q2) what notifications are sent to client-worst, if any (depending on > answer to Q1) > (client-worst either lost ownership of /foo or /foo and /foo/A) > > Consider that A and B can be arbitrary subtrees, not just leafs. > > How are the edit collision boundaries specified? > Simple YANG overlap will cause lots of deletions. > More granular/complex boundary specification would help > avoid such deletions where the 2 clients could actually co-exist. > > > :-) > > Russ > > > > Andy > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > From nobody Mon Nov 2 18:12:50 2015 Return-Path: <7riw77@gmail.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 D1D8F1AC413 for ; Mon, 2 Nov 2015 18:12:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_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 lB2VrGrK_-pK for ; Mon, 2 Nov 2015 18:12:48 -0800 (PST) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (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 E38B11AC3E7 for ; Mon, 2 Nov 2015 18:12:47 -0800 (PST) Received: by pasz6 with SMTP id z6so3520541pas.2 for ; Mon, 02 Nov 2015 18:12:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=PG89tDJBKYEbTom3T3JpOLnfQqAun9jqkN37BzZFQeE=; b=Ludq23bPqYWxyYRPClD+BK+jkFyhRpwhs9x4RSDP4HyDPRhav4pEns6eQSpQYfSxuJ W+qTZicsMWMpJi99s30yk+t5V8E1ic25g4S8obYi8QyrUKshVnkq4xwWj+k/9gsc3ePW Kq3XglTON2ZNKSKzCKLwzKGOzigrN2DHTdXhmZOMm49ZR3ww00AenMfmNlRyHJ4oGtuT 7BUWln4LChKvuZX2WFPBnyVuFRXr0miic069PQARsM2tKuTPXfOsrb6LRTA0aB+RO04i ldSeh3X23bNCG0HDvSYMxcKovOeKTkZdGqlRbmgtNVbzlzSuZSStnWlIxU/I+s6/JdnF tZrA== X-Received: by 10.66.66.166 with SMTP id g6mr30350592pat.152.1446516767648; Mon, 02 Nov 2015 18:12:47 -0800 (PST) Received: from Russ (t20010c4000003024a97c923879188b9b.v6.meeting.ietf94.jp. [2001:c40:0:3024:a97c:9238:7918:8b9b]) by smtp.gmail.com with ESMTPSA id dd2sm26406268pbc.27.2015.11.02.18.12.46 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Nov 2015 18:12:47 -0800 (PST) From: "Russ White" <7riw77@gmail.com> To: "'Joel M. Halpern'" , References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <56380923.1050301@joelhalpern.com> <010b01d115d6$efe1c3b0$cfa54b10$@gmail.com> <56381321.9060502@joelhalpern.com> In-Reply-To: <56381321.9060502@joelhalpern.com> Date: Mon, 2 Nov 2015 21:12:40 -0500 Message-ID: <008701d115dd$20a1b7c0$61e52740$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLwMtmz+XLO8+uQ7j5WaenA2rWXRwHWsxrtAgDoOY0CCi4xL5wcReog Content-Language: en-us Archived-At: Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 02:12:49 -0000 > Allowing caching means that we have to specify additional mechanisms (such > as read-through and write-through, and returns for successful writes that do > not actually take effect, and probably other aspects.) I don't really see it as "caching..." I'm thinking more of the backup route situation in the RIB, specifically. > So we agreed that was for future consideration, as it is by no means minor. I would argue it's worthwhile to at least leave space in the protocol definition for the third return option, and leave it up to agent implementations to deal with the complexity if desired in the future. :-) Russ From nobody Mon Nov 2 18:15:45 2015 Return-Path: <7riw77@gmail.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 2E0E81A901C for ; Mon, 2 Nov 2015 18:15:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_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 MOCXs8blkvL2 for ; Mon, 2 Nov 2015 18:15:38 -0800 (PST) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (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 776CC1ACD70 for ; Mon, 2 Nov 2015 18:15:38 -0800 (PST) Received: by padec8 with SMTP id ec8so3628439pad.1 for ; Mon, 02 Nov 2015 18:15:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=X20bnSYp8N6vzvNxyxprj6IMeF45WKTLJkaXNb5lHqw=; b=lgJ53qWZml12MqAdHtRj7o0EbxsS6SrWFPvclya0JAOhhRW/vpEeZfcRtWtv4j4CB3 UK4Of/73Kyzn8VY/IhI0/sASPNbIxb7o+WZRkF9TIAvRgy7UFDztA7GbMLVwn42uwLaB y1mUcH8VC35AC9cChZHZD2EqwRov0BBR24p8/kY8JXY4Dj5XInnwiory4Chn9kHKA/YO NHCC1Y758RUTv29lb2KnCQuJmIPB67dKGcDzk/8zWjX7V5d2q5+oE6c5EWm/g4C+bZPK 4H30XuGOY0t68okMjx5bprXDicWSnfSmYZZJ3aTZjYVYCpeY8NfS3r1JUhUmO1yQPBM1 la7Q== X-Received: by 10.66.100.226 with SMTP id fb2mr31063998pab.72.1446516938222; Mon, 02 Nov 2015 18:15:38 -0800 (PST) Received: from Russ (t20010c4000003024a97c923879188b9b.v6.meeting.ietf94.jp. [2001:c40:0:3024:a97c:9238:7918:8b9b]) by smtp.gmail.com with ESMTPSA id qd2sm26370384pbb.68.2015.11.02.18.15.37 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Nov 2015 18:15:37 -0800 (PST) From: "Russ White" <7riw77@gmail.com> To: "'Joel M. Halpern'" , References: <00cf01d115d1$73765ca0$5a6315e0$@gmail.com> <56380A3B.3060008@joelhalpern.com> <010a01d115d6$c41721d0$4c456570$@gmail.com> <5638136C.6030801@joelhalpern.com> In-Reply-To: <5638136C.6030801@joelhalpern.com> Date: Mon, 2 Nov 2015 21:15:32 -0500 Message-ID: <009101d115dd$8668dcf0$933a96d0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJnM+C7uUvbHKk7SEbsRDqJeBdn3ALpIyG9AaP+yswCQcwMUp0m21SA Content-Language: en-us Archived-At: Subject: Re: [i2rs] Ownership and Subscription X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 02:15:39 -0000 > I would indeed expect to use the same mechanisms for delivering the error > notifications as for all other notificaitons. > > And I suppose one could allow a client to unsubscribe from such > notifications. But it actually seems to encourage dangerous behavior to do > so. And adds extra complexity. Can you explain how it adds extra complexity? I can argue it adds more complexity in terms of race conditions/etc. either way, so I don't see a net gain in complexity from the protocol side. What I do see is the option to reduce complexity on the agent side of things by disconnecting the two data stores (?). Again, my entire purpose here is to clarify and simplify, not to make things harder... Complexity always has tradeoffs, though. :-) Russ From nobody Mon Nov 2 18:16:18 2015 Return-Path: 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 A887A1A1AB9 for ; Mon, 2 Nov 2015 18:16:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_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 aAVoVwkUkBRM for ; Mon, 2 Nov 2015 18:16:16 -0800 (PST) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (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 9F3121ACD91 for ; Mon, 2 Nov 2015 18:16:13 -0800 (PST) Received: by lffz202 with SMTP id z202so2589081lff.3 for ; Mon, 02 Nov 2015 18:16:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ocviG6GBgeIEI/ZXbRyT388bnYAEpAgcF5wxVRuEwRY=; b=DFNlPVrbWIy0dD21VeR0wp2abXb0CLuYF/IyjsdJaUFBqAIRYdkO+n7rlwfezJtFQr JEAT5kZsRrPM4kBVPOHWGcTW8UJCaXeXQpZiRSoLCRrD3EMB4Ei+1ofKd5rdgUOPOC+0 S3/wQJ4Kuk3YyJhfAwXcjhc0iwnjH1AF8VzMEFpL6r8FKyGecaYTwi9TUUxB1xxTVbA2 lKKrpnn1MqY355hnXN8227RazmYZWMvFxqvUGVg2SBCtzcpOPxoNNFrClcaJE44sqF4P Sw1V0WA1gQQUwJJEASK343luhgfy+mrZ5TJN6xf3RykUgOvJAD9WDSJiHDjjkRjunPU8 fg3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ocviG6GBgeIEI/ZXbRyT388bnYAEpAgcF5wxVRuEwRY=; b=fqOQZ+FeaHGT4ngXgxFLApfBu48MuGeyhaZCi7QtFWpuAedsIKtOTu9ZszYk3dKObn +6S9LIC8wW9wv5AGSy+fWSKdctdkSL3G33aeZAXNKz5omgLQ4qI7TSPyg0TiNsTRuNvW Cn2KqcUqsaZYoBfyXZDyesklPMTgbjg5dgeBT0fpnGTQCKoNt6JujRpTbIsyBwVikNAB RFM4yC7WEnXp4eTCDmR4VOUptApV/9F7Lsm912UMjt4TZv+10UUTASIzv7N7EZnP7sCO VLvmUnilSwtfZimk0hARA3AhuQJTNwyJL4Crr80/zRUUPekGVBbWebsguLcVQWoTK9pX W6uA== X-Gm-Message-State: ALoCoQl2veiVRmTyTak8YVnzTalYzOtrtVVwGf8DhnfBAWPaO6ibh1EBD1u45KUhzE9hxOChW2GU MIME-Version: 1.0 X-Received: by 10.25.218.135 with SMTP id r129mr7478717lfg.82.1446516971854; Mon, 02 Nov 2015 18:16:11 -0800 (PST) Received: by 10.112.144.106 with HTTP; Mon, 2 Nov 2015 18:16:11 -0800 (PST) In-Reply-To: <56381667.6070606@joelhalpern.com> References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <56380923.1050301@joelhalpern.com> <010b01d115d6$efe1c3b0$cfa54b10$@gmail.com> <56381667.6070606@joelhalpern.com> Date: Mon, 2 Nov 2015 18:16:11 -0800 Message-ID: From: Andy Bierman To: Joel Halpern Direct Content-Type: multipart/alternative; boundary=001a114037e444fa0b0523997a91 Archived-At: Cc: "i2rs@ietf.org" , Russ White <7riw77@gmail.com> Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 02:16:17 -0000 --001a114037e444fa0b0523997a91 Content-Type: text/plain; charset=UTF-8 On Mon, Nov 2, 2015 at 6:05 PM, Joel Halpern Direct < jmh.direct@joelhalpern.com> wrote: > What we side with regard to the atomicity of collisions was that the model > needed to specify that. So if the model writer concludes that the leaves A > and B in your example are so closely coupled that bad things will happen if > different people write different parts, then they can say the container is > the granularity. Usually, I would expect the leaf to be the granularity. > We do not expect the I2RS agent (or the underlying system) to guess the > granularity. > > OK -- so it is part of the data model definition. Good. These are the details wrt/ "first wins" that need to be understood. The WG and proto-dt needs to think about what YANG extensions would be needed to describe these boundaries in machine-usable form. Yours, > Joel > > Andy > On 11/2/15 9:02 PM, Andy Bierman wrote: > >> >> >> On Mon, Nov 2, 2015 at 5:28 PM, Russ White <7riw77@gmail.com >> > wrote: >> >> >> > For example, if state gets over-ridden, but preserved, then even >> though it >> is >> > not doing any good, the client which installed the state must still >> monitor for >> > any related dependenecies so as to not leave incorrect pending >> state. >> > Which also means that a client has to be able to remove state it >> has >> created, >> > even though that state has been over-ridden. And probably has to >> be able >> > to create state which won't take effect. Which in turns means >> that you >> need >> > to be able to read your own effects and the current state >> separately. >> >> I would think this should be a client specific implementation >> detail... I >> don't see why, from a protocol level, it should be disallowed, when >> the >> changes involved would be minor (or at least it seems to me?). >> >> >> I am not sure I understand edit collision processing. >> The proposals is that the ephemeral datastore contains data >> from 1 or more clients. The data from different clients is >> non-overlapping >> (for some definition of that). >> >> I will avoid running config + ephemeral leaf-override for now. >> Assume the data model is entirely for I2RS: >> >> container foo { >> leaf A { type int32; } >> leaf B { type int32; } >> } >> >> 1) client-worst set /foo/A to 42 { "foo": { "A":42 } } >> >> 2) client-best sets /foo/B to 7 { "foo": { "B":7 } } >> >> 3) Is client-best going to knock out data owned by client-worst? >> what happens to /foo/A? >> >> Q1) Is this a collision because /foo is written by both clients? >> if not, does client-best own /foo and /foo/A, and client-worst owns >> /foo/B? >> If yes, then step (2) is effectively a PUT, no matter what method is >> really used >> >> Q2) what notifications are sent to client-worst, if any (depending on >> answer to Q1) >> (client-worst either lost ownership of /foo or /foo and /foo/A) >> >> Consider that A and B can be arbitrary subtrees, not just leafs. >> >> How are the edit collision boundaries specified? >> Simple YANG overlap will cause lots of deletions. >> More granular/complex boundary specification would help >> avoid such deletions where the 2 clients could actually co-exist. >> >> >> :-) >> >> Russ >> >> >> >> Andy >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> >> >> --001a114037e444fa0b0523997a91 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Nov 2, 2015 at 6:05 PM, Joel Halpern Direct &= lt;jmh.dire= ct@joelhalpern.com> wrote:
= What we side with regard to the atomicity of collisions was that the model = needed to specify that.=C2=A0 So if the model writer concludes that the lea= ves A and B in your example are so closely coupled that bad things will hap= pen if different people write different parts, then they can say the contai= ner is the granularity.=C2=A0 Usually, I would expect the leaf to be the gr= anularity.=C2=A0 We do not expect the I2RS agent (or the underlying system)= to guess the granularity.


OK -- so it is part of the data model = definition.=C2=A0 Good.
These are the details wrt/ "first wi= ns" that need to be understood.
The WG and proto-dt needs to= think about what YANG extensions would be needed
to describe the= se boundaries in machine-usable form.

Yours,
Joel


Andy
=C2=A0
On 11/2/15 9:02 PM, Andy Bierman wrote:


On Mon, Nov 2, 2015 at 5:28 PM, Russ White <7riw77@gmail.com
<mailto:7riw77@gma= il.com>> wrote:


=C2=A0 =C2=A0 =C2=A0> For example, if state gets over-ridden, but preser= ved, then even
=C2=A0 =C2=A0 though it
=C2=A0 =C2=A0 is
=C2=A0 =C2=A0 =C2=A0> not doing any good, the client which installed the= state must still
=C2=A0 =C2=A0 monitor for
=C2=A0 =C2=A0 =C2=A0> any related dependenecies so as to not leave incor= rect pending state.
=C2=A0 =C2=A0 =C2=A0> Which also means that a client has to be able to r= emove state it has
=C2=A0 =C2=A0 created,
=C2=A0 =C2=A0 =C2=A0> even though that state has been over-ridden.=C2=A0= And probably has to
=C2=A0 =C2=A0 be able
=C2=A0 =C2=A0 =C2=A0> to create state which won't take effect.=C2=A0= Which in turns means
=C2=A0 =C2=A0 that you
=C2=A0 =C2=A0 need
=C2=A0 =C2=A0 =C2=A0> to be able to read your own effects and the curren= t state separately.

=C2=A0 =C2=A0 I would think this should be a client specific implementation=
=C2=A0 =C2=A0 detail... I
=C2=A0 =C2=A0 don't see why, from a protocol level, it should be disall= owed, when the
=C2=A0 =C2=A0 changes involved would be minor (or at least it seems to me?)= .


I am not sure I understand edit collision processing.
The proposals is that the ephemeral datastore contains data
from 1 or more clients.=C2=A0 The data from different clients is non-overla= pping
(for some definition of that).

I will avoid running config + ephemeral leaf-override for now.
Assume the data model is entirely for I2RS:

=C2=A0 =C2=A0container foo {
=C2=A0 =C2=A0 =C2=A0 leaf A { type int32; }
=C2=A0 =C2=A0 =C2=A0 leaf B { type int32; }
=C2=A0 =C2=A0}

1) client-worst set /foo/A to 42=C2=A0 =C2=A0 { "foo": { "A&= quot;:42 } }

2) client-best sets /foo/B to 7=C2=A0 =C2=A0 =C2=A0 =C2=A0{ "foo"= : { "B":7 } }

3) Is client-best going to knock out data owned by client-worst?
=C2=A0 =C2=A0 what happens to /foo/A?

Q1) Is this a collision because /foo is written by both clients?
=C2=A0 =C2=A0if not, does client-best own /foo and /foo/A, and client-worst= owns
/foo/B?
=C2=A0 =C2=A0If yes, then step (2) is effectively a PUT, no matter what met= hod is
really used

Q2) what notifications are sent to client-worst, if any (depending on
answer to Q1)
(client-worst either lost ownership of /foo or /foo and /foo/A)

Consider that A and B can be arbitrary subtrees, not just leafs.

How are the edit collision boundaries specified?
Simple YANG overlap will cause lots of deletions.
More granular/complex boundary specification would help
avoid such deletions where the 2 clients could actually co-exist.


=C2=A0 =C2=A0 :-)

=C2=A0 =C2=A0 Russ



Andy

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 i2rs mailing list
=C2=A0 =C2=A0 i2rs@ietf.= org <mailto:i2rs@= ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/i2rs



--001a114037e444fa0b0523997a91-- From nobody Mon Nov 2 20:12:33 2015 Return-Path: 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 C59B01B2CED for ; Mon, 2 Nov 2015 20:12:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_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 RlG6EKUimbA5 for ; Mon, 2 Nov 2015 20:12:29 -0800 (PST) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (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 1F98D1B2CEA for ; Mon, 2 Nov 2015 20:12:29 -0800 (PST) Received: by lfbn126 with SMTP id n126so4363464lfb.2 for ; Mon, 02 Nov 2015 20:12:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BSna+/zIxDUmU6Sage/vcIth89nKJwbXZzd9oAjCmc8=; b=KJGwZX8cUzqspcXuh78nrj/B2Zk232m+AAWsxUOpGqOSJ1VAAIRodpzvYeMRcKsww5 63GogVBD+WtXeZiMVK7REN1IKNqE+H6toIuv/tDXPiSt7z19y1ap1HfjAQ9ai7dRql9N NsOppLp1gahwAxrs0iSFH+Qo22GLvJ3GI7tP+zhPwj8hnZ7/0FqYikxmL99Stf/+QDK8 p4hjWkVHOAlqxl24/MMsc93XqQ545zHA4jVnV402JUYxbnQxyQHwvzHQyLRsFrdPoEDV 2BdMohFufaNYPM8D1Y/ogvGo+tMhlsEGsyDBF3rFLbzvy/0vkyxEWqjAFmjc1dygnFtq /URg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BSna+/zIxDUmU6Sage/vcIth89nKJwbXZzd9oAjCmc8=; b=A+g2MbsgA2chG9NitlA3t629oxyN8+AaQ3p5tA+TSZXd8L2WzRzmtQOVikrEezOOqD MZRs+yxlBgQV1PyRne3UQ899cVjT4dMYr3LZG4/SecQ1is5y55QVLDr64ZJntVdYtoz6 twy1zxVpeRiRCbpYUAuXGn7/gTfbvBbTTX6D0eU6ujSDjK2+9w9kteJq1gI6D4cb4EIO JuFMuNKt7MLa7PkP/+fV7ltEB8Da/VAs4IzvM+1+H5qij5q0cSrjZFHS9FF3LeZB4vt+ LHw0Ul9uvHdLdrIQ+Id28NeNahnFAY/56Xcyy49BYFqPhawcw+wAgpY0UY78uNzaPNNJ wQEQ== X-Gm-Message-State: ALoCoQlkD42byuQMd/qIDUSwS/8P7Fst7eKOPKlizTPOOUkWLaqDN4GezeNGMEz2uFHVKmA/Dyd1 MIME-Version: 1.0 X-Received: by 10.25.44.15 with SMTP id s15mr7508638lfs.37.1446523947164; Mon, 02 Nov 2015 20:12:27 -0800 (PST) Received: by 10.112.144.106 with HTTP; Mon, 2 Nov 2015 20:12:27 -0800 (PST) In-Reply-To: <56381667.6070606@joelhalpern.com> References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <56380923.1050301@joelhalpern.com> <010b01d115d6$efe1c3b0$cfa54b10$@gmail.com> <56381667.6070606@joelhalpern.com> Date: Mon, 2 Nov 2015 20:12:27 -0800 Message-ID: From: Andy Bierman To: Joel Halpern Direct Content-Type: multipart/alternative; boundary=001a11403c5c07c30b05239b1a7a Archived-At: Cc: "i2rs@ietf.org" , Russ White <7riw77@gmail.com> Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 04:12:32 -0000 --001a11403c5c07c30b05239b1a7a Content-Type: text/plain; charset=UTF-8 On Mon, Nov 2, 2015 at 6:05 PM, Joel Halpern Direct < jmh.direct@joelhalpern.com> wrote: > What we side with regard to the atomicity of collisions was that the model > needed to specify that. So if the model writer concludes that the leaves A > and B in your example are so closely coupled that bad things will happen if > different people write different parts, then they can say the container is > the granularity. Usually, I would expect the leaf to be the granularity. > We do not expect the I2RS agent (or the underlying system) to guess the > granularity. > > It is 1 thing to just declare this feature in the architecture and quite another to get it to work with real YANG. In fact, there is no 1 "data model". There is an ever-growing set of modules, with various forms and degrees of inter-dependence. Dean's draft does a good job of explaining these module types: https://tools.ietf.org/html/draft-bogdanovic-netmod-yang-model-classification-05 We cannot just assume that data nodes in different modules do not interact and cause a conflict. Quite the opposite, since a common data modeling practice is to create a framework and a set of augmenting modules for that framework. It is OK if there are different levels of interoperability expectations. Some details can be mandatory, some left for future work, some specifically left to the server implementation. This level of detail is still very TBD. Yours, > Joel > Andy > > On 11/2/15 9:02 PM, Andy Bierman wrote: > >> >> >> On Mon, Nov 2, 2015 at 5:28 PM, Russ White <7riw77@gmail.com >> > wrote: >> >> >> > For example, if state gets over-ridden, but preserved, then even >> though it >> is >> > not doing any good, the client which installed the state must still >> monitor for >> > any related dependenecies so as to not leave incorrect pending >> state. >> > Which also means that a client has to be able to remove state it >> has >> created, >> > even though that state has been over-ridden. And probably has to >> be able >> > to create state which won't take effect. Which in turns means >> that you >> need >> > to be able to read your own effects and the current state >> separately. >> >> I would think this should be a client specific implementation >> detail... I >> don't see why, from a protocol level, it should be disallowed, when >> the >> changes involved would be minor (or at least it seems to me?). >> >> >> I am not sure I understand edit collision processing. >> The proposals is that the ephemeral datastore contains data >> from 1 or more clients. The data from different clients is >> non-overlapping >> (for some definition of that). >> >> I will avoid running config + ephemeral leaf-override for now. >> Assume the data model is entirely for I2RS: >> >> container foo { >> leaf A { type int32; } >> leaf B { type int32; } >> } >> >> 1) client-worst set /foo/A to 42 { "foo": { "A":42 } } >> >> 2) client-best sets /foo/B to 7 { "foo": { "B":7 } } >> >> 3) Is client-best going to knock out data owned by client-worst? >> what happens to /foo/A? >> >> Q1) Is this a collision because /foo is written by both clients? >> if not, does client-best own /foo and /foo/A, and client-worst owns >> /foo/B? >> If yes, then step (2) is effectively a PUT, no matter what method is >> really used >> >> Q2) what notifications are sent to client-worst, if any (depending on >> answer to Q1) >> (client-worst either lost ownership of /foo or /foo and /foo/A) >> >> Consider that A and B can be arbitrary subtrees, not just leafs. >> >> How are the edit collision boundaries specified? >> Simple YANG overlap will cause lots of deletions. >> More granular/complex boundary specification would help >> avoid such deletions where the 2 clients could actually co-exist. >> >> >> :-) >> >> Russ >> >> >> >> Andy >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> >> >> --001a11403c5c07c30b05239b1a7a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Nov 2, 2015 at 6:05 PM, Joel Halpern Direct &= lt;jmh.dire= ct@joelhalpern.com> wrote:
What we side w= ith regard to the atomicity of collisions was that the model needed to spec= ify that.=C2=A0 So if the model writer concludes that the leaves A and B in= your example are so closely coupled that bad things will happen if differe= nt people write different parts, then they can say the container is the gra= nularity.=C2=A0 Usually, I would expect the leaf to be the granularity.=C2= =A0 We do not expect the I2RS agent (or the underlying system) to guess the= granularity.



It is 1 thing to just d= eclare this feature in the architecture and quite another
to get = it to work with real YANG.=C2=A0 In fact, there is no 1 "data model&qu= ot;.
There is an ever-growing set of modules, with various forms = and degrees
of inter-dependence.

Dean= 9;s draft does a good job of explaining these module types:

We cannot just assume that = data nodes in different modules do not interact
and cause a confl= ict.=C2=A0 Quite the opposite, since a common data modeling
pract= ice is to create a framework and a set of augmenting modules for
= that framework.

It is OK if there are different le= vels of interoperability expectations.
Some details can be mandat= ory, some left for future work,
some specifically left to the ser= ver implementation.
This level of detail is still very TBD.
=


Yours,
Joel


Andy

=
=C2=A0

On 11/2/15 9:02 PM, Andy Bierman wrote:


On Mon, Nov 2, 2015 at 5:28 PM, Russ White <7riw77@gmail.com
<mailto:7riw77@gma= il.com>> wrote:


=C2=A0 =C2=A0 =C2=A0> For example, if state gets over-ridden, but preser= ved, then even
=C2=A0 =C2=A0 though it
=C2=A0 =C2=A0 is
=C2=A0 =C2=A0 =C2=A0> not doing any good, the client which installed the= state must still
=C2=A0 =C2=A0 monitor for
=C2=A0 =C2=A0 =C2=A0> any related dependenecies so as to not leave incor= rect pending state.
=C2=A0 =C2=A0 =C2=A0> Which also means that a client has to be able to r= emove state it has
=C2=A0 =C2=A0 created,
=C2=A0 =C2=A0 =C2=A0> even though that state has been over-ridden.=C2=A0= And probably has to
=C2=A0 =C2=A0 be able
=C2=A0 =C2=A0 =C2=A0> to create state which won't take effect.=C2=A0= Which in turns means
=C2=A0 =C2=A0 that you
=C2=A0 =C2=A0 need
=C2=A0 =C2=A0 =C2=A0> to be able to read your own effects and the curren= t state separately.

=C2=A0 =C2=A0 I would think this should be a client specific implementation=
=C2=A0 =C2=A0 detail... I
=C2=A0 =C2=A0 don't see why, from a protocol level, it should be disall= owed, when the
=C2=A0 =C2=A0 changes involved would be minor (or at least it seems to me?)= .


I am not sure I understand edit collision processing.
The proposals is that the ephemeral datastore contains data
from 1 or more clients.=C2=A0 The data from different clients is non-overla= pping
(for some definition of that).

I will avoid running config + ephemeral leaf-override for now.
Assume the data model is entirely for I2RS:

=C2=A0 =C2=A0container foo {
=C2=A0 =C2=A0 =C2=A0 leaf A { type int32; }
=C2=A0 =C2=A0 =C2=A0 leaf B { type int32; }
=C2=A0 =C2=A0}

1) client-worst set /foo/A to 42=C2=A0 =C2=A0 { "foo": { "A&= quot;:42 } }

2) client-best sets /foo/B to 7=C2=A0 =C2=A0 =C2=A0 =C2=A0{ "foo"= : { "B":7 } }

3) Is client-best going to knock out data owned by client-worst?
=C2=A0 =C2=A0 what happens to /foo/A?

Q1) Is this a collision because /foo is written by both clients?
=C2=A0 =C2=A0if not, does client-best own /foo and /foo/A, and client-worst= owns
/foo/B?
=C2=A0 =C2=A0If yes, then step (2) is effectively a PUT, no matter what met= hod is
really used

Q2) what notifications are sent to client-worst, if any (depending on
answer to Q1)
(client-worst either lost ownership of /foo or /foo and /foo/A)

Consider that A and B can be arbitrary subtrees, not just leafs.

How are the edit collision boundaries specified?
Simple YANG overlap will cause lots of deletions.
More granular/complex boundary specification would help
avoid such deletions where the 2 clients could actually co-exist.


=C2=A0 =C2=A0 :-)

=C2=A0 =C2=A0 Russ



Andy

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 i2rs mailing list
=C2=A0 =C2=A0 i2rs@ietf.= org <mailto:i2rs@= ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/i2rs



--001a11403c5c07c30b05239b1a7a-- From nobody Mon Nov 2 20:32:27 2015 Return-Path: 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 6DDEA1B2D72 for ; Mon, 2 Nov 2015 20:32:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.055 X-Spam-Level: X-Spam-Status: No, score=-99.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] 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 mRcKRkh2wUMC for ; Mon, 2 Nov 2015 20:32:23 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDAA01B2D7F for ; Mon, 2 Nov 2015 20:32:22 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=133.93.24.48; From: "Susan Hares" To: "'Russ White'" <7riw77@gmail.com>, References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> In-Reply-To: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> Date: Mon, 2 Nov 2015 23:32:18 -0500 Message-ID: <001601d115f0$a0ebb030$e2c31090$@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: AQLwMtmz+XLO8+uQ7j5WaenA2rWXR5xLevLA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 04:32:24 -0000 Russ thank you for kicking off this discussion. It is an interesting approach. I know that certain RIB implementations allows a back-up route. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Russ White Sent: Monday, November 02, 2015 7:39 PM To: i2rs@ietf.org Subject: [i2rs] Conversation on Priority and Panes Y'all -- After sleeping on the discussion last night, I think the panes of glass (or is it pains of glass?? :-) ) is still by and large another expression of the priority concept within I2RS. The concept does bring up one specific point of interest, however -- what about backup information? Some vendor RIBs, for instance, allow a routing process to install not only the best path as calculated by the process -- but if the process fails to install, some RIB implementations allow the process to place the route in the "backup pool." This allows the local RIB process to drop to the "second best path," in terms of priority, so the local RIB doesn't need to query the routing processes to switch in the case of a withdraw or change in topology. To convert this to I2RS terms, it does seem worthwhile to me to have the capability for a local agent to accept an install instruction for some particular ephemeral state, and if the install fails, to hold that state for future use. This would apply to any sort of ephemeral data, including that which is configured locally on the network device. Rather than trying to think of this as "panes of glass," though, this would convert it to simply a backup list of lower priority items the local agent can use in the case of the failure of the highest priority item currently in use. The nice thing about this view is that it doesn't require a lot of changes at the protocol level. The only thing that needs to be available is the option for an agent to send three different types of answers to an install request -- 1. This ephemeral state was installed and is now being used. 2. This ephemeral state was rejected/not installed -- with potential codes for why (out of range parameter, etc.) 3. This ephemeral state was not installed, but is being held as a backup. Using these semantics, the actual implementation of such a feature is up to the local agent. It might be that some agents don't know how to hold backup information, or that it doesn't make any sense to hold some sorts of information in a backup list. This is fine -- the install can just be rejected without further note. Locally configured information could simply be treated as an item on the backup list, such that the priorities can be considered as always in deciding what to install when any particular action is taken. It seems, to me, that this is a simpler way to consider the same problem set, and reduces to an actual protocol mechanism that appears (?) to be fairly simple, and leaves as much flexibility as possible for any given agent implementation. Thoughts? :-) Russ _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue Nov 3 15:14:55 2015 Return-Path: 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 C8F341B35BF for ; Tue, 3 Nov 2015 15:14:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_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 6Tx4d51_XazX for ; Tue, 3 Nov 2015 15:14:51 -0800 (PST) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (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 008451B35BE for ; Tue, 3 Nov 2015 15:14:50 -0800 (PST) Received: by lfbn126 with SMTP id n126so32726387lfb.2 for ; Tue, 03 Nov 2015 15:14:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kuUIAcm7WESzbj7r+hdOzfPxW6YbKwrBIlVotiyd0Fw=; b=zgTBst7tHafE4YvRvoJXUKFFLdB9TZS6JrJucr6IAekHpQ1V0q7UuP5SW8a2Z6/YZQ VpGNPebyHnUqit5bZ00o6q8xH/q6pCt1ToVaLhbmVEUtWHRcNeIXA3puA/WtcQNwjoSO FtZ1SZ81w7oSwOfaLpWE5ZiuSFluKEw/abWMSIGirLnhhspZiU8k3Q9fSUrD2l6CBzO7 VPo4WpMQaf8XbsU+J20sFfxbYeZI2GDhHacJB4wyRsVvBmK1mqXENoZXANOTtiuA1YF8 7/pwXYTtFQ+0hiR8uLghe89Rf6AZ+10QEf3fJnOqpOAixFB7LCN0dyorQVEDAmMFNAZk HmsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=kuUIAcm7WESzbj7r+hdOzfPxW6YbKwrBIlVotiyd0Fw=; b=XGX2q9aDQvt4l6lnUThBAw1lFnuGfxXbj7BarT4SQUvnDlSyN+7iIPQZXCW1ls4eK7 wprL0bwJGXs/ia7XX+UNE7k8xh1LsBdJbmKi8CsQL95fpn/mkg23P7PewqfCa1tcet4F aAo5BXRmUdj0IuNNCWuuLogJlYLTZyLnaWXg4o0kuWILhrLGjh3bknNutFscJwmxmspE FDLK/U8xUZLM710YKdm2KmpM01TnCBP5LxIYXbWoEKbPKX+7r8M7WkjM9Xr94gvyZQEO LKbd+OMABnpv7SIcj1/nuGrS/5lfobDFsEcmSDMi188ImfLrhND3IhtYdV7VpnsHqqE6 4ENw== X-Gm-Message-State: ALoCoQmDDls0ZaJEADaLmEL9UBeAHBCFdgODtgJ6Fc69X9Xv2m4a+LC9QVDGkn8n4LVaVqsHhWWh MIME-Version: 1.0 X-Received: by 10.25.153.18 with SMTP id b18mr9551226lfe.33.1446592488978; Tue, 03 Nov 2015 15:14:48 -0800 (PST) Received: by 10.112.144.106 with HTTP; Tue, 3 Nov 2015 15:14:48 -0800 (PST) In-Reply-To: <001601d115f0$a0ebb030$e2c31090$@ndzh.com> References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> Date: Tue, 3 Nov 2015 15:14:48 -0800 Message-ID: From: Andy Bierman To: Susan Hares Content-Type: multipart/alternative; boundary=001a114730c070d3b40523ab0fc0 Archived-At: Cc: "i2rs@ietf.org" , Russ White <7riw77@gmail.com> Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 23:14:53 -0000 --001a114730c070d3b40523ab0fc0 Content-Type: text/plain; charset=UTF-8 Hi, This raises a data modeling issue. Should every "backup parameter" be modeled explicitly in the YANG module, or can the ephemeral datastore be used for that, without any additional data model objects? The I2RS architecture supports this "backup" concept (lower priority client), except it requires a notification from the agent and subsequent request from the client to make the backup active. With NETCONF or RESTCONF today, that round-trip will probably take around 500 to 1000 milli-seconds. Probably much worse during high loads. Our original proposal to the design team included a pane of glass for each client (and unique priorities for each client), because some people were talking about sub-milli-sec latency, and I know there is no way NETCONF or RESTCONF is going to support this sort of tight control loop. Whether the server rejects lower-priority edits right away, or whether the agent caches the request in the form of a client-specific pane, the client still needs to observe the data resources with pub/sub and decide whether its own particular state is still relevant. IMO the client complexity is the same either way, especially since the caching is only done if the client requests it. The only difference is likely to be almost a million times faster fail-over to the backup on the server. Andy On Mon, Nov 2, 2015 at 8:32 PM, Susan Hares wrote: > Russ thank you for kicking off this discussion. It is an interesting > approach. I know that certain RIB implementations allows a back-up route. > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Russ White > Sent: Monday, November 02, 2015 7:39 PM > To: i2rs@ietf.org > Subject: [i2rs] Conversation on Priority and Panes > > Y'all -- > > After sleeping on the discussion last night, I think the panes of glass (or > is it pains of glass?? :-) ) is still by and large another expression of > the priority concept within I2RS. The concept does bring up one specific > point of interest, however -- what about backup information? Some vendor > RIBs, for instance, allow a routing process to install not only the best > path as calculated by the process -- but if the process fails to install, > some RIB implementations allow the process to place the route in the > "backup > pool." This allows the local RIB process to drop to the "second best path," > in terms of priority, so the local RIB doesn't need to query the routing > processes to switch in the case of a withdraw or change in topology. > > To convert this to I2RS terms, it does seem worthwhile to me to have the > capability for a local agent to accept an install instruction for some > particular ephemeral state, and if the install fails, to hold that state > for > future use. This would apply to any sort of ephemeral data, including that > which is configured locally on the network device. Rather than trying to > think of this as "panes of glass," though, this would convert it to simply > a > backup list of lower priority items the local agent can use in the case of > the failure of the highest priority item currently in use. > > The nice thing about this view is that it doesn't require a lot of changes > at the protocol level. The only thing that needs to be available is the > option for an agent to send three different types of answers to an install > request -- > > 1. This ephemeral state was installed and is now being used. > 2. This ephemeral state was rejected/not installed -- with potential codes > for why (out of range parameter, etc.) 3. This ephemeral state was not > installed, but is being held as a backup. > > Using these semantics, the actual implementation of such a feature is up to > the local agent. It might be that some agents don't know how to hold backup > information, or that it doesn't make any sense to hold some sorts of > information in a backup list. This is fine -- the install can just be > rejected without further note. Locally configured information could simply > be treated as an item on the backup list, such that the priorities can be > considered as always in deciding what to install when any particular action > is taken. > > It seems, to me, that this is a simpler way to consider the same problem > set, and reduces to an actual protocol mechanism that appears (?) to be > fairly simple, and leaves as much flexibility as possible for any given > agent implementation. > > Thoughts? > > :-) > > Russ > > _______________________________________________ > 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 > --001a114730c070d3b40523ab0fc0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

This raises a data modeling issue.<= /div>
Should every "backup parameter" be modeled explicitly i= n
the YANG module, or can the ephemeral datastore be used
for that, without any additional data model objects?

The I2RS architecture supports this "backup" concept (lower= priority client),
except it requires a notification from the age= nt and subsequent request
from the client to make the backup acti= ve.=C2=A0 With NETCONF or RESTCONF
today, that round-trip will pr= obably take around =C2=A0500 to 1000 milli-seconds.
Probably much= worse during high loads.

Our original propos= al to the design team included a pane of glass
for each client (a= nd unique priorities for each client), because some people
= were talking about sub-milli-sec latency, and I know there is no way NETCON= F
or RESTCONF is going to support this sort of tight control loop= .

Whether the server rejects lower-priority edits = right away, or whether
the agent caches the request in the form o= f a client-specific pane,
the client still needs to observe the d= ata resources with pub/sub
and decide whether its own particular = state is still relevant.
IMO the client complexity is the same ei= ther way, especially
since the caching is only done if the client= requests it.

The only difference is likely to be = almost a million times faster
fail-over to the backup on the serv= er.


Andy

<= br>


On Mon, Nov 2, 2015 at 8:32 PM, Susan Hares = <shares@ndzh.com> wrote:
Russ thank you for ki= cking off this discussion.=C2=A0 It is an interesting
approach. I know that certain RIB implementations allows a back-up route.
Sue

-----Original Message-----
From: i2rs [mailto:i2rs-bounces@ie= tf.org] On Behalf Of Russ White
Sent: Monday, November 02, 2015 7:39 PM
To: i2rs@ietf.org
Subject: [i2rs] Conversation on Priority and Panes

Y'all --

After sleeping on the discussion last night, I think the panes of glass (or=
is it pains of glass?? :-)=C2=A0 ) is still by and large another expression= of
the priority concept within I2RS. The concept does bring up one specific point of interest, however -- what about backup information? Some vendor RIBs, for instance, allow a routing process to install not only the best path as calculated by the process -- but if the process fails to install, some RIB implementations allow the process to place the route in the "= backup
pool." This allows the local RIB process to drop to the "second b= est path,"
in terms of priority, so the local RIB doesn't need to query the routin= g
processes to switch in the case of a withdraw or change in topology.

To convert this to I2RS terms, it does seem worthwhile to me to have the capability for a local agent to accept an install instruction for some
particular ephemeral state, and if the install fails, to hold that state fo= r
future use. This would apply to any sort of ephemeral data, including that<= br> which is configured locally on the network device. Rather than trying to think of this as "panes of glass," though, this would convert it = to simply a
backup list of lower priority items the local agent can use in the case of<= br> the failure of the highest priority item currently in use.

The nice thing about this view is that it doesn't require a lot of chan= ges
at the protocol level. The only thing that needs to be available is the
option for an agent to send three different types of answers to an install<= br> request --

1. This ephemeral state was installed and is now being used.
2. This ephemeral state was rejected/not installed -- with potential codes<= br> for why (out of range parameter, etc.) 3. This ephemeral state was not
installed, but is being held as a backup.

Using these semantics, the actual implementation of such a feature is up to=
the local agent. It might be that some agents don't know how to hold ba= ckup
information, or that it doesn't make any sense to hold some sorts of information in a backup list. This is fine -- the install can just be
rejected without further note. Locally configured information could simply<= br> be treated as an item on the backup list, such that the priorities can be considered as always in deciding what to install when any particular action=
is taken.

It seems, to me, that this is a simpler way to consider the same problem set, and reduces to an actual protocol mechanism that appears (?) to be
fairly simple, and leaves as much flexibility as possible for any given
agent implementation.

Thoughts?

:-)

Russ

_______________________________________________
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

--001a114730c070d3b40523ab0fc0-- From nobody Tue Nov 3 15:49:14 2015 Return-Path: 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 DC4051B360D for ; Tue, 3 Nov 2015 15:49:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 rvgbjW1rjuem for ; Tue, 3 Nov 2015 15:49:10 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4A071ACE16 for ; Tue, 3 Nov 2015 15:49:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id CF1621C01B0; Tue, 3 Nov 2015 15:49:10 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (122x210x83x163.ap122.ftth.ucom.ne.jp [122.210.83.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 03BED1C0136; Tue, 3 Nov 2015 15:49:09 -0800 (PST) To: Andy Bierman , Susan Hares References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> From: "Joel M. Halpern" Message-ID: <563947F3.10805@joelhalpern.com> Date: Tue, 3 Nov 2015 18:49:07 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "i2rs@ietf.org" , Russ White <7riw77@gmail.com> Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 23:49:13 -0000 The basic problem I have with your description is that it treats over-writes as normal and desirable, and assumes that the priority handling is producing the correct results. If we actually believed that, I suppose making them more efficient would be sensible. But that is not actually what we are doing. Priority over-write is a disambiguation mechanism. There is no expectation that it is even a good heuristic for correctness. It is merely predictable. Trying to optimize the control loop for cases of improper behavior seems the wrong place to optimize. Having said that, if we want to get into multiple panes of ephemeral glass then we are going to need mechanisms to read the composite effect read what I as a client have applied indicate in the response to a write request that the agent has accepted the request, even though it is not actually taking effect. And if we do all that, clients whose state is pending will need to maintain monitoring of all related activities even though their network application is not in effect. And, if there are multiple aspect of an operation, if one gets over-written but retained, then the client probably can't leave it there, but has to go in and remove that state, since the client will likely be removing the rest of the related state that is still sitting there with its lynchpin missing. And then we get into the question of how much unapplied state is an agent going to store. So it all probability the client still has to be prepared for being told that not only was its state over-written (which is technically an error) but that it got deleted too. Yours, Joel On 11/3/15 6:14 PM, Andy Bierman wrote: > Hi, > > This raises a data modeling issue. > Should every "backup parameter" be modeled explicitly in > the YANG module, or can the ephemeral datastore be used > for that, without any additional data model objects? > > The I2RS architecture supports this "backup" concept (lower priority > client), > except it requires a notification from the agent and subsequent request > from the client to make the backup active. With NETCONF or RESTCONF > today, that round-trip will probably take around 500 to 1000 milli-seconds. > Probably much worse during high loads. > > Our original proposal to the design team included a pane of glass > for each client (and unique priorities for each client), because some people > were talking about sub-milli-sec latency, and I know there is no way NETCONF > or RESTCONF is going to support this sort of tight control loop. > > Whether the server rejects lower-priority edits right away, or whether > the agent caches the request in the form of a client-specific pane, > the client still needs to observe the data resources with pub/sub > and decide whether its own particular state is still relevant. > IMO the client complexity is the same either way, especially > since the caching is only done if the client requests it. > > The only difference is likely to be almost a million times faster > fail-over to the backup on the server. > > > Andy > > > > > On Mon, Nov 2, 2015 at 8:32 PM, Susan Hares > wrote: > > Russ thank you for kicking off this discussion. It is an interesting > approach. I know that certain RIB implementations allows a back-up > route. > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org > ] On Behalf Of Russ White > Sent: Monday, November 02, 2015 7:39 PM > To: i2rs@ietf.org > Subject: [i2rs] Conversation on Priority and Panes > > Y'all -- > > After sleeping on the discussion last night, I think the panes of > glass (or > is it pains of glass?? :-) ) is still by and large another > expression of > the priority concept within I2RS. The concept does bring up one specific > point of interest, however -- what about backup information? Some vendor > RIBs, for instance, allow a routing process to install not only the best > path as calculated by the process -- but if the process fails to > install, > some RIB implementations allow the process to place the route in the > "backup > pool." This allows the local RIB process to drop to the "second best > path," > in terms of priority, so the local RIB doesn't need to query the routing > processes to switch in the case of a withdraw or change in topology. > > To convert this to I2RS terms, it does seem worthwhile to me to have the > capability for a local agent to accept an install instruction for some > particular ephemeral state, and if the install fails, to hold that > state for > future use. This would apply to any sort of ephemeral data, > including that > which is configured locally on the network device. Rather than trying to > think of this as "panes of glass," though, this would convert it to > simply a > backup list of lower priority items the local agent can use in the > case of > the failure of the highest priority item currently in use. > > The nice thing about this view is that it doesn't require a lot of > changes > at the protocol level. The only thing that needs to be available is the > option for an agent to send three different types of answers to an > install > request -- > > 1. This ephemeral state was installed and is now being used. > 2. This ephemeral state was rejected/not installed -- with potential > codes > for why (out of range parameter, etc.) 3. This ephemeral state was not > installed, but is being held as a backup. > > Using these semantics, the actual implementation of such a feature > is up to > the local agent. It might be that some agents don't know how to hold > backup > information, or that it doesn't make any sense to hold some sorts of > information in a backup list. This is fine -- the install can just be > rejected without further note. Locally configured information could > simply > be treated as an item on the backup list, such that the priorities > can be > considered as always in deciding what to install when any particular > action > is taken. > > It seems, to me, that this is a simpler way to consider the same problem > set, and reduces to an actual protocol mechanism that appears (?) to be > fairly simple, and leaves as much flexibility as possible for any given > agent implementation. > > Thoughts? > > :-) > > Russ > > _______________________________________________ > 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 > From nobody Tue Nov 3 22:58:17 2015 Return-Path: <7riw77@gmail.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 E12281A00A0 for ; Tue, 3 Nov 2015 22:58:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_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 Jr-3GvBl2D00 for ; Tue, 3 Nov 2015 22:58:15 -0800 (PST) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (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 3248F1AD0AB for ; Tue, 3 Nov 2015 22:58:15 -0800 (PST) Received: by padhx2 with SMTP id hx2so36080124pad.1 for ; Tue, 03 Nov 2015 22:58:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=KJSYJ0qcaBu2Yp9DQK/M00+gmop50GR565V9Lm41pVA=; b=orx1a4sBOnPW2fjzqk8zHD66OCA9KueX8nDCFUxa3RmWM7KZOOSw2owWlkxoFH+Zb9 mGoA+uL7I/l1FeEqzrUZ7goXE25W48uMGmkAjC6FLrVBFvGvSIBVB+zJoEenp2Mu6L/T oUAt1GBGxMXfOw+9xoFKwxb8KMDqXs603DZE7W7diRbcqN9tpLsHoRPvxpbunQn+OcLL C95flhBHH95RmTT7Xtz4p+WeuZDsouHZbB/6fxCkoTMka76AxYxsExlhtB4btOjIcNgD FcNyXSIfY+xEN4nNSa21Y1A5juluc8N+1du8WVn2HIpGeEIGXYp8sj1yLvJ+3RoepO/p I9Sw== X-Received: by 10.66.216.101 with SMTP id op5mr39414959pac.71.1446620294901; Tue, 03 Nov 2015 22:58:14 -0800 (PST) Received: from Russ (dhcp-70-145.meeting.ietf94.jp. [133.93.70.145]) by smtp.gmail.com with ESMTPSA id ea1sm8126829pbb.76.2015.11.03.22.58.13 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Nov 2015 22:58:14 -0800 (PST) From: "Russ White" <7riw77@gmail.com> To: "'Joel M. Halpern'" , "'Andy Bierman'" , "'Susan Hares'" References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> In-Reply-To: <563947F3.10805@joelhalpern.com> Date: Wed, 4 Nov 2015 01:57:44 -0500 Message-ID: <013d01d116ce$2b07caa0$81175fe0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLwMtmz+XLO8+uQ7j5WaenA2rWXRwHVfCJTAW3ySwACzWyr4JwcrU/Q Content-Language: en-us Archived-At: Cc: i2rs@ietf.org Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 06:58:17 -0000 > The basic problem I have with your description is that it treats over-writes as > normal and desirable, and assumes that the priority handling is producing > the correct results. If we actually believed that, I suppose making them > more efficient would be sensible. After talking to Jeff a bit, I actually think we're probably trying to solve two different sets of problems in the same set of documents... The original idea of a "tight loop to the RIB" is sharing space here with a longer term, more static (but ephemeral) idea. It might be better if we actually split these two sets of requirements up. In the "tight loop to the RIB" case (represented by every use case I original put in the doc's I originally presented at the beginning of the WG), I'm pretty certain overwrites by multiple clients with callbacks in a very short time period are going to be a normal case -- two processes installing the same prefix in the RIB is a common situation in normal routing, and, in fact, something I would expect. Think of the case where a flow or destination needs to be redirected for some short period of time, and then traffic rerouted back to the pre-existing path, particularly in cases like software defined perimeter, or putting the user on a dead end network so they can only reach an authentication server, or redirecting a flow temporarily for traffic engineering purposes -- all of these could include entries that last under a second in the table. The "ephemeral configuration" situation is more akin to a static route -- if there are two, there's probably some error (perhaps). In reality, I've configured many pairs of static routes over the years such that if the first next hop is pulled from the table, the second next hop should be _immediately_ installed -- there's no time to wait for a round trip to the controller, so I don't know if I accept the premise that two static routes installed by two different controllers is a misconfiguration on its face. It might be good to separate these two use cases and their attendant solutions, rather than burying the "tight loop to the RIB" under more complex mechanisms designed for the apparent "long term ephemeral state" solution. :-) Russ From nobody Wed Nov 4 13:51:14 2015 Return-Path: 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 735931B342B for ; Wed, 4 Nov 2015 13:51:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.055 X-Spam-Level: X-Spam-Status: No, score=-99.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] 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 K-lAjD9R6ODh for ; Wed, 4 Nov 2015 13:51:12 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D73D51B3429 for ; Wed, 4 Nov 2015 13:51:11 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=133.93.81.236; From: "Susan Hares" To: "'Russ White'" <7riw77@gmail.com>, References: <00cf01d115d1$73765ca0$5a6315e0$@gmail.com> In-Reply-To: <00cf01d115d1$73765ca0$5a6315e0$@gmail.com> Date: Wed, 4 Nov 2015 16:51:07 -0500 Message-ID: <00af01d1174a$ea21fdd0$be65f970$@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: AQJnM+C7uUvbHKk7SEbsRDqJeBdn3J1gLTPA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] Ownership and Subscription X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 21:51:13 -0000 Russ: I have long argued for the node having the "owner bits". I am willing to be convinced that the multiple panes of glass (owner1, owner2, owner3) can be made to work in this first version of I2RS. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Russ White Sent: Monday, November 02, 2015 7:49 PM To: i2rs@ietf.org Subject: [i2rs] Ownership and Subscription Y'all -- After some thought on the entire ownership and subscription issue raised yesterday in the WG meeting -- to repeat the problem for those who weren't there... If an application/controller installs state into a particular agent running on a particular network node, what should we do with the notifications, etc.? Should the agent maintain some sort of "ownership" of the item in some way, so the agent can notify the owner/installer when their information is overwritten? Or should such notifications simply be pub/sub, where anyone (including the owner) can subscribe to changes in the item? I actually think the answer is both... IMHO, the agent should maintain a "who installed this" set of bits, but do nothing with these bits other than maintain them and include them in any notifications. These "bits" don't need to be anything complicated -- any sort of nonce would do, somehow calculated so there is little chance of the bits being replicated between controllers (a problem to be solved later, probably, or outside the confines of the protocol definition). My thinking is this -- when something is installed in the local ephemeral state by the agent, then the process might look like -- 1. The install signal is received 2. The priorities are examined, and the specific state installed 3. The installer is automatically subscribed to the notifications (the installer can decide to be removed from the pub/sub, but subscription should be on by default) 4. If the installer's state is overwritten, it receives a notification 5. This notification contains the "owner bits," which is really just shorthand for the installer to quickly check to see if "I installed this" Local policy in the controller might use this information in different ways. It's really just a bit of shorthand to help the controllers process things more efficiently, rather than real "ownership bits" in the more traditional sense. This seems like it solves the problems at hand -- ownership only implies subscription because the subscribe happens by default, but it's not really attached to the "ownership bits." It also, however, provides a shortcut for the "owner" to know what's going on with "their" installed state. Thoughts? :-) Russ _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Wed Nov 4 14:23:56 2015 Return-Path: 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 4248B1B34A7 for ; Wed, 4 Nov 2015 14:23:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.055 X-Spam-Level: X-Spam-Status: No, score=-99.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] 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 nv5FKxVHI00v for ; Wed, 4 Nov 2015 14:23:52 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1C961B34A1 for ; Wed, 4 Nov 2015 14:23:51 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=133.93.81.236; From: "Susan Hares" To: "'Joel M. Halpern'" , "'Andy Bierman'" References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> In-Reply-To: <563947F3.10805@joelhalpern.com> Date: Wed, 4 Nov 2015 17:23:42 -0500 Message-ID: <00cc01d1174f$77edbf60$67c93e20$@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: AQLwMtmz+XLO8+uQ7j5WaenA2rWXRwHVfCJTAW3ySwACzWyr4Jwdrvhw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, 'Russ White' <7riw77@gmail.com> Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 22:23:54 -0000 Joel: On the reading of composite panes, if you believe that ephemeral can be set on any configuration node or as an independent then the following Config-node-1 ephemeral node-1 (client 1), ephemeral Node-1 (client 2), Each ephemeral node could have an ID and a priority. The composite mode can apply a consistent policy: (E.g. high priority with tagging for first-wins). Asking for a composite in the rpc for read is a possible use for the composite. Asking for all of these nodes is possible. I believe this caching is required for the "tight-loop" issue of < 1 second response for query/response. If we define the group issues in the Yang language, then I think we can handle the multiple I2RS ephemeral entries with more memory space. The amount of memory space used by the I2RS caching entries can be set by the implementation in the Agent, and expressed by the model capabilities. I agree with Andy's original position that Caching will be necessary for high performance on medium to large scale Data models. Lastly, I am not sure our consensus on the "no-caching" was strong enough to refuse to consider it now. Meaning less than 10 people in interims or email -- should not prevent a larger group from reconsidering. This is a different type of consensus as a long debate on list plus IETF discussions. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Tuesday, November 03, 2015 6:49 PM To: Andy Bierman; Susan Hares Cc: i2rs@ietf.org; Russ White Subject: Re: [i2rs] Conversation on Priority and Panes The basic problem I have with your description is that it treats over-writes as normal and desirable, and assumes that the priority handling is producing the correct results. If we actually believed that, I suppose making them more efficient would be sensible. But that is not actually what we are doing. Priority over-write is a disambiguation mechanism. There is no expectation that it is even a good heuristic for correctness. It is merely predictable. Trying to optimize the control loop for cases of improper behavior seems the wrong place to optimize. Having said that, if we want to get into multiple panes of ephemeral glass then we are going to need mechanisms to read the composite effect read what I as a client have applied indicate in the response to a write request that the agent has accepted the request, even though it is not actually taking effect. And if we do all that, clients whose state is pending will need to maintain monitoring of all related activities even though their network application is not in effect. And, if there are multiple aspect of an operation, if one gets over-written but retained, then the client probably can't leave it there, but has to go in and remove that state, since the client will likely be removing the rest of the related state that is still sitting there with its lynchpin missing. And then we get into the question of how much unapplied state is an agent going to store. So it all probability the client still has to be prepared for being told that not only was its state over-written (which is technically an error) but that it got deleted too. Yours, Joel On 11/3/15 6:14 PM, Andy Bierman wrote: > Hi, > > This raises a data modeling issue. > Should every "backup parameter" be modeled explicitly in the YANG > module, or can the ephemeral datastore be used for that, without any > additional data model objects? > > The I2RS architecture supports this "backup" concept (lower priority > client), except it requires a notification from the agent and > subsequent request from the client to make the backup active. With > NETCONF or RESTCONF today, that round-trip will probably take around > 500 to 1000 milli-seconds. > Probably much worse during high loads. > > Our original proposal to the design team included a pane of glass for > each client (and unique priorities for each client), because some > people were talking about sub-milli-sec latency, and I know there is > no way NETCONF or RESTCONF is going to support this sort of tight control loop. > > Whether the server rejects lower-priority edits right away, or whether > the agent caches the request in the form of a client-specific pane, > the client still needs to observe the data resources with pub/sub and > decide whether its own particular state is still relevant. > IMO the client complexity is the same either way, especially since the > caching is only done if the client requests it. > > The only difference is likely to be almost a million times faster > fail-over to the backup on the server. > > > Andy > > > > > On Mon, Nov 2, 2015 at 8:32 PM, Susan Hares > wrote: > > Russ thank you for kicking off this discussion. It is an interesting > approach. I know that certain RIB implementations allows a back-up > route. > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org > ] On Behalf Of Russ White > Sent: Monday, November 02, 2015 7:39 PM > To: i2rs@ietf.org > Subject: [i2rs] Conversation on Priority and Panes > > Y'all -- > > After sleeping on the discussion last night, I think the panes of > glass (or > is it pains of glass?? :-) ) is still by and large another > expression of > the priority concept within I2RS. The concept does bring up one specific > point of interest, however -- what about backup information? Some vendor > RIBs, for instance, allow a routing process to install not only the best > path as calculated by the process -- but if the process fails to > install, > some RIB implementations allow the process to place the route in the > "backup > pool." This allows the local RIB process to drop to the "second best > path," > in terms of priority, so the local RIB doesn't need to query the routing > processes to switch in the case of a withdraw or change in topology. > > To convert this to I2RS terms, it does seem worthwhile to me to have the > capability for a local agent to accept an install instruction for some > particular ephemeral state, and if the install fails, to hold that > state for > future use. This would apply to any sort of ephemeral data, > including that > which is configured locally on the network device. Rather than trying to > think of this as "panes of glass," though, this would convert it to > simply a > backup list of lower priority items the local agent can use in the > case of > the failure of the highest priority item currently in use. > > The nice thing about this view is that it doesn't require a lot of > changes > at the protocol level. The only thing that needs to be available is the > option for an agent to send three different types of answers to an > install > request -- > > 1. This ephemeral state was installed and is now being used. > 2. This ephemeral state was rejected/not installed -- with potential > codes > for why (out of range parameter, etc.) 3. This ephemeral state was not > installed, but is being held as a backup. > > Using these semantics, the actual implementation of such a feature > is up to > the local agent. It might be that some agents don't know how to hold > backup > information, or that it doesn't make any sense to hold some sorts of > information in a backup list. This is fine -- the install can just be > rejected without further note. Locally configured information could > simply > be treated as an item on the backup list, such that the priorities > can be > considered as always in deciding what to install when any particular > action > is taken. > > It seems, to me, that this is a simpler way to consider the same problem > set, and reduces to an actual protocol mechanism that appears (?) to be > fairly simple, and leaves as much flexibility as possible for any given > agent implementation. > > Thoughts? > > :-) > > Russ > > _______________________________________________ > 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 > _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Wed Nov 4 15:41:35 2015 Return-Path: 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 00C281B386E for ; Wed, 4 Nov 2015 15:41:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 j5X4GiQg-xbj for ; Wed, 4 Nov 2015 15:41:31 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 843631B3840 for ; Wed, 4 Nov 2015 15:41:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 722872403F1; Wed, 4 Nov 2015 15:41:31 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from dhcp-25-165.meeting.ietf94.jp (dhcp-25-165.meeting.ietf94.jp [133.93.25.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 636682402C7; Wed, 4 Nov 2015 15:41:30 -0800 (PST) To: Susan Hares , "'Joel M. Halpern'" , 'Andy Bierman' References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> From: Joel Halpern Direct Message-ID: <563A97AA.5020308@joelhalpern.com> Date: Wed, 4 Nov 2015 18:41:30 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: i2rs@ietf.org, 'Russ White' <7riw77@gmail.com> Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 23:41:34 -0000 The working group can always reconsider any decision. But if we are going to do so, we need to recognize that the earlier discussion covered a LOT of issues that need to be dealt with. I do not understand the question in the first part of your email, so I can not comment on it. It is quite clear that caching is not required to meet a <1 second loop. In particular, this seems to be a major change in another agreement. We as a group concluded that over-write and other forms of collision are errors. They are not the control loop for which we are optimizing. The loop we said we are after is the loop from event detection through analysis and response generation to response application. That loop is completely unaffected by caching. So first, I think folks need to recognize that this discussion is revisiting several different and related WG architectural agreements. Yours, Joel On 11/4/15 5:23 PM, Susan Hares wrote: > Joel: > > On the reading of composite panes, if you believe that ephemeral can be set > on any configuration node or as an independent then the following > > Config-node-1 > ephemeral node-1 (client 1), > ephemeral Node-1 (client 2), > > Each ephemeral node could have an ID and a priority. The composite mode can > apply a consistent policy: (E.g. high priority with tagging for > first-wins). Asking for a composite in the rpc for read is a possible use > for the composite. Asking for all of these nodes is possible. > > I believe this caching is required for the "tight-loop" issue of < 1 second > response for query/response. > > If we define the group issues in the Yang language, then I think we can > handle the multiple I2RS ephemeral entries with more memory space. The > amount of memory space used by the I2RS caching entries can be set by the > implementation in the Agent, and expressed by the model capabilities. I > agree with Andy's original position that Caching will be necessary for high > performance on medium to large scale Data models. > > Lastly, I am not sure our consensus on the "no-caching" was strong enough to > refuse to consider it now. Meaning less than 10 people in interims or email > -- should not prevent a larger group from reconsidering. This is a > different type of consensus as a long debate on list plus IETF discussions. > > > Sue > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Tuesday, November 03, 2015 6:49 PM > To: Andy Bierman; Susan Hares > Cc: i2rs@ietf.org; Russ White > Subject: Re: [i2rs] Conversation on Priority and Panes > > The basic problem I have with your description is that it treats over-writes > as normal and desirable, and assumes that the priority handling is producing > the correct results. If we actually believed that, I suppose making them > more efficient would be sensible. > > But that is not actually what we are doing. Priority over-write is a > disambiguation mechanism. There is no expectation that it is even a good > heuristic for correctness. It is merely predictable. Trying to optimize > the control loop for cases of improper behavior seems the wrong place to > optimize. > > > Having said that, if we want to get into multiple panes of ephemeral glass > then we are going to need mechanisms to read the composite effect read what > I as a client have applied indicate in the response to a write request that > the agent has accepted the request, even though it is not actually taking > effect. > > And if we do all that, clients whose state is pending will need to maintain > monitoring of all related activities even though their network application > is not in effect. > > And, if there are multiple aspect of an operation, if one gets over-written > but retained, then the client probably can't leave it there, but has to go > in and remove that state, since the client will likely be removing the rest > of the related state that is still sitting there with its lynchpin missing. > > And then we get into the question of how much unapplied state is an agent > going to store. So it all probability the client still has to be prepared > for being told that not only was its state over-written (which is > technically an error) but that it got deleted too. > > Yours, > Joel > > On 11/3/15 6:14 PM, Andy Bierman wrote: >> Hi, >> >> This raises a data modeling issue. >> Should every "backup parameter" be modeled explicitly in the YANG >> module, or can the ephemeral datastore be used for that, without any >> additional data model objects? >> >> The I2RS architecture supports this "backup" concept (lower priority >> client), except it requires a notification from the agent and >> subsequent request from the client to make the backup active. With >> NETCONF or RESTCONF today, that round-trip will probably take around >> 500 to 1000 milli-seconds. >> Probably much worse during high loads. >> >> Our original proposal to the design team included a pane of glass for >> each client (and unique priorities for each client), because some >> people were talking about sub-milli-sec latency, and I know there is >> no way NETCONF or RESTCONF is going to support this sort of tight control > loop. >> >> Whether the server rejects lower-priority edits right away, or whether >> the agent caches the request in the form of a client-specific pane, >> the client still needs to observe the data resources with pub/sub and >> decide whether its own particular state is still relevant. >> IMO the client complexity is the same either way, especially since the >> caching is only done if the client requests it. >> >> The only difference is likely to be almost a million times faster >> fail-over to the backup on the server. >> >> >> Andy >> >> >> >> >> On Mon, Nov 2, 2015 at 8:32 PM, Susan Hares > > wrote: >> >> Russ thank you for kicking off this discussion. It is an interesting >> approach. I know that certain RIB implementations allows a back-up >> route. >> >> Sue >> >> -----Original Message----- >> From: i2rs [mailto:i2rs-bounces@ietf.org >> ] On Behalf Of Russ White >> Sent: Monday, November 02, 2015 7:39 PM >> To: i2rs@ietf.org >> Subject: [i2rs] Conversation on Priority and Panes >> >> Y'all -- >> >> After sleeping on the discussion last night, I think the panes of >> glass (or >> is it pains of glass?? :-) ) is still by and large another >> expression of >> the priority concept within I2RS. The concept does bring up one > specific >> point of interest, however -- what about backup information? Some > vendor >> RIBs, for instance, allow a routing process to install not only the > best >> path as calculated by the process -- but if the process fails to >> install, >> some RIB implementations allow the process to place the route in the >> "backup >> pool." This allows the local RIB process to drop to the "second best >> path," >> in terms of priority, so the local RIB doesn't need to query the > routing >> processes to switch in the case of a withdraw or change in topology. >> >> To convert this to I2RS terms, it does seem worthwhile to me to have > the >> capability for a local agent to accept an install instruction for some >> particular ephemeral state, and if the install fails, to hold that >> state for >> future use. This would apply to any sort of ephemeral data, >> including that >> which is configured locally on the network device. Rather than trying > to >> think of this as "panes of glass," though, this would convert it to >> simply a >> backup list of lower priority items the local agent can use in the >> case of >> the failure of the highest priority item currently in use. >> >> The nice thing about this view is that it doesn't require a lot of >> changes >> at the protocol level. The only thing that needs to be available is > the >> option for an agent to send three different types of answers to an >> install >> request -- >> >> 1. This ephemeral state was installed and is now being used. >> 2. This ephemeral state was rejected/not installed -- with potential >> codes >> for why (out of range parameter, etc.) 3. This ephemeral state was not >> installed, but is being held as a backup. >> >> Using these semantics, the actual implementation of such a feature >> is up to >> the local agent. It might be that some agents don't know how to hold >> backup >> information, or that it doesn't make any sense to hold some sorts of >> information in a backup list. This is fine -- the install can just be >> rejected without further note. Locally configured information could >> simply >> be treated as an item on the backup list, such that the priorities >> can be >> considered as always in deciding what to install when any particular >> action >> is taken. >> >> It seems, to me, that this is a simpler way to consider the same > problem >> set, and reduces to an actual protocol mechanism that appears (?) to > be >> fairly simple, and leaves as much flexibility as possible for any > given >> agent implementation. >> >> Thoughts? >> >> :-) >> >> Russ >> >> _______________________________________________ >> 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 >> > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Wed Nov 4 16:32:05 2015 Return-Path: <7riw77@gmail.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 709191B2BF3 for ; Wed, 4 Nov 2015 16:32:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_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 CSIq7K26H9tJ for ; Wed, 4 Nov 2015 16:32:03 -0800 (PST) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (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 7627A1B2BB3 for ; Wed, 4 Nov 2015 16:32:03 -0800 (PST) Received: by pasz6 with SMTP id z6so70380014pas.2 for ; Wed, 04 Nov 2015 16:32:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=urjIX9bxfIRyKh83BSCewoIFooMsw8KIwq2v22CLw7E=; b=GTdHiub1r8islPBiRFmOHHV1CS59ZkYCEcDeJjZxCaSHF8C0BzXInTp+A4xeI25GxU e1TNwzTGXV2j5XOBVX4Jq5xI688T6fIczUnmAWCLYXa11jHSr4Tdl59SauWaOGQrA/JX bXsGjQ1GZcqambf1+WMhas77UKb6fw7FjdRgr2/RKWrM4WVaCLnt3fYdfMu3IJW8kCIF /yNt1HYZ/Xqo+3KbOApxor6nmkPL33lvweIQnie84uRnIiVacuJPNBkhaVpI14bt5ZSw B1uwjDL/U6aaMgME7PcCPiIB6VZsBnKGP44u8yGn8t3guIwTuv/Fmq7mMtAGCP/jhS8P AQwQ== X-Received: by 10.68.91.98 with SMTP id cd2mr5812894pbb.9.1446683522960; Wed, 04 Nov 2015 16:32:02 -0800 (PST) Received: from Russ ([2001:c40:0:3064:89b0:1ec3:3a22:ffe]) by smtp.gmail.com with ESMTPSA id hz4sm2138526pbc.12.2015.11.04.16.32.01 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Nov 2015 16:32:02 -0800 (PST) From: "Russ White" <7riw77@gmail.com> To: "'Joel Halpern Direct'" , "'Susan Hares'" , "'Joel M. Halpern'" , "'Andy Bierman'" References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> <563A97AA.5020308@joelhalpern.com> In-Reply-To: <563A97AA.5020308@joelhalpern.com> Date: Wed, 4 Nov 2015 19:31:54 -0500 Message-ID: <00f301d11761$61699130$243cb390$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLwMtmz+XLO8+uQ7j5WaenA2rWXRwHVfCJTAW3ySwACzWyr4AJQYvqoAmia70ub+AyIYA== Content-Language: en-us Archived-At: Cc: i2rs@ietf.org Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 00:32:04 -0000 > It is quite clear that caching is not required to meet a <1 second loop. Given several comments on the list recently that RESTCONF isn't going to be able to meet these sorts of timers, I'm not certain... Further, I'd like to see a timer that's tighter than 1sec -- fast reroute needs to happen in <250ms in many networks. It seems like this particular area leads to "we don't have enough information right now to decide?" > We as a group concluded that over-write and other forms of collision are > errors. Calling an overwrite an error, and stating it isn't something we should optimize for, are two different things. :-) I don't think they're an error, even if you consider multiple controllers/clients. I think part of the problem might be we're thinking about different sorts of data here -- I don't think having three different processes overwriting the route to 10.1.1.0/24 with a different next hop, and expecting the second highest priority to take over when the highest priority is removed, is an error -- I'm willing to listen to the case, but I know this sort of thing is configured all the time in real networks (and not just for static routes). I can see how it would be considered an error in the case of setting up a new interface, or modifying a virtual topology, but this is what makes me suspect we have two different (and heavily interrelated) problems in hand. I think we might need to separate the case of "RPC to the RIB" and "ephemeral overlay state" in some way in our heads, even though we need to make certain we know how these things interact with one another. :-) Russ From nobody Wed Nov 4 16:41:42 2015 Return-Path: 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 E54891B2D1E for ; Wed, 4 Nov 2015 16:41:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 sWT6iESjc0AR for ; Wed, 4 Nov 2015 16:41:38 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42D5F1B33AA for ; Wed, 4 Nov 2015 16:41:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 167DB24030E; Wed, 4 Nov 2015 16:41:03 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from dhcp-25-165.meeting.ietf94.jp (dhcp-25-165.meeting.ietf94.jp [133.93.25.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4F1B92402C7; Wed, 4 Nov 2015 16:41:02 -0800 (PST) To: Russ White <7riw77@gmail.com>, 'Susan Hares' , 'Andy Bierman' References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> <563A97AA.5020308@joelhalpern.com> <00f301d11761$61699130$243cb390$@gmail.com> From: "Joel M. Halpern" Message-ID: <563AA59C.4060809@joelhalpern.com> Date: Wed, 4 Nov 2015 19:41:00 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <00f301d11761$61699130$243cb390$@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: i2rs@ietf.org Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 00:41:40 -0000 If the only problem we want to solve is the RIB, and specifically the creation of alternative RIB entries, then a VERY different approach would take care of the problem. The existing RIB models already recognize that there are multiple creators. So if we only need to handle alternative RIB entries, that mechanism to could be generalized easily to avoid even panes of glass complexity. But if we want one client to be able to modify part of a RIB entry, or if we want to be able to work with things other than RIB entries, then all of the issues that were discussed several years ago come back into play. So if you want to argue that we should solve only the small problem, that is defensible. But it is a big change in our scoping to date. And from where I sit it would not particularly help us solve the larger problem, which does need to be addressed. Yours, Joel On 11/4/15 7:31 PM, Russ White wrote: > >> It is quite clear that caching is not required to meet a <1 second loop. > > Given several comments on the list recently that RESTCONF isn't going to be > able to meet these sorts of timers, I'm not certain... Further, I'd like to > see a timer that's tighter than 1sec -- fast reroute needs to happen in > <250ms in many networks. It seems like this particular area leads to "we > don't have enough information right now to decide?" > >> We as a group concluded that over-write and other forms of collision are >> errors. > > Calling an overwrite an error, and stating it isn't something we should > optimize for, are two different things. :-) I don't think they're an error, > even if you consider multiple controllers/clients. I think part of the > problem might be we're thinking about different sorts of data here -- I > don't think having three different processes overwriting the route to > 10.1.1.0/24 with a different next hop, and expecting the second highest > priority to take over when the highest priority is removed, is an error -- > I'm willing to listen to the case, but I know this sort of thing is > configured all the time in real networks (and not just for static routes). I > can see how it would be considered an error in the case of setting up a new > interface, or modifying a virtual topology, but this is what makes me > suspect we have two different (and heavily interrelated) problems in hand. > > I think we might need to separate the case of "RPC to the RIB" and > "ephemeral overlay state" in some way in our heads, even though we need to > make certain we know how these things interact with one another. > > :-) > > Russ > From nobody Wed Nov 4 16:53:46 2015 Return-Path: <7riw77@gmail.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 C47C81A039C for ; Wed, 4 Nov 2015 16:53:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_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 qORbSAyKw4Dj for ; Wed, 4 Nov 2015 16:53:41 -0800 (PST) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (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 3C28A1A016E for ; Wed, 4 Nov 2015 16:53:41 -0800 (PST) Received: by padhx2 with SMTP id hx2so60725444pad.1 for ; Wed, 04 Nov 2015 16:53:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=zbeWmBoReU4pEgT9OioxqnazMOLUq26sUWRSpVFz5QU=; b=p3upLLup+lrayk8Fvfdv86kBZbCgLjhr6C17RxdamEfdnJ6a+O9AD01vpfDXIsvY6N pkaESzdWxob9zJWYbNAwRB2UAY1H9/cAEMlpUV/lzBrahUDt9s5w9AjKlrhOdgrkC6Qp Wyc0T5MmmezHN8KAHP1HRRUKwLmhxt0Op9JlgU9T+aoRLY8QhV4MRJ/uReo6YtfehzUQ 9NRKQGdPgPUhVXBKyeR1/swNlriWnCKSZJUBiswlX6Hj6nfDv6zht1LUeasgT+fsFVDj WnmBh+LC9wQ03fTv5ovolNV8TXXiOgteGT91dD0bf669nXF3KTsl6T4dGHeFUbdJx7AP 3LKQ== X-Received: by 10.68.165.34 with SMTP id yv2mr5686149pbb.153.1446684820474; Wed, 04 Nov 2015 16:53:40 -0800 (PST) Received: from Russ ([2001:c40:0:3064:89b0:1ec3:3a22:ffe]) by smtp.gmail.com with ESMTPSA id xu5sm4311196pab.12.2015.11.04.16.53.38 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Nov 2015 16:53:39 -0800 (PST) From: "Russ White" <7riw77@gmail.com> To: "'Joel M. Halpern'" , "'Susan Hares'" , "'Andy Bierman'" References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> <563A97AA.5020308@joelhalpern.com> <00f301d11761$61699130$243cb390$@gmail.com> <563AA59C.4060809@joelhalpern.com> In-Reply-To: <563AA59C.4060809@joelhalpern.com> Date: Wed, 4 Nov 2015 19:53:28 -0500 Message-ID: <018101d11764$66b82e50$34288af0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLwMtmz+XLO8+uQ7j5WaenA2rWXRwHVfCJTAW3ySwACzWyr4AJQYvqoAmia70sCRUpXGQJL52qvm9OJxIA= Content-Language: en-us Archived-At: Cc: i2rs@ietf.org Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 00:53:42 -0000 > But if we want one client to be able to modify part of a RIB entry, or if we > want to be able to work with things other than RIB entries, then all of the > issues that were discussed several years ago come back into play. First -- in terms of granularity -- I don't think anyone should be modifying parts of a RIB entry. Rather, each "object" should be treated as an "object" in full. This is something that needs to be addressed in the models -- what is essential, and what is accidental. Second -- I'm not arguing one problem should be solved, and others shouldn't. I'm saying I think we might have two different interrelated problem sets, both of which need to be solved. For instance, it might be useful to say something like: "In the RIB, overwrites are not an error; in all other areas they are." And then define the models and processes to handle these two different cases. I don't know that using one unified way of dealing with things is necessarily going to solve all the problems at hand. Recognizing this might help us move forward in a coherent way, rather than stumbling over the same set of problems in different guises each time some new point is undertaken. :-) Russ From nobody Wed Nov 4 23:05:31 2015 Return-Path: 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 E0A491B35E3 for ; Wed, 4 Nov 2015 23:05:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.055 X-Spam-Level: X-Spam-Status: No, score=-99.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] 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 QKQzId3MLJJL for ; Wed, 4 Nov 2015 23:05:24 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BFFC1B3B12 for ; Wed, 4 Nov 2015 23:05:24 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=133.93.24.48; From: "Susan Hares" To: "'Joel Halpern Direct'" , "'Joel M. Halpern'" , "'Andy Bierman'" References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> <563A97AA.5020308@joelhalpern.com> In-Reply-To: <563A97AA.5020308@joelhalpern.com> Date: Thu, 5 Nov 2015 02:05:16 -0500 Message-ID: <005101d11798$549a6f10$fdcf4d30$@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: AQLwMtmz+XLO8+uQ7j5WaenA2rWXRwHVfCJTAW3ySwACzWyr4AJQYvqoAmia70ub+F9HEA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, 'Russ White' <7riw77@gmail.com> Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 07:05:27 -0000 Joel: I agree that opening up the decision on caching will open a lot of issues. In my mind, this email thread has shown there may be operational issues with the "no-caching issue." We are about to send the requirements to the IESG/NETCONF, and I want to validate the caching/no-caching decision. Let me give an example. Client 1 - priority 5 -- route1 nh 2 time 1 Client 2 - priority 6 -- route1 nh 1 time 2 Client 3 - priority 4 -- route 1 nh 3 time 3 Config - priority 0 - route 1 nh 4 time 2 Node = route with subnode nexthop If you: a) save the priority + Nh differences + priority + Time b) assign config (lowest priority) + reboot tie then the priority resolution can resolve the node. I believe this is the basic multiple creators concept you mentioned in your emails for RIBs. I believe we agree that this is solvable. I do not see how this fails to solve a partial RIB. Taking the P.I. Topology draft and FB-RIB, I think a similar sequences can resolve the problem. If not, would you let me know the example that does not fit. In our earlier discussions, we stated the grouping of nodes (route, NH, interfaces) did not fit the model. In my subsequent discuss with yang folks, I came to realize a grouping of nodes which are under a particular point and we could use this. Route ----------- | \ | Prefix Nh priority If this is true, then the model could provide language that handles the grouping of variables or things being referred. This understanding of the capability (which other I2RS WG members may have known) provides me a way to model the grouping of parameters. So, I can perceive a possibility of solving caching. Is this much of my question understandable? The next part of my question was to inquire what do you see as some of the issues that we need to consider on the panes of glass. Sue -----Original Message----- From: Joel Halpern Direct [mailto:jmh.direct@joelhalpern.com] Sent: Wednesday, November 04, 2015 6:42 PM To: Susan Hares; 'Joel M. Halpern'; 'Andy Bierman' Cc: i2rs@ietf.org; 'Russ White' Subject: Re: [i2rs] Conversation on Priority and Panes The working group can always reconsider any decision. But if we are going to do so, we need to recognize that the earlier discussion covered a LOT of issues that need to be dealt with. I do not understand the question in the first part of your email, so I can not comment on it. It is quite clear that caching is not required to meet a <1 second loop. In particular, this seems to be a major change in another agreement. We as a group concluded that over-write and other forms of collision are errors. They are not the control loop for which we are optimizing. The loop we said we are after is the loop from event detection through analysis and response generation to response application. That loop is completely unaffected by caching. So first, I think folks need to recognize that this discussion is revisiting several different and related WG architectural agreements. Yours, Joel On 11/4/15 5:23 PM, Susan Hares wrote: > Joel: > > On the reading of composite panes, if you believe that ephemeral can > be set on any configuration node or as an independent then the > following > > Config-node-1 > ephemeral node-1 (client 1), > ephemeral Node-1 (client 2), > > Each ephemeral node could have an ID and a priority. The composite > mode can apply a consistent policy: (E.g. high priority with tagging for > first-wins). Asking for a composite in the rpc for read is a possible use > for the composite. Asking for all of these nodes is possible. > > I believe this caching is required for the "tight-loop" issue of < 1 > second response for query/response. > > If we define the group issues in the Yang language, then I think we > can handle the multiple I2RS ephemeral entries with more memory space. > The amount of memory space used by the I2RS caching entries can be set > by the implementation in the Agent, and expressed by the model > capabilities. I agree with Andy's original position that Caching will > be necessary for high performance on medium to large scale Data models. > > Lastly, I am not sure our consensus on the "no-caching" was strong > enough to refuse to consider it now. Meaning less than 10 people in > interims or email > -- should not prevent a larger group from reconsidering. This is a > different type of consensus as a long debate on list plus IETF discussions. > > > Sue > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Tuesday, November 03, 2015 6:49 PM > To: Andy Bierman; Susan Hares > Cc: i2rs@ietf.org; Russ White > Subject: Re: [i2rs] Conversation on Priority and Panes > > The basic problem I have with your description is that it treats > over-writes as normal and desirable, and assumes that the priority > handling is producing the correct results. If we actually believed > that, I suppose making them more efficient would be sensible. > > But that is not actually what we are doing. Priority over-write is a > disambiguation mechanism. There is no expectation that it is even a > good heuristic for correctness. It is merely predictable. Trying to > optimize the control loop for cases of improper behavior seems the > wrong place to optimize. > > > Having said that, if we want to get into multiple panes of ephemeral > glass then we are going to need mechanisms to read the composite > effect read what I as a client have applied indicate in the response > to a write request that the agent has accepted the request, even > though it is not actually taking effect. > > And if we do all that, clients whose state is pending will need to > maintain monitoring of all related activities even though their > network application is not in effect. > > And, if there are multiple aspect of an operation, if one gets > over-written but retained, then the client probably can't leave it > there, but has to go in and remove that state, since the client will > likely be removing the rest of the related state that is still sitting there with its lynchpin missing. > > And then we get into the question of how much unapplied state is an > agent going to store. So it all probability the client still has to > be prepared for being told that not only was its state over-written > (which is technically an error) but that it got deleted too. > > Yours, > Joel > > On 11/3/15 6:14 PM, Andy Bierman wrote: >> Hi, >> >> This raises a data modeling issue. >> Should every "backup parameter" be modeled explicitly in the YANG >> module, or can the ephemeral datastore be used for that, without any >> additional data model objects? >> >> The I2RS architecture supports this "backup" concept (lower priority >> client), except it requires a notification from the agent and >> subsequent request from the client to make the backup active. With >> NETCONF or RESTCONF today, that round-trip will probably take around >> 500 to 1000 milli-seconds. >> Probably much worse during high loads. >> >> Our original proposal to the design team included a pane of glass for >> each client (and unique priorities for each client), because some >> people were talking about sub-milli-sec latency, and I know there is >> no way NETCONF or RESTCONF is going to support this sort of tight >> control > loop. >> >> Whether the server rejects lower-priority edits right away, or >> whether the agent caches the request in the form of a client-specific >> pane, the client still needs to observe the data resources with >> pub/sub and decide whether its own particular state is still relevant. >> IMO the client complexity is the same either way, especially since >> the caching is only done if the client requests it. >> >> The only difference is likely to be almost a million times faster >> fail-over to the backup on the server. >> >> >> Andy >> >> >> >> >> On Mon, Nov 2, 2015 at 8:32 PM, Susan Hares > > wrote: >> >> Russ thank you for kicking off this discussion. It is an interesting >> approach. I know that certain RIB implementations allows a back-up >> route. >> >> Sue >> >> -----Original Message----- >> From: i2rs [mailto:i2rs-bounces@ietf.org >> ] On Behalf Of Russ White >> Sent: Monday, November 02, 2015 7:39 PM >> To: i2rs@ietf.org >> Subject: [i2rs] Conversation on Priority and Panes >> >> Y'all -- >> >> After sleeping on the discussion last night, I think the panes of >> glass (or >> is it pains of glass?? :-) ) is still by and large another >> expression of >> the priority concept within I2RS. The concept does bring up one > specific >> point of interest, however -- what about backup information? >> Some > vendor >> RIBs, for instance, allow a routing process to install not only >> the > best >> path as calculated by the process -- but if the process fails to >> install, >> some RIB implementations allow the process to place the route in the >> "backup >> pool." This allows the local RIB process to drop to the "second best >> path," >> in terms of priority, so the local RIB doesn't need to query the > routing >> processes to switch in the case of a withdraw or change in topology. >> >> To convert this to I2RS terms, it does seem worthwhile to me to >> have > the >> capability for a local agent to accept an install instruction for some >> particular ephemeral state, and if the install fails, to hold that >> state for >> future use. This would apply to any sort of ephemeral data, >> including that >> which is configured locally on the network device. Rather than >> trying > to >> think of this as "panes of glass," though, this would convert it to >> simply a >> backup list of lower priority items the local agent can use in the >> case of >> the failure of the highest priority item currently in use. >> >> The nice thing about this view is that it doesn't require a lot of >> changes >> at the protocol level. The only thing that needs to be available >> is > the >> option for an agent to send three different types of answers to an >> install >> request -- >> >> 1. This ephemeral state was installed and is now being used. >> 2. This ephemeral state was rejected/not installed -- with potential >> codes >> for why (out of range parameter, etc.) 3. This ephemeral state was not >> installed, but is being held as a backup. >> >> Using these semantics, the actual implementation of such a feature >> is up to >> the local agent. It might be that some agents don't know how to hold >> backup >> information, or that it doesn't make any sense to hold some sorts of >> information in a backup list. This is fine -- the install can just be >> rejected without further note. Locally configured information could >> simply >> be treated as an item on the backup list, such that the priorities >> can be >> considered as always in deciding what to install when any particular >> action >> is taken. >> >> It seems, to me, that this is a simpler way to consider the same > problem >> set, and reduces to an actual protocol mechanism that appears >> (?) to > be >> fairly simple, and leaves as much flexibility as possible for >> any > given >> agent implementation. >> >> Thoughts? >> >> :-) >> >> Russ >> >> _______________________________________________ >> 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 >> > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Wed Nov 4 23:38:10 2015 Return-Path: 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 1F9291B3B98 for ; Wed, 4 Nov 2015 23:38:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 i8_pqrOoFdgf for ; Wed, 4 Nov 2015 23:37:56 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 978631B3B67 for ; Wed, 4 Nov 2015 23:37:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 7FC66240C11; Wed, 4 Nov 2015 23:37:56 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (122x210x83x163.ap122.ftth.ucom.ne.jp [122.210.83.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 45BB42408A7; Wed, 4 Nov 2015 23:37:55 -0800 (PST) To: Susan Hares , "'Joel M. Halpern'" , 'Andy Bierman' References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> <563A97AA.5020308@joelhalpern.com> <005101d11798$549a6f10$fdcf4d30$@ndzh.com> From: "Joel M. Halpern" Message-ID: <563B0750.70009@joelhalpern.com> Date: Thu, 5 Nov 2015 02:37:52 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <005101d11798$549a6f10$fdcf4d30$@ndzh.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: i2rs@ietf.org, 'Russ White' <7riw77@gmail.com> Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 07:38:03 -0000 There are two VERY basic questions. First, is the case of two I2RS clients modifying the same "thing" something we consider normal and desirable, or is it an error. The earlier discussions was that it is an error. In discussing the many different kinds of direct and indirect collateral issues that arise, we concluded that we could not expect the I2RS agent to be able to determine the "right" thing to do in the general case. I have not seen any evidence that foer the general case we actually know this better now. And I do see a LOT of side effects and implications. For a pure RIB node solution, we already have the tools for multiple writers. the existing RIB models already have the notion of multiple entries whose key differs by who created the entry. And the notion that the RIB manager decides. We could easily represent each I2RS client as a source, and let the RIB manager handle the rest. But this is a RIB only solution. My understanding of the WG conclusion was that we wanted a common solution for a broad range of cases, including the RIB. And that we were happy to treat collision as an error. If there is new information (I have not seen any) or if the WG has changed its mind, then so be it. As an example, if one is creating policy entries that make assumptions about your route entries being in efect, then having the system change what is in effect can produce very strange and unexpected behaviors. Yours, Joel On 11/5/15 2:05 AM, Susan Hares wrote: > Joel: > > > I agree that opening up the decision on caching will open a lot of issues. > In my mind, this email thread has shown there may be operational issues with > the "no-caching issue." We are about to send the requirements to the > IESG/NETCONF, and I want to validate the caching/no-caching decision. > > Let me give an example. > > Client 1 - priority 5 -- route1 nh 2 time 1 > Client 2 - priority 6 -- route1 nh 1 time 2 > Client 3 - priority 4 -- route 1 nh 3 time 3 > Config - priority 0 - route 1 nh 4 time 2 > > Node = route with subnode nexthop > If you: > a) save the priority + Nh differences + priority + Time > b) assign config (lowest priority) + reboot tie > then the priority resolution can resolve the node. > > I believe this is the basic multiple creators concept you mentioned in your > emails for RIBs. I believe we agree that this is solvable. I do not see how > this fails to solve a partial RIB. > > Taking the P.I. Topology draft and FB-RIB, I think a similar sequences can > resolve the problem. If not, would you let me know the example that does > not fit. > > In our earlier discussions, we stated the grouping of nodes (route, NH, > interfaces) did not fit the model. In my subsequent discuss with yang > folks, I came to realize a grouping of nodes which are under a particular > point and we could use this. > > Route ----------- > | \ | > Prefix Nh priority > > If this is true, then the model could provide language that handles the > grouping of variables or things being referred. This understanding of the > capability (which other I2RS WG members may have known) provides me a way to > model the grouping of parameters. So, I can perceive a possibility of > solving caching. > > Is this much of my question understandable? The next part of my question > was to inquire what do you see as some of the issues that we need to > consider on the panes of glass. > > > Sue > > > -----Original Message----- > From: Joel Halpern Direct [mailto:jmh.direct@joelhalpern.com] > Sent: Wednesday, November 04, 2015 6:42 PM > To: Susan Hares; 'Joel M. Halpern'; 'Andy Bierman' > Cc: i2rs@ietf.org; 'Russ White' > Subject: Re: [i2rs] Conversation on Priority and Panes > > The working group can always reconsider any decision. > But if we are going to do so, we need to recognize that the earlier > discussion covered a LOT of issues that need to be dealt with. > > I do not understand the question in the first part of your email, so I can > not comment on it. > > It is quite clear that caching is not required to meet a <1 second loop. > In particular, this seems to be a major change in another agreement. > We as a group concluded that over-write and other forms of collision are > errors. They are not the control loop for which we are optimizing. The > loop we said we are after is the loop from event detection through analysis > and response generation to response application. That loop is completely > unaffected by caching. > > So first, I think folks need to recognize that this discussion is revisiting > several different and related WG architectural agreements. > > Yours, > Joel > > On 11/4/15 5:23 PM, Susan Hares wrote: >> Joel: >> >> On the reading of composite panes, if you believe that ephemeral can >> be set on any configuration node or as an independent then the >> following >> >> Config-node-1 >> ephemeral node-1 (client 1), >> ephemeral Node-1 (client 2), >> >> Each ephemeral node could have an ID and a priority. The composite >> mode can apply a consistent policy: (E.g. high priority with tagging for >> first-wins). Asking for a composite in the rpc for read is a possible > use >> for the composite. Asking for all of these nodes is possible. >> >> I believe this caching is required for the "tight-loop" issue of < 1 >> second response for query/response. >> >> If we define the group issues in the Yang language, then I think we >> can handle the multiple I2RS ephemeral entries with more memory space. >> The amount of memory space used by the I2RS caching entries can be set >> by the implementation in the Agent, and expressed by the model >> capabilities. I agree with Andy's original position that Caching will >> be necessary for high performance on medium to large scale Data models. >> >> Lastly, I am not sure our consensus on the "no-caching" was strong >> enough to refuse to consider it now. Meaning less than 10 people in >> interims or email >> -- should not prevent a larger group from reconsidering. This is a >> different type of consensus as a long debate on list plus IETF > discussions. >> >> >> Sue >> -----Original Message----- >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. Halpern >> Sent: Tuesday, November 03, 2015 6:49 PM >> To: Andy Bierman; Susan Hares >> Cc: i2rs@ietf.org; Russ White >> Subject: Re: [i2rs] Conversation on Priority and Panes >> >> The basic problem I have with your description is that it treats >> over-writes as normal and desirable, and assumes that the priority >> handling is producing the correct results. If we actually believed >> that, I suppose making them more efficient would be sensible. >> >> But that is not actually what we are doing. Priority over-write is a >> disambiguation mechanism. There is no expectation that it is even a >> good heuristic for correctness. It is merely predictable. Trying to >> optimize the control loop for cases of improper behavior seems the >> wrong place to optimize. >> >> >> Having said that, if we want to get into multiple panes of ephemeral >> glass then we are going to need mechanisms to read the composite >> effect read what I as a client have applied indicate in the response >> to a write request that the agent has accepted the request, even >> though it is not actually taking effect. >> >> And if we do all that, clients whose state is pending will need to >> maintain monitoring of all related activities even though their >> network application is not in effect. >> >> And, if there are multiple aspect of an operation, if one gets >> over-written but retained, then the client probably can't leave it >> there, but has to go in and remove that state, since the client will >> likely be removing the rest of the related state that is still sitting > there with its lynchpin missing. >> >> And then we get into the question of how much unapplied state is an >> agent going to store. So it all probability the client still has to >> be prepared for being told that not only was its state over-written >> (which is technically an error) but that it got deleted too. >> >> Yours, >> Joel >> >> On 11/3/15 6:14 PM, Andy Bierman wrote: >>> Hi, >>> >>> This raises a data modeling issue. >>> Should every "backup parameter" be modeled explicitly in the YANG >>> module, or can the ephemeral datastore be used for that, without any >>> additional data model objects? >>> >>> The I2RS architecture supports this "backup" concept (lower priority >>> client), except it requires a notification from the agent and >>> subsequent request from the client to make the backup active. With >>> NETCONF or RESTCONF today, that round-trip will probably take around >>> 500 to 1000 milli-seconds. >>> Probably much worse during high loads. >>> >>> Our original proposal to the design team included a pane of glass for >>> each client (and unique priorities for each client), because some >>> people were talking about sub-milli-sec latency, and I know there is >>> no way NETCONF or RESTCONF is going to support this sort of tight >>> control >> loop. >>> >>> Whether the server rejects lower-priority edits right away, or >>> whether the agent caches the request in the form of a client-specific >>> pane, the client still needs to observe the data resources with >>> pub/sub and decide whether its own particular state is still relevant. >>> IMO the client complexity is the same either way, especially since >>> the caching is only done if the client requests it. >>> >>> The only difference is likely to be almost a million times faster >>> fail-over to the backup on the server. >>> >>> >>> Andy >>> >>> >>> >>> >>> On Mon, Nov 2, 2015 at 8:32 PM, Susan Hares >> > wrote: >>> >>> Russ thank you for kicking off this discussion. It is an > interesting >>> approach. I know that certain RIB implementations allows a back-up >>> route. >>> >>> Sue >>> >>> -----Original Message----- >>> From: i2rs [mailto:i2rs-bounces@ietf.org >>> ] On Behalf Of Russ White >>> Sent: Monday, November 02, 2015 7:39 PM >>> To: i2rs@ietf.org >>> Subject: [i2rs] Conversation on Priority and Panes >>> >>> Y'all -- >>> >>> After sleeping on the discussion last night, I think the panes of >>> glass (or >>> is it pains of glass?? :-) ) is still by and large another >>> expression of >>> the priority concept within I2RS. The concept does bring up one >> specific >>> point of interest, however -- what about backup information? >>> Some >> vendor >>> RIBs, for instance, allow a routing process to install not only >>> the >> best >>> path as calculated by the process -- but if the process fails to >>> install, >>> some RIB implementations allow the process to place the route in the >>> "backup >>> pool." This allows the local RIB process to drop to the "second best >>> path," >>> in terms of priority, so the local RIB doesn't need to query the >> routing >>> processes to switch in the case of a withdraw or change in topology. >>> >>> To convert this to I2RS terms, it does seem worthwhile to me to >>> have >> the >>> capability for a local agent to accept an install instruction for > some >>> particular ephemeral state, and if the install fails, to hold that >>> state for >>> future use. This would apply to any sort of ephemeral data, >>> including that >>> which is configured locally on the network device. Rather than >>> trying >> to >>> think of this as "panes of glass," though, this would convert it to >>> simply a >>> backup list of lower priority items the local agent can use in the >>> case of >>> the failure of the highest priority item currently in use. >>> >>> The nice thing about this view is that it doesn't require a lot of >>> changes >>> at the protocol level. The only thing that needs to be available >>> is >> the >>> option for an agent to send three different types of answers to an >>> install >>> request -- >>> >>> 1. This ephemeral state was installed and is now being used. >>> 2. This ephemeral state was rejected/not installed -- with potential >>> codes >>> for why (out of range parameter, etc.) 3. This ephemeral state was > not >>> installed, but is being held as a backup. >>> >>> Using these semantics, the actual implementation of such a feature >>> is up to >>> the local agent. It might be that some agents don't know how to hold >>> backup >>> information, or that it doesn't make any sense to hold some sorts of >>> information in a backup list. This is fine -- the install can just > be >>> rejected without further note. Locally configured information could >>> simply >>> be treated as an item on the backup list, such that the priorities >>> can be >>> considered as always in deciding what to install when any particular >>> action >>> is taken. >>> >>> It seems, to me, that this is a simpler way to consider the same >> problem >>> set, and reduces to an actual protocol mechanism that appears >>> (?) to >> be >>> fairly simple, and leaves as much flexibility as possible for >>> any >> given >>> agent implementation. >>> >>> Thoughts? >>> >>> :-) >>> >>> Russ >>> >>> _______________________________________________ >>> 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 >>> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> > From nobody Thu Nov 5 00:10:56 2015 Return-Path: <7riw77@gmail.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 DD4D91A00B8 for ; Thu, 5 Nov 2015 00:10:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_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 2MlGucziFqCz for ; Thu, 5 Nov 2015 00:10:52 -0800 (PST) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (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 C7B041A00A0 for ; Thu, 5 Nov 2015 00:10:52 -0800 (PST) Received: by pasz6 with SMTP id z6so83463070pas.2 for ; Thu, 05 Nov 2015 00:10:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=xjViWOQ6SOAUUrRtj4MHIh6wCUH7597hyt/zwy4icdw=; b=HYFo3OkNfmDRVYKygd+2Ld4WhEg0/aDpiNLhaa4x2HDBgrluckdCbgxhS9gaTukWLD 1OCWBRnz7pMfoQC+FVDJb1zlFKZ9BmZz5/mIdDqKqbWEXaW9JDtMFftYehtcYOQOYQOe CCddQHsFb2v+sSFrRmDL/l0/xe3+m74A6BPLEjMD04gtgNVnuGs22oIvbPU5uQauAgfU gISNu27aMsfo3Jo1YKPP+0uBDFU4e1X7fpYZW9BDkoe+mtHzjA+2h+6xYt7PF8HR1316 4HZwsgXNf/bzYByOrjYoLzz0hH98Sk56IwqFL7hFXFbrH5JkTCS3H67Ng+JWMUj5GEKf 1HjQ== X-Received: by 10.68.57.205 with SMTP id k13mr7863279pbq.4.1446711052077; Thu, 05 Nov 2015 00:10:52 -0800 (PST) Received: from Russ (t20010c4000003024e4aab29367780bf1.v6.meeting.ietf94.jp. [2001:c40:0:3024:e4aa:b293:6778:bf1]) by smtp.gmail.com with ESMTPSA id sk9sm911333pbc.93.2015.11.05.00.10.49 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Nov 2015 00:10:51 -0800 (PST) From: "Russ White" <7riw77@gmail.com> To: "'Joel M. Halpern'" , "'Susan Hares'" , "'Andy Bierman'" References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> <563A97AA.5020308@joelhalpern.com> <005101d11798$549a6f10$fdcf4d30$@ndzh.com> <563B0750.70009@joelhalpern.com> In-Reply-To: <563B0750.70009@joelhalpern.com> Date: Thu, 5 Nov 2015 03:10:42 -0500 Message-ID: <034901d117a1$79a6e7d0$6cf4b770$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLwMtmz+XLO8+uQ7j5WaenA2rWXRwHVfCJTAW3ySwACzWyr4AJQYvqoAmia70sBb/tJ5QHaZBpQm944PWA= Content-Language: en-us Archived-At: Cc: i2rs@ietf.org Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 08:10:55 -0000 > First, is the case of two I2RS clients modifying the same "thing" > something we consider normal and desirable, or is it an error. The earlier > discussions was that it is an error. In discussing the many different kinds of > direct and indirect collateral issues that arise, we concluded that we could > not expect the I2RS agent to be able to determine the "right" thing to do in > the general case. So, assume the following -- 1. A local BGP process installs a route, 10.1.1.0/24 via 192.168.100.1 2. In order to move traffic off a "hot link" in a fabric, a client/controller installs a route, 10.1.1.0/24 via 192.168.200.1 3. An attack vector is detected in a flow destined to some host on 10.1.1.0/24 that causes a separate client/controller to install a route, 10.1.1.0/24 via 192.168.150.1 for five seconds If I were the operator who owned this network, I wouldn't call this an "error." I would call this "normal operation," -- in fact, the ability to do the above would be the very reason I would deploy I2RS on the network in the first place. Further, I would expect the entire process to unwind properly and _quickly_. I don't care how it happens, I just want the removal of the second client's route to leave the first client's in the table as the current route, and the removal of the first client's path leave the BGP route as the best path. To go farther, why are there client priorities at all if this is an "error?" If all overwrites of "ephemeral state" are an error, the agent should simply reject any attempt to overwrite any such state. :-) Russ From nobody Thu Nov 5 00:13:22 2015 Return-Path: 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 4C25E1A0378 for ; Thu, 5 Nov 2015 00:13:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.555 X-Spam-Level: X-Spam-Status: No, score=-98.555 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, GB_ABOUTYOU=0.5, USER_IN_WHITELIST=-100] 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 ZZInbTEt3W7U for ; Thu, 5 Nov 2015 00:13:18 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 996941A01BA for ; Thu, 5 Nov 2015 00:13:17 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=133.93.24.48; From: "Susan Hares" To: "'Joel M. Halpern'" , "'Andy Bierman'" References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> <563A97AA.5020308@joelhalpern.com> <005101d11798$549a6f10$fdcf4d30$@ndzh.com> <563B0750.70009@joelhalpern.com> In-Reply-To: <563B0750.70009@joelhalpern.com> Date: Thu, 5 Nov 2015 03:13:09 -0500 Message-ID: <00c501d117a1$d007ca40$70175ec0$@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: AQLwMtmz+XLO8+uQ7j5WaenA2rWXRwHVfCJTAW3ySwACzWyr4AJQYvqoAmia70sBb/tJ5QHaZBpQm9430cA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, 'Russ White' <7riw77@gmail.com> Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 08:13:21 -0000 Joel: Comments below. Thank you for your comment. Sue -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com] Sent: Thursday, November 05, 2015 2:38 AM To: Susan Hares; 'Joel M. Halpern'; 'Andy Bierman' Cc: i2rs@ietf.org; 'Russ White' Subject: Re: [i2rs] Conversation on Priority and Panes There are two VERY basic questions. [agreed] First, is the case of two I2RS clients modifying the same "thing" something we consider normal and desirable, or is it an error. The earlier discussions was that it is an error. In discussing the many different kinds of direct and indirect collateral issues that arise, we concluded that we could not expect the I2RS agent to be able to determine the "right" thing to do in the general case. [Sue: agreed - this is what we agreed upon. I am doing a "final check" on this concept before I ship off the requirements to the NETCONF. ] I have not seen any evidence that foer the general case we actually know this better now. And I do see a LOT of side effects and implications. [Sue: I am asking for the side effects so that I have an informed list and implications. You can send these to the list or to me individually.] My work with NETMOD/NETCONF has changed some of my views so I am asking this question to understand how it aligns with the new things I have learned. For a pure RIB node solution, we already have the tools for multiple writers. the existing RIB models already have the notion of multiple entries whose key differs by who created the entry. And the notion that the RIB manager decides. We could easily represent each I2RS client as a source, and let the RIB manager handle the rest. But this is a RIB only solution. [Sue: In my personal opinion, I think RIB only solution works for Protocol independent RIB, FB-RIB, and topology. ] My understanding of the WG conclusion was that we wanted a common solution for a broad range of cases, including the RIB. And that we were happy to treat collision as an error. If there is new information (I have not seen any) or if the WG has changed its mind, then so be it. We have not changed the WG conclusion to treat collision as an error. I am fact finding to see if others still see the list of problems. I am asking people to send the problem list to me or the list. As an example, if one is creating policy entries that make assumptions about your route entries being in efect, then having the system change what is in effect can produce very strange and unexpected behaviors. Are you concerned about the model changing or the data within a model changing? My understanding is the netconf module library yang module can provide model changing info. This is one way that the route policy make assumptions about the route. If the data changes regarding policy, these policy nodes can have version. In the gated implementation of this concept (10+ years ago), we used a policy node version in order to solve this problem. We also used a binary version of XML. Joel I appreciate your patience as I discuss pro/cons because I must defend our joint work to NETCONF. Yours, Joel On 11/5/15 2:05 AM, Susan Hares wrote: > Joel: > > > I agree that opening up the decision on caching will open a lot of issues. > In my mind, this email thread has shown there may be operational > issues with the "no-caching issue." We are about to send the > requirements to the IESG/NETCONF, and I want to validate the caching/no-caching decision. > > Let me give an example. > > Client 1 - priority 5 -- route1 nh 2 time 1 Client 2 - priority 6 -- > route1 nh 1 time 2 Client 3 - priority 4 -- route 1 nh 3 time 3 > Config - priority 0 - route 1 nh 4 time 2 > > Node = route with subnode nexthop > If you: > a) save the priority + Nh differences + priority + Time > b) assign config (lowest priority) + reboot tie then the priority > resolution can resolve the node. > > I believe this is the basic multiple creators concept you mentioned in > your emails for RIBs. I believe we agree that this is solvable. I do > not see how this fails to solve a partial RIB. > > Taking the P.I. Topology draft and FB-RIB, I think a similar > sequences can resolve the problem. If not, would you let me know the > example that does not fit. > > In our earlier discussions, we stated the grouping of nodes (route, > NH, > interfaces) did not fit the model. In my subsequent discuss with yang > folks, I came to realize a grouping of nodes which are under a > particular point and we could use this. > > Route ----------- > | \ | > Prefix Nh priority > > If this is true, then the model could provide language that handles > the grouping of variables or things being referred. This > understanding of the capability (which other I2RS WG members may have known) provides me a way to > model the grouping of parameters. So, I can perceive a possibility of > solving caching. > > Is this much of my question understandable? The next part of my > question was to inquire what do you see as some of the issues that we > need to consider on the panes of glass. > > > Sue > > > -----Original Message----- > From: Joel Halpern Direct [mailto:jmh.direct@joelhalpern.com] > Sent: Wednesday, November 04, 2015 6:42 PM > To: Susan Hares; 'Joel M. Halpern'; 'Andy Bierman' > Cc: i2rs@ietf.org; 'Russ White' > Subject: Re: [i2rs] Conversation on Priority and Panes > > The working group can always reconsider any decision. > But if we are going to do so, we need to recognize that the earlier > discussion covered a LOT of issues that need to be dealt with. > > I do not understand the question in the first part of your email, so I > can not comment on it. > > It is quite clear that caching is not required to meet a <1 second loop. > In particular, this seems to be a major change in another agreement. > We as a group concluded that over-write and other forms of collision > are errors. They are not the control loop for which we are > optimizing. The loop we said we are after is the loop from event > detection through analysis and response generation to response > application. That loop is completely unaffected by caching. > > So first, I think folks need to recognize that this discussion is > revisiting several different and related WG architectural agreements. > > Yours, > Joel > > On 11/4/15 5:23 PM, Susan Hares wrote: >> Joel: >> >> On the reading of composite panes, if you believe that ephemeral can >> be set on any configuration node or as an independent then the >> following >> >> Config-node-1 >> ephemeral node-1 (client 1), >> ephemeral Node-1 (client 2), >> >> Each ephemeral node could have an ID and a priority. The composite >> mode can apply a consistent policy: (E.g. high priority with tagging for >> first-wins). Asking for a composite in the rpc for read is a possible > use >> for the composite. Asking for all of these nodes is possible. >> >> I believe this caching is required for the "tight-loop" issue of < 1 >> second response for query/response. >> >> If we define the group issues in the Yang language, then I think we >> can handle the multiple I2RS ephemeral entries with more memory space. >> The amount of memory space used by the I2RS caching entries can be >> set by the implementation in the Agent, and expressed by the model >> capabilities. I agree with Andy's original position that Caching >> will be necessary for high performance on medium to large scale Data models. >> >> Lastly, I am not sure our consensus on the "no-caching" was strong >> enough to refuse to consider it now. Meaning less than 10 people in >> interims or email >> -- should not prevent a larger group from reconsidering. This is a >> different type of consensus as a long debate on list plus IETF > discussions. >> >> >> Sue >> -----Original Message----- >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. >> Halpern >> Sent: Tuesday, November 03, 2015 6:49 PM >> To: Andy Bierman; Susan Hares >> Cc: i2rs@ietf.org; Russ White >> Subject: Re: [i2rs] Conversation on Priority and Panes >> >> The basic problem I have with your description is that it treats >> over-writes as normal and desirable, and assumes that the priority >> handling is producing the correct results. If we actually believed >> that, I suppose making them more efficient would be sensible. >> >> But that is not actually what we are doing. Priority over-write is a >> disambiguation mechanism. There is no expectation that it is even a >> good heuristic for correctness. It is merely predictable. Trying to >> optimize the control loop for cases of improper behavior seems the >> wrong place to optimize. >> >> >> Having said that, if we want to get into multiple panes of ephemeral >> glass then we are going to need mechanisms to read the composite >> effect read what I as a client have applied indicate in the response >> to a write request that the agent has accepted the request, even >> though it is not actually taking effect. >> >> And if we do all that, clients whose state is pending will need to >> maintain monitoring of all related activities even though their >> network application is not in effect. >> >> And, if there are multiple aspect of an operation, if one gets >> over-written but retained, then the client probably can't leave it >> there, but has to go in and remove that state, since the client will >> likely be removing the rest of the related state that is still >> sitting > there with its lynchpin missing. >> >> And then we get into the question of how much unapplied state is an >> agent going to store. So it all probability the client still has to >> be prepared for being told that not only was its state over-written >> (which is technically an error) but that it got deleted too. >> >> Yours, >> Joel >> >> On 11/3/15 6:14 PM, Andy Bierman wrote: >>> Hi, >>> >>> This raises a data modeling issue. >>> Should every "backup parameter" be modeled explicitly in the YANG >>> module, or can the ephemeral datastore be used for that, without any >>> additional data model objects? >>> >>> The I2RS architecture supports this "backup" concept (lower priority >>> client), except it requires a notification from the agent and >>> subsequent request from the client to make the backup active. With >>> NETCONF or RESTCONF today, that round-trip will probably take around >>> 500 to 1000 milli-seconds. >>> Probably much worse during high loads. >>> >>> Our original proposal to the design team included a pane of glass >>> for each client (and unique priorities for each client), because >>> some people were talking about sub-milli-sec latency, and I know >>> there is no way NETCONF or RESTCONF is going to support this sort of >>> tight control >> loop. >>> >>> Whether the server rejects lower-priority edits right away, or >>> whether the agent caches the request in the form of a >>> client-specific pane, the client still needs to observe the data >>> resources with pub/sub and decide whether its own particular state is still relevant. >>> IMO the client complexity is the same either way, especially since >>> the caching is only done if the client requests it. >>> >>> The only difference is likely to be almost a million times faster >>> fail-over to the backup on the server. >>> >>> >>> Andy >>> >>> >>> >>> >>> On Mon, Nov 2, 2015 at 8:32 PM, Susan Hares >> > wrote: >>> >>> Russ thank you for kicking off this discussion. It is an > interesting >>> approach. I know that certain RIB implementations allows a back-up >>> route. >>> >>> Sue >>> >>> -----Original Message----- >>> From: i2rs [mailto:i2rs-bounces@ietf.org >>> ] On Behalf Of Russ White >>> Sent: Monday, November 02, 2015 7:39 PM >>> To: i2rs@ietf.org >>> Subject: [i2rs] Conversation on Priority and Panes >>> >>> Y'all -- >>> >>> After sleeping on the discussion last night, I think the panes of >>> glass (or >>> is it pains of glass?? :-) ) is still by and large another >>> expression of >>> the priority concept within I2RS. The concept does bring up >>> one >> specific >>> point of interest, however -- what about backup information? >>> Some >> vendor >>> RIBs, for instance, allow a routing process to install not >>> only the >> best >>> path as calculated by the process -- but if the process fails to >>> install, >>> some RIB implementations allow the process to place the route in the >>> "backup >>> pool." This allows the local RIB process to drop to the "second best >>> path," >>> in terms of priority, so the local RIB doesn't need to query >>> the >> routing >>> processes to switch in the case of a withdraw or change in topology. >>> >>> To convert this to I2RS terms, it does seem worthwhile to me >>> to have >> the >>> capability for a local agent to accept an install instruction >>> for > some >>> particular ephemeral state, and if the install fails, to hold that >>> state for >>> future use. This would apply to any sort of ephemeral data, >>> including that >>> which is configured locally on the network device. Rather than >>> trying >> to >>> think of this as "panes of glass," though, this would convert it to >>> simply a >>> backup list of lower priority items the local agent can use in the >>> case of >>> the failure of the highest priority item currently in use. >>> >>> The nice thing about this view is that it doesn't require a lot of >>> changes >>> at the protocol level. The only thing that needs to be >>> available is >> the >>> option for an agent to send three different types of answers to an >>> install >>> request -- >>> >>> 1. This ephemeral state was installed and is now being used. >>> 2. This ephemeral state was rejected/not installed -- with potential >>> codes >>> for why (out of range parameter, etc.) 3. This ephemeral state >>> was > not >>> installed, but is being held as a backup. >>> >>> Using these semantics, the actual implementation of such a feature >>> is up to >>> the local agent. It might be that some agents don't know how to hold >>> backup >>> information, or that it doesn't make any sense to hold some sorts of >>> information in a backup list. This is fine -- the install can >>> just > be >>> rejected without further note. Locally configured information could >>> simply >>> be treated as an item on the backup list, such that the priorities >>> can be >>> considered as always in deciding what to install when any particular >>> action >>> is taken. >>> >>> It seems, to me, that this is a simpler way to consider the >>> same >> problem >>> set, and reduces to an actual protocol mechanism that appears >>> (?) to >> be >>> fairly simple, and leaves as much flexibility as possible for >>> any >> given >>> agent implementation. >>> >>> Thoughts? >>> >>> :-) >>> >>> Russ >>> >>> _______________________________________________ >>> 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 >>> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> > From nobody Thu Nov 5 09:57:08 2015 Return-Path: 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 768D11B3212 for ; Thu, 5 Nov 2015 09:57:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_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 zzVaUieQDvbb for ; Thu, 5 Nov 2015 09:57:03 -0800 (PST) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (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 105841B320C for ; Thu, 5 Nov 2015 09:57:03 -0800 (PST) Received: by lfgh9 with SMTP id h9so61175080lfg.1 for ; Thu, 05 Nov 2015 09:57:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0QNFv/pNRGuG0jw3amW7PFci4DSJlBBPAZ6P3Gi0g+U=; b=cLcNk0Q+LEQyXykWrBKGtPnjMjMYWFuADd2iHaO6wCXx0geTs3kqvKdq6rZeY0QhKg b2tbkFiDLuooHzG6w6KRRVX43NAY9Iy5ULKPdC7Uedilmh86i2dVv/1VhXqJEMPw6hp4 61FpX2soms2RKPo+If69hqb97J/cuFuWNVsHTufNCUzNPNJNeFMaA6FHmyhTJyTdcN6u jnRsG5cqD3Vdj4P/gEiVTimlFu7npf1k6IQdg0BYrUKfYCntylfaYBp2h4/zh5lKN1KP MRiNYdj/Saw7HjUntKVLpooyT2dgVre2yJ8rX72Ygb0o+LUD0pH7p5DmFvE05y7jaXMd YuqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0QNFv/pNRGuG0jw3amW7PFci4DSJlBBPAZ6P3Gi0g+U=; b=QKi6pL6zKSr2qltN0rkUMRrEHnFXx4Acb5nmVz0CUq6HKf/186uNJmTjRj2ZfEOkmb Ti6pOJSOG6homy4re9nFfpGpS2m95cFfNOaccj4hetBTh6A21ukgQne5l1IdqrUv3Bxr L0+S1dt5tPsMXlWO862pacctyjZPuUQBFPbc/UnaaNJSfVhINqNDKhlaWnJNTs1Iwils mqtCtnomR/rtZl86FPFk+1omKRt5XkQgi49xXE3H43JppJ7pieS/XbesxiROD8JG6qWP nJKWT7iyZso8yw+cbuGxVwUocEofF5ASL+xDzpO5G1rhop3KrUX/6rU82PDyH2ZaTVDb rX9g== X-Gm-Message-State: ALoCoQl9dNEFR7Z9rMBUDC/wU5YgjUnhN38L+HwYBBs2Fl/slwVCCiafm24+3jZqgUbTH4LXbPnv MIME-Version: 1.0 X-Received: by 10.25.143.82 with SMTP id r79mr2604213lfd.123.1446746221181; Thu, 05 Nov 2015 09:57:01 -0800 (PST) Received: by 10.112.144.106 with HTTP; Thu, 5 Nov 2015 09:57:01 -0800 (PST) In-Reply-To: <034901d117a1$79a6e7d0$6cf4b770$@gmail.com> References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> <563A97AA.5020308@joelhalpern.com> <005101d11798$549a6f10$fdcf4d30$@ndzh.com> <563B0750.70009@joelhalpern.com> <034901d117a1$79a6e7d0$6cf4b770$@gmail.com> Date: Thu, 5 Nov 2015 09:57:01 -0800 Message-ID: From: Andy Bierman To: Russ White <7riw77@gmail.com> Content-Type: multipart/alternative; boundary=001a11401b1a9817970523ceda6c Archived-At: Cc: "i2rs@ietf.org" , "Joel M. Halpern" , Susan Hares Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 17:57:06 -0000 --001a11401b1a9817970523ceda6c Content-Type: text/plain; charset=UTF-8 On Thu, Nov 5, 2015 at 12:10 AM, Russ White <7riw77@gmail.com> wrote: > > > First, is the case of two I2RS clients modifying the same "thing" > > something we consider normal and desirable, or is it an error. The > earlier > > discussions was that it is an error. In discussing the many different > kinds of > > direct and indirect collateral issues that arise, we concluded that we > could > > not expect the I2RS agent to be able to determine the "right" thing to do > in > > the general case. > > So, assume the following -- > > 1. A local BGP process installs a route, 10.1.1.0/24 via 192.168.100.1 > 2. In order to move traffic off a "hot link" in a fabric, a > client/controller installs a route, 10.1.1.0/24 via 192.168.200.1 > 3. An attack vector is detected in a flow destined to some host on > 10.1.1.0/24 that causes a separate client/controller to install a route, > 10.1.1.0/24 via 192.168.150.1 for five seconds > > If I were the operator who owned this network, I wouldn't call this an > "error." I would call this "normal operation," -- in fact, the ability to > do > the above would be the very reason I would deploy I2RS on the network in > the > first place. Further, I would expect the entire process to unwind properly > and _quickly_. I don't care how it happens, I just want the removal of the > second client's route to leave the first client's in the table as the > current route, and the removal of the first client's path leave the BGP > route as the best path. To go farther, why are there client priorities at > all if this is an "error?" If all overwrites of "ephemeral state" are an > error, the agent should simply reject any attempt to overwrite any such > state. > > I agree that a priority override is not an error. In a multi-client environment, client A is not going to know about the other clients added to the system. This is true whether the clients are primary or secondary behind a broker. The notification to a client that some or all of its data was just overridden is a separate matter from whether the client wants all or part of its data to be removed or altered. One proposal to the design team is the notion that the server supports an advertised (static) number of clients (max client panes). Each client must be assigned a priority, such that every client has its own pane, so adding a valid edit does not fail. Activating the edit is a separate matter. Each client can flush all or part of its own pane. :-) > > Russ > > Andy --001a11401b1a9817970523ceda6c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Nov 5, 2015 at 12:10 AM, Russ White <7riw77@gmail.com> wrote:

> First, is the case of two I2RS clients modifying the same "thing&= quot;
> something we consider normal and desirable, or is it an error.=C2=A0 T= he
earlier
> discussions was that it is an error.=C2=A0 In discussing the many diff= erent
kinds of
> direct and indirect collateral issues that arise, we concluded that we=
could
> not expect the I2RS agent to be able to determine the "right"= ; thing to do
in
> the general case.

So, assume the following --

1. A local BGP process installs a route, 10.1.1.0/24 via 192.168.100.1
2. In order to move traffic off a "hot link" in a fabric, a
client/controller installs a route, 10.1.1.0/24 via 192.168.200.1
3. An attack vector is detected in a flow destined to some host on
10.1.1.= 0/24 that causes a separate client/controller to install a route,
10.1.1.= 0/24 via 192.168.150.1 for five seconds

If I were the operator who owned this network, I wouldn't call this an<= br> "error." I would call this "normal operation," -- in fa= ct, the ability to do
the above would be the very reason I would deploy I2RS on the network in th= e
first place. Further, I would expect the entire process to unwind properly<= br> and _quickly_. I don't care how it happens, I just want the removal of = the
second client's route to leave the first client's in the table as t= he
current route, and the removal of the first client's path leave the BGP=
route as the best path. To go farther, why are there client priorities at all if this is an "error?" If all overwrites of "ephemeral s= tate" are an
error, the agent should simply reject any attempt to overwrite any such
state.



I agree that a priority= override is not an error. In a multi-client environment,
client = A is not going to know about the other clients added to the system.
This is true whether the clients are primary or secondary behind a broke= r.

The notification to a client that some or all o= f its data was just overridden
is a separate matter from whether = the client wants all or part of its
data to be removed or altered= .

One proposal to the design team is the notion th= at the server
supports an advertised (static) number of clients (= max client panes).
Each client must be assigned a priority, such = that every client
has its own pane, so adding a valid edit does n= ot fail. Activating
the edit is a separate matter. Each client ca= n flush all or part of its own pane.


:-)

Russ



<= /div>
Andy

--001a11401b1a9817970523ceda6c-- From nobody Thu Nov 5 17:19:21 2015 Return-Path: <7riw77@gmail.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 EA8E01B29F8 for ; Thu, 5 Nov 2015 17:19:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_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 4UF7jo3C9SIp for ; Thu, 5 Nov 2015 17:19:18 -0800 (PST) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (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 BF01F1B2A4E for ; Thu, 5 Nov 2015 17:18:34 -0800 (PST) Received: by pacdm15 with SMTP id dm15so79944609pac.3 for ; Thu, 05 Nov 2015 17:18:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=fSHDn5bEkjYkeIOoGT0GmxPg1mgodfOt4CI078F39RQ=; b=BD/ewbx7GT4jlTktC3MCcJ8zryqebeQzRUjtbP5slJ9fQx0B+WglXk6zpuwRMIkQgy oijs0nosGJIKSjwE3U/JPtOZTRXyDSGaBTxQ/Cn539poH16ExUBI29GJ0DQQr7RTTul1 BwjBTyyLqJ6YOZysUEcl1EPw8x0B3YOAKBH7DuHav70agBaOWioG5162ekM0h0XEPO9/ 4j/e1GuC9kKOmEy76Mgi+pJrdWWJ919DXmHzteRY2+iK9bK+OMBEh1AqUBuUZyLmJcS0 50w/0ggR7vq7ad9P5h0imWLOAONHoTsICoIaKXRbButVJ2efM0wvIvkX4OFrnvzCdzdS asXA== X-Received: by 10.66.216.233 with SMTP id ot9mr13298654pac.148.1446772714383; Thu, 05 Nov 2015 17:18:34 -0800 (PST) Received: from Russ ([210.143.141.82]) by smtp.gmail.com with ESMTPSA id hz4sm8067464pbc.12.2015.11.05.17.18.30 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Nov 2015 17:18:33 -0800 (PST) From: "Russ White" <7riw77@gmail.com> To: "'Andy Bierman'" References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> <563A97AA.5020308@joelhalpern.com> <005101d11798$549a6f10$fdcf4d30$@ndzh.com> <563B0750.70009@joelhalpern.com> <034901d117a1$79a6e7d0$6cf4b770$@gmail.com> In-Reply-To: Date: Thu, 5 Nov 2015 20:18:22 -0500 Message-ID: <025101d11831$0b46d2b0$21d47810$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLwMtmz+XLO8+uQ7j5WaenA2rWXRwHVfCJTAW3ySwACzWyr4AJQYvqoAmia70sBb/tJ5QHaZBpQAchizYgBnpuM25vEHvFw Content-Language: en-us Archived-At: Cc: i2rs@ietf.org, "'Joel M. Halpern'" , 'Susan Hares' Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 01:19:20 -0000 > The notification to a client that some or all of its data was just = overridden is a > separate matter from whether the client wants all or part of its data = to be > removed or altered. I would argue this should be a SHOULD... The idea would be that any = client who sets state should be subscribed, but anyone can unsubscribe. = This leaves the default to the "right thing," but gives clients the = option to sort their own "aggregation" of signaling for efficiency/etc. = I'm uncertain about the unsubscribe at this point -- I tend to think we = shouldn't bother with "auto-unsubscribe on remove state," as we can't = guess either way, and it's just as easy for clients to queue up the = removal of state and the unsubscribe one after the other. Not convinced this is the right answer, though -- thoughts? > One proposal to the design team is the notion that the server supports = an > advertised (static) number of clients (max client panes). > Each client must be assigned a priority, such that every client has = its own > pane, so adding a valid edit does not fail. Activating the edit is a = separate > matter. Each client can flush all or part of its own pane. Just to clarify, I think we're all saying the same thing, just using = different terms. If each client must have a unique id, and the client id = is directly tied to the priority of the client in terms of installing = state, then the pane is also "everything with the same priority," which = also means "everything installed by one client." So in relation to the = state of a single object, the list of "lower priority" things that = aren't installed can be seen as what Joel is calling a "cache." From the = perspective of the client, all the state it has installed can be seen as = a "pane."=20 Does this sound right to everyone? One point -- it might not be valid for each type of object to have this = sort of "backup information." For instance, in the case of a virtual = topology built in ephemeral state, it might well be the case (I've not = thought it through yet) that it is an error to overwrite lower priority = information with higher. To Joel's point, the backup data (I don't like the term "cache," because = it has a different set of connotations for me, but I can deal with it if = that's the term everyone settles on) could introduce a lot of complexity = unless we also introduce the idea of a set of "things" as a "whole = object." In other words, in the case of a route, a "whole object" might = include the reachable destination (NLRI in BGP terms), the next hop = (which could be a tunnel tail end from the local router's perspective), = potentially a stack of markers (like an MPLS label stack), potentially = an outbound interface, and potentially a MAC header rewrite. This entire = "object" would need to be installed as one "thing," think, to make the = "cache" coherent (again, I could be wrong here). To change just the = "next hop," a client would need to install "the whole route," I think, = or we risk some major issues in coherency. I'm not saying this is = possible/not possible today, just throwing out thoughts as they occur to = me. Does all of this make sense? :-) Russ From nobody Thu Nov 5 17:45:41 2015 Return-Path: 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 E1B791A86E3 for ; Thu, 5 Nov 2015 17:45:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 JFsckgI46wed for ; Thu, 5 Nov 2015 17:45:39 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 559A11A6F17 for ; Thu, 5 Nov 2015 17:45:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4027; q=dns/txt; s=iport; t=1446774339; x=1447983939; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=WnRJdx5muCXMQ0X/7t2gcvzXcTz6zGV3eRtf2MCWW1E=; b=MNkwDtmd2XuSW1EhubA9q7f2+0OKX7FGaVpu6dQ/5hZ6JL7VfOdEQUdP QGIVUrYwLhJ5mZkzrZS4U5WMV04DNs4HYL/BnfEs+ynfhYS2+Xi2JtMdy srEQR6nYi86iVzVmxKBNv8OfnkTIwvwpTmjF5uF0uaiZKMo7NRY+Gn75p k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D0AQDoBTxW/4YNJK1egzu/SwENgV+GE?= =?us-ascii?q?AKBPTgUAQEBAQEBAYEKhDUBAQEDATgWJAYBEAsOCgkWDwkDAgECAR8mBgEHBQg?= =?us-ascii?q?BARkEiAUIwRUBAQEBAQEBAQEBAQEBAQEBAQEBGoZUhH6EISGEdwEEjhGIN40ji?= =?us-ascii?q?RuTJx8BAUKEIiCFUwEBAQ?= X-IronPort-AV: E=Sophos;i="5.20,249,1444694400"; d="scan'208";a="205013195" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Nov 2015 01:45:38 +0000 Received: from [10.24.83.247] ([10.24.83.247]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id tA61jaKb027589; Fri, 6 Nov 2015 01:45:37 GMT To: Russ White <7riw77@gmail.com>, "'Andy Bierman'" References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> <563A97AA.5020308@joelhalpern.com> <005101d11798$549a6f10$fdcf4d30$@ndzh.com> <563B0750.70009@joelhalpern.com> <034901d117a1$79a6e7d0$6cf4b770$@gmail.com> <025101d11831$0b46d2b0$21d47810$@gmail.com> From: Joe Clarke Organization: Cisco Systems, Inc. Message-ID: <563C0640.5050202@cisco.com> Date: Thu, 5 Nov 2015 20:45:36 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <025101d11831$0b46d2b0$21d47810$@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: i2rs@ietf.org, "'Joel M. Halpern'" , 'Susan Hares' Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 01:45:41 -0000 On 11/5/15 20:18, Russ White wrote: >> The notification to a client that some or all of its data was just overridden is a >> separate matter from whether the client wants all or part of its data to be >> removed or altered. > > I would argue this should be a SHOULD... The idea would be that any client who sets state should be subscribed, but anyone can unsubscribe. This leaves the default to the "right thing," but gives clients the option to sort their own "aggregation" of signaling for efficiency/etc. I'm uncertain about the unsubscribe at this point -- I tend to think we shouldn't bother with "auto-unsubscribe on remove state," as we can't guess either way, and it's just as easy for clients to queue up the removal of state and the unsubscribe one after the other. > > Not convinced this is the right answer, though -- thoughts? I don't think we should assume that just because the client removes state it wants to unsubscribe from the stream. It may want to watch what's going on for events where it can reinsert itself (as an example). > >> One proposal to the design team is the notion that the server supports an >> advertised (static) number of clients (max client panes). >> Each client must be assigned a priority, such that every client has its own >> pane, so adding a valid edit does not fail. Activating the edit is a separate >> matter. Each client can flush all or part of its own pane. > > Just to clarify, I think we're all saying the same thing, just using different terms. If each client must have a unique id, and the client id is directly tied to the priority of the client in terms of installing state, then the pane is also "everything with the same priority," which also means "everything installed by one client." So in relation to the state of a single object, the list of "lower priority" things that aren't installed can be seen as what Joel is calling a "cache." From the perspective of the client, all the state it has installed can be seen as a "pane." > > Does this sound right to everyone? Yes, this gels with my understanding. > > One point -- it might not be valid for each type of object to have this sort of "backup information." For instance, in the case of a virtual topology built in ephemeral state, it might well be the case (I've not thought it through yet) that it is an error to overwrite lower priority information with higher. > > To Joel's point, the backup data (I don't like the term "cache," because it has a different set of connotations for me, but I can deal with it if that's the term everyone settles on) could introduce a lot of complexity unless we also introduce the idea of a set of "things" as a "whole object." In other words, in the case of a route, a "whole object" might include the reachable destination (NLRI in BGP terms), the next hop (which could be a tunnel tail end from the local router's perspective), potentially a stack of markers (like an MPLS label stack), potentially an outbound interface, and potentially a MAC header rewrite. This entire "object" would need to be installed as one "thing," think, to make the "cache" coherent (again, I could be wrong here). To change just the "next hop," a client would need to install "the whole route," I think, or we risk some major issues in coherency. I'm not saying this is possible/not possible today, just throwing out thoughts as they occur to me. > > Does all of this make sense? It does. One other point that Jason Coleman, Jason Sterne and I were discussing yesterday is how we handle config in this same pane of glass model. That is, if I want to override a route via config, how would that work with existing ephemeral state? The idea proposed was to be able to assign a priority to those [static] routes that would, in essence, make them ephemeral with the associated priority. This would allow one from the CLI participate in the I2RS process. There might be other options, but this made a lot of sense at the time. Joe From nobody Fri Nov 6 19:20:53 2015 Return-Path: <7riw77@gmail.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 E8FE61ACD4A for ; Fri, 6 Nov 2015 19:20:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_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 35JCua_SxTaJ for ; Fri, 6 Nov 2015 19:20:51 -0800 (PST) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (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 BBE5F1ACD49 for ; Fri, 6 Nov 2015 19:20:51 -0800 (PST) Received: by ykek133 with SMTP id k133so204559956yke.2 for ; Fri, 06 Nov 2015 19:20:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=/SCBwvxlAnQWExPyIv1OXCjJcG8t2zBOIeYPg7JYy4Y=; b=yHBUl/KQZFK9kbvlgcFAJjIRIisMB8w11rsfeo8eO0UTv2+kJ4uDRqvKHXvzvNF8Gg bqtTUdmPEqQgMI9WV/PLYlgfMX0L9Jo+67+Wpnm1jP9EtzOWMJ+CAP/H8zNOQgnnpp12 S/17TP/ShA1wpeIq5/E7/qodCkOeUxq5b20s2jrXRETTaUsaYhw73lIdQmwTMeKopcvK Wgby720icsN/P2M/pQu8AXF6s5Qf+X785jj1v0vIY86LCXXUtSyEKOKNdgp106uDCU+q HHbzepOcCDfqLJkqtJUjpXRcPjn+alknXyaPYooZkBzM5qwb7MW49/qB6fz30AxPM/QP U3nA== X-Received: by 10.129.105.213 with SMTP id e204mr13655489ywc.61.1446866450994; Fri, 06 Nov 2015 19:20:50 -0800 (PST) Received: from Russ ([2602:30a:2e5b:44d0:3cd8:8bbc:8ab9:be38]) by smtp.gmail.com with ESMTPSA id g65sm2540096ywa.30.2015.11.06.19.20.50 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Nov 2015 19:20:50 -0800 (PST) From: "Russ White" <7riw77@gmail.com> To: "'Joe Clarke'" , "'Andy Bierman'" References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> <563A97AA.5020308@joelhalpern.com> <005101d11798$549a6f10$fdcf4d30$@ndzh.com> <563B0750.70009@joelhalpern.com> <034901d117a1$79a6e7d0$6cf4b770$@gmail.com> <025101d11831$0b46d2b0$21d47810$@gmail.com> <563C0640.5050202@cisco.com> In-Reply-To: <563C0640.5050202@cisco.com> Date: Fri, 6 Nov 2015 22:20:49 -0500 Message-ID: <048301d1190b$4d536260$e7fa2720$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLwMtmz+XLO8+uQ7j5WaenA2rWXRwHVfCJTAW3ySwACzWyr4AJQYvqoAmia70sBb/tJ5QHaZBpQAchizYgBnpuM2wKxWRn7AbJPt22borec4A== Content-Language: en-us Archived-At: Cc: i2rs@ietf.org, "'Joel M. Halpern'" , 'Susan Hares' Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2015 03:20:53 -0000 > It does. One other point that Jason Coleman, Jason Sterne and I were > discussing yesterday is how we handle config in this same pane of glass > model. That is, if I want to override a route via config, how would > that work with existing ephemeral state? > > The idea proposed was to be able to assign a priority to those [static] > routes that would, in essence, make them ephemeral with the associated > priority. This would allow one from the CLI participate in the I2RS > process. Static routes are always the monster under the bed for this sort of stuff... The main problem (it seems to me) is how they've been implemented over the years -- I don't know enough about every implementation to know if treating them as "just another process" would be painful. Here's where some folks currently maintaining actual code stepping in and saying, "this would be really painful," or, "this wouldn't be a problem," would be really helpful. If it's going to be painful, then we might need some way to indicate which clients can do what. I think the main problem with this entire way of looking at things is Joel's point on complexity, particularly in the agent. It would also be helpful to try and nail what that complexity looks like, and if there is any way to reduce it, such as -- Would treating a complete set of "things" as a single "object" that cannot be broken apart be helpful? What do those sets of things look like? Would limiting this sort of capability to a small number of objects in the model be helpful in some way? IE, this doesn't seem useful to me for links, but it does for routes. Can we figure out what the use cases are, and try to limit the number of objects for which such a capability is to a minimal number? Would it be helpful to combine these two concepts? IE, only objects that can be treated as a "single atomic thing" can have a backup? Is it useful to tie these concepts together to limit the scope of adding more than one plane to the object? I don't know the answers here, just trying to find a middle path that works, and doesn't introduce too much complexity in return. :-) Russ From nobody Fri Nov 6 20:04:01 2015 Return-Path: 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 24D4E1ACF6C for ; Fri, 6 Nov 2015 20:04:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_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 WTKxcpiwqb7Z for ; Fri, 6 Nov 2015 20:03:58 -0800 (PST) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (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 A2B9C1AD055 for ; Fri, 6 Nov 2015 20:03:57 -0800 (PST) Received: by lbces9 with SMTP id es9so186521lbc.2 for ; Fri, 06 Nov 2015 20:03:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9+f6UQHxzOD/iqbfUe5giRmh2KOp14G9qyBOiMtbcwM=; b=PxY09HQXWXhF1AQKkl4dp4p5Hkg4sC581+vGuZH4pRQ/mvpa2D5dFt8NHtPwLboZYc jUnO5YY0oSV4s4BVhQEbEo4PLHOLz94lWTuhMIvN+sTy5gSfarnSbsfHO8GRT4f6Enpq OHzBavc5m/WOQJCUh7tj8UA0uoDnp1In5jk30ZVCQqblEvNhuV7in4SX/UAfCi9s8ESO SoKf+TEBJm4a3ZXSFf6YXlMZgF4LGda9KJLZcDBEfzj5JTOErr44x4c19ldxnsGAvwc/ qQG6tGHVyadDV0cAh2lHh7OK9aayRQ7pzqUp8lCgwW4V7FXlgZjMxy+GZXJY8iaqXu5u tWew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9+f6UQHxzOD/iqbfUe5giRmh2KOp14G9qyBOiMtbcwM=; b=d+k98FejFBKZw1VWSfq/KjrezwCYHKsWsG4RE3sXNIOyJf5cTL5Of04cefTPVXFlAg PfEgVaJ5Mcb+6InDEAQjrlcbyAJ+8WrGDJYTDW+d6NSrywH5MJDTPiKsJmy4NBO1WF/b wxFWAUD/tz1AhXu5ICqzb9K37KPTihb0RCuy4VQ+XPTh55b7nlwfS/FXKVAhjYVxEB4H EJRutb5w18xtBMWtAc42S+B0r1aQOz+hSom6+cnlf1ZnNYRDTTKVfhtjnU4easV3qW+9 UtNRAM2shoaaj3GMLCDr9vdjD3l67F4yWc8Wn6Pf3dRlRpN4U5Jy4DIfh2QMu667abL2 CvNA== X-Gm-Message-State: ALoCoQlrdPllkkk4NAGWg43UJU8pbUzU3I24ClnnNxZZRLqqZQzGoX4/Y2ZiF/5sgyJPwVIgadAO MIME-Version: 1.0 X-Received: by 10.112.135.136 with SMTP id ps8mr8414727lbb.38.1446869035770; Fri, 06 Nov 2015 20:03:55 -0800 (PST) Received: by 10.112.144.106 with HTTP; Fri, 6 Nov 2015 20:03:55 -0800 (PST) In-Reply-To: <048301d1190b$4d536260$e7fa2720$@gmail.com> References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> <563A97AA.5020308@joelhalpern.com> <005101d11798$549a6f10$fdcf4d30$@ndzh.com> <563B0750.70009@joelhalpern.com> <034901d117a1$79a6e7d0$6cf4b770$@gmail.com> <025101d11831$0b46d2b0$21d47810$@gmail.com> <563C0640.5050202@cisco.com> <048301d1190b$4d536260$e7fa2720$@gmail.com> Date: Fri, 6 Nov 2015 20:03:55 -0800 Message-ID: From: Andy Bierman To: Russ White <7riw77@gmail.com> Content-Type: multipart/alternative; boundary=089e01160712ea00c10523eb7289 Archived-At: Cc: "i2rs@ietf.org" , Joe Clarke , Susan Hares , "Joel M. Halpern" Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2015 04:04:00 -0000 --089e01160712ea00c10523eb7289 Content-Type: text/plain; charset=UTF-8 On Fri, Nov 6, 2015 at 7:20 PM, Russ White <7riw77@gmail.com> wrote: > > It does. One other point that Jason Coleman, Jason Sterne and I were > > discussing yesterday is how we handle config in this same pane of glass > > model. That is, if I want to override a route via config, how would > > that work with existing ephemeral state? > > > > The idea proposed was to be able to assign a priority to those [static] > > routes that would, in essence, make them ephemeral with the associated > > priority. This would allow one from the CLI participate in the I2RS > > process. > > Static routes are always the monster under the bed for this sort of > stuff... > The main problem (it seems to me) is how they've been implemented over the > years -- I don't know enough about every implementation to know if treating > them as "just another process" would be painful. Here's where some folks > currently maintaining actual code stepping in and saying, "this would be > really painful," or, "this wouldn't be a problem," would be really helpful. > If it's going to be painful, then we might need some way to indicate which > clients can do what. > The RESTCONF server has its own internal mechanisms to deal with the interface between the protocol and the internal instrumentation. To some degree, this hides ordering details, etc. from the client. > I think the main problem with this entire way of looking at things is > Joel's > point on complexity, particularly in the agent. It would also be helpful to > try and nail what that complexity looks like, and if there is any way to > reduce it, such as -- > > Would treating a complete set of "things" as a single "object" that cannot > be broken apart be helpful? What do those sets of things look like? > > This is exactly the sort of thing that the YANG model needs to tell the server in machine-readable terms. Implementation of stop-on-error and continue-on-error is actually harder than it seems. We never leave invalid data in the running datastore. Pruning the error data and just accepting the good data is mostly arbitrary, wrt/ pruning the least amount of the ancestor subtree. Pruning data can cause a ripple effect wrt/ other validation rules, such as must/mandatory/min-elements. Knowing what constitutes a complete set of a "thing" is not in scope in YANG. IMO, YANG Packages could solve this problem. ;-) Would limiting this sort of capability to a small number of objects in the > model be helpful in some way? IE, this doesn't seem useful to me for links, > but it does for routes. Can we figure out what the use cases are, and try > to > limit the number of objects for which such a capability is to a minimal > number? > Yes -- this is the purpose of the "ephemeral true | false" statement that we want to add to YANG. It could be added to a data model (either directly or from another module somehow) to indicate what an I2RS server is expected to support. > Would it be helpful to combine these two concepts? IE, only objects that > can > be treated as a "single atomic thing" can have a backup? Is it useful to > tie > these concepts together to limit the scope of adding more than one plane to > the object? > > What if the nature of "single atomic thing" is use-case specific or even operator preference specific? As soon as you have 2 use-cases that can share the same data, the possibility of an edit-collision from normal operation exists. It also may not really be safe to have the ephemeral client take over entire sub-trees (e.g. replace instead of merge). There could be new nodes or augmentations unknown to the ephemeral client that may not need to be disabled. I don't know the answers here, just trying to find a middle path that works, > and doesn't introduce too much complexity in return. > :-) > > Russ > > Andy --089e01160712ea00c10523eb7289 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Nov 6, 2015 at 7:20 PM, Russ White <7riw77@gmail.com> wrote:
> It does.=C2=A0 One other= point that Jason Coleman, Jason Sterne and I were
> discussing yesterday is how we handle config in this same pane of glas= s
> model.=C2=A0 That is, if I want to override a route via config, how wo= uld
> that work with existing ephemeral state?
>
> The idea proposed was to be able to assign a priority to those [static= ]
> routes that would, in essence, make them ephemeral with the associated=
> priority.=C2=A0 This would allow one from the CLI participate in the I= 2RS
> process.

Static routes are always the monster under the bed for this sort of stuff..= .
The main problem (it seems to me) is how they've been implemented over = the
years -- I don't know enough about every implementation to know if trea= ting
them as "just another process" would be painful. Here's where= some folks
currently maintaining actual code stepping in and saying, "this would = be
really painful," or, "this wouldn't be a problem," would= be really helpful.
If it's going to be painful, then we might need some way to indicate wh= ich
clients can do what.

The RESTCONF serve= r has its own internal mechanisms to deal
with the interface betw= een the protocol and the internal instrumentation.
To some degree= , this hides ordering details, etc. from the client.


I think the main problem with this entire way of looking at things is Joel&= #39;s
point on complexity, particularly in the agent. It would also be helpful to=
try and nail what that complexity looks like, and if there is any way to reduce it, such as --

Would treating a complete set of "things" as a single "objec= t" that cannot
be broken apart be helpful? What do those sets of things look like?



This is exactly the sor= t of thing that the YANG model needs to tell
the server in machin= e-readable terms. =C2=A0 Implementation of stop-on-error
and cont= inue-on-error is actually harder than it seems.=C2=A0
We never le= ave invalid data in the running datastore.
Pruning the error data= and just accepting the good data is
mostly arbitrary, wrt/ pruni= ng the least amount of the ancestor subtree.
Pruning data can cau= se a ripple effect wrt/ other validation rules,
such as must/mand= atory/min-elements.

Knowing what constitutes a com= plete set of a "thing" is not in scope in YANG.
IMO, YA= NG Packages could solve this problem. ;-)


Would limiting this sort of capability to a small number of objects in the<= br> model be helpful in some way? IE, this doesn't seem useful to me for li= nks,
but it does for routes. Can we figure out what the use cases are, and try t= o
limit the number of objects for which such a capability is to a minimal
number?


Yes -- this is t= he purpose of the "ephemeral true | false" statement
th= at we want to add to YANG.=C2=A0 It could be added to a data model
(either directly or from another module somehow) to indicate what
an I2RS server is expected to support.



Would it be helpful to combine these two concepts? IE, only objects that ca= n
be treated as a "single atomic thing" can have a backup? Is it us= eful to tie
these concepts together to limit the scope of adding more than one plane to=
the object?


What if the nature of "single ato= mic thing" is use-case specific or
even operator preference = specific?

As soon as you have 2 use-cases that can= share the same data,
the possibility of an edit-collision from n= ormal operation exists.

It also may not really be = safe to have the ephemeral client take over
entire sub-trees (e.g= . replace instead of merge).=C2=A0 There could be
new nodes or au= gmentations unknown to the ephemeral client
that may not need to = be disabled.



I don't know the answers here, just trying to find a middle path that w= orks,
and doesn't introduce too much complexity in return.=C2=A0
=

:-)

Russ


Andy<= /div>

--089e01160712ea00c10523eb7289-- From nobody Sun Nov 8 06:37:02 2015 Return-Path: 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 1A5DD1B2DC0 for ; Sun, 8 Nov 2015 06:37:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.1 X-Spam-Level: X-Spam-Status: No, score=-100.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 zKh-htEL1Eoc for ; Sun, 8 Nov 2015 06:36:57 -0800 (PST) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (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 B53C81B2DBF for ; Sun, 8 Nov 2015 06:36:57 -0800 (PST) Received: by oiww189 with SMTP id w189so64259169oiw.3 for ; Sun, 08 Nov 2015 06:36:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ey6Ds73StaRNuBUVaRFt6p4+91RHM+NKuoOt1R3ABj4=; b=ILEdP+TohQz99MS/WFc+W5GLl9eE8RbAWljbMYkL31htkVvpqno29Hgm9TtmukmSQc 94g91H6he6Ncvwe4cRSSTWfN945p0JUbsiZMpz4AJFY+FrMgMAr/stgDneAzi3povB6N p5zTU5EDKy5SBnMHlJD4ropbqzZ37lfavJ+pt1G7xABeX0oPMde0pdm4ZmG/LVvxg+EI 9g35fr31LmYHqzBZK8RGH9SW5gwZrW5wrdy+TomRD1ifW2/lK1Ism9/pja5zQK4JGdEL Xw9gT+M22loF8M/B4AqoDs0/+4cAkeI7h1+mO6M6BVqr3ZwyquaFF/rWXJLdmF1ky/Fl xFcQ== MIME-Version: 1.0 X-Received: by 10.202.97.196 with SMTP id v187mr13541638oib.91.1446993417045; Sun, 08 Nov 2015 06:36:57 -0800 (PST) Received: by 10.60.6.132 with HTTP; Sun, 8 Nov 2015 06:36:56 -0800 (PST) In-Reply-To: References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> <563A97AA.5020308@joelhalpern.com> <005101d11798$549a6f10$fdcf4d30$@ndzh.com> <563B0750.70009@joelhalpern.com> <034901d117a1$79a6e7d0$6cf4b770$@gmail.com> Date: Sun, 8 Nov 2015 09:36:56 -0500 Message-ID: From: Alia Atlas To: Andy Bierman Content-Type: multipart/alternative; boundary=001a113d39389d8e9c0524086841 Archived-At: Cc: "i2rs@ietf.org" , "Joel M. Halpern" , Susan Hares , Russ White <7riw77@gmail.com> Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2015 14:37:00 -0000 --001a113d39389d8e9c0524086841 Content-Type: text/plain; charset=UTF-8 Hi Russ & Andy, I certainly understand the desire for different behavior when a priority override happens. However, this is one area where the working group was extremely clear. Sue and I had ideas of store-if-not-best and handling overwrites and so on. There was a very clear push back against any such complexity. Feel free to take a read through the archive. While it is tempting to expand the scope and functionality of I2RS to handle this as not an error, I would ask that we respect the WG consensus and get agreement and implementations going on the basics. We have a serious case of too many saying "This is an interesting soup. Let's watch it." and far too few people putting wood on the fire and experimenting. Regards, Alia On Thu, Nov 5, 2015 at 12:57 PM, Andy Bierman wrote: > > > On Thu, Nov 5, 2015 at 12:10 AM, Russ White <7riw77@gmail.com> wrote: > >> >> > First, is the case of two I2RS clients modifying the same "thing" >> > something we consider normal and desirable, or is it an error. The >> earlier >> > discussions was that it is an error. In discussing the many different >> kinds of >> > direct and indirect collateral issues that arise, we concluded that we >> could >> > not expect the I2RS agent to be able to determine the "right" thing to >> do >> in >> > the general case. >> >> So, assume the following -- >> >> 1. A local BGP process installs a route, 10.1.1.0/24 via 192.168.100.1 >> 2. In order to move traffic off a "hot link" in a fabric, a >> client/controller installs a route, 10.1.1.0/24 via 192.168.200.1 >> 3. An attack vector is detected in a flow destined to some host on >> 10.1.1.0/24 that causes a separate client/controller to install a route, >> 10.1.1.0/24 via 192.168.150.1 for five seconds >> >> If I were the operator who owned this network, I wouldn't call this an >> "error." I would call this "normal operation," -- in fact, the ability to >> do >> the above would be the very reason I would deploy I2RS on the network in >> the >> first place. Further, I would expect the entire process to unwind properly >> and _quickly_. I don't care how it happens, I just want the removal of the >> second client's route to leave the first client's in the table as the >> current route, and the removal of the first client's path leave the BGP >> route as the best path. To go farther, why are there client priorities at >> all if this is an "error?" If all overwrites of "ephemeral state" are an >> error, the agent should simply reject any attempt to overwrite any such >> state. >> >> > > I agree that a priority override is not an error. In a multi-client > environment, > client A is not going to know about the other clients added to the system. > This is true whether the clients are primary or secondary behind a broker. > > The notification to a client that some or all of its data was just > overridden > is a separate matter from whether the client wants all or part of its > data to be removed or altered. > > One proposal to the design team is the notion that the server > supports an advertised (static) number of clients (max client panes). > Each client must be assigned a priority, such that every client > has its own pane, so adding a valid edit does not fail. Activating > the edit is a separate matter. Each client can flush all or part of its > own pane. > > > :-) >> >> Russ >> >> > > Andy > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > --001a113d39389d8e9c0524086841 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Russ & Andy,

I certainly underst= and the desire for different behavior when a priority override happens.
However, this is one area where the working group was extremely clea= r.=C2=A0 Sue and I had
ideas of store-if-not-best and handling ov= erwrites and so on.=C2=A0 There was a very clear
push back agains= t any such complexity.=C2=A0 Feel free to take a read through the archive.<= /div>

While it is tempting to expand the scope and funct= ionality of I2RS to handle this as not
an error, I would ask that= we respect the WG consensus and get agreement and implementations
going on the basics.

We have a serious case of t= oo many saying "This is an interesting soup.=C2=A0 Let's watch it.= " and
far too few people putting wood on the fire and experi= menting.

Regards,
Alia

On Thu, Nov 5, 2015 at = 12:57 PM, Andy Bierman <andy@yumaworks.com> wrote:

<= br>
On Thu, Nov 5, 2015 at= 12:10 AM, Russ White <7riw77@gmail.com> wrote:

> First, is the case of two I2RS clients modifying the same "thing&= quot;
> something we consider normal and desirable, or is it an error.=C2=A0 T= he
earlier
> discussions was that it is an error.=C2=A0 In discussing the many diff= erent
kinds of
> direct and indirect collateral issues that arise, we concluded that we=
could
> not expect the I2RS agent to be able to determine the "right"= ; thing to do
in
> the general case.

So, assume the following --

1. A local BGP process installs a route, 10.1.1.0/24 via 192.168.100.1
2. In order to move traffic off a "hot link" in a fabric, a
client/controller installs a route, 10.1.1.0/24 via 192.168.200.1
3. An attack vector is detected in a flow destined to some host on
10.1.1.= 0/24 that causes a separate client/controller to install a route,
10.1.1.= 0/24 via 192.168.150.1 for five seconds

If I were the operator who owned this network, I wouldn't call this an<= br> "error." I would call this "normal operation," -- in fa= ct, the ability to do
the above would be the very reason I would deploy I2RS on the network in th= e
first place. Further, I would expect the entire process to unwind properly<= br> and _quickly_. I don't care how it happens, I just want the removal of = the
second client's route to leave the first client's in the table as t= he
current route, and the removal of the first client's path leave the BGP=
route as the best path. To go farther, why are there client priorities at all if this is an "error?" If all overwrites of "ephemeral s= tate" are an
error, the agent should simply reject any attempt to overwrite any such
state.



I agree tha= t a priority override is not an error. In a multi-client environment,
=
client A is not going to know about the other clients added to the sys= tem.
This is true whether the clients are primary or secondary be= hind a broker.

The notification to a client that s= ome or all of its data was just overridden
is a separate matter f= rom whether the client wants all or part of its
data to be remove= d or altered.

One proposal to the design team is t= he notion that the server
supports an advertised (static) number = of clients (max client panes).
Each client must be assigned a pri= ority, such that every client
has its own pane, so adding a valid= edit does not fail. Activating
the edit is a separate matter. Ea= ch client can flush all or part of its own pane.

<= br>
:-)

Russ



Andy


_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs


--001a113d39389d8e9c0524086841-- From nobody Sun Nov 8 06:54:20 2015 Return-Path: <7riw77@gmail.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 AC1EC1B2E33 for ; Sun, 8 Nov 2015 06:54:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_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 bMS_ebvyxja0 for ; Sun, 8 Nov 2015 06:54:17 -0800 (PST) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (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 99C501B2E36 for ; Sun, 8 Nov 2015 06:54:17 -0800 (PST) Received: by ykdv3 with SMTP id v3so140534098ykd.0 for ; Sun, 08 Nov 2015 06:54:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=CeKFe9hb9YC8MWHghgLSYnfQX2mszF5Wvf87ev+dRPU=; b=mHrE7F8uC8MEdS+1JX4HQ8ZYKHzXhnIrMaeuf9+6q7pO+Xnh+za/SDn+KtIBi5PZvD TwHsw9uSFttGjmxM7F/lkONTo5de5heWlW5kMpJz5qn4pyw33flhiNmnCNjIYZ9Z8Kur 4o2E1bfdWA6Kpa6BP4AtpiEbReJjEWDgJQOpo5NmC0Q7AzJ/0Vmvl8MgH9ue0vEXxMIp 5U6P0atYoQviHt6zsm9gV8bJxRm9Czny10tuZQQumxG603uAznRac0ZkFiSnWzAQZfBm 2JbjQRx/yDGNtlv93iQNJ5VHf7JW/KLIxwplYQtaZB/ZjXWM29OmBH6PV/V3J//9CgnS veDw== X-Received: by 10.13.248.66 with SMTP id i63mr19368304ywf.272.1446994456968; Sun, 08 Nov 2015 06:54:16 -0800 (PST) Received: from Russ ([2602:30a:2e5b:44d0:19d5:7aef:8b48:dd80]) by smtp.gmail.com with ESMTPSA id y66sm8730415ywe.13.2015.11.08.06.54.16 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Nov 2015 06:54:16 -0800 (PST) From: "Russ White" <7riw77@gmail.com> To: "'Alia Atlas'" , "'Andy Bierman'" References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> <563A97AA.5020308@joelhalpern.com> <005101d11798$549a6f10$fdcf4d30$@ndzh.com> <563B0750.70009@joelhalpern.com> <034901d117a1$79a6e7d0$6cf4b770$@gmail.com> In-Reply-To: Date: Sun, 8 Nov 2015 09:54:13 -0500 Message-ID: <006501d11a35$55b59f10$0120dd30$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLwMtmz+XLO8+uQ7j5WaenA2rWXRwHVfCJTAW3ySwACzWyr4AJQYvqoAmia70sBb/tJ5QHaZBpQAchizYgBnpuM2wGw4AIim7qjprA= Content-Language: en-us Archived-At: Cc: i2rs@ietf.org, "'Joel M. Halpern'" , 'Susan Hares' Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2015 14:54:18 -0000 > ideas of store-if-not-best and handling overwrites and so on. There = was a > very clear push back against any such complexity. Feel free to take a = read > through the archive. IMHO, then, is severely diminished to the point of being non-useful = work. If there is no way to store a "backup route," then any use of I2RS = to install LFAs, backup tunnels, and even temporary changes in the = routing table, are out of bounds, and I2RS becomes "yet another = configuration mechanism."=20 Russ From nobody Sun Nov 8 08:52:05 2015 Return-Path: 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 66C041A7017 for ; Sun, 8 Nov 2015 08:52:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_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 tdH9rMREGyjp for ; Sun, 8 Nov 2015 08:52:01 -0800 (PST) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (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 550AD1A7D81 for ; Sun, 8 Nov 2015 08:52:01 -0800 (PST) Received: by lfbn126 with SMTP id n126so89914864lfb.2 for ; Sun, 08 Nov 2015 08:51:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OQqANzZkr1mG+SonPzU3NOsaT7eI2rf3/480kAruBzY=; b=lThmRB82jqZSLif2muX00N6WMa0UR3EkFHNiWrfNifCDtsPmTUKqhY3xnlhRMZYUCt hnJEIdNztbXRCs62r73DUhhlgIa6b8rJ1APKtQ17D3BHvfyQ4SkPwSucrX51Mk9xHxoD glS0rfUsbOnlJi7k6Tx45sT0+j27T8xyv9jA5Vj/uV7UHjNRJq35+XprkceNXe2mz7o5 A33K0eaNPe910zMvYYbFzpWg6RCppnNW4wTnfSbD3MysbA/mVKXUQfzIW4OSpz8LmLgk 6OHt3pRr1M20VqPiSShff0RNnqu+m8iQF3RL/ayOP8BnR4fOlDW9bG3nw7hUYpI68X/I gbGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=OQqANzZkr1mG+SonPzU3NOsaT7eI2rf3/480kAruBzY=; b=gGiI/EC6R/5nDeroblrH7QUmgobg0tEwlswdzdaKuigV0XQ3z1ie8DSCfly/3jlVzV RdjjF0EZXWf2ZigBHswPJrK5MrUdxkmLsm2H1mFm6GX+6ABrGTBtLG4wfVekMXD/GKlP 2ejcdc4ewJm3GWAZ4qBLDPCDT9CQ9M7Kgok9US26Fy8loNTswF0DSCXXLG/m9ynSqEhV BTWNV2mrwZlbRlVX84BsFwjFfj7AYEfTFNM3+fEdLBL9XV9bVPC8KAitrocF+SnbSN03 dzREn0lUoW1O68SXok7dITtUF/a8AL9nJxbjprNtU2EMHY5n4rPgSeGdekKwPaB8l7n5 rmfw== X-Gm-Message-State: ALoCoQnf41GAVjuD+zM+in2Y1b33t8VntyT6HwqCukUy+FqGv+h2evejfj29RQxPNvnKxanNcpBD MIME-Version: 1.0 X-Received: by 10.25.145.209 with SMTP id t200mr7167065lfd.88.1447001519250; Sun, 08 Nov 2015 08:51:59 -0800 (PST) Received: by 10.112.144.106 with HTTP; Sun, 8 Nov 2015 08:51:59 -0800 (PST) In-Reply-To: References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> <563A97AA.5020308@joelhalpern.com> <005101d11798$549a6f10$fdcf4d30$@ndzh.com> <563B0750.70009@joelhalpern.com> <034901d117a1$79a6e7d0$6cf4b770$@gmail.com> Date: Sun, 8 Nov 2015 08:51:59 -0800 Message-ID: From: Andy Bierman To: Alia Atlas Content-Type: multipart/alternative; boundary=001a114021b08b7b8305240a4bb4 Archived-At: Cc: "i2rs@ietf.org" , "Joel M. Halpern" , Susan Hares , Russ White <7riw77@gmail.com> Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2015 16:52:04 -0000 --001a114021b08b7b8305240a4bb4 Content-Type: text/plain; charset=UTF-8 On Sun, Nov 8, 2015 at 6:36 AM, Alia Atlas wrote: > Hi Russ & Andy, > > I certainly understand the desire for different behavior when a priority > override happens. > However, this is one area where the working group was extremely clear. > Sue and I had > ideas of store-if-not-best and handling overwrites and so on. There was a > very clear > push back against any such complexity. Feel free to take a read through > the archive. > > While it is tempting to expand the scope and functionality of I2RS to > handle this as not > an error, I would ask that we respect the WG consensus and get agreement > and implementations > going on the basics. > > We have a serious case of too many saying "This is an interesting soup. > Let's watch it." and > far too few people putting wood on the fire and experimenting. > > It's hard to get a protocol built here just by throwing requirements over the wall. Standards track documents should be past the experimentation stage (although that is far too common in the IETF). There should be multiple vendors saying "This is how we solved this problem. Use our solution." There are several distinct problems here. (1) what is an edit overlap? This is actually a hard problem. Obviously duplicates of running datastore instances overlap, but not so obvious are the shared ancestor nodes or data model specific interactions between disjoint objects. This needs to be solved even if there was only 1 client, because running and ephemeral datastores can overlap. (2) what needs to happen in the client and server to make the backup data active? It concerns me that the implementations of proprietary I2RS use caching instead of introducing a distributed control loop here. If you think caching is hard, just wait until you try to get 10X - 100X faster performance out of your notification system to implement a tight control loop. There is complexity in both approaches. The pub/sub work is brand new as well, so it will not be stable for awhile. A workaround is to implement a single client, which itself is a broker, and handles all the caching. It will try to delete the old data and add the backup in 1 step. The alternative will be around 1 sec. latency to install the backup. Regards, > Alia > Andy > > On Thu, Nov 5, 2015 at 12:57 PM, Andy Bierman wrote: > >> >> >> On Thu, Nov 5, 2015 at 12:10 AM, Russ White <7riw77@gmail.com> wrote: >> >>> >>> > First, is the case of two I2RS clients modifying the same "thing" >>> > something we consider normal and desirable, or is it an error. The >>> earlier >>> > discussions was that it is an error. In discussing the many different >>> kinds of >>> > direct and indirect collateral issues that arise, we concluded that we >>> could >>> > not expect the I2RS agent to be able to determine the "right" thing to >>> do >>> in >>> > the general case. >>> >>> So, assume the following -- >>> >>> 1. A local BGP process installs a route, 10.1.1.0/24 via 192.168.100.1 >>> 2. In order to move traffic off a "hot link" in a fabric, a >>> client/controller installs a route, 10.1.1.0/24 via 192.168.200.1 >>> 3. An attack vector is detected in a flow destined to some host on >>> 10.1.1.0/24 that causes a separate client/controller to install a route, >>> 10.1.1.0/24 via 192.168.150.1 for five seconds >>> >>> If I were the operator who owned this network, I wouldn't call this an >>> "error." I would call this "normal operation," -- in fact, the ability >>> to do >>> the above would be the very reason I would deploy I2RS on the network in >>> the >>> first place. Further, I would expect the entire process to unwind >>> properly >>> and _quickly_. I don't care how it happens, I just want the removal of >>> the >>> second client's route to leave the first client's in the table as the >>> current route, and the removal of the first client's path leave the BGP >>> route as the best path. To go farther, why are there client priorities at >>> all if this is an "error?" If all overwrites of "ephemeral state" are an >>> error, the agent should simply reject any attempt to overwrite any such >>> state. >>> >>> >> >> I agree that a priority override is not an error. In a multi-client >> environment, >> client A is not going to know about the other clients added to the system. >> This is true whether the clients are primary or secondary behind a broker. >> >> The notification to a client that some or all of its data was just >> overridden >> is a separate matter from whether the client wants all or part of its >> data to be removed or altered. >> >> One proposal to the design team is the notion that the server >> supports an advertised (static) number of clients (max client panes). >> Each client must be assigned a priority, such that every client >> has its own pane, so adding a valid edit does not fail. Activating >> the edit is a separate matter. Each client can flush all or part of its >> own pane. >> >> >> :-) >>> >>> Russ >>> >>> >> >> Andy >> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> >> > --001a114021b08b7b8305240a4bb4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Nov 8, 2015 at 6:36 AM, Alia Atlas <akatlas@gmail.com><= /span> wrote:
Hi Russ &a= mp; Andy,

I certainly understand the desire for differen= t behavior when a priority override happens.
However, this is one= area where the working group was extremely clear.=C2=A0 Sue and I had
ideas of store-if-not-best and handling overwrites and so on.=C2=A0 T= here was a very clear
push back against any such complexity.=C2= =A0 Feel free to take a read through the archive.

= While it is tempting to expand the scope and functionality of I2RS to handl= e this as not
an error, I would ask that we respect the WG consen= sus and get agreement and implementations
going on the basics.

We have a serious case of too many saying "This= is an interesting soup.=C2=A0 Let's watch it." and
far = too few people putting wood on the fire and experimenting.


It's hard to get a protocol = built here just by throwing requirements over the wall.
Standards= track documents should be past the experimentation stage
(althou= gh that is far too common in the IETF). There should be multiple
= vendors saying "This is how we solved this problem.=C2=A0 Use our solu= tion."

There are several distinct problems he= re.

(1) what is an edit overlap?
This is= actually a hard problem. Obviously duplicates of running datastore
instances overlap, but not so obvious are the shared ancestor nodes or
data model specific interactions between disjoint objects.=C2=A0 T= his needs to be solved
even if there was only 1 client, because r= unning and ephemeral datastores can overlap.

(2) w= hat needs to happen in the client and server to make the backup data active= ?
It concerns me that the implementations of proprietary I2RS use= caching
instead of introducing a distributed control loop here.= =C2=A0 If you think caching is
hard, just wait until you try to g= et 10X - 100X faster performance out of your
notification system = to implement a tight control loop.=C2=A0 There is complexity
in b= oth approaches. The pub/sub work is brand new as well, so it will not
=
be stable for awhile.

A workaround is to impl= ement a single client, which itself is a broker,
and handles all = the caching.=C2=A0 It will try to delete the old data and add the backup
in 1 step. The alternative will be around 1 sec. latency to install= the backup.



Regards,
Alia=


Andy
= =C2=A0

<= div class=3D"gmail_quote">On Thu, Nov 5, 2015 at 12:57 PM, Andy Bierman <= andy@yumaworks.com> wrote:
=


On Thu, Nov 5, 2015 at 12:10 AM, Russ White <7riw77@gmail.com= > wrote:

> First, is the case of two I2RS clients modifying the same "thing&= quot;
> something we consider normal and desirable, or is it an error.=C2=A0 T= he
earlier
> discussions was that it is an error.=C2=A0 In discussing the many diff= erent
kinds of
> direct and indirect collateral issues that arise, we concluded that we=
could
> not expect the I2RS agent to be able to determine the "right"= ; thing to do
in
> the general case.

So, assume the following --

1. A local BGP process installs a route, 10.1.1.0/24 via 192.168.100.1
2. In order to move traffic off a "hot link" in a fabric, a
client/controller installs a route, 10.1.1.0/24 via 192.168.200.1
3. An attack vector is detected in a flow destined to some host on
10.1.1.= 0/24 that causes a separate client/controller to install a route,
10.1.1.= 0/24 via 192.168.150.1 for five seconds

If I were the operator who owned this network, I wouldn't call this an<= br> "error." I would call this "normal operation," -- in fa= ct, the ability to do
the above would be the very reason I would deploy I2RS on the network in th= e
first place. Further, I would expect the entire process to unwind properly<= br> and _quickly_. I don't care how it happens, I just want the removal of = the
second client's route to leave the first client's in the table as t= he
current route, and the removal of the first client's path leave the BGP=
route as the best path. To go farther, why are there client priorities at all if this is an "error?" If all overwrites of "ephemeral s= tate" are an
error, the agent should simply reject any attempt to overwrite any such
state.



I agree tha= t a priority override is not an error. In a multi-client environment,
=
client A is not going to know about the other clients added to the sys= tem.
This is true whether the clients are primary or secondary be= hind a broker.

The notification to a client that s= ome or all of its data was just overridden
is a separate matter f= rom whether the client wants all or part of its
data to be remove= d or altered.

One proposal to the design team is t= he notion that the server
supports an advertised (static) number = of clients (max client panes).
Each client must be assigned a pri= ority, such that every client
has its own pane, so adding a valid= edit does not fail. Activating
the edit is a separate matter. Ea= ch client can flush all or part of its own pane.

<= br>
:-)

Russ



Andy


_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs



--001a114021b08b7b8305240a4bb4-- From nobody Sun Nov 8 09:15:58 2015 Return-Path: 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 A59281A8AAE for ; Sun, 8 Nov 2015 09:15:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 W_Z_mIGqOdcb for ; Sun, 8 Nov 2015 09:15:55 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A2FB1A8A76 for ; Sun, 8 Nov 2015 09:15:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 608B9440056; Sun, 8 Nov 2015 09:15:55 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id BCE5444001F; Sun, 8 Nov 2015 09:15:54 -0800 (PST) To: Andy Bierman , Alia Atlas References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> <563A97AA.5020308@joelhalpern.com> <005101d11798$549a6f10$fdcf4d30$@ndzh.com> <563B0750.70009@joelhalpern.com> <034901d117a1$79a6e7d0$6cf4b770$@gmail.com> From: "Joel M. Halpern" Message-ID: <563F8349.4030600@joelhalpern.com> Date: Sun, 8 Nov 2015 12:15:53 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "i2rs@ietf.org" , Susan Hares , Russ White <7riw77@gmail.com> Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2015 17:15:56 -0000 Aince the working group agreement and the request Alia is making is NOt to store backup / cache, but to use the control loop to deal with changes and errors, I do not follow what your comment 2 is raising? Yours, Joel On 11/8/15 11:51 AM, Andy Bierman wrote: > > > On Sun, Nov 8, 2015 at 6:36 AM, Alia Atlas > wrote: > > Hi Russ & Andy, > > I certainly understand the desire for different behavior when a > priority override happens. > However, this is one area where the working group was extremely > clear. Sue and I had > ideas of store-if-not-best and handling overwrites and so on. There > was a very clear > push back against any such complexity. Feel free to take a read > through the archive. > > While it is tempting to expand the scope and functionality of I2RS > to handle this as not > an error, I would ask that we respect the WG consensus and get > agreement and implementations > going on the basics. > > We have a serious case of too many saying "This is an interesting > soup. Let's watch it." and > far too few people putting wood on the fire and experimenting. > ... > (2) what needs to happen in the client and server to make the backup > data active? > It concerns me that the implementations of proprietary I2RS use caching > instead of introducing a distributed control loop here. If you think > caching is > hard, just wait until you try to get 10X - 100X faster performance out > of your > notification system to implement a tight control loop. There is complexity > in both approaches. The pub/sub work is brand new as well, so it will not > be stable for awhile. ... From nobody Sun Nov 8 09:26:01 2015 Return-Path: <7riw77@gmail.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 5147C1A8BB5 for ; Sun, 8 Nov 2015 09:25:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_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 gJybP4I6U3v1 for ; Sun, 8 Nov 2015 09:25:57 -0800 (PST) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (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 A5ED11A8BB3 for ; Sun, 8 Nov 2015 09:25:57 -0800 (PST) Received: by ykba4 with SMTP id a4so232314805ykb.3 for ; Sun, 08 Nov 2015 09:25:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:mime-version:to:cc:from:subject:date:in-reply-to :references:content-type; bh=FQurNGoHqh4jtKWAQ0Gk4QDVfQokbh86gzwBQStqa5w=; b=RlRsCOBrbMWJDV8Poihc+bmnplf4N+U8F4jatZjYGDO/OqIfC0FeKs7XYFRi1GVFva ftsrXWptML0tNOKCnTEmO6dsqDOjAyjk9VUAxPIPnBuyPzi5tPRGA62ugXYU26qbmenI HzctpL0c1hjbzXp9RwB8l0rzZqVI4bUVvO5/z65L2XaOn9xDQPLJgpqwvbf77UktGx0g Yv/q9NtqhLUf+MjO6LQJDEYqoccKNe+TzegxrLrn5mEc0zIHYb7axKuUBt0iu4ZJyzFy ZFGPgXGPxN06lq6hpR/jGXjLQmVayU5fhG1RjjBzoCtwcy1cm9lr/qC9tHmNxim5lNKy DYTA== X-Received: by 10.129.158.143 with SMTP id v137mr21473991ywg.49.1447003556911; Sun, 08 Nov 2015 09:25:56 -0800 (PST) Received: from [10.170.233.253] ([166.137.96.13]) by smtp.gmail.com with ESMTPSA id i141sm9387134ywc.2.2015.11.08.09.25.55 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 08 Nov 2015 09:25:56 -0800 (PST) Message-ID: <563f85a4.936d810a.84ada.1a22@mx.google.com> MIME-Version: 1.0 To: "Joel M. Halpern" , Andy Bierman , Alia Atlas From: <7riw77@gmail.com> Date: Sun, 8 Nov 2015 12:25:54 -0500 In-Reply-To: <563F8349.4030600@joelhalpern.com> References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> <563A97AA.5020308@joelhalpern.com> <005101d11798$549a6f10$fdcf4d30$@ndzh.com> <563B0750.70009@joelhalpern.com> <034901d117a1$79a6e7d0$6cf4b770$@gmail.com> <563F8349.4030600@joelhalpern.com> Content-Type: multipart/alternative; boundary="_D322EDF5-C68D-4037-A0F8-4B93BFFB749F_" Archived-At: Cc: "i2rs@ietf.org" , Susan Hares Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2015 17:25:59 -0000 --_D322EDF5-C68D-4037-A0F8-4B93BFFB749F_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Because the time required to support such a loop is too long to make this w= ork useful in the control plane. We don't have seconds to compute and insta= ll an lfa, for instance, or to redirect a ddos stream to a cleaner=20 Further, if you think having "planes of configuration," is complex, wait un= til you try to troubleshoot a muiltistate instability problem with a severa= l second loop time as multiple clients discover, then react to, what other = clients are doing. No-one has a "full state set," hence there is no way to = either understand what the state should be, or what parts are interacting. Bottom line -- you can either see the complexity for what it is and manage = it, or you can try to throw it over the wall fir someone else to deal with.= The second option doesn't really solve the complexity. In fact, it make th= e problem much worse. Being able to see the potential states in a single pl= ace is a crucial piece of the manageability puzzle here. Russ Sent from my Windows Phone -----Original Message----- From: "Joel M. Halpern" Sent: =E2=80=8E11/=E2=80=8E8/=E2=80=8E2015 12:15 PM To: "Andy Bierman" ; "Alia Atlas" Cc: "Russ White" <7riw77@gmail.com>; "i2rs@ietf.org" ; "Susa= n Hares" Subject: Re: [i2rs] Conversation on Priority and Panes Aince the working group agreement and the request Alia is making is NOt=20 to store backup / cache, but to use the control loop to deal with=20 changes and errors, I do not follow what your comment 2 is raising? Yours, Joel On 11/8/15 11:51 AM, Andy Bierman wrote: > > > On Sun, Nov 8, 2015 at 6:36 AM, Alia Atlas > wrote: > > Hi Russ & Andy, > > I certainly understand the desire for different behavior when a > priority override happens. > However, this is one area where the working group was extremely > clear. Sue and I had > ideas of store-if-not-best and handling overwrites and so on. There > was a very clear > push back against any such complexity. Feel free to take a read > through the archive. > > While it is tempting to expand the scope and functionality of I2RS > to handle this as not > an error, I would ask that we respect the WG consensus and get > agreement and implementations > going on the basics. > > We have a serious case of too many saying "This is an interesting > soup. Let's watch it." and > far too few people putting wood on the fire and experimenting. > ... > (2) what needs to happen in the client and server to make the backup > data active? > It concerns me that the implementations of proprietary I2RS use caching > instead of introducing a distributed control loop here. If you think > caching is > hard, just wait until you try to get 10X - 100X faster performance out > of your > notification system to implement a tight control loop. There is complexi= ty > in both approaches. The pub/sub work is brand new as well, so it will not > be stable for awhile. ... --_D322EDF5-C68D-4037-A0F8-4B93BFFB749F_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

Because the time required to support such a loop is t= oo long to make this work useful in the control plane. We don't have second= s to compute and install an lfa, for instance, or to redirect a ddos stream= to a cleaner

Further, if you think having "planes of configuration= ," is complex, wait until you try to troubleshoot a muiltistate instability= problem with a several second loop time as multiple clients discover, then= react to, what other clients are doing. No-one has a "full state set," hen= ce there is no way to either understand what the state should be, or what p= arts are interacting.

Bottom line -- you can either see the complexi= ty for what it is and manage it, or you can try to throw it over the wall f= ir someone else to deal with. The second option doesn't really solve the co= mplexity. In fact, it make the problem much worse. Being able to see the po= tential states in a single place is a crucial piece of the manageability pu= zzle here.

Russ

Sent from my Windows Phone
From: Joel M. = Halpern
Sent: =E2=80=8E11/=E2=80=8E8/=E2=80=8E2015 12= :15 PM
To: Andy Bie= rman; Alia Atlas
Cc: Russ White; i2rs@ietf.org; Su= san Hares
Subject: Re: [i2rs] Conversation on Priorit= y and Panes

Aince the working group agreement and the r= equest Alia is making is NOt
to store backup / cache, but to use the co= ntrol loop to deal with
changes and errors, I do not follow what your c= omment 2 is raising?

Yours,
Joel

On 11/8/15 11:51 AM, Andy= Bierman wrote:
>
>
> On Sun, Nov 8, 2015 at 6:36 AM, Ali= a Atlas <akatlas@gmail.com
> <mailto:akatlas@gmail.com>> = wrote:
>
>     Hi Russ & Andy,
><= br>>     I certainly understand the desire for diffe= rent behavior when a
>     priority override happ= ens.
>     However, this is one area where the wo= rking group was extremely
>     clear.  Sue = and I had
>     ideas of store-if-not-best and ha= ndling overwrites and so on.  There
>     wa= s a very clear
>     push back against any such c= omplexity.  Feel free to take a read
>     t= hrough the archive.
>
>     While it is tem= pting to expand the scope and functionality of I2RS
>  &nbs= p;  to handle this as not
>     an error, I = would ask that we respect the WG consensus and get
>   = ;  agreement and implementations
>     going= on the basics.
>
>     We have a serious c= ase of too many saying "This is an interesting
>   &nb= sp; soup.  Let's watch it." and
>     far to= o few people putting wood on the fire and experimenting.
>
...
= > (2) what needs to happen in the client and server to make the backup> data active?
> It concerns me that the implementations of prop= rietary I2RS use caching
> instead of introducing a distributed contr= ol loop here.  If you think
> caching is
> hard, just wait= until you try to get 10X - 100X faster performance out
> of your
= > notification system to implement a tight control loop.  There is = complexity
> in both approaches. The pub/sub work is brand new as wel= l, so it will not
> be stable for awhile.
...
= --_D322EDF5-C68D-4037-A0F8-4B93BFFB749F_-- From nobody Sun Nov 8 09:41:57 2015 Return-Path: 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 00FC11A9027 for ; Sun, 8 Nov 2015 09:41:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_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 4n5qjq_hxYN5 for ; Sun, 8 Nov 2015 09:41:54 -0800 (PST) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (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 2717D1A9026 for ; Sun, 8 Nov 2015 09:41:54 -0800 (PST) Received: by lffz63 with SMTP id z63so22424994lff.0 for ; Sun, 08 Nov 2015 09:41:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+AXURxJsOXeQ1cai1vQa638jLGH3r8R+bF3d0VpwZrU=; b=oXOBhxjj3kma7/GHzMaUOgnOx/cV+GQqyRN8HAXRBVZ10wXCRhqk4XdFItJxVwC3zg swBNM6QBvTaS2al7oo+CPPqz8BahIs50Rb8YEF8rtNJ46lcvpzJoTQzUDwxdjiapvolc sH9jF4q1cS9F2MG0GwJC03gBW6qU02jKdZTdLLiUJnErql8Mr7W67rYOllU+TnZfGsHz cx1RLE+2ZLUs6mluRJK6j4H6SVeg4hk/SQNAguurfNWLPOyehB87C+r5u+LcvnodTID/ lgOHj9xE0i7dE9sf8Vj8fG8Cbu6uX51NwopM7McoYVsSW60Fzl1H9nTPU117/5vxirRM Sgmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+AXURxJsOXeQ1cai1vQa638jLGH3r8R+bF3d0VpwZrU=; b=kDr8x943JaaSU5+GmDzoACD5sIAAl8vHKd6Ce6PCXrTjK4H+lIYlucte8AiOH/OA40 fODlLBwfhwk4T5FpTbRw2QI2R2RJZrYiqsjgzB3iD6AEZ0oFtNLzlIMQDcBr/OqlihSu EApD57mHSCU0Cemdg1uCIgwayU41KRspqiHuTK1F9vtlUs/lcWanWBomJ/Akfah6s0fa 8VvABlggBiB5/RZNWjRuglVEebVnTqq81du5NPCn7iN4zCsLBn1MdV8AtGTqXFrUSS/j ruFrjt5zSh6+Eu2GBE4X+U7dG9eSpIFR7TtdqdIA/qPvFfbsR2sPCiSZ/OZEVjqDJL8q 8lpw== X-Gm-Message-State: ALoCoQl3bQsYJFxZQLOxS5twMxyiGMFHqzCPDQv1XtFCm7yD4ETT2VrCbjG1dBRHNwRUWGyrkBL8 MIME-Version: 1.0 X-Received: by 10.25.211.194 with SMTP id k185mr7137784lfg.119.1447004512304; Sun, 08 Nov 2015 09:41:52 -0800 (PST) Received: by 10.112.144.106 with HTTP; Sun, 8 Nov 2015 09:41:52 -0800 (PST) In-Reply-To: <563F8349.4030600@joelhalpern.com> References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> <563A97AA.5020308@joelhalpern.com> <005101d11798$549a6f10$fdcf4d30$@ndzh.com> <563B0750.70009@joelhalpern.com> <034901d117a1$79a6e7d0$6cf4b770$@gmail.com> <563F8349.4030600@joelhalpern.com> Date: Sun, 8 Nov 2015 09:41:52 -0800 Message-ID: From: Andy Bierman To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=001a1141805ef1d6c505240afd09 Archived-At: Cc: "i2rs@ietf.org" , Susan Hares , Russ White <7riw77@gmail.com>, Alia Atlas Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2015 17:41:56 -0000 --001a1141805ef1d6c505240afd09 Content-Type: text/plain; charset=UTF-8 Hi, On Sun, Nov 8, 2015 at 9:15 AM, Joel M. Halpern wrote: > Aince the working group agreement and the request Alia is making is NOt to > store backup / cache, but to use the control loop to deal with changes and > errors, I do not follow what your comment 2 is raising? > > IMO standards based on operational experience have a better chance of success. > Yours, > Joel > Andy > > On 11/8/15 11:51 AM, Andy Bierman wrote: > >> >> >> On Sun, Nov 8, 2015 at 6:36 AM, Alia Atlas > > wrote: >> >> Hi Russ & Andy, >> >> I certainly understand the desire for different behavior when a >> priority override happens. >> However, this is one area where the working group was extremely >> clear. Sue and I had >> ideas of store-if-not-best and handling overwrites and so on. There >> was a very clear >> push back against any such complexity. Feel free to take a read >> through the archive. >> >> While it is tempting to expand the scope and functionality of I2RS >> to handle this as not >> an error, I would ask that we respect the WG consensus and get >> agreement and implementations >> going on the basics. >> >> We have a serious case of too many saying "This is an interesting >> soup. Let's watch it." and >> far too few people putting wood on the fire and experimenting. >> >> ... > >> (2) what needs to happen in the client and server to make the backup >> data active? >> It concerns me that the implementations of proprietary I2RS use caching >> instead of introducing a distributed control loop here. If you think >> caching is >> hard, just wait until you try to get 10X - 100X faster performance out >> of your >> notification system to implement a tight control loop. There is >> complexity >> in both approaches. The pub/sub work is brand new as well, so it will not >> be stable for awhile. >> > ... > --001a1141805ef1d6c505240afd09 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,


On Sun, Nov 8, 2015 at 9:15 AM, Joel M. Halpern <jmh@joelhal= pern.com> wrote:
Aince th= e working group agreement and the request Alia is making is NOt to store ba= ckup / cache, but to use the control loop to deal with changes and errors, = I do not follow what your comment 2 is raising?



IMO standards based on = operational experience have a better chance of success.

=C2=A0
Yours,
Joel


Andy
=C2= =A0

On 11/8/15 11:51 AM, Andy Bierman wrote:


On Sun, Nov 8, 2015 at 6:36 AM, Alia Atlas <akatlas@gmail.com
<mailto:akatlas@g= mail.com>> wrote:

=C2=A0 =C2=A0 Hi Russ & Andy,

=C2=A0 =C2=A0 I certainly understand the desire for different behavior when= a
=C2=A0 =C2=A0 priority override happens.
=C2=A0 =C2=A0 However, this is one area where the working group was extreme= ly
=C2=A0 =C2=A0 clear.=C2=A0 Sue and I had
=C2=A0 =C2=A0 ideas of store-if-not-best and handling overwrites and so on.= =C2=A0 There
=C2=A0 =C2=A0 was a very clear
=C2=A0 =C2=A0 push back against any such complexity.=C2=A0 Feel free to tak= e a read
=C2=A0 =C2=A0 through the archive.

=C2=A0 =C2=A0 While it is tempting to expand the scope and functionality of= I2RS
=C2=A0 =C2=A0 to handle this as not
=C2=A0 =C2=A0 an error, I would ask that we respect the WG consensus and ge= t
=C2=A0 =C2=A0 agreement and implementations
=C2=A0 =C2=A0 going on the basics.

=C2=A0 =C2=A0 We have a serious case of too many saying "This is an in= teresting
=C2=A0 =C2=A0 soup.=C2=A0 Let's watch it." and
=C2=A0 =C2=A0 far too few people putting wood on the fire and experimenting= .

...
(2) what needs to happen in the client and server to make the backup
data active?
It concerns me that the implementations of proprietary I2RS use caching
instead of introducing a distributed control loop here.=C2=A0 If you think<= br> caching is
hard, just wait until you try to get 10X - 100X faster performance out
of your
notification system to implement a tight control loop.=C2=A0 There is compl= exity
in both approaches. The pub/sub work is brand new as well, so it will not be stable for awhile.
...

--001a1141805ef1d6c505240afd09-- From nobody Mon Nov 9 05:32:11 2015 Return-Path: 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 E4E3B1B2B93 for ; Mon, 9 Nov 2015 05:32:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 BlfIL9qT3Ssq for ; Mon, 9 Nov 2015 05:32:07 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id D32211B2B92 for ; Mon, 9 Nov 2015 05:32:06 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id B70041CC0196 for ; Mon, 9 Nov 2015 14:32:05 +0100 (CET) From: Ladislav Lhotka To: i2rs@ietf.org User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Mon, 09 Nov 2015 14:32:02 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [i2rs] Errors in ietf-i2rs-rib module X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 13:32:10 -0000 Hi, I checked the module ietf-i2rs-rib.yang with pyang and it generates a pretty long list of errors. The problem seems to be in all cases that the module defines the same data nodes in multiple cases of a choice. For example, grouping "tunnel-encap" contains this (schematically): choice tunnel-type { case ipv4 { uses ipv4-header; } case nvgre { choice nvgre-type { case ipv4 { uses ipv4-header; } ... } } ... } So the same data nodes defined by the "ipv4-header" grouping appear in both "ipv4" and "nvgre/ipv4" cases, which is not possible in YANG. One remedy could be to encapsulate the individual cases in specific containers. Lada -------------------- Start of forwarded message -------------------- From: internet-drafts@ietf.org To: Date: Sun, 01 Nov 2015 22:39:20 -0800 Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-03.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 : A YANG Data Model for Routing Information Base (RIB) Authors : Lixing Wang Hariharan Ananthakrishnan Mach(Guoyi) Chen Amit Dass Sriganesh Kini Nitin Bahadur Filename : draft-ietf-i2rs-rib-data-model-03.txt Pages : 61 Date : 2015-11-01 Abstract: This document defines a YANG data model for Routing Information Base (RIB) that aligns with the I2RS RIB information model. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-i2rs-rib-data-model-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-rib-data-model-03 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 i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs -------------------- End of forwarded message -------------------- -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Nov 9 05:32:44 2015 Return-Path: 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 812771B2B99 for ; Mon, 9 Nov 2015 05:32:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 5DnQjPG7oKcc for ; Mon, 9 Nov 2015 05:32:38 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0719.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:719]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0E381B2B97 for ; Mon, 9 Nov 2015 05:32:37 -0800 (PST) Received: from BLUPR05MB292.namprd05.prod.outlook.com (10.141.23.27) by BLUPR05MB292.namprd05.prod.outlook.com (10.141.23.27) with Microsoft SMTP Server (TLS) id 15.1.318.15; Mon, 9 Nov 2015 13:32:13 +0000 Received: from BLUPR05MB292.namprd05.prod.outlook.com ([10.141.23.27]) by BLUPR05MB292.namprd05.prod.outlook.com ([10.141.23.27]) with mapi id 15.01.0318.003; Mon, 9 Nov 2015 13:32:13 +0000 From: Chris Bowers To: "i2rs@ietf.org" Thread-Topic: feedback on draft-ietf-i2rs-rib-data-model-03 Thread-Index: AdEape/xVXarXm+DQZuKvXwrIYPAvw== Date: Mon, 9 Nov 2015 13:32:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=cbowers@juniper.net; x-originating-ip: [66.129.239.14] x-microsoft-exchange-diagnostics: 1; BLUPR05MB292; 5:/QGjOqZssYHOSRrAUnilTUsxhgOyNqAo3Et3Ct/16OPDDvAlJZ96+SQV+R6oNugj7hKsUdE4k53HAhoVeLnE5ISDSPLaF4xHz6LiuquhkdXk6MpBlZvh8l5a+gYs1QGAnh2bjxdZE+vfYDc8rXLbVQ==; 24:gpfiH/uHvrPugzBNAjF9cK17Leywp1IviN4xw1B+s4Sjoqja55/yhiT1IgrgYMxd0aBoBTus3/xqRpuqhllA5QpbLypq/VC/haUFb32In7s=; 20:V0uEmoTo0yru5wlDqR4E+vygKb6NvX9iZxP2HrAsLyyEaSvYGpwF0v8ghrSy/LCzyedPjLnjyrJU7izoopQP2Q== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB292; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(3002001)(10201501046); SRVR:BLUPR05MB292; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB292; x-forefront-prvs: 0755F54DD9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(164054003)(199003)(230783001)(2501003)(102836002)(92566002)(5003600100002)(19580395003)(40100003)(66066001)(5008740100001)(450100001)(2900100001)(110136002)(15975445007)(122556002)(11100500001)(87936001)(5007970100001)(5004730100002)(50986999)(54356999)(101416001)(107886002)(5001920100001)(99286002)(86362001)(74316001)(5001960100002)(77096005)(229853001)(105586002)(81156007)(97736004)(33656002)(2351001)(76576001)(10400500002)(5002640100001)(106356001)(189998001)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB292; H:BLUPR05MB292.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR05MB2924F5738FF87E731A47FE4A9150BLUPR05MB292namprd_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Nov 2015 13:32:12.8191 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB292 Archived-At: Subject: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 13:32:43 -0000 --_000_BLUPR05MB2924F5738FF87E731A47FE4A9150BLUPR05MB292namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I2RS WG and draft authors, Below is some feedback on the text of draft-ietf-i2rs-rib-data-model-03. Thanks, Chris ------------------------ It would be good to provide a way to get the yang model text file without i= etf draft headers interspersed throughout, so that people can run it throug= h pyang more easily. One way to do this is to publish the xml of the draft via the draft submiss= ion tool. Another common way is github, but I couldn't find it there. ------------------------ The description of the nexthop-preference-def (see below) is confusing. Fi= rst, I assume there is an error in the text since the example of downloadin= g primary/standby/tertiary nexthops to the FIB should presumably select thr= ee nexthops, but the text refers to selecting the two resolved nexthops wit= h the highest preference . More fundamentally, this example seems to impl= y that only two next-hops will get downloaded to the FIB, whereas one coul= d imagine an implementation that uses three, four, five or more nexthops of= different preferences. If hardware supports more than two next-hop prefer= ences being installed in the FIB, then what is the mechanism for the client= to learn how many preference values are supported? This should all be mad= e clearer in the text. typedef nexthop-preference-def { type uint8 { range "1..99"; } description "Nexthop-preference is used for protection schemes. It is an integer value between 1 and 99. A lower value indicates higher preference. To download a primary/standby/tertiary group to the FIB, the nexthops that are resolved and have two highest preferences are selected."; } ------------------------ If I understand the yang syntax and semantics correctly, the "nh-add" RPC c= reates a nexthop in a given RIB that is not associated with any match condi= tion on a route. I assume the intention is to create a nexthop with a next= hop-id but not associated with any prefix that can then be referenced by mu= ltiple other route match conditions. This seems like a reasonable thing t= o do. However, I can see two possible issues with this. The first issue is that the structure of the data model doesn't seem to not= allow this. "grouping route" uses "grouping route-prefix" next to "cont= ainer next-hop". It appears to me that as currently written "container mat= ch" in "grouping route-prefix" is a mandatory node based on section 3.1 of= RFC6020 , since the "mandatory" statements below choice/cases cascade up t= o the container. So the current form of the "nh-add" RPC may not be cons= istent with the data model as currently defined. The second issue is that creating a next-hop without an associated match ap= pears to differ from the RIB grammar defined in section 6 of draft-ietf-i2r= s-rib-info-model-08. In the RIB info model, it seems that the only way for = a to appear is together with a . ::=3D [] [] It would be good to address these inconsistencies in some way. ------------------------ In the definition of nh-add, "rpc nh-add { input { " uses "grouping next-h= op" which has the leaf nexthop-id as a mandatory element. Based on sectio= n 7.13.2 of RFC 6020, it seems that the nexthop-id would need to be present= in the RPC invocation defined by "rpc nh-add". This seems inconsistent wi= th the description of nh-add in section 2.5 of this document where no nexth= op-id is supplied in the input, and instead the network element allocates a= nexthop-id and returns it in the output of the rpc. It would be good to address this inconsistency. ------------------------ Treating tunnel-decap as a type of next-hop doesn't make sense to me. I ass= ume the desire to include tunnel-decap as well as tunnel-encap is to have a= usable stand-alone data model module which to deal with some use cases wit= hout having to rely on another module that defines tunnel-decap. However, = the result doesn't make sense. I think the most common scenario involving = routers would be to install a route on router A for prefix P whose nexthop = is a tunnel-encap whose destination is router B. One router B one would n= eed to install a corresponding tunnel-decap whose source is router A. The = most common scenario is then that router B does a normal route lookup on th= e decapsulated packet independent of the interface it entered on. I don't = see how this most common use case would be handled with the tunnel-decap ne= xt-hop in this document. Section 7.2.5. of draft-ietf-i2rs-rib-info-model-08 gives an example usage = for tunnel-decap where the tunnel-decap nexthop is used to pop an MPLS labe= l and send the traffic out an egress interface next-hop. This example is n= ot the most common scenario. And if we want to accomplish this scenario of = decapsulating and sending to a particular nexthop, it makes more sense to = treat tunnel-decap as a route match condition similar to an interface-route= in the existing data model. However, I think the model should be able to = handle the more common scenario described above when traffic needs to be de= capsulated and routed based on a normal route lookup. Treating tunnel-decap as a next-hop type really makes no sense to me. I th= ink this aspect of the model should be changed. ------------------------ The description of "identity ttl-action" on p.22 is missing the action "dec= rease-and-copy-to-next". I suggest either adding it to the description or= getting rid of the other 3 from the description. Listing only 3 of 4 opti= ons is confusing. ------------------------ These are some typos that I noticed as well. ------------------------ s/Struture/Structure/ Figure 2: Routing Instance Stuture ------------------------ s/nexhtop/nexthop/ There are several occurrences of this misspelling. ------------------------ s/tunnel-decap-nexthp/tunnel-decap-nexthop/ ------------------------ s/attribtes/attributes/ ------------------------ s/nexhop/nexthop/ ------------------------ s/usesd/used/ on p34. ------------------------ --_000_BLUPR05MB2924F5738FF87E731A47FE4A9150BLUPR05MB292namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I2RS WG and draft authors,
 
Below is some feedback on the text of draft-ietf-i2rs-rib-data-model-0= 3.
 
Thanks,
Chris
 
------------------------
It would be good to provide a way to get the yang model text file with= out ietf draft headers interspersed throughout, so that people can run it t= hrough pyang more easily.
One way to do this is to publish the xml of the draft via the draft su= bmission tool.
Another common way is github, but  I couldn’t find it there= .
 
------------------------
The description of the nexthop-preference-def (see below) is confusing= .  First, I assume there is an error in the text since the example of = downloading primary/standby/tertiary nexthops to the FIB should presumably = select three nexthops, but the text refers to selecting the two resolved nexthops with the highest preference .  = More fundamentally, this example seems to  imply that only two next-ho= ps will get downloaded to the FIB, whereas  one could imagine an imple= mentation that uses three, four, five or more nexthops of different preferences.  If hardware supports more than two next-hop= preferences being installed in the FIB, then what is the mechanism for the= client to learn how many preference values are supported?  This shoul= d all be made clearer in the text.
 
=      typedef nexthop-preference-def {
=        type uint8 {
=          range "1..99";
=        }
=        description
=          "Nexthop-preference i= s used for protection schemes.
=           It is an integer val= ue between 1 and 99.  A lower
=           value indicates high= er preference.  To download a
=           primary/standby/tert= iary group to the FIB, the
=           nexthops that are re= solved and have two highest
=           preferences are sele= cted.";
=      }
 
------------------------
If I understand the yang syntax and semantics correctly, the “nh= -add” RPC creates a nexthop in a given RIB that is not associated wit= h any match condition on a route.  I assume the intention is to create= a nexthop with a nexthop-id but not associated with any prefix that can then be referenced by multiple other route match condit= ions.   This seems like a reasonable thing to do.  However, = I can see two possible issues with this.
 
The first issue is that the structure of the data model doesn’t = seem to not allow this.   “grouping route” uses ̶= 0;grouping route-prefix”  next to “container next-hop̶= 1;.  It appears to me that as currently written “container match= ” in  “grouping route-prefix” is a mandatory node based on section 3.1 of RFC6020 , since the “mand= atory” statements below choice/cases cascade up to the container.&nbs= p;   So the current form of the “nh-add” RPC may not = be consistent with the data model as currently defined.
 
The second issue is that creating a next-hop without an associated mat= ch appears to differ from the RIB grammar defined in section 6 of draft-iet= f-i2rs-rib-info-model-08. In the RIB info model, it seems that the only way= for a <nexthop> to appear is together with a <match>.
 
=   <route> ::=3D <match> <nexthop>
=             &nb= sp; [<route-attributes>]
=             &nb= sp; [<route-vendor-attributes>]
 
It would be good to address these inconsistencies in some way.  <= /div>
 
------------------------
In the definition of nh-add, “rpc nh-add { input { ” = uses “grouping next-hop”  which has the leaf nexthop-id a= s a mandatory element.  Based on section 7.13.2 of RFC 6020, it seems = that the nexthop-id would need to be present in the RPC invocation defined by “rpc nh-add”.  This seems inconsistent with the descrip= tion of nh-add in section 2.5 of this document where no nexthop-id is suppl= ied in the input, and instead the network element allocates a nexthop-id an= d returns it in the output of the rpc.
 
It would be good to address this inconsistency.
 
------------------------
Treating tunnel-decap as a type of next-hop doesn’t make sense t= o me. I assume the desire to include tunnel-decap as well as tunnel-encap i= s to have a usable stand-alone data model module which to deal with some us= e cases without having to rely on another module that defines tunnel-decap.  However, the result doesn’t m= ake sense.  I think the most common scenario involving routers would b= e to install a route on router A for prefix P whose nexthop is a tunnel-enc= ap whose destination is router B.   One router B one would need to install a corresponding tunnel-decap whose source is rout= er A.  The most common scenario is then that router B does a normal ro= ute lookup on the decapsulated packet independent of the interface it enter= ed on.  I don’t see how this most common use case would be handled with the tunnel-decap next-hop in this document.<= /div>
 
Section 7.2.5. of draft-ietf-i2rs-rib-info-model-08 gives an example u= sage for tunnel-decap where the tunnel-decap nexthop is used to pop an MPLS= label and send the traffic out an egress interface next-hop.  This ex= ample is not the most common scenario. And if we want to accomplish this scenario of  decapsulating and sendi= ng to a particular nexthop, it makes more sense to treat tunnel-decap as a = route match condition similar to an interface-route in the existing data mo= del.  However, I think the model should be able to handle the more common scenario described above when traffic nee= ds to be decapsulated and routed based on a normal route lookup.
 
Treating tunnel-decap as a next-hop type really makes no sense to me.&= nbsp; I think this aspect of the model should be changed.
 
------------------------
The description of “identity ttl-action” on p.22 is missin= g the action “decrease-and-copy-to-next”.  I suggest eithe= r adding  it to the description or getting rid of the other 3 from the= description.  Listing only 3 of 4 options is confusing.
 
------------------------
These are some typos that I noticed as well. 
 
------------------------
s/Struture/Structure/
= Figure 2: Routing Instance Stuture
 
------------------------
s/nexhtop/nexthop/
 
There are several occurrences of this misspelling.
------------------------
s/tunnel-decap-nexthp/tunnel-decap-nexthop/
 
------------------------
= s/attribtes/attributes/
 
------------------------
s/nexhop/nexthop/
 
------------------------
s/usesd/used/
on p34.
 
------------------------
 
 
 
 --_000_BLUPR05MB2924F5738FF87E731A47FE4A9150BLUPR05MB292namprd_-- From nobody Mon Nov 9 16:52:53 2015 Return-Path: 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 B61181B2B61 for ; Mon, 9 Nov 2015 16:52:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.707 X-Spam-Level: X-Spam-Status: No, score=-2.707 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 SUtKKGj6OTPe for ; Mon, 9 Nov 2015 16:52:47 -0800 (PST) Received: from nm18-vm3.bullet.mail.gq1.yahoo.com (nm18-vm3.bullet.mail.gq1.yahoo.com [98.136.217.218]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DAD51B2B7D for ; Mon, 9 Nov 2015 16:52:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1447116767; bh=DcM4VsyxVc9jRGOM9Qo6CctVrbWWHPdqb26vBodTBtc=; h=Date:Subject:From:To:From:Subject; b=gM4g1QIUrB5E6l3YTmIJIv2VvRQzj8wL+hQ+QEwJelRyyZQY+yGgaGMWNw/MPE14q3Cov5Suhu6hCVUuErWI9/6fUg3CwpooCrRle3FvO6Wgkd/k5UK65UkL1I+kevtpO1AXOx/5p65+aGZm+DHdCpj8/B5cVNM+2S/F3WCt8q0inxT2RQ0yM/ydy+5CKXG7v+HpEdqXESFoVE3wp9NQuoKKifIg+7JW1js3L3dan5ZL8D3DdwDW+kfWUsdFhCc/wiTP6rqAFJCyMkDEvgQbC8qC7SskA+WcVU7MNH2v/d7ku/4FIM/dGfhRHVTEEbhmdd2sLLZ/bys1CaKYty/ifQ== Received: from [216.39.60.183] by nm18.bullet.mail.gq1.yahoo.com with NNFMP; 10 Nov 2015 00:52:47 -0000 Received: from [98.136.164.78] by tm19.bullet.mail.gq1.yahoo.com with NNFMP; 10 Nov 2015 00:52:47 -0000 Received: from [127.0.0.1] by smtp240.mail.gq1.yahoo.com with NNFMP; 10 Nov 2015 00:52:47 -0000 X-Yahoo-Newman-Id: 149770.19476.bm@smtp240.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 4rc4JskVM1mCWVr3lF94gmVEy9CnaAi4KclYYk8y9cD6Cxr 0Jf7UyO0_Y8wPMicdNpedLefn.P6dmYnuOul1xuggM1II1nmKoRU.TCUUz0s k0iksza_8.uy9Q5cRXfgy1fi61GA5FgisIGVmE3LZEnwFxKdvWvtEL_vS5mx QKk8Z3BxbEJwaZeJCoOkw3ObxD69o7efB93b.wtVxz5QoPtXZoa.cy9MWvjy p8m1HQXE7HHdhU..9yFe_RKezgm6zk9_m9gxJfw8jgbZNUYpI139.EUM0U9r 8oRn9ahnA1LxEYFY_v2UDP14QKG7YyM9oTsSaEQyu1cWJDRf7eLy5A9yO41f Qd55B.z8BfxN1478B96EjHcD2IrbmzsxeUcDIgfb77yWHVTHfUa8ihfjMjIN uAkbD6OXN_t_Io2hN5WErRpaRhbf77v3wK8fVj0m1grtnuOkNXlyyNqhb2Gd qJ3RIkZ79QEEj4TS.e0CFaxhH6jhRQErgDUIFNPwZU6jPjqwYw27KuPXE5Qj GWjVlA42pe05lJbF4EuMfWh1.81fiAtwNgjE.bXg- X-Yahoo-SMTP: jU6Na92swBBdqSRkLOL9Cp_LhHZgQAQoL10- User-Agent: Microsoft-MacOutlook/14.4.4.140807 Date: Mon, 09 Nov 2015 16:52:38 -0700 From: Nitin Bahadur To: Chris Bowers , "i2rs@ietf.org" , Mach Chen Message-ID: Thread-Topic: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3529932766_81238364" Archived-At: Subject: Re: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 00:52:51 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3529932766_81238364 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Chris, =20 Thanks for spending time on the spec. Please see NB> below for some o= f the issues you have raised. ------------------------ The description of the nexthop-preference-def (see below) is confusing. First, I assume there is an error in the text since the example of downloading primary/standby/tertiary nexthops to the FIB should presumably select three nexthops, but the text refers to selecting the two resolved nexthops with the highest preference . NB> That is a typo IMO. More fundamentally, this example seems to imply that only two next-hops will get downloaded to the FIB, whereas one could imagine an implementatio= n that uses three, four, five or more nexthops of different preferences. If hardware supports more than two next-hop preferences being installed in the FIB, then what is the mechanism for the client to learn how many preference values are supported? This should all be made clearer in the text. typedef nexthop-preference-def { type uint8 { range "1..99"; } description "Nexthop-preference is used for protection schemes. It is an integer value between 1 and 99. A lower value indicates higher preference. To download a primary/standby/tertiary group to the FIB, the nexthops that are resolved and have two highest preferences are selected."; } NB> Would something like this be preferable "To download N nexthops to the FIB, the N nexthops with the lowest value ar= e selected=B2. =20 =20 ------------------------ If I understand the yang syntax and semantics correctly, the =B3nh-add=B2 RPC creates a nexthop in a given RIB that is not associated with any match condition on a route. I assume the intention is to create a nexthop with a nexthop-id but not associated with any prefix that can then be referenced b= y multiple other route match conditions. This seems like a reasonable thing to do. However, I can see two possible issues with this. =20 The first issue is that the structure of the data model doesn=B9t seem to not allow this. =B3grouping route=B2 uses =B3grouping route-prefix=B2 next to =B3container next-hop=B2. It appears to me that as currently written =B3containe= r match=B2 in =B3grouping route-prefix=B2 is a mandatory node based on section 3.1 of RFC6020 , since the =B3mandatory=B2 statements below choice/cases cascade up to the container. So the current form of the =B3nh-add=B2 RPC may not be consistent with the data model as currently defined. =20 The second issue is that creating a next-hop without an associated match appears to differ from the RIB grammar defined in section 6 of draft-ietf-i2rs-rib-info-model-08. In the RIB info model, it seems that the only way for a to appear is together with a . =20 ::=3D [] [] =20 NB> I=B9m not sure if I agree with the creation of nexthop discrepancy. A nexthop can be created independently and then in the , you can reference the relevant nexthop-id. ::=3D =3D =3D ------------------------ Treating tunnel-decap as a type of next-hop doesn=B9t make sense to me. I assume the desire to include tunnel-decap as well as tunnel-encap is to hav= e a usable stand-alone data model module which to deal with some use cases without having to rely on another module that defines tunnel-decap. However, the result doesn=B9t make sense. I think the most common scenario involving routers would be to install a route on router A for prefix P whos= e nexthop is a tunnel-encap whose destination is router B. One router B one would need to install a corresponding tunnel-decap whose source is router A= . The most common scenario is then that router B does a normal route lookup o= n the decapsulated packet independent of the interface it entered on. I don=B9t see how this most common use case would be handled with the tunnel-decap next-hop in this document. NB> On router B, condition would be the incoming label and the =B3action=B2 to be taken on that would be =B3decap=B2 the MPLS label. And you can chain that with to say continue the route lookup in say =B3inet.0=B2= . The draft says, "RIB_NAME: A nexthop pointing to a RIB indicates that the route lookup needs to continue in the specified RIB.=B2 NB> Does that address your concern? =20 Section 7.2.5. of draft-ietf-i2rs-rib-info-model-08 gives an example usage for tunnel-decap where the tunnel-decap nexthop is used to pop an MPLS labe= l and send the traffic out an egress interface next-hop. This example is not the most common scenario. And if we want to accomplish this scenario of decapsulating and sending to a particular nexthop, it makes more sense to treat tunnel-decap as a route match condition similar to an interface-route in the existing data model. However, I think the model should be able to handle the more common scenario described above when traffic needs to be decapsulated and routed based on a normal route lookup. Treating tunnel-decap as a next-hop type really makes no sense to me. I think this aspect of the model should be changed. NB> See above comment. =20 Thanks Nitin --B_3529932766_81238364 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Hi Chris,
 
      Thanks for spending time on the= spec. Please see NB> below for some of the issues you have raised.
=

----------------------= --
The description of the nexthop-preference-def (see below) is co= nfusing.  First, I assume there is an error in the text since the examp= le of downloading primary/standby/tertiary nexthops to the FIB should presum= ably select three nexthops, but the text refers to selecting the two resolved nexthops with the highest preference . <= /div>

NB> Tha= t is a typo IMO.

= More fundamentally, this example seems to  imply that only two next-hop= s will get downloaded to the FIB, whereas  one could imagine an impleme= ntation that uses three, four, five or more nexthops of different preferences.  If hardware supports more than two next-hop= preferences being installed in the FIB, then what is the mechanism for the = client to learn how many preference values are supported?  This should = all be made clearer in the text.

<= font face=3D"Courier New" size=3D"2">   = ; typedef nexthop-preference-def {
       type uint8 {<= /font>
    = ;     range "1..99";
       }
    &nbs= p;  description
         "Nexthop-preference is= used for protection schemes.
          It is a= n integer value between 1 and 99.  A lower
       &n= bsp;  value indicates higher preference.  To download a
    &n= bsp;     primary/standby/tertiary group to the FIB, the<= /span>
  &nbs= p;       nexthops that are resolved and have t= wo highest
 = ;         preferences are selected."= ;
  &n= bsp;  }
NB> Would something like this be pref= erable
"To download N nexthops to <= span style=3D"font-size: 13px;">the = ;FIB, the N nexthops with the lowest value are selected”.
 
 
------------------= ------
If I understand the yang syntax and semantics correctly, th= e “nh-add” RPC creates a nexthop in a given RIB that is not asso= ciated with any match condition on a route.  I assume the intention is = to create a nexthop with a nexthop-id but not associated with any prefix that can then be referenced by multiple other route match condit= ions.   This seems like a reasonable thing to do.  However, I= can see two possible issues with this.
 
The firs= t issue is that the structure of the data model doesn’t seem to not al= low this.   “grouping route” uses “grouping rout= e-prefix”  next to “container next-hop”.  It app= ears to me that as currently written “container match” in  = “grouping route-prefix” is a mandatory node based on section 3.1 of RFC6020 , since the “mand= atory” statements below choice/cases cascade up to the container. = ;   So the current form of the “nh-add” RPC may not be= consistent with the data model as currently defined.
 
=
The second issue is that creating a next-hop without an associated matc= h appears to differ from the RIB grammar defined in section 6 of draft-ietf-= i2rs-rib-info-model-08. In the RIB info model, it seems that the only way fo= r a <nexthop> to appear is together with a <match>.
 
  <route> ::=3D <match>= ; <nexthop>
=        &nbs= p;      [<route-attributes>]
&nbs= p;             [= <route-vendor-attributes>]
 
=

NB> I’m not sure if I agree= with the creation of nexthop discrepancy. A nexthop can be created independ= ently and then in the <route>, you can reference the relevant nexthop-= id.

<route> ::=3D <match> <nexthop>=
                  =3D = <match> <nexthop-base>
        &nb= sp;         =3D <match> <NEXTHOP_ID>


------------------------
Treating tunnel-decap a= s a type of next-hop doesn’t make sense to me. I assume the desire to = include tunnel-decap as well as tunnel-encap is to have a usable stand-alone= data model module which to deal with some use cases without having to rely = on another module that defines tunnel-decap.  However, the result doesn’t m= ake sense.  I think the most common scenario involving routers would be= to install a route on router A for prefix P whose nexthop is a tunnel-encap= whose destination is router B.   One router B one would need to install a corresponding tunnel-decap whose source is rout= er A.  The most common scenario is then that router B does a normal rou= te lookup on the decapsulated packet independent of the interface it entered= on. 

I don’t see = how this most common use case would be handled with the tunnel-decap next-ho= p in this document.
=
NB> On router = B, <match> condition would be the incoming label and the “action= ” to be taken on that would be “decap” the MPLS label. And= you can chain that with <RIB_NAME> to say continue the route lookup i= n say “inet.0”. The draft says, "RIB_NA= ME: A nexthop pointing to a RIB indicates that the route
= 
  =
    lookup needs to continue in the specified RIB.”

= NB> Does that address your concern?=

 
Section 7.2.5. of draft-ietf-i2rs-rib-info= -model-08 gives an example usage for tunnel-decap where the tunnel-decap nex= thop is used to pop an MPLS label and send the traffic out an egress interfa= ce next-hop.  This example is not the most common scenario. And if we want to accomplish this scenario of  decapsulating and sendi= ng to a particular nexthop, it makes more sense to treat tunnel-decap as a r= oute match condition similar to an interface-route in the existing data mode= l.  However, I think the model should be able to handle the more common scenario described above when traffic nee= ds to be decapsulated and routed based on a normal route lookup.

Trea= ting tunnel-decap as a next-hop type really makes no sense to me.  I th= ink this aspect of the model should be changed.

<= span id=3D"OLK_SRC_BODY_SECTION" style=3D"color: rgb(0, 0, 0); font-family: Cali= bri, sans-serif; font-size: 14px;">
NB> See above comment.
 
Thanks
Nitin --B_3529932766_81238364-- From nobody Mon Nov 9 22:42:41 2015 Return-Path: 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 2853D1B3391 for ; Mon, 9 Nov 2015 22:42:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 OEtL5m5vrtBe for ; Mon, 9 Nov 2015 22:42:38 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 936BC1B3393 for ; Mon, 9 Nov 2015 22:42:26 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CDW77374; Tue, 10 Nov 2015 06:42:21 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 10 Nov 2015 06:42:18 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.229]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0235.001; Tue, 10 Nov 2015 14:41:50 +0800 From: Mach Chen To: Ladislav Lhotka , "i2rs@ietf.org" Thread-Topic: [i2rs] Errors in ietf-i2rs-rib module Thread-Index: AQHRGvMWd638TsqWdEuUoWhabylHr56UiGCw Date: Tue, 10 Nov 2015 06:41:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.564191CE.006C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.229, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 9efdd2de97b197070c0137e7dda95b6e Archived-At: Subject: Re: [i2rs] Errors in ietf-i2rs-rib module X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 06:42:41 -0000 Hi Lada, Thanks for checking the module!=20 I used the pyang-1.4.1 in the past and found no error. I just changed to us= e pyang-1.6 and indeed found a lot of errors. I have addressed them that wi= ll be reflected in the next revision.=20 Best regards, Mach > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Ladislav Lhotka > Sent: Monday, November 09, 2015 9:32 PM > To: i2rs@ietf.org > Subject: [i2rs] Errors in ietf-i2rs-rib module >=20 > Hi, >=20 > I checked the module ietf-i2rs-rib.yang with pyang and it generates a pre= tty > long list of errors. The problem seems to be in all cases that the module= defines > the same data nodes in multiple cases of a choice. >=20 > For example, grouping "tunnel-encap" contains this (schematically): >=20 > choice tunnel-type { > case ipv4 { > uses ipv4-header; > } > case nvgre { > choice nvgre-type { > case ipv4 { > uses ipv4-header; > } > ... > } > } > ... > } >=20 > So the same data nodes defined by the "ipv4-header" grouping appear in bo= th > "ipv4" and "nvgre/ipv4" cases, which is not possible in YANG. >=20 > One remedy could be to encapsulate the individual cases in specific conta= iners. >=20 > Lada >=20 > -------------------- Start of forwarded message -------------------- > From: internet-drafts@ietf.org > To: > Date: Sun, 01 Nov 2015 22:39:20 -0800 > Cc: i2rs@ietf.org > Subject: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-03.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Interface to the Routing System Working= Group > of the IETF. >=20 > Title : A YANG Data Model for Routing Information Base > (RIB) > Authors : Lixing Wang > Hariharan Ananthakrishnan > Mach(Guoyi) Chen > Amit Dass > Sriganesh Kini > Nitin Bahadur > Filename : draft-ietf-i2rs-rib-data-model-03.txt > Pages : 61 > Date : 2015-11-01 >=20 > Abstract: > This document defines a YANG data model for Routing Information Base > (RIB) that aligns with the I2RS RIB information model. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-i2rs-rib-data-model-03 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2rs-rib-data-model-03 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > -------------------- End of forwarded message -------------------- >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue Nov 10 01:44:50 2015 Return-Path: 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 03D691B3551 for ; Tue, 10 Nov 2015 01:44:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 hd5p44DLkoWA for ; Tue, 10 Nov 2015 01:44:47 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74C9F1B3550 for ; Tue, 10 Nov 2015 01:44:46 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CDX02827; Tue, 10 Nov 2015 09:44:19 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 10 Nov 2015 09:44:17 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.229]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0235.001; Tue, 10 Nov 2015 17:43:27 +0800 From: Mach Chen To: Chris Bowers , "i2rs@ietf.org" Thread-Topic: feedback on draft-ietf-i2rs-rib-data-model-03 Thread-Index: AdEape/xVXarXm+DQZuKvXwrIYPAvwA62aAQAAADW5A= Date: Tue, 10 Nov 2015 09:43:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.135] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.5641BC8A.0064, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.229, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: bcbc8f296e706401f42a0fd945b0120a Archived-At: Subject: Re: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 09:44:49 -0000 Hi Chris,=20 Thanks for your comments! Please see my reply inline... > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Chris Bowers > Sent: Monday, November 09, 2015 9:32 PM > To: i2rs@ietf.org > Subject: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 >=20 > I2RS WG and draft authors, >=20 > Below is some feedback on the text of draft-ietf-i2rs-rib-data-model-03. >=20 > Thanks, > Chris >=20 > ------------------------ > It would be good to provide a way to get the yang model text file without= ietf > draft headers interspersed throughout, so that people can run it through = pyang > more easily. > One way to do this is to publish the xml of the draft via the draft submi= ssion > tool. > Another common way is github, but=A0 I couldn't find it there. >=20 > ------------------------ > The description of the nexthop-preference-def (see below) is confusing.= =A0 First, > I assume there is an error in the text since the example of downloading > primary/standby/tertiary nexthops to the FIB should presumably select thr= ee > nexthops, but the text refers to selecting the two resolved nexthops with= the > highest preference .=A0 More fundamentally, this example seems to=A0 impl= y that > only two next-hops will get downloaded to the FIB, whereas=A0 one could > imagine an implementation that uses three, four, five or more nexthops of > different preferences.=A0 If hardware supports more than two next-hop > preferences being installed in the FIB, then what is the mechanism for th= e > client to learn how many preference values are supported?=A0 This should = all be > made clearer in the text. >=20 > =A0=A0=A0=A0 typedef nexthop-preference-def { > =A0=A0=A0=A0=A0=A0 type uint8 { > =A0=A0=A0=A0=A0=A0=A0=A0 range "1..99"; > =A0=A0=A0=A0=A0=A0 } > =A0=A0=A0=A0=A0=A0 description > =A0=A0=A0=A0=A0=A0=A0=A0 "Nexthop-preference is used for protection schem= es. > =A0=A0=A0=A0=A0=A0=A0=A0=A0 It is an integer value between 1 and 99.=A0 A= lower > =A0=A0=A0=A0=A0=A0=A0=A0=A0 value indicates higher preference.=A0 To down= load a > =A0=A0=A0=A0=A0=A0=A0=A0=A0 primary/standby/tertiary group to the FIB, th= e > =A0=A0=A0=A0=A0=A0=A0=A0=A0 nexthops that are resolved and have two highe= st > =A0=A0=A0=A0=A0=A0=A0=A0=A0 preferences are selected."; > =A0=A0=A0=A0 } >=20 As Nitin said, it a typo. The data model changed with time, but the descrip= tion is not be updated accordingly. Will update it in the next version. > ------------------------ > If I understand the yang syntax and semantics correctly, the "nh-add" RPC > creates a nexthop in a given RIB that is not associated with any match > condition on a route.=A0 I assume the intention is to create a nexthop wi= th a > nexthop-id but not associated with any prefix that can then be referenced= by > multiple other route match conditions.=A0=A0 This seems like a reasonable= thing to > do.=A0 However, I can see two possible issues with this. >=20 > The first issue is that the structure of the data model doesn't seem to n= ot > allow this.=A0=A0 "grouping route" uses "grouping route-prefix"=A0 next t= o > "container next-hop".=A0 It appears to me that as currently written "cont= ainer > match" in=A0 "grouping route-prefix" is a mandatory node based on section= 3.1 > of RFC6020 , since the "mandatory" statements below choice/cases cascade > up to the container.=A0=A0=A0 So the current form of the "nh-add" RPC may= not be > consistent with the data model as currently defined. The nh-add is only about how to add a nexthop to a rib, why this is relevan= t to the "grouping route"? "grouping route" is mainly related to the route-add rpc. To add a route to = a rib, if the nexthop-id is needed, the i2rs client needs to call the nh-ad= d RPC to request a nexthop-id. After that, it calls the route-add to instal= l the route. And when calling the route-add rpc, the route and nexthop (inc= luding the nexthop-id) are already there.=20 >=20 > The second issue is that creating a next-hop without an associated match > appears to differ from the RIB grammar defined in section 6 of > draft-ietf-i2rs-rib-info-model-08. In the RIB info model, it seems that t= he only > way for a to appear is together with a . >=20 > =A0 ::=3D > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [] > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [] >=20 > It would be good to address these inconsistencies in some way. I am not sure that this is an inconsistency. The info model is just to defi= ne what components a should include, but it does not forbid a speci= fic component can be processed or created alone.=20 >=20 > ------------------------ > In the definition of nh-add, "rpc nh-add { input { "=A0 uses "grouping > next-hop"=A0 which has the leaf nexthop-id as a mandatory element.=A0 Bas= ed > on section 7.13.2 of RFC 6020, it seems that the nexthop-id would need to= be > present in the RPC invocation defined by "rpc nh-add".=A0 This seems > inconsistent with the description of nh-add in section 2.5 of this docume= nt > where no nexthop-id is supplied in the input, and instead the network ele= ment > allocates a nexthop-id and returns it in the output of the rpc. >=20 > It would be good to address this inconsistency. Not every implementation will support nexthop-id, so it is an optional attr= ibute. Seem it's safe to remove the "mandatory" statement.=20 >=20 > ------------------------ > Treating tunnel-decap as a type of next-hop doesn't make sense to me. I > assume the desire to include tunnel-decap as well as tunnel-encap is to h= ave a > usable stand-alone data model module which to deal with some use cases > without having to rely on another module that defines > tunnel-decap.=A0 However, the result doesn't make sense.=A0 I think the m= ost > common scenario involving routers would be to install a route on router A= for > prefix P whose nexthop is a tunnel-encap whose destination is router B.= =A0=A0 One > router B one would need to install a corresponding tunnel-decap whose sou= rce > is router A.=A0 The most common scenario is then that router B does a nor= mal > route lookup on the decapsulated packet independent of the interface it > entered on.=A0 I don't see how this most common use case would be handled > with the tunnel-decap next-hop in this document. >=20 > Section 7.2.5. of draft-ietf-i2rs-rib-info-model-08 gives an example usag= e for > tunnel-decap where the tunnel-decap nexthop is used to pop an MPLS label = and > send the traffic out an egress interface next-hop.=A0 This example is not= the > most common scenario. And if we want to accomplish this scenario > of=A0 decapsulating and sending to a particular nexthop, it makes more se= nse to > treat tunnel-decap as a route match condition similar to an interface-rou= te in > the existing data model.=A0 However, I think the model should be able to = handle > the more common scenario described above when traffic needs to be > decapsulated and routed based on a normal route lookup. >=20 > Treating tunnel-decap as a next-hop type really makes no sense to me.=A0 = I think > this aspect of the model should be changed. >=20 > ------------------------ > The description of "identity ttl-action" on p.22 is missing the action > "decrease-and-copy-to-next".=A0 I suggest either adding=A0 it to the desc= ription > or getting rid of the other 3 from the description.=A0 Listing only 3 of = 4 options is > confusing. >=20 > ------------------------ > These are some typos that I noticed as well. >=20 > ------------------------ > s/Struture/Structure/ > Figure 2: Routing Instance Stuture >=20 > ------------------------ > s/nexhtop/nexthop/ >=20 > There are several occurrences of this misspelling. > ------------------------ > s/tunnel-decap-nexthp/tunnel-decap-nexthop/ >=20 > ------------------------ > s/attribtes/attributes/ >=20 > ------------------------ > s/nexhop/nexthop/ >=20 > ------------------------ > s/usesd/used/ > on p34. >=20 Will fix the above typos. Thanks, Mach > ------------------------ >=20 >=20 >=20 From nobody Wed Nov 11 19:28:05 2015 Return-Path: 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 493D71A6F7B for ; Wed, 11 Nov 2015 19:28:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 49a16TMBcRAJ for ; Wed, 11 Nov 2015 19:27:55 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0123.outbound.protection.outlook.com [65.55.169.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0EEA1A6F5A for ; Wed, 11 Nov 2015 19:27:54 -0800 (PST) Received: from BY2PR05MB614.namprd05.prod.outlook.com (10.141.218.148) by BY2PR05MB614.namprd05.prod.outlook.com (10.141.218.148) with Microsoft SMTP Server (TLS) id 15.1.318.15; Thu, 12 Nov 2015 03:27:50 +0000 Received: from BY2PR05MB614.namprd05.prod.outlook.com ([10.141.218.148]) by BY2PR05MB614.namprd05.prod.outlook.com ([10.141.218.148]) with mapi id 15.01.0318.003; Thu, 12 Nov 2015 03:27:50 +0000 From: Chris Bowers To: Nitin Bahadur , "i2rs@ietf.org" , Mach Chen Thread-Topic: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 Thread-Index: AQHRG1IfVu9gg5MiSU6fmCG9ahcIBp6XumQw Date: Thu, 12 Nov 2015 03:27:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=cbowers@juniper.net; x-originating-ip: [66.129.239.14] x-microsoft-exchange-diagnostics: 1; BY2PR05MB614; 5:0h6P20pBGDlwoC1wuSnWcArCX1DTSmJxub6iOS3QOHn0ivOBbzoQCTDUDGG1C5zSe6FphQw0A4f/rJyn7zwYgZ4KdRh12V1RMZj5t/k8mR5koZW+Vcb6IcEXZOqmUiDEglJHulEEJFsxgxYYk/emjw==; 24:5/RyQZWR4dsKM3Izi6xQg3fDghcoKtOyizcVvJ6qMJu6lQ0FZgSSKmaL9i0gjWKLziIGM/dQPf00JPc9OMmYwQVymi53n0bFppsoMfsYa8c=; 20:mKFiwuEle6+YpD7Sao7mi3samp2e5xJJZDcnOMgdMR7InOxhs5cFHkgXioBwhySmsb6tjdUJgrXzrQnylzr5yg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB614; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(201166117486090)(138986009662008)(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046); SRVR:BY2PR05MB614; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB614; x-forefront-prvs: 07584EDBCD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(31014005)(52044002)(189002)(164054003)(199003)(377454003)(52604005)(77096005)(54356999)(5007970100001)(5001960100002)(5002640100001)(107886002)(122556002)(15975445007)(81156007)(106356001)(5001770100001)(189998001)(2501003)(105586002)(2900100001)(19300405004)(92566002)(230783001)(10400500002)(76576001)(97736004)(40100003)(2521001)(5004730100002)(86362001)(50986999)(87936001)(99286002)(19625215002)(106116001)(19580395003)(5003600100002)(33656002)(74316001)(19617315012)(16236675004)(101416001)(102836002)(76176999)(2950100001)(11100500001)(5008740100001)(19580405001)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB614; H:BY2PR05MB614.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR05MB61474F2979A888D4D6D520DA9120BY2PR05MB614namprd_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Nov 2015 03:27:50.2561 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB614 Archived-At: Subject: Re: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 03:28:03 -0000 --_000_BY2PR05MB61474F2979A888D4D6D520DA9120BY2PR05MB614namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Nitin and Mach, Thanks for your responses. Jeff Haas suggested to me that we keep track of = issues for this on the I2RS wiki at: http://trac.tools.ietf.org/wg/i2rs/trac/wiki/IssuesRibDataModel So far, I posted one issue that I think needs more discussion. I copied it= below. Please feel free to edit the Wiki as part of the discussion as wel= l. Issue 1: Should we define tunnel encapsulation and tunnel decapsulation as = next-hops in the RIB data model? The RIB data model can model some types of encapsulation and decapsulation = by treating encapsulation and decapsulation as next-hops. For encapsulation= , a route is paired with a tunnel-encap-nexthop. For decapsulation, an init= ial route match condition is paired with a next-hop chain which consists of= a tunnel-decap-nexthop and another nexthop such as rib-name-nexthop or an = egress-interface-nexthop. 1) It is not clear if this model for decapsulation supports all useful enca= psulation types. For example, it is not clear that the route-match-types cu= rrently in draft-ietf-i2rs-rib-data-model-03 can be used to select traffic for GRE, NVGR= E, and VXLAN decapsulation. One could consider extending the route-match-ty= pes to include the header information needed to identify other encapsulatio= n types. However, this may also be a sign that the basic approach should be= re-evaluated. 2) Does treating tunnel-encap and tunnel-decap as next-hops result in a dat= a model that is easy to use for someone trying to program network forwardin= g behavior? From the point-of-view of a user of the data model, modeling tu= nnels as interfaces seems more useful. Treating tunnel decapsulation as a t= ype of ingress interface and tunnel encapsulation as a type of egress inter= face would fit with the current RIB model (which already has the concept of= an interface-route and an interface-nexthop.) And it would reduce the amou= nt of next-hop chaining that is required to make tunnels work compared to t= he current model. Thanks, Chris From: Nitin Bahadur [mailto:nitin_bahadur@yahoo.com] Sent: Monday, November 09, 2015 5:53 PM To: Chris Bowers ; i2rs@ietf.org; Mach Chen Subject: Re: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 Hi Chris, Thanks for spending time on the spec. Please see NB> below for some o= f the issues you have raised. ------------------------ The description of the nexthop-preference-def (see below) is confusing. Fi= rst, I assume there is an error in the text since the example of downloadin= g primary/standby/tertiary nexthops to the FIB should presumably select thr= ee nexthops, but the text refers to selecting the two resolved nexthops wit= h the highest preference . NB> That is a typo IMO. More fundamentally, this example seems to imply that only two next-hops wi= ll get downloaded to the FIB, whereas one could imagine an implementation = that uses three, four, five or more nexthops of different preferences. If = hardware supports more than two next-hop preferences being installed in the= FIB, then what is the mechanism for the client to learn how many preferenc= e values are supported? This should all be made clearer in the text. typedef nexthop-preference-def { type uint8 { range "1..99"; } description "Nexthop-preference is used for protection schemes. It is an integer value between 1 and 99. A lower value indicates higher preference. To download a primary/standby/tertiary group to the FIB, the nexthops that are resolved and have two highest preferences are selected."; } NB> Would something like this be preferable "To download N nexthops to the FIB, the N nexthops with the lowest value ar= e selected". ------------------------ If I understand the yang syntax and semantics correctly, the "nh-add" RPC c= reates a nexthop in a given RIB that is not associated with any match condi= tion on a route. I assume the intention is to create a nexthop with a next= hop-id but not associated with any prefix that can then be referenced by mu= ltiple other route match conditions. This seems like a reasonable thing t= o do. However, I can see two possible issues with this. The first issue is that the structure of the data model doesn't seem to not= allow this. "grouping route" uses "grouping route-prefix" next to "cont= ainer next-hop". It appears to me that as currently written "container mat= ch" in "grouping route-prefix" is a mandatory node based on section 3.1 of= RFC6020 , since the "mandatory" statements below choice/cases cascade up t= o the container. So the current form of the "nh-add" RPC may not be cons= istent with the data model as currently defined. The second issue is that creating a next-hop without an associated match ap= pears to differ from the RIB grammar defined in section 6 of draft-ietf-i2r= s-rib-info-model-08. In the RIB info model, it seems that the only way for = a to appear is together with a . ::=3D [] [] NB> I'm not sure if I agree with the creation of nexthop discrepancy. A nex= thop can be created independently and then in the , you can referenc= e the relevant nexthop-id. ::=3D =3D =3D ------------------------ Treating tunnel-decap as a type of next-hop doesn't make sense to me. I ass= ume the desire to include tunnel-decap as well as tunnel-encap is to have a= usable stand-alone data model module which to deal with some use cases wit= hout having to rely on another module that defines tunnel-decap. However, = the result doesn't make sense. I think the most common scenario involving = routers would be to install a route on router A for prefix P whose nexthop = is a tunnel-encap whose destination is router B. One router B one would n= eed to install a corresponding tunnel-decap whose source is router A. The = most common scenario is then that router B does a normal route lookup on th= e decapsulated packet independent of the interface it entered on. I don't see how this most common use case would be handled with the tunnel-= decap next-hop in this document. NB> On router B, condition would be the incoming label and the "act= ion" to be taken on that would be "decap" the MPLS label. And you can chain= that with to say continue the route lookup in say "inet.0". The= draft says, "RIB_NAME: A nexthop pointing to a RIB indicates that the rout= e lookup needs to continue in the specified RIB." NB> Does that address your concern? Section 7.2.5. of draft-ietf-i2rs-rib-info-model-08 gives an example usage = for tunnel-decap where the tunnel-decap nexthop is used to pop an MPLS labe= l and send the traffic out an egress interface next-hop. This example is n= ot the most common scenario. And if we want to accomplish this scenario of = decapsulating and sending to a particular nexthop, it makes more sense to = treat tunnel-decap as a route match condition similar to an interface-route= in the existing data model. However, I think the model should be able to = handle the more common scenario described above when traffic needs to be de= capsulated and routed based on a normal route lookup. Treating tunnel-decap as a next-hop type really makes no sense to me. I th= ink this aspect of the model should be changed. NB> See above comment. Thanks Nitin --_000_BY2PR05MB61474F2979A888D4D6D520DA9120BY2PR05MB614namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Nitin and Mach,

 

Thanks for your responses. Jeff Haas = suggested to me that we keep track of issues for this on the I2RS wiki at:<= o:p>

 

http://trac.tools.ietf.org/wg/i2rs/t= rac/wiki/IssuesRibDataModel

 

So far, I posted one issue that I thi= nk needs more discussion.  I copied it below.  Please feel free t= o edit the Wiki as part of the discussion as well.

Issue 1: Should we define tunnel encapsulation and tunnel decapsulation= as next-hops in the RIB data model?

The RIB data model can model some types of encapsulation and decapsulati= on by treating encapsulation and decapsulation as next-hops. For encapsulat= ion, a route is paired with a tunnel-encap-nexthop. For decapsulation, an i= nitial route match condition is paired with a next-hop chain which consists of a tunnel-decap-nexthop and = another nexthop such as rib-name-nexthop or an egress-interface-nexthop.

1) It is not clear if this model for decapsulation supports all useful e= ncapsulation types. For example, it is not clear that the route-match-types= currently in dr= aft-ietf-i2rs-rib-data-model-03 can be used to select traffic for GRE, = NVGRE, and VXLAN decapsulation. One could consider extending the route-matc= h-types to include the header information needed to identify other encapsulation types. However, this may also be a = sign that the basic approach should be re-evaluated.

2) Does treating tunnel-encap and tunnel-decap as next-hops result in a = data model that is easy to use for someone trying to program network forwar= ding behavior? From the point-of-view of a user of the data model, modeling= tunnels as interfaces seems more useful. Treating tunnel decapsulation as a type of ingress interface and t= unnel encapsulation as a type of egress interface would fit with the curren= t RIB model (which already has the concept of an interface-route and an int= erface-nexthop.) And it would reduce the amount of next-hop chaining that is required to make tunnels work comp= ared to the current model.

Thanks,

Chris

 

From: Nitin Bahadur [mailto:nitin_ba= hadur@yahoo.com]
Sent: Monday, November 09, 2015 5:53 PM
To: Chris Bowers <cbowers@juniper.net>; i2rs@ietf.org; Mach Ch= en <mach.chen@huawei.com>
Subject: Re: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03

 

Hi Chris,

 

      Thanks for spendin= g time on the spec. Please see NB> below for some of the issues you have= raised.

 

------------------------

The description of the nexthop-preferen= ce-def (see below) is confusing.  First, I assume there is an error in= the text since the example of downloading primary/standby/tertiary nexthops to the FIB should presumably select three nexthops, but the text = refers to selecting the two resolved nexthops with the highest preference .=  

 

NB> That is a typo IMO.

 

More fundamentally, this example seems = to  imply that only two next-hops will get downloaded to the FIB, wher= eas  one could imagine an implementation that uses three, four, five or more nexthops of different preferences.  If hard= ware supports more than two next-hop preferences being installed in the FIB= , then what is the mechanism for the client to learn how many preference va= lues are supported?  This should all be made clearer in the text.

 

    typedef nexthop-preference-def {=

       type uint= 8 {

       &nbs= p; range "1..99";

       }<= span style=3D"font-size:11.5pt;font-family:"Calibri",sans-serif;c= olor:black">

       descripti= on

       &nbs= p; "Nexthop-preference is used for protection schemes.

       &nbs= p;  It is an integer value between 1 and 99.  A lower

       &nbs= p;  value indicates higher preference.  To download a

       &nbs= p;  primary/standby/tertiary group to the FIB, the

       &nbs= p;  nexthops that are resolved and have two highest

       &nbs= p;  preferences are selected.";

     }

 

NB> Would something like this be pre= ferable

"To download N nexthops to the FIB, the N nexthops w= ith the lowest value are selected”.

 

 

------------------------

If I understand the yang syntax and sem= antics correctly, the “nh-add” RPC creates a nexthop in a given= RIB that is not associated with any match condition on a route.  I assume the intention is to create a nexthop with a nexthop-= id but not associated with any prefix that can then be referenced by multip= le other route match conditions.   This seems like a reasonable t= hing to do.  However, I can see two possible issues with this.

 

The first issue is that the structure o= f the data model doesn’t seem to not allow this.   “g= rouping route” uses “grouping route-prefix”  next to= “container next-hop”.  It appears to me that as currently written “container match” i= n  “grouping route-prefix” is a mandatory node based on se= ction 3.1 of RFC6020 , since the “mandatory” statements below c= hoice/cases cascade up to the container.    So the current f= orm of the “nh-add” RPC may not be consistent with the data model as currently defined.

 

The second issue is that creating a nex= t-hop without an associated match appears to differ from the RIB grammar de= fined in section 6 of draft-ietf-i2rs-rib-info-model-08. In the RIB info model, it seems that the only way for a <nexthop> to= appear is together with a <match>.

 

  <route> ::=3D <match> <n= exthop>

       &nbs= p;      [<route-attributes>]

       &nbs= p;      [<route-vendor-attributes>]

 

 

NB> I’m not sure if I agree with the creati= on of nexthop discrepancy. A nexthop can be created independently and then = in the <route>, you can reference the relevant nexthop-id.=

 

<route> ::=3D <match> <nexthop>

              &nb= sp;   =3D <match> <nexthop-base>

              &nb= sp;   =3D <match> <NEXTHOP_ID>

 

 

------------------------

Treating tunnel-decap as a type of next= -hop doesn’t make sense to me. I assume the desire to include tunnel-= decap as well as tunnel-encap is to have a usable stand-alone data model module which to deal with some use cases without having to rely= on another module that defines tunnel-decap.  However, the result doe= sn’t make sense.  I think the most common scenario involving rou= ters would be to install a route on router A for prefix P whose nexthop is a tunnel-encap whose destination is router B.&nb= sp;  One router B one would need to install a corresponding tunnel-dec= ap whose source is router A.  The most common scenario is then that ro= uter B does a normal route lookup on the decapsulated packet independent of the interface it entered on. =

 

I don’t see how this most common use case wou= ld be handled with the tunnel-decap next-hop in this document.<= /o:p>

 

NB> On router B,= <match> condition would be the incoming label and the “action&= #8221; to be taken on that would be “decap” the MPLS label. And= you can chain that with <RIB_NAME> to say continue the route lookup in say “inet.0”. The draft says, "RIB_NAME: A nexthop poi= nting to a RIB indicates that the route

    =
  lookup needs to continue in the specified RIB.”

NB> = Does that address your concern?


 

Section 7.2.5. of draft-ietf-i2rs-rib-i= nfo-model-08 gives an example usage for tunnel-decap where the tunnel-decap= nexthop is used to pop an MPLS label and send the traffic out an egress interface next-hop.  This example is not th= e most common scenario. And if we want to accomplish this scenario of = decapsulating and sending to a particular nexthop, it makes more sense to = treat tunnel-decap as a route match condition similar to an interface-route in the existing data model.  However, I= think the model should be able to handle the more common scenario describe= d above when traffic needs to be decapsulated and routed based on a normal = route lookup.

 

Treating tunnel-dec= ap as a next-hop type really makes no sense to me.  I think this aspec= t of the model should be changed.

 

NB> See above comment.

 

Thanks

Nitin

--_000_BY2PR05MB61474F2979A888D4D6D520DA9120BY2PR05MB614namprd_-- From nobody Thu Nov 12 15:16:06 2015 Return-Path: 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 459D31B3AB1 for ; Thu, 12 Nov 2015 15:16:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 LTYdNIx95rM2 for ; Thu, 12 Nov 2015 15:16:02 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 922501B3AAD for ; Thu, 12 Nov 2015 15:16:01 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CEA39722; Thu, 12 Nov 2015 23:15:59 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 12 Nov 2015 23:15:57 +0000 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0235.001; Thu, 12 Nov 2015 15:15:52 -0800 From: Linda Dunbar To: Russ White <7riw77@gmail.com>, "i2rs@ietf.org" Thread-Topic: [i2rs] Ownership and Subscription Thread-Index: AdEV0CXx69e2m0PhTXO3QDOWmk66OQHyjCLg Date: Thu, 12 Nov 2015 23:15:52 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657D819A7@dfweml701-chm> References: <00cf01d115d1$73765ca0$5a6315e0$@gmail.com> In-Reply-To: <00cf01d115d1$73765ca0$5a6315e0$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.236] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.56451DAF.007B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: b3c15c18512bc1c39ff1abd85bd1f45f Archived-At: Subject: Re: [i2rs] Ownership and Subscription X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 23:16:04 -0000 Russ,=20 Is it referring to the draft-ietf-i2rs-pub-sub-requirements-03? Some questions:=20 - the information that Applications need is probably not the original YANG = data model values. I would think that the information any application need = are some level of processed information based on the YANG data model collec= ted by the I2RS Agent.=20 - Why does I2RS need to worry about the ownership information?=20 - Why can't notification run in parallel with the pub/sub?=20 Linda=20 =20 -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Russ White Sent: Monday, November 02, 2015 6:49 PM To: i2rs@ietf.org Subject: [i2rs] Ownership and Subscription Y'all -- After some thought on the entire ownership and subscription issue raised ye= sterday in the WG meeting -- to repeat the problem for those who weren't th= ere... If an application/controller installs state into a particular agent = running on a particular network node, what should we do with the notificati= ons, etc.? Should the agent maintain some sort of "ownership" of the item i= n some way, so the agent can notify the owner/installer when their informat= ion is overwritten? Or should such notifications simply be pub/sub, where a= nyone (including the owner) can subscribe to changes in the item? I actually think the answer is both... IMHO, the agent should maintain a "w= ho installed this" set of bits, but do nothing with these bits other than m= aintain them and include them in any notifications. These "bits" don't need= to be anything complicated -- any sort of nonce would do, somehow calculat= ed so there is little chance of the bits being replicated between controlle= rs (a problem to be solved later, probably, or outside the confines of the = protocol definition). My thinking is this -- when something is installed in= the local ephemeral state by the agent, then the process might look like -= - 1. The install signal is received 2. The priorities are examined, and the specific state installed 3. The ins= taller is automatically subscribed to the notifications (the installer can = decide to be removed from the pub/sub, but subscription should be on by def= ault) 4. If the installer's state is overwritten, it receives a notificatio= n 5. This notification contains the "owner bits," which is really just shor= thand for the installer to quickly check to see if "I installed this" Local policy in the controller might use this information in different ways= . It's really just a bit of shorthand to help the controllers process things = more efficiently, rather than real "ownership bits" in the more traditional= sense. This seems like it solves the problems at hand -- ownership only implies su= bscription because the subscribe happens by default, but it's not really at= tached to the "ownership bits." It also, however, provides a shortcut for t= he "owner" to know what's going on with "their" installed state. Thoughts? :-) Russ =20 _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Fri Nov 13 01:37:15 2015 Return-Path: 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 007471A874B for ; Fri, 13 Nov 2015 01:37:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 8oABK2bK1YA3 for ; Fri, 13 Nov 2015 01:37:10 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F03941A873B for ; Fri, 13 Nov 2015 01:37:09 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CAG94190; Fri, 13 Nov 2015 09:37:08 +0000 (GMT) Received: from SZXEMA414-HUB.china.huawei.com (10.82.72.73) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 13 Nov 2015 09:37:07 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.229]) by SZXEMA414-HUB.china.huawei.com ([10.82.72.73]) with mapi id 14.03.0235.001; Fri, 13 Nov 2015 17:36:59 +0800 From: Mach Chen To: Chris Bowers , Nitin Bahadur , "i2rs@ietf.org" Thread-Topic: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 Thread-Index: AQHRG1IjbUKB4wbpWkONHUipG28+956XN3YAgAJ8vKCAAAAhwA== Date: Fri, 13 Nov 2015 09:36:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.135] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.5645AF44.01A9, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.229, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: bb7990b17777f4c6b66d4d4919cb884e Archived-At: Subject: Re: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 09:37:14 -0000 Hi Chris, Thanks for raising the issue and putting it on the I2RS wiki! The current data model is aligned with the info model. Regarding the tunnel= encap and decap, the info model is defined as is. Regarding GRE, NvGRE or VxLAN decapsulation, in my understanding, they are = actually IP tunnels, and the current model has already support IPv4/IPv6 IP= tunnel decapsulation. Or maybe I missed something? Best regards, Mach > From: Chris Bowers [mailto:cbowers@juniper.net] > Sent: Thursday, November 12, 2015 11:28 AM > To: Nitin Bahadur; i2rs@ietf.org; Mach Chen > Subject: RE: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 >=20 > Nitin and Mach, >=20 > Thanks for your responses. Jeff Haas suggested to me that we keep track o= f > issues for this on the I2RS wiki at: >=20 > http://trac.tools.ietf.org/wg/i2rs/trac/wiki/IssuesRibDataModel >=20 > So far, I posted one issue that I think needs more discussion.=A0 I copie= d it > below.=A0 Please feel free to edit the Wiki as part of the discussion as = well. > Issue 1: Should we define tunnel encapsulation and tunnel decapsulation a= s > next-hops in the RIB data model? > The RIB data model can model some types of encapsulation and decapsulatio= n > by treating encapsulation and decapsulation as next-hops. For encapsulati= on, a > route is paired with a tunnel-encap-nexthop. For decapsulation, an initia= l route > match condition is paired with a next-hop chain which consists of a > tunnel-decap-nexthop and another nexthop such as rib-name-nexthop or an > egress-interface-nexthop. > 1) It is not clear if this model for decapsulation supports all useful en= capsulation > types. For example, it is not clear that the route-match-types currently = in > draft-ietf-i2rs-rib-data-model-03 can be used to select traffic for GRE, = NVGRE, > and VXLAN decapsulation.=20 > One could consider extending the route-match-types > to include the header information needed to identify other encapsulation = types. > However, this may also be a sign that the basic approach should be > re-evaluated. > 2) Does treating tunnel-encap and tunnel-decap as next-hops result in a d= ata > model that is easy to use for someone trying to program network forwardin= g > behavior? From the point-of-view of a user of the data model, modeling tu= nnels > as interfaces seems more useful. Treating tunnel decapsulation as a type = of > ingress interface and tunnel encapsulation as a type of egress interface = would > fit with the current RIB model (which already has the concept of an > interface-route and an interface-nexthop.) And it would reduce the amount= of > next-hop chaining that is required to make tunnels work compared to the > current model. > Thanks, > Chris >=20 >=20 > From: Nitin Bahadur [mailto:nitin_bahadur@yahoo.com] > Sent: Monday, November 09, 2015 5:53 PM > To: Chris Bowers ; i2rs@ietf.org; Mach Chen > > Subject: Re: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 >=20 > Hi Chris, >=20 > =A0 =A0 =A0 Thanks for spending time on the spec. Please see NB> below fo= r some > of the issues you have raised. >=20 > ------------------------ > The description of the nexthop-preference-def (see below) is confusing.= =A0 First, > I assume there is an error in the text since the example of downloading > primary/standby/tertiary nexthops to the FIB should presumably select thr= ee > nexthops, but the text refers to selecting the two resolved nexthops with= the > highest preference . >=20 > NB> That is a typo IMO. >=20 > More fundamentally, this example seems to=A0 imply that only two next-hop= s > will get downloaded to the FIB, whereas=A0 one could imagine an > implementation that uses three, four, five or more nexthops of different > preferences.=A0 If hardware supports more than two next-hop preferences > being installed in the FIB, then what is the mechanism for the client to = learn > how many preference values are supported?=A0 This should all be made clea= rer > in the text. >=20 > =A0 =A0 typedef nexthop-preference-def { > =A0=A0=A0=A0=A0=A0 type uint8 { > =A0=A0=A0=A0=A0=A0=A0=A0 range "1..99"; > =A0=A0=A0=A0=A0=A0 } > =A0=A0=A0=A0=A0=A0 description > =A0=A0=A0=A0=A0=A0=A0=A0 "Nexthop-preference is used for protection schem= es. > =A0=A0=A0=A0=A0=A0=A0=A0=A0 It is an integer value between 1 and 99.=A0 A= lower > =A0=A0=A0=A0=A0=A0=A0=A0=A0 value indicates higher preference.=A0 To down= load a > =A0=A0=A0=A0=A0=A0=A0=A0=A0 primary/standby/tertiary group to the FIB, th= e > =A0=A0=A0=A0=A0=A0=A0=A0=A0 nexthops that are resolved and have two highe= st > =A0=A0=A0=A0=A0=A0=A0=A0=A0 preferences are selected."; > =A0=A0=A0=A0 } >=20 > NB> Would something like this be preferable > "To download N nexthops to=A0the=A0FIB, the N nexthops with the lowest va= lue > are selected". >=20 >=20 > ------------------------ > If I understand the yang syntax and semantics correctly, the "nh-add" RPC > creates a nexthop in a given RIB that is not associated with any match > condition on a route.=A0 I assume the intention is to create a nexthop wi= th a > nexthop-id but not associated with any prefix that can then be referenced= by > multiple other route match conditions.=A0=A0 This seems like a reasonable= thing to > do.=A0 However, I can see two possible issues with this. >=20 > The first issue is that the structure of the data model doesn't seem to n= ot > allow this.=A0=A0 "grouping route" uses "grouping route-prefix"=A0 next t= o > "container next-hop".=A0 It appears to me that as currently written "cont= ainer > match" in=A0 "grouping route-prefix" is a mandatory node based on section= 3.1 > of RFC6020 , since the "mandatory" statements below choice/cases cascade > up to the container.=A0=A0=A0 So the current form of the "nh-add" RPC may= not be > consistent with the data model as currently defined. >=20 > The second issue is that creating a next-hop without an associated match > appears to differ from the RIB grammar defined in section 6 of > draft-ietf-i2rs-rib-info-model-08. In the RIB info model, it seems that t= he only > way for a to appear is together with a . >=20 > =A0 ::=3D > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [] > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [] >=20 >=20 > NB> I'm not sure if I agree with the creation of nexthop discrepancy. A n= exthop > can be created independently and then in the , you can reference t= he > relevant nexthop-id. >=20 > ::=3D > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D >=20 >=20 > ------------------------ > Treating tunnel-decap as a type of next-hop doesn't make sense to me. I > assume the desire to include tunnel-decap as well as tunnel-encap is to h= ave a > usable stand-alone data model module which to deal with some use cases > without having to rely on another module that defines > tunnel-decap.=A0 However, the result doesn't make sense.=A0 I think the m= ost > common scenario involving routers would be to install a route on router A= for > prefix P whose nexthop is a tunnel-encap whose destination is router B.= =A0=A0 One > router B one would need to install a corresponding tunnel-decap whose sou= rce > is router A.=A0 The most common scenario is then that router B does a nor= mal > route lookup on the decapsulated packet independent of the interface it > entered on. >=20 > I don't see how this most common use case would be handled with the > tunnel-decap next-hop in this document. >=20 > NB> On router B, condition would be the incoming label and the > "action" to be taken on that would be "decap" the MPLS label. And you can > chain that with to say continue the route lookup in say "inet.= 0". > The draft says, "RIB_NAME: A nexthop pointing to a RIB indicates that the > route > =A0=A0=A0=A0=A0 lookup needs to continue in the specified RIB." >=20 > NB> Does that address your concern? >=20 >=20 > Section 7.2.5. of draft-ietf-i2rs-rib-info-model-08 gives an example usag= e for > tunnel-decap where the tunnel-decap nexthop is used to pop an MPLS label = and > send the traffic out an egress interface next-hop.=A0 This example is not= the > most common scenario. And if we want to accomplish this scenario > of=A0 decapsulating and sending to a particular nexthop, it makes more se= nse to > treat tunnel-decap as a route match condition similar to an interface-rou= te in > the existing data model.=A0 However, I think the model should be able to = handle > the more common scenario described above when traffic needs to be > decapsulated and routed based on a normal route lookup. >=20 > Treating tunnel-decap as a next-hop type really makes no sense to me.=A0 = I think > this aspect of the model should be changed. >=20 > NB> See above comment. >=20 > Thanks > Nitin From nobody Sat Nov 14 08:38:24 2015 Return-Path: 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 E776C1A903F for ; Sat, 14 Nov 2015 08:38:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 H6O2uem1qP2U for ; Sat, 14 Nov 2015 08:38:20 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0755.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:755]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 859C81A8F42 for ; Sat, 14 Nov 2015 08:38:19 -0800 (PST) Received: from BY2PR05MB614.namprd05.prod.outlook.com (10.141.218.148) by BY2PR05MB613.namprd05.prod.outlook.com (10.141.218.145) with Microsoft SMTP Server (TLS) id 15.1.318.15; Sat, 14 Nov 2015 16:37:55 +0000 Received: from BY2PR05MB614.namprd05.prod.outlook.com ([10.141.218.148]) by BY2PR05MB614.namprd05.prod.outlook.com ([10.141.218.148]) with mapi id 15.01.0318.003; Sat, 14 Nov 2015 16:37:55 +0000 From: Chris Bowers To: Mach Chen , Nitin Bahadur , "i2rs@ietf.org" Thread-Topic: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 Thread-Index: AQHRG1IjVu9gg5MiSU6fmCG9ahcIBp6XN3YAgAJ8vKCAAAAhwIAA2Y5Q Date: Sat, 14 Nov 2015 16:37:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=cbowers@juniper.net; x-originating-ip: [66.129.239.14] x-microsoft-exchange-diagnostics: 1; BY2PR05MB613; 5:trpOb6YZNYJsyrwA8WfX2u1Fm2o50IMq25hObuoPKOYZGpAmEAfEDuXnbdxuo5zojIfpXuu1m9ZKgH9jZf9sRh/5BDzYIpAFOGS805oRCsnXiqOx7jiqm8UoZlGg402+68lQLCakB6sdqstxXp2usw==; 24:t8F2WvoBwH7HTk2c3k0U0VxIVnjATBX3ctZhUAcGKJ+9H6+PWA2DX6B6v2phuxEtOvCogcnAC/d6w66FARF78g+P4KGJyqkEGtSCFZ2fMj4=; 20:GLc9xV//p1WUa2TWTPBD5FRfv0EPNCAVPGBLCibTOwLmqfwZWVXjC3H5FcdhMMwGEuEiuLhVZZI0LUldOnQfNA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB613; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(201166117486090)(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(10201501046)(3002001); SRVR:BY2PR05MB613; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB613; x-forefront-prvs: 07607ED19A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(31014005)(199003)(377454003)(13464003)(52604005)(164054003)(189002)(52044002)(15975445007)(87936001)(2521001)(102836002)(10400500002)(5004730100002)(1720100001)(19580405001)(77096005)(5002640100001)(97736004)(19580395003)(92566002)(2900100001)(99286002)(2950100001)(5007970100001)(105586002)(81156007)(106356001)(66066001)(106116001)(2501003)(33656002)(74316001)(76176999)(5001960100002)(189998001)(5003600100002)(230783001)(107886002)(76576001)(50986999)(5001920100001)(101416001)(86362001)(586003)(5008740100001)(11100500001)(5001770100001)(54356999)(40100003)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB613; H:BY2PR05MB614.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Nov 2015 16:37:55.0977 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB613 Archived-At: Subject: Re: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2015 16:38:24 -0000 Mach, I may be overlooking something, but I don't see how one can use the element= s in the current data model to configure a router to decapsulate GRE, NVGRE= or VxLAN in the following scenario. =20 Assume we have 4 types of tunneled traffic arriving at the router with the = same source and destination IP address. The decapsulated packets need to b= e processed by 4 different rib-name-nexthops depending on information in t= he encapsulation header. In this example, the four different tunneled traf= fic types are IP-in-IP, IP in GRE, and VxLAN encapsulated traffic with two = different VNIs, so the different packet headers look like this (only the re= levant fields are shown): 1) ip src=3D1.1.1.1, ip dest=3D2.2.2.2,protocol number=3D4 , inner IP packe= t 2) ip src=3D1.1.1.1, ip dest=3D2.2.2.2,protocol number=3D47, inner IP packe= t 3) ip src=3D1.1.1.1, ip dest=3D2.2.2.2,protocol number=3D17, udp dest port= =3D 4789, VNI=3D920, inner Ethernet frame 4) ip src=3D1.1.1.1, ip dest=3D2.2.2.2,protocol number=3D17, udp dest port= =3D 4789, VNI=3D921, inner Ethernet frame There are a few ways that one might think about accomplishing decapsulation= of these packets into different rib-name-nexthops using the next-hop chain= ing in the data model. However, regardless of the particular choice of how= to chain next-hops and route matches, at some point one needs to be able t= o do a route match based on IP protocol number to distinguish between IP in= IP, GRE, and UDP. In addition, one needs to be able to match on UDP desti= nation port to distinguish VxLAN from other UDP traffic with the same src/d= est address. Finally one needs to be able to match on VNI in order to be a= ble to demultiplex the two streams of VxLAN traffic into different rib-name= -nexthops. I don't see that these values (IP protocol number, UDP dest port, or VNI) a= re currently included in the route match conditions in the model, so I don'= t see how the current data model can be used to configure a router to disti= nguish between these traffic types while performing decapsulation. If the above analysis is correct, then one might consider adding additional= route match conditions to cover these decapsulation cases. However, it m= ay also make sense to consider other approaches to modeling tunnels. Thanks, Chris =20 -----Original Message----- From: Mach Chen [mailto:mach.chen@huawei.com]=20 Sent: Friday, November 13, 2015 3:37 AM To: Chris Bowers ; Nitin Bahadur ; i2rs@ietf.org Subject: RE: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 Hi Chris, Thanks for raising the issue and putting it on the I2RS wiki! The current data model is aligned with the info model. Regarding the tunnel= encap and decap, the info model is defined as is. Regarding GRE, NvGRE or VxLAN decapsulation, in my understanding, they are = actually IP tunnels, and the current model has already support IPv4/IPv6 IP= tunnel decapsulation. Or maybe I missed something? Best regards, Mach > From: Chris Bowers [mailto:cbowers@juniper.net] > Sent: Thursday, November 12, 2015 11:28 AM > To: Nitin Bahadur; i2rs@ietf.org; Mach Chen > Subject: RE: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 >=20 > Nitin and Mach, >=20 > Thanks for your responses. Jeff Haas suggested to me that we keep=20 > track of issues for this on the I2RS wiki at: >=20 > http://trac.tools.ietf.org/wg/i2rs/trac/wiki/IssuesRibDataModel >=20 > So far, I posted one issue that I think needs more discussion.=A0 I=20 > copied it below.=A0 Please feel free to edit the Wiki as part of the disc= ussion as well. > Issue 1: Should we define tunnel encapsulation and tunnel=20 > decapsulation as next-hops in the RIB data model? > The RIB data model can model some types of encapsulation and=20 > decapsulation by treating encapsulation and decapsulation as=20 > next-hops. For encapsulation, a route is paired with a=20 > tunnel-encap-nexthop. For decapsulation, an initial route match=20 > condition is paired with a next-hop chain which consists of a=20 > tunnel-decap-nexthop and another nexthop such as rib-name-nexthop or an e= gress-interface-nexthop. > 1) It is not clear if this model for decapsulation supports all useful=20 > encapsulation types. For example, it is not clear that the=20 > route-match-types currently in > draft-ietf-i2rs-rib-data-model-03 can be used to select traffic for=20 > GRE, NVGRE, and VXLAN decapsulation. > One could consider extending the route-match-types to include the=20 > header information needed to identify other encapsulation types. > However, this may also be a sign that the basic approach should be=20 > re-evaluated. > 2) Does treating tunnel-encap and tunnel-decap as next-hops result in=20 > a data model that is easy to use for someone trying to program network=20 > forwarding behavior? From the point-of-view of a user of the data=20 > model, modeling tunnels as interfaces seems more useful. Treating=20 > tunnel decapsulation as a type of ingress interface and tunnel=20 > encapsulation as a type of egress interface would fit with the current=20 > RIB model (which already has the concept of an interface-route and an=20 > interface-nexthop.) And it would reduce the amount of next-hop=20 > chaining that is required to make tunnels work compared to the current mo= del. > Thanks, > Chris >=20 >=20 > From: Nitin Bahadur [mailto:nitin_bahadur@yahoo.com] > Sent: Monday, November 09, 2015 5:53 PM > To: Chris Bowers ; i2rs@ietf.org; Mach Chen=20 > > Subject: Re: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 >=20 > Hi Chris, >=20 > =A0 =A0 =A0 Thanks for spending time on the spec. Please see NB> below fo= r=20 > some of the issues you have raised. >=20 > ------------------------ > The description of the nexthop-preference-def (see below) is=20 > confusing.=A0 First, I assume there is an error in the text since the=20 > example of downloading primary/standby/tertiary nexthops to the FIB=20 > should presumably select three nexthops, but the text refers to=20 > selecting the two resolved nexthops with the highest preference . >=20 > NB> That is a typo IMO. >=20 > More fundamentally, this example seems to=A0 imply that only two=20 > next-hops will get downloaded to the FIB, whereas=A0 one could imagine=20 > an implementation that uses three, four, five or more nexthops of=20 > different preferences.=A0 If hardware supports more than two next-hop=20 > preferences being installed in the FIB, then what is the mechanism for=20 > the client to learn how many preference values are supported?=A0 This=20 > should all be made clearer in the text. >=20 > =A0 =A0 typedef nexthop-preference-def { > =A0=A0=A0=A0=A0=A0 type uint8 { > =A0=A0=A0=A0=A0=A0=A0=A0 range "1..99"; > =A0=A0=A0=A0=A0=A0 } > =A0=A0=A0=A0=A0=A0 description > =A0=A0=A0=A0=A0=A0=A0=A0 "Nexthop-preference is used for protection schem= es. > =A0=A0=A0=A0=A0=A0=A0=A0=A0 It is an integer value between 1 and 99.=A0 A= lower > =A0=A0=A0=A0=A0=A0=A0=A0=A0 value indicates higher preference.=A0 To down= load a > =A0=A0=A0=A0=A0=A0=A0=A0=A0 primary/standby/tertiary group to the FIB, th= e > =A0=A0=A0=A0=A0=A0=A0=A0=A0 nexthops that are resolved and have two highe= st > =A0=A0=A0=A0=A0=A0=A0=A0=A0 preferences are selected."; > =A0=A0=A0=A0 } >=20 > NB> Would something like this be preferable > "To download N nexthops to=A0the=A0FIB, the N nexthops with the lowest=20 > value are selected". >=20 >=20 > ------------------------ > If I understand the yang syntax and semantics correctly, the "nh-add"=20 > RPC creates a nexthop in a given RIB that is not associated with any=20 > match condition on a route.=A0 I assume the intention is to create a=20 > nexthop with a nexthop-id but not associated with any prefix that can=20 > then be referenced by multiple other route match conditions.=A0=A0 This=20 > seems like a reasonable thing to do.=A0 However, I can see two possible i= ssues with this. >=20 > The first issue is that the structure of the data model doesn't seem=20 > to not allow this.=A0=A0 "grouping route" uses "grouping route-prefix"=A0= =20 > next to "container next-hop".=A0 It appears to me that as currently=20 > written "container match" in=A0 "grouping route-prefix" is a mandatory=20 > node based on section 3.1 of RFC6020 , since the "mandatory"=20 > statements below choice/cases cascade up to the container.=A0=A0=A0 So th= e=20 > current form of the "nh-add" RPC may not be consistent with the data mode= l as currently defined. >=20 > The second issue is that creating a next-hop without an associated=20 > match appears to differ from the RIB grammar defined in section 6 of=20 > draft-ietf-i2rs-rib-info-model-08. In the RIB info model, it seems=20 > that the only way for a to appear is together with a . >=20 > =A0 ::=3D > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [] > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [] >=20 >=20 > NB> I'm not sure if I agree with the creation of nexthop discrepancy.=20 > NB> A nexthop > can be created independently and then in the , you can=20 > reference the relevant nexthop-id. >=20 > ::=3D > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D >=20 >=20 > ------------------------ > Treating tunnel-decap as a type of next-hop doesn't make sense to me.=20 > I assume the desire to include tunnel-decap as well as tunnel-encap is=20 > to have a usable stand-alone data model module which to deal with some=20 > use cases without having to rely on another module that defines=20 > tunnel-decap.=A0 However, the result doesn't make sense.=A0 I think the=20 > most common scenario involving routers would be to install a route on=20 > router A for prefix P whose nexthop is a tunnel-encap whose=20 > destination is router B.=A0=A0 One router B one would need to install a=20 > corresponding tunnel-decap whose source is router A.=A0 The most common=20 > scenario is then that router B does a normal route lookup on the=20 > decapsulated packet independent of the interface it entered on. >=20 > I don't see how this most common use case would be handled with the=20 > tunnel-decap next-hop in this document. >=20 > NB> On router B, condition would be the incoming label and the > "action" to be taken on that would be "decap" the MPLS label. And you=20 > can chain that with to say continue the route lookup in say "i= net.0". > The draft says, "RIB_NAME: A nexthop pointing to a RIB indicates that=20 > the route > =A0=A0=A0=A0=A0 lookup needs to continue in the specified RIB." >=20 > NB> Does that address your concern? >=20 >=20 > Section 7.2.5. of draft-ietf-i2rs-rib-info-model-08 gives an example=20 > usage for tunnel-decap where the tunnel-decap nexthop is used to pop=20 > an MPLS label and send the traffic out an egress interface next-hop.=A0=20 > This example is not the most common scenario. And if we want to=20 > accomplish this scenario of=A0 decapsulating and sending to a particular= =20 > nexthop, it makes more sense to treat tunnel-decap as a route match=20 > condition similar to an interface-route in the existing data model.=A0=20 > However, I think the model should be able to handle the more common=20 > scenario described above when traffic needs to be decapsulated and routed= based on a normal route lookup. >=20 > Treating tunnel-decap as a next-hop type really makes no sense to me.=A0= =20 > I think this aspect of the model should be changed. >=20 > NB> See above comment. >=20 > Thanks > Nitin From nobody Sun Nov 15 19:05:47 2015 Return-Path: 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 4F4581B2A6B for ; Sun, 15 Nov 2015 19:05:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.786 X-Spam-Level: X-Spam-Status: No, score=-4.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham 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 cutctzwqytYs for ; Sun, 15 Nov 2015 19:05:41 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F23DD1B2A68 for ; Sun, 15 Nov 2015 19:05:40 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CAJ39640; Mon, 16 Nov 2015 03:05:38 +0000 (GMT) Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 16 Nov 2015 03:05:37 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.73]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0235.001; Mon, 16 Nov 2015 11:05:32 +0800 From: Mach Chen To: Chris Bowers , Nitin Bahadur , "i2rs@ietf.org" Thread-Topic: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 Thread-Index: AQHRG1IjbUKB4wbpWkONHUipG28+956XN3YAgAJ8vKCAAAAhwIABhIyAgAK/DUA= Date: Mon, 16 Nov 2015 03:05:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.135] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.56494802.0065, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.73, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: bb7990b17777f4c6b66d4d4919cb884e Archived-At: Subject: Re: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 03:05:45 -0000 Hi Chris, Much thanks for the detailed explanation! In my understanding, the I2RS intends to leverage the existing RIB design. = Regarding to tunnel decap, normally, the protocol number and udp port belon= g to the protocol stack process, they are not parts of the rib. As for the = VNI and VSI, since they are new, the implementations may be different. But = they may also not be necessary as part of a route to be installed in the ri= b. They can just be decapsulated by the VxLan/NvGRE protocol stack process = and used as an identifier to find the next rib (e.g., the MAC rib), and the= n perform another rib lookup. If I am wrong, please correct me. Regarding to the suggestion to change tunnel-decap to tunnel-interface, thi= s will require not only to modify the current data model, but to modify the= info model that has already passed the WG last call. I hope to hear the op= inions of the WG. Best regards, Mach > -----Original Message----- > From: Chris Bowers [mailto:cbowers@juniper.net] > Sent: Sunday, November 15, 2015 12:38 AM > To: Mach Chen; Nitin Bahadur; i2rs@ietf.org > Subject: RE: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 >=20 > Mach, >=20 > I may be overlooking something, but I don't see how one can use the eleme= nts > in the current data model to configure a router to decapsulate GRE, NVGRE= or > VxLAN in the following scenario. >=20 > Assume we have 4 types of tunneled traffic arriving at the router with th= e same > source and destination IP address. The decapsulated packets need to be > processed by 4 different rib-name-nexthops depending on information in t= he > encapsulation header. In this example, the four different tunneled traff= ic > types are IP-in-IP, IP in GRE, and VxLAN encapsulated traffic with two di= fferent > VNIs, so the different packet headers look like this (only the relevant f= ields are > shown): >=20 > 1) ip src=3D1.1.1.1, ip dest=3D2.2.2.2,protocol number=3D4 , inner IP pac= ket > 2) ip src=3D1.1.1.1, ip dest=3D2.2.2.2,protocol number=3D47, inner IP pac= ket > 3) ip src=3D1.1.1.1, ip dest=3D2.2.2.2,protocol number=3D17, udp dest por= t=3D 4789, > VNI=3D920, inner Ethernet frame > 4) ip src=3D1.1.1.1, ip dest=3D2.2.2.2,protocol number=3D17, udp dest por= t=3D 4789, > VNI=3D921, inner Ethernet frame >=20 > There are a few ways that one might think about accomplishing decapsulati= on > of these packets into different rib-name-nexthops using the next-hop chai= ning > in the data model. However, regardless of the particular choice of how t= o > chain next-hops and route matches, at some point one needs to be able to = do a > route match based on IP protocol number to distinguish between IP in IP, = GRE, > and UDP. In addition, one needs to be able to match on UDP destination p= ort > to distinguish VxLAN from other UDP traffic with the same src/dest addres= s. > Finally one needs to be able to match on VNI in order to be able to demul= tiplex > the two streams of VxLAN traffic into different rib-name-nexthops. >=20 > I don't see that these values (IP protocol number, UDP dest port, or VNI)= are > currently included in the route match conditions in the model, so I don't= see > how the current data model can be used to configure a router to distingui= sh > between these traffic types while performing decapsulation. >=20 > If the above analysis is correct, then one might consider adding addition= al route > match conditions to cover these decapsulation cases. However, it may al= so > make sense to consider other approaches to modeling tunnels. >=20 > Thanks, > Chris >=20 > -----Original Message----- > From: Mach Chen [mailto:mach.chen@huawei.com] > Sent: Friday, November 13, 2015 3:37 AM > To: Chris Bowers ; Nitin Bahadur > ; i2rs@ietf.org > Subject: RE: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 >=20 > Hi Chris, >=20 > Thanks for raising the issue and putting it on the I2RS wiki! >=20 > The current data model is aligned with the info model. Regarding the tunn= el > encap and decap, the info model is defined as is. >=20 > Regarding GRE, NvGRE or VxLAN decapsulation, in my understanding, they ar= e > actually IP tunnels, and the current model has already support IPv4/IPv6 = IP > tunnel decapsulation. Or maybe I missed something? >=20 > Best regards, > Mach >=20 > > From: Chris Bowers [mailto:cbowers@juniper.net] > > Sent: Thursday, November 12, 2015 11:28 AM > > To: Nitin Bahadur; i2rs@ietf.org; Mach Chen > > Subject: RE: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 > > > > Nitin and Mach, > > > > Thanks for your responses. Jeff Haas suggested to me that we keep > > track of issues for this on the I2RS wiki at: > > > > http://trac.tools.ietf.org/wg/i2rs/trac/wiki/IssuesRibDataModel > > > > So far, I posted one issue that I think needs more discussion.=A0 I > > copied it below.=A0 Please feel free to edit the Wiki as part of the di= scussion as > well. > > Issue 1: Should we define tunnel encapsulation and tunnel > > decapsulation as next-hops in the RIB data model? > > The RIB data model can model some types of encapsulation and > > decapsulation by treating encapsulation and decapsulation as > > next-hops. For encapsulation, a route is paired with a > > tunnel-encap-nexthop. For decapsulation, an initial route match > > condition is paired with a next-hop chain which consists of a > > tunnel-decap-nexthop and another nexthop such as rib-name-nexthop or an > egress-interface-nexthop. > > 1) It is not clear if this model for decapsulation supports all useful > > encapsulation types. For example, it is not clear that the > > route-match-types currently in > > draft-ietf-i2rs-rib-data-model-03 can be used to select traffic for > > GRE, NVGRE, and VXLAN decapsulation. > > One could consider extending the route-match-types to include the > > header information needed to identify other encapsulation types. > > However, this may also be a sign that the basic approach should be > > re-evaluated. > > 2) Does treating tunnel-encap and tunnel-decap as next-hops result in > > a data model that is easy to use for someone trying to program network > > forwarding behavior? From the point-of-view of a user of the data > > model, modeling tunnels as interfaces seems more useful. Treating > > tunnel decapsulation as a type of ingress interface and tunnel > > encapsulation as a type of egress interface would fit with the current > > RIB model (which already has the concept of an interface-route and an > > interface-nexthop.) And it would reduce the amount of next-hop > > chaining that is required to make tunnels work compared to the current > model. > > Thanks, > > Chris > > > > > > From: Nitin Bahadur [mailto:nitin_bahadur@yahoo.com] > > Sent: Monday, November 09, 2015 5:53 PM > > To: Chris Bowers ; i2rs@ietf.org; Mach Chen > > > > Subject: Re: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 > > > > Hi Chris, > > > > =A0 =A0 =A0 Thanks for spending time on the spec. Please see NB> below = for > > some of the issues you have raised. > > > > ------------------------ > > The description of the nexthop-preference-def (see below) is > > confusing.=A0 First, I assume there is an error in the text since the > > example of downloading primary/standby/tertiary nexthops to the FIB > > should presumably select three nexthops, but the text refers to > > selecting the two resolved nexthops with the highest preference . > > > > NB> That is a typo IMO. > > > > More fundamentally, this example seems to=A0 imply that only two > > next-hops will get downloaded to the FIB, whereas=A0 one could imagine > > an implementation that uses three, four, five or more nexthops of > > different preferences.=A0 If hardware supports more than two next-hop > > preferences being installed in the FIB, then what is the mechanism for > > the client to learn how many preference values are supported?=A0 This > > should all be made clearer in the text. > > > > =A0 =A0 typedef nexthop-preference-def { > > =A0=A0=A0=A0=A0=A0 type uint8 { > > =A0=A0=A0=A0=A0=A0=A0=A0 range "1..99"; > > =A0=A0=A0=A0=A0=A0 } > > =A0=A0=A0=A0=A0=A0 description > > =A0=A0=A0=A0=A0=A0=A0=A0 "Nexthop-preference is used for protection sch= emes. > > =A0=A0=A0=A0=A0=A0=A0=A0=A0 It is an integer value between 1 and 99.=A0= A lower > > =A0=A0=A0=A0=A0=A0=A0=A0=A0 value indicates higher preference.=A0 To do= wnload a > > =A0=A0=A0=A0=A0=A0=A0=A0=A0 primary/standby/tertiary group to the FIB, = the > > =A0=A0=A0=A0=A0=A0=A0=A0=A0 nexthops that are resolved and have two hig= hest > > =A0=A0=A0=A0=A0=A0=A0=A0=A0 preferences are selected."; > > =A0=A0=A0=A0 } > > > > NB> Would something like this be preferable > > "To download N nexthops to=A0the=A0FIB, the N nexthops with the lowest > > value are selected". > > > > > > ------------------------ > > If I understand the yang syntax and semantics correctly, the "nh-add" > > RPC creates a nexthop in a given RIB that is not associated with any > > match condition on a route.=A0 I assume the intention is to create a > > nexthop with a nexthop-id but not associated with any prefix that can > > then be referenced by multiple other route match conditions.=A0=A0 This > > seems like a reasonable thing to do.=A0 However, I can see two possible= issues > with this. > > > > The first issue is that the structure of the data model doesn't seem > > to not allow this.=A0=A0 "grouping route" uses "grouping route-prefix" > > next to "container next-hop".=A0 It appears to me that as currently > > written "container match" in=A0 "grouping route-prefix" is a mandatory > > node based on section 3.1 of RFC6020 , since the "mandatory" > > statements below choice/cases cascade up to the container.=A0=A0=A0 So = the > > current form of the "nh-add" RPC may not be consistent with the data mo= del > as currently defined. > > > > The second issue is that creating a next-hop without an associated > > match appears to differ from the RIB grammar defined in section 6 of > > draft-ietf-i2rs-rib-info-model-08. In the RIB info model, it seems > > that the only way for a to appear is together with a . > > > > =A0 ::=3D > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [] > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [] > > > > > > NB> I'm not sure if I agree with the creation of nexthop discrepancy. > > NB> A nexthop > > can be created independently and then in the , you can > > reference the relevant nexthop-id. > > > > ::=3D > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D > > > > > > ------------------------ > > Treating tunnel-decap as a type of next-hop doesn't make sense to me. > > I assume the desire to include tunnel-decap as well as tunnel-encap is > > to have a usable stand-alone data model module which to deal with some > > use cases without having to rely on another module that defines > > tunnel-decap.=A0 However, the result doesn't make sense.=A0 I think the > > most common scenario involving routers would be to install a route on > > router A for prefix P whose nexthop is a tunnel-encap whose > > destination is router B.=A0=A0 One router B one would need to install a > > corresponding tunnel-decap whose source is router A.=A0 The most common > > scenario is then that router B does a normal route lookup on the > > decapsulated packet independent of the interface it entered on. > > > > I don't see how this most common use case would be handled with the > > tunnel-decap next-hop in this document. > > > > NB> On router B, condition would be the incoming label and the > > "action" to be taken on that would be "decap" the MPLS label. And you > > can chain that with to say continue the route lookup in say > "inet.0". > > The draft says, "RIB_NAME: A nexthop pointing to a RIB indicates that > > the route > > =A0=A0=A0=A0=A0 lookup needs to continue in the specified RIB." > > > > NB> Does that address your concern? > > > > > > Section 7.2.5. of draft-ietf-i2rs-rib-info-model-08 gives an example > > usage for tunnel-decap where the tunnel-decap nexthop is used to pop > > an MPLS label and send the traffic out an egress interface next-hop. > > This example is not the most common scenario. And if we want to > > accomplish this scenario of=A0 decapsulating and sending to a particula= r > > nexthop, it makes more sense to treat tunnel-decap as a route match > > condition similar to an interface-route in the existing data model. > > However, I think the model should be able to handle the more common > > scenario described above when traffic needs to be decapsulated and rout= ed > based on a normal route lookup. > > > > Treating tunnel-decap as a next-hop type really makes no sense to me. > > I think this aspect of the model should be changed. > > > > NB> See above comment. > > > > Thanks > > Nitin From nobody Mon Nov 16 09:56:46 2015 Return-Path: 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 E77EC1AC449 for ; Mon, 16 Nov 2015 09:56:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.237 X-Spam-Level: X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MALFORMED_FREEMAIL=1.047, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham 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 taUHCOO7v6OC for ; Mon, 16 Nov 2015 09:56:43 -0800 (PST) Received: from nm21-vm7.bullet.mail.gq1.yahoo.com (nm21-vm7.bullet.mail.gq1.yahoo.com [98.136.217.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 457111AC44D for ; Mon, 16 Nov 2015 09:56:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1447696600; bh=w/VK4t8sxkNHqhKbNHNhXGpIR6CVRSAjvfY8sYeobMs=; h=Date:Subject:From:To:References:In-Reply-To:From:Subject; b=XXHBWWFstOFo8eYrykRy+liwjM8YOziuJo/9BdEL/NnZR1JKEyi7Sc8lAAZd7WUv9vvPls0j/Df7XT1GPRNENFcvWCcH5uiaHDT2IjPt8X8R69bYNYlRDfGloL6RLGWZCQcI7t14GoHfMrKGkHxKspPKtw6y7t9sN2obVcW/biP6SSJarleHLRD+DYSuZ9+6BN94lB4U6t89pzuBVR7dRPMuaMSSfsnETdd4XNDvsReLiuVuaTX3nHoNfxNmwHJ+qpfXtBOOI3nFnMDcuOK+idmjVIzPS6nba5gFq5bfVcpYAnVfiYgEVh3TbE19Fm4JhI+IA5xlconFHRGOk/Lwlg== Received: from [98.137.12.191] by nm21.bullet.mail.gq1.yahoo.com with NNFMP; 16 Nov 2015 17:56:40 -0000 Received: from [98.136.164.74] by tm12.bullet.mail.gq1.yahoo.com with NNFMP; 16 Nov 2015 17:56:40 -0000 Received: from [127.0.0.1] by smtp236.mail.gq1.yahoo.com with NNFMP; 16 Nov 2015 17:56:40 -0000 X-Yahoo-Newman-Id: 870753.98892.bm@smtp236.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 1wt1434VM1kg4ge2dZMyqcxFcIXLizonWFHmKgG7fsRIcCc 3OXsHdfI2husJASyh8hjrXY1Ri3d3GAgPrFPevILsETx5TiBgtBtMaPiKrHC 7_U7nM8Mb5VIyhveowHJj5_oejAjgU0I2nSH.QfYEY2U5Yikg0_kn8DyOhDk MNs_ibcsrJobHcqMXB8ZLxe2UFaJ_TI5yFR2JOK5D3RCw3EkUCUpdb49JRAM FUtjPJmPHyCu6j9VgI0OkdqiOEgvbvxcwfiAGfsrLfYfmodiMoqiyd8SNlTH nGdz0IAXzaK.QVLsQ7NR58GPSIpEjcea.6Dm8fRbuzqF9UUF0slKAfzm.fvZ J1lqKLh8n8ncenln3BMCCytTqC3wiiEVzjEccHZeuRyPLphMDk5QomsBcfwF Au2PHCq1Cp79VImpViIbgLbSQ1Uwpg2.O2XFlJ0f023ApGRvukr8_8064pBl 826XlQklFS8TPD0JXG0VKUCL._VBbniEp0.CuGOAn6POmvQXEGLMeHSQC8FT 4FCYOXUxxAvur62OeiekL_SP64wWwkGyH_UKTNbg2 X-Yahoo-SMTP: jU6Na92swBBdqSRkLOL9Cp_LhHZgQAQoL10- User-Agent: Microsoft-MacOutlook/14.4.4.140807 Date: Mon, 16 Nov 2015 09:56:34 -0800 From: Nitin Bahadur To: Mach Chen , Chris Bowers , "i2rs@ietf.org" Message-ID: Thread-Topic: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 17:56:46 -0000 Chris, I agree with Mach=B9s comment. To actually decap VxLan and do something intelligently, one needs something like a firewall rule. There is no routing protocol that provides rules on decap of VxLan packets. So the RIB in general does not contain this information in today=B9s routers (AFAIK). IMO, the content for this should go into http://tools.ietf.org/id/draft-kini-i2rs-fb-rib-info-model-02.txt Thanks Nitin On 11/15/15, 7:05 PM, "Mach Chen" wrote: >Hi Chris, > >Much thanks for the detailed explanation! > >In my understanding, the I2RS intends to leverage the existing RIB >design. Regarding to tunnel decap, normally, the protocol number and udp >port belong to the protocol stack process, they are not parts of the rib. >As for the VNI and VSI, since they are new, the implementations may be >different. But they may also not be necessary as part of a route to be >installed in the rib. They can just be decapsulated by the VxLan/NvGRE >protocol stack process and used as an identifier to find the next rib >(e.g., the MAC rib), and then perform another rib lookup. If I am wrong, >please correct me. > >Regarding to the suggestion to change tunnel-decap to tunnel-interface, >this will require not only to modify the current data model, but to >modify the info model that has already passed the WG last call. I hope to >hear the opinions of the WG. > >Best regards, >Mach > >> -----Original Message----- >> From: Chris Bowers [mailto:cbowers@juniper.net] >> Sent: Sunday, November 15, 2015 12:38 AM >> To: Mach Chen; Nitin Bahadur; i2rs@ietf.org >> Subject: RE: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 >>=20 >> Mach, >>=20 >> I may be overlooking something, but I don't see how one can use the >>elements >> in the current data model to configure a router to decapsulate GRE, >>NVGRE or >> VxLAN in the following scenario. >>=20 >> Assume we have 4 types of tunneled traffic arriving at the router with >>the same >> source and destination IP address. The decapsulated packets need to be >> processed by 4 different rib-name-nexthops depending on information in >>the >> encapsulation header. In this example, the four different tunneled >>traffic >> types are IP-in-IP, IP in GRE, and VxLAN encapsulated traffic with two >>different >> VNIs, so the different packet headers look like this (only the relevant >>fields are >> shown): >>=20 >> 1) ip src=3D1.1.1.1, ip dest=3D2.2.2.2,protocol number=3D4 , inner IP packet >> 2) ip src=3D1.1.1.1, ip dest=3D2.2.2.2,protocol number=3D47, inner IP packet >> 3) ip src=3D1.1.1.1, ip dest=3D2.2.2.2,protocol number=3D17, udp dest port=3D >>4789, >> VNI=3D920, inner Ethernet frame >> 4) ip src=3D1.1.1.1, ip dest=3D2.2.2.2,protocol number=3D17, udp dest port=3D >>4789, >> VNI=3D921, inner Ethernet frame >>=20 >> There are a few ways that one might think about accomplishing >>decapsulation >> of these packets into different rib-name-nexthops using the next-hop >>chaining >> in the data model. However, regardless of the particular choice of how >>to >> chain next-hops and route matches, at some point one needs to be able >>to do a >> route match based on IP protocol number to distinguish between IP in >>IP, GRE, >> and UDP. In addition, one needs to be able to match on UDP destination >>port >> to distinguish VxLAN from other UDP traffic with the same src/dest >>address. >> Finally one needs to be able to match on VNI in order to be able to >>demultiplex >> the two streams of VxLAN traffic into different rib-name-nexthops. >>=20 >> I don't see that these values (IP protocol number, UDP dest port, or >>VNI) are >> currently included in the route match conditions in the model, so I >>don't see >> how the current data model can be used to configure a router to >>distinguish >> between these traffic types while performing decapsulation. >>=20 >> If the above analysis is correct, then one might consider adding >>additional route >> match conditions to cover these decapsulation cases. However, it may >>also >> make sense to consider other approaches to modeling tunnels. >>=20 >> Thanks, >> Chris >>=20 >> -----Original Message----- >> From: Mach Chen [mailto:mach.chen@huawei.com] >> Sent: Friday, November 13, 2015 3:37 AM >> To: Chris Bowers ; Nitin Bahadur >> ; i2rs@ietf.org >> Subject: RE: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 >>=20 >> Hi Chris, >>=20 >> Thanks for raising the issue and putting it on the I2RS wiki! >>=20 >> The current data model is aligned with the info model. Regarding the >>tunnel >> encap and decap, the info model is defined as is. >>=20 >> Regarding GRE, NvGRE or VxLAN decapsulation, in my understanding, they >>are >> actually IP tunnels, and the current model has already support >>IPv4/IPv6 IP >> tunnel decapsulation. Or maybe I missed something? >>=20 >> Best regards, >> Mach >>=20 >> > From: Chris Bowers [mailto:cbowers@juniper.net] >> > Sent: Thursday, November 12, 2015 11:28 AM >> > To: Nitin Bahadur; i2rs@ietf.org; Mach Chen >> > Subject: RE: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 >> > >> > Nitin and Mach, >> > >> > Thanks for your responses. Jeff Haas suggested to me that we keep >> > track of issues for this on the I2RS wiki at: >> > >> > http://trac.tools.ietf.org/wg/i2rs/trac/wiki/IssuesRibDataModel >> > >> > So far, I posted one issue that I think needs more discussion. I >> > copied it below. Please feel free to edit the Wiki as part of the >>discussion as >> well. >> > Issue 1: Should we define tunnel encapsulation and tunnel >> > decapsulation as next-hops in the RIB data model? >> > The RIB data model can model some types of encapsulation and >> > decapsulation by treating encapsulation and decapsulation as >> > next-hops. For encapsulation, a route is paired with a >> > tunnel-encap-nexthop. For decapsulation, an initial route match >> > condition is paired with a next-hop chain which consists of a >> > tunnel-decap-nexthop and another nexthop such as rib-name-nexthop or >>an >> egress-interface-nexthop. >> > 1) It is not clear if this model for decapsulation supports all useful >> > encapsulation types. For example, it is not clear that the >> > route-match-types currently in >> > draft-ietf-i2rs-rib-data-model-03 can be used to select traffic for >> > GRE, NVGRE, and VXLAN decapsulation. >> > One could consider extending the route-match-types to include the >> > header information needed to identify other encapsulation types. >> > However, this may also be a sign that the basic approach should be >> > re-evaluated. >> > 2) Does treating tunnel-encap and tunnel-decap as next-hops result in >> > a data model that is easy to use for someone trying to program network >> > forwarding behavior? From the point-of-view of a user of the data >> > model, modeling tunnels as interfaces seems more useful. Treating >> > tunnel decapsulation as a type of ingress interface and tunnel >> > encapsulation as a type of egress interface would fit with the current >> > RIB model (which already has the concept of an interface-route and an >> > interface-nexthop.) And it would reduce the amount of next-hop >> > chaining that is required to make tunnels work compared to the current >> model. >> > Thanks, >> > Chris >> > >> > >> > From: Nitin Bahadur [mailto:nitin_bahadur@yahoo.com] >> > Sent: Monday, November 09, 2015 5:53 PM >> > To: Chris Bowers ; i2rs@ietf.org; Mach Chen >> > >> > Subject: Re: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 >> > >> > Hi Chris, >> > >> > Thanks for spending time on the spec. Please see NB> below for >> > some of the issues you have raised. >> > >> > ------------------------ >> > The description of the nexthop-preference-def (see below) is >> > confusing. First, I assume there is an error in the text since the >> > example of downloading primary/standby/tertiary nexthops to the FIB >> > should presumably select three nexthops, but the text refers to >> > selecting the two resolved nexthops with the highest preference . >> > >> > NB> That is a typo IMO. >> > >> > More fundamentally, this example seems to imply that only two >> > next-hops will get downloaded to the FIB, whereas one could imagine >> > an implementation that uses three, four, five or more nexthops of >> > different preferences. If hardware supports more than two next-hop >> > preferences being installed in the FIB, then what is the mechanism for >> > the client to learn how many preference values are supported? This >> > should all be made clearer in the text. >> > >> > typedef nexthop-preference-def { >> > type uint8 { >> > range "1..99"; >> > } >> > description >> > "Nexthop-preference is used for protection schemes. >> > It is an integer value between 1 and 99. A lower >> > value indicates higher preference. To download a >> > primary/standby/tertiary group to the FIB, the >> > nexthops that are resolved and have two highest >> > preferences are selected."; >> > } >> > >> > NB> Would something like this be preferable >> > "To download N nexthops to the FIB, the N nexthops with the lowest >> > value are selected". >> > >> > >> > ------------------------ >> > If I understand the yang syntax and semantics correctly, the "nh-add" >> > RPC creates a nexthop in a given RIB that is not associated with any >> > match condition on a route. I assume the intention is to create a >> > nexthop with a nexthop-id but not associated with any prefix that can >> > then be referenced by multiple other route match conditions. This >> > seems like a reasonable thing to do. However, I can see two possible >>issues >> with this. >> > >> > The first issue is that the structure of the data model doesn't seem >> > to not allow this. "grouping route" uses "grouping route-prefix" >> > next to "container next-hop". It appears to me that as currently >> > written "container match" in "grouping route-prefix" is a mandatory >> > node based on section 3.1 of RFC6020 , since the "mandatory" >> > statements below choice/cases cascade up to the container. So the >> > current form of the "nh-add" RPC may not be consistent with the data >>model >> as currently defined. >> > >> > The second issue is that creating a next-hop without an associated >> > match appears to differ from the RIB grammar defined in section 6 of >> > draft-ietf-i2rs-rib-info-model-08. In the RIB info model, it seems >> > that the only way for a to appear is together with a >>. >> > >> > ::=3D >> > [] >> > [] >> > >> > >> > NB> I'm not sure if I agree with the creation of nexthop discrepancy. >> > NB> A nexthop >> > can be created independently and then in the , you can >> > reference the relevant nexthop-id. >> > >> > ::=3D >> > =3D >> > =3D >> > >> > >> > ------------------------ >> > Treating tunnel-decap as a type of next-hop doesn't make sense to me. >> > I assume the desire to include tunnel-decap as well as tunnel-encap is >> > to have a usable stand-alone data model module which to deal with some >> > use cases without having to rely on another module that defines >> > tunnel-decap. However, the result doesn't make sense. I think the >> > most common scenario involving routers would be to install a route on >> > router A for prefix P whose nexthop is a tunnel-encap whose >> > destination is router B. One router B one would need to install a >> > corresponding tunnel-decap whose source is router A. The most common >> > scenario is then that router B does a normal route lookup on the >> > decapsulated packet independent of the interface it entered on. >> > >> > I don't see how this most common use case would be handled with the >> > tunnel-decap next-hop in this document. >> > >> > NB> On router B, condition would be the incoming label and the >> > "action" to be taken on that would be "decap" the MPLS label. And you >> > can chain that with to say continue the route lookup in say >> "inet.0". >> > The draft says, "RIB_NAME: A nexthop pointing to a RIB indicates that >> > the route >> > lookup needs to continue in the specified RIB." >> > >> > NB> Does that address your concern? >> > >> > >> > Section 7.2.5. of draft-ietf-i2rs-rib-info-model-08 gives an example >> > usage for tunnel-decap where the tunnel-decap nexthop is used to pop >> > an MPLS label and send the traffic out an egress interface next-hop. >> > This example is not the most common scenario. And if we want to >> > accomplish this scenario of decapsulating and sending to a particular >> > nexthop, it makes more sense to treat tunnel-decap as a route match >> > condition similar to an interface-route in the existing data model. >> > However, I think the model should be able to handle the more common >> > scenario described above when traffic needs to be decapsulated and >>routed >> based on a normal route lookup. >> > >> > Treating tunnel-decap as a next-hop type really makes no sense to me. >> > I think this aspect of the model should be changed. >> > >> > NB> See above comment. >> > >> > Thanks >> > Nitin From nobody Mon Nov 16 10:31:18 2015 Return-Path: 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 D11BA1A86FA for ; Mon, 16 Nov 2015 10:31:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 YEGpPIGsP3LM for ; Mon, 16 Nov 2015 10:31:12 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0758.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:758]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA0641A86F7 for ; Mon, 16 Nov 2015 10:31:11 -0800 (PST) Received: from BY2PR05MB614.namprd05.prod.outlook.com (10.141.218.148) by BY2PR05MB613.namprd05.prod.outlook.com (10.141.218.145) with Microsoft SMTP Server (TLS) id 15.1.318.15; Mon, 16 Nov 2015 18:30:51 +0000 Received: from BY2PR05MB614.namprd05.prod.outlook.com ([10.141.218.148]) by BY2PR05MB614.namprd05.prod.outlook.com ([10.141.218.148]) with mapi id 15.01.0318.003; Mon, 16 Nov 2015 18:30:51 +0000 From: Chris Bowers To: Nitin Bahadur , Mach Chen , "i2rs@ietf.org" Thread-Topic: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 Thread-Index: AQHRG1IjVu9gg5MiSU6fmCG9ahcIBp6XN3YAgAJ8vKCAAAAhwIAA2Y5QgANyyICAAPj1AIAAA0ug Date: Mon, 16 Nov 2015 18:30:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=cbowers@juniper.net; x-originating-ip: [66.129.239.14] x-microsoft-exchange-diagnostics: 1; BY2PR05MB613; 5:FQqAkKpmL+Z9knOn161FZLkHWYcJrl93K4vyV5Q4hxFjkYmguJpAojIRIOuFdI18vQV9aefygyCg9B4srhVs13WNxGYvhNdzIv1JnO0dl2+hyc4o8GvzcBtw0LVOShCL47sHQIFVmL5rp4fnOrSWPA==; 24:f6A8BrNp4QACa0XIYwqKy8sQGciFzXabrXOzekPJmdKLNE55cWwYwjmN2x9pG7J2GQTC7PpathCW3cF13KE2rw5U0415LMHTyliNYk+w64M=; 20:sbGcqqrCQ8f/FpzYOAxGGD9werVeGmKjY3u5zz3mdnMw7hzFhddCP4xg33jjpR2rAcO2XWyw/39TMTRdGbGzGw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB613; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(201166117486090)(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046); SRVR:BY2PR05MB613; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB613; x-forefront-prvs: 0762FFD075 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(479174004)(52604005)(52044002)(189002)(164054003)(31014005)(24454002)(13464003)(377454003)(51914003)(93886004)(586003)(5003600100002)(230783001)(76576001)(107886002)(189998001)(5001960100002)(50986999)(54356999)(5001770100001)(11100500001)(74316001)(76176999)(40100003)(33656002)(122556002)(86362001)(101416001)(5008740100001)(15975445007)(87936001)(2521001)(1720100001)(5004730100002)(81156007)(19580395003)(10400500002)(77096005)(97736004)(2900100001)(5007970100001)(19580405001)(2501003)(102836002)(66066001)(99286002)(106116001)(105586002)(2950100001)(106356001)(92566002)(5002640100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB613; H:BY2PR05MB614.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2015 18:30:51.2223 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB613 Archived-At: Subject: Re: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 18:31:17 -0000 Nitin and Mach, I think we are in agreement that VXLAN decapsulation should NOT be included= in the rib-data-model. I think we disagree about whether or not we should include VXLAN _encapsula= tion_ (which is currently included in the draft) as part of the rib data mo= del. To be clear, I do not think that either VXLAN encapsulation or decap= sulation should be part of the rib data model. =20 I find it odd that the current data model provides the ability to configure= encap, but not decap, for VXLAN. This would require the user of the data = model to configure VXLAN tunnel-encap using one data model and vxlan-decap= using another data model. I think this is perhaps an indication that VXL= AN encap does not belong in the RIB data model either. Thanks, Chris -----Original Message----- From: Nitin Bahadur [mailto:nitin_bahadur@yahoo.com]=20 Sent: Monday, November 16, 2015 11:57 AM To: Mach Chen ; Chris Bowers ; i= 2rs@ietf.org Subject: Re: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 Chris, I agree with Mach=B9s comment. To actually decap VxLan and do something = intelligently, one needs something like a firewall rule. There is no routin= g protocol that provides rules on decap of VxLan packets. So the RIB in gen= eral does not contain this information in today=B9s routers (AFAIK). IMO, the content for this should go into http://tools.ietf.org/id/draft-kin= i-i2rs-fb-rib-info-model-02.txt Thanks Nitin On 11/15/15, 7:05 PM, "Mach Chen" wrote: >Hi Chris, > >Much thanks for the detailed explanation! > >In my understanding, the I2RS intends to leverage the existing RIB=20 >design. Regarding to tunnel decap, normally, the protocol number and=20 >udp port belong to the protocol stack process, they are not parts of the r= ib. >As for the VNI and VSI, since they are new, the implementations may be=20 >different. But they may also not be necessary as part of a route to be=20 >installed in the rib. They can just be decapsulated by the VxLan/NvGRE=20 >protocol stack process and used as an identifier to find the next rib=20 >(e.g., the MAC rib), and then perform another rib lookup. If I am=20 >wrong, please correct me. > >Regarding to the suggestion to change tunnel-decap to tunnel-interface,=20 >this will require not only to modify the current data model, but to=20 >modify the info model that has already passed the WG last call. I hope=20 >to hear the opinions of the WG. > >Best regards, >Mach > >> -----Original Message----- >> From: Chris Bowers [mailto:cbowers@juniper.net] >> Sent: Sunday, November 15, 2015 12:38 AM >> To: Mach Chen; Nitin Bahadur; i2rs@ietf.org >> Subject: RE: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 >>=20 >> Mach, >>=20 >> I may be overlooking something, but I don't see how one can use the=20 >>elements in the current data model to configure a router to=20 >>decapsulate GRE, NVGRE or VxLAN in the following scenario. >>=20 >> Assume we have 4 types of tunneled traffic arriving at the router=20 >>with the same source and destination IP address. The decapsulated=20 >>packets need to be processed by 4 different rib-name-nexthops=20 >>depending on information in the encapsulation header. In this=20 >>example, the four different tunneled traffic types are IP-in-IP, IP=20 >>in GRE, and VxLAN encapsulated traffic with two different VNIs, so=20 >>the different packet headers look like this (only the relevant fields=20 >>are >> shown): >>=20 >> 1) ip src=3D1.1.1.1, ip dest=3D2.2.2.2,protocol number=3D4 , inner IP=20 >>packet >> 2) ip src=3D1.1.1.1, ip dest=3D2.2.2.2,protocol number=3D47, inner IP=20 >>packet >> 3) ip src=3D1.1.1.1, ip dest=3D2.2.2.2,protocol number=3D17, udp dest po= rt=3D=20 >>4789, VNI=3D920, inner Ethernet frame >> 4) ip src=3D1.1.1.1, ip dest=3D2.2.2.2,protocol number=3D17, udp dest po= rt=3D=20 >>4789, VNI=3D921, inner Ethernet frame >>=20 >> There are a few ways that one might think about accomplishing=20 >>decapsulation of these packets into different rib-name-nexthops using=20 >>the next-hop chaining in the data model. However, regardless of the=20 >>particular choice of how to chain next-hops and route matches, at=20 >>some point one needs to be able to do a route match based on IP=20 >>protocol number to distinguish between IP in IP, GRE, and UDP. In=20 >>addition, one needs to be able to match on UDP destination port to=20 >>distinguish VxLAN from other UDP traffic with the same src/dest=20 >>address. >> Finally one needs to be able to match on VNI in order to be able to=20 >>demultiplex the two streams of VxLAN traffic into different=20 >>rib-name-nexthops. >>=20 >> I don't see that these values (IP protocol number, UDP dest port, or >>VNI) are >> currently included in the route match conditions in the model, so I=20 >>don't see how the current data model can be used to configure a=20 >>router to distinguish between these traffic types while performing=20 >>decapsulation. >>=20 >> If the above analysis is correct, then one might consider adding=20 >>additional route match conditions to cover these decapsulation cases. =20 >>However, it may also make sense to consider other approaches to=20 >>modeling tunnels. >>=20 >> Thanks, >> Chris >>=20 >> -----Original Message----- >> From: Mach Chen [mailto:mach.chen@huawei.com] >> Sent: Friday, November 13, 2015 3:37 AM >> To: Chris Bowers ; Nitin Bahadur=20 >> ; i2rs@ietf.org >> Subject: RE: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 >>=20 >> Hi Chris, >>=20 >> Thanks for raising the issue and putting it on the I2RS wiki! >>=20 >> The current data model is aligned with the info model. Regarding the=20 >>tunnel encap and decap, the info model is defined as is. >>=20 >> Regarding GRE, NvGRE or VxLAN decapsulation, in my understanding,=20 >>they are actually IP tunnels, and the current model has already=20 >>support >>IPv4/IPv6 IP >> tunnel decapsulation. Or maybe I missed something? >>=20 >> Best regards, >> Mach >>=20 >> > From: Chris Bowers [mailto:cbowers@juniper.net] >> > Sent: Thursday, November 12, 2015 11:28 AM >> > To: Nitin Bahadur; i2rs@ietf.org; Mach Chen >> > Subject: RE: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 >> > >> > Nitin and Mach, >> > >> > Thanks for your responses. Jeff Haas suggested to me that we keep=20 >> > track of issues for this on the I2RS wiki at: >> > >> > http://trac.tools.ietf.org/wg/i2rs/trac/wiki/IssuesRibDataModel >> > >> > So far, I posted one issue that I think needs more discussion. I=20 >> > copied it below. Please feel free to edit the Wiki as part of the >>discussion as >> well. >> > Issue 1: Should we define tunnel encapsulation and tunnel=20 >> > decapsulation as next-hops in the RIB data model? >> > The RIB data model can model some types of encapsulation and=20 >> > decapsulation by treating encapsulation and decapsulation as=20 >> > next-hops. For encapsulation, a route is paired with a=20 >> > tunnel-encap-nexthop. For decapsulation, an initial route match=20 >> > condition is paired with a next-hop chain which consists of a=20 >> > tunnel-decap-nexthop and another nexthop such as rib-name-nexthop=20 >> > or >>an >> egress-interface-nexthop. >> > 1) It is not clear if this model for decapsulation supports all=20 >> > useful encapsulation types. For example, it is not clear that the=20 >> > route-match-types currently in >> > draft-ietf-i2rs-rib-data-model-03 can be used to select traffic for=20 >> > GRE, NVGRE, and VXLAN decapsulation. >> > One could consider extending the route-match-types to include the=20 >> > header information needed to identify other encapsulation types. >> > However, this may also be a sign that the basic approach should be=20 >> > re-evaluated. >> > 2) Does treating tunnel-encap and tunnel-decap as next-hops result=20 >> > in a data model that is easy to use for someone trying to program=20 >> > network forwarding behavior? From the point-of-view of a user of=20 >> > the data model, modeling tunnels as interfaces seems more useful.=20 >> > Treating tunnel decapsulation as a type of ingress interface and=20 >> > tunnel encapsulation as a type of egress interface would fit with=20 >> > the current RIB model (which already has the concept of an=20 >> > interface-route and an >> > interface-nexthop.) And it would reduce the amount of next-hop=20 >> > chaining that is required to make tunnels work compared to the=20 >> > current >> model. >> > Thanks, >> > Chris >> > >> > >> > From: Nitin Bahadur [mailto:nitin_bahadur@yahoo.com] >> > Sent: Monday, November 09, 2015 5:53 PM >> > To: Chris Bowers ; i2rs@ietf.org; Mach Chen=20 >> > >> > Subject: Re: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 >> > >> > Hi Chris, >> > >> > Thanks for spending time on the spec. Please see NB> below=20 >> > for some of the issues you have raised. >> > >> > ------------------------ >> > The description of the nexthop-preference-def (see below) is=20 >> > confusing. First, I assume there is an error in the text since the=20 >> > example of downloading primary/standby/tertiary nexthops to the FIB=20 >> > should presumably select three nexthops, but the text refers to=20 >> > selecting the two resolved nexthops with the highest preference . >> > >> > NB> That is a typo IMO. >> > >> > More fundamentally, this example seems to imply that only two=20 >> > next-hops will get downloaded to the FIB, whereas one could=20 >> > imagine an implementation that uses three, four, five or more=20 >> > nexthops of different preferences. If hardware supports more than=20 >> > two next-hop preferences being installed in the FIB, then what is=20 >> > the mechanism for the client to learn how many preference values=20 >> > are supported? This should all be made clearer in the text. >> > >> > typedef nexthop-preference-def { >> > type uint8 { >> > range "1..99"; >> > } >> > description >> > "Nexthop-preference is used for protection schemes. >> > It is an integer value between 1 and 99. A lower >> > value indicates higher preference. To download a >> > primary/standby/tertiary group to the FIB, the >> > nexthops that are resolved and have two highest >> > preferences are selected."; >> > } >> > >> > NB> Would something like this be preferable >> > "To download N nexthops to the FIB, the N nexthops with the lowest=20 >> > value are selected". >> > >> > >> > ------------------------ >> > If I understand the yang syntax and semantics correctly, the "nh-add" >> > RPC creates a nexthop in a given RIB that is not associated with=20 >> > any match condition on a route. I assume the intention is to=20 >> > create a nexthop with a nexthop-id but not associated with any prefix = that can >> > then be referenced by multiple other route match conditions. This >> > seems like a reasonable thing to do. However, I can see two=20 >> > possible >>issues >> with this. >> > >> > The first issue is that the structure of the data model doesn't seem >> > to not allow this. "grouping route" uses "grouping route-prefix" >> > next to "container next-hop". It appears to me that as currently=20 >> > written "container match" in "grouping route-prefix" is a=20 >> > mandatory node based on section 3.1 of RFC6020 , since the "mandatory" >> > statements below choice/cases cascade up to the container. So the >> > current form of the "nh-add" RPC may not be consistent with the=20 >> > data >>model >> as currently defined. >> > >> > The second issue is that creating a next-hop without an associated=20 >> > match appears to differ from the RIB grammar defined in section 6=20 >> > of draft-ietf-i2rs-rib-info-model-08. In the RIB info model, it=20 >> > seems that the only way for a to appear is together with=20 >> > a >>. >> > >> > ::=3D >> > [] >> > [] >> > >> > >> > NB> I'm not sure if I agree with the creation of nexthop discrepancy. >> > NB> A nexthop >> > can be created independently and then in the , you can=20 >> > reference the relevant nexthop-id. >> > >> > ::=3D >> > =3D >> > =3D >> > >> > >> > ------------------------ >> > Treating tunnel-decap as a type of next-hop doesn't make sense to me. >> > I assume the desire to include tunnel-decap as well as tunnel-encap=20 >> > is to have a usable stand-alone data model module which to deal=20 >> > with some use cases without having to rely on another module that=20 >> > defines tunnel-decap. However, the result doesn't make sense. I=20 >> > think the most common scenario involving routers would be to=20 >> > install a route on router A for prefix P whose nexthop is a tunnel-enc= ap whose >> > destination is router B. One router B one would need to install a >> > corresponding tunnel-decap whose source is router A. The most=20 >> > common scenario is then that router B does a normal route lookup on=20 >> > the decapsulated packet independent of the interface it entered on. >> > >> > I don't see how this most common use case would be handled with the=20 >> > tunnel-decap next-hop in this document. >> > >> > NB> On router B, condition would be the incoming label and=20 >> > NB> the >> > "action" to be taken on that would be "decap" the MPLS label. And=20 >> > you can chain that with to say continue the route lookup=20 >> > in say >> "inet.0". >> > The draft says, "RIB_NAME: A nexthop pointing to a RIB indicates=20 >> > that the route >> > lookup needs to continue in the specified RIB." >> > >> > NB> Does that address your concern? >> > >> > >> > Section 7.2.5. of draft-ietf-i2rs-rib-info-model-08 gives an=20 >> > example usage for tunnel-decap where the tunnel-decap nexthop is=20 >> > used to pop an MPLS label and send the traffic out an egress interface= next-hop. >> > This example is not the most common scenario. And if we want to=20 >> > accomplish this scenario of decapsulating and sending to a=20 >> > particular nexthop, it makes more sense to treat tunnel-decap as a=20 >> > route match condition similar to an interface-route in the existing da= ta model. >> > However, I think the model should be able to handle the more common=20 >> > scenario described above when traffic needs to be decapsulated and >>routed >> based on a normal route lookup. >> > >> > Treating tunnel-decap as a next-hop type really makes no sense to me. >> > I think this aspect of the model should be changed. >> > >> > NB> See above comment. >> > >> > Thanks >> > Nitin From nobody Mon Nov 16 11:55:21 2015 Return-Path: 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 EE0881A8902 for ; Mon, 16 Nov 2015 11:55:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.238 X-Spam-Level: X-Spam-Status: No, score=-2.238 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MALFORMED_FREEMAIL=1.047, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham 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 YW0u7uGWmwRU for ; Mon, 16 Nov 2015 11:55:18 -0800 (PST) Received: from nm16.bullet.mail.gq1.yahoo.com (nm16.bullet.mail.gq1.yahoo.com [98.137.176.58]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BE2B1A88FF for ; Mon, 16 Nov 2015 11:55:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1447703710; bh=+8ajdepVb2f1Ur5zbr6u1oaWr5QEUSRC5+Ivf2yRYEg=; h=Date:Subject:From:To:References:In-Reply-To:From:Subject; b=liMa2/mVXI08zyFwZb/qSuHJLPrjOuTDr4XrpCVYknDSxiXznTRAwtM646SfiiLhW2RVvEWxkSmCwQaOrodRjLIw1tUCG3LUa+w8mroPmIlgdz6JFOpX2H0m6gVCUwfC+6ttd5zJsf1sk0MZ4FRyPI5wyJNzPJcr54L6iSzEE+3WI/UzkdlBswW5TLf1T/SIAgzwgs0hNfkafQF3/LP5Bv8FHeelz6Wj6bwJEvSda+/1cS19iuWCv5D3/5WWB5j+SwZ8xEZDJ2H2hQNGZvqIbV+vbMBPPo2Gl8ewzTju2PtuxWZ/MQFCbMLlgaqWvo+tJoe54N3pQ31PjBMIGPHNVw== Received: from [98.137.12.62] by nm16.bullet.mail.gq1.yahoo.com with NNFMP; 16 Nov 2015 19:55:10 -0000 Received: from [98.136.164.75] by tm7.bullet.mail.gq1.yahoo.com with NNFMP; 16 Nov 2015 19:55:10 -0000 Received: from [127.0.0.1] by smtp237.mail.gq1.yahoo.com with NNFMP; 16 Nov 2015 19:55:10 -0000 X-Yahoo-Newman-Id: 845370.51633.bm@smtp237.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: WHXqVh4VM1k.xQvyw2CVabhkyAWWXhNA5CAdGkNkdTkV5sN _1eSxgrgJWdVWlsh2uRXYpEe3jAXI7DumX9FHbaFH6cUAQXP6ULcWnwQ3WHi ke9cIcwGezFPSHHMsW6a5y1dNJogZJcX2QwJ7UaGu.vo2cVYvkbdgdz6TGw9 or1_3BP2OMvL5ymxYUn32aquqGvHBvjV1aShh0bc3MQMxGQKsmRkFMHAUtD3 KZM5CYHccQYL1tTSN4.cxBT7b.H57.G3yJmUtQSrALZkV2fA_Em3sg5682XR QOT98lFv8vuhDAUqNq6OjVkX_RRLfvoIrvuMX6n2cMHInaoc0exgEtk3XLjQ RFfphyhxBvpKjyoLSzPlD1gJ27RdoQYa2SY2WUKA0r5tsJr5XY.P81Cuz18F 2dhHaGXriH39VN32CGF5bn8w6kFN02jf5z_POENtwdY_cvcb5QIc_h63fasm hWoqTPdRxLm1vpPET5dyd_yiu4.mPjrQRWjPASaLmWkTHDKxPVT064mKeFVd KkyBDaEa9qnoc5Znf9HXc7gLFENllUy8sYMtYVTI- X-Yahoo-SMTP: jU6Na92swBBdqSRkLOL9Cp_LhHZgQAQoL10- User-Agent: Microsoft-MacOutlook/14.4.4.140807 Date: Mon, 16 Nov 2015 11:55:05 -0800 From: Nitin Bahadur To: Chris Bowers , Mach Chen , "i2rs@ietf.org" Message-ID: Thread-Topic: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 19:55:20 -0000 >I find it odd that the current data model provides the ability to >configure encap, but not decap, for VXLAN. This would require the user >of the data model to configure VXLAN tunnel-encap using one data model >and vxlan-decap using another data model. I think this is perhaps an >indication that VXLAN encap does not belong in the RIB data model either. I=B9ll buy that argument. And I believe we can extend that argument to GRE & NVGRE as well. Anyone on the list have comments related to this? Thanks Nitin From nobody Mon Nov 16 12:17:53 2015 Return-Path: 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 5C5871B30F0 for ; Mon, 16 Nov 2015 12:17:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.086 X-Spam-Level: X-Spam-Status: No, score=-15.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 klyajy7EVIO4 for ; Mon, 16 Nov 2015 12:17:51 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBE421B30F5 for ; Mon, 16 Nov 2015 12:17:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1348; q=dns/txt; s=iport; t=1447705070; x=1448914670; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=/KrW4xVcvrVGw8MuDNBX8Biq2O6i1eGgnoJ7gR+FKR4=; b=kMEN/j1cpqIqPCvfZCSfSeZSk/7mA6YR4o0VrvBtDjBxrfJBQ1WE2JLJ 44OB1c/pAEahIVLT8+SOWaW5/LGRr/QtCihLusUoKTAcjQ/7MzjNipUiy YpuILEjHFqsBhyoC/a1owm1IQ7Iglez6vi7c0YvvQ8DtYmIY/FonztIY2 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAgCjOEpW/49dJa1dgztTbwavCY9RA?= =?us-ascii?q?Q2BZRcKhW8CHIErOBQBAQEBAQEBgQqENQEBBAEBATE6GwIBCBwoAgIlCxMSAgQ?= =?us-ascii?q?BEogZAxINjTSdLQaQKQEBAQEBAQEBAQEBAQEBAQEBAQEBFQR7ileCU4UcgUoBB?= =?us-ascii?q?IYLDJAxAYs3gW+UcodSAR8BAUKEBHKEA4EHAQEB?= X-IronPort-AV: E=Sophos;i="5.20,304,1444694400"; d="scan'208";a="51099420" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Nov 2015 20:17:49 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id tAGKHnWC017760 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 16 Nov 2015 20:17:49 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 16 Nov 2015 14:17:47 -0600 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1104.000; Mon, 16 Nov 2015 14:17:47 -0600 From: "Manish Kumar (manishkr)" To: Nitin Bahadur , Chris Bowers , Mach Chen , "i2rs@ietf.org" Thread-Topic: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 Thread-Index: AQHRG1IjbUKB4wbpWkONHUipG28+956XN3YAgAJ8vKCAAAAhwIABhIyAgAK/DUCAAWZHAIAACZWAgAAXiICAAGKEgA== Date: Mon, 16 Nov 2015 20:17:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.2.150604 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.40.38] Content-Type: text/plain; charset="euc-kr" Content-ID: <3D7CE1C19E758645BAB7434133DD79CE@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 20:17:52 -0000 RW5jYXAvRGVjYXAgYmVsb25nIHRvIGEgZGlmZmVyZW50IGxheWVyIChhY3R1YWxseSBvbmUgdGhh dCB0aWVzIHR3byBsYXllcnMNCnRvZ2V0aGVyKSBhbmQgUklCIGRvZXNuoa90IGxvb2sgdGhlIHJp Z2h0IHBsYWNlIGZvciBlbmNhcC9kZWNhcCB0byBtZS4NCg0KVGhhbmtzLA0KTWFuaXNoDQoNCk9u IDE3LzExLzE1IDE6MjUgYW0sICJpMnJzIG9uIGJlaGFsZiBvZiBOaXRpbiBCYWhhZHVyIg0KPGky cnMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Ygbml0aW5fYmFoYWR1ckB5YWhvby5jb20+ IHdyb3RlOg0KDQo+DQo+DQo+PkkgZmluZCBpdCBvZGQgdGhhdCB0aGUgY3VycmVudCBkYXRhIG1v ZGVsIHByb3ZpZGVzIHRoZSBhYmlsaXR5IHRvDQo+PmNvbmZpZ3VyZSBlbmNhcCwgYnV0IG5vdCBk ZWNhcCwgZm9yIFZYTEFOLiAgVGhpcyB3b3VsZCByZXF1aXJlIHRoZSB1c2VyDQo+Pm9mIHRoZSBk YXRhIG1vZGVsIHRvIGNvbmZpZ3VyZSBWWExBTiB0dW5uZWwtZW5jYXAgIHVzaW5nIG9uZSBkYXRh IG1vZGVsDQo+PmFuZCB2eGxhbi1kZWNhcCB1c2luZyBhbm90aGVyIGRhdGEgbW9kZWwuICAgSSB0 aGluayB0aGlzIGlzIHBlcmhhcHMgYW4NCj4+aW5kaWNhdGlvbiB0aGF0IFZYTEFOIGVuY2FwIGRv ZXMgbm90IGJlbG9uZyBpbiB0aGUgUklCIGRhdGEgbW9kZWwgZWl0aGVyLg0KPg0KPkmp9mxsIGJ1 eSB0aGF0IGFyZ3VtZW50LiBBbmQgSSBiZWxpZXZlIHdlIGNhbiBleHRlbmQgdGhhdCBhcmd1bWVu dCB0byBHUkUgJg0KPk5WR1JFIGFzIHdlbGwuDQo+DQo+QW55b25lIG9uIHRoZSBsaXN0IGhhdmUg Y29tbWVudHMgcmVsYXRlZCB0byB0aGlzPw0KPg0KPlRoYW5rcw0KPk5pdGluDQo+DQo+DQo+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5pMnJzIG1haWxp bmcgbGlzdA0KPmkycnNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2kycnMNCg0K From nobody Mon Nov 16 12:58:33 2015 Return-Path: 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 66AF01B3177 for ; Mon, 16 Nov 2015 12:58:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.786 X-Spam-Level: X-Spam-Status: No, score=-4.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham 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 MLzrbwLUYI7N for ; Mon, 16 Nov 2015 12:58:28 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F16E1B3174 for ; Mon, 16 Nov 2015 12:58:28 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CEE65301; Mon, 16 Nov 2015 20:58:25 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 16 Nov 2015 20:58:25 +0000 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0235.001; Mon, 16 Nov 2015 12:58:08 -0800 From: Linda Dunbar To: "Manish Kumar (manishkr)" , Nitin Bahadur , Chris Bowers , Mach Chen , "i2rs@ietf.org" Thread-Topic: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 Thread-Index: AQHRG1IjVu9gg5MiSU6fmCG9ahcIBp6XN3YAgAJ8vKCAAAAhwIAA2Y5QgARr7ZKAAI+BgIAAF4mAgAAGV4D//4MlsA== Date: Mon, 16 Nov 2015 20:58:08 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657D9C7D7@dfweml701-chm> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.213] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.564A4372.002A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 7ddf2dc19dc4d994e48e9543f6bd9ad0 Archived-At: Subject: Re: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 20:58:31 -0000 +1,=20 IMHO, Encap/Decap should be part of Tunnel.=20 Linda=20 -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Manish Kumar (manish= kr) Sent: Monday, November 16, 2015 2:18 PM To: Nitin Bahadur; Chris Bowers; Mach Chen; i2rs@ietf.org Subject: Re: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 Encap/Decap belong to a different layer (actually one that ties two layers together) and RIB doesn't look the right place for encap/decap to me. Thanks, Manish On 17/11/15 1:25 am, "i2rs on behalf of Nitin Bahadur" wrote: > > >>I find it odd that the current data model provides the ability to=20 >>configure encap, but not decap, for VXLAN. This would require the=20 >>user of the data model to configure VXLAN tunnel-encap using one data mo= del >>and vxlan-decap using another data model. I think this is perhaps an >>indication that VXLAN encap does not belong in the RIB data model either. > >I=B9ll buy that argument. And I believe we can extend that argument to=20 >GRE & NVGRE as well. > >Anyone on the list have comments related to this? > >Thanks >Nitin > > >_______________________________________________ >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 From nobody Mon Nov 16 13:16:31 2015 Return-Path: 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 474181B319F for ; Mon, 16 Nov 2015 13:16:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.537 X-Spam-Level: X-Spam-Status: No, score=-1.537 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MALFORMED_FREEMAIL=1.047, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.585, SPF_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 M4yIGsYJYoHC for ; Mon, 16 Nov 2015 13:16:22 -0800 (PST) Received: from nm1.bullet.mail.gq1.yahoo.com (nm1.bullet.mail.gq1.yahoo.com [98.136.218.75]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F46D1B319B for ; Mon, 16 Nov 2015 13:16:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1447708581; bh=Bcd38Oz2pQtJH4mL3nK0BVNvysEcwsvWb4oiV1Txe9Y=; h=Date:Subject:From:To:References:In-Reply-To:From:Subject; b=MIopR6AtH3D64vGl0FrMP2mYIosE9r2tX1UXZ23Eh2TOfMbh9LKkgH9gstRD/CeVE4B2NmLmP0JYPn8j1djeXBDjorpPx4v9T41HUAfJXg1SMEEIMyK1oCW0aG4ck2n4jICWxfqw3/jJEYSLL5Wovqu8PQvGAy0kJZm8vDvFH7i+r7Qs+pyN1Y/0AUijDtFuuPhP+HIANzG8YiemnxYI4WSdzvCIThDa9Wa+6/Obj+XapdTO+1pppLSgyBL/4dqPzTJnGX52sQPXoYwUGuI158eWfFgb4twBIawA5Ssyqoa1H0UgxekbMjwyQkHzzD2W85SsJTJ424QxHoOkK+akJw== Received: from [98.137.12.58] by nm1.bullet.mail.gq1.yahoo.com with NNFMP; 16 Nov 2015 21:16:21 -0000 Received: from [208.71.42.191] by tm3.bullet.mail.gq1.yahoo.com with NNFMP; 16 Nov 2015 21:16:21 -0000 Received: from [127.0.0.1] by smtp202.mail.gq1.yahoo.com with NNFMP; 16 Nov 2015 21:16:21 -0000 X-Yahoo-Newman-Id: 698809.57325.bm@smtp202.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: jzlUC.QVM1lJR7VFHCWnB7UzOAbYNK4PALo6MaJCq8cLCMP G3AdcohI003qNH_4HZkXxA5d3OTD5XV2wS1XD0sGkNtF9gTJ3KSZIseYcWmr mvhKhy2MS.XeWtS0ffqn9GLcVcwutyBmy6bdC6YhDkqr2YkYj4nieUCfBO2l UpsKctrvrOqwtzgfjL9.gS7VdVdwFy.wTgkNWIGVaQJz4udIjcgYvp05Phbm .zFz9IiHJOJpycju7gWo6F4tvi7smGq1rt2QH_.rj.Hc63ytbop0KebAAER. x717ZxTlJomodr9A.Xp5tIYavxTSz_Id8cNrE2YlZB2X7.FrVWUWvSM7lIRr sb1U6TRNRe6YiksFDTluzXmcvcrqMq4D1qKIGJysFWrfuf55cpuHsjgtYnzJ _Z0zntFxEr_kX5Or7COsFYSU71uYQ727s5WU_LaR25revs.NOqL12UXlRXpR XD6AO_V0biQZnTldOaU612mXBYU9TVNcwMdDPlqFC8AWlXNxkTIabLjD0.1e 0GI1Bao67nVmaVFIqhgvT3xCpDnVjrYFNT4PD1tg- X-Yahoo-SMTP: jU6Na92swBBdqSRkLOL9Cp_LhHZgQAQoL10- User-Agent: Microsoft-MacOutlook/14.4.4.140807 Date: Mon, 16 Nov 2015 13:16:16 -0800 From: Nitin Bahadur To: "Manish Kumar (manishkr)" , Chris Bowers , Mach Chen , "i2rs@ietf.org" Message-ID: Thread-Topic: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="EUC-KR" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 21:16:23 -0000 We need a minimal tunnel encap for MPLS=A1=A6so that mpls labels can be pushed and popped. So I do want to keep basic (aka mpls) tunnel encap/decap in this draft. This will also enable development of solutions based on Segment routing (or whatever it=A1=AFs called these days). Nitin On 11/16/15, 12:17 PM, "Manish Kumar (manishkr)" wrote: >Encap/Decap belong to a different layer (actually one that ties two layers >together) and RIB doesn=A1=AFt look the right place for encap/decap to me. > >Thanks, >Manish > >On 17/11/15 1:25 am, "i2rs on behalf of Nitin Bahadur" > wrote: > >> >> >>>I find it odd that the current data model provides the ability to >>>configure encap, but not decap, for VXLAN. This would require the user >>>of the data model to configure VXLAN tunnel-encap using one data model >>>and vxlan-decap using another data model. I think this is perhaps an >>>indication that VXLAN encap does not belong in the RIB data model >>>either. >> >>I=A9=F6ll buy that argument. And I believe we can extend that argument to GRE >>& >>NVGRE as well. >> >>Anyone on the list have comments related to this? >> >>Thanks >>Nitin >> >> >>_______________________________________________ >>i2rs mailing list >>i2rs@ietf.org >>https://www.ietf.org/mailman/listinfo/i2rs > From nobody Mon Nov 16 14:00:29 2015 Return-Path: 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 8793A1B3211 for ; Mon, 16 Nov 2015 14:00:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, SPF_HELO_PASS=-0.001, SPF_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 KAQo6a0_lCdz for ; Mon, 16 Nov 2015 14:00:23 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0707.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::707]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 112B21B3205 for ; Mon, 16 Nov 2015 14:00:22 -0800 (PST) Received: from BLUPR0501MB1715.namprd05.prod.outlook.com (10.163.120.18) by DM2PR05MB622.namprd05.prod.outlook.com (10.141.157.20) with Microsoft SMTP Server (TLS) id 15.1.325.17; Mon, 16 Nov 2015 22:00:02 +0000 Received: from BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) by BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) with mapi id 15.01.0325.003; Mon, 16 Nov 2015 22:00:01 +0000 From: "Jeffrey (Zhaohui) Zhang" To: Nitin Bahadur , "Manish Kumar (manishkr)" , Chris Bowers , Mach Chen , "i2rs@ietf.org" Thread-Topic: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 Thread-Index: AQHRG1Ij4Wr2VRW/F023u5nVFobmR56XN3YAgAJ8vKCAAAAhwIACCqiAgAJBroCAAPj1AIAACZSAgAAXiYCAAAZYgIAAEFcAgAALgDA= Date: Mon, 16 Nov 2015 22:00:01 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=zzhang@juniper.net; x-originating-ip: [66.129.241.13] x-microsoft-exchange-diagnostics: 1; DM2PR05MB622; 5:BaD4UJETSUkwcHsrqrUDrDdBSocpfirSrxoktBWXIlXY6xybFHjav9cVp3/gdpYFT3amqNnGXtEEouJAzK4nIIwOo16LHafAnU5ap4Wm1+wutuo2vsOBxabGB87//5FC5glzbz1e1ULZO+aUOJfXfw==; 24:BgJv0MvQZnRuErVRWqzvHENJ9A2/kX/E5AX1X9JVLWI62i21tJztqTQJ47VWbwh860gUYgixhVcpDkC2bMbpPLv0fjgmaC44yYSq1H3OzZI=; 20:3gEKQOVxpoEn66S1rf1GZvatvilpUDPSqyq+s5SjujGHCSWh0ELouM+ATq82PZFUSDLRr6eIcjIdEZI3ftcT/Q== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB622; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(201166117486090)(138986009662008)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:DM2PR05MB622; BCL:0; PCL:0; RULEID:; SRVR:DM2PR05MB622; x-forefront-prvs: 0762FFD075 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(377454003)(24454002)(479174004)(13464003)(199003)(189002)(164054003)(5004730100002)(1941001)(5007970100001)(76576001)(101416001)(5001960100002)(40100003)(2950100001)(19580405001)(99286002)(50986999)(10400500002)(189998001)(5002640100001)(87936001)(86362001)(5008740100001)(105586002)(230783001)(5001770100001)(19580395003)(33656002)(106356001)(93886004)(66066001)(54356999)(2501003)(2900100001)(81156007)(586003)(77096005)(15975445007)(92566002)(74316001)(102836002)(5003600100002)(2521001)(97736004)(107886002)(106116001)(5001920100001)(122556002)(76176999)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB622; H:BLUPR0501MB1715.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2015 22:00:01.7662 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR05MB622 Archived-At: Subject: Re: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 22:00:27 -0000 Current RIB has ieee-mac RIB, which could use vxlan encap nexthops. BTW, mpls encap/decap is needed even for non-segmenting scenarios - plain o= ld l3vpn, vpls, or evpn with mpls data plane. Jeffrey > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Nitin Bahadur > Sent: Monday, November 16, 2015 4:16 PM > To: Manish Kumar (manishkr) ; Chris Bowers > ; Mach Chen ; i2rs@ietf.org > Subject: Re: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 >=20 >=20 > We need a minimal tunnel encap for MPLS.so that mpls labels can be pushed > and popped. So I do want to keep basic (aka mpls) tunnel encap/decap in > this draft. This will also enable development of solutions based on > Segment routing (or whatever it's called these days). >=20 > Nitin >=20 > On 11/16/15, 12:17 PM, "Manish Kumar (manishkr)" > wrote: >=20 > >Encap/Decap belong to a different layer (actually one that ties two > layers > >together) and RIB doesn't look the right place for encap/decap to me. > > > >Thanks, > >Manish > > > >On 17/11/15 1:25 am, "i2rs on behalf of Nitin Bahadur" > > wrote: > > > >> > >> > >>>I find it odd that the current data model provides the ability to > >>>configure encap, but not decap, for VXLAN. This would require the use= r > >>>of the data model to configure VXLAN tunnel-encap using one data mode= l > >>>and vxlan-decap using another data model. I think this is perhaps an > >>>indication that VXLAN encap does not belong in the RIB data model > >>>either. > >> > >>I=B9ll buy that argument. And I believe we can extend that argument to = GRE > >>& > >>NVGRE as well. > >> > >>Anyone on the list have comments related to this? > >> > >>Thanks > >>Nitin > >> > >> > >>_______________________________________________ > >>i2rs mailing list > >>i2rs@ietf.org > >>https://www.ietf.org/mailman/listinfo/i2rs > > >=20 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Wed Nov 18 00:37:45 2015 Return-Path: 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 6669B1B2A17 for ; Wed, 18 Nov 2015 00:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.186 X-Spam-Level: X-Spam-Status: No, score=-4.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham 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 wXkI24C27_CV for ; Wed, 18 Nov 2015 00:37:42 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FD291B2A12 for ; Wed, 18 Nov 2015 00:37:41 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CAM54392; Wed, 18 Nov 2015 08:37:38 +0000 (GMT) Received: from SZXEMA414-HUB.china.huawei.com (10.82.72.73) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 18 Nov 2015 08:37:37 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.73]) by SZXEMA414-HUB.china.huawei.com ([10.82.72.73]) with mapi id 14.03.0235.001; Wed, 18 Nov 2015 16:36:35 +0800 From: Mach Chen To: "Jeffrey (Zhaohui) Zhang" , Nitin Bahadur , "Manish Kumar (manishkr)" , Chris Bowers , "i2rs@ietf.org" Thread-Topic: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 Thread-Index: AQHRG1IjbUKB4wbpWkONHUipG28+956XN3YAgAJ8vKCAAAAhwIABhIyAgAK/DUCAAHuWAIAACZSAgAAXiYCAAAZYgIAAEFcAgAAMOYCAAsinsA== Date: Wed, 18 Nov 2015 08:36:34 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.135] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.564C38D3.000E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.73, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: bb7990b17777f4c6b66d4d4919cb884e Archived-At: Subject: Re: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 08:37:44 -0000 Indeed, I agree with Jeffery here. I'd suggest we keep the current model as is and address the vxlan/nvgre dec= ap in other places.=20 Best regards, Mach > -----Original Message----- > From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] > Sent: Tuesday, November 17, 2015 6:00 AM > To: Nitin Bahadur; Manish Kumar (manishkr); Chris Bowers; Mach Chen; > i2rs@ietf.org > Subject: RE: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 >=20 > Current RIB has ieee-mac RIB, which could use vxlan encap nexthops. >=20 > BTW, mpls encap/decap is needed even for non-segmenting scenarios - plain > old l3vpn, vpls, or evpn with mpls data plane. >=20 > Jeffrey >=20 > > -----Original Message----- > > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Nitin Bahadur > > Sent: Monday, November 16, 2015 4:16 PM > > To: Manish Kumar (manishkr) ; Chris Bowers > > ; Mach Chen ; > i2rs@ietf.org > > Subject: Re: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 > > > > > > We need a minimal tunnel encap for MPLS.so that mpls labels can be > > pushed and popped. So I do want to keep basic (aka mpls) tunnel > > encap/decap in this draft. This will also enable development of > > solutions based on Segment routing (or whatever it's called these days)= . > > > > Nitin > > > > On 11/16/15, 12:17 PM, "Manish Kumar (manishkr)" > > wrote: > > > > >Encap/Decap belong to a different layer (actually one that ties two > > layers > > >together) and RIB doesn't look the right place for encap/decap to me. > > > > > >Thanks, > > >Manish > > > > > >On 17/11/15 1:25 am, "i2rs on behalf of Nitin Bahadur" > > > wrote: > > > > > >> > > >> > > >>>I find it odd that the current data model provides the ability to > > >>>configure encap, but not decap, for VXLAN. This would require the > > >>>user of the data model to configure VXLAN tunnel-encap using one da= ta > model > > >>>and vxlan-decap using another data model. I think this is perhaps = an > > >>>indication that VXLAN encap does not belong in the RIB data model > > >>>either. > > >> > > >>I=B9ll buy that argument. And I believe we can extend that argument t= o > > >>GRE & NVGRE as well. > > >> > > >>Anyone on the list have comments related to this? > > >> > > >>Thanks > > >>Nitin > > >> > > >> > > >>_______________________________________________ > > >>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 From nobody Thu Nov 19 12:34:31 2015 Return-Path: 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 754A01B3514 for ; Thu, 19 Nov 2015 12:34:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.953 X-Spam-Level: X-Spam-Status: No, score=-0.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RP_MATCHES_RCVD=-0.585, SPF_HELO_PASS=-0.001, SPF_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 Y_Wq2xGkjdSb for ; Thu, 19 Nov 2015 12:34:29 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 910E21B3513 for ; Thu, 19 Nov 2015 12:34:29 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id A74D91E1D2; Thu, 19 Nov 2015 15:35:09 -0500 (EST) Date: Thu, 19 Nov 2015 15:35:09 -0500 From: Jeffrey Haas To: Russ White <7riw77@gmail.com> Message-ID: <20151119203509.GA22415@pfrc.org> References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> <563A97AA.5020308@joelhalpern.com> <00f301d11761$61699130$243cb390$@gmail.com> <563AA59C.4060809@joelhalpern.com> <018101d11764$66b82e50$34288af0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <018101d11764$66b82e50$34288af0$@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: i2rs@ietf.org, "'Joel M. Halpern'" , 'Andy Bierman' , 'Susan Hares' Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 20:34:30 -0000 [Catching up on list traffic after being sick for a bit.] On Wed, Nov 04, 2015 at 07:53:28PM -0500, Russ White wrote: > First -- in terms of granularity -- I don't think anyone should be modifying > parts of a RIB entry. Rather, each "object" should be treated as an "object" > in full. This is something that needs to be addressed in the models -- what > is essential, and what is accidental. I think we chatted briefly about this. While I think we agree in principle that this is a desired behavior, the methods to implement this are what is leading to the discordance: - If we have a yang schema representing a RIB, nothing in netconf/restconf prohibits one party with sufficient permissions from tampering with a subset of nodes associated with a given RIB entry. The issue is fundamentally we're allowing different parties to scribble on top of pieces of configuration. This is a configuration based mechanism. - If we only interact with the RIB via something like a RPC call defined in yang, then the properties of not interfering with another entry can be enforced by the implementation of that RPC. This is more of an API based mechanism. The logic implementing the RPC provides the enforcement. An API based mechanism addresses the issue, but the question basically comes down to how to expose the remainder of the associated state for the RIB in such an implementation. Do we expose operational state? If so, we can have a config=false representation of that state. How do we expose the provisioned state? Do we require the user to issue a series of RPCs to get the state? It would be very convenient if it were present as a config=true set of nodes, but this is the problem we're avoiding. What we'd end up with is potentially something similar to what the OpenConfig group wants: state that is provisioned, but distinct from the operational state of the system. In this example, it'd be effectively a second piece of operational state. I'm thinking more and more that a significant portion of our problem spaces come down to some form of the above discussion. I2RS priority is rather painful to create and enforce when your interface to provision it is config=true nodes in an ephemeral datastore. It's a bit clearer when it is provisioned via RPC instead. -- Jeff From nobody Thu Nov 19 23:13:17 2015 Return-Path: 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 34C121ACE70 for ; Thu, 19 Nov 2015 23:13:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.986 X-Spam-Level: X-Spam-Status: No, score=-1.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham 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 RayHsoCLcmxZ for ; Thu, 19 Nov 2015 23:13:11 -0800 (PST) Received: from smtpjc.telefonica.com (smtpjc.telefonica.com [81.47.204.76]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA85F1ACE5B for ; Thu, 19 Nov 2015 23:13:10 -0800 (PST) Received: from smtpjc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5AF411B8323; Fri, 20 Nov 2015 08:13:07 +0100 (CET) Received: from ESTGVMSP101.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtpjc.telefonica.com (Postfix) with ESMTPS id 3F8FD1B815D; Fri, 20 Nov 2015 08:13:07 +0100 (CET) Received: from emea01-am1-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.92.6.49) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 20 Nov 2015 08:13:06 +0100 Received: from DB4PR06MB0639.eurprd06.prod.outlook.com (10.161.13.145) by DB4PR06MB0639.eurprd06.prod.outlook.com (10.161.13.145) with Microsoft SMTP Server (TLS) id 15.1.331.20; Fri, 20 Nov 2015 07:13:05 +0000 Received: from DB4PR06MB0639.eurprd06.prod.outlook.com ([10.161.13.145]) by DB4PR06MB0639.eurprd06.prod.outlook.com ([10.161.13.145]) with mapi id 15.01.0331.019; Fri, 20 Nov 2015 07:13:05 +0000 From: PEDRO ANDRES ARANDA GUTIERREZ To: Jeffrey Haas , Russ White <7riw77@gmail.com> Thread-Topic: [i2rs] Conversation on Priority and Panes Thread-Index: AQHRIwm/+3O1h73j5ke4p1jGIHLAp56kkHqA Date: Fri, 20 Nov 2015 07:13:04 +0000 Message-ID: <5B54713B-CDE6-4F65-BE79-91F5B9FF3850@telefonica.com> References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> <563A97AA.5020308@joelhalpern.com> <00f301d11761$61699130$243cb390$@gmail.com> <563AA59C.4060809@joelhalpern.com> <018101d11764$66b82e50$34288af0$@gmail.com> <20151119203509.GA22415@pfrc.org> In-Reply-To: <20151119203509.GA22415@pfrc.org> Accept-Language: es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151105 authentication-results: spf=none (sender IP is ) smtp.mailfrom=pedroa.aranda@telefonica.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [195.235.92.36] x-microsoft-exchange-diagnostics: 1; DB4PR06MB0639; 5:K0P4CxtNZ8pHdL78tBmyg19BCS1Wy1crodlTp2WTFVZU28jwzzdsww3I4OYe8/0qffmyAXU+fzwtLSAPsAOfs1VWm9KquSuPhT4zaLLpf1WzozWCOxZ0WZNW9mR1VzdI/mBZt7qTVu6LKfXgA0lFMA==; 24:vJmOFtTIqq4Xd7E8AeCG0soHIy6CPUW4bAZKq3iiGoMjmnYdB46cpId24arfiRcLtDZkkWUR8iW2FQ8R+hCCt4s77klxKDVjVIYrdRbelmI= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB0639; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:DB4PR06MB0639; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0639; x-forefront-prvs: 07665BE9D1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(86362001)(575784001)(87936001)(83506001)(82746002)(83716003)(106116001)(105586002)(106356001)(19580395003)(5004730100002)(5002640100001)(54356999)(5007970100001)(101416001)(33656002)(50986999)(19580405001)(76176999)(2950100001)(2900100001)(5008740100001)(11100500001)(15975445007)(66066001)(40100003)(77096005)(36756003)(586003)(189998001)(5001770100001)(122556002)(5001960100002)(4001350100001)(81156007)(92566002)(10400500002)(102836003)(3846002)(5001920100001)(6116002)(97736004)(93886004)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB0639; H:DB4PR06MB0639.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <686CC450245B2F498ECD23F2AE9C6E11@eurprd06.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2015 07:13:04.5645 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB0639 X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: Cc: "i2rs@ietf.org" , "'Joel M. Halpern'" , 'Andy Bierman' , 'Susan Hares' Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 07:13:15 -0000 SEkgbGlzdCwNCg0KSeKAmW0gd29ya2luZyBvbiBhIHByb2plY3Qgd2VyZSB3ZSBhcmUgYWxzbyB0 YWtpbmcgb24gdGhpcyBwcm9ibGVtIHNwYWNlLiBBbHRob3VnaCB3ZSBhcmUgY3VycmVudGx5IE9w ZW5GbG93IGJhc2VkLCB3ZSBhcmUgdHJ5aW5nIHRvIGdlbmVyYWxpc2Ugb3VyIG1lY2hhbmlzbXMu IFdlIGhvcGUgd2UgbWF5IGJlIGFibGUgdG8gY29udHJpYnV0ZSBpbiB0aGlzIGRpc2N1c3Npb24u DQoNCkJlc3QsIC9QQQ0KDQpQUzogYW5zd2VycyBpbmxpbmUNCi0tLQ0KRHIuIFBlZHJvIEEuIEFy YW5kYSBHdXRpw6lycmV6DQoNClRlY2hub2xvZ3kgRXhwbG9yYXRpb24gLQ0KTmV0d29yayBJbm5v dmF0aW9uICYgVmlydHVhbGlzYXRpb24NCmVtYWlsOiBwZWRyb2EgZDB0IGFyYW5kYSBBdCB0ZWxl Zm9uaWNhIGQwdCBjb20NClRlbGVmw7NuaWNhLCBJbnZlc3RpZ2FjacOzbiB5IERlc2Fycm9sbG8N CkMvIFp1cmJhcsOhbiwxMg0KMjgwMTAgTWFkcmlkLCBTcGFpbg0KDQpGcmFnZW4gc2luZCBuaWNo dCBkYSwgdW0gYmVhbnR3b3J0ZXQgenUgd2VyZGVuLg0KRnJhZ2VuIHNpbmQgZGEsIHVtIGdlc3Rl bGx0IHp1IHdlcmRlbi4NCkdlb3JnIEtyZWlzbGVyDQoNCg0KDQoNCg0KPkFuIEFQSSBiYXNlZCBt ZWNoYW5pc20gYWRkcmVzc2VzIHRoZSBpc3N1ZSwgYnV0IHRoZSBxdWVzdGlvbiBiYXNpY2FsbHkg Y29tZXMNCj5kb3duIHRvIGhvdyB0byBleHBvc2UgdGhlIHJlbWFpbmRlciBvZiB0aGUgYXNzb2Np YXRlZCBzdGF0ZSBmb3IgdGhlIFJJQiBpbg0KPnN1Y2ggYW4gaW1wbGVtZW50YXRpb24uICBEbyB3 ZSBleHBvc2Ugb3BlcmF0aW9uYWwgc3RhdGU/ICBJZiBzbywgd2UgY2FuIGhhdmUNCj5hIGNvbmZp Zz1mYWxzZSByZXByZXNlbnRhdGlvbiBvZiB0aGF0IHN0YXRlLg0KDQpZb3UgZWl0aGVyIGV4cG9z ZSB0aGUgc3RhdGUgb3IgeW91IHJlcXVpcmUgdGhlIGRpZmZlcmVudCBhcHBzIHRvIG1haW50YWlu IGEgY29weSBvZiB0aGUgc3RhdGUsIHdoaWNoIGlzIHNvcnQgb2YNCkEpIGRhbmdlcm91cywgYmVj YXVzZSBhbiBhcHAgY291bGQgYmUgYnVpbGRpbmcgYSBjb3JydXB0ZWQvYmlhc2VkIHZpZXcgb2Yg dGhlIHN0YXRlIGlmIHRoZXkgY2Fubm90IOKAnHNwb29mIiB0aGUgY29uZmlndXJhdGlvbiB0cmFm ZmljIGZyb20gb3RoZXIgYXBwcyBhbmQgdGhlbiBzdGFydCBjcmVhdGluZyBoYXZvYw0KQikgdGVk aW91cywgYmVjYXVzZSB3ZSBuZWVkIGFsbCBhcHBzIHRvIHJlcGxpY2F0ZSB0aGUgc3RhdGUNCg0K PkhvdyBkbyB3ZSBleHBvc2UgdGhlIHByb3Zpc2lvbmVkIHN0YXRlPyAgRG8gd2UgcmVxdWlyZSB0 aGUgdXNlciB0byBpc3N1ZSBhDQo+c2VyaWVzIG9mIFJQQ3MgdG8gZ2V0IHRoZSBzdGF0ZT8gIEl0 IHdvdWxkIGJlIHZlcnkgY29udmVuaWVudCBpZiBpdCB3ZXJlDQo+cHJlc2VudCBhcyBhIGNvbmZp Zz10cnVlIHNldCBvZiBub2RlcywgYnV0IHRoaXMgaXMgdGhlIHByb2JsZW0gd2UncmUNCj5hdm9p ZGluZy4gIFdoYXQgd2UnZCBlbmQgdXAgd2l0aCBpcyBwb3RlbnRpYWxseSBzb21ldGhpbmcgc2lt aWxhciB0byB3aGF0DQo+dGhlIE9wZW5Db25maWcgZ3JvdXAgd2FudHM6IHN0YXRlIHRoYXQgaXMg cHJvdmlzaW9uZWQsIGJ1dCBkaXN0aW5jdCBmcm9tIHRoZQ0KPm9wZXJhdGlvbmFsIHN0YXRlIG9m IHRoZSBzeXN0ZW0uICBJbiB0aGlzIGV4YW1wbGUsIGl0J2QgYmUgZWZmZWN0aXZlbHkgYQ0KPnNl Y29uZCBwaWVjZSBvZiBvcGVyYXRpb25hbCBzdGF0ZS4NCg0KSSBzZWUgdGhlIGJlbmVmaXRzIG9m IHRoYXQgYXBwcm9hY2guIEhvd2V2ZXIgdGhlcmUgaXMgYSBkcmF3YmFjayB0aGVyZSBhbmQgdGhh dCBpcyB0aGUgcmVzcG9uc2l2ZW5lc3MgYW5kIGhvdyB0byBjb250cm9sIHJhY2UgY29uZGl0aW9u cyB0aGVyZToNCg0KQVBQMTogZ2V0cyAoYW5kIGxvY2tzKSB0aGUgc3RhdGUsIGNhbGN1bGF0ZXMg dGhlIG5ldyBzdGF0ZSBhbmQgdGhlbiB3cml0ZXMgKGFuZCB1bmxvY2tzKSB0aGUgc3RhdGUNCkFQ UDI6IHNlZXMgdGhlIHN0YXRlIGlzIGxvY2tlZCBhbmQgd2FpdHMgdW50aWwgaXQgaXMgdW5sb2Nr ZWQgdG8gZ2V0IGFuZCBsb2NrIGl0IHRvIGRvIGl0cyBvcGVyYXRpb25zDQoNClRoYXQNCkEpIG1h eSBzbG93IGRvd24gYXBwcyBhIGxvdC4gKER1bm5vIGlmIHRoYXQgY2FuIGJlIGV2ZW4gZGVzaXJh YmxlIHRvIGF2b2lkIG9zY2lsbGF0aW9uKQ0KQikgcmluZ3Mgc29tZSBiZWxscyBpbiB0aGUgYmFj ayBvZiBteSBtaW5kIHJlZ2FyZGluZyBkZWFkbG9ja3MgSSBzdHVkaWVkIChsb25nIGFnbykgYXQg dGhlIHVuaXZlcnNpdHkgOi0pIGxpa2Ugd2hhdCBoYXBwZW5zIGlmIEFQUDEgYW5kIEFQUDIgYWNj ZXNzIHRoZSBzdGF0ZSBhdCB0aGUgc2FtZSB0aW1lLCBldGMuDQoNCj4NCj5JJ20gdGhpbmtpbmcg bW9yZSBhbmQgbW9yZSB0aGF0IGEgc2lnbmlmaWNhbnQgcG9ydGlvbiBvZiBvdXIgcHJvYmxlbSBz cGFjZXMNCj5jb21lIGRvd24gdG8gc29tZSBmb3JtIG9mIHRoZSBhYm92ZSBkaXNjdXNzaW9uLiAg STJSUyBwcmlvcml0eSBpcyByYXRoZXINCj5wYWluZnVsIHRvIGNyZWF0ZSBhbmQgZW5mb3JjZSB3 aGVuIHlvdXIgaW50ZXJmYWNlIHRvIHByb3Zpc2lvbiBpdCBpcw0KPmNvbmZpZz10cnVlIG5vZGVz IGluIGFuIGVwaGVtZXJhbCBkYXRhc3RvcmUuICBJdCdzIGEgYml0IGNsZWFyZXIgd2hlbiBpdCBp cw0KPnByb3Zpc2lvbmVkIHZpYSBSUEMgaW5zdGVhZC4NCj4NCj4tLSBKZWZmDQo+DQo+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5pMnJzIG1haWxpbmcg bGlzdA0KPmkycnNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2kycnMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRXN0ZSBtZW5z YWplIHkgc3VzIGFkanVudG9zIHNlIGRpcmlnZW4gZXhjbHVzaXZhbWVudGUgYSBzdSBkZXN0aW5h dGFyaW8sIHB1ZWRlIGNvbnRlbmVyIGluZm9ybWFjacOzbiBwcml2aWxlZ2lhZGEgbyBjb25maWRl bmNpYWwgeSBlcyBwYXJhIHVzbyBleGNsdXNpdm8gZGUgbGEgcGVyc29uYSBvIGVudGlkYWQgZGUg ZGVzdGluby4gU2kgbm8gZXMgdXN0ZWQuIGVsIGRlc3RpbmF0YXJpbyBpbmRpY2FkbywgcXVlZGEg bm90aWZpY2FkbyBkZSBxdWUgbGEgbGVjdHVyYSwgdXRpbGl6YWNpw7NuLCBkaXZ1bGdhY2nDs24g eS9vIGNvcGlhIHNpbiBhdXRvcml6YWNpw7NuIHB1ZWRlIGVzdGFyIHByb2hpYmlkYSBlbiB2aXJ0 dWQgZGUgbGEgbGVnaXNsYWNpw7NuIHZpZ2VudGUuIFNpIGhhIHJlY2liaWRvIGVzdGUgbWVuc2Fq ZSBwb3IgZXJyb3IsIGxlIHJvZ2Ftb3MgcXVlIG5vcyBsbyBjb211bmlxdWUgaW5tZWRpYXRhbWVu dGUgcG9yIGVzdGEgbWlzbWEgdsOtYSB5IHByb2NlZGEgYSBzdSBkZXN0cnVjY2nDs24uDQoNClRo ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyB0cmFuc21pc3Npb24gaXMgcHJpdmlsZWdl ZCBhbmQgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGludGVuZGVkIG9ubHkgZm9yIHRoZSB1c2Ug b2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IG5hbWVkIGFib3ZlLiBJZiB0aGUgcmVhZGVyIG9m IHRoaXMgbWVzc2FnZSBpcyBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJl Ynkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uIG9yIGNvcHlp bmcgb2YgdGhpcyBjb21tdW5pY2F0aW9uIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBkbyBub3QgcmVhZCBpdC4g UGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgdGhhdCB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IgYW5kIHRoZW4gZGVsZXRlIGl0Lg0KDQpF c3RhIG1lbnNhZ2VtIGUgc2V1cyBhbmV4b3Mgc2UgZGlyaWdlbSBleGNsdXNpdmFtZW50ZSBhbyBz ZXUgZGVzdGluYXTDoXJpbywgcG9kZSBjb250ZXIgaW5mb3JtYcOnw6NvIHByaXZpbGVnaWFkYSBv dSBjb25maWRlbmNpYWwgZSDDqSBwYXJhIHVzbyBleGNsdXNpdm8gZGEgcGVzc29hIG91IGVudGlk YWRlIGRlIGRlc3Rpbm8uIFNlIG7Do28gw6kgdm9zc2Egc2VuaG9yaWEgbyBkZXN0aW5hdMOhcmlv IGluZGljYWRvLCBmaWNhIG5vdGlmaWNhZG8gZGUgcXVlIGEgbGVpdHVyYSwgdXRpbGl6YcOnw6Nv LCBkaXZ1bGdhw6fDo28gZS9vdSBjw7NwaWEgc2VtIGF1dG9yaXphw6fDo28gcG9kZSBlc3RhciBw cm9pYmlkYSBlbSB2aXJ0dWRlIGRhIGxlZ2lzbGHDp8OjbyB2aWdlbnRlLiBTZSByZWNlYmV1IGVz dGEgbWVuc2FnZW0gcG9yIGVycm8sIHJvZ2Ftb3MtbGhlIHF1ZSBub3MgbyBjb211bmlxdWUgaW1l ZGlhdGFtZW50ZSBwb3IgZXN0YSBtZXNtYSB2aWEgZSBwcm9jZWRhIGEgc3VhIGRlc3RydWnDp8Oj bw0K From nobody Fri Nov 20 04:36:21 2015 Return-Path: <7riw77@gmail.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 05F661B2F82 for ; Fri, 20 Nov 2015 04:36:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.149 X-Spam-Level: X-Spam-Status: No, score=0.149 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_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 lxtFCbgz-AdQ for ; Fri, 20 Nov 2015 04:36:19 -0800 (PST) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (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 6084D1B2F81 for ; Fri, 20 Nov 2015 04:36:19 -0800 (PST) Received: by ykdv3 with SMTP id v3so158833073ykd.0 for ; Fri, 20 Nov 2015 04:36:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=zeA5b7Z9eAD3W/ipqi35J8RmU29JOxW1VTvFv5QQT58=; b=yhH9Turd18d/9o1Jm+7hizmZd5iVOaGdrZB6hZZcX78ZXERv+XB5+YFPGv9reKrbDf sCLkv9C2fIcTuRka8iGLpzYtT5dQzRwMVYbfzDpS88t5BKwXFgpmU5jNM0YoEbRJP7VT 3KkxEtIeZSwnBZEhJZZVop+3lsytgRro2cNAla+gcpYJgZA5S37KAYBSwFQT9fAs/z5K Q2pJ3Pk01jZwug+RdDeVa/8D3JgXzXJSo4CvhUBVZlS9MWCZ+bL86HVjl/rfH9Vby6bZ UldK6IsH6okxCkHQz0xIALYFeUDclcSv1q2RdlOecjOvPWJiCap9Z8AAmrY1ZVwOGsXi ES/w== X-Received: by 10.13.254.133 with SMTP id o127mr12420201ywf.89.1448022978716; Fri, 20 Nov 2015 04:36:18 -0800 (PST) Received: from Russ (108-78-210-25.lightspeed.chrlnc.sbcglobal.net. [108.78.210.25]) by smtp.gmail.com with ESMTPSA id z130sm14043405ywb.18.2015.11.20.04.36.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Nov 2015 04:36:18 -0800 (PST) From: "Russ White" <7riw77@gmail.com> To: "'PEDRO ANDRES ARANDA GUTIERREZ'" , "'Jeffrey Haas'" References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> <563A97AA.5020308@joelhalpern.com> <00f301d11761$61699130$243cb390$@gmail.com> <563AA59C.4060809@joelhalpern.com> <018101d11764$66b82e50$34288af0$@gmail.com> <20151119203509.GA22415@pfrc.org> <5B54713B-CDE6-4F65-BE79-91F5B9FF3850@telefonica.com> In-Reply-To: <5B54713B-CDE6-4F65-BE79-91F5B9FF3850@telefonica.com> Date: Fri, 20 Nov 2015 07:36:04 -0500 Message-ID: <008d01d12390$064987c0$12dc9740$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLwMtmz+XLO8+uQ7j5WaenA2rWXRwHVfCJTAW3ySwACzWyr4AJQYvqoAmia70sCRUpXGQJL52qvAewKHZECaD7TrgHLBOvzm7riXmA= Content-Language: en-us Archived-At: Cc: i2rs@ietf.org, "'Joel M. Halpern'" , 'Andy Bierman' , 'Susan Hares' Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 12:36:21 -0000 > You either expose the state or you require the different apps to = maintain a > copy of the state, which is sort of > A) dangerous, because an app could be building a corrupted/biased view = of > the state if they cannot =E2=80=9Cspoof" the configuration traffic = from other apps and > then start creating havoc > B) tedious, because we need all apps to replicate the state I'm not seeing the planes as being "replicated by various apps," though. = If we take a simple model -- Internal device state -- agent -- client(s) Then the internal device state is the actual running state, the agent is = holding the "planes of glass," and each client is holding its desired = state, the current state (as the feedback loop), and whatever = policies/actions/code it needs to manage. I don't see where client 1 is = going to need a full copy of the "planes of glass" the agent is holding, = so I don't see any complexity for anyone but the agent here -- and that = should be optional. Consider what happens when some internal device state changes that will = (ultimately) trigger some policy on some particular client. There are = two options here --=20 1. The agent informs all the clients who have subscribed to that = particular event, and then takes the incoming commands as they are = processed. 2. The agent has some sort of "cache," or "planes of glass," that allow = it to replace information from an internal store as needed, based on = predetermined factors it has been informed of by the clients. I don't see either of these as invalid or "wrong" -- just different = responses. In fact, we might want one reaction in some cases, and = another in others. There may be some cases where time is of the essence, = and hence having the information needed within the agent to make a = decision locally is important. There may be other cases where it's not = worth the agent locally storing this information; the loop can be a bit = longer. We've already admitted this with the inclusion of "backup = routes" in the RIB model (which is already an unlimited cache of "backup = information" for one particular node in the tree, albeit just for next = hops, which is disturbing in many ways from a routing perspective). The point I think that's being made here is there's no reason not to = generalize the "next hop" situation -- the WG has said, "no, we don't = want to do that," but the nexthop example has already broken that rule, = so I'm not certain that we're even being consistent about our = objections, or being clear in what it is we want to do.=20 IMHO, there's nothing wrong with the agent being _allowed_ to hold such = backup state, or "planes of glass," even if it's for a subset of the = entire model, and letting users and vendors work together to decide what = makes sense and what doesn't in terms of holding this sort of = information locally. I don't see why, as a WG, we should pre-emptively = decide that _only_ the nexthop has this sort of speed requirement, and = forcing everything else to go through the notify/reply loop. What this = is going to lead to, in the long run, I think, is actually more = complexity -- as use cases are put forward to support tighter loops for = something other than the nexthop, we're going to have to put forward = drafts extending the models for each and every case. I don't see how = this is simpler than putting the protocol mechanics in place up front to = support three responses to an attempt to install some piece of state -- 1. Can't do it for reason x 2. Done 3. Stored, but not installed for reason x (same reason codes as above) And the one additional query -- can you please give me all the state you = have stored for this object? If there's any additional complexity, I'd love to hear about it, because = I don't see it right now -- I'm perfectly willing to have my mind = changed. But in terms of complexity tradeoff -- and complexity is always = a tradeoff -- I see a couple of extra things to define now, versus going = through the entire model and somehow building what's already there for = nexthop into anything that someone can present a valid use case for. > APP1: gets (and locks) the state, calculates the new state and then = writes > (and unlocks) the state > APP2: sees the state is locked and waits until it is unlocked to get = and lock it > to do its operations We don't do locks/unlocks -- that's a key point here. This is all = atomic. It's not a database, it's more like a web app with a restful = interface.=20 No locks. Ever.=20 :-) Russ From nobody Fri Nov 20 04:55:13 2015 Return-Path: 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 0C3CE1B2FEE for ; Fri, 20 Nov 2015 04:55:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.186 X-Spam-Level: X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham 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 INbvi6yXEZwX for ; Fri, 20 Nov 2015 04:55:10 -0800 (PST) Received: from smtpjc.telefonica.com (smtpjc.telefonica.com [81.47.204.76]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80E0F1B2FED for ; Fri, 20 Nov 2015 04:55:09 -0800 (PST) Received: from smtpjc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D00452D04EC; Fri, 20 Nov 2015 13:55:06 +0100 (CET) Received: from ESTGVMSP113.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtpjc.telefonica.com (Postfix) with ESMTPS id BEC2A2D0514; Fri, 20 Nov 2015 13:55:06 +0100 (CET) Received: from emea01-db3-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.92.6.55) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 20 Nov 2015 13:55:05 +0100 Received: from DB4PR06MB0639.eurprd06.prod.outlook.com (10.161.13.145) by DB4PR06MB0639.eurprd06.prod.outlook.com (10.161.13.145) with Microsoft SMTP Server (TLS) id 15.1.331.20; Fri, 20 Nov 2015 12:55:00 +0000 Received: from DB4PR06MB0639.eurprd06.prod.outlook.com ([10.161.13.145]) by DB4PR06MB0639.eurprd06.prod.outlook.com ([10.161.13.145]) with mapi id 15.01.0331.019; Fri, 20 Nov 2015 12:55:00 +0000 From: PEDRO ANDRES ARANDA GUTIERREZ To: Russ White <7riw77@gmail.com>, 'Jeffrey Haas' Thread-Topic: [i2rs] Conversation on Priority and Panes Thread-Index: AQHRIwm/+3O1h73j5ke4p1jGIHLAp56kkHqAgABJfACAABYNgA== Date: Fri, 20 Nov 2015 12:55:00 +0000 Message-ID: <99B64F3B-20A1-4D3C-A445-46D235EDB44D@telefonica.com> References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> <563A97AA.5020308@joelhalpern.com> <00f301d11761$61699130$243cb390$@gmail.com> <563AA59C.4060809@joelhalpern.com> <018101d11764$66b82e50$34288af0$@gmail.com> <20151119203509.GA22415@pfrc.org> <5B54713B-CDE6-4F65-BE79-91F5B9FF3850@telefonica.com> <008d01d12390$064987c0$12dc9740$@gmail.com> In-Reply-To: <008d01d12390$064987c0$12dc9740$@gmail.com> Accept-Language: es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151105 authentication-results: spf=none (sender IP is ) smtp.mailfrom=pedroa.aranda@telefonica.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [195.235.92.36] x-microsoft-exchange-diagnostics: 1; DB4PR06MB0639; 5:DYlyJJSM/6yOY4xkTEIYVUDVFYCvGiRPzOg1ZIQu9c5E5fZLFXNyFoWq0onT+H5q3/sG0STO6lvkJ1DpNwNlASI6I2LMx2wi2S/oEKGkAXSZcglv9sKB3/ALVXmJedIKYBdumpXCV3jg8J9AIrserg==; 24:ESairPYbEwBJMbWfeRTZMcG3Wk1d9ieQZjQZPFNnNdT6S5tGXPHtgbMajtW+jAWozcIypZ5o1ADZDM9BRrGMQ4hCfpMKIaUwDgk0alep09g= x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(42139001); SRVR:DB4PR06MB0639; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(40392960112811); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:DB4PR06MB0639; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0639; x-forefront-prvs: 07665BE9D1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(59124004)(199003)(189002)(11100500001)(77096005)(66066001)(2900100001)(2950100001)(5008740100001)(40100003)(10400500002)(4001350100001)(92566002)(81156007)(6116002)(97736004)(93886004)(102836003)(586003)(3846002)(36756003)(5001770100001)(5001960100002)(122556002)(189998001)(83716003)(106356001)(82746002)(106116001)(105586002)(575784001)(86362001)(83506001)(87936001)(76176999)(50986999)(19580405001)(33656002)(5004730100002)(5002640100001)(19580395003)(54356999)(5007970100001)(101416001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB0639; H:DB4PR06MB0639.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <80B8DA956EE60140B6EA0CED76372352@eurprd06.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2015 12:55:00.5707 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB0639 X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: Cc: "i2rs@ietf.org" , "'Joel M. Halpern'" , 'Andy Bierman' , 'Susan Hares' Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 12:55:13 -0000 VGhlIGRhbmdlciBJIHNlZSB0aGVyZSBpcyB0aGF0IGEgc3BlY2lmaWMgcG9saWN5IGFwcGxpZWQg Ynkgb25lIGNsaWVudCAoYXBwKSBtYXkgdHJpZ2dlciB1bmludGVuZGVkIGNoYW5nZXMgaW4gYSBw YXJ0IG9mIHRoZSAicGxhbmVzIG9mIGdsYXNzIiBpdCBpcyBub3QgYXdhcmUgb2YuIEhlbmNlIGEg ZnVsbCBjb3B5IGlzIG5lZWRlZCBpbiBlYWNoIGNsaWVudCAoYXBwKSBtYXkgYmUgbmVlZGVk4oCm IFRoaXMgYWxzbyBob2xkcyBmb3Igc3Vic2NyaWJpbmcgdG8gY2hhbmdlIG5vdGlmaWNhdGlvbnMu IEhvdyBjYW4gSSBzdWJzY3JpYmUgdG8gYSBjaGFuZ2Ugbm90aWZpY2F0aW9uIG9mIHNvbWV0aGlu ZyBJ4oCZbSBub3Qgb3IgSSBkb27igJl0IHdhbnQgdG8gYmUgYXdhcmUgb2Y/DQoNCkJSLC9QQQ0K LS0tDQpEci4gUGVkcm8gQS4gQXJhbmRhIEd1dGnDqXJyZXoNCg0KVGVjaG5vbG9neSBFeHBsb3Jh dGlvbiAtDQpOZXR3b3JrIElubm92YXRpb24gJiBWaXJ0dWFsaXNhdGlvbg0KZW1haWw6IHBlZHJv YSBkMHQgYXJhbmRhIEF0IHRlbGVmb25pY2EgZDB0IGNvbQ0KVGVsZWbDs25pY2EsIEludmVzdGln YWNpw7NuIHkgRGVzYXJyb2xsbw0KQy8gWnVyYmFyw6FuLDEyDQoyODAxMCBNYWRyaWQsIFNwYWlu DQoNCkZyYWdlbiBzaW5kIG5pY2h0IGRhLCB1bSBiZWFudHdvcnRldCB6dSB3ZXJkZW4uDQpGcmFn ZW4gc2luZCBkYSwgdW0gZ2VzdGVsbHQgenUgd2VyZGVuLg0KR2VvcmcgS3JlaXNsZXINCg0KDQoN Cg0KDQoNCg0KDQoNCi0tLS0tTWVuc2FqZSBvcmlnaW5hbC0tLS0tDQpEZTogaTJycyA8aTJycy1i b3VuY2VzQGlldGYub3JnPiBlbiBub21icmUgZGUgUnVzcyBXaGl0ZSA8N3Jpdzc3QGdtYWlsLmNv bT4NCkZlY2hhOiB2aWVybmVzLCAyMCBkZSBub3ZpZW1icmUgZGUgMjAxNSwgMTM6MzYNClBhcmE6 IHBhYWcgPHBlZHJvYS5hcmFuZGFAdGVsZWZvbmljYS5jb20+LCAnSmVmZnJleSBIYWFzJyA8amhh YXNAcGZyYy5vcmc+DQpDQzogImkycnNAaWV0Zi5vcmciIDxpMnJzQGlldGYub3JnPiwgIidKb2Vs IE0uIEhhbHBlcm4nIiA8am1oQGpvZWxoYWxwZXJuLmNvbT4sICdBbmR5IEJpZXJtYW4nIDxhbmR5 QHl1bWF3b3Jrcy5jb20+LCBTdWUgSGFyZXMgPHNoYXJlc0BuZHpoLmNvbT4NCkFzdW50bzogUmU6 IFtpMnJzXSBDb252ZXJzYXRpb24gb24gUHJpb3JpdHkgYW5kIFBhbmVzDQoNCj5JJ20gbm90IHNl ZWluZyB0aGUgcGxhbmVzIGFzIGJlaW5nICJyZXBsaWNhdGVkIGJ5IHZhcmlvdXMgYXBwcywiIHRo b3VnaC4gSWYgd2UgdGFrZSBhIHNpbXBsZSBtb2RlbCAtLQ0KPg0KPkludGVybmFsIGRldmljZSBz dGF0ZSAtLSBhZ2VudCAtLSBjbGllbnQocykNCj4NCj5UaGVuIHRoZSBpbnRlcm5hbCBkZXZpY2Ug c3RhdGUgaXMgdGhlIGFjdHVhbCBydW5uaW5nIHN0YXRlLCB0aGUgYWdlbnQgaXMgaG9sZGluZyB0 aGUgInBsYW5lcyBvZiBnbGFzcywiIGFuZCBlYWNoIGNsaWVudCBpcyBob2xkaW5nIGl0cyBkZXNp cmVkIHN0YXRlLCB0aGUgY3VycmVudCBzdGF0ZSAoYXMgdGhlIGZlZWRiYWNrIGxvb3ApLCBhbmQg d2hhdGV2ZXIgcG9saWNpZXMvYWN0aW9ucy9jb2RlIGl0IG5lZWRzIHRvIG1hbmFnZS4gSSBkb24n dCBzZWUgd2hlcmUgY2xpZW50IDEgaXMgZ29pbmcgdG8gbmVlZCBhIGZ1bGwgY29weSBvZiB0aGUg InBsYW5lcyBvZiBnbGFzcyIgdGhlIGFnZW50IGlzIGhvbGRpbmcsIHNvIEkgZG9uJ3Qgc2VlIGFu eSBjb21wbGV4aXR5IGZvciBhbnlvbmUgYnV0IHRoZSBhZ2VudCBoZXJlIC0tIGFuZCB0aGF0IHNo b3VsZCBiZSBvcHRpb25hbC4NCj4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cg0KRXN0ZSBtZW5zYWplIHkgc3VzIGFkanVudG9zIHNlIGRpcmlnZW4gZXhjbHVzaXZhbWVudGUg YSBzdSBkZXN0aW5hdGFyaW8sIHB1ZWRlIGNvbnRlbmVyIGluZm9ybWFjacOzbiBwcml2aWxlZ2lh ZGEgbyBjb25maWRlbmNpYWwgeSBlcyBwYXJhIHVzbyBleGNsdXNpdm8gZGUgbGEgcGVyc29uYSBv IGVudGlkYWQgZGUgZGVzdGluby4gU2kgbm8gZXMgdXN0ZWQuIGVsIGRlc3RpbmF0YXJpbyBpbmRp Y2FkbywgcXVlZGEgbm90aWZpY2FkbyBkZSBxdWUgbGEgbGVjdHVyYSwgdXRpbGl6YWNpw7NuLCBk aXZ1bGdhY2nDs24geS9vIGNvcGlhIHNpbiBhdXRvcml6YWNpw7NuIHB1ZWRlIGVzdGFyIHByb2hp YmlkYSBlbiB2aXJ0dWQgZGUgbGEgbGVnaXNsYWNpw7NuIHZpZ2VudGUuIFNpIGhhIHJlY2liaWRv IGVzdGUgbWVuc2FqZSBwb3IgZXJyb3IsIGxlIHJvZ2Ftb3MgcXVlIG5vcyBsbyBjb211bmlxdWUg aW5tZWRpYXRhbWVudGUgcG9yIGVzdGEgbWlzbWEgdsOtYSB5IHByb2NlZGEgYSBzdSBkZXN0cnVj Y2nDs24uDQoNClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyB0cmFuc21pc3Npb24g aXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGludGVuZGVkIG9ubHkg Zm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IG5hbWVkIGFib3ZlLiBJZiB0 aGUgcmVhZGVyIG9mIHRoaXMgbWVzc2FnZSBpcyBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwg eW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0 aW9uIG9yIGNvcHlpbmcgb2YgdGhpcyBjb21tdW5pY2F0aW9uIGlzIHN0cmljdGx5IHByb2hpYml0 ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBkbyBu b3QgcmVhZCBpdC4gUGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgdGhhdCB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IgYW5kIHRoZW4gZGVs ZXRlIGl0Lg0KDQpFc3RhIG1lbnNhZ2VtIGUgc2V1cyBhbmV4b3Mgc2UgZGlyaWdlbSBleGNsdXNp dmFtZW50ZSBhbyBzZXUgZGVzdGluYXTDoXJpbywgcG9kZSBjb250ZXIgaW5mb3JtYcOnw6NvIHBy aXZpbGVnaWFkYSBvdSBjb25maWRlbmNpYWwgZSDDqSBwYXJhIHVzbyBleGNsdXNpdm8gZGEgcGVz c29hIG91IGVudGlkYWRlIGRlIGRlc3Rpbm8uIFNlIG7Do28gw6kgdm9zc2Egc2VuaG9yaWEgbyBk ZXN0aW5hdMOhcmlvIGluZGljYWRvLCBmaWNhIG5vdGlmaWNhZG8gZGUgcXVlIGEgbGVpdHVyYSwg dXRpbGl6YcOnw6NvLCBkaXZ1bGdhw6fDo28gZS9vdSBjw7NwaWEgc2VtIGF1dG9yaXphw6fDo28g cG9kZSBlc3RhciBwcm9pYmlkYSBlbSB2aXJ0dWRlIGRhIGxlZ2lzbGHDp8OjbyB2aWdlbnRlLiBT ZSByZWNlYmV1IGVzdGEgbWVuc2FnZW0gcG9yIGVycm8sIHJvZ2Ftb3MtbGhlIHF1ZSBub3MgbyBj b211bmlxdWUgaW1lZGlhdGFtZW50ZSBwb3IgZXN0YSBtZXNtYSB2aWEgZSBwcm9jZWRhIGEgc3Vh IGRlc3RydWnDp8Ojbw0K From nobody Fri Nov 20 05:11:26 2015 Return-Path: <7riw77@gmail.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 B50D01A1B46 for ; Fri, 20 Nov 2015 05:11:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.149 X-Spam-Level: X-Spam-Status: No, score=0.149 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_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 9UqZtpDNi1cc for ; Fri, 20 Nov 2015 05:11:23 -0800 (PST) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (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 73E711A017C for ; Fri, 20 Nov 2015 05:11:23 -0800 (PST) Received: by ykfs79 with SMTP id s79so161334149ykf.1 for ; Fri, 20 Nov 2015 05:11:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=JuDMhRiKDyfQcOnhzJ6NXOSuAGLRh8583WdiAbtvBRo=; b=DMXNWkzlNs5NLoncoWwRaaaohrZpuLJWfemvIOFXa5vCS5nRga8ROVCZ7CWCMqPIi3 8+iG6I/QXcs9V7i5LgQiznDVCG1lyykFgYoUO0HnxTECDeLt3v0AoppQXR8DiPKrLAmD Y33BZfHLT8Fpgek1YcGvpF1VhqhlNGq/oriWy5Q52Vf2Ow/1wSB1HMELTllsG2iEKLAV yikSY9kr+yQt/w3iAuT59HHzJxXPQbG2QwYUPf7dGAx7auJ0C+NtBXuQ/tQ1neDG6g3A ZoJnc26mQ4ysp/s9M/RmojWt+xUGRe7HsBMoolNvG+zwoLwxFvcfclu6TAmGCoEMIMV9 JDzQ== X-Received: by 10.129.155.196 with SMTP id s187mr5333869ywg.24.1448025082824; Fri, 20 Nov 2015 05:11:22 -0800 (PST) Received: from Russ (108-78-210-25.lightspeed.chrlnc.sbcglobal.net. [108.78.210.25]) by smtp.gmail.com with ESMTPSA id e66sm14206908ywd.33.2015.11.20.05.11.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Nov 2015 05:11:22 -0800 (PST) From: "Russ White" <7riw77@gmail.com> To: "'PEDRO ANDRES ARANDA GUTIERREZ'" , "'Jeffrey Haas'" References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> <563A97AA.5020308@joelhalpern.com> <00f301d11761$61699130$243cb390$@gmail.com> <563AA59C.4060809@joelhalpern.com> <018101d11764$66b82e50$34288af0$@gmail.com> <20151119203509.GA22415@pfrc.org> <5B54713B-CDE6-4F65-BE79-91F5B9FF3850@telefonica.com> <008d01d12390$064987c0$12dc9740$@gmail.com> <99B64F3B-20A1-4D3C-A445-46D235EDB44D@telefonica.com> In-Reply-To: <99B64F3B-20A1-4D3C-A445-46D235EDB44D@telefonica.com> Date: Fri, 20 Nov 2015 08:11:08 -0500 Message-ID: <014a01d12394$ec5ffa60$c51fef20$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLwMtmz+XLO8+uQ7j5WaenA2rWXRwHVfCJTAW3ySwACzWyr4AJQYvqoAmia70sCRUpXGQJL52qvAewKHZECaD7TrgHLBOvzApMDTUsCqh6d65uRBQTw Content-Language: en-us Archived-At: Cc: i2rs@ietf.org, "'Joel M. Halpern'" , 'Andy Bierman' , 'Susan Hares' Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 13:11:24 -0000 > The danger I see there is that a specific policy applied by one client = (app) may > trigger unintended changes in a part of the "planes of glass" it is = not aware > of. Hence a full copy is needed in each client (app) may be = needed=E2=80=A6 This also > holds for subscribing to change notifications. How can I subscribe to = a change > notification of something I=E2=80=99m not or I don=E2=80=99t want to = be aware of? I don't see how that's going to be any different whether the alternate = states are held in the agent or on the clients -- either way, doing "x" = might trigger some other client to do "y." The only difference is how = long it takes for the first client to see the second client doing "y," = and then reacting to it by doing "z." Even trying to make certain every = client has a full list of all possible conditions there will still be = race conditions in the mix, so that won't solve the problem, either. At = some point, you're going to hit your head against CAP -- it's just a = matter of where, when, and how to manage it.=20 The only real solution to this sort of problem is to have a definitive = single "metric" that provides an answer to every situation. Just like = with a routing protocol, you can't build a distributed system that uses = more than one metric without ending up with wedgies (hence BGP). Mike = Shand once told me this is an np(complete) problem -- I'm guessing Mike = is right on this one. It seems, to me, that this is precisely what the = "priority" in this system provides -- in any case, the client with the = best priority wins. As no two clients can have the same priority (it's = tied to the client id, from what I remember), it "just works." The one situation you can get in to is when client 1 says "do x," client = 2 says, "do y," and you end up with a routing loop or contradictory = policies applied. This is going to be a problem no matter where the = information is stored. I don't think we can address this at the protocol = level -- all the protocol can do is be as accurate about current state = as it's installed as possible. The agent should be able to detect some = situations like this and refuse to install the offending state. The = clients may be able to detect some of this, as well, and fix things. But = I don't see how we could specify such a thing in the protocol. Or = rather, if we do, when we'd ever be able to stop specifying such = things...=20 :-) Russ From nobody Sun Nov 22 23:04:50 2015 Return-Path: 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 BF1AE1B3159 for ; Sun, 22 Nov 2015 23:04:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.186 X-Spam-Level: X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham 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 l9mXJIqKWnrM for ; Sun, 22 Nov 2015 23:04:46 -0800 (PST) Received: from smtptc.telefonica.com (smtptc.telefonica.com [195.76.34.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F4E31A1B1B for ; Sun, 22 Nov 2015 23:04:45 -0800 (PST) Received: from smtptc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8B8CD601AC; Mon, 23 Nov 2015 08:04:28 +0100 (CET) Received: from ESTGVMSP110.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtptc.telefonica.com (Postfix) with ESMTPS id 6DFB76018E; Mon, 23 Nov 2015 08:04:28 +0100 (CET) Received: from emea01-db3-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.93.6.53) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 23 Nov 2015 08:04:27 +0100 Received: from DB4PR06MB0639.eurprd06.prod.outlook.com (10.161.13.145) by DB4PR06MB0638.eurprd06.prod.outlook.com (10.161.13.144) with Microsoft SMTP Server (TLS) id 15.1.331.20; Mon, 23 Nov 2015 07:04:26 +0000 Received: from DB4PR06MB0639.eurprd06.prod.outlook.com ([10.161.13.145]) by DB4PR06MB0639.eurprd06.prod.outlook.com ([10.161.13.145]) with mapi id 15.01.0331.019; Mon, 23 Nov 2015 07:04:26 +0000 From: PEDRO ANDRES ARANDA GUTIERREZ To: Russ White <7riw77@gmail.com>, 'Jeffrey Haas' Thread-Topic: [i2rs] Conversation on Priority and Panes Thread-Index: AQHRIwm/+3O1h73j5ke4p1jGIHLAp56kkHqAgABJfACAABYNgP//88AAgARhSwA= Date: Mon, 23 Nov 2015 07:04:26 +0000 Message-ID: <87361DB1-DC6F-4023-A807-4003B436B472@telefonica.com> References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> <563A97AA.5020308@joelhalpern.com> <00f301d11761$61699130$243cb390$@gmail.com> <563AA59C.4060809@joelhalpern.com> <018101d11764$66b82e50$34288af0$@gmail.com> <20151119203509.GA22415@pfrc.org> <5B54713B-CDE6-4F65-BE79-91F5B9FF3850@telefonica.com> <008d01d12390$064987c0$12dc9740$@gmail.com> <99B64F3B-20A1-4D3C-A445-46D235EDB44D@telefonica.com> <014a01d12394$ec5ffa60$c51fef20$@gmail.com> In-Reply-To: <014a01d12394$ec5ffa60$c51fef20$@gmail.com> Accept-Language: es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151105 authentication-results: spf=none (sender IP is ) smtp.mailfrom=pedroa.aranda@telefonica.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [195.235.92.36] x-microsoft-exchange-diagnostics: 1; DB4PR06MB0638; 5:Bllt6XTR2L7/3oaUFxggJqOrBEfD4S7jU9e5iN2gJNpkheRQkzmWYG0flF0U8sO06MJUyingjxV+zzy86QTRKn4sUS3swmy7Qd388WqR6QjBVUwWTB+ZldtRsNlqYGe8t9nDXS4WWcrkdxZAwVAYXg==; 24:sB6wuu70JwLb3YqipnTYXhMT1pnj63lfcXhggYukXyuXPV8QMHPEKCwtdsGUgyg1OKtsZ/aDHBwla4OtesP5v1Q9362tuXpovSIEOM6crbo= x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(42139001); SRVR:DB4PR06MB0638; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(40392960112811); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(10201501046)(3002001); SRVR:DB4PR06MB0638; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0638; x-forefront-prvs: 07697999E6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(59124004)(5008740100001)(33656002)(2900100001)(5002640100001)(86362001)(36756003)(5004730100002)(92566002)(5007970100001)(87936001)(105586002)(77096005)(575784001)(586003)(106116001)(10400500002)(83716003)(40100003)(19580395003)(2950100001)(101416001)(6116002)(4001350100001)(83506001)(93886004)(5001770100001)(76176999)(106356001)(50986999)(3846002)(82746002)(81156007)(122556002)(66066001)(189998001)(19580405001)(54356999)(5001920100001)(5001960100002)(102836003)(11100500001)(97736004)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB0638; H:DB4PR06MB0639.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <8C36EE462C00DE49B9B6B2081E0DDE78@eurprd06.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2015 07:04:26.1447 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB0638 X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: Cc: "i2rs@ietf.org" , "'Joel M. Halpern'" , 'Andy Bierman' , 'Susan Hares' Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2015 07:04:49 -0000 SGksDQoNClJlIHRoZSBtZXRyaWMgJ3Byb2JsZW0nLCBqdXN0IHRvIGJlIG1vcmUgcHJlY2lzZSBp biB3aGF0IHdvdWxkIGJlIG5lZWRlZCwgd2UgYXJlIGxvb2tpbmcgYSBtZXRyaWMgdGhhdCBncm93 cyBvciBkZWNyZWFzZXMgbW9ub3RvbmljYWxseSBhY3Jvc3MgdGhlIHdob2xlIG5ldHdvcmsuIFRo ZSB0aGVvcmV0aWNhbCBncm91bmRzIGZvciB0aGlzIGFyZSBpbiBULiBHcmlmZmlu4oCZcyBhbmQg U29icmluaG/igJlzIHdvcmsgb24gQkdQLTQgYW5kIHRoYXQgbGllcyBhbHJlYWR5IGEgY291cGxl IG9mIHllYXJzIGFnbyBhbmQgdGhhdCBtYWtlcyB0aGUgYW5hbHlzaXMgbXVjaCDigJhlYXNpZXLi gJkgKG5vIHdvcnJpZXMgYWJvdXQgbnAoY29tcGxldGUpIHByb2JsZW1zLCBldGMuKS4gVGhpcyBj b3VsZCBiZSBhcHBsaWVkIGluIEkyUlMgYXQgdGhlIHJvdXRpbmcgcHJvdG9jb2wgbGV2ZWwuIFNv LCB3ZSBjb3VsZCBkaXNjdXNzIHdoZXJlIHRoYXQgc2l0cyAoc2hvdWxkIGJlIHRoZSBjbGllbnRz LCByaWdodD8pIGFuZCBJIGRvbuKAmXQga25vdyBpZiB0aGF04oCZcyBiZWVuIGFscmVhZHkgZG9u ZSwgc2luY2UgSeKAmW0gcXVpdGUgbmV3IHRvIHRoaXMgbGlzdC4NCg0KTm93LCBoYXZpbmcg4oCc c29sdmVk4oCdIHRoYXQgcGFydCBvZiB0aGUgZXF1YXRpb24gOi0pICwgdGhlIHBhcnQgdGhhdCBp bnRlcmVzdHMgbWUgbW9yZSBpcyB0aGUgY29uZmxpY3RpbmcgY2xpZW50cyBwcm9ibGVtLCBiZWNh dXNlIHRoaXMgY291bGQgYmUgZ2VuZXJhbGlzZWQgdG8gb3RoZXIgcHJvYmxlbSBzcGFjZXMgaW4g dGhlIFNETiBhcmVhLiBJIGRvIGFncmVlIHRoYXQgYWdlbnRzIHNob3VsZCBiZSBhYmxlIHRvIGNh dGNoIG9mZmVuZGluZyBzdGF0ZSBiZWZvcmUgaW5zdGFsbGluZyBpdCBhbmQgSeKAmW0gbG9va2lu ZyBmb3Igd2F5cyB0byBzcGVjaWZ5IGEgbWluaW1hbCBzZXQgb2YgZmVhdHVyZXMgdGhhdCBuZWVk IHRvIGJlIHN1cHBvcnRlZCBhdCBwcm90b2NvbCBsZXZlbC4NCg0KQW55b25lIGVsc2UgaW50ZXJl c3RlZD8NCg0KQlIsIC9QQQ0KLS0tDQpEci4gUGVkcm8gQS4gQXJhbmRhIEd1dGnDqXJyZXoNCg0K VGVjaG5vbG9neSBFeHBsb3JhdGlvbiAtDQpOZXR3b3JrIElubm92YXRpb24gJiBWaXJ0dWFsaXNh dGlvbg0KZW1haWw6IHBlZHJvYSBkMHQgYXJhbmRhIEF0IHRlbGVmb25pY2EgZDB0IGNvbQ0KVGVs ZWbDs25pY2EsIEludmVzdGlnYWNpw7NuIHkgRGVzYXJyb2xsbw0KQy8gWnVyYmFyw6FuLDEyDQoy ODAxMCBNYWRyaWQsIFNwYWluDQoNCkZyYWdlbiBzaW5kIG5pY2h0IGRhLCB1bSBiZWFudHdvcnRl dCB6dSB3ZXJkZW4uDQpGcmFnZW4gc2luZCBkYSwgdW0gZ2VzdGVsbHQgenUgd2VyZGVuLg0KR2Vv cmcgS3JlaXNsZXINCg0KDQoNCg0KDQoNCg0KDQotLS0tLU1lbnNhamUgb3JpZ2luYWwtLS0tLQ0K RGU6IFJ1c3MgV2hpdGUgPDdyaXc3N0BnbWFpbC5jb20+DQpGZWNoYTogdmllcm5lcywgMjAgZGUg bm92aWVtYnJlIGRlIDIwMTUsIDE0OjExDQpQYXJhOiBwYWFnIDxwZWRyb2EuYXJhbmRhQHRlbGVm b25pY2EuY29tPiwgJ0plZmZyZXkgSGFhcycgPGpoYWFzQHBmcmMub3JnPg0KQ0M6ICJpMnJzQGll dGYub3JnIiA8aTJyc0BpZXRmLm9yZz4sICInSm9lbCBNLiBIYWxwZXJuJyIgPGptaEBqb2VsaGFs cGVybi5jb20+LCAnQW5keSBCaWVybWFuJyA8YW5keUB5dW1hd29ya3MuY29tPiwgU3VlIEhhcmVz IDxzaGFyZXNAbmR6aC5jb20+DQpBc3VudG86IFJFOiBbaTJyc10gQ29udmVyc2F0aW9uIG9uIFBy aW9yaXR5IGFuZCBQYW5lcw0KDQo+DQo+PiBUaGUgZGFuZ2VyIEkgc2VlIHRoZXJlIGlzIHRoYXQg YSBzcGVjaWZpYyBwb2xpY3kgYXBwbGllZCBieSBvbmUgY2xpZW50IChhcHApIG1heQ0KPj4gdHJp Z2dlciB1bmludGVuZGVkIGNoYW5nZXMgaW4gYSBwYXJ0IG9mIHRoZSAicGxhbmVzIG9mIGdsYXNz IiBpdCBpcyBub3QgYXdhcmUNCj4+IG9mLiBIZW5jZSBhIGZ1bGwgY29weSBpcyBuZWVkZWQgaW4g ZWFjaCBjbGllbnQgKGFwcCkgbWF5IGJlIG5lZWRlZOKApiBUaGlzIGFsc28NCj4+IGhvbGRzIGZv ciBzdWJzY3JpYmluZyB0byBjaGFuZ2Ugbm90aWZpY2F0aW9ucy4gSG93IGNhbiBJIHN1YnNjcmli ZSB0byBhIGNoYW5nZQ0KPj4gbm90aWZpY2F0aW9uIG9mIHNvbWV0aGluZyBJ4oCZbSBub3Qgb3Ig SSBkb27igJl0IHdhbnQgdG8gYmUgYXdhcmUgb2Y/DQo+DQo+SSBkb24ndCBzZWUgaG93IHRoYXQn cyBnb2luZyB0byBiZSBhbnkgZGlmZmVyZW50IHdoZXRoZXIgdGhlIGFsdGVybmF0ZSBzdGF0ZXMg YXJlIGhlbGQgaW4gdGhlIGFnZW50IG9yIG9uIHRoZSBjbGllbnRzIC0tIGVpdGhlciB3YXksIGRv aW5nICJ4IiBtaWdodCB0cmlnZ2VyIHNvbWUgb3RoZXIgY2xpZW50IHRvIGRvICJ5LiIgVGhlIG9u bHkgZGlmZmVyZW5jZSBpcyBob3cgbG9uZyBpdCB0YWtlcyBmb3IgdGhlIGZpcnN0IGNsaWVudCB0 byBzZWUgdGhlIHNlY29uZCBjbGllbnQgZG9pbmcgInksIiBhbmQgdGhlbiByZWFjdGluZyB0byBp dCBieSBkb2luZyAiei4iIEV2ZW4gdHJ5aW5nIHRvIG1ha2UgY2VydGFpbiBldmVyeSBjbGllbnQg aGFzIGEgZnVsbCBsaXN0IG9mIGFsbCBwb3NzaWJsZSBjb25kaXRpb25zIHRoZXJlIHdpbGwgc3Rp bGwgYmUgcmFjZSBjb25kaXRpb25zIGluIHRoZSBtaXgsIHNvIHRoYXQgd29uJ3Qgc29sdmUgdGhl IHByb2JsZW0sIGVpdGhlci4gQXQgc29tZSBwb2ludCwgeW91J3JlIGdvaW5nIHRvIGhpdCB5b3Vy IGhlYWQgYWdhaW5zdCBDQVAgLS0gaXQncyBqdXN0IGEgbWF0dGVyIG9mIHdoZXJlLCB3aGVuLCBh bmQgaG93IHRvIG1hbmFnZSBpdC4NCj4NCj5UaGUgb25seSByZWFsIHNvbHV0aW9uIHRvIHRoaXMg c29ydCBvZiBwcm9ibGVtIGlzIHRvIGhhdmUgYSBkZWZpbml0aXZlIHNpbmdsZSAibWV0cmljIiB0 aGF0IHByb3ZpZGVzIGFuIGFuc3dlciB0byBldmVyeSBzaXR1YXRpb24uIEp1c3QgbGlrZSB3aXRo IGEgcm91dGluZyBwcm90b2NvbCwgeW91IGNhbid0IGJ1aWxkIGEgZGlzdHJpYnV0ZWQgc3lzdGVt IHRoYXQgdXNlcyBtb3JlIHRoYW4gb25lIG1ldHJpYyB3aXRob3V0IGVuZGluZyB1cCB3aXRoIHdl ZGdpZXMgKGhlbmNlIEJHUCkuIE1pa2UgU2hhbmQgb25jZSB0b2xkIG1lIHRoaXMgaXMgYW4gbnAo Y29tcGxldGUpIHByb2JsZW0gLS0gSSdtIGd1ZXNzaW5nIE1pa2UgaXMgcmlnaHQgb24gdGhpcyBv bmUuIEl0IHNlZW1zLCB0byBtZSwgdGhhdCB0aGlzIGlzIHByZWNpc2VseSB3aGF0IHRoZSAicHJp b3JpdHkiIGluIHRoaXMgc3lzdGVtIHByb3ZpZGVzIC0tIGluIGFueSBjYXNlLCB0aGUgY2xpZW50 IHdpdGggdGhlIGJlc3QgcHJpb3JpdHkgd2lucy4gQXMgbm8gdHdvIGNsaWVudHMgY2FuIGhhdmUg dGhlIHNhbWUgcHJpb3JpdHkgKGl0J3MgdGllZCB0byB0aGUgY2xpZW50IGlkLCBmcm9tIHdoYXQg SSByZW1lbWJlciksIGl0ICJqdXN0IHdvcmtzLiINCj4NCj5UaGUgb25lIHNpdHVhdGlvbiB5b3Ug Y2FuIGdldCBpbiB0byBpcyB3aGVuIGNsaWVudCAxIHNheXMgImRvIHgsIiBjbGllbnQgMiBzYXlz LCAiZG8geSwiIGFuZCB5b3UgZW5kIHVwIHdpdGggYSByb3V0aW5nIGxvb3Agb3IgY29udHJhZGlj dG9yeSBwb2xpY2llcyBhcHBsaWVkLiBUaGlzIGlzIGdvaW5nIHRvIGJlIGEgcHJvYmxlbSBubyBt YXR0ZXIgd2hlcmUgdGhlIGluZm9ybWF0aW9uIGlzIHN0b3JlZC4gSSBkb24ndCB0aGluayB3ZSBj YW4gYWRkcmVzcyB0aGlzIGF0IHRoZSBwcm90b2NvbCBsZXZlbCAtLSBhbGwgdGhlIHByb3RvY29s IGNhbiBkbyBpcyBiZSBhcyBhY2N1cmF0ZSBhYm91dCBjdXJyZW50IHN0YXRlIGFzIGl0J3MgaW5z dGFsbGVkIGFzIHBvc3NpYmxlLiBUaGUgYWdlbnQgc2hvdWxkIGJlIGFibGUgdG8gZGV0ZWN0IHNv bWUgc2l0dWF0aW9ucyBsaWtlIHRoaXMgYW5kIHJlZnVzZSB0byBpbnN0YWxsIHRoZSBvZmZlbmRp bmcgc3RhdGUuIFRoZSBjbGllbnRzIG1heSBiZSBhYmxlIHRvIGRldGVjdCBzb21lIG9mIHRoaXMs IGFzIHdlbGwsIGFuZCBmaXggdGhpbmdzLiBCdXQgSSBkb24ndCBzZWUgaG93IHdlIGNvdWxkIHNw ZWNpZnkgc3VjaCBhIHRoaW5nIGluIHRoZSBwcm90b2NvbC4gT3IgcmF0aGVyLCBpZiB3ZSBkbywg d2hlbiB3ZSdkIGV2ZXIgYmUgYWJsZSB0byBzdG9wIHNwZWNpZnlpbmcgc3VjaCB0aGluZ3MuLi4N Cj4NCj46LSkNCj4NCj5SdXNzDQo+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQoNCkVzdGUgbWVuc2FqZSB5IHN1cyBhZGp1bnRvcyBzZSBkaXJpZ2VuIGV4Y2x1c2l2YW1lbnRl IGEgc3UgZGVzdGluYXRhcmlvLCBwdWVkZSBjb250ZW5lciBpbmZvcm1hY2nDs24gcHJpdmlsZWdp YWRhIG8gY29uZmlkZW5jaWFsIHkgZXMgcGFyYSB1c28gZXhjbHVzaXZvIGRlIGxhIHBlcnNvbmEg byBlbnRpZGFkIGRlIGRlc3Rpbm8uIFNpIG5vIGVzIHVzdGVkLiBlbCBkZXN0aW5hdGFyaW8gaW5k aWNhZG8sIHF1ZWRhIG5vdGlmaWNhZG8gZGUgcXVlIGxhIGxlY3R1cmEsIHV0aWxpemFjacOzbiwg ZGl2dWxnYWNpw7NuIHkvbyBjb3BpYSBzaW4gYXV0b3JpemFjacOzbiBwdWVkZSBlc3RhciBwcm9o aWJpZGEgZW4gdmlydHVkIGRlIGxhIGxlZ2lzbGFjacOzbiB2aWdlbnRlLiBTaSBoYSByZWNpYmlk byBlc3RlIG1lbnNhamUgcG9yIGVycm9yLCBsZSByb2dhbW9zIHF1ZSBub3MgbG8gY29tdW5pcXVl IGlubWVkaWF0YW1lbnRlIHBvciBlc3RhIG1pc21hIHbDrWEgeSBwcm9jZWRhIGEgc3UgZGVzdHJ1 Y2Npw7NuLg0KDQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgdHJhbnNtaXNzaW9u IGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBvbmx5 IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSBuYW1lZCBhYm92ZS4gSWYg dGhlIHJlYWRlciBvZiB0aGlzIG1lc3NhZ2UgaXMgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQs IHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1 dGlvbiBvciBjb3B5aW5nIG9mIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBzdHJpY3RseSBwcm9oaWJp dGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgZG8g bm90IHJlYWQgaXQuIFBsZWFzZSBpbW1lZGlhdGVseSByZXBseSB0byB0aGUgc2VuZGVyIHRoYXQg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yIGFuZCB0aGVuIGRl bGV0ZSBpdC4NCg0KRXN0YSBtZW5zYWdlbSBlIHNldXMgYW5leG9zIHNlIGRpcmlnZW0gZXhjbHVz aXZhbWVudGUgYW8gc2V1IGRlc3RpbmF0w6FyaW8sIHBvZGUgY29udGVyIGluZm9ybWHDp8OjbyBw cml2aWxlZ2lhZGEgb3UgY29uZmlkZW5jaWFsIGUgw6kgcGFyYSB1c28gZXhjbHVzaXZvIGRhIHBl c3NvYSBvdSBlbnRpZGFkZSBkZSBkZXN0aW5vLiBTZSBuw6NvIMOpIHZvc3NhIHNlbmhvcmlhIG8g ZGVzdGluYXTDoXJpbyBpbmRpY2FkbywgZmljYSBub3RpZmljYWRvIGRlIHF1ZSBhIGxlaXR1cmEs IHV0aWxpemHDp8OjbywgZGl2dWxnYcOnw6NvIGUvb3UgY8OzcGlhIHNlbSBhdXRvcml6YcOnw6Nv IHBvZGUgZXN0YXIgcHJvaWJpZGEgZW0gdmlydHVkZSBkYSBsZWdpc2xhw6fDo28gdmlnZW50ZS4g U2UgcmVjZWJldSBlc3RhIG1lbnNhZ2VtIHBvciBlcnJvLCByb2dhbW9zLWxoZSBxdWUgbm9zIG8g Y29tdW5pcXVlIGltZWRpYXRhbWVudGUgcG9yIGVzdGEgbWVzbWEgdmlhIGUgcHJvY2VkYSBhIHN1 YSBkZXN0cnVpw6fDo28NCg== From nobody Sun Nov 22 23:16:02 2015 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C68361B318B; Sun, 22 Nov 2015 23:15:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151123071558.25655.92641.idtracker@ietfa.amsl.com> Date: Sun, 22 Nov 2015 23:15:58 -0800 Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2015 07:15:59 -0000 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 : A YANG Data Model for Routing Information Base (RIB) Authors : Lixing Wang Hariharan Ananthakrishnan Mach(Guoyi) Chen Amit Dass Sriganesh Kini Nitin Bahadur Filename : draft-ietf-i2rs-rib-data-model-04.txt Pages : 65 Date : 2015-11-22 Abstract: This document defines a YANG data model for Routing Information Base (RIB) that aligns with the I2RS RIB information model. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-i2rs-rib-data-model-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-rib-data-model-04 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 nobody Sun Nov 22 23:23:16 2015 Return-Path: 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 41E161B3662 for ; Sun, 22 Nov 2015 23:23:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.786 X-Spam-Level: X-Spam-Status: No, score=-4.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham 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 iTnxVP5eF1Md for ; Sun, 22 Nov 2015 23:23:12 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 348691B3661 for ; Sun, 22 Nov 2015 23:23:12 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CEL78391; Mon, 23 Nov 2015 07:23:09 +0000 (GMT) Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 23 Nov 2015 07:23:08 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.73]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0235.001; Mon, 23 Nov 2015 15:23:02 +0800 From: Mach Chen To: "i2rs@ietf.org" Thread-Topic: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.txt Thread-Index: AQHRJb7gDQr+c8ugKk+zT8tYpLAi3J6pMp/g Date: Mon, 23 Nov 2015 07:23:01 +0000 Message-ID: References: <20151123071558.25655.92641.idtracker@ietfa.amsl.com> In-Reply-To: <20151123071558.25655.92641.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0202.5652BEDE.004F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.73, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: bc1b2c948e9700dd07f8129248718cf5 Archived-At: Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2015 07:23:15 -0000 Hi, We just uploaded an update that addresses the comments received (include on= line and offline) recently. Please review the draft and comment! Thanks, Mach > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of internet-drafts@ie= tf.org > Sent: Monday, November 23, 2015 3:16 PM > To: i-d-announce@ietf.org > Cc: i2rs@ietf.org > Subject: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Interface to the Routing System Working= Group > of the IETF. >=20 > Title : A YANG Data Model for Routing Information Base > (RIB) > Authors : Lixing Wang > Hariharan Ananthakrishnan > Mach(Guoyi) Chen > Amit Dass > Sriganesh Kini > Nitin Bahadur > Filename : draft-ietf-i2rs-rib-data-model-04.txt > Pages : 65 > Date : 2015-11-22 >=20 > Abstract: > This document defines a YANG data model for Routing Information Base > (RIB) that aligns with the I2RS RIB information model. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-i2rs-rib-data-model-04 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2rs-rib-data-model-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Mon Nov 23 04:06:49 2015 Return-Path: <7riw77@gmail.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 F1FBE1B3225 for ; Mon, 23 Nov 2015 04:06:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_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 4Dbp7LeQQgpO for ; Mon, 23 Nov 2015 04:06:46 -0800 (PST) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (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 67ECF1B3224 for ; Mon, 23 Nov 2015 04:06:46 -0800 (PST) Received: by ykdv3 with SMTP id v3so233816836ykd.0 for ; Mon, 23 Nov 2015 04:06:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=o8bRzHygJ/mqBzHOV0UMSfa6IE2nJvpamwMo/QtQrsc=; b=npDJThFiX8T8XslryMNeTpDoqsU6wZtQbyVVRfsSziIGU1Us6uijNKUDQ3p1vhhpED u+FVhSheioxe1TKpnwKbmOGdRuC8zp7Tk9MJvKbwg5M7+WSGQEJLFQPyvnBLmUHJ+olk 1HQUjJtr8yxQwXugmALWvmBz5yiy1WT4R9TjZbMjZSIfwFzLkmPY3DAHlOERESk8WsIY ZGueb6FBViVfge8efqE+M9CbGes9KF4bZoV4kaqZkv3N9wuFCITxT81oyjKPnU3FAoYb 71Cc/P86u5f0z5VxJF1OoQkkBz8f+x0GpwmenXcjQSwbI6mm2YR9HlkaCh1oZJsMdhbY NpUQ== X-Received: by 10.129.113.68 with SMTP id m65mr4541774ywc.61.1448280405748; Mon, 23 Nov 2015 04:06:45 -0800 (PST) Received: from Russ ([2602:30a:2e5b:44d0:3d31:3ea:5be1:4e14]) by smtp.gmail.com with ESMTPSA id v23sm11221590ywa.30.2015.11.23.04.06.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Nov 2015 04:06:45 -0800 (PST) From: "Russ White" <7riw77@gmail.com> To: "'PEDRO ANDRES ARANDA GUTIERREZ'" , "'Jeffrey Haas'" References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> <563A97AA.5020308@joelhalpern.com> <00f301d11761$61699130$243cb390$@gmail.com> <563AA59C.4060809@joelhalpern.com> <018101d11764$66b82e50$34288af0$@gmail.com> <20151119203509.GA22415@pfrc.org> <5B54713B-CDE6-4F65-BE79-91F5B9FF3850@telefonica.com> <008d01d12390$064987c0$12dc9740$@gmail.com> <99B64F3B-20A1-4D3C-A445-46D235EDB44D@telefonica.com> <014a01d12394$ec5ffa60$c51fef20$@gmail.com> <87361DB1-DC6F-4023-A807-4003B436B472@telefonica.com> In-Reply-To: <87361DB1-DC6F-4023-A807-4003B436B472@telefonica.com> Date: Mon, 23 Nov 2015 07:06:29 -0500 Message-ID: <012501d125e7$62e457e0$28ad07a0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLwMtmz+XLO8+uQ7j5WaenA2rWXRwHVfCJTAW3ySwACzWyr4AJQYvqoAmia70sCRUpXGQJL52qvAewKHZECaD7TrgHLBOvzApMDTUsCqh6d6wGYO72JAaqfRnSbe5ECYA== Content-Language: en-us Archived-At: Cc: i2rs@ietf.org, "'Joel M. Halpern'" , 'Andy Bierman' , 'Susan Hares' Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2015 12:06:48 -0000 > Re the metric 'problem', just to be more precise in what would be = needed, > we are looking a metric that grows or decreases monotonically across = the > whole network.=20 I assume you mean in the routing space, and not in the controller/client = space, correct? In terms of a distributed protocol? So, you're saying = the delay could use "metrics" between 11 and 20, while the bandwidth = could use "metrics" between 21 and 30, etc? And then you just add them = all together? That's what IS-IS has done for years... Even BGP really = only has one "metric," with following "tie breakers..." So if you have = something like weight/local pref/etc, such that they occupy different = "spaces" in a bit pattern (something suggested, btw, in the original = wide community work, and in other places, as well), you're actually just = building a single metric. You've not "solved" the multiple metric problem -- just done something a = little different than EIGRP's K values to combine them into a single = metric, which is where you need to be to have the ability to build a = single stable SPT/DAG. > The theoretical grounds for this are in T. Griffin=E2=80=99s and > Sobrinho=E2=80=99s work on BGP-4 and that lies already a couple of = years ago and that > makes the analysis much =E2=80=98easier=E2=80=99 (no worries about = np(complete) problems, > etc.). This could be applied in I2RS at the routing protocol level. = So, we could > discuss where that sits (should be the clients, right?) and I = don=E2=80=99t know if > that=E2=80=99s been already done, since I=E2=80=99m quite new to this = list. This doesn=E2=80=99t apply to the problem at hand, though... You seem to = be saying (clarify if wrong) -- 1. Give each client some set of bits out of a 128 bit number space (or = larger, etc.) 2. Each client can have different "metrics" within their own number = space 3. When a client attempts to add some ephemeral state, they use a metric = within their "space" 4. The agent can just use the straight number as a relative priority for = each potential piece of state This doesn't do anything different than the current concept of priority = between clients, only in the current plan each client only has one = priority, rather than multiples. I don't see where this relates to the = problem at hand.=20 =20 > Now, having =E2=80=9Csolved=E2=80=9D that part of the equation :-) , = the part that interests me > more is the conflicting clients problem, because this could be = generalised to > other problem spaces in the SDN area. I do agree that agents should be = able > to catch offending state before installing it and I=E2=80=99m looking = for ways to specify > a minimal set of features that need to be supported at protocol level. >=20 > Anyone else interested? This is precisely where the problem lies. And this is where you're going = to hit the CAP theorem in full force. There are only a few choices -- 1. Make the database eventually consistent 2. Shut down accessibility during changes 3. ?? (1) is the idea of either having the agent call back to all the clients = when state they installed is overwritten or allowing the agent to = locally store some state where it already has the information in hand = and install it locally -- the only real difference between these two = solutions is the "balance of complexity versus speed..." The entire = discussion here is how much additional complexity are we actually adding = by doing "panes of glass," which are just locally stored state which = isn't currently installed. I'm arguing that there's minimal complexity = added that you're not already going to have in the system to allow the = agent to store information locally _if_ it chooses to. Jeff is arguing = (I think) that the "panes of glass" concept is a coherent way of looking = at this problem that will help us understand and manage the complexity = in a way that makes sense. Joel is arguing (I think) that this sort of = solution is out of the WG charter, and it's too complex. I _think_ I = have the three general perspectives right, but I don't know if I really = have so... :-) (2) is the idea of locking the database while you're changing it. This = is explicitly outside the scope of I2RS entirely, given we're trying to = design something that's atomic/restful. There are a lot of techniques = you can use to speed up locking -- row locking, sharding, etc. -- but = none of these are interesting from the I2RS perspective.=20 :-) Russ From nobody Mon Nov 23 10:57:39 2015 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB8E1ACDD5; Mon, 23 Nov 2015 10:57:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151123185736.16085.14321.idtracker@ietfa.amsl.com> Date: Mon, 23 Nov 2015 10:57:36 -0800 Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-traceability-04.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2015 18:57:36 -0000 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 : Interface to the Routing System (I2RS) Traceability: Framework and Information Model Authors : Joe Clarke Gonzalo Salgueiro Carlos Pignataro Filename : draft-ietf-i2rs-traceability-04.txt Pages : 14 Date : 2015-11-23 Abstract: This document describes a framework for traceability in the Interface to the Routing System (I2RS) and information model for that framework. It specifies the motivation, requirements, use cases, and defines an information model for recording interactions between elements implementing the I2RS protocol. This framework provides a consistent tracing interface for components implementing the I2RS architecture to record what was done, by which component, and when. It aims to improve the management of I2RS implementations, and can be used for troubleshooting, auditing, forensics, and accounting purposes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-i2rs-traceability-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-traceability-04 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 nobody Mon Nov 23 11:00:13 2015 Return-Path: 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 A230B1ACDC1; Mon, 23 Nov 2015 11:00:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.086 X-Spam-Level: X-Spam-Status: No, score=-15.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 cw9qF2zPJiVH; Mon, 23 Nov 2015 11:00:10 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 650BC1ACDE6; Mon, 23 Nov 2015 11:00:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2175; q=dns/txt; s=iport; t=1448305208; x=1449514808; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=BtOCPOBN+VUvJM7FmFDGIQmhCk+RS5SJr+08p3ccVoI=; b=J+CdhcemJQC179Pogl1usRKPGhhTh20ltLodmrP0RR6BRQRhcEQ18icR Xx1j+gF5NDpTtl9KZDizbb3xdyuMsl1H6tFp7D6ZUQqMB0Wtc6WmOsKkk OVkXwUDKvL/oNLqEaf+yuVHVUfCyedoCr6vdh+PMDJfqZ3pFAaJb4mf+M U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D9AQBHYVNW/5xdJa1egztTb78eAQ2BZ?= =?us-ascii?q?RcKhW4CgUk4FAEBAQEBAQGBCoQ1AQEEAQEBNTYKARALEgYJFg8JAwIBAgEVIg4?= =?us-ascii?q?HDAYCAQGIKg2/GgEBAQEBAQEBAQEBAQEBAQEBARuGVIR+iTkBBI4UiDyFJIgNg?= =?us-ascii?q?VtJg3eDApMuHwEBQoQiIDSFKwEBAQ?= X-IronPort-AV: E=Sophos;i="5.20,338,1444694400"; d="scan'208";a="209946975" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Nov 2015 18:59:06 +0000 Received: from [10.117.46.173] (rtp-jclarke-89112.cisco.com [10.117.46.173]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id tANIx6H8016097; Mon, 23 Nov 2015 18:59:06 GMT To: internet-drafts@ietf.org, i-d-announce@ietf.org References: <20151123185736.16085.14321.idtracker@ietfa.amsl.com> From: Joe Clarke Organization: Cisco Systems, Inc. Message-ID: <565361FA.4040407@cisco.com> Date: Mon, 23 Nov 2015 13:59:06 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151123185736.16085.14321.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: i2rs@ietf.org Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-traceability-04.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2015 19:00:11 -0000 The changes in this version cover logging of requested versus applied operations and their data. Joe On 11/23/15 13:57, internet-drafts@ietf.org wrote: > > 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 : Interface to the Routing System (I2RS) Traceability: Framework and Information Model > Authors : Joe Clarke > Gonzalo Salgueiro > Carlos Pignataro > Filename : draft-ietf-i2rs-traceability-04.txt > Pages : 14 > Date : 2015-11-23 > > Abstract: > This document describes a framework for traceability in the Interface > to the Routing System (I2RS) and information model for that > framework. It specifies the motivation, requirements, use cases, and > defines an information model for recording interactions between > elements implementing the I2RS protocol. This framework provides a > consistent tracing interface for components implementing the I2RS > architecture to record what was done, by which component, and when. > It aims to improve the management of I2RS implementations, and can be > used for troubleshooting, auditing, forensics, and accounting > purposes. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-i2rs-traceability-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-traceability-04 > > > 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 > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Mon Nov 23 11:56:21 2015 Return-Path: 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 CCC701B29C5 for ; Mon, 23 Nov 2015 11:56:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.086 X-Spam-Level: X-Spam-Status: No, score=-15.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 NC2B83hDf--6 for ; Mon, 23 Nov 2015 11:56:18 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1B871B29BE for ; Mon, 23 Nov 2015 11:56:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3910; q=dns/txt; s=iport; t=1448308577; x=1449518177; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=eZ3D5SSxVlKRSFL1OVnK3aVN2VMnwQwsWc/tlEIOiqM=; b=SN5L2avKkVdm1P7o9OPKorVGinZRr0M5cH7CiTPYT71AVIAFM8G79OaS ItZQqMLvmpRm8xH2VCRVC53X/kQ1eZSQCeNPrjq8vPYPUoB3ry/rfS/GM wEiUQ3xRFATtrFaGvS57PqhmvnHuLy7cPkZHiOiTG4Dd5CzHviK7ylDNP Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D+AQCwblNW/4kNJK1egztTbwa/GAENg?= =?us-ascii?q?WUXCoVuAhyBLTgUAQEBAQEBAYEKhDQBAQEEAQEBIBE6FwQCAQgRBAEBAwIjAwI?= =?us-ascii?q?CAiULFAEICAIEARKILg2vKJAaAQEBAQEBAQEBAQEBAQEBAQEBAQEBGIEBilGEW?= =?us-ascii?q?YMcgUQFllABhSOIDYFbSYN3hzWGJohUAR8BAUKEBHKEJIEHAQEB?= X-IronPort-AV: E=Sophos;i="5.20,338,1444694400"; d="scan'208";a="211209770" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Nov 2015 19:56:17 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id tANJuGVL019010 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 23 Nov 2015 19:56:17 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 23 Nov 2015 14:56:16 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.000; Mon, 23 Nov 2015 14:56:16 -0500 From: "Acee Lindem (acee)" To: Mach Chen , "i2rs@ietf.org" Thread-Topic: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.txt Thread-Index: AQHRJb7h39RAbXuc60efRnDCdZXpzJ6pmKmAgABt2gA= Date: Mon, 23 Nov 2015 19:56:15 +0000 Message-ID: References: <20151123071558.25655.92641.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2015 19:56:20 -0000 SGkgTWFjaCwgDQoNCknigJltIGxvb2tpbmcgYXQgZHJhZnQtaWV0Zi1pMnJzLXJpYi1kYXRhLW1v ZGVsLTA0LnR4dCBhbmQgaXQgc3RpbGwgaW5jbHVkZXMNCmFsbCB0aGUgdHVubmVsIGVuY2Fwcy4g SSBrbm93IHlvdSByZWNlaXZlZCBzZXZlcmFsIGNvbW1lbnRzIHRoYXQgdGhvc2UNCnNob3VsZCBi ZSBpbiB0aGUgdHVubmVsIG1vZGVsKHMpIGFuZCB0aGlzIEkyUlMgUklCIG1vZGVsIHNob3VsZCBt ZXJlbHkNCnJlZmVyZW5jZSBhbiBpbXBvcnRlZCB0dW5uZWwgYWJzdHJhY3Rpb24uIEhvdyBhcmUg eW91IGdvaW5nIHRvIGFkZHJlc3MNCnRoaXM/IEl0IHNlZW1lZCB0aGF0IHRoZSBjb25zZW5zdXMg KGFuZCBhbiBvcGluaW9uIHRoYXQgSSBzaGFyZSkgd2FzIHRoYXQNCnRoaXMgbW9kZWwgc2hvdWxk IG5vdCBhdHRlbXB0IHRvIGdlbmVyaWNhbGx5IGNyZWF0ZWQgdHVubmVscyB2aWEgUklCL0ZJQg0K ZW50cmllcy4gDQpUaGFua3MsDQpBY2VlDQoNCk9uIDExLzIzLzE1LCAyOjIzIEFNLCAiaTJycyBv biBiZWhhbGYgb2YgTWFjaCBDaGVuIiA8aTJycy1ib3VuY2VzQGlldGYub3JnDQpvbiBiZWhhbGYg b2YgbWFjaC5jaGVuQGh1YXdlaS5jb20+IHdyb3RlOg0KDQo+SGksDQo+DQo+V2UganVzdCB1cGxv YWRlZCBhbiB1cGRhdGUgdGhhdCBhZGRyZXNzZXMgdGhlIGNvbW1lbnRzIHJlY2VpdmVkIChpbmNs dWRlDQo+b25saW5lIGFuZCBvZmZsaW5lKSByZWNlbnRseS4gUGxlYXNlIHJldmlldyB0aGUgZHJh ZnQgYW5kIGNvbW1lbnQhDQo+DQo+VGhhbmtzLA0KPk1hY2gNCj4NCj4+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBpMnJzIFttYWlsdG86aTJycy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YNCj4+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQo+PiBTZW50OiBNb25k YXksIE5vdmVtYmVyIDIzLCAyMDE1IDM6MTYgUE0NCj4+IFRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5v cmcNCj4+IENjOiBpMnJzQGlldGYub3JnDQo+PiBTdWJqZWN0OiBbaTJyc10gSS1EIEFjdGlvbjog ZHJhZnQtaWV0Zi1pMnJzLXJpYi1kYXRhLW1vZGVsLTA0LnR4dA0KPj4gDQo+PiANCj4+IEEgTmV3 IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURy YWZ0cw0KPj5kaXJlY3Rvcmllcy4NCj4+ICBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRo ZSBJbnRlcmZhY2UgdG8gdGhlIFJvdXRpbmcgU3lzdGVtDQo+PldvcmtpbmcgR3JvdXANCj4+IG9m IHRoZSBJRVRGLg0KPj4gDQo+PiAgICAgICAgIFRpdGxlICAgICAgICAgICA6IEEgWUFORyBEYXRh IE1vZGVsIGZvciBSb3V0aW5nIEluZm9ybWF0aW9uIEJhc2UNCj4+IChSSUIpDQo+PiAgICAgICAg IEF1dGhvcnMgICAgICAgICA6IExpeGluZyBXYW5nDQo+PiAgICAgICAgICAgICAgICAgICAgICAg ICAgIEhhcmloYXJhbiBBbmFudGhha3Jpc2huYW4NCj4+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgTWFjaChHdW95aSkgQ2hlbg0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICBBbWl0IERh c3MNCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgU3JpZ2FuZXNoIEtpbmkNCj4+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgTml0aW4gQmFoYWR1cg0KPj4gCUZpbGVuYW1lICAgICAgICA6 IGRyYWZ0LWlldGYtaTJycy1yaWItZGF0YS1tb2RlbC0wNC50eHQNCj4+IAlQYWdlcyAgICAgICAg ICAgOiA2NQ0KPj4gCURhdGUgICAgICAgICAgICA6IDIwMTUtMTEtMjINCj4+IA0KPj4gQWJzdHJh Y3Q6DQo+PiAgICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBZQU5HIGRhdGEgbW9kZWwgZm9yIFJv dXRpbmcgSW5mb3JtYXRpb24gQmFzZQ0KPj4gICAgKFJJQikgdGhhdCBhbGlnbnMgd2l0aCB0aGUg STJSUyBSSUIgaW5mb3JtYXRpb24gbW9kZWwuDQo+PiANCj4+IA0KPj4gDQo+PiBUaGUgSUVURiBk YXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4+IGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaTJycy1yaWItZGF0YS1tb2RlbC8NCj4+ IA0KPj4gVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+PiBo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pMnJzLXJpYi1kYXRhLW1vZGVs LTA0DQo+PiANCj4+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJs ZSBhdDoNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWky cnMtcmliLWRhdGEtbW9kZWwtMDQNCj4+IA0KPj4gDQo+PiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1h eSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPj5zdWJtaXNzaW9u DQo+PiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0 IHRvb2xzLmlldGYub3JnLg0KPj4gDQo+PiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxh YmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+PiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzLw0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4gaTJycyBtYWlsaW5nIGxpc3QNCj4+IGkycnNAaWV0Zi5vcmcNCj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJycw0KPg0KPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+aTJycyBtYWlsaW5nIGxpc3QNCj5p MnJzQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMnJz DQoNCg== From nobody Mon Nov 23 13:27:28 2015 Return-Path: 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 BDF051B3478 for ; Mon, 23 Nov 2015 13:27:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 xm1MDzOQQhtd for ; Mon, 23 Nov 2015 13:27:25 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A5021B3477 for ; Mon, 23 Nov 2015 13:27:25 -0800 (PST) X-AuditID: c618062d-f799d6d000000ec2-06-565332ded57e Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 7D.DF.03778.ED233565; Mon, 23 Nov 2015 16:38:07 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0248.002; Mon, 23 Nov 2015 16:27:24 -0500 From: Jeff Tantsura To: "Acee Lindem (acee)" , Mach Chen , "i2rs@ietf.org" Thread-Topic: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.txt Thread-Index: AQHRJb7gfQvt/sYhs0ikLpWdxwOf0p6ph+WAgADSdID//7TegA== Date: Mon, 23 Nov 2015 21:27:22 +0000 Message-ID: <8D628270-A455-4E01-881F-BA20D544228D@ericsson.com> References: <20151123071558.25655.92641.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151105 x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="utf-8" Content-ID: <8152773578439C45995B8C9BE66B062C@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJIsWRmVeSWpSXmKPExsUyuXRPiO59o+Awg54uPovJb+cxW6yb8YHF 4sJaYQdmjym/N7J6tBx5y+qxZMlPpgDmKC6blNSczLLUIn27BK6M7TsOMRfM0KjoPTWVpYFx inoXIweHhICJxJsu1i5GTiBTTOLCvfVsXYxcHEICRxglzjT+g3KWM0qcmn6WGaSKTcBA4v+3 4ywgtohAnsT3TYfAuoUFXCVutX1nhIi7SRy88ZQZZIGIgJNEy7MokDCLgKrExFOdYCW8AvYS qy83MEPMX88o8ebQKrCZnAI6EvN3zWACsRmBLvp+ag2YzSwgLnHryXwmiEsFJJbsOc8MYYtK vHz8jxVkl6iArsS3vwEQYSWJOa+vgZ3ALKApsX6XPsQUa4nJ65YwQtiKElO6H7JDnCMocXLm E5YJjOKzkCybhdA9C0n3LCTds5B0L2BkXcXIUVqcWpabbmSwiREYYcck2HR3MO55aXmIUYCD UYmH94NmcJgQa2JZcWXuIUYJDmYlEd4p6UAh3pTEyqrUovz4otKc1OJDjNIcLErivPuX3A8V EkhPLEnNTk0tSC2CyTJxcEo1MMrFbPmcd952q0nfh5u3Owx1882TpY/3Kur5hS9ZpLWDP/vZ K9truSIbtJJm7TbtXvhTvLzlhYO93t/53muX9X1YZbV1gpBfutEkzs1WofmvD66wF1H/9Fb4 DdujI6kzhad2ODV4S11qmtrKtaFgzgG57Xmz4lUfr+M/Ktkm4/Zy+jbrDZKX/iqxFGckGmox FxUnAgDLMekqrAIAAA== Archived-At: Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2015 21:27:27 -0000 SGkgTWFjaCwNCg0KSSBhZ3JlZSB3aXRoIEFjZWXigJlzIGNvbW1lbnRzIGFuZCB3b3VsZCBlbmNv dXJhZ2UgeW91IHRvIHVzZSBnZW5lcmljL2V4aXN0aW5nIHR1bm5lbCBtb2RlbChzKSwgcGxlYXNl IHNlZSBjb21tZW50cyBwcm92aWRlZCBkdXJpbmcgUlRHV0cgbWVldGluZyBpbiBZb2tvaGFtYS4N ClRoZXJlIGFyZSBhbHJlYWR5IHRvbyBtYW55LCB3ZSBuZWVkIHRvIHJhdGlvbmFsaXplIHRoaXMg d29yay4NCg0KVGhpcyBpcyB3aGF0IGhhcyBiZWVuIGRpc2N1c3NlZCBpbiBZb2tvaGFtYSwgUm9i aW4gcHJlc2VudGVkDQoNCi0tIGRyYWZ0LWxpLXJ0Z3dnLXV0dW5uZWwteWFuZw0KICAgLS0gZHJh ZnQtbGktcnRnd2ctdHVubmVsLXBvbGljeS15YW5nDQogICAtLSBkcmFmdC13d3otbmV0bW9kLXlh bmctdHVubmVsLWNmZw0KICAgLS0gZHJhZnQtemhlbmctaW50YXJlYS1ncmUteWFuZw0KICAgLS0g ZHJhZnQtbGl1LWludGFyZWEtZ3JlLXR1bm5lbC15YW5nDQogICAtLSBkcmFmdC1saXUtaW50YXJl YS1pcGlwdjQtdHVubmVsLXlhbmcNCg0KDQoNCkNoZWVycywNCkplZmYNCg0KDQoNCg0KDQoNCk9u IDExLzIzLzE1LCAxMTo1NiwgImkycnMgb24gYmVoYWxmIG9mIEFjZWUgTGluZGVtIChhY2VlKSIg PGkycnMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgYWNlZUBjaXNjby5jb20+IHdyb3Rl Og0KDQo+SGkgTWFjaCwgDQo+DQo+SeKAmW0gbG9va2luZyBhdCBkcmFmdC1pZXRmLWkycnMtcmli LWRhdGEtbW9kZWwtMDQudHh0IGFuZCBpdCBzdGlsbCBpbmNsdWRlcw0KPmFsbCB0aGUgdHVubmVs IGVuY2Fwcy4gSSBrbm93IHlvdSByZWNlaXZlZCBzZXZlcmFsIGNvbW1lbnRzIHRoYXQgdGhvc2UN Cj5zaG91bGQgYmUgaW4gdGhlIHR1bm5lbCBtb2RlbChzKSBhbmQgdGhpcyBJMlJTIFJJQiBtb2Rl bCBzaG91bGQgbWVyZWx5DQo+cmVmZXJlbmNlIGFuIGltcG9ydGVkIHR1bm5lbCBhYnN0cmFjdGlv bi4gSG93IGFyZSB5b3UgZ29pbmcgdG8gYWRkcmVzcw0KPnRoaXM/IEl0IHNlZW1lZCB0aGF0IHRo ZSBjb25zZW5zdXMgKGFuZCBhbiBvcGluaW9uIHRoYXQgSSBzaGFyZSkgd2FzIHRoYXQNCj50aGlz IG1vZGVsIHNob3VsZCBub3QgYXR0ZW1wdCB0byBnZW5lcmljYWxseSBjcmVhdGVkIHR1bm5lbHMg dmlhIFJJQi9GSUINCj5lbnRyaWVzLiANCj5UaGFua3MsDQo+QWNlZQ0KPg0KPk9uIDExLzIzLzE1 LCAyOjIzIEFNLCAiaTJycyBvbiBiZWhhbGYgb2YgTWFjaCBDaGVuIiA8aTJycy1ib3VuY2VzQGll dGYub3JnDQo+b24gYmVoYWxmIG9mIG1hY2guY2hlbkBodWF3ZWkuY29tPiB3cm90ZToNCj4NCj4+ SGksDQo+Pg0KPj5XZSBqdXN0IHVwbG9hZGVkIGFuIHVwZGF0ZSB0aGF0IGFkZHJlc3NlcyB0aGUg Y29tbWVudHMgcmVjZWl2ZWQgKGluY2x1ZGUNCj4+b25saW5lIGFuZCBvZmZsaW5lKSByZWNlbnRs eS4gUGxlYXNlIHJldmlldyB0aGUgZHJhZnQgYW5kIGNvbW1lbnQhDQo+Pg0KPj5UaGFua3MsDQo+ Pk1hY2gNCj4+DQo+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBpMnJz IFttYWlsdG86aTJycy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4+PmludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZw0KPj4+IFNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMjMsIDIwMTUgMzox NiBQTQ0KPj4+IFRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCj4+PiBDYzogaTJyc0BpZXRmLm9y Zw0KPj4+IFN1YmplY3Q6IFtpMnJzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWkycnMtcmliLWRh dGEtbW9kZWwtMDQudHh0DQo+Pj4gDQo+Pj4gDQo+Pj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMg YXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzDQo+Pj5kaXJlY3Rvcmll cy4NCj4+PiAgVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgSW50ZXJmYWNlIHRvIHRo ZSBSb3V0aW5nIFN5c3RlbQ0KPj4+V29ya2luZyBHcm91cA0KPj4+IG9mIHRoZSBJRVRGLg0KPj4+ IA0KPj4+ICAgICAgICAgVGl0bGUgICAgICAgICAgIDogQSBZQU5HIERhdGEgTW9kZWwgZm9yIFJv dXRpbmcgSW5mb3JtYXRpb24gQmFzZQ0KPj4+IChSSUIpDQo+Pj4gICAgICAgICBBdXRob3JzICAg ICAgICAgOiBMaXhpbmcgV2FuZw0KPj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgSGFyaWhh cmFuIEFuYW50aGFrcmlzaG5hbg0KPj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgTWFjaChH dW95aSkgQ2hlbg0KPj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgQW1pdCBEYXNzDQo+Pj4g ICAgICAgICAgICAgICAgICAgICAgICAgICBTcmlnYW5lc2ggS2luaQ0KPj4+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgTml0aW4gQmFoYWR1cg0KPj4+IAlGaWxlbmFtZSAgICAgICAgOiBkcmFm dC1pZXRmLWkycnMtcmliLWRhdGEtbW9kZWwtMDQudHh0DQo+Pj4gCVBhZ2VzICAgICAgICAgICA6 IDY1DQo+Pj4gCURhdGUgICAgICAgICAgICA6IDIwMTUtMTEtMjINCj4+PiANCj4+PiBBYnN0cmFj dDoNCj4+PiAgICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBZQU5HIGRhdGEgbW9kZWwgZm9yIFJv dXRpbmcgSW5mb3JtYXRpb24gQmFzZQ0KPj4+ICAgIChSSUIpIHRoYXQgYWxpZ25zIHdpdGggdGhl IEkyUlMgUklCIGluZm9ybWF0aW9uIG1vZGVsLg0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+IFRoZSBJ RVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPj4+IGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaTJycy1yaWItZGF0YS1tb2Rl bC8NCj4+PiANCj4+PiBUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBh dDoNCj4+PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pMnJzLXJpYi1k YXRhLW1vZGVsLTA0DQo+Pj4gDQo+Pj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24g aXMgYXZhaWxhYmxlIGF0Og0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1k cmFmdC1pZXRmLWkycnMtcmliLWRhdGEtbW9kZWwtMDQNCj4+PiANCj4+PiANCj4+PiBQbGVhc2Ug bm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBv Zg0KPj4+c3VibWlzc2lvbg0KPj4+IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZm IGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+Pj4gDQo+Pj4gSW50ZXJuZXQtRHJh ZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPj4+IGZ0cDovL2Z0 cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+Pj4gDQo+Pj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBpMnJzIG1haWxpbmcgbGlzdA0KPj4+ IGkycnNAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2kycnMNCj4+DQo+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+PmkycnMgbWFpbGluZyBsaXN0DQo+PmkycnNAaWV0Zi5vcmcNCj4+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMnJzDQo+DQo+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj5pMnJzIG1haWxpbmcgbGlzdA0KPmkycnNAaWV0 Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2kycnMNCg== From nobody Mon Nov 23 14:33:44 2015 Return-Path: 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 5F4CD1ACE47 for ; Mon, 23 Nov 2015 14:33:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 DSYwjRZUmJCw for ; Mon, 23 Nov 2015 14:33:40 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC0CF1ACE42 for ; Mon, 23 Nov 2015 14:33:39 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.177; From: "Susan Hares" To: "'Jeff Tantsura'" , "'Acee Lindem \(acee\)'" , "'Mach Chen'" , References: <20151123071558.25655.92641.idtracker@ietfa.amsl.com> <8D628270-A455-4E01-881F-BA20D544228D@ericsson.com> In-Reply-To: <8D628270-A455-4E01-881F-BA20D544228D@ericsson.com> Date: Mon, 23 Nov 2015 17:33:22 -0500 Message-ID: <03cd01d1263e$f66a8960$e33f9c20$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03CE_01D12615.0D9A9BE0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLzNuIIn4QWw/Hs75J8GiGq3b7+uQJO1DWoAiHpGU0CXgkCw5wvh5tw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' , "'Benoit Claise \(bclaise\)'" , 'Alia Atlas' Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2015 22:33:42 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03CE_01D12615.0D9A9BE0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Jeff and Acee:=20 =20 Your suggested change goes against the WG adopted RIB Information draft = that has been discussed for over 2 years. The informational draft has = been through WG LC and you did not make any suggestions or comments = during the WG LC. Any change of this matter is not simply something you = indicate to the authors, but needs to be discussed on the WG as a = direction change for the RIB IM/DM models.=20 =20 Prior to moving this change through WG adoption cycle, the routing = architectural team needs to have: a) concrete proposal for the ephemeral = state that covers I2RS RIB and = https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ and b) = I requested this input of Acee Lindem as a representative of the routing = architecture team. =20 =20 I will be glad to work with you on a concrete proposal that you can send = to the email list and present at the I2RS interim meeting on 12/16/2015 = (10-11:30am ET).=20 =20 Sue Hares=20 =20 -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Jeff Tantsura Sent: Monday, November 23, 2015 4:27 PM To: Acee Lindem (acee); Mach Chen; i2rs@ietf.org Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.txt =20 Hi Mach, =20 I agree with Acee=E2=80=99s comments and would encourage you to use = generic/existing tunnel model(s), please see comments provided during = RTGWG meeting in Yokohama. There are already too many, we need to rationalize this work. =20 This is what has been discussed in Yokohama, Robin presented =20 -- draft-li-rtgwg-utunnel-yang -- draft-li-rtgwg-tunnel-policy-yang -- draft-wwz-netmod-yang-tunnel-cfg -- draft-zheng-intarea-gre-yang -- draft-liu-intarea-gre-tunnel-yang -- draft-liu-intarea-ipipv4-tunnel-yang =20 Cheers, Jeff =20 =20 =20 =20 =20 =20 On 11/23/15, 11:56, "i2rs on behalf of Acee Lindem (acee)" < = = i2rs-bounces@ietf.org on behalf of acee@cisco.com> wrote: =20 >Hi Mach, >=20 >I=E2=80=99m looking at draft-ietf-i2rs-rib-data-model-04.txt and it = still=20 >includes all the tunnel encaps. I know you received several comments=20 >that those should be in the tunnel model(s) and this I2RS RIB model=20 >should merely reference an imported tunnel abstraction. How are you=20 >going to address this? It seemed that the consensus (and an opinion=20 >that I share) was that this model should not attempt to generically=20 >created tunnels via RIB/FIB entries. >Thanks, >Acee >=20 >On 11/23/15, 2:23 AM, "i2rs on behalf of Mach Chen"=20 >< = = i2rs-bounces@ietf.org on behalf of mach.chen@huawei.com> wrote: >=20 >>Hi, >>=20 >>We just uploaded an update that addresses the comments received=20 >>(include online and offline) recently. Please review the draft and = comment! >>=20 >>Thanks, >>Mach >>=20 >>> -----Original Message----- >>> From: i2rs [ = mailto:i2rs-bounces@ietf.org] On Behalf Of=20 >>> internet-drafts@ietf.org >>> Sent: Monday, November 23, 2015 3:16 PM >>> To: i-d-announce@ietf.org >>> Cc: i2rs@ietf.org >>> Subject: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.txt >>>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts=20 >>>directories. >>> This draft is a work item of the Interface to the Routing System=20 >>>Working Group of the IETF. >>>=20 >>> Title : A YANG Data Model for Routing Information = Base >>> (RIB) >>> Authors : Lixing Wang >>> Hariharan Ananthakrishnan >>> Mach(Guoyi) Chen >>> Amit Dass >>> Sriganesh Kini >>> Nitin Bahadur >>> Filename : draft-ietf-i2rs-rib-data-model-04.txt >>> Pages : 65 >>> Date : 2015-11-22 >>>=20 >>> Abstract: >>> This document defines a YANG data model for Routing Information = Base >>> (RIB) that aligns with the I2RS RIB information model. >>>=20 >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> = https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/ >>>=20 >>> There's also a htmlized version available at: >>> = https://tools.ietf.org/html/draft-ietf-i2rs-rib-data-model-04 >>>=20 >>> A diff from the previous version is available at: >>> = = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2rs-rib-data-model-04 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of=20 >>>submission until the htmlized version and diff are available at=20 >>>tools.ietf.org. >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> = ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> = https://www.ietf.org/mailman/listinfo/i2rs >>=20 >>_______________________________________________ >>i2rs mailing list >> i2rs@ietf.org >> = https://www.ietf.org/mailman/listinfo/i2rs >=20 >_______________________________________________ >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 ------=_NextPart_000_03CE_01D12615.0D9A9BE0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Jeff = and Acee:

 

Your suggested change goes against the WG adopted = RIB Information draft that has been discussed for over 2 years. = =C2=A0The informational draft has been through WG LC and you did not = make any suggestions or comments during the WG LC. =C2=A0Any change of = this matter is not simply something you indicate to the authors, but = needs to be discussed on the WG as a direction change for the RIB IM/DM = models.

 

Prior to moving this change through WG adoption = cycle, the routing architectural team needs to have: a) concrete = proposal for the ephemeral state that covers I2RS RIB and = https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ = =C2=A0and =C2=A0b) I requested this input of Acee Lindem as a = representative of the routing architecture team. = =C2=A0=C2=A0=C2=A0

=C2=A0

I will = be glad to work with you on a concrete proposal that you can send to the = email list and present at the I2RS interim meeting on 12/16/2015 = (10-11:30am ET).

=C2=A0

=C2=A0Sue Hares

 

-----Original Message-----
From: i2rs = [mailto:i2rs-bounces@ietf.org] On Behalf Of Jeff Tantsura
Sent: = Monday, November 23, 2015 4:27 PM
To: Acee Lindem (acee); Mach Chen; = i2rs@ietf.org
Subject: Re: [i2rs] I-D Action: = draft-ietf-i2rs-rib-data-model-04.txt

 

Hi = Mach,

 

I agree with Acee=E2=80=99s comments and would = encourage you to use generic/existing tunnel model(s), please see = comments provided during RTGWG meeting in Yokohama.

There are already too many, we need to rationalize = this work.

 

This is what has been discussed in Yokohama, Robin = presented

 

-- draft-li-rtgwg-utunnel-yang

=C2=A0=C2=A0 -- = draft-li-rtgwg-tunnel-policy-yang

=C2=A0=C2=A0 -- = draft-wwz-netmod-yang-tunnel-cfg

=C2=A0=C2=A0 -- = draft-zheng-intarea-gre-yang

=C2=A0=C2=A0 -- = draft-liu-intarea-gre-tunnel-yang

=C2=A0=C2=A0 -- = draft-liu-intarea-ipipv4-tunnel-yang

 

Cheers,

Jeff

 

 

 

 

 

 

On = 11/23/15, 11:56, "i2rs on behalf of Acee Lindem (acee)" <i2rs-bounces@ietf.org on = behalf of acee@cisco.com> wrote:

 

>Hi = Mach,

> 

>I=E2=80=99m looking at = draft-ietf-i2rs-rib-data-model-04.txt and it still

>includes all the tunnel encaps. I know you = received several comments

>that those should be in the tunnel model(s) and = this I2RS RIB model

>should = merely reference an imported tunnel abstraction. How are you =

>going to address this? It = seemed that the consensus (and an opinion

>that I share) was that this model should not = attempt to generically

>created tunnels via RIB/FIB = entries.

>Thanks,

>Acee

> 

>On 11/23/15, 2:23 AM, "i2rs on behalf of = Mach Chen"

><i2rs-bounces@ietf.org on = behalf of mach.chen@huawei.com> wrote:

> 

>>Hi,

>> 

>>We just uploaded an update that addresses = the comments received

>>(include online and offline) recently. = Please review the draft and comment!

>> 

>>Thanks,

>>Mach

>> 

>>> -----Original = Message-----

>>> From: = i2rs [mailto:i2rs-bounces@ietf.= org] On Behalf Of

>>>internet-drafts@ietf.org<= /span>

>>> Sent: = Monday, November 23, 2015 3:16 PM

>>> To: i-d-announce@ietf.org

>>> Cc: i2rs@ietf.org<= o:p>

>>> Subject: [i2rs] I-D = Action: draft-ietf-i2rs-rib-data-model-04.txt

>>>

>>>

>>> A New Internet-Draft is available from = the on-line Internet-Drafts

>>>directories.

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

>>>Working Group=C2=A0 of the = IETF.

>>> =

>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Title=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = : A YANG Data Model for Routing Information Base

>>> (RIB)

>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Authors=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : Lixing = Wang

>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Hariharan = Ananthakrishnan

>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Mach(Guoyi) = Chen

>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Amit Dass

>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Sriganesh Kini

>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Nitin Bahadur

>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = Filename=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : = draft-ietf-i2rs-rib-data-model-04.txt

>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = Pages=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : = 65

>>> = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = Date=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : = 2015-11-22

>>> =

>>> = Abstract:

>>>=C2=A0=C2=A0=C2=A0 This document = defines a YANG data model for Routing Information Base

>>>=C2=A0=C2=A0=C2=A0 (RIB) that aligns = with the I2RS RIB information model.

>>>

>>>

>>>

>>> The IETF datatracker status page for = this draft is:

>>> https://datatracker.ietf.= org/doc/draft-ietf-i2rs-rib-data-model/

>>>

>>> There's also a htmlized version = available at:

>>> https://tools.ietf.org/ht= ml/draft-ietf-i2rs-rib-data-model-04

>>>

>>> A diff from the previous version is = available at:

>>> https://www.ietf.org/rfcd= iff?url2=3Ddraft-ietf-i2rs-rib-data-model-04

>>>

>>>

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

>>>submission=C2=A0 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/intern= et-drafts/

>>> =

>>> = _______________________________________________

>>> i2rs mailing list

>>> i2rs@ietf.org<= o:p>

>>> https://www.ietf.org/mail= man/listinfo/i2rs

>> 

>>____________________________________________= ___

>>i2rs mailing = list

>>i2rs@ietf.org<= o:p>

>>https://www.ietf.org/mail= man/listinfo/i2rs

> 

>_______________________________________________<= o:p>

>i2rs mailing = list

>i2rs@ietf.org<= o:p>

>https://www.ietf.org/mail= man/listinfo/i2rs

_______________________________________________=

i2rs mailing list

i2rs@ietf.org<= o:p>

https://www.ietf.org/mail= man/listinfo/i2rs

------=_NextPart_000_03CE_01D12615.0D9A9BE0-- From nobody Mon Nov 23 14:36:38 2015 Return-Path: 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 A9A4D1ACE4E for ; Mon, 23 Nov 2015 14:36:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.354 X-Spam-Level: X-Spam-Status: No, score=-96.354 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 JCdQXyzrPegK for ; Mon, 23 Nov 2015 14:36:36 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F96F1ACE4D for ; Mon, 23 Nov 2015 14:36:36 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.177; From: "Susan Hares" To: Date: Mon, 23 Nov 2015 17:36:32 -0500 Message-ID: <03da01d1263f$6723f560$356be020$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03DB_01D12615.7E4F7400" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdEmPhwDR/rZ48XvSfKyD94L9ZVPdQ== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' , 'Alia Atlas' Subject: [i2rs] proposed Interim X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2015 22:36:37 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03DB_01D12615.7E4F7400 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all: Here's the interims planned for I2RS before IETF 95 Date Proposed Topic ------ ------------------- 12/16 - Ephemeral State, Protocol Strawman, FB-RIB, Service Topology 01/13 - I2RS Protocol update, I2RS BGP, OSPF, ISIS Models 01/27 - I2RS protocol Update, TRILL, MPLS, BGP Extended Models 02/10 - I2RS protocol proposal 02/24 - I2RS Protocol Data Model 03/09 - I2RS Protocol and Data Models The meeting time of 10-11:30am ET on Wednesdays seems to work for Europe and all US time zones. The Asian time zones suffer with a late night meeting so I'd like to propose that on 4 of these meetings (12/16, 1/27, 2/24, and 3/9) that the chairs hold a second meeting at 10:00-11:30pm ET. I solicit your feedback on the interims schedule. Only the first interim (12/16/2015) topic is fixed to address issue brought up at the I2RS meeting in Yokohama. Sue Hares ------=_NextPart_000_03DB_01D12615.7E4F7400 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all: =

 

Here’s the interims planned for I2RS before IETF = 95

Date      Proposed Topic =

------       = -------------------

12/16 – = Ephemeral State, Protocol Strawman, FB-RIB, Service = Topology

01/13 - I2RS Protocol = update, I2RS BGP, OSPF, ISIS Models

01/27 - I2RS protocol Update, TRILL, MPLS, BGP = Extended Models

02/10 - I2RS protocol = proposal

02/24 - I2RS Protocol Data = Model

03/09 - I2RS Protocol and Data = Models

 

The meeting time of 10-11:30am ET on Wednesdays seems = to work for Europe and all US time zones.   The Asian time = zones suffer with a late night meeting so I’d like to propose that = on 4 of these meetings (12/16,  1/27, 2/24, and 3/9) that the = chairs hold a second meeting at 10:00-11:30pm ET. =  

 

I solicit your feedback on the interims schedule. =  Only the first interim (12/16/2015) topic is fixed to address = issue brought up at the I2RS meeting in Yokohama.

 

Sue Hares =

  

------=_NextPart_000_03DB_01D12615.7E4F7400-- From nobody Mon Nov 23 14:45:20 2015 Return-Path: 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 9296B1ACE8A for ; Mon, 23 Nov 2015 14:45:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 M4TCMjHp-zBu for ; Mon, 23 Nov 2015 14:45:16 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFABE1ACE86 for ; Mon, 23 Nov 2015 14:45:15 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.177; From: "Susan Hares" To: References: <20151123071558.25655.92641.idtracker@ietfa.amsl.com> <8D628270-A455-4E01-881F-BA20D544228D@ericsson.com> In-Reply-To: Date: Mon, 23 Nov 2015 17:45:12 -0500 Message-ID: <041001d12640$9d5104b0$d7f30e10$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0411_01D12616.B4811730" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLzNuIIn4QWw/Hs75J8GiGq3b7+uQJO1DWoAiHpGU0CXgkCwwFzieCSnCQA3rA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2015 22:45:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0411_01D12616.B4811730 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Resending to I2RS WG.=20 =20 From: Susan Hares [mailto:shares@ndzh.com]=20 Sent: Monday, November 23, 2015 5:33 PM To: 'Jeff Tantsura'; 'Acee Lindem (acee)'; 'Mach Chen'; 'i2rs@ietf.org' Cc: 'Jeffrey Haas'; 'Alia Atlas'; 'Benoit Claise (bclaise)' Subject: RE: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.txt =20 Jeff and Acee:=20 =20 Your suggested change goes against the WG adopted RIB Information draft = that has been discussed for over 2 years. The informational draft has = been through WG LC and you did not make any suggestions or comments = during the WG LC. Any change of this matter is not simply something you = indicate to the authors, but needs to be discussed on the WG as a = direction change for the RIB IM/DM models.=20 =20 Prior to moving this change through WG adoption cycle, the routing = architectural team needs to have: a) concrete proposal for the ephemeral = state that covers I2RS RIB and = https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ and b) = I requested this input of Acee Lindem as a representative of the routing = architecture team. =20 =20 I will be glad to work with you on a concrete proposal that you can send = to the email list and present at the I2RS interim meeting on 12/16/2015 = (10-11:30am ET).=20 =20 Sue Hares=20 =20 -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Jeff Tantsura Sent: Monday, November 23, 2015 4:27 PM To: Acee Lindem (acee); Mach Chen; i2rs@ietf.org Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.txt =20 Hi Mach, =20 I agree with Acee=E2=80=99s comments and would encourage you to use = generic/existing tunnel model(s), please see comments provided during = RTGWG meeting in Yokohama. There are already too many, we need to rationalize this work. =20 This is what has been discussed in Yokohama, Robin presented =20 -- draft-li-rtgwg-utunnel-yang -- draft-li-rtgwg-tunnel-policy-yang -- draft-wwz-netmod-yang-tunnel-cfg -- draft-zheng-intarea-gre-yang -- draft-liu-intarea-gre-tunnel-yang -- draft-liu-intarea-ipipv4-tunnel-yang =20 Cheers, Jeff =20 =20 =20 =20 =20 =20 On 11/23/15, 11:56, "i2rs on behalf of Acee Lindem (acee)" < = = i2rs-bounces@ietf.org on behalf of acee@cisco.com> wrote: =20 >Hi Mach, >=20 >I=E2=80=99m looking at draft-ietf-i2rs-rib-data-model-04.txt and it = still=20 >includes all the tunnel encaps. I know you received several comments=20 >that those should be in the tunnel model(s) and this I2RS RIB model=20 >should merely reference an imported tunnel abstraction. How are you=20 >going to address this? It seemed that the consensus (and an opinion=20 >that I share) was that this model should not attempt to generically=20 >created tunnels via RIB/FIB entries. >Thanks, >Acee >=20 >On 11/23/15, 2:23 AM, "i2rs on behalf of Mach Chen"=20 >< = = i2rs-bounces@ietf.org on behalf of mach.chen@huawei.com> wrote: >=20 >>Hi, >>=20 >>We just uploaded an update that addresses the comments received=20 >>(include online and offline) recently. Please review the draft and = comment! >>=20 >>Thanks, >>Mach >>=20 >>> -----Original Message----- >>> From: i2rs [ = mailto:i2rs-bounces@ietf.org] On Behalf Of=20 >>> internet-drafts@ietf.org >>> Sent: Monday, November 23, 2015 3:16 PM >>> To: i-d-announce@ietf.org >>> Cc: i2rs@ietf.org >>> Subject: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.txt >>>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts=20 >>>directories. >>> This draft is a work item of the Interface to the Routing System=20 >>>Working Group of the IETF. >>>=20 >>> Title : A YANG Data Model for Routing Information = Base >>> (RIB) >>> Authors : Lixing Wang >>> Hariharan Ananthakrishnan >>> Mach(Guoyi) Chen >>> Amit Dass >>> Sriganesh Kini >>> Nitin Bahadur >>> Filename : draft-ietf-i2rs-rib-data-model-04.txt >>> Pages : 65 >>> Date : 2015-11-22 >>>=20 >>> Abstract: >>> This document defines a YANG data model for Routing Information = Base >>> (RIB) that aligns with the I2RS RIB information model. >>>=20 >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> = https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/ >>>=20 >>> There's also a htmlized version available at: >>> = https://tools.ietf.org/html/draft-ietf-i2rs-rib-data-model-04 >>>=20 >>> A diff from the previous version is available at: >>> = = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2rs-rib-data-model-04 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of=20 >>>submission until the htmlized version and diff are available at=20 >>>tools.ietf.org. >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> = ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> = https://www.ietf.org/mailman/listinfo/i2rs >>=20 >>_______________________________________________ >>i2rs mailing list >> i2rs@ietf.org >> = https://www.ietf.org/mailman/listinfo/i2rs >=20 >_______________________________________________ >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 ------=_NextPart_000_0411_01D12616.B4811730 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Resending to I2RS WG.

 

From:= = Susan Hares [mailto:shares@ndzh.com]
Sent: Monday, November = 23, 2015 5:33 PM
To: 'Jeff Tantsura'; 'Acee Lindem (acee)'; = 'Mach Chen'; 'i2rs@ietf.org'
Cc: 'Jeffrey Haas'; 'Alia Atlas'; = 'Benoit Claise (bclaise)'
Subject: RE: [i2rs] I-D Action: = draft-ietf-i2rs-rib-data-model-04.txt

 

Jeff and = Acee:

 

Your suggested change goes against the WG adopted = RIB Information draft that has been discussed for over 2 years. =  The informational draft has been through WG LC and you did not = make any suggestions or comments during the WG LC.  Any change of = this matter is not simply something you indicate to the authors, but = needs to be discussed on the WG as a direction change for the RIB IM/DM = models.

 

Prior to moving this change through WG adoption = cycle, the routing architectural team needs to have: a) concrete = proposal for the ephemeral state that covers I2RS RIB and = https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ =  and  b) I requested this input of Acee Lindem as a = representative of the routing architecture team. =    

 

I will = be glad to work with you on a concrete proposal that you can send to the = email list and present at the I2RS interim meeting on 12/16/2015 = (10-11:30am ET).

 

 Sue Hares

 

-----Original Message-----
From: i2rs [mailto:i2rs-bounces@ietf.org] = On Behalf Of Jeff Tantsura
Sent: Monday, November 23, 2015 4:27 = PM
To: Acee Lindem (acee); Mach Chen; i2rs@ietf.org
Subject: Re: [i2rs] = I-D Action: draft-ietf-i2rs-rib-data-model-04.txt

 

Hi = Mach,

 

I agree with Acee=E2=80=99s comments and would = encourage you to use generic/existing tunnel model(s), please see = comments provided during RTGWG meeting in Yokohama.

There are already too many, we need to rationalize = this work.

 

This is what has been discussed in Yokohama, Robin = presented

 

-- draft-li-rtgwg-utunnel-yang

   -- = draft-li-rtgwg-tunnel-policy-yang

   -- = draft-wwz-netmod-yang-tunnel-cfg

   -- = draft-zheng-intarea-gre-yang

   -- = draft-liu-intarea-gre-tunnel-yang

   -- = draft-liu-intarea-ipipv4-tunnel-yang

 

Cheers,

Jeff

 

 

 

 

 

 

On = 11/23/15, 11:56, "i2rs on behalf of Acee Lindem (acee)" <i2rs-bounces@ietf.org on = behalf of acee@cisco.com> wrote:

 

>Hi = Mach,

> 

>I=E2=80=99m looking at = draft-ietf-i2rs-rib-data-model-04.txt and it still

>includes all the tunnel encaps. I know you = received several comments

>that those should be in the tunnel model(s) and = this I2RS RIB model

>should = merely reference an imported tunnel abstraction. How are you =

>going to address this? It = seemed that the consensus (and an opinion

>that I share) was that this model should not = attempt to generically

>created tunnels via RIB/FIB = entries.

>Thanks,

>Acee

> 

>On 11/23/15, 2:23 AM, "i2rs on behalf of = Mach Chen"

><i2rs-bounces@ietf.org on = behalf of mach.chen@huawei.com> wrote:

> 

>>Hi,

>> 

>>We just uploaded an update that addresses = the comments received

>>(include online and offline) recently. = Please review the draft and comment!

>> 

>>Thanks,

>>Mach

>> 

>>> -----Original = Message-----

>>> From: = i2rs [mailto:i2rs-bounces@ietf.= org] On Behalf Of

>>>internet-drafts@ietf.org<= /span>

>>> Sent: = Monday, November 23, 2015 3:16 PM

>>> To: i-d-announce@ietf.org

>>> Cc: i2rs@ietf.org<= o:p>

>>> Subject: [i2rs] I-D = Action: draft-ietf-i2rs-rib-data-model-04.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.

>>> =

>>>      &nbs= p;  = Title           : A = YANG Data Model for Routing Information Base

>>> (RIB)

>>>      &nbs= p;  Authors         : = Lixing Wang

>>>      &nbs= p;            = ;        Hariharan = Ananthakrishnan

>>>      &nbs= p;            = ;        Mach(Guoyi) = Chen

>>>      &nbs= p;            = ;        Amit Dass

>>>      &nbs= p;            = ;        Sriganesh = Kini

>>>      &nbs= p;            = ;        Nitin = Bahadur

>>> =        = Filename        : = draft-ietf-i2rs-rib-data-model-04.txt

>>>        = Pages           : = 65

>>> =        = Date            : = 2015-11-22

>>> =

>>> = Abstract:

>>>    This document = defines a YANG data model for Routing Information Base

>>>    (RIB) that aligns = with the I2RS RIB information model.

>>>

>>>

>>>

>>> The IETF datatracker status page for = this draft is:

>>> https://datatracker.ietf.= org/doc/draft-ietf-i2rs-rib-data-model/

>>>

>>> There's also a htmlized version = available at:

>>> https://tools.ietf.org/ht= ml/draft-ietf-i2rs-rib-data-model-04

>>>

>>> A diff from the previous version is = available at:

>>> https://www.ietf.org/rfcd= iff?url2=3Ddraft-ietf-i2rs-rib-data-model-04

>>>

>>>

>>> 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/intern= et-drafts/

>>> =

>>> = _______________________________________________

>>> i2rs mailing list

>>> i2rs@ietf.org<= o:p>

>>> https://www.ietf.org/mail= man/listinfo/i2rs

>> 

>>____________________________________________= ___

>>i2rs mailing = list

>>i2rs@ietf.org<= o:p>

>>https://www.ietf.org/mail= man/listinfo/i2rs

> 

>_______________________________________________<= o:p>

>i2rs mailing = list

>i2rs@ietf.org<= o:p>

>https://www.ietf.org/mail= man/listinfo/i2rs

_______________________________________________=

i2rs mailing list

i2rs@ietf.org<= o:p>

https://www.ietf.org/mail= man/listinfo/i2rs

------=_NextPart_000_0411_01D12616.B4811730-- From nobody Mon Nov 23 16:29:53 2015 Return-Path: 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 03F4F1B2A14 for ; Mon, 23 Nov 2015 16:29:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.085 X-Spam-Level: X-Spam-Status: No, score=-15.085 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 59OM8zWypaPa for ; Mon, 23 Nov 2015 16:29:48 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FC201B2A12 for ; Mon, 23 Nov 2015 16:29:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=39601; q=dns/txt; s=iport; t=1448324988; x=1449534588; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=AuJV/FlD/vVXQeSJ8GhKE0yj2a+OWQXTxfq0IK9iDHQ=; b=Iw9ZhiN0f/UK9RVi9MSdWinQyc/GoBjeTXHPsc8585iBmRfO7ksC58qk JV4i2/prVQjUw1qeG+NkKD/Y3bCTLmUupgbAompEq4i5AeLQFo/FZggfs yfmHKEom7UGXex8T1mmLwU3gSzHhwGYdgRxxogUfr8xCW3JNq22gg8gbl U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D/AQBorlNW/5tdJa1egm5NU28GvxgBD?= =?us-ascii?q?YFiAxcBCYVuAhyBLTgUAQEBAQEBAYEKhDQBAQEDAQEBASAKQRcEAgEIDgMBAgE?= =?us-ascii?q?BASEBBgMCAgIlCxQDBQEIAgQBEogmCA2uY5AwAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBGItShCoRATUKDQmCZIFEBZJrg2UBhSOIDYFbSYN3hzWGJoRjg3EBHwEBQoI?= =?us-ascii?q?RHYFWcgGDaTqBBwEBAQ?= X-IronPort-AV: E=Sophos; i="5.20,338,1444694400"; d="scan'208,217"; a="49616390" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Nov 2015 00:29:47 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id tAO0TlpN004336 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 24 Nov 2015 00:29:47 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 23 Nov 2015 19:29:46 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.000; Mon, 23 Nov 2015 19:29:45 -0500 From: "Acee Lindem (acee)" To: Susan Hares , "i2rs@ietf.org" Thread-Topic: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt Thread-Index: AQHRJkCnXerbjrqsRkCeqqFxylBayJ6qUewA Date: Tue, 24 Nov 2015 00:29:45 +0000 Message-ID: References: <20151123071558.25655.92641.idtracker@ietfa.amsl.com> <8D628270-A455-4E01-881F-BA20D544228D@ericsson.com> <041001d12640$9d5104b0$d7f30e10$@ndzh.com> In-Reply-To: <041001d12640$9d5104b0$d7f30e10$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: multipart/alternative; boundary="_000_D27916203EEF3aceeciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 00:29:52 -0000 --_000_D27916203EEF3aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VlLA0KDQpGcm9tOiBpMnJzIDxpMnJzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmkycnMtYm91 bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBTdXNhbiBIYXJlcyA8c2hhcmVzQG5kemguY29t PG1haWx0bzpzaGFyZXNAbmR6aC5jb20+Pg0KRGF0ZTogTW9uZGF5LCBOb3ZlbWJlciAyMywgMjAx NSBhdCA1OjQ1IFBNDQpUbzogImkycnNAaWV0Zi5vcmc8bWFpbHRvOmkycnNAaWV0Zi5vcmc+IiA8 aTJyc0BpZXRmLm9yZzxtYWlsdG86aTJyc0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBbaTJyc10gRlc6 IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtaTJycy1yaWItZGF0YS1tb2RlbC0wNC50eHQNCg0KUmVz ZW5kaW5nIHRvIEkyUlMgV0cuDQoNCkZyb206IFN1c2FuIEhhcmVzIFttYWlsdG86c2hhcmVzQG5k emguY29tXQ0KU2VudDogTW9uZGF5LCBOb3ZlbWJlciAyMywgMjAxNSA1OjMzIFBNDQpUbzogJ0pl ZmYgVGFudHN1cmEnOyAnQWNlZSBMaW5kZW0gKGFjZWUpJzsgJ01hY2ggQ2hlbic7ICdpMnJzQGll dGYub3JnPG1haWx0bzonaTJyc0BpZXRmLm9yZz4nDQpDYzogJ0plZmZyZXkgSGFhcyc7ICdBbGlh IEF0bGFzJzsgJ0Jlbm9pdCBDbGFpc2UgKGJjbGFpc2UpJw0KU3ViamVjdDogUkU6IFtpMnJzXSBJ LUQgQWN0aW9uOiBkcmFmdC1pZXRmLWkycnMtcmliLWRhdGEtbW9kZWwtMDQudHh0DQoNCg0KSmVm ZiBhbmQgQWNlZToNCg0KDQoNCllvdXIgc3VnZ2VzdGVkIGNoYW5nZSBnb2VzIGFnYWluc3QgdGhl IFdHIGFkb3B0ZWQgUklCIEluZm9ybWF0aW9uIGRyYWZ0IHRoYXQgaGFzIGJlZW4gZGlzY3Vzc2Vk IGZvciBvdmVyIDIgeWVhcnMuICBUaGUgaW5mb3JtYXRpb25hbCBkcmFmdCBoYXMgYmVlbiB0aHJv dWdoIFdHIExDIGFuZCB5b3UgZGlkIG5vdCBtYWtlIGFueSBzdWdnZXN0aW9ucyBvciBjb21tZW50 cyBkdXJpbmcgdGhlIFdHIExDLiAgQW55IGNoYW5nZSBvZiB0aGlzIG1hdHRlciBpcyBub3Qgc2lt cGx5IHNvbWV0aGluZyB5b3UgaW5kaWNhdGUgdG8gdGhlIGF1dGhvcnMsIGJ1dCBuZWVkcyB0byBi ZSBkaXNjdXNzZWQgb24gdGhlIFdHIGFzIGEgZGlyZWN0aW9uIGNoYW5nZSBmb3IgdGhlIFJJQiBJ TS9ETSBtb2RlbHMuDQoNCkluZGVwZW5kZW50IG9mIHRoZSBJMlJTIGVmZm9ydHMsIG1pbGVzdG9u ZXMsIGFuZCBwcm9jZXNzZXMsIEkgdGhpbmsgd2UgbmVlZCB0byBhZGRyZXNzIHdoZXRoZXIgcHJv dmlzaW9uaW5nIGFsbCB0aGVzZSB0dW5uZWxzIHZpYSBSSUIgaW5zdGFsbGF0aW9uIGlzICBhcHBy b3ByaWF0ZSBhbmQsIGFkZGl0aW9uYWxseSwgY29uc2lzdGVudCB3aXRoIG90aGVyIFdHIFlBTkcg bW9kZWxzLiBJbiBtYW55IGNhc2VzLCBpdCB3b3VsZCBzZWVtIHRoZXJlIGFyZSB0dW5uZWwgYXR0 cmlidXRlcyBvdGhlciB0aGFuIHRoZSBlbmNhcHMgdGhhdCBuZWVkIHRvIGJlIHByb3Zpc2lvbmVk LiBBdCBhIG1pbmltdW0sIEkgdGhpbmsgeW914oCZZCBuZWVkIHRvIGVpdGhlciByZWZlcmVuY2Ug YW4gUkZDIGRlc2NyaWJpbmcgc29mdCB0dW5uZWwgcHJvdmlzaW9uaW5nIG9yIGRlc2NyaWJlIHRo ZSBzcGVjaWZpY3Mgb2YgdGhpcyBwcm92aXNpb25pbmcuDQoNCg0KDQoNClByaW9yIHRvIG1vdmlu ZyB0aGlzIGNoYW5nZSB0aHJvdWdoIFdHIGFkb3B0aW9uIGN5Y2xlLCB0aGUgcm91dGluZyBhcmNo aXRlY3R1cmFsIHRlYW0gbmVlZHMgdG8gaGF2ZTogYSkgY29uY3JldGUgcHJvcG9zYWwgZm9yIHRo ZSBlcGhlbWVyYWwgc3RhdGUgdGhhdCBjb3ZlcnMgSTJSUyBSSUIgYW5kIGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0bW9kLXJvdXRpbmctY2ZnLyAgYW5kICBi KSBJIHJlcXVlc3RlZCB0aGlzIGlucHV0IG9mIEFjZWUgTGluZGVtIGFzIGEgcmVwcmVzZW50YXRp dmUgb2YgdGhlIHJvdXRpbmcgYXJjaGl0ZWN0dXJlIHRlYW0uDQoNClRoZSAgaWRlbnRpZmljYXRp b24gb2YgdGhpcyBwcm9ibGVtIHdpdGggdHVubmVsIHByb3Zpc2lvbmluZyBpcyBhIGRpcmVjdCBv dXRjb21lIG9mIHRoaXMgZWZmb3J0Lg0KDQoNCg0KDQoNCg0KSSB3aWxsIGJlIGdsYWQgdG8gd29y ayB3aXRoIHlvdSBvbiBhIGNvbmNyZXRlIHByb3Bvc2FsIHRoYXQgeW91IGNhbiBzZW5kIHRvIHRo ZSBlbWFpbCBsaXN0IGFuZCBwcmVzZW50IGF0IHRoZSBJMlJTIGludGVyaW0gbWVldGluZyBvbiAx Mi8xNi8yMDE1ICgxMC0xMTozMGFtIEVUKS4NCg0KSSB3aWxsIGNvbnRpbnVlIHRvIHdvcmsgb24g aWV0Zi1yb3V0aW5nIGFsaWdubWVudCBidXQgZG9u4oCZdCBoYXZlIHRoZSBiYW5kd2lkdGggZm9y IHRoZSBhYm92ZS4NCg0KQWNlZQ0KDQoNCg0KDQoNCg0KDQogU3VlIEhhcmVzDQoNCg0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaTJycyBbbWFpbHRvOmkycnMtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIEplZmYgVGFudHN1cmENClNlbnQ6IE1vbmRheSwgTm92ZW1i ZXIgMjMsIDIwMTUgNDoyNyBQTQ0KVG86IEFjZWUgTGluZGVtIChhY2VlKTsgTWFjaCBDaGVuOyBp MnJzQGlldGYub3JnPG1haWx0bzppMnJzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtpMnJzXSBJ LUQgQWN0aW9uOiBkcmFmdC1pZXRmLWkycnMtcmliLWRhdGEtbW9kZWwtMDQudHh0DQoNCg0KDQpI aSBNYWNoLA0KDQoNCg0KSSBhZ3JlZSB3aXRoIEFjZWXigJlzIGNvbW1lbnRzIGFuZCB3b3VsZCBl bmNvdXJhZ2UgeW91IHRvIHVzZSBnZW5lcmljL2V4aXN0aW5nIHR1bm5lbCBtb2RlbChzKSwgcGxl YXNlIHNlZSBjb21tZW50cyBwcm92aWRlZCBkdXJpbmcgUlRHV0cgbWVldGluZyBpbiBZb2tvaGFt YS4NCg0KVGhlcmUgYXJlIGFscmVhZHkgdG9vIG1hbnksIHdlIG5lZWQgdG8gcmF0aW9uYWxpemUg dGhpcyB3b3JrLg0KDQoNCg0KVGhpcyBpcyB3aGF0IGhhcyBiZWVuIGRpc2N1c3NlZCBpbiBZb2tv aGFtYSwgUm9iaW4gcHJlc2VudGVkDQoNCg0KDQotLSBkcmFmdC1saS1ydGd3Zy11dHVubmVsLXlh bmcNCg0KICAgLS0gZHJhZnQtbGktcnRnd2ctdHVubmVsLXBvbGljeS15YW5nDQoNCiAgIC0tIGRy YWZ0LXd3ei1uZXRtb2QteWFuZy10dW5uZWwtY2ZnDQoNCiAgIC0tIGRyYWZ0LXpoZW5nLWludGFy ZWEtZ3JlLXlhbmcNCg0KICAgLS0gZHJhZnQtbGl1LWludGFyZWEtZ3JlLXR1bm5lbC15YW5nDQoN CiAgIC0tIGRyYWZ0LWxpdS1pbnRhcmVhLWlwaXB2NC10dW5uZWwteWFuZw0KDQoNCg0KQ2hlZXJz LA0KDQpKZWZmDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCk9uIDExLzIzLzE1LCAxMTo1Niwg ImkycnMgb24gYmVoYWxmIG9mIEFjZWUgTGluZGVtIChhY2VlKSIgPGkycnMtYm91bmNlc0BpZXRm Lm9yZyBvbiBiZWhhbGYgb2YgYWNlZUBjaXNjby5jb208bWFpbHRvOmkycnMtYm91bmNlc0BpZXRm Lm9yZyUyMG9uJTIwYmVoYWxmJTIwb2YlMjBhY2VlQGNpc2NvLmNvbT4+IHdyb3RlOg0KDQoNCg0K PkhpIE1hY2gsDQoNCj4NCg0KPknigJltIGxvb2tpbmcgYXQgZHJhZnQtaWV0Zi1pMnJzLXJpYi1k YXRhLW1vZGVsLTA0LnR4dCBhbmQgaXQgc3RpbGwNCg0KPmluY2x1ZGVzIGFsbCB0aGUgdHVubmVs IGVuY2Fwcy4gSSBrbm93IHlvdSByZWNlaXZlZCBzZXZlcmFsIGNvbW1lbnRzDQoNCj50aGF0IHRo b3NlIHNob3VsZCBiZSBpbiB0aGUgdHVubmVsIG1vZGVsKHMpIGFuZCB0aGlzIEkyUlMgUklCIG1v ZGVsDQoNCj5zaG91bGQgbWVyZWx5IHJlZmVyZW5jZSBhbiBpbXBvcnRlZCB0dW5uZWwgYWJzdHJh Y3Rpb24uIEhvdyBhcmUgeW91DQoNCj5nb2luZyB0byBhZGRyZXNzIHRoaXM/IEl0IHNlZW1lZCB0 aGF0IHRoZSBjb25zZW5zdXMgKGFuZCBhbiBvcGluaW9uDQoNCj50aGF0IEkgc2hhcmUpIHdhcyB0 aGF0IHRoaXMgbW9kZWwgc2hvdWxkIG5vdCBhdHRlbXB0IHRvIGdlbmVyaWNhbGx5DQoNCj5jcmVh dGVkIHR1bm5lbHMgdmlhIFJJQi9GSUIgZW50cmllcy4NCg0KPlRoYW5rcywNCg0KPkFjZWUNCg0K Pg0KDQo+T24gMTEvMjMvMTUsIDI6MjMgQU0sICJpMnJzIG9uIGJlaGFsZiBvZiBNYWNoIENoZW4i DQoNCj48aTJycy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBtYWNoLmNoZW5AaHVhd2Vp LmNvbTxtYWlsdG86aTJycy1ib3VuY2VzQGlldGYub3JnJTIwb24lMjBiZWhhbGYlMjBvZiUyMG1h Y2guY2hlbkBodWF3ZWkuY29tPj4gd3JvdGU6DQoNCj4NCg0KPj5IaSwNCg0KPj4NCg0KPj5XZSBq dXN0IHVwbG9hZGVkIGFuIHVwZGF0ZSB0aGF0IGFkZHJlc3NlcyB0aGUgY29tbWVudHMgcmVjZWl2 ZWQNCg0KPj4oaW5jbHVkZSBvbmxpbmUgYW5kIG9mZmxpbmUpIHJlY2VudGx5LiBQbGVhc2UgcmV2 aWV3IHRoZSBkcmFmdCBhbmQgY29tbWVudCENCg0KPj4NCg0KPj5UaGFua3MsDQoNCj4+TWFjaA0K DQo+Pg0KDQo+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KPj4+IEZyb206IGkycnMg W21haWx0bzppMnJzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KDQo+Pj5pbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCg0KPj4+ IFNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMjMsIDIwMTUgMzoxNiBQTQ0KDQo+Pj4gVG86IGktZC1h bm5vdW5jZUBpZXRmLm9yZzxtYWlsdG86aS1kLWFubm91bmNlQGlldGYub3JnPg0KDQo+Pj4gQ2M6 IGkycnNAaWV0Zi5vcmc8bWFpbHRvOmkycnNAaWV0Zi5vcmc+DQoNCj4+PiBTdWJqZWN0OiBbaTJy c10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1pMnJzLXJpYi1kYXRhLW1vZGVsLTA0LnR4dA0KDQo+ Pj4NCg0KPj4+DQoNCj4+PiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0 aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMNCg0KPj4+ZGlyZWN0b3JpZXMuDQoNCj4+PiAgVGhp cyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgSW50ZXJmYWNlIHRvIHRoZSBSb3V0aW5nIFN5 c3RlbQ0KDQo+Pj5Xb3JraW5nIEdyb3VwICBvZiB0aGUgSUVURi4NCg0KPj4+DQoNCj4+PiAgICAg ICAgIFRpdGxlICAgICAgICAgICA6IEEgWUFORyBEYXRhIE1vZGVsIGZvciBSb3V0aW5nIEluZm9y bWF0aW9uIEJhc2UNCg0KPj4+IChSSUIpDQoNCj4+PiAgICAgICAgIEF1dGhvcnMgICAgICAgICA6 IExpeGluZyBXYW5nDQoNCj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgIEhhcmloYXJhbiBB bmFudGhha3Jpc2huYW4NCg0KPj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgTWFjaChHdW95 aSkgQ2hlbg0KDQo+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICBBbWl0IERhc3MNCg0KPj4+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgU3JpZ2FuZXNoIEtpbmkNCg0KPj4+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgTml0aW4gQmFoYWR1cg0KDQo+Pj4gICAgICAgIEZpbGVuYW1lICAg ICAgICA6IGRyYWZ0LWlldGYtaTJycy1yaWItZGF0YS1tb2RlbC0wNC50eHQNCg0KPj4+ICAgICAg ICBQYWdlcyAgICAgICAgICAgOiA2NQ0KDQo+Pj4gICAgICAgIERhdGUgICAgICAgICAgICA6IDIw MTUtMTEtMjINCg0KPj4+DQoNCj4+PiBBYnN0cmFjdDoNCg0KPj4+ICAgIFRoaXMgZG9jdW1lbnQg ZGVmaW5lcyBhIFlBTkcgZGF0YSBtb2RlbCBmb3IgUm91dGluZyBJbmZvcm1hdGlvbiBCYXNlDQoN Cj4+PiAgICAoUklCKSB0aGF0IGFsaWducyB3aXRoIHRoZSBJMlJTIFJJQiBpbmZvcm1hdGlvbiBt b2RlbC4NCg0KPj4+DQoNCj4+Pg0KDQo+Pj4NCg0KPj4+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0 YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KDQo+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJzLXJpYi1kYXRhLW1vZGVsLw0KDQo+Pj4NCg0KPj4+ IFRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KDQo+Pj4gaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaTJycy1yaWItZGF0YS1tb2RlbC0w NA0KDQo+Pj4NCg0KPj4+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWls YWJsZSBhdDoNCg0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1p ZXRmLWkycnMtcmliLWRhdGEtbW9kZWwtMDQNCg0KPj4+DQoNCj4+Pg0KDQo+Pj4gUGxlYXNlIG5v dGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YN Cg0KPj4+c3VibWlzc2lvbiAgdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJl IGF2YWlsYWJsZSBhdA0KDQo+Pj50b29scy5pZXRmLm9yZy4NCg0KPj4+DQoNCj4+PiBJbnRlcm5l dC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQoNCj4+PiBm dHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KDQo+Pj4NCg0KPj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCj4+PiBpMnJzIG1haWxp bmcgbGlzdA0KDQo+Pj4gaTJyc0BpZXRmLm9yZzxtYWlsdG86aTJyc0BpZXRmLm9yZz4NCg0KPj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJycw0KDQo+Pg0KDQo+Pl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCj4+aTJycyBt YWlsaW5nIGxpc3QNCg0KPj5pMnJzQGlldGYub3JnPG1haWx0bzppMnJzQGlldGYub3JnPg0KDQo+ Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJycw0KDQo+DQoNCj5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQo+aTJycyBtYWls aW5nIGxpc3QNCg0KPmkycnNAaWV0Zi5vcmc8bWFpbHRvOmkycnNAaWV0Zi5vcmc+DQoNCj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2kycnMNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KaTJycyBtYWlsaW5nIGxpc3QNCg0K aTJyc0BpZXRmLm9yZzxtYWlsdG86aTJyc0BpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pMnJzDQo= --_000_D27916203EEF3aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <472CD4AD153AA4428102E4BF3FBB5747@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5TdWUsJm5ic3A7 PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9O Ij4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0ZXh0 LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9S REVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6 IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsg Qk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHls ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPmkycnMgJmx0OzxhIGhyZWY9Im1haWx0 bzppMnJzLWJvdW5jZXNAaWV0Zi5vcmciPmkycnMtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9u IGJlaGFsZiBvZiBTdXNhbiBIYXJlcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNoYXJlc0BuZHpoLmNv bSI+c2hhcmVzQG5kemguY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6 Ym9sZCI+RGF0ZTogPC9zcGFuPk1vbmRheSwgTm92ZW1iZXIgMjMsIDIwMTUgYXQgNTo0NSBQTTxi cj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPiZxdW90OzxhIGhy ZWY9Im1haWx0bzppMnJzQGlldGYub3JnIj5pMnJzQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEg aHJlZj0ibWFpbHRvOmkycnNAaWV0Zi5vcmciPmkycnNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxz cGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+W2kycnNdIEZXOiBJ LUQgQWN0aW9uOiBkcmFmdC1pZXRmLWkycnMtcmliLWRhdGEtbW9kZWwtMDQudHh0PGJyPg0KPC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJ QlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQ QURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2IHhtbG5zOnY9InVybjpzY2hl bWFzLW1pY3Jvc29mdC1jb206dm1sIiB4bWxuczpvPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29t Om9mZmljZTpvZmZpY2UiIHhtbG5zOnc9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNl OndvcmQiIHhtbG5zOng9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmV4Y2VsIiB4 bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwi IHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxtZXRhIG5hbWU9Ikdl bmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0K PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAy IDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6 MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9y bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAu TXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1h cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1z b0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwi c2Fucy1zZXJpZiI7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFp biBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi UGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFu LkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0K CW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsN Cglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjEN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjxkaXYg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj5SZXNlbmRpbmcgdG8gSTJSUyBXRy4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWls eTogVGFob21hLCBzYW5zLXNlcmlmOyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7Ij4gU3VzYW4gSGFy ZXMgWzxhIGhyZWY9Im1haWx0bzpzaGFyZXNAbmR6aC5jb20iPm1haWx0bzpzaGFyZXNAbmR6aC5j b208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgTm92ZW1iZXIgMjMsIDIwMTUgNToz MyBQTTxicj4NCjxiPlRvOjwvYj4gJ0plZmYgVGFudHN1cmEnOyAnQWNlZSBMaW5kZW0gKGFjZWUp JzsgJ01hY2ggQ2hlbic7IDxhIGhyZWY9Im1haWx0bzonaTJyc0BpZXRmLm9yZyI+DQonaTJyc0Bp ZXRmLm9yZzwvYT4nPGJyPg0KPGI+Q2M6PC9iPiAnSmVmZnJleSBIYWFzJzsgJ0FsaWEgQXRsYXMn OyAnQmVub2l0IENsYWlzZSAoYmNsYWlzZSknPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbaTJy c10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1pMnJzLXJpYi1kYXRhLW1vZGVsLTA0LnR4dDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkplZmYgYW5kIEFj ZWU6IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Zb3VyIHN1Z2dlc3RlZCBjaGFuZ2Ug Z29lcyBhZ2FpbnN0IHRoZSBXRyBhZG9wdGVkIFJJQiBJbmZvcm1hdGlvbiBkcmFmdCB0aGF0IGhh cyBiZWVuIGRpc2N1c3NlZCBmb3Igb3ZlciAyIHllYXJzLiAmbmJzcDtUaGUgaW5mb3JtYXRpb25h bCBkcmFmdCBoYXMgYmVlbiB0aHJvdWdoIFdHIExDIGFuZCB5b3UgZGlkIG5vdCBtYWtlIGFueSBz dWdnZXN0aW9ucyBvciBjb21tZW50cyBkdXJpbmcgdGhlIFdHIExDLiAmbmJzcDtBbnkNCiBjaGFu Z2Ugb2YgdGhpcyBtYXR0ZXIgaXMgbm90IHNpbXBseSBzb21ldGhpbmcgeW91IGluZGljYXRlIHRv IHRoZSBhdXRob3JzLCBidXQgbmVlZHMgdG8gYmUgZGlzY3Vzc2VkIG9uIHRoZSBXRyBhcyBhIGRp cmVjdGlvbiBjaGFuZ2UgZm9yIHRoZSBSSUIgSU0vRE0gbW9kZWxzLjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2PkluZGVwZW5kZW50IG9mIHRoZSBJMlJTIGVmZm9ydHMsIG1pbGVzdG9uZXMsIGFuZCBwcm9j ZXNzZXMsIEkgdGhpbmsgd2UgbmVlZCB0byBhZGRyZXNzIHdoZXRoZXIgcHJvdmlzaW9uaW5nIGFs bCB0aGVzZSB0dW5uZWxzIHZpYSBSSUIgaW5zdGFsbGF0aW9uIGlzICZuYnNwO2FwcHJvcHJpYXRl IGFuZCwgYWRkaXRpb25hbGx5LCBjb25zaXN0ZW50IHdpdGggb3RoZXIgV0cgWUFORyBtb2RlbHMu IEluIG1hbnkgY2FzZXMsIGl0IHdvdWxkIHNlZW0gdGhlcmUNCiBhcmUgdHVubmVsIGF0dHJpYnV0 ZXMgb3RoZXIgdGhhbiB0aGUgZW5jYXBzIHRoYXQgbmVlZCB0byBiZSBwcm92aXNpb25lZC4gQXQg YSBtaW5pbXVtLCBJIHRoaW5rIHlvdeKAmWQgbmVlZCB0byBlaXRoZXIgcmVmZXJlbmNlIGFuIFJG QyBkZXNjcmliaW5nIHNvZnQgdHVubmVsIHByb3Zpc2lvbmluZyBvciBkZXNjcmliZSB0aGUgc3Bl Y2lmaWNzIG9mIHRoaXMgcHJvdmlzaW9uaW5nLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8YmxvY2txdW90ZSBpZD0iTUFD X09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVj NGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXYgeG1s bnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVybjpzY2hlbWFz LW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpv ZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vb2ZmaWNl LzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0K PGRpdiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPlByaW9yIHRvIG1vdmluZyB0aGlzIGNoYW5nZSB0aHJvdWdoIFdHIGFk b3B0aW9uIGN5Y2xlLCB0aGUgcm91dGluZyBhcmNoaXRlY3R1cmFsIHRlYW0gbmVlZHMgdG8gaGF2 ZTogYSkgY29uY3JldGUgcHJvcG9zYWwgZm9yIHRoZSBlcGhlbWVyYWwgc3RhdGUgdGhhdCBjb3Zl cnMgSTJSUyBSSUIgYW5kDQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLW5ldG1vZC1yb3V0aW5nLWNmZy8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0bW9kLXJvdXRpbmctY2ZnLzwvYT4gJm5ic3A7YW5kICZu YnNwO2IpIEkgcmVxdWVzdGVkIHRoaXMgaW5wdXQgb2YgQWNlZSBMaW5kZW0gYXMgYSByZXByZXNl bnRhdGl2ZSBvZiB0aGUgcm91dGluZyBhcmNoaXRlY3R1cmUgdGVhbS4gJm5ic3A7Jm5ic3A7PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxkaXY+VGhlICZuYnNwO2lkZW50aWZpY2F0aW9uIG9mIHRoaXMgcHJvYmxl bSB3aXRoIHR1bm5lbCBwcm92aXNpb25pbmcgaXMgYSBkaXJlY3Qgb3V0Y29tZSBvZiB0aGlzIGVm Zm9ydC4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19C T0RZX1NFQ1RJT04iPg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JM T0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAg MCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2IHhtbG5zOnY9InVybjpzY2hlbWFzLW1pY3Jv c29mdC1jb206dm1sIiB4bWxuczpvPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpv ZmZpY2UiIHhtbG5zOnc9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOndvcmQiIHht bG5zOng9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmV4Y2VsIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxkaXYgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5J IHdpbGwgYmUgZ2xhZCB0byB3b3JrIHdpdGggeW91IG9uIGEgY29uY3JldGUgcHJvcG9zYWwgdGhh dCB5b3UgY2FuIHNlbmQgdG8gdGhlIGVtYWlsIGxpc3QgYW5kIHByZXNlbnQgYXQgdGhlIEkyUlMg aW50ZXJpbSBtZWV0aW5nIG9uIDEyLzE2LzIwMTUgKDEwLTExOjMwYW0gRVQpLjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8ZGl2Pkkgd2lsbCBjb250aW51ZSB0byB3b3JrIG9uIGlldGYtcm91dGluZyBhbGlnbm1l bnQgYnV0IGRvbuKAmXQgaGF2ZSB0aGUgYmFuZHdpZHRoIGZvciB0aGUgYWJvdmUuJm5ic3A7PC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5BY2VlJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxibG9ja3F1b3RlIGlk PSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6 ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRp diB4bWxuczp2PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOnZtbCIgeG1sbnM6bz0idXJuOnNj aGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4bWxuczp3PSJ1cm46c2NoZW1hcy1t aWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczp4PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQt Y29tOm9mZmljZTpleGNlbCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9v ZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0 MCI+DQo8ZGl2IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7U3VlIEhhcmVzIDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IGkycnMgWzxh IGhyZWY9Im1haWx0bzppMnJzLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzppMnJzLWJvdW5jZXNA aWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgSmVmZiBUYW50c3VyYTxicj4NClNlbnQ6IE1vbmRh eSwgTm92ZW1iZXIgMjMsIDIwMTUgNDoyNyBQTTxicj4NClRvOiBBY2VlIExpbmRlbSAoYWNlZSk7 IE1hY2ggQ2hlbjsgPGEgaHJlZj0ibWFpbHRvOmkycnNAaWV0Zi5vcmciPmkycnNAaWV0Zi5vcmc8 L2E+PGJyPg0KU3ViamVjdDogUmU6IFtpMnJzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWkycnMt cmliLWRhdGEtbW9kZWwtMDQudHh0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkhpIE1h Y2gsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkkgYWdyZWUgd2l0aCBBY2Vl4oCZcyBj b21tZW50cyBhbmQgd291bGQgZW5jb3VyYWdlIHlvdSB0byB1c2UgZ2VuZXJpYy9leGlzdGluZyB0 dW5uZWwgbW9kZWwocyksIHBsZWFzZSBzZWUgY29tbWVudHMgcHJvdmlkZWQgZHVyaW5nIFJUR1dH IG1lZXRpbmcgaW4gWW9rb2hhbWEuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij5UaGVyZSBhcmUgYWxyZWFkeSB0b28gbWFueSwgd2UgbmVlZCB0byByYXRpb25hbGl6ZSB0 aGlzIHdvcmsuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoaXMgaXMgd2hhdCBoYXMg YmVlbiBkaXNjdXNzZWQgaW4gWW9rb2hhbWEsIFJvYmluIHByZXNlbnRlZDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4tLSBkcmFmdC1saS1ydGd3Zy11dHVubmVsLXlhbmc8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyAtLSBkcmFmdC1saS1y dGd3Zy10dW5uZWwtcG9saWN5LXlhbmc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOyZuYnNwOyAtLSBkcmFmdC13d3otbmV0bW9kLXlhbmctdHVubmVsLWNmZzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IC0tIGRy YWZ0LXpoZW5nLWludGFyZWEtZ3JlLXlhbmc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOyZuYnNwOyAtLSBkcmFmdC1saXUtaW50YXJlYS1ncmUtdHVubmVsLXlh bmc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyAt LSBkcmFmdC1saXUtaW50YXJlYS1pcGlwdjQtdHVubmVsLXlhbmc8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+SmVmZjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+T24gMTEvMjMvMTUs IDExOjU2LCAmcXVvdDtpMnJzIG9uIGJlaGFsZiBvZiBBY2VlIExpbmRlbSAoYWNlZSkmcXVvdDsg Jmx0OzxhIGhyZWY9Im1haWx0bzppMnJzLWJvdW5jZXNAaWV0Zi5vcmclMjBvbiUyMGJlaGFsZiUy MG9mJTIwYWNlZUBjaXNjby5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQt ZGVjb3JhdGlvbjpub25lIj5pMnJzLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGFjZWVA Y2lzY28uY29tPC9zcGFuPjwvYT4mZ3Q7DQogd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDtIaSBNYWNoLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 O0nigJltIGxvb2tpbmcgYXQgZHJhZnQtaWV0Zi1pMnJzLXJpYi1kYXRhLW1vZGVsLTA0LnR4dCBh bmQgaXQgc3RpbGwNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 O2luY2x1ZGVzIGFsbCB0aGUgdHVubmVsIGVuY2Fwcy4gSSBrbm93IHlvdSByZWNlaXZlZCBzZXZl cmFsIGNvbW1lbnRzDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDt0aGF0IHRob3NlIHNob3VsZCBiZSBpbiB0aGUgdHVubmVsIG1vZGVsKHMpIGFuZCB0aGlzIEky UlMgUklCIG1vZGVsDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDtzaG91bGQgbWVyZWx5IHJlZmVyZW5jZSBhbiBpbXBvcnRlZCB0dW5uZWwgYWJzdHJhY3Rpb24u IEhvdyBhcmUgeW91DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDtnb2luZyB0byBhZGRyZXNzIHRoaXM/IEl0IHNlZW1lZCB0aGF0IHRoZSBjb25zZW5zdXMgKGFu ZCBhbiBvcGluaW9uDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDt0aGF0IEkgc2hhcmUpIHdhcyB0aGF0IHRoaXMgbW9kZWwgc2hvdWxkIG5vdCBhdHRlbXB0IHRv IGdlbmVyaWNhbGx5DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDtjcmVhdGVkIHR1bm5lbHMgdmlhIFJJQi9GSUIgZW50cmllcy48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDtUaGFua3MsPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7QWNlZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0O09uIDExLzIzLzE1LCAyOjIzIEFNLCAmcXVvdDtpMnJzIG9uIGJlaGFsZiBvZiBNYWNo IENoZW4mcXVvdDsgPG86cD4NCjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsmbHQ7PGEgaHJlZj0ibWFpbHRvOmkycnMtYm91bmNlc0BpZXRmLm9yZyUyMG9uJTIwYmVoYWxm JTIwb2YlMjBtYWNoLmNoZW5AaHVhd2VpLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3Rl eHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmkycnMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYg b2YgbWFjaC5jaGVuQGh1YXdlaS5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0O0hpLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsmZ3Q7V2UganVzdCB1cGxvYWRlZCBhbiB1cGRhdGUgdGhhdCBh ZGRyZXNzZXMgdGhlIGNvbW1lbnRzIHJlY2VpdmVkDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsmZ3Q7KGluY2x1ZGUgb25saW5lIGFuZCBvZmZsaW5lKSByZWNl bnRseS4gUGxlYXNlIHJldmlldyB0aGUgZHJhZnQgYW5kIGNvbW1lbnQhPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDtUaGFua3MsPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0O01hY2g8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyBGcm9t OiBpMnJzIFs8YSBocmVmPSJtYWlsdG86aTJycy1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHls ZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+bWFpbHRvOmkycnMtYm91 bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+XSBPbiBCZWhhbGYgT2YNCjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7PGEgaHJlZj0ibWFpbHRvOmludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1k ZWNvcmF0aW9uOm5vbmUiPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsgU2VudDogTW9u ZGF5LCBOb3ZlbWJlciAyMywgMjAxNSAzOjE2IFBNPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsgVG86IDxhIGhyZWY9Im1haWx0bzppLWQtYW5ub3Vu Y2VAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlv bjpub25lIj5pLWQtYW5ub3VuY2VAaWV0Zi5vcmc8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7IENjOiA8YSBocmVmPSJtYWlsdG86 aTJyc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0 aW9uOm5vbmUiPmkycnNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7IFN1YmplY3Q6IFtpMnJzXSBJLUQgQWN0aW9u OiBkcmFmdC1pZXRmLWkycnMtcmliLWRhdGEtbW9kZWwtMDQudHh0PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsgPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsgQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZh aWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzDQo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0O2RpcmVjdG9yaWVzLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jm5ic3A7IFRoaXMg ZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIEludGVyZmFjZSB0byB0aGUgUm91dGluZyBTeXN0 ZW0NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7 V29ya2luZyBHcm91cCZuYnNwOyBvZiB0aGUgSUVURi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBUaXRsZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IEEgWUFORyBEYXRhIE1vZGVsIGZvciBSb3V0aW5n IEluZm9ybWF0aW9uIEJhc2U8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsmZ3Q7Jmd0OyAoUklCKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IEF1dGhvcnMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgOiBMaXhpbmcgV2FuZzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IEhhcmloYXJhbiBBbmFudGhha3Jpc2huYW48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBNYWNoKEd1b3lpKSBDaGVuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgQW1pdCBEYXNzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU3Jp Z2FuZXNoIEtpbmk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsm Z3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBOaXRpbiBC YWhhZHVyPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZn dDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZpbGVuYW1lJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogZHJhZnQtaWV0Zi1pMnJzLXJpYi1k YXRhLW1vZGVsLTA0LnR4dDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyZndDsmZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBQYWdlcyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyA6IDY1PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZn dDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IERhdGUmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOiAy MDE1LTExLTIyPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0 OyZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZn dDsgQWJzdHJhY3Q6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgWUFORyBk YXRhIG1vZGVsIGZvciBSb3V0aW5nIEluZm9ybWF0aW9uIEJhc2U8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyAoUklC KSB0aGF0IGFsaWducyB3aXRoIHRoZSBJMlJTIFJJQiBpbmZvcm1hdGlvbiBtb2RlbC48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyA8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyA8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyA8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyBUaGUgSUVURiBkYXRhdHJhY2tl ciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWkycnMtcmliLWRhdGEtbW9kZWwvIj4NCjxzcGFuIHN0 eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWkycnMtcmliLWRhdGEtbW9kZWwvPC9zcGFu PjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0 OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyBU aGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pMnJzLXJpYi1kYXRhLW1vZGVsLTA0Ij4N CjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pMnJzLXJpYi1kYXRhLW1vZGVsLTA0 PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsm Z3Q7Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7 Jmd0OyBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsgPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtaTJycy1yaWIt ZGF0YS1tb2RlbC0wNCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29y YXRpb246bm9uZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYt aTJycy1yaWItZGF0YS1tb2RlbC0wNDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsgUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNv dXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7c3VibWlzc2lvbiZuYnNwOyB1bnRpbCB0aGUg aHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0DQo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0O3Rvb2xzLmlldGYub3JnLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7IDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7IEludGVybmV0 LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDo8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJmdHA6 Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRv d3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsmZ3Q7Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7IGky cnMgbWFpbGluZyBsaXN0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOmkycnNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJj b2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5pMnJzQGlldGYub3JnPC9zcGFu PjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0 OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2kycnMiPg0K PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJyczwvc3Bhbj48L2E+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDtfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyZndDtpMnJzIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDs8YSBocmVmPSJtYWlsdG86aTJyc0BpZXRmLm9y ZyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmky cnNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyZndDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2kycnMiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpu b25lIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2kycnM8L3NwYW4+PC9h PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0O19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7aTJycyBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDs8YSBocmVmPSJtYWlsdG86aTJyc0BpZXRmLm9yZyI+PHNw YW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmkycnNAaWV0 Zi5vcmc8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJycyI+ PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJyczwvc3Bhbj48L2E+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+aTJycyBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxhIGhyZWY9Im1haWx0bzppMnJzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6 d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aTJyc0BpZXRmLm9yZzwvc3Bhbj48L2E+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2kycnMiPjxzcGFuIHN0eWxlPSJjb2xvcjp3 aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2kycnM8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D27916203EEF3aceeciscocom_-- From nobody Mon Nov 23 18:57:17 2015 Return-Path: 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 E324C1B3550 for ; Mon, 23 Nov 2015 18:57:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 o0weZHEaw2IF for ; Mon, 23 Nov 2015 18:57:13 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E05181B3543 for ; Mon, 23 Nov 2015 18:57:12 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.177; From: "Susan Hares" To: "'Acee Lindem \(acee\)'" , References: <20151123071558.25655.92641.idtracker@ietfa.amsl.com> <8D628270-A455-4E01-881F-BA20D544228D@ericsson.com> <041001d12640$9d5104b0$d7f30e10$@ndzh.com> In-Reply-To: Date: Mon, 23 Nov 2015 21:57:02 -0500 Message-ID: <047901d12663$cb716880$62543980$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_047A_01D12639.E29FF460" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLzNuIIn4QWw/Hs75J8GiGq3b7+uQJO1DWoAiHpGU0CXgkCwwFVd58VAjQ3mH+cE4oMUA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' , 'Jeff Tantsura' , 'Alia Atlas' Subject: Re: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 02:57:17 -0000 This is a multipart message in MIME format. ------=_NextPart_000_047A_01D12639.E29FF460 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Acee:=20 =20 Is your input individual input or input from the routing architecture = for yang models?=20 =20 =20 The routing architecture for yang models is incomplete without the = consideration of the I2RS ephemeral state and I2RS architecture. Asking = the I2RS WG to change a document that is in WG LC based on an incomplete = architectural document is not reasonable. An alignment between = = https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ without = the consideration of the I2RS ephemeral state is an incomplete alignment = and a problematic approach for I2RS WG=E2=80=99s efforts. =20 =20 In a volunteer organization, each person has the right to makes choices = in what they have time to do. If you do not have bandwidth to provide = an adequate routing architecture for yang models that considers = ephemeral state or its needs, that is your choice. Unless you have a = concrete proposal for the ephemeral state that covers I2RS RIB and = = https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/, the = I2RS WG LC will be closed after 2 week (11/23 =E2=80=93 12/7) WG review = of the in draft-ietf-i2rs-rib-data-model-04.txt. =20 =20 Please remember that the I2RS RIB model has two parts: I2RS = Informational Model and I2RS Data Model. The I2RS Informational Model = and the I2RS Data Model have descriptions on the soft tunnel = provisioning as mechanisms. Questions at this point must demonstrate a = knowledge of these documents or suggest specific changes to the = documents. If you wish to raise the following questions, please do = this in light of specific sections that include both the I2RS = Informational Model, the I2RS Data Model, and I2RS architecture.=20 =20 a) I2RS tunnels must include additions beyond encapsulation,=20 b) Why the I2RS Informational Model and the I2RS Data Model do not = provide the soft tunnel provisioning or describe the specifics of this = provision? =20 =20 The I2RS Informational Model has examples for these tunnels. You are = welcome to make proposal for specific changes to the I2RS Informational = Model or the I2RS Data Model. The I2RS Informational Model has = completed WG LC so the bar for substantive comments is high. =20 =20 =20 Cheers,=20 =20 Sue Hares=20 =20 From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Acee Lindem = (acee) Sent: Monday, November 23, 2015 7:30 PM To: Susan Hares; i2rs@ietf.org Subject: Re: [i2rs] FW: I-D Action: = draft-ietf-i2rs-rib-data-model-04.txt =20 Sue,=20 =20 From: i2rs on behalf of Susan Hares = Date: Monday, November 23, 2015 at 5:45 PM To: "i2rs@ietf.org" Subject: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt =20 Resending to I2RS WG.=20 =20 From: Susan Hares [mailto:shares@ndzh.com]=20 Sent: Monday, November 23, 2015 5:33 PM To: 'Jeff Tantsura'; 'Acee Lindem (acee)'; 'Mach Chen'; 'i2rs@ietf.org' Cc: 'Jeffrey Haas'; 'Alia Atlas'; 'Benoit Claise (bclaise)' Subject: RE: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.txt =20 Jeff and Acee:=20 =20 Your suggested change goes against the WG adopted RIB Information draft = that has been discussed for over 2 years. The informational draft has = been through WG LC and you did not make any suggestions or comments = during the WG LC. Any change of this matter is not simply something you = indicate to the authors, but needs to be discussed on the WG as a = direction change for the RIB IM/DM models. =20 Independent of the I2RS efforts, milestones, and processes, I think we = need to address whether provisioning all these tunnels via RIB = installation is appropriate and, additionally, consistent with other WG = YANG models. In many cases, it would seem there are tunnel attributes = other than the encaps that need to be provisioned. At a minimum, I think = you=E2=80=99d need to either reference an RFC describing soft tunnel = provisioning or describe the specifics of this provisioning.=20 =20 =20 Prior to moving this change through WG adoption cycle, the routing = architectural team needs to have: a) concrete proposal for the ephemeral = state that covers I2RS RIB and = https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ and b) = I requested this input of Acee Lindem as a representative of the routing = architecture team. =20 =20 The identification of this problem with tunnel provisioning is a direct = outcome of this effort.=20 =20 =20 =20 I will be glad to work with you on a concrete proposal that you can send = to the email list and present at the I2RS interim meeting on 12/16/2015 = (10-11:30am ET). =20 I will continue to work on ietf-routing alignment but don=E2=80=99t have = the bandwidth for the above.=20 =20 Acee=20 =20 =20 =20 =20 =20 Sue Hares=20 =20 -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Jeff Tantsura Sent: Monday, November 23, 2015 4:27 PM To: Acee Lindem (acee); Mach Chen; i2rs@ietf.org Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.txt =20 Hi Mach, =20 I agree with Acee=E2=80=99s comments and would encourage you to use = generic/existing tunnel model(s), please see comments provided during = RTGWG meeting in Yokohama. There are already too many, we need to rationalize this work. =20 This is what has been discussed in Yokohama, Robin presented =20 -- draft-li-rtgwg-utunnel-yang -- draft-li-rtgwg-tunnel-policy-yang -- draft-wwz-netmod-yang-tunnel-cfg -- draft-zheng-intarea-gre-yang -- draft-liu-intarea-gre-tunnel-yang -- draft-liu-intarea-ipipv4-tunnel-yang =20 Cheers, Jeff =20 =20 =20 =20 =20 =20 On 11/23/15, 11:56, "i2rs on behalf of Acee Lindem (acee)" < = = i2rs-bounces@ietf.org on behalf of acee@cisco.com> wrote: =20 >Hi Mach, >=20 >I=E2=80=99m looking at draft-ietf-i2rs-rib-data-model-04.txt and it = still=20 >includes all the tunnel encaps. I know you received several comments=20 >that those should be in the tunnel model(s) and this I2RS RIB model=20 >should merely reference an imported tunnel abstraction. How are you=20 >going to address this? It seemed that the consensus (and an opinion=20 >that I share) was that this model should not attempt to generically=20 >created tunnels via RIB/FIB entries. >Thanks, >Acee >=20 >On 11/23/15, 2:23 AM, "i2rs on behalf of Mach Chen"=20 >< = = i2rs-bounces@ietf.org on behalf of mach.chen@huawei.com> wrote: >=20 >>Hi, >>=20 >>We just uploaded an update that addresses the comments received=20 >>(include online and offline) recently. Please review the draft and = comment! >>=20 >>Thanks, >>Mach >>=20 >>> -----Original Message----- >>> From: i2rs [ = mailto:i2rs-bounces@ietf.org] On Behalf Of=20 >>> internet-drafts@ietf.org >>> Sent: Monday, November 23, 2015 3:16 PM >>> To: i-d-announce@ietf.org >>> Cc: i2rs@ietf.org >>> Subject: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.txt >>>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts=20 >>>directories. >>> This draft is a work item of the Interface to the Routing System=20 >>>Working Group of the IETF. >>>=20 >>> Title : A YANG Data Model for Routing Information = Base >>> (RIB) >>> Authors : Lixing Wang >>> Hariharan Ananthakrishnan >>> Mach(Guoyi) Chen >>> Amit Dass >>> Sriganesh Kini >>> Nitin Bahadur >>> Filename : draft-ietf-i2rs-rib-data-model-04.txt >>> Pages : 65 >>> Date : 2015-11-22 >>>=20 >>> Abstract: >>> This document defines a YANG data model for Routing Information = Base >>> (RIB) that aligns with the I2RS RIB information model. >>>=20 >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> = https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/ >>>=20 >>> There's also a htmlized version available at: >>> = https://tools.ietf.org/html/draft-ietf-i2rs-rib-data-model-04 >>>=20 >>> A diff from the previous version is available at: >>> = = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2rs-rib-data-model-04 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of=20 >>>submission until the htmlized version and diff are available at=20 >>>tools.ietf.org. >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> = ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> = https://www.ietf.org/mailman/listinfo/i2rs >>=20 >>_______________________________________________ >>i2rs mailing list >> i2rs@ietf.org >> = https://www.ietf.org/mailman/listinfo/i2rs >=20 >_______________________________________________ >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 ------=_NextPart_000_047A_01D12639.E29FF460 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Acee: =

 

Is your input individual input or input from the = routing architecture for yang models?

 

<I2RS = chair hat on>

The routing = architecture for yang models is incomplete without the consideration of = the I2RS ephemeral state and I2RS architecture.=C2=A0 Asking the I2RS WG = to change a document that is in WG LC based on an incomplete = architectural document is not reasonable. =C2=A0An alignment between = https://datatracker.ietf.org/doc/draft-ietf-ne= tmod-routing-cfg/ without = the consideration of the I2RS ephemeral state is an incomplete alignment = and a problematic =C2=A0approach for I2RS WG=E2=80=99s efforts. = =C2=A0=C2=A0

 

In a = volunteer organization, each person has the right to makes choices in = what they have time to do.=C2=A0=C2=A0 If you do not have bandwidth to = provide an adequate routing architecture for yang models that considers = ephemeral state or its needs, that is your choice. =C2=A0Unless you have = a concrete proposal for the ephemeral state that covers I2RS RIB and = https://datatracker.ietf.org/doc/draft-ietf-ne= tmod-routing-cfg/, the I2RS WG LC will be closed after 2 week = (11/23 =E2=80=93 12/7) WG review of the in draft-ietf-i2rs-rib-data-model-04.txt.=C2=A0 = =C2=A0=C2=A0=C2=A0

 

Please = remember that the I2RS RIB model has two parts:=C2=A0 I2RS Informational = Model and I2RS Data Model.=C2=A0 The I2RS = Informational Model and the I2RS Data Model have descriptions on the = soft tunnel provisioning as mechanisms.=C2=A0 Questions at this point = must demonstrate a knowledge of these documents or suggest specific = changes to the documents. =C2=A0=C2=A0If you wish to raise the following = questions, please do this in light of specific sections that include = both the I2RS Informational Model, the I2RS Data Model, and I2RS = architecture.

 

a)      = I2RS tunnels must include additions beyond = encapsulation,

b)      = Why the I2RS Informational Model and the I2RS = Data Model do not provide the soft tunnel provisioning or describe the = specifics of this provision?=C2=A0

 

The I2RS = Informational Model has examples for these tunnels. =C2=A0You are = welcome to make proposal for specific changes to the I2RS Informational = Model or the I2RS Data Model.=C2=A0 The I2RS Informational Model has = completed WG LC so the bar for substantive comments is high.=C2=A0 = =C2=A0=C2=A0

<I2RS chair hat = off>

 

Cheers, =

 

Sue = Hares

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Acee Lindem = (acee)
Sent: Monday, November 23, 2015 7:30 PM
To: = Susan Hares; i2rs@ietf.org
Subject: Re: [i2rs] FW: I-D Action: = draft-ietf-i2rs-rib-data-model-04.txt

 

Sue, 

 

=

From: = i2rs <i2rs-bounces@ietf.org> on = behalf of Susan Hares <shares@ndzh.com>
Date: = Monday, November 23, 2015 at 5:45 PM
To: "i2rs@ietf.org" <i2rs@ietf.org>
Subject: = [i2rs] FW: I-D Action: = draft-ietf-i2rs-rib-data-model-04.txt

 

=

Resending to I2RS WG. =

 

= From:= Susan Hares [mailto:shares@ndzh.com] =
Sent: Monday, November 23, 2015 5:33 PM
To: 'Jeff = Tantsura'; 'Acee Lindem (acee)'; 'Mach Chen'; 'i2rs@ietf.org'
Cc: = 'Jeffrey Haas'; 'Alia Atlas'; 'Benoit Claise = (bclaise)'
Subject: RE: [i2rs] I-D Action: = draft-ietf-i2rs-rib-data-model-04.txt

 

Jeff and Acee: =

 

Your suggested change = goes against the WG adopted RIB Information draft that has been = discussed for over 2 years.  The informational draft has been = through WG LC and you did not make any suggestions or comments during = the WG LC.  Any change of this matter is not simply something you = indicate to the authors, but needs to be discussed on the WG as a = direction change for the RIB IM/DM = models.

 

=

Independent of the I2RS efforts, = milestones, and processes, I think we need to address whether = provisioning all these tunnels via RIB installation is  appropriate = and, additionally, consistent with other WG YANG models. In many cases, = it would seem there are tunnel attributes other than the encaps that = need to be provisioned. At a minimum, I think you=E2=80=99d need to = either reference an RFC describing soft tunnel provisioning or describe = the specifics of this = provisioning. 

 

=

 

Prior to moving this = change through WG adoption cycle, the routing architectural team needs = to have: a) concrete proposal for the ephemeral state that covers I2RS = RIB and = https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ =  and  b) I requested this input of Acee Lindem as a = representative of the routing architecture team. =   

 

=

The  identification of this = problem with tunnel provisioning is a direct outcome of this = effort. 

 

=

 

 

I will be glad to work = with you on a concrete proposal that you can send to the email list and = present at the I2RS interim meeting on 12/16/2015 (10-11:30am = ET).

 

=

I = will continue to work on ietf-routing alignment but don=E2=80=99t have = the bandwidth for the above. 

 

=

Acee 

 

=

 

=

 

=

 

=

 

 Sue Hares =

 

-----Original = Message-----
From: i2rs [mailto:i2rs-bounces@ietf.org] = On Behalf Of Jeff Tantsura
Sent: Monday, November 23, 2015 4:27 = PM
To: Acee Lindem (acee); Mach Chen; i2rs@ietf.org
Subject: Re: [i2rs] = I-D Action: = draft-ietf-i2rs-rib-data-model-04.txt

 

Hi = Mach,

 

I agree with = Acee=E2=80=99s comments and would encourage you to use generic/existing = tunnel model(s), please see comments provided during RTGWG meeting in = Yokohama.

There are already too many, we need to rationalize = this work.

 

This is what has been = discussed in Yokohama, Robin presented

 

-- = draft-li-rtgwg-utunnel-yang

   -- = draft-li-rtgwg-tunnel-policy-yang

   -- = draft-wwz-netmod-yang-tunnel-cfg

   -- = draft-zheng-intarea-gre-yang

   -- = draft-liu-intarea-gre-tunnel-yang

   -- = draft-liu-intarea-ipipv4-tunnel-yang

 

Cheers,

Jeff

 

 

 

 

 

 

On 11/23/15, 11:56, = "i2rs on behalf of Acee Lindem (acee)" <i2rs-bounces@ietf.org on = behalf of acee@cisco.com> wrote:

 

>Hi = Mach,

> 

>I=E2=80=99m looking = at draft-ietf-i2rs-rib-data-model-04.txt and it still =

>includes all the tunnel encaps. I know you = received several comments

>that those should = be in the tunnel model(s) and this I2RS RIB model =

>should merely reference an imported tunnel = abstraction. How are you

>going to address = this? It seemed that the consensus (and an opinion =

>that I share) was that this model should not = attempt to generically

>created tunnels via = RIB/FIB entries.

>Thanks,

>Acee

> 

>On 11/23/15, 2:23 = AM, "i2rs on behalf of Mach Chen"

><i2rs-bounces@ietf.org on = behalf of mach.chen@huawei.com> = wrote:

> 

>>Hi,

>> 

>>We just = uploaded an update that addresses the comments received =

>>(include online and offline) recently. = Please review the draft and comment!

>> 

>>Thanks,

>>Mach

>> 

>>> = -----Original Message-----

>>> From: i2rs = [mailto:i2rs-bounces@ietf.= org] On Behalf Of

>>>internet-drafts@ietf.org<= /span>

>>> Sent: Monday, November 23, 2015 3:16 = PM

>>> To: i-d-announce@ietf.org

>>> Cc: i2rs@ietf.org<= o:p>

>>> Subject: [i2rs] I-D Action: = draft-ietf-i2rs-rib-data-model-04.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.

>>>

>>>      &nb= sp;  = Title           : A = YANG Data Model for Routing Information Base

>>> = (RIB)

>>>      &nb= sp;  Authors         : = Lixing Wang

>>>      &nb= sp;           &nbs= p;        Hariharan = Ananthakrishnan

>>>      &nb= sp;           &nbs= p;        Mach(Guoyi) = Chen

>>>      &nb= sp;           &nbs= p;        Amit = Dass

>>>      &nb= sp;           &nbs= p;        Sriganesh = Kini

>>>      &nb= sp;           &nbs= p;        Nitin = Bahadur

>>>        = Filename        : = draft-ietf-i2rs-rib-data-model-04.txt

>>> =        = Pages           : = 65

>>>        = Date            : = 2015-11-22

>>>

>>> = Abstract:

>>>    This document = defines a YANG data model for Routing Information = Base

>>>    (RIB) that aligns = with the I2RS RIB information model.

>>> =

>>>

>>> =

>>> The IETF datatracker status page for = this draft is:

>>> https://datatracker.ietf.= org/doc/draft-ietf-i2rs-rib-data-model/

<= p class=3DMsoPlainText>>>> =

>>> There's also a htmlized version = available at:

>>> https://tools.ietf.org/ht= ml/draft-ietf-i2rs-rib-data-model-04

>>> =

>>> A diff from the previous version is = available at:

>>> https://www.ietf.org/rfcd= iff?url2=3Ddraft-ietf-i2rs-rib-data-model-04=

>>> =

>>>

>>> 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/intern= et-drafts/

>>>

>>> = _______________________________________________

>>> i2rs = mailing list

>>> i2rs@ietf.org<= o:p>

>>> https://www.ietf.org/mail= man/listinfo/i2rs

>> 

>>___________________________________________= ____

>>i2rs mailing list

>>i2rs@ietf.org<= o:p>

>>https://www.ietf.org/mail= man/listinfo/i2rs

> 

>_______________________________________________=

>i2rs mailing list

>i2rs@ietf.org<= o:p>

>https://www.ietf.org/mail= man/listinfo/i2rs

_______________________________________________

i2rs mailing list

i2rs@ietf.org<= o:p>

https://www.ietf.org/mail= man/listinfo/i2rs

------=_NextPart_000_047A_01D12639.E29FF460-- From nobody Tue Nov 24 05:35:02 2015 Return-Path: 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 B3E611A6F3F for ; Tue, 24 Nov 2015 05:34:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.085 X-Spam-Level: X-Spam-Status: No, score=-15.085 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 j82Bk2l_0h3H for ; Tue, 24 Nov 2015 05:34:51 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 407951A6F38 for ; Tue, 24 Nov 2015 05:34:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=72849; q=dns/txt; s=iport; t=1448372089; x=1449581689; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=m2ZD1PzGHdSEIq7v+OJkawzOKLhtGEcN1nK9wWRzP5o=; b=KlCUbdFH1JB293mPtWYZ0TXRZufjPJywtyA4AciTEFmEKbNtZIoFSlSV dtBGSuy7Djas1TdcMXhJnJVmZ5Bf1EO4S9AOOtalsE5Cn92CfMZJuraIO i0NWiln16S+S6AKATVB1MGfnpOdzVai0Kt6Rjmzt9nONRVaUvCX4oew/d k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D/AQAbZ1RW/5FdJa1egm5NU28GvyEBD?= =?us-ascii?q?YFiAxcBCYVuAhyBHTgUAQEBAQEBAYEKhDQBAQEDAQEBASAKQQsMBAIBCA4DAQI?= =?us-ascii?q?BAQEhAQYDAgICHwYLFAMFAQgCBAENBYgZAwoIDa4yizQNhG0BAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEYi1KCU4FXEQElBwkKDQkCBoJcgUQFkmuDZQGFI4YXgXaBW0m?= =?us-ascii?q?Dd4c1hiaBAoNhg3EBHwEBQoIRHYFWcgGDaTqBBwEBAQ?= X-IronPort-AV: E=Sophos; i="5.20,338,1444694400"; d="scan'208,217"; a="49750785" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Nov 2015 13:34:47 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id tAODYlXJ014864 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 24 Nov 2015 13:34:47 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 24 Nov 2015 08:34:46 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.000; Tue, 24 Nov 2015 08:34:39 -0500 From: "Acee Lindem (acee)" To: Susan Hares , "i2rs@ietf.org" Thread-Topic: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt Thread-Index: AQHRJkCnXerbjrqsRkCeqqFxylBayJ6qUewAgAB8+gCAAF5RAA== Date: Tue, 24 Nov 2015 13:34:39 +0000 Message-ID: References: <20151123071558.25655.92641.idtracker@ietfa.amsl.com> <8D628270-A455-4E01-881F-BA20D544228D@ericsson.com> <041001d12640$9d5104b0$d7f30e10$@ndzh.com> <047901d12663$cb716880$62543980$@ndzh.com> In-Reply-To: <047901d12663$cb716880$62543980$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: multipart/alternative; boundary="_000_D279CE493EFC8aceeciscocom_" MIME-Version: 1.0 Archived-At: Cc: 'Jeffrey Haas' , 'Jeff Tantsura' , 'Alia Atlas' Subject: Re: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 13:34:58 -0000 --_000_D279CE493EFC8aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogU3VzYW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbTxtYWlsdG86c2hhcmVzQG5kemguY29t Pj4NCkRhdGU6IE1vbmRheSwgTm92ZW1iZXIgMjMsIDIwMTUgYXQgOTo1NyBQTQ0KVG86IEFjZWUg TGluZGVtIDxhY2VlQGNpc2NvLmNvbTxtYWlsdG86YWNlZUBjaXNjby5jb20+PiwgImkycnNAaWV0 Zi5vcmc8bWFpbHRvOmkycnNAaWV0Zi5vcmc+IiA8aTJyc0BpZXRmLm9yZzxtYWlsdG86aTJyc0Bp ZXRmLm9yZz4+DQpDYzogQWxpYSBBdGxhcyA8YWthdGxhc0BnbWFpbC5jb208bWFpbHRvOmFrYXRs YXNAZ21haWwuY29tPj4sIEplZmYgSGFhcyA8amhhYXNAcGZyYy5vcmc8bWFpbHRvOmpoYWFzQHBm cmMub3JnPj4sIEplZmYgVGFudHN1cmEgPGplZmYudGFudHN1cmFAZXJpY3Nzb24uY29tPG1haWx0 bzpqZWZmLnRhbnRzdXJhQGVyaWNzc29uLmNvbT4+DQpTdWJqZWN0OiBSRTogW2kycnNdIEZXOiBJ LUQgQWN0aW9uOiBkcmFmdC1pZXRmLWkycnMtcmliLWRhdGEtbW9kZWwtMDQudHh0DQoNCkFjZWU6 DQoNCklzIHlvdXIgaW5wdXQgaW5kaXZpZHVhbCBpbnB1dCBvciBpbnB1dCBmcm9tIHRoZSByb3V0 aW5nIGFyY2hpdGVjdHVyZSBmb3IgeWFuZyBtb2RlbHM/DQoNCkluZGl2aWR1YWwuDQoNCg0KDQo8 STJSUyBjaGFpciBoYXQgb24+DQoNClRoZSByb3V0aW5nIGFyY2hpdGVjdHVyZSBmb3IgeWFuZyBt b2RlbHMgaXMgaW5jb21wbGV0ZSB3aXRob3V0IHRoZSBjb25zaWRlcmF0aW9uIG9mIHRoZSBJMlJT IGVwaGVtZXJhbCBzdGF0ZSBhbmQgSTJSUyBhcmNoaXRlY3R1cmUuICBBc2tpbmcgdGhlIEkyUlMg V0cgdG8gY2hhbmdlIGEgZG9jdW1lbnQgdGhhdCBpcyBpbiBXRyBMQyBiYXNlZCBvbiBhbiBpbmNv bXBsZXRlIGFyY2hpdGVjdHVyYWwgZG9jdW1lbnQgaXMgbm90IHJlYXNvbmFibGUuDQoNCk15IGNv bW1lbnQgd2l0aCByZXNwZWN0IHRvIHR1bm5lbCBwcm92aXNpb25pbmcgaXMgbm90IGJhc2VkIG9u IGFueSBhcmNoaXRlY3R1cmUgZG9jdW1lbnQuDQoNCg0KQW4gYWxpZ25tZW50IGJldHdlZW4gaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRtb2Qtcm91dGluZy1j ZmcvIHdpdGhvdXQgdGhlIGNvbnNpZGVyYXRpb24gb2YgdGhlIEkyUlMgZXBoZW1lcmFsIHN0YXRl IGlzIGFuIGluY29tcGxldGUgYWxpZ25tZW50IGFuZCBhIHByb2JsZW1hdGljICBhcHByb2FjaCBm b3IgSTJSUyBXR+KAmXMgZWZmb3J0cy4NCg0KSTJSUyBtb2RlbHMgc2hvdWxkIGF1Z21lbnQgdGhl IGJhc2UgbW9kZWxzIHdpdGggZXBoZW1lcmFsIHN0YXRlLg0KDQoNCg0KSW4gYSB2b2x1bnRlZXIg b3JnYW5pemF0aW9uLCBlYWNoIHBlcnNvbiBoYXMgdGhlIHJpZ2h0IHRvIG1ha2VzIGNob2ljZXMg aW4gd2hhdCB0aGV5IGhhdmUgdGltZSB0byBkby4gICBJZiB5b3UgZG8gbm90IGhhdmUgYmFuZHdp ZHRoIHRvIHByb3ZpZGUgYW4gYWRlcXVhdGUgcm91dGluZyBhcmNoaXRlY3R1cmUgZm9yIHlhbmcg bW9kZWxzIHRoYXQgY29uc2lkZXJzIGVwaGVtZXJhbCBzdGF0ZSBvciBpdHMgbmVlZHMsIHRoYXQg aXMgeW91ciBjaG9pY2UuICBVbmxlc3MgeW91IGhhdmUgYSBjb25jcmV0ZSBwcm9wb3NhbCBmb3Ig dGhlIGVwaGVtZXJhbCBzdGF0ZSB0aGF0IGNvdmVycyBJMlJTIFJJQiBhbmQgaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRtb2Qtcm91dGluZy1jZmcvLCB0aGUg STJSUyBXRyBMQyB3aWxsIGJlIGNsb3NlZCBhZnRlciAyIHdlZWsgKDExLzIzIOKAkyAxMi83KSBX RyByZXZpZXcgb2YgdGhlIGluIGRyYWZ0LWlldGYtaTJycy1yaWItZGF0YS1tb2RlbC0wNC50eHQu DQoNCldlIGhhdmUgcHJvcG9zZWQgdHVubmVsIG1vZGVscywgZHJhZnQtaWV0Zi1uZXRtb2Qtcm91 dGluZy1jZmcgaXMgbm90IG1lYW50IHRvIHN1cHBsYW50IHRoZW0uIEJUVywgd2UgZG9u4oCZdCBw bGFuIHRvIHVwZGF0ZSBkcmFmdC1pZXRmLWkycnMtcmliLWRhdGEtbW9kZWwtMDQudHh0LiBVcGRh dGVzIGJhc2VkIG9uIEkyUlMgd2lsbCBiZSBpbiB0aGUgYSBuZXh0LWhvcCBhdWdtZW50YXRpb24g ZHJhZnQgdGhhdCBleHRlbmRzIGRyYWZ0LWlldGYtbmV0bW9kLXJ0Zy1jZmcuDQoNCg0KDQpQbGVh c2UgcmVtZW1iZXIgdGhhdCB0aGUgSTJSUyBSSUIgbW9kZWwgaGFzIHR3byBwYXJ0czogIEkyUlMg SW5mb3JtYXRpb25hbCBNb2RlbCBhbmQgSTJSUyBEYXRhIE1vZGVsLiAgVGhlIEkyUlMgSW5mb3Jt YXRpb25hbCBNb2RlbCBhbmQgdGhlIEkyUlMgRGF0YSBNb2RlbCBoYXZlIGRlc2NyaXB0aW9ucyBv biB0aGUgc29mdCB0dW5uZWwgcHJvdmlzaW9uaW5nIGFzIG1lY2hhbmlzbXMuICBRdWVzdGlvbnMg YXQgdGhpcyBwb2ludCBtdXN0IGRlbW9uc3RyYXRlIGEga25vd2xlZGdlIG9mIHRoZXNlIGRvY3Vt ZW50cyBvciBzdWdnZXN0IHNwZWNpZmljIGNoYW5nZXMgdG8gdGhlIGRvY3VtZW50cy4gICBJZiB5 b3Ugd2lzaCB0byByYWlzZSB0aGUgZm9sbG93aW5nIHF1ZXN0aW9ucywgcGxlYXNlIGRvIHRoaXMg aW4gbGlnaHQgb2Ygc3BlY2lmaWMgc2VjdGlvbnMgdGhhdCBpbmNsdWRlIGJvdGggdGhlIEkyUlMg SW5mb3JtYXRpb25hbCBNb2RlbCwgdGhlIEkyUlMgRGF0YSBNb2RlbCwgYW5kIEkyUlMgYXJjaGl0 ZWN0dXJlLg0KDQoNCmEpICAgICAgSTJSUyB0dW5uZWxzIG11c3QgaW5jbHVkZSBhZGRpdGlvbnMg YmV5b25kIGVuY2Fwc3VsYXRpb24sDQoNCmIpICAgICAgV2h5IHRoZSBJMlJTIEluZm9ybWF0aW9u YWwgTW9kZWwgYW5kIHRoZSBJMlJTIERhdGEgTW9kZWwgZG8gbm90IHByb3ZpZGUgdGhlIHNvZnQg dHVubmVsIHByb3Zpc2lvbmluZyBvciBkZXNjcmliZSB0aGUgc3BlY2lmaWNzIG9mIHRoaXMgcHJv dmlzaW9uPw0KDQpUaGUgSTJSUyBJbmZvcm1hdGlvbmFsIE1vZGVsIGhhcyBleGFtcGxlcyBmb3Ig dGhlc2UgdHVubmVscy4gIFlvdSBhcmUgd2VsY29tZSB0byBtYWtlIHByb3Bvc2FsIGZvciBzcGVj aWZpYyBjaGFuZ2VzIHRvIHRoZSBJMlJTIEluZm9ybWF0aW9uYWwgTW9kZWwgb3IgdGhlIEkyUlMg RGF0YSBNb2RlbC4gIFRoZSBJMlJTIEluZm9ybWF0aW9uYWwgTW9kZWwgaGFzIGNvbXBsZXRlZCBX RyBMQyBzbyB0aGUgYmFyIGZvciBzdWJzdGFudGl2ZSBjb21tZW50cyBpcyBoaWdoLg0KDQpJIGRv buKAmXQgYmVsaWV2ZSB0aGlzIGV4Y2VycHQgZnJvbSB0aGUgUklCIGluZm9ybWF0aW9uIG1vZGVs cyBkZXNjcmliZXMgc29mdCB0dW5uZWwgcHJvdmlzaW9uaW5nIGZvciBlYWNoIG9mIHRoZSB0dW5u ZWxzIHByb3Bvc2VkIGluIHRoZSBSSUIgZGF0YSBtb2RlbDoNCg0KNy4yLjEuICBUdW5uZWwgbmV4 dGhvcHMNCg0KICAgQSB0dW5uZWwgbmV4dGhvcCBwb2ludHMgdG8gYSB0dW5uZWwgb2Ygc29tZSBr aW5kLiAgVHJhZmZpYyB0aGF0IGdvZXMNCiAgIG92ZXIgdGhlIHR1bm5lbCBnZXRzIGVuY2Fwc3Vs YXRlZCB3aXRoIHRoZSB0dW5uZWwgZW5jYXAuICBUdW5uZWwNCiAgIG5leHRob3BzIGFyZSB1c2Vm dWwgZm9yIGFic3RyYWN0aW5nIG91dCBkZXRhaWxzIG9mIHRoZSBuZXR3b3JrLCBieQ0KICAgaGF2 aW5nIHRoZSB0cmFmZmljIHNlYW1sZXNzbHkgcm91dGUgYmV0d2VlbiBuZXR3b3JrIGVkZ2VzLiAg QXQgdGhlDQogICBlbmQgb2YgYSB0dW5uZWwsIHRoZSB0dW5uZWwgd2lsbCBnZXQgZGVjYXBzdWxh dGVkLiAgVGh1cyB0aGUgZ3JhbW1hcg0KICAgc3VwcG9ydHMgdHdvIGtpbmRzIG9mIG9wZXJhdGlv bnMsIG9uZSBmb3IgZW5jYXAgYW5kIGFub3RoZXIgZm9yDQogICBkZWNhcC4NCg0KQWNlZQ0KDQoN Cg0KPEkyUlMgY2hhaXIgaGF0IG9mZj4NCg0KQ2hlZXJzLA0KDQpTdWUgSGFyZXMNCg0KRnJvbTog aTJycyBbbWFpbHRvOmkycnMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFjZWUgTGlu ZGVtIChhY2VlKQ0KU2VudDogTW9uZGF5LCBOb3ZlbWJlciAyMywgMjAxNSA3OjMwIFBNDQpUbzog U3VzYW4gSGFyZXM7IGkycnNAaWV0Zi5vcmc8bWFpbHRvOmkycnNAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBSZTogW2kycnNdIEZXOiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWkycnMtcmliLWRhdGEtbW9k ZWwtMDQudHh0DQoNClN1ZSwNCg0KRnJvbTogaTJycyA8aTJycy1ib3VuY2VzQGlldGYub3JnPG1h aWx0bzppMnJzLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgU3VzYW4gSGFyZXMgPHNo YXJlc0BuZHpoLmNvbTxtYWlsdG86c2hhcmVzQG5kemguY29tPj4NCkRhdGU6IE1vbmRheSwgTm92 ZW1iZXIgMjMsIDIwMTUgYXQgNTo0NSBQTQ0KVG86ICJpMnJzQGlldGYub3JnPG1haWx0bzppMnJz QGlldGYub3JnPiIgPGkycnNAaWV0Zi5vcmc8bWFpbHRvOmkycnNAaWV0Zi5vcmc+Pg0KU3ViamVj dDogW2kycnNdIEZXOiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWkycnMtcmliLWRhdGEtbW9kZWwt MDQudHh0DQoNClJlc2VuZGluZyB0byBJMlJTIFdHLg0KDQpGcm9tOiBTdXNhbiBIYXJlcyBbbWFp bHRvOnNoYXJlc0BuZHpoLmNvbV0NClNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMjMsIDIwMTUgNToz MyBQTQ0KVG86ICdKZWZmIFRhbnRzdXJhJzsgJ0FjZWUgTGluZGVtIChhY2VlKSc7ICdNYWNoIENo ZW4nOyAnaTJyc0BpZXRmLm9yZzxtYWlsdG86J2kycnNAaWV0Zi5vcmc+Jw0KQ2M6ICdKZWZmcmV5 IEhhYXMnOyAnQWxpYSBBdGxhcyc7ICdCZW5vaXQgQ2xhaXNlIChiY2xhaXNlKScNClN1YmplY3Q6 IFJFOiBbaTJyc10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1pMnJzLXJpYi1kYXRhLW1vZGVsLTA0 LnR4dA0KDQoNCkplZmYgYW5kIEFjZWU6DQoNCg0KDQpZb3VyIHN1Z2dlc3RlZCBjaGFuZ2UgZ29l cyBhZ2FpbnN0IHRoZSBXRyBhZG9wdGVkIFJJQiBJbmZvcm1hdGlvbiBkcmFmdCB0aGF0IGhhcyBi ZWVuIGRpc2N1c3NlZCBmb3Igb3ZlciAyIHllYXJzLiAgVGhlIGluZm9ybWF0aW9uYWwgZHJhZnQg aGFzIGJlZW4gdGhyb3VnaCBXRyBMQyBhbmQgeW91IGRpZCBub3QgbWFrZSBhbnkgc3VnZ2VzdGlv bnMgb3IgY29tbWVudHMgZHVyaW5nIHRoZSBXRyBMQy4gIEFueSBjaGFuZ2Ugb2YgdGhpcyBtYXR0 ZXIgaXMgbm90IHNpbXBseSBzb21ldGhpbmcgeW91IGluZGljYXRlIHRvIHRoZSBhdXRob3JzLCBi dXQgbmVlZHMgdG8gYmUgZGlzY3Vzc2VkIG9uIHRoZSBXRyBhcyBhIGRpcmVjdGlvbiBjaGFuZ2Ug Zm9yIHRoZSBSSUIgSU0vRE0gbW9kZWxzLg0KDQpJbmRlcGVuZGVudCBvZiB0aGUgSTJSUyBlZmZv cnRzLCBtaWxlc3RvbmVzLCBhbmQgcHJvY2Vzc2VzLCBJIHRoaW5rIHdlIG5lZWQgdG8gYWRkcmVz cyB3aGV0aGVyIHByb3Zpc2lvbmluZyBhbGwgdGhlc2UgdHVubmVscyB2aWEgUklCIGluc3RhbGxh dGlvbiBpcyAgYXBwcm9wcmlhdGUgYW5kLCBhZGRpdGlvbmFsbHksIGNvbnNpc3RlbnQgd2l0aCBv dGhlciBXRyBZQU5HIG1vZGVscy4gSW4gbWFueSBjYXNlcywgaXQgd291bGQgc2VlbSB0aGVyZSBh cmUgdHVubmVsIGF0dHJpYnV0ZXMgb3RoZXIgdGhhbiB0aGUgZW5jYXBzIHRoYXQgbmVlZCB0byBi ZSBwcm92aXNpb25lZC4gQXQgYSBtaW5pbXVtLCBJIHRoaW5rIHlvdeKAmWQgbmVlZCB0byBlaXRo ZXIgcmVmZXJlbmNlIGFuIFJGQyBkZXNjcmliaW5nIHNvZnQgdHVubmVsIHByb3Zpc2lvbmluZyBv ciBkZXNjcmliZSB0aGUgc3BlY2lmaWNzIG9mIHRoaXMgcHJvdmlzaW9uaW5nLg0KDQoNCg0KDQpQ cmlvciB0byBtb3ZpbmcgdGhpcyBjaGFuZ2UgdGhyb3VnaCBXRyBhZG9wdGlvbiBjeWNsZSwgdGhl IHJvdXRpbmcgYXJjaGl0ZWN0dXJhbCB0ZWFtIG5lZWRzIHRvIGhhdmU6IGEpIGNvbmNyZXRlIHBy b3Bvc2FsIGZvciB0aGUgZXBoZW1lcmFsIHN0YXRlIHRoYXQgY292ZXJzIEkyUlMgUklCIGFuZCBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW5ldG1vZC1yb3V0aW5n LWNmZy8gIGFuZCAgYikgSSByZXF1ZXN0ZWQgdGhpcyBpbnB1dCBvZiBBY2VlIExpbmRlbSBhcyBh IHJlcHJlc2VudGF0aXZlIG9mIHRoZSByb3V0aW5nIGFyY2hpdGVjdHVyZSB0ZWFtLg0KDQpUaGUg IGlkZW50aWZpY2F0aW9uIG9mIHRoaXMgcHJvYmxlbSB3aXRoIHR1bm5lbCBwcm92aXNpb25pbmcg aXMgYSBkaXJlY3Qgb3V0Y29tZSBvZiB0aGlzIGVmZm9ydC4NCg0KDQoNCg0KDQoNCkkgd2lsbCBi ZSBnbGFkIHRvIHdvcmsgd2l0aCB5b3Ugb24gYSBjb25jcmV0ZSBwcm9wb3NhbCB0aGF0IHlvdSBj YW4gc2VuZCB0byB0aGUgZW1haWwgbGlzdCBhbmQgcHJlc2VudCBhdCB0aGUgSTJSUyBpbnRlcmlt IG1lZXRpbmcgb24gMTIvMTYvMjAxNSAoMTAtMTE6MzBhbSBFVCkuDQoNCkkgd2lsbCBjb250aW51 ZSB0byB3b3JrIG9uIGlldGYtcm91dGluZyBhbGlnbm1lbnQgYnV0IGRvbuKAmXQgaGF2ZSB0aGUg YmFuZHdpZHRoIGZvciB0aGUgYWJvdmUuDQoNCkFjZWUNCg0KDQoNCg0KDQoNCg0KIFN1ZSBIYXJl cw0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGkycnMgW21haWx0bzpp MnJzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKZWZmIFRhbnRzdXJhDQpTZW50OiBN b25kYXksIE5vdmVtYmVyIDIzLCAyMDE1IDQ6MjcgUE0NClRvOiBBY2VlIExpbmRlbSAoYWNlZSk7 IE1hY2ggQ2hlbjsgaTJyc0BpZXRmLm9yZzxtYWlsdG86aTJyc0BpZXRmLm9yZz4NClN1YmplY3Q6 IFJlOiBbaTJyc10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1pMnJzLXJpYi1kYXRhLW1vZGVsLTA0 LnR4dA0KDQoNCg0KSGkgTWFjaCwNCg0KDQoNCkkgYWdyZWUgd2l0aCBBY2Vl4oCZcyBjb21tZW50 cyBhbmQgd291bGQgZW5jb3VyYWdlIHlvdSB0byB1c2UgZ2VuZXJpYy9leGlzdGluZyB0dW5uZWwg bW9kZWwocyksIHBsZWFzZSBzZWUgY29tbWVudHMgcHJvdmlkZWQgZHVyaW5nIFJUR1dHIG1lZXRp bmcgaW4gWW9rb2hhbWEuDQoNClRoZXJlIGFyZSBhbHJlYWR5IHRvbyBtYW55LCB3ZSBuZWVkIHRv IHJhdGlvbmFsaXplIHRoaXMgd29yay4NCg0KDQoNClRoaXMgaXMgd2hhdCBoYXMgYmVlbiBkaXNj dXNzZWQgaW4gWW9rb2hhbWEsIFJvYmluIHByZXNlbnRlZA0KDQoNCg0KLS0gZHJhZnQtbGktcnRn d2ctdXR1bm5lbC15YW5nDQoNCiAgIC0tIGRyYWZ0LWxpLXJ0Z3dnLXR1bm5lbC1wb2xpY3kteWFu Zw0KDQogICAtLSBkcmFmdC13d3otbmV0bW9kLXlhbmctdHVubmVsLWNmZw0KDQogICAtLSBkcmFm dC16aGVuZy1pbnRhcmVhLWdyZS15YW5nDQoNCiAgIC0tIGRyYWZ0LWxpdS1pbnRhcmVhLWdyZS10 dW5uZWwteWFuZw0KDQogICAtLSBkcmFmdC1saXUtaW50YXJlYS1pcGlwdjQtdHVubmVsLXlhbmcN Cg0KDQoNCkNoZWVycywNCg0KSmVmZg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpPbiAxMS8y My8xNSwgMTE6NTYsICJpMnJzIG9uIGJlaGFsZiBvZiBBY2VlIExpbmRlbSAoYWNlZSkiIDxpMnJz LWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGFjZWVAY2lzY28uY29tPG1haWx0bzppMnJz LWJvdW5jZXNAaWV0Zi5vcmclMjBvbiUyMGJlaGFsZiUyMG9mJTIwYWNlZUBjaXNjby5jb20+PiB3 cm90ZToNCg0KDQoNCj5IaSBNYWNoLA0KDQo+DQoNCj5J4oCZbSBsb29raW5nIGF0IGRyYWZ0LWll dGYtaTJycy1yaWItZGF0YS1tb2RlbC0wNC50eHQgYW5kIGl0IHN0aWxsDQoNCj5pbmNsdWRlcyBh bGwgdGhlIHR1bm5lbCBlbmNhcHMuIEkga25vdyB5b3UgcmVjZWl2ZWQgc2V2ZXJhbCBjb21tZW50 cw0KDQo+dGhhdCB0aG9zZSBzaG91bGQgYmUgaW4gdGhlIHR1bm5lbCBtb2RlbChzKSBhbmQgdGhp cyBJMlJTIFJJQiBtb2RlbA0KDQo+c2hvdWxkIG1lcmVseSByZWZlcmVuY2UgYW4gaW1wb3J0ZWQg dHVubmVsIGFic3RyYWN0aW9uLiBIb3cgYXJlIHlvdQ0KDQo+Z29pbmcgdG8gYWRkcmVzcyB0aGlz PyBJdCBzZWVtZWQgdGhhdCB0aGUgY29uc2Vuc3VzIChhbmQgYW4gb3Bpbmlvbg0KDQo+dGhhdCBJ IHNoYXJlKSB3YXMgdGhhdCB0aGlzIG1vZGVsIHNob3VsZCBub3QgYXR0ZW1wdCB0byBnZW5lcmlj YWxseQ0KDQo+Y3JlYXRlZCB0dW5uZWxzIHZpYSBSSUIvRklCIGVudHJpZXMuDQoNCj5UaGFua3Ms DQoNCj5BY2VlDQoNCj4NCg0KPk9uIDExLzIzLzE1LCAyOjIzIEFNLCAiaTJycyBvbiBiZWhhbGYg b2YgTWFjaCBDaGVuIg0KDQo+PGkycnMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgbWFj aC5jaGVuQGh1YXdlaS5jb208bWFpbHRvOmkycnMtYm91bmNlc0BpZXRmLm9yZyUyMG9uJTIwYmVo YWxmJTIwb2YlMjBtYWNoLmNoZW5AaHVhd2VpLmNvbT4+IHdyb3RlOg0KDQo+DQoNCj4+SGksDQoN Cj4+DQoNCj4+V2UganVzdCB1cGxvYWRlZCBhbiB1cGRhdGUgdGhhdCBhZGRyZXNzZXMgdGhlIGNv bW1lbnRzIHJlY2VpdmVkDQoNCj4+KGluY2x1ZGUgb25saW5lIGFuZCBvZmZsaW5lKSByZWNlbnRs eS4gUGxlYXNlIHJldmlldyB0aGUgZHJhZnQgYW5kIGNvbW1lbnQhDQoNCj4+DQoNCj4+VGhhbmtz LA0KDQo+Pk1hY2gNCg0KPj4NCg0KPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCj4+ PiBGcm9tOiBpMnJzIFttYWlsdG86aTJycy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YN Cg0KPj4+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmc+DQoNCj4+PiBTZW50OiBNb25kYXksIE5vdmVtYmVyIDIzLCAyMDE1IDM6MTYgUE0NCg0K Pj4+IFRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmc8bWFpbHRvOmktZC1hbm5vdW5jZUBpZXRmLm9y Zz4NCg0KPj4+IENjOiBpMnJzQGlldGYub3JnPG1haWx0bzppMnJzQGlldGYub3JnPg0KDQo+Pj4g U3ViamVjdDogW2kycnNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtaTJycy1yaWItZGF0YS1tb2Rl bC0wNC50eHQNCg0KPj4+DQoNCj4+Pg0KDQo+Pj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZh aWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzDQoNCj4+PmRpcmVjdG9yaWVz Lg0KDQo+Pj4gIFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIEludGVyZmFjZSB0byB0 aGUgUm91dGluZyBTeXN0ZW0NCg0KPj4+V29ya2luZyBHcm91cCAgb2YgdGhlIElFVEYuDQoNCj4+ Pg0KDQo+Pj4gICAgICAgICBUaXRsZSAgICAgICAgICAgOiBBIFlBTkcgRGF0YSBNb2RlbCBmb3Ig Um91dGluZyBJbmZvcm1hdGlvbiBCYXNlDQoNCj4+PiAoUklCKQ0KDQo+Pj4gICAgICAgICBBdXRo b3JzICAgICAgICAgOiBMaXhpbmcgV2FuZw0KDQo+Pj4gICAgICAgICAgICAgICAgICAgICAgICAg ICBIYXJpaGFyYW4gQW5hbnRoYWtyaXNobmFuDQoNCj4+PiAgICAgICAgICAgICAgICAgICAgICAg ICAgIE1hY2goR3VveWkpIENoZW4NCg0KPj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgQW1p dCBEYXNzDQoNCj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgIFNyaWdhbmVzaCBLaW5pDQoN Cj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgIE5pdGluIEJhaGFkdXINCg0KPj4+ICAgICAg ICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWkycnMtcmliLWRhdGEtbW9kZWwtMDQudHh0 DQoNCj4+PiAgICAgICAgUGFnZXMgICAgICAgICAgIDogNjUNCg0KPj4+ICAgICAgICBEYXRlICAg ICAgICAgICAgOiAyMDE1LTExLTIyDQoNCj4+Pg0KDQo+Pj4gQWJzdHJhY3Q6DQoNCj4+PiAgICBU aGlzIGRvY3VtZW50IGRlZmluZXMgYSBZQU5HIGRhdGEgbW9kZWwgZm9yIFJvdXRpbmcgSW5mb3Jt YXRpb24gQmFzZQ0KDQo+Pj4gICAgKFJJQikgdGhhdCBhbGlnbnMgd2l0aCB0aGUgSTJSUyBSSUIg aW5mb3JtYXRpb24gbW9kZWwuDQoNCj4+Pg0KDQo+Pj4NCg0KPj4+DQoNCj4+PiBUaGUgSUVURiBk YXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCg0KPj4+IGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaTJycy1yaWItZGF0YS1tb2RlbC8N Cg0KPj4+DQoNCj4+PiBUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBh dDoNCg0KPj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWkycnMtcmli LWRhdGEtbW9kZWwtMDQNCg0KPj4+DQoNCj4+PiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVy c2lvbiBpcyBhdmFpbGFibGUgYXQ6DQoNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZm P3VybDI9ZHJhZnQtaWV0Zi1pMnJzLXJpYi1kYXRhLW1vZGVsLTA0DQoNCj4+Pg0KDQo+Pj4NCg0K Pj4+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9t IHRoZSB0aW1lIG9mDQoNCj4+PnN1Ym1pc3Npb24gIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9u IGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQNCg0KPj4+dG9vbHMuaWV0Zi5vcmcuDQoNCj4+Pg0K DQo+Pj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQ IGF0Og0KDQo+Pj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0KPj4+DQoN Cj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQo+ Pj4gaTJycyBtYWlsaW5nIGxpc3QNCg0KPj4+IGkycnNAaWV0Zi5vcmc8bWFpbHRvOmkycnNAaWV0 Zi5vcmc+DQoNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2kycnMN Cg0KPj4NCg0KPj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KDQo+PmkycnMgbWFpbGluZyBsaXN0DQoNCj4+aTJyc0BpZXRmLm9yZzxtYWlsdG86aTJyc0Bp ZXRmLm9yZz4NCg0KPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2kycnMN Cg0KPg0KDQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cg0KPmkycnMgbWFpbGluZyBsaXN0DQoNCj5pMnJzQGlldGYub3JnPG1haWx0bzppMnJzQGlldGYu b3JnPg0KDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMnJzDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCmkycnMgbWFp bGluZyBsaXN0DQoNCmkycnNAaWV0Zi5vcmc8bWFpbHRvOmkycnNAaWV0Zi5vcmc+DQoNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJycw0K --_000_D279CE493EFC8aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <8FB2B27F3CDA09448D9242CF58598349@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0K PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpOyBmb250LXNpemU6IDExcHQ7IGZvbnQt d2VpZ2h0OiBib2xkOyI+RnJvbTogPC9zcGFuPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBD YWxpYnJpOyBmb250LXNpemU6IDExcHQ7Ij5TdXNhbiBIYXJlcyAmbHQ7PC9zcGFuPjxhIGhyZWY9 Im1haWx0bzpzaGFyZXNAbmR6aC5jb20iIHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaTsgZm9u dC1zaXplOiAxMXB0OyI+c2hhcmVzQG5kemguY29tPC9hPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTogQ2FsaWJyaTsgZm9udC1zaXplOiAxMXB0OyI+Jmd0Ozwvc3Bhbj48L2Rpdj4NCjxzcGFuIGlk PSJPTEtfU1JDX0JPRFlfU0VDVElPTiIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0ZXh0LWFsaWduOmxlZnQ7 IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1l ZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElO Ry1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hU OiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWln aHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPk1vbmRheSwgTm92ZW1iZXIgMjMsIDIwMTUgYXQgOTo1NyBQ TTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPkFjZWUgTGlu ZGVtICZsdDs8YSBocmVmPSJtYWlsdG86YWNlZUBjaXNjby5jb20iPmFjZWVAY2lzY28uY29tPC9h PiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzppMnJzQGlldGYub3JnIj5pMnJzQGlldGYub3Jn PC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmkycnNAaWV0Zi5vcmciPmkycnNAaWV0Zi5v cmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9zcGFu PkFsaWEgQXRsYXMgJmx0OzxhIGhyZWY9Im1haWx0bzpha2F0bGFzQGdtYWlsLmNvbSI+YWthdGxh c0BnbWFpbC5jb208L2E+Jmd0OywgSmVmZiBIYWFzICZsdDs8YSBocmVmPSJtYWlsdG86amhhYXNA cGZyYy5vcmciPmpoYWFzQHBmcmMub3JnPC9hPiZndDssIEplZmYgVGFudHN1cmEgJmx0OzxhIGhy ZWY9Im1haWx0bzpqZWZmLnRhbnRzdXJhQGVyaWNzc29uLmNvbSI+amVmZi50YW50c3VyYUBlcmlj c3Nvbi5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJq ZWN0OiA8L3NwYW4+UkU6IFtpMnJzXSBGVzogSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1pMnJzLXJp Yi1kYXRhLW1vZGVsLTA0LnR4dDxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9S REVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAg NTsiPg0KPGRpdiB4bWxuczp2PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOnZtbCIgeG1sbnM6 bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4bWxuczp3PSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczp4PSJ1cm46c2NoZW1hcy1t aWNyb3NvZnQtY29tOm9mZmljZTpleGNlbCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9z b2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvVFIv UkVDLWh0bWw0MCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1pY3Jvc29mdCBX b3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRp b25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9z ZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxp YnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0 LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFy IjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4w cHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnAuTXNvTGlzdFBhcmFn cmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0 eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4 dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWlu IFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5CYWxs b29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9u dC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4 LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0K QGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6OTAyNTIxMjc4Ow0KCW1zby1saXN0LXR5cGU6aHlicmlk Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczozMzgwNTY1MTYgNjc2OTg3MTEgNjc2OTg3MTMgNjc2 OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3 MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxv d2VyOw0KCW1zby1sZXZlbC10ZXh0OiIlMVwpIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30N CkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpA bGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZl bDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3 DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0K QGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmln aHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVs DQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjxkaXYgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkFjZWU6IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JcyB5b3VyIGlucHV0IGlu ZGl2aWR1YWwgaW5wdXQgb3IgaW5wdXQgZnJvbSB0aGUgcm91dGluZyBhcmNoaXRlY3R1cmUgZm9y IHlhbmcgbW9kZWxzPzwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N Cjwvc3Bhbj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxicj4NCjwvZGl2Pg0KPGRp diBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KSW5kaXZpZHVhbC4mbmJzcDs8L2Rpdj4NCjxkaXYg c3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6 IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6 ZTogMTRweDsiPg0KPGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04i IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRU UklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7 IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXYgeG1sbnM6dj0idXJuOnNj aGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1j b206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZp Y2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6ZXhjZWwi IHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vb2ZmaWNlLzIwMDQvMTIvb21t bCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPGRpdiBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZsdDtJ MlJTIGNoYWlyIGhhdCBvbiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij5UaGUgcm91dGluZyBhcmNoaXRlY3R1cmUgZm9yIHlhbmcgbW9kZWxzIGlzIGluY29tcGxl dGUgd2l0aG91dCB0aGUgY29uc2lkZXJhdGlvbiBvZiB0aGUgSTJSUyBlcGhlbWVyYWwgc3RhdGUg YW5kIEkyUlMgYXJjaGl0ZWN0dXJlLiZuYnNwOyBBc2tpbmcgdGhlIEkyUlMgV0cgdG8gY2hhbmdl IGEgZG9jdW1lbnQgdGhhdCBpcyBpbiBXRyBMQyBiYXNlZCBvbiBhbiBpbmNvbXBsZXRlIGFyY2hp dGVjdHVyYWwgZG9jdW1lbnQNCiBpcyBub3QgcmVhc29uYWJsZS4gJm5ic3A7PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0KPGRpdiBzdHlsZT0iY29s b3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQt c2l6ZTogMTRweDsiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAs IDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+ DQpNeSBjb21tZW50IHdpdGggcmVzcGVjdCB0byB0dW5uZWwgcHJvdmlzaW9uaW5nIGlzIG5vdCBi YXNlZCBvbiBhbnkgYXJjaGl0ZWN0dXJlIGRvY3VtZW50LiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHls ZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IGZvbnQtc2l6ZTogMTRweDsiPg0KPGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZ X1NFQ1RJT04iIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09V VExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRm IDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXYgeG1sbnM6 dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVybjpzY2hlbWFzLW1p Y3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0 LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZp Y2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vb2ZmaWNlLzIw MDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPGRp diBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QW4gYWxpZ25tZW50IGJldHdl ZW4gPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1u ZXRtb2Qtcm91dGluZy1jZmcvIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5odHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW5ldG1vZC1yb3V0aW5nLWNm Zy88L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7d2l0aG91dCB0aGUg Y29uc2lkZXJhdGlvbiBvZiB0aGUgSTJSUyBlcGhlbWVyYWwgc3RhdGUgaXMgYW4gaW5jb21wbGV0 ZSBhbGlnbm1lbnQgYW5kIGEgcHJvYmxlbWF0aWMgJm5ic3A7YXBwcm9hY2ggZm9yIEkyUlMgV0fi gJlzIGVmZm9ydHMuDQogJm5ic3A7Jm5ic3A7PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwg MCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7 Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KSTJSUyBtb2Rl bHMgc2hvdWxkIGF1Z21lbnQgdGhlIGJhc2UgbW9kZWxzIHdpdGggZXBoZW1lcmFsIHN0YXRlLiZu YnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGJyPg0KPC9kaXY+DQo8 ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtf U1JDX0JPRFlfU0VDVElPTiIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxibG9ja3F1b3RlIGlk PSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6 ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRp diB4bWxuczp2PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOnZtbCIgeG1sbnM6bz0idXJuOnNj aGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4bWxuczp3PSJ1cm46c2NoZW1hcy1t aWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczp4PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQt Y29tOm9mZmljZTpleGNlbCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9v ZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0 MCI+DQo8ZGl2IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gYSB2b2x1 bnRlZXIgb3JnYW5pemF0aW9uLCBlYWNoIHBlcnNvbiBoYXMgdGhlIHJpZ2h0IHRvIG1ha2VzIGNo b2ljZXMgaW4gd2hhdCB0aGV5IGhhdmUgdGltZSB0byBkby4mbmJzcDsmbmJzcDsgSWYgeW91IGRv IG5vdCBoYXZlIGJhbmR3aWR0aCB0byBwcm92aWRlIGFuIGFkZXF1YXRlIHJvdXRpbmcgYXJjaGl0 ZWN0dXJlIGZvciB5YW5nIG1vZGVscyB0aGF0IGNvbnNpZGVycyBlcGhlbWVyYWwgc3RhdGUgb3Ig aXRzIG5lZWRzLA0KIHRoYXQgaXMgeW91ciBjaG9pY2UuICZuYnNwO1VubGVzcyB5b3UgaGF2ZSBh IGNvbmNyZXRlIHByb3Bvc2FsIGZvciB0aGUgZXBoZW1lcmFsIHN0YXRlIHRoYXQgY292ZXJzIEky UlMgUklCIGFuZA0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1uZXRtb2Qtcm91dGluZy1jZmcvIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4 dCI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRtb2Qtcm91 dGluZy1jZmcvPC9zcGFuPjwvYT4sIHRoZSBJMlJTIFdHIExDIHdpbGwgYmUgY2xvc2VkIGFmdGVy IDIgd2VlayAoMTEvMjMg4oCTIDEyLzcpIFdHIHJldmlldyBvZiB0aGUgaW4NCjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+ZHJhZnQtaWV0Zi1pMnJzLXJpYi1kYXRhLW1vZGVsLTA0LnR4dC4mbmJz cDsgPC9zcGFuPiZuYnNwOyZuYnNwOzwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvc3Bhbj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxicj4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KV2UgaGF2ZSBwcm9wb3NlZCB0dW5u ZWwgbW9kZWxzLCBkcmFmdC1pZXRmLW5ldG1vZC1yb3V0aW5nLWNmZyBpcyBub3QgbWVhbnQgdG8g c3VwcGxhbnQgdGhlbS4gQlRXLCB3ZSBkb27igJl0IHBsYW4gdG8gdXBkYXRlJm5ic3A7ZHJhZnQt aWV0Zi1pMnJzLXJpYi1kYXRhLW1vZGVsLTA0LnR4dC4gVXBkYXRlcyBiYXNlZCBvbiBJMlJTIHdp bGwgYmUgaW4gdGhlIGEgbmV4dC1ob3AgYXVnbWVudGF0aW9uIGRyYWZ0IHRoYXQgZXh0ZW5kcyBk cmFmdC1pZXRmLW5ldG1vZC1ydGctY2ZnLiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6 IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6 ZTogMTRweDsiPg0KPGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04i IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRU UklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7 IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXYgeG1sbnM6dj0idXJuOnNj aGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1j b206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZp Y2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6ZXhjZWwi IHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vb2ZmaWNlLzIwMDQvMTIvb21t bCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPGRpdiBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlBsZWFzZSByZW1lbWJlciB0aGF0IHRoZSBJMlJTIFJJQiBtb2RlbCBoYXMgdHdvIHBhcnRzOiZu YnNwOyBJMlJTIEluZm9ybWF0aW9uYWwgTW9kZWwgYW5kIEkyUlMgRGF0YSBNb2RlbC4mbmJzcDsN CjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGhlIEkyUlMgSW5mb3JtYXRpb25hbCBNb2RlbCBh bmQgdGhlIEkyUlMgRGF0YSBNb2RlbCBoYXZlIGRlc2NyaXB0aW9ucyBvbiB0aGUgc29mdCB0dW5u ZWwgcHJvdmlzaW9uaW5nIGFzIG1lY2hhbmlzbXMuJm5ic3A7IFF1ZXN0aW9ucyBhdCB0aGlzIHBv aW50IG11c3QgZGVtb25zdHJhdGUgYSBrbm93bGVkZ2Ugb2YgdGhlc2UgZG9jdW1lbnRzIG9yIHN1 Z2dlc3Qgc3BlY2lmaWMgY2hhbmdlcyB0byB0aGUgZG9jdW1lbnRzLg0KICZuYnNwOyZuYnNwO0lm IHlvdSB3aXNoIHRvIHJhaXNlIHRoZSBmb2xsb3dpbmcgcXVlc3Rpb25zLCBwbGVhc2UgZG8gdGhp cyBpbiBsaWdodCBvZiBzcGVjaWZpYyBzZWN0aW9ucyB0aGF0IGluY2x1ZGUgYm90aCB0aGUgSTJS UyBJbmZvcm1hdGlvbmFsIE1vZGVsLCB0aGUgSTJSUyBEYXRhIE1vZGVsLCBhbmQgSTJSUyBhcmNo aXRlY3R1cmUuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IS0tW2lmICFzdXBw b3J0TGlzdHNdLS0+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+YSk8c3BhbiBzdHlsZT0i Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgZm9udC1zaXplOiA3cHQ7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAn VGltZXMgTmV3IFJvbWFuJzsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFu Pjwvc3Bhbj48IS0tW2VuZGlmXS0tPkkyUlMgdHVubmVscyBtdXN0IGluY2x1ZGUgYWRkaXRpb25z IGJleW9uZCBlbmNhcHN1bGF0aW9uLA0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlz dFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEg bGZvMSI+PCEtLVtpZiAhc3VwcG9ydExpc3RzXS0tPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25v cmUiPmIpPHNwYW4gc3R5bGU9ImZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3Jt YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGZvbnQtc2l6ZTogN3B0OyBsaW5lLWhlaWdodDogbm9y bWFsOyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PCEtLVtlbmRpZl0tLT5XaHkgdGhlIEkyUlMgSW5m b3JtYXRpb25hbCBNb2RlbCBhbmQgdGhlIEkyUlMgRGF0YSBNb2RlbCBkbyBub3QgcHJvdmlkZSB0 aGUgc29mdCB0dW5uZWwgcHJvdmlzaW9uaW5nIG9yIGRlc2NyaWJlIHRoZSBzcGVjaWZpY3Mgb2Yg dGhpcyBwcm92aXNpb24/Jm5ic3A7DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIEkyUlMg SW5mb3JtYXRpb25hbCBNb2RlbCBoYXMgZXhhbXBsZXMgZm9yIHRoZXNlIHR1bm5lbHMuICZuYnNw O1lvdSBhcmUgd2VsY29tZSB0byBtYWtlIHByb3Bvc2FsIGZvciBzcGVjaWZpYyBjaGFuZ2VzIHRv IHRoZSBJMlJTIEluZm9ybWF0aW9uYWwgTW9kZWwgb3IgdGhlIEkyUlMgRGF0YSBNb2RlbC4mbmJz cDsgVGhlIEkyUlMgSW5mb3JtYXRpb25hbCBNb2RlbCBoYXMgY29tcGxldGVkIFdHIExDIHNvIHRo ZSBiYXIgZm9yDQogc3Vic3RhbnRpdmUgY29tbWVudHMgaXMgaGlnaC48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8ZGl2IHN0eWxlPSJjb2xvcjog cmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXpl OiAxNHB4OyI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCkkg ZG9u4oCZdCBiZWxpZXZlIHRoaXMgZXhjZXJwdCBmcm9tIHRoZSBSSUIgaW5mb3JtYXRpb24gbW9k ZWxzIGRlc2NyaWJlcyBzb2Z0IHR1bm5lbCBwcm92aXNpb25pbmcgZm9yIGVhY2ggb2YgdGhlIHR1 bm5lbHMgcHJvcG9zZWQgaW4gdGhlIFJJQiBkYXRhIG1vZGVsOjwvZGl2Pg0KPGRpdiBzdHlsZT0i Y29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZv bnQtc2l6ZTogMTRweDsiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJD YWxpYnJpLHNhbnMtc2VyaWYiPjcuMi4xLiAmbmJzcDtUdW5uZWwgbmV4dGhvcHM8L2ZvbnQ+PC9k aXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+PGJyPg0KPC9mb250Pjwv ZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtB IHR1bm5lbCBuZXh0aG9wIHBvaW50cyB0byBhIHR1bm5lbCBvZiBzb21lIGtpbmQuICZuYnNwO1Ry YWZmaWMgdGhhdCBnb2VzPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNh bnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtvdmVyIHRoZSB0dW5uZWwgZ2V0cyBlbmNhcHN1bGF0ZWQg d2l0aCB0aGUgdHVubmVsIGVuY2FwLiAmbmJzcDtUdW5uZWw8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxm b250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO25leHRob3BzIGFyZSB1 c2VmdWwgZm9yIGFic3RyYWN0aW5nIG91dCBkZXRhaWxzIG9mIHRoZSBuZXR3b3JrLCBieTwvZm9u dD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4mbmJzcDsgJm5i c3A7aGF2aW5nIHRoZSB0cmFmZmljIHNlYW1sZXNzbHkgcm91dGUgYmV0d2VlbiBuZXR3b3JrIGVk Z2VzLiAmbmJzcDtBdCB0aGU8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmks c2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO2VuZCBvZiBhIHR1bm5lbCwgdGhlIHR1bm5lbCB3aWxs IGdldCBkZWNhcHN1bGF0ZWQuICZuYnNwO1RodXMgdGhlIGdyYW1tYXI8L2ZvbnQ+PC9kaXY+DQo8 ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO3N1cHBvcnRz IHR3byBraW5kcyBvZiBvcGVyYXRpb25zLCBvbmUgZm9yIGVuY2FwIGFuZCBhbm90aGVyIGZvcjwv Zm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4mbmJzcDsg Jm5ic3A7ZGVjYXAuPC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdi KDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAx NHB4OyI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCkFjZWUm bmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxicj4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xL X1NSQ19CT0RZX1NFQ1RJT04iIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8YmxvY2txdW90ZSBp ZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZU OiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxk aXYgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVybjpz Y2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVtYXMt bWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9zb2Z0 LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20v b2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1s NDAiPg0KPGRpdiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNw OyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmx0O0kyUlMgY2hh aXIgaGF0IG9mZiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkNoZWVycywgPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5TdWUgSGFy ZXMgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5 OiBUYWhvbWEsIHNhbnMtc2VyaWY7Ij4gaTJycyBbPGEgaHJlZj0ibWFpbHRvOmkycnMtYm91bmNl c0BpZXRmLm9yZyI+bWFpbHRvOmkycnMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhh bGYgT2YgPC9iPkFjZWUgTGluZGVtIChhY2VlKTxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE5v dmVtYmVyIDIzLCAyMDE1IDc6MzAgUE08YnI+DQo8Yj5Ubzo8L2I+IFN1c2FuIEhhcmVzOyA8YSBo cmVmPSJtYWlsdG86aTJyc0BpZXRmLm9yZyI+aTJyc0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFtpMnJzXSBGVzogSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1pMnJzLXJpYi1k YXRhLW1vZGVsLTA0LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+ U3VlLCZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPmkycnMgJmx0OzxhIGhy ZWY9Im1haWx0bzppMnJzLWJvdW5jZXNAaWV0Zi5vcmciPmkycnMtYm91bmNlc0BpZXRmLm9yZzwv YT4mZ3Q7IG9uIGJlaGFsZiBvZiBTdXNhbiBIYXJlcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNoYXJl c0BuZHpoLmNvbSI+c2hhcmVzQG5kemguY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+TW9u ZGF5LCBOb3ZlbWJlciAyMywgMjAxNSBhdCA1OjQ1IFBNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDs8 YSBocmVmPSJtYWlsdG86aTJyc0BpZXRmLm9yZyI+aTJyc0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0 OzxhIGhyZWY9Im1haWx0bzppMnJzQGlldGYub3JnIj5pMnJzQGlldGYub3JnPC9hPiZndDs8YnI+ DQo8Yj5TdWJqZWN0OiA8L2I+W2kycnNdIEZXOiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWkycnMt cmliLWRhdGEtbW9kZWwtMDQudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7cGFk ZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXJpZ2h0OjBp biIgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+UmVzZW5k aW5nIHRvIEkyUlMgV0cuIDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6 IFRhaG9tYSwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7 IGNvbG9yOiBibGFjazsiPiBTdXNhbiBIYXJlcyBbPGEgaHJlZj0ibWFpbHRvOnNoYXJlc0BuZHpo LmNvbSI+bWFpbHRvOnNoYXJlc0BuZHpoLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9u ZGF5LCBOb3ZlbWJlciAyMywgMjAxNSA1OjMzIFBNPGJyPg0KPGI+VG86PC9iPiAnSmVmZiBUYW50 c3VyYSc7ICdBY2VlIExpbmRlbSAoYWNlZSknOyAnTWFjaCBDaGVuJzsgPGEgaHJlZj0ibWFpbHRv OidpMnJzQGlldGYub3JnIj4NCidpMnJzQGlldGYub3JnPC9hPic8YnI+DQo8Yj5DYzo8L2I+ICdK ZWZmcmV5IEhhYXMnOyAnQWxpYSBBdGxhcyc7ICdCZW5vaXQgQ2xhaXNlIChiY2xhaXNlKSc8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtpMnJzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWkycnMt cmliLWRhdGEtbW9kZWwtMDQudHh0PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5KZWZmIGFu ZCBBY2VlOiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+WW91ciBzdWdn ZXN0ZWQgY2hhbmdlIGdvZXMgYWdhaW5zdCB0aGUgV0cgYWRvcHRlZCBSSUIgSW5mb3JtYXRpb24g ZHJhZnQgdGhhdCBoYXMgYmVlbiBkaXNjdXNzZWQgZm9yIG92ZXIgMiB5ZWFycy4gJm5ic3A7VGhl IGluZm9ybWF0aW9uYWwgZHJhZnQgaGFzIGJlZW4gdGhyb3VnaCBXRyBMQyBhbmQgeW91IGRpZCBu b3QgbWFrZSBhbnkgc3VnZ2VzdGlvbnMgb3IgY29tbWVudHMNCiBkdXJpbmcgdGhlIFdHIExDLiAm bmJzcDtBbnkgY2hhbmdlIG9mIHRoaXMgbWF0dGVyIGlzIG5vdCBzaW1wbHkgc29tZXRoaW5nIHlv dSBpbmRpY2F0ZSB0byB0aGUgYXV0aG9ycywgYnV0IG5lZWRzIHRvIGJlIGRpc2N1c3NlZCBvbiB0 aGUgV0cgYXMgYSBkaXJlY3Rpb24gY2hhbmdlIGZvciB0aGUgUklCIElNL0RNIG1vZGVscy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFj ayI+SW5kZXBlbmRlbnQgb2YgdGhlIEkyUlMgZWZmb3J0cywgbWlsZXN0b25lcywgYW5kIHByb2Nl c3NlcywgSSB0aGluayB3ZSBuZWVkIHRvIGFkZHJlc3Mgd2hldGhlciBwcm92aXNpb25pbmcgYWxs IHRoZXNlIHR1bm5lbHMgdmlhIFJJQiBpbnN0YWxsYXRpb24gaXMgJm5ic3A7YXBwcm9wcmlhdGUg YW5kLCBhZGRpdGlvbmFsbHksIGNvbnNpc3RlbnQNCiB3aXRoIG90aGVyIFdHIFlBTkcgbW9kZWxz LiBJbiBtYW55IGNhc2VzLCBpdCB3b3VsZCBzZWVtIHRoZXJlIGFyZSB0dW5uZWwgYXR0cmlidXRl cyBvdGhlciB0aGFuIHRoZSBlbmNhcHMgdGhhdCBuZWVkIHRvIGJlIHByb3Zpc2lvbmVkLiBBdCBh IG1pbmltdW0sIEkgdGhpbmsgeW914oCZZCBuZWVkIHRvIGVpdGhlciByZWZlcmVuY2UgYW4gUkZD IGRlc2NyaWJpbmcgc29mdCB0dW5uZWwgcHJvdmlzaW9uaW5nIG9yIGRlc2NyaWJlIHRoZSBzcGVj aWZpY3MNCiBvZiB0aGlzIHByb3Zpc2lvbmluZy4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1 QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDtt YXJnaW4tcmlnaHQ6MGluIiBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5QcmlvciB0byBtb3ZpbmcgdGhpcyBjaGFu Z2UgdGhyb3VnaCBXRyBhZG9wdGlvbiBjeWNsZSwgdGhlIHJvdXRpbmcgYXJjaGl0ZWN0dXJhbCB0 ZWFtIG5lZWRzIHRvIGhhdmU6IGEpIGNvbmNyZXRlIHByb3Bvc2FsIGZvciB0aGUgZXBoZW1lcmFs IHN0YXRlIHRoYXQgY292ZXJzIEkyUlMgUklCIGFuZA0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRtb2Qtcm91dGluZy1jZmcvIj5odHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW5ldG1vZC1yb3V0aW5nLWNmZy88 L2E+ICZuYnNwO2FuZCAmbmJzcDtiKSBJIHJlcXVlc3RlZCB0aGlzIGlucHV0IG9mIEFjZWUgTGlu ZGVtIGFzIGEgcmVwcmVzZW50YXRpdmUgb2YgdGhlIHJvdXRpbmcgYXJjaGl0ZWN0dXJlIHRlYW0u ICZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2NvbG9yOmJsYWNrIj5UaGUgJm5ic3A7aWRlbnRpZmljYXRpb24gb2YgdGhpcyBwcm9i bGVtIHdpdGggdHVubmVsIHByb3Zpc2lvbmluZyBpcyBhIGRpcmVjdCBvdXRjb21lIG9mIHRoaXMg ZWZmb3J0LiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi1yaWdodDowaW4iIGlkPSJN QUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SSB3aWxsIGJlIGdsYWQgdG8gd29yayB3 aXRoIHlvdSBvbiBhIGNvbmNyZXRlIHByb3Bvc2FsIHRoYXQgeW91IGNhbiBzZW5kIHRvIHRoZSBl bWFpbCBsaXN0IGFuZCBwcmVzZW50IGF0IHRoZSBJMlJTIGludGVyaW0gbWVldGluZyBvbiAxMi8x Ni8yMDE1ICgxMC0xMTozMGFtIEVUKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+SSB3aWxsIGNvbnRpbnVlIHRvIHdvcmsgb24g aWV0Zi1yb3V0aW5nIGFsaWdubWVudCBidXQgZG9u4oCZdCBoYXZlIHRoZSBiYW5kd2lkdGggZm9y IHRoZSBhYm92ZS4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2si PkFjZWUmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21h cmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tcmlnaHQ6MGluIiBpZD0iTUFDX09VVExPT0tfQVRUUklC VVRJT05fQkxPQ0tRVU9URSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDtT dWUgSGFyZXMgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogaTJycyBbPGEgaHJlZj0ibWFpbHRvOmkycnMt Ym91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmkycnMtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJl aGFsZiBPZiBKZWZmIFRhbnRzdXJhPGJyPg0KU2VudDogTW9uZGF5LCBOb3ZlbWJlciAyMywgMjAx NSA0OjI3IFBNPGJyPg0KVG86IEFjZWUgTGluZGVtIChhY2VlKTsgTWFjaCBDaGVuOyA8YSBocmVm PSJtYWlsdG86aTJyc0BpZXRmLm9yZyI+aTJyc0BpZXRmLm9yZzwvYT48YnI+DQpTdWJqZWN0OiBS ZTogW2kycnNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtaTJycy1yaWItZGF0YS1tb2RlbC0wNC50 eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SGkgTWFjaCw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SSBhZ3JlZSB3aXRoIEFjZWXigJlzIGNv bW1lbnRzIGFuZCB3b3VsZCBlbmNvdXJhZ2UgeW91IHRvIHVzZSBnZW5lcmljL2V4aXN0aW5nIHR1 bm5lbCBtb2RlbChzKSwgcGxlYXNlIHNlZSBjb21tZW50cyBwcm92aWRlZCBkdXJpbmcgUlRHV0cg bWVldGluZyBpbiBZb2tvaGFtYS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoZXJlIGFyZSBhbHJlYWR5IHRv byBtYW55LCB3ZSBuZWVkIHRvIHJhdGlvbmFsaXplIHRoaXMgd29yay48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGhpcyBpcyB3aGF0IGhhcyBiZWVuIGRpc2N1c3NlZCBp biBZb2tvaGFtYSwgUm9iaW4gcHJlc2VudGVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPi0tIGRyYWZ0LWxpLXJ0Z3dnLXV0dW5uZWwteWFuZzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7IC0tIGRyYWZ0LWxpLXJ0Z3dnLXR1bm5lbC1wb2xpY3kteWFuZzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7IC0tIGRyYWZ0LXd3ei1uZXRtb2QteWFuZy10dW5uZWwtY2Zn PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgLS0gZHJhZnQtemhlbmctaW50YXJlYS1ncmUt eWFuZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IC0tIGRyYWZ0LWxpdS1pbnRhcmVhLWdy ZS10dW5uZWwteWFuZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IC0tIGRyYWZ0LWxpdS1p bnRhcmVhLWlwaXB2NC10dW5uZWwteWFuZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5KZWZmPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj5PbiAxMS8yMy8xNSwgMTE6NTYsICZxdW90O2kycnMgb24gYmVo YWxmIG9mIEFjZWUgTGluZGVtIChhY2VlKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmkycnMt Ym91bmNlc0BpZXRmLm9yZyUyMG9uJTIwYmVoYWxmJTIwb2YlMjBhY2VlQGNpc2NvLmNvbSI+PHNw YW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmkycnMtYm91 bmNlc0BpZXRmLm9yZw0KIG9uIGJlaGFsZiBvZiBhY2VlQGNpc2NvLmNvbTwvc3Bhbj48L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0O0hpIE1h Y2gsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7SeKAmW0g bG9va2luZyBhdCBkcmFmdC1pZXRmLWkycnMtcmliLWRhdGEtbW9kZWwtMDQudHh0IGFuZCBpdCBz dGlsbA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7aW5jbHVkZXMgYWxsIHRoZSB0dW5uZWwgZW5jYXBz LiBJIGtub3cgeW91IHJlY2VpdmVkIHNldmVyYWwgY29tbWVudHMNCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jmd0O3RoYXQgdGhvc2Ugc2hvdWxkIGJlIGluIHRoZSB0dW5uZWwgbW9kZWwocykgYW5kIHRoaXMg STJSUyBSSUIgbW9kZWwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0O3Nob3VsZCBtZXJlbHkgcmVmZXJl bmNlIGFuIGltcG9ydGVkIHR1bm5lbCBhYnN0cmFjdGlvbi4gSG93IGFyZSB5b3UNCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jmd0O2dvaW5nIHRvIGFkZHJlc3MgdGhpcz8gSXQgc2VlbWVkIHRoYXQgdGhlIGNv bnNlbnN1cyAoYW5kIGFuIG9waW5pb24NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0O3RoYXQgSSBzaGFy ZSkgd2FzIHRoYXQgdGhpcyBtb2RlbCBzaG91bGQgbm90IGF0dGVtcHQgdG8gZ2VuZXJpY2FsbHkN CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jmd0O2NyZWF0ZWQgdHVubmVscyB2aWEgUklCL0ZJQiBlbnRyaWVz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jmd0O1RoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDtBY2VlPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7T24gMTEvMjMvMTUs IDI6MjMgQU0sICZxdW90O2kycnMgb24gYmVoYWxmIG9mIE1hY2ggQ2hlbiZxdW90Ow0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4mZ3Q7Jmx0OzxhIGhyZWY9Im1haWx0bzppMnJzLWJvdW5jZXNAaWV0Zi5vcmcl MjBvbiUyMGJlaGFsZiUyMG9mJTIwbWFjaC5jaGVuQGh1YXdlaS5jb20iPjxzcGFuIHN0eWxlPSJj b2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5pMnJzLWJvdW5jZXNAaWV0Zi5v cmcgb24gYmVoYWxmIG9mIG1hY2guY2hlbkBodWF3ZWkuY29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDtIaSw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZndDsmZ3Q7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0O1dl IGp1c3QgdXBsb2FkZWQgYW4gdXBkYXRlIHRoYXQgYWRkcmVzc2VzIHRoZSBjb21tZW50cyByZWNl aXZlZA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0OyhpbmNsdWRlIG9ubGluZSBhbmQgb2ZmbGlu ZSkgcmVjZW50bHkuIFBsZWFzZSByZXZpZXcgdGhlIGRyYWZ0IGFuZCBjb21tZW50ITxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsmZ3Q7VGhhbmtzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jmd0OyZndDtNYWNoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0OyZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0OyZndDsgRnJvbTogaTJycyBbPGEgaHJlZj0ibWFpbHRv OmkycnMtYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4 dC1kZWNvcmF0aW9uOm5vbmUiPm1haWx0bzppMnJzLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9h Pl0gT24gQmVoYWxmIE9mDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsmZ3Q7Jmd0OzxhIGhyZWY9Im1h aWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0 ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L3NwYW4+ PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDsmZ3Q7IFNlbnQ6IE1vbmRheSwgTm92ZW1iZXIg MjMsIDIwMTUgMzoxNiBQTTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDsmZ3Q7IFRvOiA8YSBocmVm PSJtYWlsdG86aS1kLWFubm91bmNlQGlldGYub3JnIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5k b3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5pLWQtYW5ub3VuY2VAaWV0Zi5vcmc8L3NwYW4+ PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDsmZ3Q7IENjOiA8YSBocmVmPSJtYWlsdG86aTJy c0BpZXRmLm9yZyI+DQo8c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRp b246bm9uZSI+aTJyc0BpZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0 OyZndDsgU3ViamVjdDogW2kycnNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtaTJycy1yaWItZGF0 YS1tb2RlbC0wNC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsmZ3Q7Jmd0OyA8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZndDsmZ3Q7Jmd0OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsmZ3Q7Jmd0OyBBIE5ldyBJbnRl cm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMN CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDsmZ3Q7ZGlyZWN0b3JpZXMuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mZ3Q7Jmd0OyZndDsmbmJzcDsgVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgSW50 ZXJmYWNlIHRvIHRoZSBSb3V0aW5nIFN5c3RlbQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0OyZn dDtXb3JraW5nIEdyb3VwJm5ic3A7IG9mIHRoZSBJRVRGLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZn dDsmZ3Q7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRpdGxlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogQSBZQU5HIERhdGEgTW9kZWwg Zm9yIFJvdXRpbmcgSW5mb3JtYXRpb24gQmFzZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDsmZ3Q7 IChSSUIpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQXV0aG9ycyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IExpeGluZyBXYW5nPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m Z3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSGFy aWhhcmFuIEFuYW50aGFrcmlzaG5hbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE1hY2goR3VveWkpIENoZW48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBBbWl0IERhc3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsmZ3Q7Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTcmlnYW5lc2ggS2luaTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IE5pdGluIEJhaGFkdXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsmZ3Q7Jmd0OyAmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRmlsZW5hbWUmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOiBkcmFmdC1pZXRmLWkycnMtcmliLWRhdGEtbW9kZWwt MDQudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0OyZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IFBhZ2VzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogNjU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsmZ3Q7Jmd0 OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRGF0ZSZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IDIw MTUtMTEtMjI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsmZ3Q7Jmd0OyA8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZn dDsmZ3Q7Jmd0OyBBYnN0cmFjdDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsmZ3Q7Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBZQU5HIGRhdGEgbW9kZWwgZm9yIFJv dXRpbmcgSW5mb3JtYXRpb24gQmFzZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IChSSUIpIHRoYXQgYWxpZ25zIHdpdGggdGhlIEkyUlMgUklCIGluZm9ybWF0 aW9uIG1vZGVsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDsmZ3Q7IDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jmd0OyZndDsmZ3Q7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDsmZ3Q7IDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jmd0OyZndDsmZ3Q7IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlz IGRyYWZ0IGlzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaTJycy1yaWItZGF0YS1tb2RlbC8i Pg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaTJycy1yaWItZGF0YS1t b2RlbC88L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDsmZ3Q7IDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jmd0OyZndDsmZ3Q7IFRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxh YmxlIGF0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWkycnMtcmliLWRhdGEtbW9kZWwtMDQiPg0KPHNw YW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWkycnMtcmliLWRhdGEtbW9kZWwtMDQ8L3Nw YW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDsmZ3Q7IDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0 OyZndDsmZ3Q7IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBh dDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1pMnJzLXJpYi1kYXRhLW1vZGVsLTA0Ij4NCjxz cGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczov L3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1pMnJzLXJpYi1kYXRhLW1vZGVs LTA0PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsmZ3Q7Jmd0OyA8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZndDsmZ3Q7Jmd0OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsmZ3Q7Jmd0OyBQbGVhc2Ugbm90 ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0OyZndDtzdWJtaXNzaW9uJm5ic3A7IHVudGlsIHRoZSBo dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQNCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jmd0OyZndDsmZ3Q7dG9vbHMuaWV0Zi5vcmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0OyZn dDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0OyZndDsgSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNv IGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDsm Z3Q7IDxhIGhyZWY9ImZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvIj4NCjxzcGFu IHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5mdHA6Ly9mdHAu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLzwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7 Jmd0OyZndDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsmZ3Q7Jmd0 OyBpMnJzIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9 Im1haWx0bzppMnJzQGlldGYub3JnIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3Rl eHQtZGVjb3JhdGlvbjpub25lIj5pMnJzQGlldGYub3JnPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2kycnMiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0 aW9uOm5vbmUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJyczwvc3Bh bj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0 OyZndDtfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jmd0OyZndDtpMnJzIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0 OyZndDs8YSBocmVmPSJtYWlsdG86aTJyc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOndp bmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmkycnNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jmd0OyZndDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2kycnMiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVj b3JhdGlvbjpub25lIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2kycnM8 L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0 O19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4mZ3Q7aTJycyBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDs8YSBocmVm PSJtYWlsdG86aTJyc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4 dC1kZWNvcmF0aW9uOm5vbmUiPmkycnNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jmd0OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJy cyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJyczwvc3Bhbj48L2E+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+aTJycyBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxhIGhy ZWY9Im1haWx0bzppMnJzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0 ZXh0LWRlY29yYXRpb246bm9uZSI+aTJyc0BpZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2kycnMi PjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2kycnM8L3NwYW4+PC9hPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D279CE493EFC8aceeciscocom_-- From nobody Tue Nov 24 06:55:28 2015 Return-Path: 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 7B19F1A854C for ; Tue, 24 Nov 2015 06:55:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 nZEWJWfMSyoz for ; Tue, 24 Nov 2015 06:55:22 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A6FC1A0406 for ; Tue, 24 Nov 2015 06:55:21 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.177; From: "Susan Hares" To: "'Acee Lindem \(acee\)'" , References: <20151123071558.25655.92641.idtracker@ietfa.amsl.com> <8D628270-A455-4E01-881F-BA20D544228D@ericsson.com> <041001d12640$9d5104b0$d7f30e10$@ndzh.com> <047901d12663$cb716880$62543980$@ndzh.com> In-Reply-To: Date: Tue, 24 Nov 2015 09:55:00 -0500 Message-ID: <05ec01d126c8$183f6ea0$48be4be0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_05ED_01D1269E.2F6F0BF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLzNuIIn4QWw/Hs75J8GiGq3b7+uQJO1DWoAiHpGU0CXgkCwwFVd58VAjQ3mH8CkBQvUAHQKi79m/FU/CA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' , 'Jeff Tantsura' , 'Alia Atlas' Subject: Re: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 14:55:26 -0000 This is a multipart message in MIME format. ------=_NextPart_000_05ED_01D1269E.2F6F0BF0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Acee:=20 =20 Top of the morning on a fine snowy day.=20 =20 =20 You should also look at section 2.4.3 as well as section 7.2.1. Can you = suggest what you would like to see covered in section 7.2.1? What use = case are you trying to solve? =20 =20 None of the models described by your email are working drafts ( = draft-li-rtgwg-utunnel-yang, draft-li-rtgwg-tunnel-policy-yang, = draft-wwz-netmod-yang-tunnel-cfg, draft-zheng-intarea-gre-yang, = draft-liu-intarea-gre-tunnel-yang, and = draft-liu-intarea-ipipv4-tunnel-yang).=20 The I2RS RIB model and the tunnels have been in discussion since 2013. = Stating I2RS should change document which have gone to WG LC to follow = the work of individual drafts is not a reasonable request.=20 =20 Without further clarification of an error case your concerned about, or = a specific concern for a I2RS use case, or WG approved architectural = document with a specific set of design principles you are concerned = about, I cannot re-open a completed WG LC for the I2RS Information = Model. The I2RS RIB Data Model follows the I2RS Informational Model. = =20 =20 I will host a design team for those who I2RS Members to comment on the = incomplete routing architecture for yang models to suggest solutions for = the routing architecture. I2RS members should contact me off-list if = you wish to participate. =20 =20 =20 Cheerily,=20 =20 Sue=20 =20 From: Acee Lindem (acee) [mailto:acee@cisco.com]=20 Sent: Tuesday, November 24, 2015 8:35 AM To: Susan Hares; i2rs@ietf.org Cc: 'Alia Atlas'; 'Jeffrey Haas'; 'Jeff Tantsura' Subject: Re: [i2rs] FW: I-D Action: = draft-ietf-i2rs-rib-data-model-04.txt =20 From: Susan Hares < shares@ndzh.com> Date: Monday, November 23, 2015 at 9:57 PM To: Acee Lindem , "i2rs@ietf.org" Cc: Alia Atlas , Jeff Haas , Jeff = Tantsura Subject: RE: [i2rs] FW: I-D Action: = draft-ietf-i2rs-rib-data-model-04.txt =20 Acee:=20 =20 Is your input individual input or input from the routing architecture = for yang models? =20 Individual.=20 =20 =20 =20 =20 The routing architecture for yang models is incomplete without the = consideration of the I2RS ephemeral state and I2RS architecture. Asking = the I2RS WG to change a document that is in WG LC based on an incomplete = architectural document is not reasonable. =20 =20 My comment with respect to tunnel provisioning is not based on any = architecture document.=20 =20 An alignment between = = https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ without = the consideration of the I2RS ephemeral state is an incomplete alignment = and a problematic approach for I2RS WG=E2=80=99s efforts. =20 =20 I2RS models should augment the base models with ephemeral state.=20 =20 =20 In a volunteer organization, each person has the right to makes choices = in what they have time to do. If you do not have bandwidth to provide = an adequate routing architecture for yang models that considers = ephemeral state or its needs, that is your choice. Unless you have a = concrete proposal for the ephemeral state that covers I2RS RIB and = = https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/, the = I2RS WG LC will be closed after 2 week (11/23 =E2=80=93 12/7) WG review = of the in draft-ietf-i2rs-rib-data-model-04.txt. =20 =20 We have proposed tunnel models, draft-ietf-netmod-routing-cfg is not = meant to supplant them. BTW, we don=E2=80=99t plan to update = draft-ietf-i2rs-rib-data-model-04.txt. Updates based on I2RS will be in = the a next-hop augmentation draft that extends = draft-ietf-netmod-rtg-cfg.=20 =20 Sue =E2=80=93 Ace did you mean draft-ietf-nemod-routing-config in the = previous sentence. Your proposed tunnel models are individual drafts. = =20 =20 =20 Please remember that the I2RS RIB model has two parts: I2RS = Informational Model and I2RS Data Model. The I2RS Informational Model = and the I2RS Data Model have descriptions on the soft tunnel = provisioning as mechanisms. Questions at this point must demonstrate a = knowledge of these documents or suggest specific changes to the = documents. If you wish to raise the following questions, please do = this in light of specific sections that include both the I2RS = Informational Model, the I2RS Data Model, and I2RS architecture.=20 =20 a) I2RS tunnels must include additions beyond encapsulation,=20 b) Why the I2RS Informational Model and the I2RS Data Model do not = provide the soft tunnel provisioning or describe the specifics of this = provision? =20 =20 The I2RS Informational Model has examples for these tunnels. You are = welcome to make proposal for specific changes to the I2RS Informational = Model or the I2RS Data Model. The I2RS Informational Model has = completed WG LC so the bar for substantive comments is high. =20 I don=E2=80=99t believe this excerpt from the RIB information models = describes soft tunnel provisioning for each of the tunnels proposed in = the RIB data model: =20 7.2.1. Tunnel nexthops =20 A tunnel nexthop points to a tunnel of some kind. Traffic that goes over the tunnel gets encapsulated with the tunnel encap. Tunnel nexthops are useful for abstracting out details of the network, by having the traffic seamlessly route between network edges. At the end of a tunnel, the tunnel will get decapsulated. Thus the grammar supports two kinds of operations, one for encap and another for decap. =20 Acee=20 =20 =20 =20 =20 =20 Cheers,=20 =20 Sue Hares=20 =20 From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Acee Lindem = (acee) Sent: Monday, November 23, 2015 7:30 PM To: Susan Hares; i2rs@ietf.org Subject: Re: [i2rs] FW: I-D Action: = draft-ietf-i2rs-rib-data-model-04.txt =20 Sue,=20 =20 From: i2rs on behalf of Susan Hares = Date: Monday, November 23, 2015 at 5:45 PM To: "i2rs@ietf.org" Subject: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt =20 Resending to I2RS WG.=20 =20 From: Susan Hares [mailto:shares@ndzh.com]=20 Sent: Monday, November 23, 2015 5:33 PM To: 'Jeff Tantsura'; 'Acee Lindem (acee)'; 'Mach Chen'; 'i2rs@ietf.org' Cc: 'Jeffrey Haas'; 'Alia Atlas'; 'Benoit Claise (bclaise)' Subject: RE: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.txt =20 Jeff and Acee:=20 =20 Your suggested change goes against the WG adopted RIB Information draft = that has been discussed for over 2 years. The informational draft has = been through WG LC and you did not make any suggestions or comments = during the WG LC. Any change of this matter is not simply something you = indicate to the authors, but needs to be discussed on the WG as a = direction change for the RIB IM/DM models. =20 Independent of the I2RS efforts, milestones, and processes, I think we = need to address whether provisioning all these tunnels via RIB = installation is appropriate and, additionally, consistent with other WG = YANG models. In many cases, it would seem there are tunnel attributes = other than the encaps that need to be provisioned. At a minimum, I think = you=E2=80=99d need to either reference an RFC describing soft tunnel = provisioning or describe the specifics of this provisioning.=20 =20 =20 Prior to moving this change through WG adoption cycle, the routing = architectural team needs to have: a) concrete proposal for the ephemeral = state that covers I2RS RIB and = https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ and b) = I requested this input of Acee Lindem as a representative of the routing = architecture team. =20 =20 The identification of this problem with tunnel provisioning is a direct = outcome of this effort.=20 =20 =20 =20 I will be glad to work with you on a concrete proposal that you can send = to the email list and present at the I2RS interim meeting on 12/16/2015 = (10-11:30am ET). =20 I will continue to work on ietf-routing alignment but don=E2=80=99t have = the bandwidth for the above.=20 =20 Acee=20 =20 =20 =20 =20 =20 Sue Hares=20 =20 -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Jeff Tantsura Sent: Monday, November 23, 2015 4:27 PM To: Acee Lindem (acee); Mach Chen; i2rs@ietf.org Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.txt =20 Hi Mach, =20 I agree with Acee=E2=80=99s comments and would encourage you to use = generic/existing tunnel model(s), please see comments provided during = RTGWG meeting in Yokohama. There are already too many, we need to rationalize this work. =20 This is what has been discussed in Yokohama, Robin presented =20 -- draft-li-rtgwg-utunnel-yang -- draft-li-rtgwg-tunnel-policy-yang -- draft-wwz-netmod-yang-tunnel-cfg -- draft-zheng-intarea-gre-yang -- draft-liu-intarea-gre-tunnel-yang -- draft-liu-intarea-ipipv4-tunnel-yang =20 Cheers, Jeff =20 =20 =20 =20 =20 =20 On 11/23/15, 11:56, "i2rs on behalf of Acee Lindem (acee)" < = = i2rs-bounces@ietf.org on behalf of acee@cisco.com> wrote: =20 >Hi Mach, >=20 >I=E2=80=99m looking at draft-ietf-i2rs-rib-data-model-04.txt and it = still=20 >includes all the tunnel encaps. I know you received several comments=20 >that those should be in the tunnel model(s) and this I2RS RIB model=20 >should merely reference an imported tunnel abstraction. How are you=20 >going to address this? It seemed that the consensus (and an opinion=20 >that I share) was that this model should not attempt to generically=20 >created tunnels via RIB/FIB entries. >Thanks, >Acee >=20 >On 11/23/15, 2:23 AM, "i2rs on behalf of Mach Chen"=20 >< = = i2rs-bounces@ietf.org on behalf of mach.chen@huawei.com> wrote: >=20 >>Hi, >>=20 >>We just uploaded an update that addresses the comments received=20 >>(include online and offline) recently. Please review the draft and = comment! >>=20 >>Thanks, >>Mach >>=20 >>> -----Original Message----- >>> From: i2rs [ = mailto:i2rs-bounces@ietf.org] On Behalf Of=20 >>> internet-drafts@ietf.org >>> Sent: Monday, November 23, 2015 3:16 PM >>> To: i-d-announce@ietf.org >>> Cc: i2rs@ietf.org >>> Subject: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.txt >>>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts=20 >>>directories. >>> This draft is a work item of the Interface to the Routing System=20 >>>Working Group of the IETF. >>>=20 >>> Title : A YANG Data Model for Routing Information = Base >>> (RIB) >>> Authors : Lixing Wang >>> Hariharan Ananthakrishnan >>> Mach(Guoyi) Chen >>> Amit Dass >>> Sriganesh Kini >>> Nitin Bahadur >>> Filename : draft-ietf-i2rs-rib-data-model-04.txt >>> Pages : 65 >>> Date : 2015-11-22 >>>=20 >>> Abstract: >>> This document defines a YANG data model for Routing Information = Base >>> (RIB) that aligns with the I2RS RIB information model. >>>=20 >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> = https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/ >>>=20 >>> There's also a htmlized version available at: >>> = https://tools.ietf.org/html/draft-ietf-i2rs-rib-data-model-04 >>>=20 >>> A diff from the previous version is available at: >>> = = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2rs-rib-data-model-04 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of=20 >>>submission until the htmlized version and diff are available at=20 >>>tools.ietf.org. >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> = ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> = https://www.ietf.org/mailman/listinfo/i2rs >>=20 >>_______________________________________________ >>i2rs mailing list >> i2rs@ietf.org >> = https://www.ietf.org/mailman/listinfo/i2rs >=20 >_______________________________________________ >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 ------=_NextPart_000_05ED_01D1269E.2F6F0BF0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Acee:

 

Top of the morning on a = fine snowy day.

 

<WG Chair hat on> =

You should also look at section 2.4.3 as well as = section 7.2.1.=C2=A0 Can you suggest what you would like to see covered = in section 7.2.1?=C2=A0 What use case are you trying to solve?=C2=A0 = =C2=A0

 

None of the models = described by your email are working drafts ( draft-li-rtgwg-utunnel-yang, =  draft-li-rtgwg-tunnel-policy-yang, = draft-wwz-netmod-yang-tunnel-cfg, draft-zheng-intarea-gre-yang, = draft-liu-intarea-gre-tunnel-yang, and = draft-liu-intarea-ipipv4-tunnel-yang).

The I2RS RIB model and = the tunnels have been in discussion since 2013.=C2=A0 Stating I2RS = should change document which have gone to WG LC to follow the work of = individual drafts is not a reasonable request.

 

Without further = clarification of an error case your concerned about, or a specific = concern for a I2RS use case, or WG approved architectural document with = a specific set of design principles you are concerned about, I cannot = re-open a completed WG LC for the I2RS Information Model.=C2=A0 = =C2=A0The I2RS RIB Data Model follows the I2RS Informational = Model.=C2=A0 =C2=A0=C2=A0

 

I will host a design = team for those who I2RS Members to comment on the incomplete routing = architecture for yang models to suggest solutions for the routing = architecture. =C2=A0I2RS members should contact me off-list if you wish = to participate. =C2=A0

<WG Hat off>

 

Cheerily, =

 

Sue =

 

From:= = Acee Lindem (acee) [mailto:acee@cisco.com]
Sent: Tuesday, = November 24, 2015 8:35 AM
To: Susan Hares; = i2rs@ietf.org
Cc: 'Alia Atlas'; 'Jeffrey Haas'; 'Jeff = Tantsura'
Subject: Re: [i2rs] FW: I-D Action: = draft-ietf-i2rs-rib-data-model-04.txt

 

From: Susan Hares <shares@ndzh.com>

Date: = Monday, November 23, 2015 at 9:57 = PM
To: Acee Lindem <acee@cisco.com>, "i2rs@ietf.org" <i2rs@ietf.org>
Cc: Alia = Atlas <akatlas@gmail.com>, Jeff Haas = <jhaas@pfrc.org>, Jeff = Tantsura <jeff.tantsura@ericsson.com= >
Subject: RE: [i2rs] FW: I-D Action: = draft-ietf-i2rs-rib-data-model-04.txt

 

=

Acee: =

 

Is your input individual = input or input from the routing architecture for yang = models?

 

=

Individual. 

 

=

 

=

 

<I2RS chair hat on> =

The routing architecture for yang models is = incomplete without the consideration of the I2RS ephemeral state and = I2RS architecture.  Asking the I2RS WG to change a document that is = in WG LC based on an incomplete architectural document is not = reasonable.  

 

=

My comment with respect to tunnel = provisioning is not based on any architecture = document. 

 

=

An alignment between = https://datatracker.ietf.org/doc/draft-ietf-ne= tmod-routing-cfg/ without the consideration of the I2RS = ephemeral state is an incomplete alignment and a problematic =  approach for I2RS WG=E2=80=99s efforts. =   

 

=

I2RS models should augment the = base models with ephemeral state. 

 

=

 

In a volunteer = organization, each person has the right to makes choices in what they = have time to do.   If you do not have bandwidth to provide an = adequate routing architecture for yang models that considers ephemeral = state or its needs, that is your choice.  Unless you have a = concrete proposal for the ephemeral state that covers I2RS RIB and = https://datatracker.ietf.org/doc/draft-ietf-ne= tmod-routing-cfg/, the I2RS WG LC will be closed after 2 week = (11/23 =E2=80=93 12/7) WG review of the in = draft-ietf-i2rs-rib-data-model-04.txt.  =   

 

=

We have proposed tunnel models, = draft-ietf-netmod-routing-cfg is not meant to supplant them. BTW, we = don=E2=80=99t plan to update draft-ietf-i2rs-rib-data-model-04.txt. = Updates based on I2RS will be in the a next-hop augmentation draft that = extends = draft-ietf-netmod-rtg-cfg. 

 

Sue =E2=80=93 Ace did = you mean draft-ietf-nemod-routing-config in the previous sentence. = =C2=A0Your proposed tunnel models are individual drafts. = =C2=A0=C2=A0

 

 

 

Please remember that the = I2RS RIB model has two parts:  I2RS Informational Model and I2RS = Data Model.  The I2RS Informational Model and the I2RS Data Model = have descriptions on the soft tunnel provisioning as mechanisms.  = Questions at this point must demonstrate a knowledge of these documents = or suggest specific changes to the documents.   If you wish to = raise the following questions, please do this in light of specific = sections that include both the I2RS Informational Model, the I2RS Data = Model, and I2RS architecture.

 

a)      = I2RS tunnels = must include additions beyond encapsulation,

b)      = Why the I2RS = Informational Model and the I2RS Data Model do not provide the soft = tunnel provisioning or describe the specifics of this provision?  =

 

The I2RS Informational = Model has examples for these tunnels.  You are welcome to make = proposal for specific changes to the I2RS Informational Model or the = I2RS Data Model.  The I2RS Informational Model has completed WG LC = so the bar for substantive comments is = high.

 

=

I = don=E2=80=99t believe this excerpt from the RIB information models = describes soft tunnel provisioning for each of the tunnels proposed in = the RIB data model:

 

=

7.2.1. =  Tunnel nexthops

 

   A tunnel = nexthop points to a tunnel of some kind.  Traffic that = goes

   over the = tunnel gets encapsulated with the tunnel encap.  Tunnel

   nexthops = are useful for abstracting out details of the network, by

   having = the traffic seamlessly route between network edges.  At = the

   end of a = tunnel, the tunnel will get decapsulated.  Thus the = grammar

   supports = two kinds of operations, one for encap and another for

  =  decap.

 

=

Acee 

 

=

 

=

  =   

<I2RS chair hat off> =

 

Cheers,

 

Sue Hares

 

= From:= i2rs [mailto:i2rs-bounces@ietf.org] = On Behalf Of Acee Lindem (acee)
Sent: Monday, November = 23, 2015 7:30 PM
To: Susan Hares; i2rs@ietf.org
Subject: Re: = [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt

 

Sue, 

 

From: = i2rs <i2rs-bounces@ietf.org> on = behalf of Susan Hares <shares@ndzh.com>
Date: = Monday, November 23, 2015 at 5:45 PM
To: "i2rs@ietf.org" <i2rs@ietf.org>
Subject: = [i2rs] FW: I-D Action: = draft-ietf-i2rs-rib-data-model-04.txt

 

Resending to I2RS WG. =

 

= From:= Susan Hares [mailto:shares@ndzh.com] =
Sent: Monday, November 23, 2015 5:33 PM
To: 'Jeff = Tantsura'; 'Acee Lindem (acee)'; 'Mach Chen'; 'i2rs@ietf.org'
Cc: = 'Jeffrey Haas'; 'Alia Atlas'; 'Benoit Claise = (bclaise)'
Subject: RE: [i2rs] I-D Action: = draft-ietf-i2rs-rib-data-model-04.txt

 

Jeff and Acee: =

 

Your suggested change = goes against the WG adopted RIB Information draft that has been = discussed for over 2 years.  The informational draft has been = through WG LC and you did not make any suggestions or comments during = the WG LC.  Any change of this matter is not simply something you = indicate to the authors, but needs to be discussed on the WG as a = direction change for the RIB IM/DM = models.

 

Independent of the I2RS efforts, = milestones, and processes, I think we need to address whether = provisioning all these tunnels via RIB installation is  appropriate = and, additionally, consistent with other WG YANG models. In many cases, = it would seem there are tunnel attributes other than the encaps that = need to be provisioned. At a minimum, I think you=E2=80=99d need to = either reference an RFC describing soft tunnel provisioning or describe = the specifics of this provisioning. 

 

 

Prior to moving this = change through WG adoption cycle, the routing architectural team needs = to have: a) concrete proposal for the ephemeral state that covers I2RS = RIB and = https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ =  and  b) I requested this input of Acee Lindem as a = representative of the routing architecture team. =   

 

The =  identification of this problem with tunnel provisioning is a = direct outcome of this effort. 

 

 

 

I will be glad to work = with you on a concrete proposal that you can send to the email list and = present at the I2RS interim meeting on 12/16/2015 (10-11:30am = ET).

 

I will = continue to work on ietf-routing alignment but don=E2=80=99t have the = bandwidth for the above. 

 

Acee 

 

 

 

 

 

 Sue Hares =

 

-----Original = Message-----
From: i2rs [mailto:i2rs-bounces@ietf.org] = On Behalf Of Jeff Tantsura
Sent: Monday, November 23, 2015 4:27 = PM
To: Acee Lindem (acee); Mach Chen; i2rs@ietf.org
Subject: Re: [i2rs] = I-D Action: = draft-ietf-i2rs-rib-data-model-04.txt

 

Hi = Mach,

 

I agree with = Acee=E2=80=99s comments and would encourage you to use generic/existing = tunnel model(s), please see comments provided during RTGWG meeting in = Yokohama.

There are already too many, we need to rationalize = this work.

 

This is what has been = discussed in Yokohama, Robin presented

 

-- = draft-li-rtgwg-utunnel-yang

   -- = draft-li-rtgwg-tunnel-policy-yang

   -- = draft-wwz-netmod-yang-tunnel-cfg

   -- = draft-zheng-intarea-gre-yang

   -- = draft-liu-intarea-gre-tunnel-yang

   -- = draft-liu-intarea-ipipv4-tunnel-yang

 

Cheers,

Jeff

 

 

 

 

 

 

On 11/23/15, 11:56, = "i2rs on behalf of Acee Lindem (acee)" <i2rs-bounces@ietf.org on = behalf of acee@cisco.com> wrote:

 

>Hi = Mach,

> 

>I=E2=80=99m looking = at draft-ietf-i2rs-rib-data-model-04.txt and it still =

>includes all the tunnel encaps. I know you = received several comments

>that those should = be in the tunnel model(s) and this I2RS RIB model =

>should merely reference an imported tunnel = abstraction. How are you

>going to address = this? It seemed that the consensus (and an opinion =

>that I share) was that this model should not = attempt to generically

>created tunnels via = RIB/FIB entries.

>Thanks,

>Acee

> 

>On 11/23/15, 2:23 = AM, "i2rs on behalf of Mach Chen"

><i2rs-bounces@ietf.org on = behalf of mach.chen@huawei.com> = wrote:

> 

>>Hi,

>> 

>>We just = uploaded an update that addresses the comments received =

>>(include online and offline) recently. = Please review the draft and comment!

>> 

>>Thanks,

>>Mach

>> 

>>> = -----Original Message-----

>>> From: i2rs = [mailto:i2rs-bounces@ietf.= org] On Behalf Of

>>>internet-drafts@ietf.org<= /span>

>>> Sent: Monday, November 23, 2015 3:16 = PM

>>> To: i-d-announce@ietf.org

>>> Cc: i2rs@ietf.org<= o:p>

>>> Subject: [i2rs] I-D Action: = draft-ietf-i2rs-rib-data-model-04.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.

>>>

>>>      &nb= sp;  = Title           : A = YANG Data Model for Routing Information Base

>>> = (RIB)

>>>      &nb= sp;  Authors         : = Lixing Wang

>>>      &nb= sp;           &nbs= p;        Hariharan = Ananthakrishnan

>>>      &nb= sp;           &nbs= p;        Mach(Guoyi) = Chen

>>>      &nb= sp;           &nbs= p;        Amit = Dass

>>>      &nb= sp;           &nbs= p;        Sriganesh = Kini

>>>      &nb= sp;           &nbs= p;        Nitin = Bahadur

>>>        = Filename        : = draft-ietf-i2rs-rib-data-model-04.txt

>>> =        = Pages           : = 65

>>>        = Date            : = 2015-11-22

>>>

>>> = Abstract:

>>>    This document = defines a YANG data model for Routing Information = Base

>>>    (RIB) that aligns = with the I2RS RIB information model.

>>> =

>>>

>>> =

>>> The IETF datatracker status page for = this draft is:

>>> https://datatracker.ietf.= org/doc/draft-ietf-i2rs-rib-data-model/

<= p class=3DMsoPlainText>>>> =

>>> There's also a htmlized version = available at:

>>> https://tools.ietf.org/ht= ml/draft-ietf-i2rs-rib-data-model-04

>>> =

>>> A diff from the previous version is = available at:

>>> https://www.ietf.org/rfcd= iff?url2=3Ddraft-ietf-i2rs-rib-data-model-04=

>>> =

>>>

>>> 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/intern= et-drafts/

>>>

>>> = _______________________________________________

>>> i2rs = mailing list

>>> i2rs@ietf.org<= o:p>

>>> https://www.ietf.org/mail= man/listinfo/i2rs

>> 

>>___________________________________________= ____

>>i2rs mailing list

>>i2rs@ietf.org<= o:p>

>>https://www.ietf.org/mail= man/listinfo/i2rs

> 

>_______________________________________________=

>i2rs mailing list

>i2rs@ietf.org<= o:p>

>https://www.ietf.org/mail= man/listinfo/i2rs

_______________________________________________

i2rs mailing list

i2rs@ietf.org<= o:p>

https://www.ietf.org/mail= man/listinfo/i2rs

------=_NextPart_000_05ED_01D1269E.2F6F0BF0-- From nobody Tue Nov 24 07:33:16 2015 Return-Path: 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 B17E41A88B2 for ; Tue, 24 Nov 2015 07:33:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.186 X-Spam-Level: X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham 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 0us_-qIGkp-a for ; Tue, 24 Nov 2015 07:33:09 -0800 (PST) Received: from smtptc.telefonica.com (smtptc.telefonica.com [195.76.34.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05E1D1A8883 for ; Tue, 24 Nov 2015 07:33:09 -0800 (PST) Received: from smtptc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0FBE26021F; Tue, 24 Nov 2015 16:33:06 +0100 (CET) Received: from ESTGVMSP105.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtptc.telefonica.com (Postfix) with ESMTPS id EAD7E601AC; Tue, 24 Nov 2015 16:33:05 +0100 (CET) Received: from emea01-db3-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.92.6.51) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 24 Nov 2015 16:33:05 +0100 Received: from DB4PR06MB0639.eurprd06.prod.outlook.com (10.161.13.145) by DB4PR06MB0639.eurprd06.prod.outlook.com (10.161.13.145) with Microsoft SMTP Server (TLS) id 15.1.331.20; Tue, 24 Nov 2015 15:32:03 +0000 Received: from DB4PR06MB0639.eurprd06.prod.outlook.com ([10.161.13.145]) by DB4PR06MB0639.eurprd06.prod.outlook.com ([10.161.13.145]) with mapi id 15.01.0331.019; Tue, 24 Nov 2015 15:32:03 +0000 From: PEDRO ANDRES ARANDA GUTIERREZ To: Russ White <7riw77@gmail.com>, 'Jeffrey Haas' Thread-Topic: [i2rs] Conversation on Priority and Panes Thread-Index: AQHRIwm/+3O1h73j5ke4p1jGIHLAp56kkHqAgABJfACAABYNgP//88AAgARhSwCAAEOjgIAB3IYA Date: Tue, 24 Nov 2015 15:32:03 +0000 Message-ID: <0EAC7123-CECA-4C34-B5E3-E89F0C8DBF94@telefonica.com> References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> <563A97AA.5020308@joelhalpern.com> <00f301d11761$61699130$243cb390$@gmail.com> <563AA59C.4060809@joelhalpern.com> <018101d11764$66b82e50$34288af0$@gmail.com> <20151119203509.GA22415@pfrc.org> <5B54713B-CDE6-4F65-BE79-91F5B9FF3850@telefonica.com> <008d01d12390$064987c0$12dc9740$@gmail.com> <99B64F3B-20A1-4D3C-A445-46D235EDB44D@telefonica.com> <014a01d12394$ec5ffa60$c51fef20$@gmail.com> <87361DB1-DC6F-4023-A807-4003B436B472@telefonica.com> <012501d125e7$62e457e0$28ad07a0$@gmail.com> In-Reply-To: <012501d125e7$62e457e0$28ad07a0$@gmail.com> Accept-Language: es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151105 authentication-results: spf=none (sender IP is ) smtp.mailfrom=pedroa.aranda@telefonica.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [143.233.5.6] x-microsoft-exchange-diagnostics: 1; DB4PR06MB0639; 5:vb4XpbXfkTulReFdtrGTwRMi214uFASwn4jIdRIN9tvPEtUhOje+ZEAYOKqimqspEBEccK1YgH5Kpdv8HLZPDhaKiDZACUq2y2rLp4BVQalp+Og1gzaoFD0Y58QqUQETo6pJ/VXTWkcZ5wBMzJYJpg==; 24:JgRkFeb8cz2qBwNOEs5FbnEcO1UA/uGOg+AZ9kl+qHU7Usr1GqEuQF0TyuAsaCL32pCH0knWfTvG7h90/Cn2wk6KBzq572Z81SfyKY8fI9Y= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB0639; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(40392960112811); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(10201501046); SRVR:DB4PR06MB0639; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0639; x-forefront-prvs: 0770F75EA9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(59124004)(199003)(189002)(5007970100001)(97736004)(189998001)(5008740100001)(11100500001)(66066001)(77096005)(36756003)(2900100001)(92566002)(3846002)(586003)(81156007)(102836003)(93886004)(40100003)(5001770100001)(4001350100001)(10400500002)(122556002)(5001960100002)(76176999)(106356001)(2950100001)(105586002)(50986999)(575784001)(86362001)(87936001)(6116002)(19580405001)(54356999)(19580395003)(83716003)(5002640100001)(5004730100002)(83506001)(101416001)(106116001)(33656002)(82746002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB0639; H:DB4PR06MB0639.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <3C4F068C1E6FAF4A88335216E0A41AD3@eurprd06.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Nov 2015 15:32:03.2914 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB0639 X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: Cc: "i2rs@ietf.org" , "'Joel M. Halpern'" , 'Andy Bierman' , 'Susan Hares' Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 15:33:14 -0000 SGkgUnVzcywNCg0KSeKAmW0gdHJ5aW5nIHRvIGlkZW50aWZ5IHRoZSBkaWZmZXJlbmNlcyBiZXR3 ZWVuIGludGVyYWN0aW9ucyB3aXRoIHJvdXRpbmcgcHJvdG9jb2xzIGluIEkyUlMgYW5kIHdoYXQg aXMgcHVyZWx5IGNvbmZsaWN0cyBiZXR3ZWVuIGNsaWVudHMuIEN1cnJlbnRseSBJIHNlZSB0b28g bWFueSBpc3N1ZXMgb3ZlcmxhcHBpbmcgYW5kIEkgZmVhciB0aGF0IHRoZSB0cmVlcyBhcmUgbm90 IGxldHRpbmcgdXMgc2VlIHRoZSBmb3Jlc3QuDQoNClNvIG15IHRha2Ugb24gcm91dGluZyBwcm90 b2NvbHMgYW5kIHdlZGdpZXMgbWlnaHQgaGF2ZSBiZWVuIHRvbyBjb21wYWN0IDotKSBMZXQgbWUg Z2l2ZSBpdCBhIHNlY29uZCB0cnk6IFN0ZXBwaW5nIG91dHNpZGUgdGhlIEkyUlMgcHJvYmxlbSBz cGFjZSwgdGhlcmUgaXMgYSBsb3Qgb2Ygd29yayB0aGF0IHNob3dzIHRoYXQgdGhlIG9yaWdpbiBm b3IgQkdQLTQgaW5zdGFiaWxpdHkgaXMgdGhhdCBvdXIgYmVsb3ZlZCByb3V0ZS1tYXBzIGNyZWF0 ZSBtZXRyaWNzIHRoYXQgYXJlIG5vdCBtb25vdG9uaWNhbGx5IGluY3JlYXNpbmcgb3IgZGVjcmVh c2luZyBhbmQgdGhhdCBtYWtlcyB0aGUgcm91dGluZyBwcm90b2NvbHMgbWV0YS1zdGFibGUuIChC VFcsIEnigJltIHRoZSBmaXJzdCBjdWxwcml0IHdoZW4gaXQgY29tZXMgdG8gdGhlIHVzZSBvZiB0 aGVtLCBJIGhhdmUgY3JlYXRlZCBtb3JlIHRoYW4gb25lIHdlZGdpZSA6LVAgKSBBY2tub3dsZWRn aW5nIHRoYXQgdGhpcyBpcyBhIHNpZ25pZmljYW50IChhbmQgcXVpdGUgY29tcGxleCkgcHJvYmxl bSBmb3IgdGhlIEludGVybmV0IGluIGdlbmVyYWwsIEkgZmVlbCB0aGF0IGl0IHNob3VsZCBiZSB0 cmVhdGVkIHNvbWV3aGVyZSBlbHNlIChHUk9XPykuDQoNClRoZSBwZXJzcGVjdGl2ZSBJIHdvdWxk IGxpa2UgdG8gdGFrZSBoZXJlIGlzOg0KLSBhc3N1bWUgdGhhdCB3ZSBoYXZlIHR3byBvciBtb3Jl IGNsaWVudHMgdGhhdCBwcm9kdWNlIHBlcmZlY3RseSBzb3VuZCByb3V0aW5nIGluZm9ybWF0aW9u IChubyB3ZWRnaWVzIHRoZXJlKQ0KLSBhc3N1bWUgdGhleSB0YWxrIHRvIHRoZSBzYW1lIGFnZW50 DQotIG5vdyBteSBxdWVzdGlvbnMNCiAgICAgICAgMS4tIGlzIHRoZXJlIGFueSB3YXkgdG8gZGV0 ZWN0IHdoZXRoZXIgdGhlIGNsaWVudHMgcHJvZHVjZSBjb250cmFkaWN0aW5nL2NvbmZsaWN0aW5n IGluZm9ybWF0aW9uPw0KICAgICAgICAyLi0gaXMgdGhlcmUgYW55IHdheSB0byByZXNvbHZlIHRo ZXNlIGNvbnRyYWRpY3Rpb25zL2NvbmZsaWN0cz8NCg0KQlIsIC9QQQ0KLS0tDQpEci4gUGVkcm8g QS4gQXJhbmRhIEd1dGnDqXJyZXoNCg0KVGVjaG5vbG9neSBFeHBsb3JhdGlvbiAtDQpOZXR3b3Jr IElubm92YXRpb24gJiBWaXJ0dWFsaXNhdGlvbg0KZW1haWw6IHBlZHJvYSBkMHQgYXJhbmRhIEF0 IHRlbGVmb25pY2EgZDB0IGNvbQ0KVGVsZWbDs25pY2EsIEludmVzdGlnYWNpw7NuIHkgRGVzYXJy b2xsbw0KQy8gWnVyYmFyw6FuLDEyDQoyODAxMCBNYWRyaWQsIFNwYWluDQoNCkZyYWdlbiBzaW5k IG5pY2h0IGRhLCB1bSBiZWFudHdvcnRldCB6dSB3ZXJkZW4uDQpGcmFnZW4gc2luZCBkYSwgdW0g Z2VzdGVsbHQgenUgd2VyZGVuLg0KR2VvcmcgS3JlaXNsZXINCg0KDQoNCg0KDQoNCg0KDQotLS0t LU1lbnNhamUgb3JpZ2luYWwtLS0tLQ0KRGU6IFJ1c3MgV2hpdGUgPDdyaXc3N0BnbWFpbC5jb20+ DQpGZWNoYTogbHVuZXMsIDIzIGRlIG5vdmllbWJyZSBkZSAyMDE1LCAxNDowNg0KUGFyYTogcGFh ZyA8cGVkcm9hLmFyYW5kYUB0ZWxlZm9uaWNhLmNvbT4sICdKZWZmcmV5IEhhYXMnIDxqaGFhc0Bw ZnJjLm9yZz4NCkNDOiAiaTJyc0BpZXRmLm9yZyIgPGkycnNAaWV0Zi5vcmc+LCAiJ0pvZWwgTS4g SGFscGVybiciIDxqbWhAam9lbGhhbHBlcm4uY29tPiwgJ0FuZHkgQmllcm1hbicgPGFuZHlAeXVt YXdvcmtzLmNvbT4sIFN1ZSBIYXJlcyA8c2hhcmVzQG5kemguY29tPg0KQXN1bnRvOiBSRTogW2ky cnNdIENvbnZlcnNhdGlvbiBvbiBQcmlvcml0eSBhbmQgUGFuZXMNCg0KPg0KPj4gUmUgdGhlIG1l dHJpYyAncHJvYmxlbScsIGp1c3QgdG8gYmUgbW9yZSBwcmVjaXNlIGluIHdoYXQgd291bGQgYmUg bmVlZGVkLA0KPj4gd2UgYXJlIGxvb2tpbmcgYSBtZXRyaWMgdGhhdCBncm93cyBvciBkZWNyZWFz ZXMgbW9ub3RvbmljYWxseSBhY3Jvc3MgdGhlDQo+PiB3aG9sZSBuZXR3b3JrLg0KPg0KPkkgYXNz dW1lIHlvdSBtZWFuIGluIHRoZSByb3V0aW5nIHNwYWNlLCBhbmQgbm90IGluIHRoZSBjb250cm9s bGVyL2NsaWVudCBzcGFjZSwgY29ycmVjdD8gSW4gdGVybXMgb2YgYSBkaXN0cmlidXRlZCBwcm90 b2NvbD8gU28sIHlvdSdyZSBzYXlpbmcgdGhlIGRlbGF5IGNvdWxkIHVzZSAibWV0cmljcyIgYmV0 d2VlbiAxMSBhbmQgMjAsIHdoaWxlIHRoZSBiYW5kd2lkdGggY291bGQgdXNlICJtZXRyaWNzIiBi ZXR3ZWVuIDIxIGFuZCAzMCwgZXRjPyBBbmQgdGhlbiB5b3UganVzdCBhZGQgdGhlbSBhbGwgdG9n ZXRoZXI/IFRoYXQncyB3aGF0IElTLUlTIGhhcyBkb25lIGZvciB5ZWFycy4uLiBFdmVuIEJHUCBy ZWFsbHkgb25seSBoYXMgb25lICJtZXRyaWMsIiB3aXRoIGZvbGxvd2luZyAidGllIGJyZWFrZXJz Li4uIiBTbyBpZiB5b3UgaGF2ZSBzb21ldGhpbmcgbGlrZSB3ZWlnaHQvbG9jYWwgcHJlZi9ldGMs IHN1Y2ggdGhhdCB0aGV5IG9jY3VweSBkaWZmZXJlbnQgInNwYWNlcyIgaW4gYSBiaXQgcGF0dGVy biAoc29tZXRoaW5nIHN1Z2dlc3RlZCwgYnR3LCBpbiB0aGUgb3JpZ2luYWwgd2lkZSBjb21tdW5p dHkgd29yaywgYW5kIGluIG90aGVyIHBsYWNlcywgYXMgd2VsbCksIHlvdSdyZSBhY3R1YWxseSBq dXN0IGJ1aWxkaW5nIGEgc2luZ2xlIG1ldHJpYy4NCj4NCj5Zb3UndmUgbm90ICJzb2x2ZWQiIHRo ZSBtdWx0aXBsZSBtZXRyaWMgcHJvYmxlbSAtLSBqdXN0IGRvbmUgc29tZXRoaW5nIGEgbGl0dGxl IGRpZmZlcmVudCB0aGFuIEVJR1JQJ3MgSyB2YWx1ZXMgdG8gY29tYmluZSB0aGVtIGludG8gYSBz aW5nbGUgbWV0cmljLCB3aGljaCBpcyB3aGVyZSB5b3UgbmVlZCB0byBiZSB0byBoYXZlIHRoZSBh YmlsaXR5IHRvIGJ1aWxkIGEgc2luZ2xlIHN0YWJsZSBTUFQvREFHLg0KPg0KPj4gVGhlIHRoZW9y ZXRpY2FsIGdyb3VuZHMgZm9yIHRoaXMgYXJlIGluIFQuIEdyaWZmaW7igJlzIGFuZA0KPj4gU29i cmluaG/igJlzIHdvcmsgb24gQkdQLTQgYW5kIHRoYXQgbGllcyBhbHJlYWR5IGEgY291cGxlIG9m IHllYXJzIGFnbyBhbmQgdGhhdA0KPj4gbWFrZXMgdGhlIGFuYWx5c2lzIG11Y2gg4oCYZWFzaWVy 4oCZIChubyB3b3JyaWVzIGFib3V0IG5wKGNvbXBsZXRlKSBwcm9ibGVtcywNCj4+IGV0Yy4pLiBU aGlzIGNvdWxkIGJlIGFwcGxpZWQgaW4gSTJSUyBhdCB0aGUgcm91dGluZyBwcm90b2NvbCBsZXZl bC4gU28sIHdlIGNvdWxkDQo+PiBkaXNjdXNzIHdoZXJlIHRoYXQgc2l0cyAoc2hvdWxkIGJlIHRo ZSBjbGllbnRzLCByaWdodD8pIGFuZCBJIGRvbuKAmXQga25vdyBpZg0KPj4gdGhhdOKAmXMgYmVl biBhbHJlYWR5IGRvbmUsIHNpbmNlIEnigJltIHF1aXRlIG5ldyB0byB0aGlzIGxpc3QuDQo+DQo+ VGhpcyBkb2VzbuKAmXQgYXBwbHkgdG8gdGhlIHByb2JsZW0gYXQgaGFuZCwgdGhvdWdoLi4uIFlv dSBzZWVtIHRvIGJlIHNheWluZyAoY2xhcmlmeSBpZiB3cm9uZykgLS0NCj4NCj4xLiBHaXZlIGVh Y2ggY2xpZW50IHNvbWUgc2V0IG9mIGJpdHMgb3V0IG9mIGEgMTI4IGJpdCBudW1iZXIgc3BhY2Ug KG9yIGxhcmdlciwgZXRjLikNCj4yLiBFYWNoIGNsaWVudCBjYW4gaGF2ZSBkaWZmZXJlbnQgIm1l dHJpY3MiIHdpdGhpbiB0aGVpciBvd24gbnVtYmVyIHNwYWNlDQo+My4gV2hlbiBhIGNsaWVudCBh dHRlbXB0cyB0byBhZGQgc29tZSBlcGhlbWVyYWwgc3RhdGUsIHRoZXkgdXNlIGEgbWV0cmljIHdp dGhpbiB0aGVpciAic3BhY2UiDQo+NC4gVGhlIGFnZW50IGNhbiBqdXN0IHVzZSB0aGUgc3RyYWln aHQgbnVtYmVyIGFzIGEgcmVsYXRpdmUgcHJpb3JpdHkgZm9yIGVhY2ggcG90ZW50aWFsIHBpZWNl IG9mIHN0YXRlDQo+DQo+VGhpcyBkb2Vzbid0IGRvIGFueXRoaW5nIGRpZmZlcmVudCB0aGFuIHRo ZSBjdXJyZW50IGNvbmNlcHQgb2YgcHJpb3JpdHkgYmV0d2VlbiBjbGllbnRzLCBvbmx5IGluIHRo ZSBjdXJyZW50IHBsYW4gZWFjaCBjbGllbnQgb25seSBoYXMgb25lIHByaW9yaXR5LCByYXRoZXIg dGhhbiBtdWx0aXBsZXMuIEkgZG9uJ3Qgc2VlIHdoZXJlIHRoaXMgcmVsYXRlcyB0byB0aGUgcHJv YmxlbSBhdCBoYW5kLg0KPg0KPj4gTm93LCBoYXZpbmcg4oCcc29sdmVk4oCdIHRoYXQgcGFydCBv ZiB0aGUgZXF1YXRpb24gOi0pICwgdGhlIHBhcnQgdGhhdCBpbnRlcmVzdHMgbWUNCj4+IG1vcmUg aXMgdGhlIGNvbmZsaWN0aW5nIGNsaWVudHMgcHJvYmxlbSwgYmVjYXVzZSB0aGlzIGNvdWxkIGJl IGdlbmVyYWxpc2VkIHRvDQo+PiBvdGhlciBwcm9ibGVtIHNwYWNlcyBpbiB0aGUgU0ROIGFyZWEu IEkgZG8gYWdyZWUgdGhhdCBhZ2VudHMgc2hvdWxkIGJlIGFibGUNCj4+IHRvIGNhdGNoIG9mZmVu ZGluZyBzdGF0ZSBiZWZvcmUgaW5zdGFsbGluZyBpdCBhbmQgSeKAmW0gbG9va2luZyBmb3Igd2F5 cyB0byBzcGVjaWZ5DQo+PiBhIG1pbmltYWwgc2V0IG9mIGZlYXR1cmVzIHRoYXQgbmVlZCB0byBi ZSBzdXBwb3J0ZWQgYXQgcHJvdG9jb2wgbGV2ZWwuDQo+Pg0KPj4gQW55b25lIGVsc2UgaW50ZXJl c3RlZD8NCj4NCj5UaGlzIGlzIHByZWNpc2VseSB3aGVyZSB0aGUgcHJvYmxlbSBsaWVzLiBBbmQg dGhpcyBpcyB3aGVyZSB5b3UncmUgZ29pbmcgdG8gaGl0IHRoZSBDQVAgdGhlb3JlbSBpbiBmdWxs IGZvcmNlLiBUaGVyZSBhcmUgb25seSBhIGZldyBjaG9pY2VzIC0tDQo+DQo+MS4gTWFrZSB0aGUg ZGF0YWJhc2UgZXZlbnR1YWxseSBjb25zaXN0ZW50DQo+Mi4gU2h1dCBkb3duIGFjY2Vzc2liaWxp dHkgZHVyaW5nIGNoYW5nZXMNCj4zLiA/Pw0KPg0KPigxKSBpcyB0aGUgaWRlYSBvZiBlaXRoZXIg aGF2aW5nIHRoZSBhZ2VudCBjYWxsIGJhY2sgdG8gYWxsIHRoZSBjbGllbnRzIHdoZW4gc3RhdGUg dGhleSBpbnN0YWxsZWQgaXMgb3ZlcndyaXR0ZW4gb3IgYWxsb3dpbmcgdGhlIGFnZW50IHRvIGxv Y2FsbHkgc3RvcmUgc29tZSBzdGF0ZSB3aGVyZSBpdCBhbHJlYWR5IGhhcyB0aGUgaW5mb3JtYXRp b24gaW4gaGFuZCBhbmQgaW5zdGFsbCBpdCBsb2NhbGx5IC0tIHRoZSBvbmx5IHJlYWwgZGlmZmVy ZW5jZSBiZXR3ZWVuIHRoZXNlIHR3byBzb2x1dGlvbnMgaXMgdGhlICJiYWxhbmNlIG9mIGNvbXBs ZXhpdHkgdmVyc3VzIHNwZWVkLi4uIiBUaGUgZW50aXJlIGRpc2N1c3Npb24gaGVyZSBpcyBob3cg bXVjaCBhZGRpdGlvbmFsIGNvbXBsZXhpdHkgYXJlIHdlIGFjdHVhbGx5IGFkZGluZyBieSBkb2lu ZyAicGFuZXMgb2YgZ2xhc3MsIiB3aGljaCBhcmUganVzdCBsb2NhbGx5IHN0b3JlZCBzdGF0ZSB3 aGljaCBpc24ndCBjdXJyZW50bHkgaW5zdGFsbGVkLiBJJ20gYXJndWluZyB0aGF0IHRoZXJlJ3Mg bWluaW1hbCBjb21wbGV4aXR5IGFkZGVkIHRoYXQgeW91J3JlIG5vdCBhbHJlYWR5IGdvaW5nIHRv IGhhdmUgaW4gdGhlIHN5c3RlbSB0byBhbGxvdyB0aGUgYWdlbnQgdG8gc3RvcmUgaW5mb3JtYXRp b24gbG9jYWxseSBfaWZfIGl0IGNob29zZXMgdG8uIEplZmYgaXMgYXJndWluZyAoSSB0aGluaykg dGhhdCB0aGUgInBhbmVzIG9mIGdsYXNzIiBjb25jZXB0IGlzIGEgY29oZXJlbnQgd2F5IG9mIGxv b2tpbmcgYXQgdGhpcyBwcm9ibGVtIHRoYXQgd2lsbCBoZWxwIHVzIHVuZGVyc3RhbmQgYW5kIG1h bmFnZSB0aGUgY29tcGxleGl0eSBpbiBhIHdheSB0aGF0IG1ha2VzIHNlbnNlLiBKb2VsIGlzIGFy Z3VpbmcgKEkgdGhpbmspIHRoYXQgdGhpcyBzb3J0IG9mIHNvbHV0aW9uIGlzIG91dCBvZiB0aGUg V0cgY2hhcnRlciwgYW5kIGl0J3MgdG9vIGNvbXBsZXguIEkgX3RoaW5rXyBJIGhhdmUgdGhlIHRo cmVlIGdlbmVyYWwgcGVyc3BlY3RpdmVzIHJpZ2h0LCBidXQgSSBkb24ndCBrbm93IGlmIEkgcmVh bGx5IGhhdmUgc28uLi4gOi0pDQo+DQo+KDIpIGlzIHRoZSBpZGVhIG9mIGxvY2tpbmcgdGhlIGRh dGFiYXNlIHdoaWxlIHlvdSdyZSBjaGFuZ2luZyBpdC4gVGhpcyBpcyBleHBsaWNpdGx5IG91dHNp ZGUgdGhlIHNjb3BlIG9mIEkyUlMgZW50aXJlbHksIGdpdmVuIHdlJ3JlIHRyeWluZyB0byBkZXNp Z24gc29tZXRoaW5nIHRoYXQncyBhdG9taWMvcmVzdGZ1bC4gVGhlcmUgYXJlIGEgbG90IG9mIHRl Y2huaXF1ZXMgeW91IGNhbiB1c2UgdG8gc3BlZWQgdXAgbG9ja2luZyAtLSByb3cgbG9ja2luZywg c2hhcmRpbmcsIGV0Yy4gLS0gYnV0IG5vbmUgb2YgdGhlc2UgYXJlIGludGVyZXN0aW5nIGZyb20g dGhlIEkyUlMgcGVyc3BlY3RpdmUuDQo+DQo+Oi0pDQo+DQo+UnVzcw0KPg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KDQpFc3RlIG1lbnNhamUgeSBzdXMgYWRqdW50b3Mgc2Ug ZGlyaWdlbiBleGNsdXNpdmFtZW50ZSBhIHN1IGRlc3RpbmF0YXJpbywgcHVlZGUgY29udGVuZXIg aW5mb3JtYWNpw7NuIHByaXZpbGVnaWFkYSBvIGNvbmZpZGVuY2lhbCB5IGVzIHBhcmEgdXNvIGV4 Y2x1c2l2byBkZSBsYSBwZXJzb25hIG8gZW50aWRhZCBkZSBkZXN0aW5vLiBTaSBubyBlcyB1c3Rl ZC4gZWwgZGVzdGluYXRhcmlvIGluZGljYWRvLCBxdWVkYSBub3RpZmljYWRvIGRlIHF1ZSBsYSBs ZWN0dXJhLCB1dGlsaXphY2nDs24sIGRpdnVsZ2FjacOzbiB5L28gY29waWEgc2luIGF1dG9yaXph Y2nDs24gcHVlZGUgZXN0YXIgcHJvaGliaWRhIGVuIHZpcnR1ZCBkZSBsYSBsZWdpc2xhY2nDs24g dmlnZW50ZS4gU2kgaGEgcmVjaWJpZG8gZXN0ZSBtZW5zYWplIHBvciBlcnJvciwgbGUgcm9nYW1v cyBxdWUgbm9zIGxvIGNvbXVuaXF1ZSBpbm1lZGlhdGFtZW50ZSBwb3IgZXN0YSBtaXNtYSB2w61h IHkgcHJvY2VkYSBhIHN1IGRlc3RydWNjacOzbi4NCg0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l ZCBpbiB0aGlzIHRyYW5zbWlzc2lvbiBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgaW5m b3JtYXRpb24gaW50ZW5kZWQgb25seSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBl bnRpdHkgbmFtZWQgYWJvdmUuIElmIHRoZSByZWFkZXIgb2YgdGhpcyBtZXNzYWdlIGlzIG5vdCB0 aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBk aXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24gb3IgY29weWluZyBvZiB0aGlzIGNvbW11bmljYXRp b24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFu c21pc3Npb24gaW4gZXJyb3IsIGRvIG5vdCByZWFkIGl0LiBQbGVhc2UgaW1tZWRpYXRlbHkgcmVw bHkgdG8gdGhlIHNlbmRlciB0aGF0IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlv biBpbiBlcnJvciBhbmQgdGhlbiBkZWxldGUgaXQuDQoNCkVzdGEgbWVuc2FnZW0gZSBzZXVzIGFu ZXhvcyBzZSBkaXJpZ2VtIGV4Y2x1c2l2YW1lbnRlIGFvIHNldSBkZXN0aW5hdMOhcmlvLCBwb2Rl IGNvbnRlciBpbmZvcm1hw6fDo28gcHJpdmlsZWdpYWRhIG91IGNvbmZpZGVuY2lhbCBlIMOpIHBh cmEgdXNvIGV4Y2x1c2l2byBkYSBwZXNzb2Egb3UgZW50aWRhZGUgZGUgZGVzdGluby4gU2UgbsOj byDDqSB2b3NzYSBzZW5ob3JpYSBvIGRlc3RpbmF0w6FyaW8gaW5kaWNhZG8sIGZpY2Egbm90aWZp Y2FkbyBkZSBxdWUgYSBsZWl0dXJhLCB1dGlsaXphw6fDo28sIGRpdnVsZ2HDp8OjbyBlL291IGPD s3BpYSBzZW0gYXV0b3JpemHDp8OjbyBwb2RlIGVzdGFyIHByb2liaWRhIGVtIHZpcnR1ZGUgZGEg bGVnaXNsYcOnw6NvIHZpZ2VudGUuIFNlIHJlY2ViZXUgZXN0YSBtZW5zYWdlbSBwb3IgZXJybywg cm9nYW1vcy1saGUgcXVlIG5vcyBvIGNvbXVuaXF1ZSBpbWVkaWF0YW1lbnRlIHBvciBlc3RhIG1l c21hIHZpYSBlIHByb2NlZGEgYSBzdWEgZGVzdHJ1acOnw6NvDQo= From nobody Tue Nov 24 07:37:08 2015 Return-Path: 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 EF4AD1A8850 for ; Tue, 24 Nov 2015 07:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 qoWUhWQ-4ZqX for ; Tue, 24 Nov 2015 07:37:04 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD6D61A8855 for ; Tue, 24 Nov 2015 07:37:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 6D541251341; Tue, 24 Nov 2015 07:37:04 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 7E506250A2A; Tue, 24 Nov 2015 07:37:03 -0800 (PST) To: PEDRO ANDRES ARANDA GUTIERREZ , Russ White <7riw77@gmail.com>, 'Jeffrey Haas' References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> <563A97AA.5020308@joelhalpern.com> <00f301d11761$61699130$243cb390$@gmail.com> <563AA59C.4060809@joelhalpern.com> <018101d11764$66b82e50$34288af0$@gmail.com> <20151119203509.GA22415@pfrc.org> <5B54713B-CDE6-4F65-BE79-91F5B9FF3850@telefonica.com> <008d01d12390$064987c0$12dc9740$@gmail.com> <99B64F3B-20A1-4D3C-A445-46D235EDB44D@telefonica.com> <014a01d12394$ec5ffa60$c51fef20$@gmail.com> <87361DB1-DC6F-4023-A807-4003B436B472@telefonica.com> <012501d125e7$62e457e0$28ad07a0$@gmail.com> <0EAC7123-CECA-4C34-B5E3-E89F0C8DBF94@telefonica.com> From: "Joel M. Halpern" Message-ID: <56548418.6060603@joelhalpern.com> Date: Tue, 24 Nov 2015 10:36:56 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <0EAC7123-CECA-4C34-B5E3-E89F0C8DBF94@telefonica.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "i2rs@ietf.org" , "'Joel M. Halpern'" , 'Andy Bierman' , 'Susan Hares' Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 15:37:07 -0000 I believe that determining whether two independent and internally consistent sets of changes can, in combination, produce a wedgie or other failure is a research problem. As far as I know, the I2RS working group concluded that it was a sufficiently hard problem that we did not expect the I2RS agent to get involved in trying to detect, much less remediate, such cross-object inconsistencies. Yours, Joel On 11/24/15 10:32 AM, PEDRO ANDRES ARANDA GUTIERREZ wrote: > Hi Russ, > > I’m trying to identify the differences between interactions with routing protocols in I2RS and what is purely conflicts between clients. Currently I see too many issues overlapping and I fear that the trees are not letting us see the forest. > > So my take on routing protocols and wedgies might have been too compact :-) Let me give it a second try: Stepping outside the I2RS problem space, there is a lot of work that shows that the origin for BGP-4 instability is that our beloved route-maps create metrics that are not monotonically increasing or decreasing and that makes the routing protocols meta-stable. (BTW, I’m the first culprit when it comes to the use of them, I have created more than one wedgie :-P ) Acknowledging that this is a significant (and quite complex) problem for the Internet in general, I feel that it should be treated somewhere else (GROW?). > > The perspective I would like to take here is: > - assume that we have two or more clients that produce perfectly sound routing information (no wedgies there) > - assume they talk to the same agent > - now my questions > 1.- is there any way to detect whether the clients produce contradicting/conflicting information? > 2.- is there any way to resolve these contradictions/conflicts? > > BR, /PA > --- > Dr. Pedro A. Aranda Gutiérrez > > Technology Exploration - > Network Innovation & Virtualisation > email: pedroa d0t aranda At telefonica d0t com > Telefónica, Investigación y Desarrollo > C/ Zurbarán,12 > 28010 Madrid, Spain > > Fragen sind nicht da, um beantwortet zu werden. > Fragen sind da, um gestellt zu werden. > Georg Kreisler > > > > > > > > > -----Mensaje original----- > De: Russ White <7riw77@gmail.com> > Fecha: lunes, 23 de noviembre de 2015, 14:06 > Para: paag , 'Jeffrey Haas' > CC: "i2rs@ietf.org" , "'Joel M. Halpern'" , 'Andy Bierman' , Sue Hares > Asunto: RE: [i2rs] Conversation on Priority and Panes > >> >>> Re the metric 'problem', just to be more precise in what would be needed, >>> we are looking a metric that grows or decreases monotonically across the >>> whole network. >> >> I assume you mean in the routing space, and not in the controller/client space, correct? In terms of a distributed protocol? So, you're saying the delay could use "metrics" between 11 and 20, while the bandwidth could use "metrics" between 21 and 30, etc? And then you just add them all together? That's what IS-IS has done for years... Even BGP really only has one "metric," with following "tie breakers..." So if you have something like weight/local pref/etc, such that they occupy different "spaces" in a bit pattern (something suggested, btw, in the original wide community work, and in other places, as well), you're actually just building a single metric. >> >> You've not "solved" the multiple metric problem -- just done something a little different than EIGRP's K values to combine them into a single metric, which is where you need to be to have the ability to build a single stable SPT/DAG. >> >>> The theoretical grounds for this are in T. Griffin’s and >>> Sobrinho’s work on BGP-4 and that lies already a couple of years ago and that >>> makes the analysis much ‘easier’ (no worries about np(complete) problems, >>> etc.). This could be applied in I2RS at the routing protocol level. So, we could >>> discuss where that sits (should be the clients, right?) and I don’t know if >>> that’s been already done, since I’m quite new to this list. >> >> This doesn’t apply to the problem at hand, though... You seem to be saying (clarify if wrong) -- >> >> 1. Give each client some set of bits out of a 128 bit number space (or larger, etc.) >> 2. Each client can have different "metrics" within their own number space >> 3. When a client attempts to add some ephemeral state, they use a metric within their "space" >> 4. The agent can just use the straight number as a relative priority for each potential piece of state >> >> This doesn't do anything different than the current concept of priority between clients, only in the current plan each client only has one priority, rather than multiples. I don't see where this relates to the problem at hand. >> >>> Now, having “solved” that part of the equation :-) , the part that interests me >>> more is the conflicting clients problem, because this could be generalised to >>> other problem spaces in the SDN area. I do agree that agents should be able >>> to catch offending state before installing it and I’m looking for ways to specify >>> a minimal set of features that need to be supported at protocol level. >>> >>> Anyone else interested? >> >> This is precisely where the problem lies. And this is where you're going to hit the CAP theorem in full force. There are only a few choices -- >> >> 1. Make the database eventually consistent >> 2. Shut down accessibility during changes >> 3. ?? >> >> (1) is the idea of either having the agent call back to all the clients when state they installed is overwritten or allowing the agent to locally store some state where it already has the information in hand and install it locally -- the only real difference between these two solutions is the "balance of complexity versus speed..." The entire discussion here is how much additional complexity are we actually adding by doing "panes of glass," which are just locally stored state which isn't currently installed. I'm arguing that there's minimal complexity added that you're not already going to have in the system to allow the agent to store information locally _if_ it chooses to. Jeff is arguing (I think) that the "panes of glass" concept is a coherent way of looking at this problem that will help us understand and manage the complexity in a way that makes sense. Joel is arguing (I think) that this sort of solution is out of the WG charter, and it's too complex. I _think_ I have the th r ee general perspectives right, but I don't know if I really have so... :-) >> >> (2) is the idea of locking the database while you're changing it. This is explicitly outside the scope of I2RS entirely, given we're trying to design something that's atomic/restful. There are a lot of techniques you can use to speed up locking -- row locking, sharding, etc. -- but none of these are interesting from the I2RS perspective. >> >> :-) >> >> Russ >> > > ________________________________ > > Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. > > The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. > > Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição > From nobody Tue Nov 24 08:01:35 2015 Return-Path: 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 CF7291A8A13 for ; Tue, 24 Nov 2015 08:01:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_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 7_3fOPhn-H-G for ; Tue, 24 Nov 2015 08:01:30 -0800 (PST) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (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 DC0C41A8785 for ; Tue, 24 Nov 2015 08:01:29 -0800 (PST) Received: by lfaz4 with SMTP id z4so26724291lfa.0 for ; Tue, 24 Nov 2015 08:01:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iOOJD3p2wlNrJqsVX7QwA/A3NFxdAWJtbp7Z7v5/MqQ=; b=Tbn+7ON4N0UfYw0/Y5UIFHDQ/5WIw9y3veJnd3J3BirsgXkGGk/ohWq0rZp0POji7+ gDgMZsGPW5FIbOd677CfTnYrRhnoM6xFYtimJbbe8mZdfhfeaLz53pdMxhp0puLYkzAi nIKWkhng3QTmME5QEP3PwxQDq/aMoAiDyHrZ9nQETm7H0f8VxxD3XyE1CWuGcjvhIXhh PwVKBzHPI11sQqJJ3glFe+fI0ynv4SvKk4Wr9IpyrVGBV3KmRxJoLksReTK0ivHOYsl1 EocIXBoWRxrQwpG4OdCW5AzVVTzfDwgmGO9CJBz+erwN9Eie2KoMIJ06Tb4SJ+PxLcXA 7eig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=iOOJD3p2wlNrJqsVX7QwA/A3NFxdAWJtbp7Z7v5/MqQ=; b=ahdYKC7SLRUkbjOH6ZcOtSRoXf/qHRd0/cDs8J3z0f8Z9pxInPaMhwyLq6Mx/1l83K FQ6+N7YejuqGLimVAVhEOAbvYhpkIIakfTGWQBIAskE5PRsqgzdRbRzzf9Vf7O79y9K3 L7RRMSMQHD4F/Bpig+w5GIim+gCGJ4Lzv+BU4/5qZPKmx9yUD5zku8kmqKzJ99E3o6bQ c5SlkB/+yWXuMdRGLCG1vNrIwaLtFG85ObkJopuOs50Yvjbb+Iiyk90vZJrbnVBq+YE8 Hq0nN+9fjfTkbpIaUxwzqx4VjfKTBkbpmA8LcwvYdF6hvEp63QrgR9ezUb0loffyfay7 Dvpg== X-Gm-Message-State: ALoCoQkwWnm47Asf3TP8kw/DpPpe+lr47nFuwUik7oREInoopoLKPsi2J0jKULYBwtJTWxFnHgZR MIME-Version: 1.0 X-Received: by 10.112.202.101 with SMTP id kh5mr13541542lbc.66.1448380887906; Tue, 24 Nov 2015 08:01:27 -0800 (PST) Received: by 10.112.144.36 with HTTP; Tue, 24 Nov 2015 08:01:27 -0800 (PST) In-Reply-To: <56548418.6060603@joelhalpern.com> References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> <563A97AA.5020308@joelhalpern.com> <00f301d11761$61699130$243cb390$@gmail.com> <563AA59C.4060809@joelhalpern.com> <018101d11764$66b82e50$34288af0$@gmail.com> <20151119203509.GA22415@pfrc.org> <5B54713B-CDE6-4F65-BE79-91F5B9FF3850@telefonica.com> <008d01d12390$064987c0$12dc9740$@gmail.com> <99B64F3B-20A1-4D3C-A445-46D235EDB44D@telefonica.com> <014a01d12394$ec5ffa60$c51fef20$@gmail.com> <87361DB1-DC6F-4023-A807-4003B436B472@telefonica.com> <012501d125e7$62e457e0$28ad07a0$@gmail.com> <0EAC7123-CECA-4C34-B5E3-E89F0C8DBF94@telefonica.com> <56548418.6060603@joelhalpern.com> Date: Tue, 24 Nov 2015 08:01:27 -0800 Message-ID: From: Andy Bierman To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=001a11c3724c52da5405254b7435 Archived-At: Cc: Jeffrey Haas , PEDRO ANDRES ARANDA GUTIERREZ , Susan Hares , Russ White <7riw77@gmail.com>, "i2rs@ietf.org" Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 16:01:34 -0000 --001a11c3724c52da5405254b7435 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Nov 24, 2015 at 7:36 AM, Joel M. Halpern wrote: > I believe that determining whether two independent and internally > consistent sets of changes can, in combination, produce a wedgie or other > failure is a research problem. > As far as I know, the I2RS working group concluded that it was a > sufficiently hard problem that we did not expect the I2RS agent to get > involved in trying to detect, much less remediate, such cross-object > inconsistencies. > > But the I2RS agent is responsible for identifying an edit collision between a new low-priority request and existing higher priority edits. That sounds involved to me. So the agent cannot possibly solve this problem yet it is responsible for precisely that in order to implement client priority. The agent can see that /foo[42] exists in the request and /foo[42] exists in the ephemeral datastore, and call that a collision. However, if /foo[1] or /bar[19] are also part of the "edit", such that simply replacing /foo[42] will break things, then the agent will not know. It will simply overwrite /foo[42] and leave /foo[1] and /bar[19] in the datastore. So is the low-priority client responsible for removing /foo[1] and /bar[19]= ? Seems the answer is no. The client can go away and there are no cleanup requirements mentioned in the architecture. Yours, > Joel > Andy > > On 11/24/15 10:32 AM, PEDRO ANDRES ARANDA GUTIERREZ wrote: > >> Hi Russ, >> >> I=E2=80=99m trying to identify the differences between interactions with= routing >> protocols in I2RS and what is purely conflicts between clients. Currentl= y I >> see too many issues overlapping and I fear that the trees are not lettin= g >> us see the forest. >> >> So my take on routing protocols and wedgies might have been too compact >> :-) Let me give it a second try: Stepping outside the I2RS problem space= , >> there is a lot of work that shows that the origin for BGP-4 instability = is >> that our beloved route-maps create metrics that are not monotonically >> increasing or decreasing and that makes the routing protocols meta-stabl= e. >> (BTW, I=E2=80=99m the first culprit when it comes to the use of them, I = have >> created more than one wedgie :-P ) Acknowledging that this is a signific= ant >> (and quite complex) problem for the Internet in general, I feel that it >> should be treated somewhere else (GROW?). >> >> The perspective I would like to take here is: >> - assume that we have two or more clients that produce perfectly sound >> routing information (no wedgies there) >> - assume they talk to the same agent >> - now my questions >> 1.- is there any way to detect whether the clients produce >> contradicting/conflicting information? >> 2.- is there any way to resolve these contradictions/conflicts? >> >> BR, /PA >> --- >> Dr. Pedro A. Aranda Guti=C3=A9rrez >> >> Technology Exploration - >> Network Innovation & Virtualisation >> email: pedroa d0t aranda At telefonica d0t com >> Telef=C3=B3nica, Investigaci=C3=B3n y Desarrollo >> C/ Zurbar=C3=A1n,12 >> 28010 Madrid, Spain >> >> Fragen sind nicht da, um beantwortet zu werden. >> Fragen sind da, um gestellt zu werden. >> Georg Kreisler >> >> >> >> >> >> >> >> >> -----Mensaje original----- >> De: Russ White <7riw77@gmail.com> >> Fecha: lunes, 23 de noviembre de 2015, 14:06 >> Para: paag , 'Jeffrey Haas' > > >> CC: "i2rs@ietf.org" , "'Joel M. Halpern'" < >> jmh@joelhalpern.com>, 'Andy Bierman' , Sue Hares < >> shares@ndzh.com> >> Asunto: RE: [i2rs] Conversation on Priority and Panes >> >> >>> Re the metric 'problem', just to be more precise in what would be neede= d, >>>> we are looking a metric that grows or decreases monotonically across t= he >>>> whole network. >>>> >>> >>> I assume you mean in the routing space, and not in the controller/clien= t >>> space, correct? In terms of a distributed protocol? So, you're saying t= he >>> delay could use "metrics" between 11 and 20, while the bandwidth could = use >>> "metrics" between 21 and 30, etc? And then you just add them all togeth= er? >>> That's what IS-IS has done for years... Even BGP really only has one >>> "metric," with following "tie breakers..." So if you have something lik= e >>> weight/local pref/etc, such that they occupy different "spaces" in a bi= t >>> pattern (something suggested, btw, in the original wide community work,= and >>> in other places, as well), you're actually just building a single metri= c. >>> >>> You've not "solved" the multiple metric problem -- just done something = a >>> little different than EIGRP's K values to combine them into a single >>> metric, which is where you need to be to have the ability to build a si= ngle >>> stable SPT/DAG. >>> >>> The theoretical grounds for this are in T. Griffin=E2=80=99s and >>>> Sobrinho=E2=80=99s work on BGP-4 and that lies already a couple of yea= rs ago >>>> and that >>>> makes the analysis much =E2=80=98easier=E2=80=99 (no worries about np(= complete) >>>> problems, >>>> etc.). This could be applied in I2RS at the routing protocol level. So= , >>>> we could >>>> discuss where that sits (should be the clients, right?) and I don=E2= =80=99t >>>> know if >>>> that=E2=80=99s been already done, since I=E2=80=99m quite new to this = list. >>>> >>> >>> This doesn=E2=80=99t apply to the problem at hand, though... You seem t= o be >>> saying (clarify if wrong) -- >>> >>> 1. Give each client some set of bits out of a 128 bit number space (or >>> larger, etc.) >>> 2. Each client can have different "metrics" within their own number spa= ce >>> 3. When a client attempts to add some ephemeral state, they use a metri= c >>> within their "space" >>> 4. The agent can just use the straight number as a relative priority fo= r >>> each potential piece of state >>> >>> This doesn't do anything different than the current concept of priority >>> between clients, only in the current plan each client only has one >>> priority, rather than multiples. I don't see where this relates to the >>> problem at hand. >>> >>> Now, having =E2=80=9Csolved=E2=80=9D that part of the equation :-) , th= e part that >>>> interests me >>>> more is the conflicting clients problem, because this could be >>>> generalised to >>>> other problem spaces in the SDN area. I do agree that agents should be >>>> able >>>> to catch offending state before installing it and I=E2=80=99m looking = for ways >>>> to specify >>>> a minimal set of features that need to be supported at protocol level. >>>> >>>> Anyone else interested? >>>> >>> >>> This is precisely where the problem lies. And this is where you're goin= g >>> to hit the CAP theorem in full force. There are only a few choices -- >>> >>> 1. Make the database eventually consistent >>> 2. Shut down accessibility during changes >>> 3. ?? >>> >>> (1) is the idea of either having the agent call back to all the clients >>> when state they installed is overwritten or allowing the agent to local= ly >>> store some state where it already has the information in hand and insta= ll >>> it locally -- the only real difference between these two solutions is t= he >>> "balance of complexity versus speed..." The entire discussion here is h= ow >>> much additional complexity are we actually adding by doing "panes of >>> glass," which are just locally stored state which isn't currently >>> installed. I'm arguing that there's minimal complexity added that you'r= e >>> not already going to have in the system to allow the agent to store >>> information locally _if_ it chooses to. Jeff is arguing (I think) that = the >>> "panes of glass" concept is a coherent way of looking at this problem t= hat >>> will help us understand and manage the complexity in a way that makes >>> sense. Joel is arguing (I think) that this sort of solution is out of t= he >>> WG charter, and it's too complex. I _think_ I have the th >>> >> r > ee general perspectives right, but I don't know if I really have so... :-= ) > >> >>> (2) is the idea of locking the database while you're changing it. This >>> is explicitly outside the scope of I2RS entirely, given we're trying to >>> design something that's atomic/restful. There are a lot of techniques y= ou >>> can use to speed up locking -- row locking, sharding, etc. -- but none = of >>> these are interesting from the I2RS perspective. >>> >>> :-) >>> >>> Russ >>> >>> >> ________________________________ >> >> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, >> puede contener informaci=C3=B3n privilegiada o confidencial y es para us= o >> exclusivo de la persona o entidad de destino. Si no es usted. el >> destinatario indicado, queda notificado de que la lectura, utilizaci=C3= =B3n, >> divulgaci=C3=B3n y/o copia sin autorizaci=C3=B3n puede estar prohibida e= n virtud de >> la legislaci=C3=B3n vigente. Si ha recibido este mensaje por error, le r= ogamos >> que nos lo comunique inmediatamente por esta misma v=C3=ADa y proceda a = su >> destrucci=C3=B3n. >> >> The information contained in this transmission is privileged and >> confidential information intended only for the use of the individual or >> entity named above. If the reader of this message is not the intended >> recipient, you are hereby notified that any dissemination, distribution = or >> copying of this communication is strictly prohibited. If you have receiv= ed >> this transmission in error, do not read it. Please immediately reply to = the >> sender that you have received this communication in error and then delet= e >> it. >> >> Esta mensagem e seus anexos se dirigem exclusivamente ao seu >> destinat=C3=A1rio, pode conter informa=C3=A7=C3=A3o privilegiada ou conf= idencial e =C3=A9 para >> uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vossa= senhoria o >> destinat=C3=A1rio indicado, fica notificado de que a leitura, utiliza=C3= =A7=C3=A3o, >> divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem autoriza=C3=A7=C3=A3o pode esta= r proibida em virtude da >> legisla=C3=A7=C3=A3o vigente. Se recebeu esta mensagem por erro, rogamos= -lhe que nos >> o comunique imediatamente por esta mesma via e proceda a sua destrui=C3= =A7=C3=A3o >> >> --001a11c3724c52da5405254b7435 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Nov 24, 2015 at 7:36 AM, Joel M. Halpern <= jmh@joelhalpern.co= m> wrote:
I believe that de= termining whether two independent and internally consistent sets of changes= can, in combination, produce a wedgie or other failure is a research probl= em.
As far as I know, the I2RS working group concluded that it was a sufficient= ly hard problem that we did not expect the I2RS agent to get involved in tr= ying to detect, much less remediate, such cross-object inconsistencies.



But the I2RS agent is r= esponsible for identifying an edit collision between
a new low-pr= iority request and existing higher priority edits. That sounds
in= volved to me.=C2=A0 So the agent cannot possibly solve this problem
yet it is responsible for precisely that in order to implement client pr= iority.

The agent can see that /foo[42] exists in = the request and /foo[42] exists
in the ephemeral datastore, and c= all that a collision.

However, if /foo[1] or /bar[= 19] are also part of the "edit", such that simply replacing
=
/foo[42] will break things, then the agent will not know. It will simp= ly overwrite
/foo[42] and leave /foo[1] and /bar[19] in the datas= tore.

So is the low-priority client responsible fo= r removing /foo[1] and /bar[19]?
Seems the answer is no. The clie= nt can go away and there are no cleanup
requirements mentioned in= the architecture.



Yours,
Joel


Andy
=C2= =A0

On 11/24/15 10:32 AM, PEDRO ANDRES ARANDA GUTIERREZ wrote:
Hi Russ,

I=E2=80=99m trying to identify the differences between interactions with ro= uting protocols in I2RS and what is purely conflicts between clients. Curre= ntly I see too many issues overlapping and I fear that the trees are not le= tting us see the forest.

So my take on routing protocols and wedgies might have been too compact :-)= Let me give it a second try: Stepping outside the I2RS problem space, ther= e is a lot of work that shows that the origin for BGP-4 instability is that= our beloved route-maps create metrics that are not monotonically increasin= g or decreasing and that makes the routing protocols meta-stable. (BTW, I= =E2=80=99m the first culprit when it comes to the use of them, I have creat= ed more than one wedgie :-P ) Acknowledging that this is a significant (and= quite complex) problem for the Internet in general, I feel that it should = be treated somewhere else (GROW?).

The perspective I would like to take here is:
- assume that we have two or more clients that produce perfectly sound rout= ing information (no wedgies there)
- assume they talk to the same agent
- now my questions
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01.- is there any way to detect whether th= e clients produce contradicting/conflicting information?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02.- is there any way to resolve these con= tradictions/conflicts?

BR, /PA
---
Dr. Pedro A. Aranda Guti=C3=A9rrez

Technology Exploration -
Network Innovation & Virtualisation
email: pedroa d0t aranda At telefonica d0t com
Telef=C3=B3nica, Investigaci=C3=B3n y Desarrollo
C/ Zurbar=C3=A1n,12
28010 Madrid, Spain

Fragen sind nicht da, um beantwortet zu werden.
Fragen sind da, um gestellt zu werden.
Georg Kreisler








-----Mensaje original-----
De: Russ White <7r= iw77@gmail.com>
Fecha: lunes, 23 de noviembre de 2015, 14:06
Para: paag <pedroa.aranda@telefonica.com>, 'Jeffrey Haas' <jhaas@pfrc.org>
CC: "i2rs@ietf.org<= /a>" <i2rs@ietf.= org>, "'Joel M. Halpern'" <jmh@joelhalpern.com>, 'Andy= Bierman' <a= ndy@yumaworks.com>, Sue Hares <shares@ndzh.com>
Asunto: RE: [i2rs] Conversation on Priority and Panes


Re the metric 'problem', just to be more precise in what would be n= eeded,
we are looking a metric that grows or decreases monotonically across the whole network.

I assume you mean in the routing space, and not in the controller/client sp= ace, correct? In terms of a distributed protocol? So, you're saying the= delay could use "metrics" between 11 and 20, while the bandwidth= could use "metrics" between 21 and 30, etc? And then you just ad= d them all together? That's what IS-IS has done for years... Even BGP r= eally only has one "metric," with following "tie breakers...= " So if you have something like weight/local pref/etc, such that they = occupy different "spaces" in a bit pattern (something suggested, = btw, in the original wide community work, and in other places, as well), yo= u're actually just building a single metric.

You've not "solved" the multiple metric problem -- just done = something a little different than EIGRP's K values to combine them into= a single metric, which is where you need to be to have the ability to buil= d a single stable SPT/DAG.

The theoretical grounds for this are in T. Griffin=E2=80=99s and
Sobrinho=E2=80=99s work on BGP-4 and that lies already a couple of years ag= o and that
makes the analysis much =E2=80=98easier=E2=80=99 (no worries about np(compl= ete) problems,
etc.). This could be applied in I2RS at the routing protocol level. So, we = could
discuss where that sits (should be the clients, right?) and I don=E2=80=99t= know if
that=E2=80=99s been already done, since I=E2=80=99m quite new to this list.=

This doesn=E2=80=99t apply to the problem at hand, though... You seem to be= saying (clarify if wrong) --

1. Give each client some set of bits out of a 128 bit number space (or larg= er, etc.)
2. Each client can have different "metrics" within their own numb= er space
3. When a client attempts to add some ephemeral state, they use a metric wi= thin their "space"
4. The agent can just use the straight number as a relative priority for ea= ch potential piece of state

This doesn't do anything different than the current concept of priority= between clients, only in the current plan each client only has one priorit= y, rather than multiples. I don't see where this relates to the problem= at hand.

Now, having =E2=80=9Csolved=E2=80=9D that part of the equation :-) , the pa= rt that interests me
more is the conflicting clients problem, because this could be generalised = to
other problem spaces in the SDN area. I do agree that agents should be able=
to catch offending state before installing it and I=E2=80=99m looking for w= ays to specify
a minimal set of features that need to be supported at protocol level.

Anyone else interested?

This is precisely where the problem lies. And this is where you're goin= g to hit the CAP theorem in full force. There are only a few choices --

1. Make the database eventually consistent
2. Shut down accessibility during changes
3. ??

(1) is the idea of either having the agent call back to all the clients whe= n state they installed is overwritten or allowing the agent to locally stor= e some state where it already has the information in hand and install it lo= cally -- the only real difference between these two solutions is the "= balance of complexity versus speed..." The entire discussion here is h= ow much additional complexity are we actually adding by doing "panes o= f glass," which are just locally stored state which isn't currentl= y installed. I'm arguing that there's minimal complexity added that= you're not already going to have in the system to allow the agent to s= tore information locally _if_ it chooses to. Jeff is arguing (I think) that= the "panes of glass" concept is a coherent way of looking at thi= s problem that will help us understand and manage the complexity in a way t= hat makes sense. Joel is arguing (I think) that this sort of solution is ou= t of the WG charter, and it's too complex. I _think_ I have the th
r
ee general perspectives right, but I don't know if I really have so... = :-)

(2) is the idea of locking the database while you're changing it. This = is explicitly outside the scope of I2RS entirely, given we're trying to= design something that's atomic/restful. There are a lot of techniques = you can use to speed up locking -- row locking, sharding, etc. -- but none = of these are interesting from the I2RS perspective.

:-)

Russ


________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=C3=B3n privilegiada o confidencial y es para uso exc= lusivo de la persona o entidad de destino. Si no es usted. el destinatario = indicado, queda notificado de que la lectura, utilizaci=C3=B3n, divulgaci= =C3=B3n y/o copia sin autorizaci=C3=B3n puede estar prohibida en virtud de = la legislaci=C3=B3n vigente. Si ha recibido este mensaje por error, le roga= mos que nos lo comunique inmediatamente por esta misma v=C3=ADa y proceda a= su destrucci=C3=B3n.

The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3=A1= rio, pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9= para uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vo= ssa senhoria o destinat=C3=A1rio indicado, fica notificado de que a leitura= , utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem autoriza= =C3=A7=C3=A3o pode estar proibida em virtude da legisla=C3=A7=C3=A3o vigent= e. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imedi= atamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o


--001a11c3724c52da5405254b7435-- From nobody Tue Nov 24 08:06:14 2015 Return-Path: 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 62A0F1A8AB2 for ; Tue, 24 Nov 2015 08:06:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.186 X-Spam-Level: X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham 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 YjDrbmJ3S5Oa for ; Tue, 24 Nov 2015 08:06:09 -0800 (PST) Received: from smtpjc.telefonica.com (smtpjc.telefonica.com [81.47.204.76]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BB2C1A8AC4 for ; Tue, 24 Nov 2015 08:06:08 -0800 (PST) Received: from smtpjc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 63DF32F00BC; Tue, 24 Nov 2015 17:06:06 +0100 (CET) Received: from ESTGVMSP105.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtpjc.telefonica.com (Postfix) with ESMTPS id 553BE2F0078; Tue, 24 Nov 2015 17:06:06 +0100 (CET) Received: from emea01-db3-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.92.6.51) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 24 Nov 2015 17:06:05 +0100 Received: from DB4PR06MB0639.eurprd06.prod.outlook.com (10.161.13.145) by DB4PR06MB0638.eurprd06.prod.outlook.com (10.161.13.144) with Microsoft SMTP Server (TLS) id 15.1.331.20; Tue, 24 Nov 2015 16:06:04 +0000 Received: from DB4PR06MB0639.eurprd06.prod.outlook.com ([10.161.13.145]) by DB4PR06MB0639.eurprd06.prod.outlook.com ([10.161.13.145]) with mapi id 15.01.0331.019; Tue, 24 Nov 2015 16:06:04 +0000 From: PEDRO ANDRES ARANDA GUTIERREZ To: "Joel M. Halpern" , Russ White <7riw77@gmail.com>, 'Jeffrey Haas' Thread-Topic: [i2rs] Conversation on Priority and Panes Thread-Index: AQHRIwm/+3O1h73j5ke4p1jGIHLAp56kkHqAgABJfACAABYNgP//88AAgARhSwCAAEOjgIAB3IYA///wmwCAABjlAA== Date: Tue, 24 Nov 2015 16:06:04 +0000 Message-ID: <50DB16FA-7F98-4914-8EC1-99E054C2EA36@telefonica.com> References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> <563A97AA.5020308@joelhalpern.com> <00f301d11761$61699130$243cb390$@gmail.com> <563AA59C.4060809@joelhalpern.com> <018101d11764$66b82e50$34288af0$@gmail.com> <20151119203509.GA22415@pfrc.org> <5B54713B-CDE6-4F65-BE79-91F5B9FF3850@telefonica.com> <008d01d12390$064987c0$12dc9740$@gmail.com> <99B64F3B-20A1-4D3C-A445-46D235EDB44D@telefonica.com> <014a01d12394$ec5ffa60$c51fef20$@gmail.com> <87361DB1-DC6F-4023-A807-4003B436B472@telefonica.com> <012501d125e7$62e457e0$28ad07a0$@gmail.com> <0EAC7123-CECA-4C34-B5E3-E89F0C8DBF94@telefonica.com> <56548418.6060603@joelhalpern.com> In-Reply-To: <56548418.6060603@joelhalpern.com> Accept-Language: es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151105 authentication-results: spf=none (sender IP is ) smtp.mailfrom=pedroa.aranda@telefonica.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [143.233.5.6] x-microsoft-exchange-diagnostics: 1; DB4PR06MB0638; 5:R0v2r3rQWBDqMGvs8bOs6wjJn8B2ALtGSyOEX+5Os2vUp1PC3X/AwKwB7HKHQQ5r6L6et9mkzBpfJmHKeZrCIOZ5hr4eTuY8LZOc0blTcagYApLAoNcu1vKApPfZkB245hkfIfjE24gGCJAP/4TOsA==; 24:50pTkNyBOetGMixl5yiAthP2eGlnvuxA/cKL87TKWGw5UV1XpIlwwn7Q/FNoDtg5kt7wd6bP3oNhGOVonUmlRbY8A2hoXfMdaKk9cqUqDC8= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB0638; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(40392960112811); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046); SRVR:DB4PR06MB0638; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0638; x-forefront-prvs: 0770F75EA9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(189002)(199003)(377454003)(59124004)(25724002)(479174004)(40134004)(33656002)(2900100001)(5002640100001)(5007970100001)(5004730100002)(5008740100001)(86362001)(77096005)(92566002)(586003)(105586002)(575784001)(106116001)(87936001)(10400500002)(83716003)(19580395003)(40100003)(101416001)(82746002)(4001350100001)(5001770100001)(76176999)(83506001)(36756003)(106356001)(6116002)(189998001)(3846002)(50986999)(2950100001)(54356999)(81156007)(97736004)(66066001)(122556002)(5001960100002)(102836003)(11100500001)(93886004)(19580405001)(5001920100001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB0638; H:DB4PR06MB0639.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <6F292DE65BBF214FA132A279F86D11A4@eurprd06.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Nov 2015 16:06:04.0872 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB0638 X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: Cc: "i2rs@ietf.org" , 'Andy Bierman' , 'Susan Hares' Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 16:06:13 -0000 SGkgSm9lbCwNCg0KR2VuZXJhbGlzZWQgY29uZmxpY3QgZGV0ZWN0aW9uL3Jlc29sdXRpb24gaXMg cXVpdGUgYSBoYXJkIHByb2JsZW0sIEkgYWdyZWUgb24gdGhhdC4gQnV0IG1heWJlIHdlIGNhbiBz dGFydCBieSBleGFtaW5pbmcgYSBjb3VwbGUgb2YgdXNlIGNhc2VzIHRoYXQgd2UgaWRlbnRpZnku ICBXaXRoIHRoZSB0aW1lIEkgaGF2ZSBsZWFybnQgdGhhdCBpbiBtYW55IG9jY2FzaW9ucyB5b3Ug Y2FuIHN0YXJ0IGF2b2lkaW5nIHByb2JsZW1zIGJ5IGF2b2lkaW5nIHRoZSBtb3JlIG9idmlvdXMg b25lcy4NCg0KQmVzdCwgL1BBDQotLS0NCkRyLiBQZWRybyBBLiBBcmFuZGEgR3V0acOpcnJleg0K DQpUZWNobm9sb2d5IEV4cGxvcmF0aW9uIC0NCk5ldHdvcmsgSW5ub3ZhdGlvbiAmIFZpcnR1YWxp c2F0aW9uDQplbWFpbDogcGVkcm9hIGQwdCBhcmFuZGEgQXQgdGVsZWZvbmljYSBkMHQgY29tDQpU ZWxlZsOzbmljYSwgSW52ZXN0aWdhY2nDs24geSBEZXNhcnJvbGxvDQpDLyBadXJiYXLDoW4sMTIN CjI4MDEwIE1hZHJpZCwgU3BhaW4NCg0KRnJhZ2VuIHNpbmQgbmljaHQgZGEsIHVtIGJlYW50d29y dGV0IHp1IHdlcmRlbi4NCkZyYWdlbiBzaW5kIGRhLCB1bSBnZXN0ZWxsdCB6dSB3ZXJkZW4uDQpH ZW9yZyBLcmVpc2xlcg0KDQoNCg0KDQoNCg0KDQoNCi0tLS0tTWVuc2FqZSBvcmlnaW5hbC0tLS0t DQpEZTogIkpvZWwgTS4gSGFscGVybiIgPGptaEBqb2VsaGFscGVybi5jb20+DQpGZWNoYTogbWFy dGVzLCAyNCBkZSBub3ZpZW1icmUgZGUgMjAxNSwgMTc6MzYNClBhcmE6IHBhYWcgPHBlZHJvYS5h cmFuZGFAdGVsZWZvbmljYS5jb20+LCBSdXNzIFdoaXRlIDw3cml3NzdAZ21haWwuY29tPiwgJ0pl ZmZyZXkgSGFhcycgPGpoYWFzQHBmcmMub3JnPg0KQ0M6ICJpMnJzQGlldGYub3JnIiA8aTJyc0Bp ZXRmLm9yZz4sICInSm9lbCBNLiBIYWxwZXJuJyIgPGptaEBqb2VsaGFscGVybi5jb20+LCAnQW5k eSBCaWVybWFuJyA8YW5keUB5dW1hd29ya3MuY29tPiwgU3VlIEhhcmVzIDxzaGFyZXNAbmR6aC5j b20+DQpBc3VudG86IFJlOiBbaTJyc10gQ29udmVyc2F0aW9uIG9uIFByaW9yaXR5IGFuZCBQYW5l cw0KDQo+SSBiZWxpZXZlIHRoYXQgZGV0ZXJtaW5pbmcgd2hldGhlciB0d28gaW5kZXBlbmRlbnQg YW5kIGludGVybmFsbHkNCj5jb25zaXN0ZW50IHNldHMgb2YgY2hhbmdlcyBjYW4sIGluIGNvbWJp bmF0aW9uLCBwcm9kdWNlIGEgd2VkZ2llIG9yDQo+b3RoZXIgZmFpbHVyZSBpcyBhIHJlc2VhcmNo IHByb2JsZW0uDQo+QXMgZmFyIGFzIEkga25vdywgdGhlIEkyUlMgd29ya2luZyBncm91cCBjb25j bHVkZWQgdGhhdCBpdCB3YXMgYQ0KPnN1ZmZpY2llbnRseSBoYXJkIHByb2JsZW0gdGhhdCB3ZSBk aWQgbm90IGV4cGVjdCB0aGUgSTJSUyBhZ2VudCB0byBnZXQNCj5pbnZvbHZlZCBpbiB0cnlpbmcg dG8gZGV0ZWN0LCBtdWNoIGxlc3MgcmVtZWRpYXRlLCBzdWNoIGNyb3NzLW9iamVjdA0KPmluY29u c2lzdGVuY2llcy4NCj4NCj5Zb3VycywNCj5Kb2VsDQo+DQo+T24gMTEvMjQvMTUgMTA6MzIgQU0s IFBFRFJPIEFORFJFUyBBUkFOREEgR1VUSUVSUkVaIHdyb3RlOg0KPj4gSGkgUnVzcywNCj4+DQo+ PiBJ4oCZbSB0cnlpbmcgdG8gaWRlbnRpZnkgdGhlIGRpZmZlcmVuY2VzIGJldHdlZW4gaW50ZXJh Y3Rpb25zIHdpdGggcm91dGluZyBwcm90b2NvbHMgaW4gSTJSUyBhbmQgd2hhdCBpcyBwdXJlbHkg Y29uZmxpY3RzIGJldHdlZW4gY2xpZW50cy4gQ3VycmVudGx5IEkgc2VlIHRvbyBtYW55IGlzc3Vl cyBvdmVybGFwcGluZyBhbmQgSSBmZWFyIHRoYXQgdGhlIHRyZWVzIGFyZSBub3QgbGV0dGluZyB1 cyBzZWUgdGhlIGZvcmVzdC4NCj4+DQo+PiBTbyBteSB0YWtlIG9uIHJvdXRpbmcgcHJvdG9jb2xz IGFuZCB3ZWRnaWVzIG1pZ2h0IGhhdmUgYmVlbiB0b28gY29tcGFjdCA6LSkgTGV0IG1lIGdpdmUg aXQgYSBzZWNvbmQgdHJ5OiBTdGVwcGluZyBvdXRzaWRlIHRoZSBJMlJTIHByb2JsZW0gc3BhY2Us IHRoZXJlIGlzIGEgbG90IG9mIHdvcmsgdGhhdCBzaG93cyB0aGF0IHRoZSBvcmlnaW4gZm9yIEJH UC00IGluc3RhYmlsaXR5IGlzIHRoYXQgb3VyIGJlbG92ZWQgcm91dGUtbWFwcyBjcmVhdGUgbWV0 cmljcyB0aGF0IGFyZSBub3QgbW9ub3RvbmljYWxseSBpbmNyZWFzaW5nIG9yIGRlY3JlYXNpbmcg YW5kIHRoYXQgbWFrZXMgdGhlIHJvdXRpbmcgcHJvdG9jb2xzIG1ldGEtc3RhYmxlLiAoQlRXLCBJ 4oCZbSB0aGUgZmlyc3QgY3VscHJpdCB3aGVuIGl0IGNvbWVzIHRvIHRoZSB1c2Ugb2YgdGhlbSwg SSBoYXZlIGNyZWF0ZWQgbW9yZSB0aGFuIG9uZSB3ZWRnaWUgOi1QICkgQWNrbm93bGVkZ2luZyB0 aGF0IHRoaXMgaXMgYSBzaWduaWZpY2FudCAoYW5kIHF1aXRlIGNvbXBsZXgpIHByb2JsZW0gZm9y IHRoZSBJbnRlcm5ldCBpbiBnZW5lcmFsLCBJIGZlZWwgdGhhdCBpdCBzaG91bGQgYmUgdHJlYXRl ZCBzb21ld2hlcmUgZWxzZSAoR1JPVz8pLg0KPj4NCj4+IFRoZSBwZXJzcGVjdGl2ZSBJIHdvdWxk IGxpa2UgdG8gdGFrZSBoZXJlIGlzOg0KPj4gLSBhc3N1bWUgdGhhdCB3ZSBoYXZlIHR3byBvciBt b3JlIGNsaWVudHMgdGhhdCBwcm9kdWNlIHBlcmZlY3RseSBzb3VuZCByb3V0aW5nIGluZm9ybWF0 aW9uIChubyB3ZWRnaWVzIHRoZXJlKQ0KPj4gLSBhc3N1bWUgdGhleSB0YWxrIHRvIHRoZSBzYW1l IGFnZW50DQo+PiAtIG5vdyBteSBxdWVzdGlvbnMNCj4+ICAgICAgICAgIDEuLSBpcyB0aGVyZSBh bnkgd2F5IHRvIGRldGVjdCB3aGV0aGVyIHRoZSBjbGllbnRzIHByb2R1Y2UgY29udHJhZGljdGlu Zy9jb25mbGljdGluZyBpbmZvcm1hdGlvbj8NCj4+ICAgICAgICAgIDIuLSBpcyB0aGVyZSBhbnkg d2F5IHRvIHJlc29sdmUgdGhlc2UgY29udHJhZGljdGlvbnMvY29uZmxpY3RzPw0KPj4NCj4+IEJS LCAvUEENCj4+IC0tLQ0KPj4gRHIuIFBlZHJvIEEuIEFyYW5kYSBHdXRpw6lycmV6DQo+Pg0KPj4g VGVjaG5vbG9neSBFeHBsb3JhdGlvbiAtDQo+PiBOZXR3b3JrIElubm92YXRpb24gJiBWaXJ0dWFs aXNhdGlvbg0KPj4gZW1haWw6IHBlZHJvYSBkMHQgYXJhbmRhIEF0IHRlbGVmb25pY2EgZDB0IGNv bQ0KPj4gVGVsZWbDs25pY2EsIEludmVzdGlnYWNpw7NuIHkgRGVzYXJyb2xsbw0KPj4gQy8gWnVy YmFyw6FuLDEyDQo+PiAyODAxMCBNYWRyaWQsIFNwYWluDQo+Pg0KPj4gRnJhZ2VuIHNpbmQgbmlj aHQgZGEsIHVtIGJlYW50d29ydGV0IHp1IHdlcmRlbi4NCj4+IEZyYWdlbiBzaW5kIGRhLCB1bSBn ZXN0ZWxsdCB6dSB3ZXJkZW4uDQo+PiBHZW9yZyBLcmVpc2xlcg0KPj4NCj4+DQo+Pg0KPj4NCj4+ DQo+Pg0KPj4NCj4+DQo+PiAtLS0tLU1lbnNhamUgb3JpZ2luYWwtLS0tLQ0KPj4gRGU6IFJ1c3Mg V2hpdGUgPDdyaXc3N0BnbWFpbC5jb20+DQo+PiBGZWNoYTogbHVuZXMsIDIzIGRlIG5vdmllbWJy ZSBkZSAyMDE1LCAxNDowNg0KPj4gUGFyYTogcGFhZyA8cGVkcm9hLmFyYW5kYUB0ZWxlZm9uaWNh LmNvbT4sICdKZWZmcmV5IEhhYXMnIDxqaGFhc0BwZnJjLm9yZz4NCj4+IENDOiAiaTJyc0BpZXRm Lm9yZyIgPGkycnNAaWV0Zi5vcmc+LCAiJ0pvZWwgTS4gSGFscGVybiciIDxqbWhAam9lbGhhbHBl cm4uY29tPiwgJ0FuZHkgQmllcm1hbicgPGFuZHlAeXVtYXdvcmtzLmNvbT4sIFN1ZSBIYXJlcyA8 c2hhcmVzQG5kemguY29tPg0KPj4gQXN1bnRvOiBSRTogW2kycnNdIENvbnZlcnNhdGlvbiBvbiBQ cmlvcml0eSBhbmQgUGFuZXMNCj4+DQo+Pj4NCj4+Pj4gUmUgdGhlIG1ldHJpYyAncHJvYmxlbScs IGp1c3QgdG8gYmUgbW9yZSBwcmVjaXNlIGluIHdoYXQgd291bGQgYmUgbmVlZGVkLA0KPj4+PiB3 ZSBhcmUgbG9va2luZyBhIG1ldHJpYyB0aGF0IGdyb3dzIG9yIGRlY3JlYXNlcyBtb25vdG9uaWNh bGx5IGFjcm9zcyB0aGUNCj4+Pj4gd2hvbGUgbmV0d29yay4NCj4+Pg0KPj4+IEkgYXNzdW1lIHlv dSBtZWFuIGluIHRoZSByb3V0aW5nIHNwYWNlLCBhbmQgbm90IGluIHRoZSBjb250cm9sbGVyL2Ns aWVudCBzcGFjZSwgY29ycmVjdD8gSW4gdGVybXMgb2YgYSBkaXN0cmlidXRlZCBwcm90b2NvbD8g U28sIHlvdSdyZSBzYXlpbmcgdGhlIGRlbGF5IGNvdWxkIHVzZSAibWV0cmljcyIgYmV0d2VlbiAx MSBhbmQgMjAsIHdoaWxlIHRoZSBiYW5kd2lkdGggY291bGQgdXNlICJtZXRyaWNzIiBiZXR3ZWVu IDIxIGFuZCAzMCwgZXRjPyBBbmQgdGhlbiB5b3UganVzdCBhZGQgdGhlbSBhbGwgdG9nZXRoZXI/ IFRoYXQncyB3aGF0IElTLUlTIGhhcyBkb25lIGZvciB5ZWFycy4uLiBFdmVuIEJHUCByZWFsbHkg b25seSBoYXMgb25lICJtZXRyaWMsIiB3aXRoIGZvbGxvd2luZyAidGllIGJyZWFrZXJzLi4uIiBT byBpZiB5b3UgaGF2ZSBzb21ldGhpbmcgbGlrZSB3ZWlnaHQvbG9jYWwgcHJlZi9ldGMsIHN1Y2gg dGhhdCB0aGV5IG9jY3VweSBkaWZmZXJlbnQgInNwYWNlcyIgaW4gYSBiaXQgcGF0dGVybiAoc29t ZXRoaW5nIHN1Z2dlc3RlZCwgYnR3LCBpbiB0aGUgb3JpZ2luYWwgd2lkZSBjb21tdW5pdHkgd29y aywgYW5kIGluIG90aGVyIHBsYWNlcywgYXMgd2VsbCksIHlvdSdyZSBhY3R1YWxseSBqdXN0IGJ1 aWxkaW5nIGEgc2luZ2xlIG1ldHJpYy4NCj4+Pg0KPj4+IFlvdSd2ZSBub3QgInNvbHZlZCIgdGhl IG11bHRpcGxlIG1ldHJpYyBwcm9ibGVtIC0tIGp1c3QgZG9uZSBzb21ldGhpbmcgYSBsaXR0bGUg ZGlmZmVyZW50IHRoYW4gRUlHUlAncyBLIHZhbHVlcyB0byBjb21iaW5lIHRoZW0gaW50byBhIHNp bmdsZSBtZXRyaWMsIHdoaWNoIGlzIHdoZXJlIHlvdSBuZWVkIHRvIGJlIHRvIGhhdmUgdGhlIGFi aWxpdHkgdG8gYnVpbGQgYSBzaW5nbGUgc3RhYmxlIFNQVC9EQUcuDQo+Pj4NCj4+Pj4gVGhlIHRo ZW9yZXRpY2FsIGdyb3VuZHMgZm9yIHRoaXMgYXJlIGluIFQuIEdyaWZmaW7igJlzIGFuZA0KPj4+ PiBTb2JyaW5ob+KAmXMgd29yayBvbiBCR1AtNCBhbmQgdGhhdCBsaWVzIGFscmVhZHkgYSBjb3Vw bGUgb2YgeWVhcnMgYWdvIGFuZCB0aGF0DQo+Pj4+IG1ha2VzIHRoZSBhbmFseXNpcyBtdWNoIOKA mGVhc2llcuKAmSAobm8gd29ycmllcyBhYm91dCBucChjb21wbGV0ZSkgcHJvYmxlbXMsDQo+Pj4+ IGV0Yy4pLiBUaGlzIGNvdWxkIGJlIGFwcGxpZWQgaW4gSTJSUyBhdCB0aGUgcm91dGluZyBwcm90 b2NvbCBsZXZlbC4gU28sIHdlIGNvdWxkDQo+Pj4+IGRpc2N1c3Mgd2hlcmUgdGhhdCBzaXRzIChz aG91bGQgYmUgdGhlIGNsaWVudHMsIHJpZ2h0PykgYW5kIEkgZG9u4oCZdCBrbm93IGlmDQo+Pj4+ IHRoYXTigJlzIGJlZW4gYWxyZWFkeSBkb25lLCBzaW5jZSBJ4oCZbSBxdWl0ZSBuZXcgdG8gdGhp cyBsaXN0Lg0KPj4+DQo+Pj4gVGhpcyBkb2VzbuKAmXQgYXBwbHkgdG8gdGhlIHByb2JsZW0gYXQg aGFuZCwgdGhvdWdoLi4uIFlvdSBzZWVtIHRvIGJlIHNheWluZyAoY2xhcmlmeSBpZiB3cm9uZykg LS0NCj4+Pg0KPj4+IDEuIEdpdmUgZWFjaCBjbGllbnQgc29tZSBzZXQgb2YgYml0cyBvdXQgb2Yg YSAxMjggYml0IG51bWJlciBzcGFjZSAob3IgbGFyZ2VyLCBldGMuKQ0KPj4+IDIuIEVhY2ggY2xp ZW50IGNhbiBoYXZlIGRpZmZlcmVudCAibWV0cmljcyIgd2l0aGluIHRoZWlyIG93biBudW1iZXIg c3BhY2UNCj4+PiAzLiBXaGVuIGEgY2xpZW50IGF0dGVtcHRzIHRvIGFkZCBzb21lIGVwaGVtZXJh bCBzdGF0ZSwgdGhleSB1c2UgYSBtZXRyaWMgd2l0aGluIHRoZWlyICJzcGFjZSINCj4+PiA0LiBU aGUgYWdlbnQgY2FuIGp1c3QgdXNlIHRoZSBzdHJhaWdodCBudW1iZXIgYXMgYSByZWxhdGl2ZSBw cmlvcml0eSBmb3IgZWFjaCBwb3RlbnRpYWwgcGllY2Ugb2Ygc3RhdGUNCj4+Pg0KPj4+IFRoaXMg ZG9lc24ndCBkbyBhbnl0aGluZyBkaWZmZXJlbnQgdGhhbiB0aGUgY3VycmVudCBjb25jZXB0IG9m IHByaW9yaXR5IGJldHdlZW4gY2xpZW50cywgb25seSBpbiB0aGUgY3VycmVudCBwbGFuIGVhY2gg Y2xpZW50IG9ubHkgaGFzIG9uZSBwcmlvcml0eSwgcmF0aGVyIHRoYW4gbXVsdGlwbGVzLiBJIGRv bid0IHNlZSB3aGVyZSB0aGlzIHJlbGF0ZXMgdG8gdGhlIHByb2JsZW0gYXQgaGFuZC4NCj4+Pg0K Pj4+PiBOb3csIGhhdmluZyDigJxzb2x2ZWTigJ0gdGhhdCBwYXJ0IG9mIHRoZSBlcXVhdGlvbiA6 LSkgLCB0aGUgcGFydCB0aGF0IGludGVyZXN0cyBtZQ0KPj4+PiBtb3JlIGlzIHRoZSBjb25mbGlj dGluZyBjbGllbnRzIHByb2JsZW0sIGJlY2F1c2UgdGhpcyBjb3VsZCBiZSBnZW5lcmFsaXNlZCB0 bw0KPj4+PiBvdGhlciBwcm9ibGVtIHNwYWNlcyBpbiB0aGUgU0ROIGFyZWEuIEkgZG8gYWdyZWUg dGhhdCBhZ2VudHMgc2hvdWxkIGJlIGFibGUNCj4+Pj4gdG8gY2F0Y2ggb2ZmZW5kaW5nIHN0YXRl IGJlZm9yZSBpbnN0YWxsaW5nIGl0IGFuZCBJ4oCZbSBsb29raW5nIGZvciB3YXlzIHRvIHNwZWNp ZnkNCj4+Pj4gYSBtaW5pbWFsIHNldCBvZiBmZWF0dXJlcyB0aGF0IG5lZWQgdG8gYmUgc3VwcG9y dGVkIGF0IHByb3RvY29sIGxldmVsLg0KPj4+Pg0KPj4+PiBBbnlvbmUgZWxzZSBpbnRlcmVzdGVk Pw0KPj4+DQo+Pj4gVGhpcyBpcyBwcmVjaXNlbHkgd2hlcmUgdGhlIHByb2JsZW0gbGllcy4gQW5k IHRoaXMgaXMgd2hlcmUgeW91J3JlIGdvaW5nIHRvIGhpdCB0aGUgQ0FQIHRoZW9yZW0gaW4gZnVs bCBmb3JjZS4gVGhlcmUgYXJlIG9ubHkgYSBmZXcgY2hvaWNlcyAtLQ0KPj4+DQo+Pj4gMS4gTWFr ZSB0aGUgZGF0YWJhc2UgZXZlbnR1YWxseSBjb25zaXN0ZW50DQo+Pj4gMi4gU2h1dCBkb3duIGFj Y2Vzc2liaWxpdHkgZHVyaW5nIGNoYW5nZXMNCj4+PiAzLiA/Pw0KPj4+DQo+Pj4gKDEpIGlzIHRo ZSBpZGVhIG9mIGVpdGhlciBoYXZpbmcgdGhlIGFnZW50IGNhbGwgYmFjayB0byBhbGwgdGhlIGNs aWVudHMgd2hlbiBzdGF0ZSB0aGV5IGluc3RhbGxlZCBpcyBvdmVyd3JpdHRlbiBvciBhbGxvd2lu ZyB0aGUgYWdlbnQgdG8gbG9jYWxseSBzdG9yZSBzb21lIHN0YXRlIHdoZXJlIGl0IGFscmVhZHkg aGFzIHRoZSBpbmZvcm1hdGlvbiBpbiBoYW5kIGFuZCBpbnN0YWxsIGl0IGxvY2FsbHkgLS0gdGhl IG9ubHkgcmVhbCBkaWZmZXJlbmNlIGJldHdlZW4gdGhlc2UgdHdvIHNvbHV0aW9ucyBpcyB0aGUg ImJhbGFuY2Ugb2YgY29tcGxleGl0eSB2ZXJzdXMgc3BlZWQuLi4iIFRoZSBlbnRpcmUgZGlzY3Vz c2lvbiBoZXJlIGlzIGhvdyBtdWNoIGFkZGl0aW9uYWwgY29tcGxleGl0eSBhcmUgd2UgYWN0dWFs bHkgYWRkaW5nIGJ5IGRvaW5nICJwYW5lcyBvZiBnbGFzcywiIHdoaWNoIGFyZSBqdXN0IGxvY2Fs bHkgc3RvcmVkIHN0YXRlIHdoaWNoIGlzbid0IGN1cnJlbnRseSBpbnN0YWxsZWQuIEknbSBhcmd1 aW5nIHRoYXQgdGhlcmUncyBtaW5pbWFsIGNvbXBsZXhpdHkgYWRkZWQgdGhhdCB5b3UncmUgbm90 IGFscmVhZHkgZ29pbmcgdG8gaGF2ZSBpbiB0aGUgc3lzdGVtIHRvIGFsbG93IHRoZSBhZ2VudCB0 byBzdG9yZSBpbmZvcm1hdGlvbiBsb2NhbGx5IF9pZl8gaXQgY2hvb3NlcyB0by4gSmVmZiBpcyBh cmd1aW5nIChJIHRoaW5rKSB0aGF0IHRoZSAicGFuZXMgb2YgZ2xhc3MiIGNvbmNlcHQgaXMgYSBj b2hlcmVudCB3YXkgb2YgbG9va2luZyBhdCB0aGlzIHByb2JsZW0gdGhhdCB3aWxsIGhlbHAgdXMg dW5kZXJzdGFuZCBhbmQgbWFuYWdlIHRoZSBjb21wbGV4aXR5IGluIGEgd2F5IHRoYXQgbWFrZXMg c2Vuc2UuIEpvZWwgaXMgYXJndWluZyAoSSB0aGluaykgdGhhdCB0aGlzIHNvcnQgb2Ygc29sdXRp b24gaXMgb3V0IG9mIHRoZSBXRyBjaGFydGVyLCBhbmQgaXQncyB0b28gY29tcGxleC4gSSBfdGhp bmtfIEkgaGF2DQo+IGUgdGhlIHRoDQo+IHINCj5lZSBnZW5lcmFsIHBlcnNwZWN0aXZlcyByaWdo dCwgYnV0IEkgZG9uJ3Qga25vdyBpZiBJIHJlYWxseSBoYXZlIHNvLi4uIDotKQ0KPj4+DQo+Pj4g KDIpIGlzIHRoZSBpZGVhIG9mIGxvY2tpbmcgdGhlIGRhdGFiYXNlIHdoaWxlIHlvdSdyZSBjaGFu Z2luZyBpdC4gVGhpcyBpcyBleHBsaWNpdGx5IG91dHNpZGUgdGhlIHNjb3BlIG9mIEkyUlMgZW50 aXJlbHksIGdpdmVuIHdlJ3JlIHRyeWluZyB0byBkZXNpZ24gc29tZXRoaW5nIHRoYXQncyBhdG9t aWMvcmVzdGZ1bC4gVGhlcmUgYXJlIGEgbG90IG9mIHRlY2huaXF1ZXMgeW91IGNhbiB1c2UgdG8g c3BlZWQgdXAgbG9ja2luZyAtLSByb3cgbG9ja2luZywgc2hhcmRpbmcsIGV0Yy4gLS0gYnV0IG5v bmUgb2YgdGhlc2UgYXJlIGludGVyZXN0aW5nIGZyb20gdGhlIEkyUlMgcGVyc3BlY3RpdmUuDQo+ Pj4NCj4+PiA6LSkNCj4+Pg0KPj4+IFJ1c3MNCj4+Pg0KPj4NCj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+Pg0KPj4gRXN0ZSBtZW5zYWplIHkgc3VzIGFkanVudG9zIHNlIGRp cmlnZW4gZXhjbHVzaXZhbWVudGUgYSBzdSBkZXN0aW5hdGFyaW8sIHB1ZWRlIGNvbnRlbmVyIGlu Zm9ybWFjacOzbiBwcml2aWxlZ2lhZGEgbyBjb25maWRlbmNpYWwgeSBlcyBwYXJhIHVzbyBleGNs dXNpdm8gZGUgbGEgcGVyc29uYSBvIGVudGlkYWQgZGUgZGVzdGluby4gU2kgbm8gZXMgdXN0ZWQu IGVsIGRlc3RpbmF0YXJpbyBpbmRpY2FkbywgcXVlZGEgbm90aWZpY2FkbyBkZSBxdWUgbGEgbGVj dHVyYSwgdXRpbGl6YWNpw7NuLCBkaXZ1bGdhY2nDs24geS9vIGNvcGlhIHNpbiBhdXRvcml6YWNp w7NuIHB1ZWRlIGVzdGFyIHByb2hpYmlkYSBlbiB2aXJ0dWQgZGUgbGEgbGVnaXNsYWNpw7NuIHZp Z2VudGUuIFNpIGhhIHJlY2liaWRvIGVzdGUgbWVuc2FqZSBwb3IgZXJyb3IsIGxlIHJvZ2Ftb3Mg cXVlIG5vcyBsbyBjb211bmlxdWUgaW5tZWRpYXRhbWVudGUgcG9yIGVzdGEgbWlzbWEgdsOtYSB5 IHByb2NlZGEgYSBzdSBkZXN0cnVjY2nDs24uDQo+Pg0KPj4gVGhlIGluZm9ybWF0aW9uIGNvbnRh aW5lZCBpbiB0aGlzIHRyYW5zbWlzc2lvbiBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwg aW5mb3JtYXRpb24gaW50ZW5kZWQgb25seSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBv ciBlbnRpdHkgbmFtZWQgYWJvdmUuIElmIHRoZSByZWFkZXIgb2YgdGhpcyBtZXNzYWdlIGlzIG5v dCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFu eSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24gb3IgY29weWluZyBvZiB0aGlzIGNvbW11bmlj YXRpb24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0 cmFuc21pc3Npb24gaW4gZXJyb3IsIGRvIG5vdCByZWFkIGl0LiBQbGVhc2UgaW1tZWRpYXRlbHkg cmVwbHkgdG8gdGhlIHNlbmRlciB0aGF0IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNh dGlvbiBpbiBlcnJvciBhbmQgdGhlbiBkZWxldGUgaXQuDQo+Pg0KPj4gRXN0YSBtZW5zYWdlbSBl IHNldXMgYW5leG9zIHNlIGRpcmlnZW0gZXhjbHVzaXZhbWVudGUgYW8gc2V1IGRlc3RpbmF0w6Fy aW8sIHBvZGUgY29udGVyIGluZm9ybWHDp8OjbyBwcml2aWxlZ2lhZGEgb3UgY29uZmlkZW5jaWFs IGUgw6kgcGFyYSB1c28gZXhjbHVzaXZvIGRhIHBlc3NvYSBvdSBlbnRpZGFkZSBkZSBkZXN0aW5v LiBTZSBuw6NvIMOpIHZvc3NhIHNlbmhvcmlhIG8gZGVzdGluYXTDoXJpbyBpbmRpY2FkbywgZmlj YSBub3RpZmljYWRvIGRlIHF1ZSBhIGxlaXR1cmEsIHV0aWxpemHDp8OjbywgZGl2dWxnYcOnw6Nv IGUvb3UgY8OzcGlhIHNlbSBhdXRvcml6YcOnw6NvIHBvZGUgZXN0YXIgcHJvaWJpZGEgZW0gdmly dHVkZSBkYSBsZWdpc2xhw6fDo28gdmlnZW50ZS4gU2UgcmVjZWJldSBlc3RhIG1lbnNhZ2VtIHBv ciBlcnJvLCByb2dhbW9zLWxoZSBxdWUgbm9zIG8gY29tdW5pcXVlIGltZWRpYXRhbWVudGUgcG9y IGVzdGEgbWVzbWEgdmlhIGUgcHJvY2VkYSBhIHN1YSBkZXN0cnVpw6fDo28NCj4+DQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkVzdGUgbWVuc2FqZSB5IHN1cyBhZGp1bnRv cyBzZSBkaXJpZ2VuIGV4Y2x1c2l2YW1lbnRlIGEgc3UgZGVzdGluYXRhcmlvLCBwdWVkZSBjb250 ZW5lciBpbmZvcm1hY2nDs24gcHJpdmlsZWdpYWRhIG8gY29uZmlkZW5jaWFsIHkgZXMgcGFyYSB1 c28gZXhjbHVzaXZvIGRlIGxhIHBlcnNvbmEgbyBlbnRpZGFkIGRlIGRlc3Rpbm8uIFNpIG5vIGVz IHVzdGVkLiBlbCBkZXN0aW5hdGFyaW8gaW5kaWNhZG8sIHF1ZWRhIG5vdGlmaWNhZG8gZGUgcXVl IGxhIGxlY3R1cmEsIHV0aWxpemFjacOzbiwgZGl2dWxnYWNpw7NuIHkvbyBjb3BpYSBzaW4gYXV0 b3JpemFjacOzbiBwdWVkZSBlc3RhciBwcm9oaWJpZGEgZW4gdmlydHVkIGRlIGxhIGxlZ2lzbGFj acOzbiB2aWdlbnRlLiBTaSBoYSByZWNpYmlkbyBlc3RlIG1lbnNhamUgcG9yIGVycm9yLCBsZSBy b2dhbW9zIHF1ZSBub3MgbG8gY29tdW5pcXVlIGlubWVkaWF0YW1lbnRlIHBvciBlc3RhIG1pc21h IHbDrWEgeSBwcm9jZWRhIGEgc3UgZGVzdHJ1Y2Npw7NuLg0KDQpUaGUgaW5mb3JtYXRpb24gY29u dGFpbmVkIGluIHRoaXMgdHJhbnNtaXNzaW9uIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlh bCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBvbmx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFs IG9yIGVudGl0eSBuYW1lZCBhYm92ZS4gSWYgdGhlIHJlYWRlciBvZiB0aGlzIG1lc3NhZ2UgaXMg bm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQg YW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiBvciBjb3B5aW5nIG9mIHRoaXMgY29tbXVu aWNhdGlvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgZG8gbm90IHJlYWQgaXQuIFBsZWFzZSBpbW1lZGlhdGVs eSByZXBseSB0byB0aGUgc2VuZGVyIHRoYXQgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5p Y2F0aW9uIGluIGVycm9yIGFuZCB0aGVuIGRlbGV0ZSBpdC4NCg0KRXN0YSBtZW5zYWdlbSBlIHNl dXMgYW5leG9zIHNlIGRpcmlnZW0gZXhjbHVzaXZhbWVudGUgYW8gc2V1IGRlc3RpbmF0w6FyaW8s IHBvZGUgY29udGVyIGluZm9ybWHDp8OjbyBwcml2aWxlZ2lhZGEgb3UgY29uZmlkZW5jaWFsIGUg w6kgcGFyYSB1c28gZXhjbHVzaXZvIGRhIHBlc3NvYSBvdSBlbnRpZGFkZSBkZSBkZXN0aW5vLiBT ZSBuw6NvIMOpIHZvc3NhIHNlbmhvcmlhIG8gZGVzdGluYXTDoXJpbyBpbmRpY2FkbywgZmljYSBu b3RpZmljYWRvIGRlIHF1ZSBhIGxlaXR1cmEsIHV0aWxpemHDp8OjbywgZGl2dWxnYcOnw6NvIGUv b3UgY8OzcGlhIHNlbSBhdXRvcml6YcOnw6NvIHBvZGUgZXN0YXIgcHJvaWJpZGEgZW0gdmlydHVk ZSBkYSBsZWdpc2xhw6fDo28gdmlnZW50ZS4gU2UgcmVjZWJldSBlc3RhIG1lbnNhZ2VtIHBvciBl cnJvLCByb2dhbW9zLWxoZSBxdWUgbm9zIG8gY29tdW5pcXVlIGltZWRpYXRhbWVudGUgcG9yIGVz dGEgbWVzbWEgdmlhIGUgcHJvY2VkYSBhIHN1YSBkZXN0cnVpw6fDo28NCg== From nobody Tue Nov 24 08:15:00 2015 Return-Path: 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 F26621A8AF3 for ; Tue, 24 Nov 2015 08:14:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 m1cXlqMolUWX for ; Tue, 24 Nov 2015 08:14:56 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 989641A8AF0 for ; Tue, 24 Nov 2015 08:14:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 86F44251341; Tue, 24 Nov 2015 08:14:56 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 9E5D7259F31; Tue, 24 Nov 2015 08:14:55 -0800 (PST) To: Andy Bierman References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> <563A97AA.5020308@joelhalpern.com> <00f301d11761$61699130$243cb390$@gmail.com> <563AA59C.4060809@joelhalpern.com> <018101d11764$66b82e50$34288af0$@gmail.com> <20151119203509.GA22415@pfrc.org> <5B54713B-CDE6-4F65-BE79-91F5B9FF3850@telefonica.com> <008d01d12390$064987c0$12dc9740$@gmail.com> <99B64F3B-20A1-4D3C-A445-46D235EDB44D@telefonica.com> <014a01d12394$ec5ffa60$c51fef20$@gmail.com> <87361DB1-DC6F-4023-A807-4003B436B472@telefonica.com> <012501d125e7$62e457e0$28ad07a0$@gmail.com> <0EAC7123-CECA-4C34-B5E3-E89F0C8DBF94@telefonica.com> <56548418.6060603@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <56548CF8.8030900@joelhalpern.com> Date: Tue, 24 Nov 2015 11:14:48 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Jeffrey Haas , PEDRO ANDRES ARANDA GUTIERREZ , Susan Hares , Russ White <7riw77@gmail.com>, "i2rs@ietf.org" Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 16:14:59 -0000 The agent is required to detect and report direct collisions. It is not required or expected to detect indirect collisions, which are the complex source of wedgies and other interesting behaviors. Yours, Joel PS: The WG discussed requiring a maintained connection between the client and agent, and agreed not to do that. Which means that no, agents do not delete state just because clients have disappeared. On 11/24/15 11:01 AM, Andy Bierman wrote: > > > On Tue, Nov 24, 2015 at 7:36 AM, Joel M. Halpern > wrote: > > I believe that determining whether two independent and internally > consistent sets of changes can, in combination, produce a wedgie or > other failure is a research problem. > As far as I know, the I2RS working group concluded that it was a > sufficiently hard problem that we did not expect the I2RS agent to > get involved in trying to detect, much less remediate, such > cross-object inconsistencies. > > > > But the I2RS agent is responsible for identifying an edit collision between > a new low-priority request and existing higher priority edits. That sounds > involved to me. So the agent cannot possibly solve this problem > yet it is responsible for precisely that in order to implement client > priority. > > The agent can see that /foo[42] exists in the request and /foo[42] exists > in the ephemeral datastore, and call that a collision. > > However, if /foo[1] or /bar[19] are also part of the "edit", such that > simply replacing > /foo[42] will break things, then the agent will not know. It will simply > overwrite > /foo[42] and leave /foo[1] and /bar[19] in the datastore. > > So is the low-priority client responsible for removing /foo[1] and /bar[19]? > Seems the answer is no. The client can go away and there are no cleanup > requirements mentioned in the architecture. > > > > Yours, > Joel > > > > Andy > > > On 11/24/15 10:32 AM, PEDRO ANDRES ARANDA GUTIERREZ wrote: > > Hi Russ, > > I’m trying to identify the differences between interactions with > routing protocols in I2RS and what is purely conflicts between > clients. Currently I see too many issues overlapping and I fear > that the trees are not letting us see the forest. > > So my take on routing protocols and wedgies might have been too > compact :-) Let me give it a second try: Stepping outside the > I2RS problem space, there is a lot of work that shows that the > origin for BGP-4 instability is that our beloved route-maps > create metrics that are not monotonically increasing or > decreasing and that makes the routing protocols meta-stable. > (BTW, I’m the first culprit when it comes to the use of them, I > have created more than one wedgie :-P ) Acknowledging that this > is a significant (and quite complex) problem for the Internet in > general, I feel that it should be treated somewhere else (GROW?). > > The perspective I would like to take here is: > - assume that we have two or more clients that produce perfectly > sound routing information (no wedgies there) > - assume they talk to the same agent > - now my questions > 1.- is there any way to detect whether the clients > produce contradicting/conflicting information? > 2.- is there any way to resolve these > contradictions/conflicts? > > BR, /PA > --- > Dr. Pedro A. Aranda Gutiérrez > > Technology Exploration - > Network Innovation & Virtualisation > email: pedroa d0t aranda At telefonica d0t com > Telefónica, Investigación y Desarrollo > C/ Zurbarán,12 > 28010 Madrid, Spain > > Fragen sind nicht da, um beantwortet zu werden. > Fragen sind da, um gestellt zu werden. > Georg Kreisler > > > > > > > > > -----Mensaje original----- > De: Russ White <7riw77@gmail.com > > Fecha: lunes, 23 de noviembre de 2015, 14:06 > Para: paag >, 'Jeffrey Haas' > > > CC: "i2rs@ietf.org " >, "'Joel M. Halpern'" > >, 'Andy > Bierman' >, Sue > Hares > > Asunto: RE: [i2rs] Conversation on Priority and Panes > > > Re the metric 'problem', just to be more precise in what > would be needed, > we are looking a metric that grows or decreases > monotonically across the > whole network. > > > I assume you mean in the routing space, and not in the > controller/client space, correct? In terms of a distributed > protocol? So, you're saying the delay could use "metrics" > between 11 and 20, while the bandwidth could use "metrics" > between 21 and 30, etc? And then you just add them all > together? That's what IS-IS has done for years... Even BGP > really only has one "metric," with following "tie > breakers..." So if you have something like weight/local > pref/etc, such that they occupy different "spaces" in a bit > pattern (something suggested, btw, in the original wide > community work, and in other places, as well), you're > actually just building a single metric. > > You've not "solved" the multiple metric problem -- just done > something a little different than EIGRP's K values to > combine them into a single metric, which is where you need > to be to have the ability to build a single stable SPT/DAG. > > The theoretical grounds for this are in T. Griffin’s and > Sobrinho’s work on BGP-4 and that lies already a couple > of years ago and that > makes the analysis much ‘easier’ (no worries about > np(complete) problems, > etc.). This could be applied in I2RS at the routing > protocol level. So, we could > discuss where that sits (should be the clients, right?) > and I don’t know if > that’s been already done, since I’m quite new to this list. > > > This doesn’t apply to the problem at hand, though... You > seem to be saying (clarify if wrong) -- > > 1. Give each client some set of bits out of a 128 bit number > space (or larger, etc.) > 2. Each client can have different "metrics" within their own > number space > 3. When a client attempts to add some ephemeral state, they > use a metric within their "space" > 4. The agent can just use the straight number as a relative > priority for each potential piece of state > > This doesn't do anything different than the current concept > of priority between clients, only in the current plan each > client only has one priority, rather than multiples. I don't > see where this relates to the problem at hand. > > Now, having “solved” that part of the equation :-) , the > part that interests me > more is the conflicting clients problem, because this > could be generalised to > other problem spaces in the SDN area. I do agree that > agents should be able > to catch offending state before installing it and I’m > looking for ways to specify > a minimal set of features that need to be supported at > protocol level. > > Anyone else interested? > > > This is precisely where the problem lies. And this is where > you're going to hit the CAP theorem in full force. There are > only a few choices -- > > 1. Make the database eventually consistent > 2. Shut down accessibility during changes > 3. ?? > > (1) is the idea of either having the agent call back to all > the clients when state they installed is overwritten or > allowing the agent to locally store some state where it > already has the information in hand and install it locally > -- the only real difference between these two solutions is > the "balance of complexity versus speed..." The entire > discussion here is how much additional complexity are we > actually adding by doing "panes of glass," which are just > locally stored state which isn't currently installed. I'm > arguing that there's minimal complexity added that you're > not already going to have in the system to allow the agent > to store information locally _if_ it chooses to. Jeff is > arguing (I think) that the "panes of glass" concept is a > coherent way of looking at this problem that will help us > understand and manage the complexity in a way that makes > sense. Joel is arguing (I think) that this sort of solution > is out of the WG charter, and it's too complex. I _think_ I > have the th > > r > ee general perspectives right, but I don't know if I really have > so... :-) > > > (2) is the idea of locking the database while you're > changing it. This is explicitly outside the scope of I2RS > entirely, given we're trying to design something that's > atomic/restful. There are a lot of techniques you can use to > speed up locking -- row locking, sharding, etc. -- but none > of these are interesting from the I2RS perspective. > > :-) > > Russ > > > ________________________________ > > Este mensaje y sus adjuntos se dirigen exclusivamente a su > destinatario, puede contener información privilegiada o > confidencial y es para uso exclusivo de la persona o entidad de > destino. Si no es usted. el destinatario indicado, queda > notificado de que la lectura, utilización, divulgación y/o copia > sin autorización puede estar prohibida en virtud de la > legislación vigente. Si ha recibido este mensaje por error, le > rogamos que nos lo comunique inmediatamente por esta misma vía y > proceda a su destrucción. > > The information contained in this transmission is privileged and > confidential information intended only for the use of the > individual or entity named above. If the reader of this message > is not the intended recipient, you are hereby notified that any > dissemination, distribution or copying of this communication is > strictly prohibited. If you have received this transmission in > error, do not read it. Please immediately reply to the sender > that you have received this communication in error and then > delete it. > > Esta mensagem e seus anexos se dirigem exclusivamente ao seu > destinatário, pode conter informação privilegiada ou > confidencial e é para uso exclusivo da pessoa ou entidade de > destino. Se não é vossa senhoria o destinatário indicado, fica > notificado de que a leitura, utilização, divulgação e/ou cópia > sem autorização pode estar proibida em virtude da legislação > vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos > o comunique imediatamente por esta mesma via e proceda a sua > destruição > > From nobody Tue Nov 24 08:29:36 2015 Return-Path: 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 6A6871A8F4A for ; Tue, 24 Nov 2015 08:29:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_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 WHCOoVbw3y1R for ; Tue, 24 Nov 2015 08:29:23 -0800 (PST) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (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 B92011A8768 for ; Tue, 24 Nov 2015 08:29:00 -0800 (PST) Received: by lfs39 with SMTP id 39so26360696lfs.3 for ; Tue, 24 Nov 2015 08:28:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=j7254fc1+bFl9+xyzbBWTdffQr5geH3C964xP90lf9Q=; b=SMJUCZxfn7MKqWI0Qx8u5yKGEWfzNAGFH242LfbI3T640TUSFP1/vvgitIU601C59L sKR3Mi9iwDdHCU2mUF/5ZCRCLglJo/WoEPbiI+xu0oi3drJttLyGiU4GSXVZz0/5zOmN UuDt0uleJXirdwYPh76m8pSH35CmoQvmkNsT0xITH9pvV3KWI+xPxbtYu9Et5W5a7Alh XDYdXl7GjcRLHOnH8TYI9Cun7w8m7AweS4YEfKhPm/dtsqFBdpW3W9VqNr0wfqgT+1KL VyNZ+nGixwJwoCrNnI8fqFm0cxHXvg0pfoW2CIpiuIOeDd5SFqFNoasvNlZ0faFC6ZHq eGpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=j7254fc1+bFl9+xyzbBWTdffQr5geH3C964xP90lf9Q=; b=D7zuvNEqTLMjlG8KO6YefzsJlMPXO0qCRZ+IyTBy9CnucHSeYY5QWv2Z1Ydn9JYALb ATwZLrI5n7/RFyuUSzo79j5q+9gCrf5c1xwHRrjUHfKn4jZBhn7/qtrJSiJ58Wmj7JLz U2FDTeRf0IC/OQyDcB3f1gwrnFhuSwklGrZjxEGzDP+RVswOSEjRaAzARcr/SYD7eRTE jf8YHxRpSw4T02XYBUx95vax2CH2KMwK8WvpLFCx45xmK1c1wfOxs6MG1obpmr4SXvhB FWxYJYmviHFc0ah63ZTjMBKB9mvjgqW1Q3L/ABiWW5fiNW0Wwmq/rpsD5lJj1VU2GSiA Ho6w== X-Gm-Message-State: ALoCoQlm5DiMceCnGcY3chFwr3jOMJPtG9iCd8wBnrVKufYDGAZgK7rt5/OT77958tnv1Ek05wRj MIME-Version: 1.0 X-Received: by 10.112.140.197 with SMTP id ri5mr13269898lbb.65.1448382537282; Tue, 24 Nov 2015 08:28:57 -0800 (PST) Received: by 10.112.144.36 with HTTP; Tue, 24 Nov 2015 08:28:56 -0800 (PST) In-Reply-To: <56548CF8.8030900@joelhalpern.com> References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> <563A97AA.5020308@joelhalpern.com> <00f301d11761$61699130$243cb390$@gmail.com> <563AA59C.4060809@joelhalpern.com> <018101d11764$66b82e50$34288af0$@gmail.com> <20151119203509.GA22415@pfrc.org> <5B54713B-CDE6-4F65-BE79-91F5B9FF3850@telefonica.com> <008d01d12390$064987c0$12dc9740$@gmail.com> <99B64F3B-20A1-4D3C-A445-46D235EDB44D@telefonica.com> <014a01d12394$ec5ffa60$c51fef20$@gmail.com> <87361DB1-DC6F-4023-A807-4003B436B472@telefonica.com> <012501d125e7$62e457e0$28ad07a0$@gmail.com> <0EAC7123-CECA-4C34-B5E3-E89F0C8DBF94@telefonica.com> <56548418.6060603@joelhalpern.com> <56548CF8.8030900@joelhalpern.com> Date: Tue, 24 Nov 2015 08:28:56 -0800 Message-ID: From: Andy Bierman To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=001a11c25b46a24f4105254bd6c2 Archived-At: Cc: Jeffrey Haas , PEDRO ANDRES ARANDA GUTIERREZ , Susan Hares , Russ White <7riw77@gmail.com>, "i2rs@ietf.org" Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 16:29:27 -0000 --001a11c25b46a24f4105254bd6c2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Nov 24, 2015 at 8:14 AM, Joel M. Halpern wrote: > The agent is required to detect and report direct collisions. > It is not required or expected to detect indirect collisions, which are > the complex source of wedgies and other interesting behaviors. > > OK, punting the problem is fair enough. What happens when the YANG validation for /foo[19] and /bar[1] now fails because /foo[42] was changed? Does the agent reject the edit from the higher priority client? Does I2RS ignore YANG validation= , assuming the YANG authors really didn't mean what they wrote? Yours, > Joel > > Andy > PS: The WG discussed requiring a maintained connection between the client > and agent, and agreed not to do that. Which means that no, agents do not > delete state just because clients have disappeared. > > > On 11/24/15 11:01 AM, Andy Bierman wrote: > >> >> >> On Tue, Nov 24, 2015 at 7:36 AM, Joel M. Halpern > > wrote: >> >> I believe that determining whether two independent and internally >> consistent sets of changes can, in combination, produce a wedgie or >> other failure is a research problem. >> As far as I know, the I2RS working group concluded that it was a >> sufficiently hard problem that we did not expect the I2RS agent to >> get involved in trying to detect, much less remediate, such >> cross-object inconsistencies. >> >> >> >> But the I2RS agent is responsible for identifying an edit collision >> between >> a new low-priority request and existing higher priority edits. That soun= ds >> involved to me. So the agent cannot possibly solve this problem >> yet it is responsible for precisely that in order to implement client >> priority. >> >> The agent can see that /foo[42] exists in the request and /foo[42] exist= s >> in the ephemeral datastore, and call that a collision. >> >> However, if /foo[1] or /bar[19] are also part of the "edit", such that >> simply replacing >> /foo[42] will break things, then the agent will not know. It will simply >> overwrite >> /foo[42] and leave /foo[1] and /bar[19] in the datastore. >> >> So is the low-priority client responsible for removing /foo[1] and >> /bar[19]? >> Seems the answer is no. The client can go away and there are no cleanup >> requirements mentioned in the architecture. >> >> >> >> Yours, >> Joel >> >> >> >> Andy >> >> >> On 11/24/15 10:32 AM, PEDRO ANDRES ARANDA GUTIERREZ wrote: >> >> Hi Russ, >> >> I=E2=80=99m trying to identify the differences between interacti= ons with >> routing protocols in I2RS and what is purely conflicts between >> clients. Currently I see too many issues overlapping and I fear >> that the trees are not letting us see the forest. >> >> So my take on routing protocols and wedgies might have been too >> compact :-) Let me give it a second try: Stepping outside the >> I2RS problem space, there is a lot of work that shows that the >> origin for BGP-4 instability is that our beloved route-maps >> create metrics that are not monotonically increasing or >> decreasing and that makes the routing protocols meta-stable. >> (BTW, I=E2=80=99m the first culprit when it comes to the use of = them, I >> have created more than one wedgie :-P ) Acknowledging that this >> is a significant (and quite complex) problem for the Internet in >> general, I feel that it should be treated somewhere else (GROW?)= . >> >> The perspective I would like to take here is: >> - assume that we have two or more clients that produce perfectly >> sound routing information (no wedgies there) >> - assume they talk to the same agent >> - now my questions >> 1.- is there any way to detect whether the clients >> produce contradicting/conflicting information? >> 2.- is there any way to resolve these >> contradictions/conflicts? >> >> BR, /PA >> --- >> Dr. Pedro A. Aranda Guti=C3=A9rrez >> >> Technology Exploration - >> Network Innovation & Virtualisation >> email: pedroa d0t aranda At telefonica d0t com >> Telef=C3=B3nica, Investigaci=C3=B3n y Desarrollo >> C/ Zurbar=C3=A1n,12 >> 28010 Madrid, Spain >> >> Fragen sind nicht da, um beantwortet zu werden. >> Fragen sind da, um gestellt zu werden. >> Georg Kreisler >> >> >> >> >> >> >> >> >> -----Mensaje original----- >> De: Russ White <7riw77@gmail.com > >> Fecha: lunes, 23 de noviembre de 2015, 14:06 >> Para: paag > >, 'Jeffrey Haas' >> > >> CC: "i2rs@ietf.org " > >, "'Joel M. Halpern'" >> >, 'Andy >> Bierman' >, Sue >> Hares > >> Asunto: RE: [i2rs] Conversation on Priority and Panes >> >> >> Re the metric 'problem', just to be more precise in what >> would be needed, >> we are looking a metric that grows or decreases >> monotonically across the >> whole network. >> >> >> I assume you mean in the routing space, and not in the >> controller/client space, correct? In terms of a distributed >> protocol? So, you're saying the delay could use "metrics" >> between 11 and 20, while the bandwidth could use "metrics" >> between 21 and 30, etc? And then you just add them all >> together? That's what IS-IS has done for years... Even BGP >> really only has one "metric," with following "tie >> breakers..." So if you have something like weight/local >> pref/etc, such that they occupy different "spaces" in a bit >> pattern (something suggested, btw, in the original wide >> community work, and in other places, as well), you're >> actually just building a single metric. >> >> You've not "solved" the multiple metric problem -- just done >> something a little different than EIGRP's K values to >> combine them into a single metric, which is where you need >> to be to have the ability to build a single stable SPT/DAG. >> >> The theoretical grounds for this are in T. Griffin=E2=80= =99s and >> Sobrinho=E2=80=99s work on BGP-4 and that lies already a= couple >> of years ago and that >> makes the analysis much =E2=80=98easier=E2=80=99 (no wor= ries about >> np(complete) problems, >> etc.). This could be applied in I2RS at the routing >> protocol level. So, we could >> discuss where that sits (should be the clients, right?) >> and I don=E2=80=99t know if >> that=E2=80=99s been already done, since I=E2=80=99m quit= e new to this >> list. >> >> >> This doesn=E2=80=99t apply to the problem at hand, though...= You >> seem to be saying (clarify if wrong) -- >> >> 1. Give each client some set of bits out of a 128 bit number >> space (or larger, etc.) >> 2. Each client can have different "metrics" within their own >> number space >> 3. When a client attempts to add some ephemeral state, they >> use a metric within their "space" >> 4. The agent can just use the straight number as a relative >> priority for each potential piece of state >> >> This doesn't do anything different than the current concept >> of priority between clients, only in the current plan each >> client only has one priority, rather than multiples. I don't >> see where this relates to the problem at hand. >> >> Now, having =E2=80=9Csolved=E2=80=9D that part of the eq= uation :-) , the >> part that interests me >> more is the conflicting clients problem, because this >> could be generalised to >> other problem spaces in the SDN area. I do agree that >> agents should be able >> to catch offending state before installing it and I=E2= =80=99m >> looking for ways to specify >> a minimal set of features that need to be supported at >> protocol level. >> >> Anyone else interested? >> >> >> This is precisely where the problem lies. And this is where >> you're going to hit the CAP theorem in full force. There are >> only a few choices -- >> >> 1. Make the database eventually consistent >> 2. Shut down accessibility during changes >> 3. ?? >> >> (1) is the idea of either having the agent call back to all >> the clients when state they installed is overwritten or >> allowing the agent to locally store some state where it >> already has the information in hand and install it locally >> -- the only real difference between these two solutions is >> the "balance of complexity versus speed..." The entire >> discussion here is how much additional complexity are we >> actually adding by doing "panes of glass," which are just >> locally stored state which isn't currently installed. I'm >> arguing that there's minimal complexity added that you're >> not already going to have in the system to allow the agent >> to store information locally _if_ it chooses to. Jeff is >> arguing (I think) that the "panes of glass" concept is a >> coherent way of looking at this problem that will help us >> understand and manage the complexity in a way that makes >> sense. Joel is arguing (I think) that this sort of solution >> is out of the WG charter, and it's too complex. I _think_ I >> have the th >> >> r >> ee general perspectives right, but I don't know if I really have >> so... :-) >> >> >> (2) is the idea of locking the database while you're >> changing it. This is explicitly outside the scope of I2RS >> entirely, given we're trying to design something that's >> atomic/restful. There are a lot of techniques you can use to >> speed up locking -- row locking, sharding, etc. -- but none >> of these are interesting from the I2RS perspective. >> >> :-) >> >> Russ >> >> >> ________________________________ >> >> Este mensaje y sus adjuntos se dirigen exclusivamente a su >> destinatario, puede contener informaci=C3=B3n privilegiada o >> confidencial y es para uso exclusivo de la persona o entidad de >> destino. Si no es usted. el destinatario indicado, queda >> notificado de que la lectura, utilizaci=C3=B3n, divulgaci=C3=B3n= y/o copia >> sin autorizaci=C3=B3n puede estar prohibida en virtud de la >> legislaci=C3=B3n vigente. Si ha recibido este mensaje por error,= le >> rogamos que nos lo comunique inmediatamente por esta misma v=C3= =ADa y >> proceda a su destrucci=C3=B3n. >> >> The information contained in this transmission is privileged and >> confidential information intended only for the use of the >> individual or entity named above. If the reader of this message >> is not the intended recipient, you are hereby notified that any >> dissemination, distribution or copying of this communication is >> strictly prohibited. If you have received this transmission in >> error, do not read it. Please immediately reply to the sender >> that you have received this communication in error and then >> delete it. >> >> Esta mensagem e seus anexos se dirigem exclusivamente ao seu >> destinat=C3=A1rio, pode conter informa=C3=A7=C3=A3o privilegiada= ou >> confidencial e =C3=A9 para uso exclusivo da pessoa ou entidade d= e >> destino. Se n=C3=A3o =C3=A9 vossa senhoria o destinat=C3=A1rio i= ndicado, fica >> notificado de que a leitura, utiliza=C3=A7=C3=A3o, divulga=C3=A7= =C3=A3o e/ou c=C3=B3pia >> sem autoriza=C3=A7=C3=A3o pode estar proibida em virtude da legi= sla=C3=A7=C3=A3o >> vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos >> o comunique imediatamente por esta mesma via e proceda a sua >> destrui=C3=A7=C3=A3o >> >> >> --001a11c25b46a24f4105254bd6c2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Nov 24, 2015 at 8:14 AM, Joel M. Halpern <= jmh@joelhalpern.co= m> wrote:
The agent is requ= ired to detect and report direct collisions.
It is not required or expected to detect indirect collisions, which are the= complex source of wedgies and other interesting behaviors.


OK, punting the problem is fair enough= .

What happens when the YANG validation for /foo[1= 9] and /bar[1]
now fails because /foo[42] was changed?=C2=A0 Does= the agent reject
the edit from the higher priority client?=C2=A0= Does I2RS ignore YANG validation,
assuming the YANG authors real= ly didn't mean what they wrote?


Yours,
Joel



Andy

=C2=A0
PS: The WG discussed requiring a maintained connection between the client a= nd agent, and agreed not to do that.=C2=A0 Which means that no, agents do n= ot delete state just because clients have disappeared.


On 11/24/15 11:01 AM, Andy Bierman wrote:


On Tue, Nov 24, 2015 at 7:36 AM, Joel M. Halpern <jmh@joelhalpern.com
<mailto:jmh@joe= lhalpern.com>> wrote:

=C2=A0 =C2=A0 I believe that determining whether two independent and intern= ally
=C2=A0 =C2=A0 consistent sets of changes can, in combination, produce a wed= gie or
=C2=A0 =C2=A0 other failure is a research problem.
=C2=A0 =C2=A0 As far as I know, the I2RS working group concluded that it wa= s a
=C2=A0 =C2=A0 sufficiently hard problem that we did not expect the I2RS age= nt to
=C2=A0 =C2=A0 get involved in trying to detect, much less remediate, such =C2=A0 =C2=A0 cross-object inconsistencies.



But the I2RS agent is responsible for identifying an edit collision between=
a new low-priority request and existing higher priority edits. That sounds<= br> involved to me.=C2=A0 So the agent cannot possibly solve this problem
yet it is responsible for precisely that in order to implement client
priority.

The agent can see that /foo[42] exists in the request and /foo[42] exists in the ephemeral datastore, and call that a collision.

However, if /foo[1] or /bar[19] are also part of the "edit", such= that
simply replacing
/foo[42] will break things, then the agent will not know. It will simply overwrite
/foo[42] and leave /foo[1] and /bar[19] in the datastore.

So is the low-priority client responsible for removing /foo[1] and /bar[19]= ?
Seems the answer is no. The client can go away and there are no cleanup
requirements mentioned in the architecture.



=C2=A0 =C2=A0 Yours,
=C2=A0 =C2=A0 Joel



Andy


=C2=A0 =C2=A0 On 11/24/15 10:32 AM, PEDRO ANDRES ARANDA GUTIERREZ wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi Russ,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I=E2=80=99m trying to identify the differences = between interactions with
=C2=A0 =C2=A0 =C2=A0 =C2=A0 routing protocols in I2RS and what is purely co= nflicts between
=C2=A0 =C2=A0 =C2=A0 =C2=A0 clients. Currently I see too many issues overla= pping and I fear
=C2=A0 =C2=A0 =C2=A0 =C2=A0 that the trees are not letting us see the fores= t.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 So my take on routing protocols and wedgies mig= ht have been too
=C2=A0 =C2=A0 =C2=A0 =C2=A0 compact :-) Let me give it a second try: Steppi= ng outside the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 I2RS problem space, there is a lot of work that= shows that the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 origin for BGP-4 instability is that our belove= d route-maps
=C2=A0 =C2=A0 =C2=A0 =C2=A0 create metrics that are not monotonically incre= asing or
=C2=A0 =C2=A0 =C2=A0 =C2=A0 decreasing and that makes the routing protocols= meta-stable.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (BTW, I=E2=80=99m the first culprit when it com= es to the use of them, I
=C2=A0 =C2=A0 =C2=A0 =C2=A0 have created more than one wedgie :-P ) Acknowl= edging that this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 is a significant (and quite complex) problem fo= r the Internet in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 general, I feel that it should be treated somew= here else (GROW?).

=C2=A0 =C2=A0 =C2=A0 =C2=A0 The perspective I would like to take here is: =C2=A0 =C2=A0 =C2=A0 =C2=A0 - assume that we have two or more clients that = produce perfectly
=C2=A0 =C2=A0 =C2=A0 =C2=A0 sound routing information (no wedgies there) =C2=A0 =C2=A0 =C2=A0 =C2=A0 - assume they talk to the same agent
=C2=A0 =C2=A0 =C2=A0 =C2=A0 - now my questions
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1.- is there= any way to detect whether the clients
=C2=A0 =C2=A0 =C2=A0 =C2=A0 produce contradicting/conflicting information?<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2.- is there= any way to resolve these
=C2=A0 =C2=A0 =C2=A0 =C2=A0 contradictions/conflicts?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 BR, /PA
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ---
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Dr. Pedro A. Aranda Guti=C3=A9rrez

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Technology Exploration -
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Network Innovation & Virtualisation
=C2=A0 =C2=A0 =C2=A0 =C2=A0 email: pedroa d0t aranda At telefonica d0t com<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Telef=C3=B3nica, Investigaci=C3=B3n y Desarroll= o
=C2=A0 =C2=A0 =C2=A0 =C2=A0 C/ Zurbar=C3=A1n,12
=C2=A0 =C2=A0 =C2=A0 =C2=A0 28010 Madrid, Spain

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Fragen sind nicht da, um beantwortet zu werden.=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Fragen sind da, um gestellt zu werden.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Georg Kreisler








=C2=A0 =C2=A0 =C2=A0 =C2=A0 -----Mensaje original-----
=C2=A0 =C2=A0 =C2=A0 =C2=A0 De: Russ White <7riw77@gmail.com <mailto:7riw77@gmail.com>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Fecha: lunes, 23 de noviembre de 2015, 14:06 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Para: paag <pedroa.aranda@telefonica.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:pedroa.aranda@telefonica.com>>, = 9;Jeffrey Haas'
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <jhaas@pfrc.org <mailto:jhaas@pfrc.org>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 CC: "i2rs@ietf.org <mailto:i2rs@ietf.org>" <i2rs@ietf.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:i2rs@ietf.org>>, "'Joel M. Halpern'&q= uot;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>, 'Andy =C2=A0 =C2=A0 =C2=A0 =C2=A0 Bierman' <andy@yumaworks.com <mailto:andy@yumaworks.com>>, Su= e
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Hares <shares@ndzh.com <mailto:shares@ndzh.com>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Asunto: RE: [i2rs] Conversation on Priority and= Panes


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Re the metric '= problem', just to be more precise in what
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 would be needed, =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 we are looking a me= tric that grows or decreases
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 monotonically acros= s the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 whole network.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I assume you mean in the routing = space, and not in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 controller/client space, correct?= In terms of a distributed
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 protocol? So, you're saying t= he delay could use "metrics"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 between 11 and 20, while the band= width could use "metrics"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 between 21 and 30, etc? And then = you just add them all
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 together? That's what IS-IS h= as done for years... Even BGP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 really only has one "metric,= " with following "tie
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 breakers..." So if you have = something like weight/local
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 pref/etc, such that they occupy d= ifferent "spaces" in a bit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 pattern (something suggested, btw= , in the original wide
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 community work, and in other plac= es, as well), you're
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 actually just building a single m= etric.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 You've not "solved"= the multiple metric problem -- just done
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 something a little different than= EIGRP's K values to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 combine them into a single metric= , which is where you need
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to be to have the ability to buil= d a single stable SPT/DAG.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The theoretical gro= unds for this are in T. Griffin=E2=80=99s and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Sobrinho=E2=80=99s = work on BGP-4 and that lies already a couple
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of years ago and th= at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 makes the analysis = much =E2=80=98easier=E2=80=99 (no worries about
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 np(complete) proble= ms,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 etc.). This could b= e applied in I2RS at the routing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 protocol level. So,= we could
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 discuss where that = sits (should be the clients, right?)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and I don=E2=80=99t= know if
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 that=E2=80=99s been= already done, since I=E2=80=99m quite new to this list.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 This doesn=E2=80=99t apply to the= problem at hand, though... You
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 seem to be saying (clarify if wro= ng) --

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1. Give each client some set of b= its out of a 128 bit number
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 space (or larger, etc.)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2. Each client can have different= "metrics" within their own
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 number space
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3. When a client attempts to add = some ephemeral state, they
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 use a metric within their "s= pace"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 4. The agent can just use the str= aight number as a relative
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 priority for each potential piece= of state

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 This doesn't do anything diff= erent than the current concept
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of priority between clients, only= in the current plan each
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 client only has one priority, rat= her than multiples. I don't
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 see where this relates to the pro= blem at hand.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Now, having =E2=80= =9Csolved=E2=80=9D that part of the equation :-) , the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 part that interests= me
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 more is the conflic= ting clients problem, because this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 could be generalise= d to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 other problem space= s in the SDN area. I do agree that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 agents should be ab= le
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to catch offending = state before installing it and I=E2=80=99m
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 looking for ways to= specify
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 a minimal set of fe= atures that need to be supported at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 protocol level.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Anyone else interes= ted?


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 This is precisely where the probl= em lies. And this is where
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 you're going to hit the CAP t= heorem in full force. There are
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 only a few choices --

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1. Make the database eventually c= onsistent
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2. Shut down accessibility during= changes
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3. ??

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (1) is the idea of either having = the agent call back to all
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the clients when state they insta= lled is overwritten or
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 allowing the agent to locally sto= re some state where it
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 already has the information in ha= nd and install it locally
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- the only real difference betwe= en these two solutions is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the "balance of complexity v= ersus speed..." The entire
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 discussion here is how much addit= ional complexity are we
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 actually adding by doing "pa= nes of glass," which are just
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 locally stored state which isn= 9;t currently installed. I'm
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 arguing that there's minimal = complexity added that you're
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 not already going to have in the = system to allow the agent
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to store information locally _if_= it chooses to. Jeff is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 arguing (I think) that the "= panes of glass" concept is a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 coherent way of looking at this p= roblem that will help us
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 understand and manage the complex= ity in a way that makes
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 sense. Joel is arguing (I think) = that this sort of solution
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 is out of the WG charter, and it&= #39;s too complex. I _think_ I
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 have the th

=C2=A0 =C2=A0 r
=C2=A0 =C2=A0 ee general perspectives right, but I don't know if I real= ly have
=C2=A0 =C2=A0 so... :-)


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (2) is the idea of locking the da= tabase while you're
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 changing it. This is explicitly o= utside the scope of I2RS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 entirely, given we're trying = to design something that's
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 atomic/restful. There are a lot o= f techniques you can use to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 speed up locking -- row locking, = sharding, etc. -- but none
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of these are interesting from the= I2RS perspective.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :-)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Russ


=C2=A0 =C2=A0 =C2=A0 =C2=A0 ________________________________

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Este mensaje y sus adjuntos se dirigen exclusiv= amente a su
=C2=A0 =C2=A0 =C2=A0 =C2=A0 destinatario, puede contener informaci=C3=B3n p= rivilegiada o
=C2=A0 =C2=A0 =C2=A0 =C2=A0 confidencial y es para uso exclusivo de la pers= ona o entidad de
=C2=A0 =C2=A0 =C2=A0 =C2=A0 destino. Si no es usted. el destinatario indica= do, queda
=C2=A0 =C2=A0 =C2=A0 =C2=A0 notificado de que la lectura, utilizaci=C3=B3n,= divulgaci=C3=B3n y/o copia
=C2=A0 =C2=A0 =C2=A0 =C2=A0 sin autorizaci=C3=B3n puede estar prohibida en = virtud de la
=C2=A0 =C2=A0 =C2=A0 =C2=A0 legislaci=C3=B3n vigente. Si ha recibido este m= ensaje por error, le
=C2=A0 =C2=A0 =C2=A0 =C2=A0 rogamos que nos lo comunique inmediatamente por= esta misma v=C3=ADa y
=C2=A0 =C2=A0 =C2=A0 =C2=A0 proceda a su destrucci=C3=B3n.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 The information contained in this transmission = is privileged and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 confidential information intended only for the = use of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 individual or entity named above. If the reader= of this message
=C2=A0 =C2=A0 =C2=A0 =C2=A0 is not the intended recipient, you are hereby n= otified that any
=C2=A0 =C2=A0 =C2=A0 =C2=A0 dissemination, distribution or copying of this = communication is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 strictly prohibited. If you have received this = transmission in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 error, do not read it. Please immediately reply= to the sender
=C2=A0 =C2=A0 =C2=A0 =C2=A0 that you have received this communication in er= ror and then
=C2=A0 =C2=A0 =C2=A0 =C2=A0 delete it.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Esta mensagem e seus anexos se dirigem exclusiv= amente ao seu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 destinat=C3=A1rio, pode conter informa=C3=A7=C3= =A3o privilegiada ou
=C2=A0 =C2=A0 =C2=A0 =C2=A0 confidencial e =C3=A9 para uso exclusivo da pes= soa ou entidade de
=C2=A0 =C2=A0 =C2=A0 =C2=A0 destino. Se n=C3=A3o =C3=A9 vossa senhoria o de= stinat=C3=A1rio indicado, fica
=C2=A0 =C2=A0 =C2=A0 =C2=A0 notificado de que a leitura, utiliza=C3=A7=C3= =A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia
=C2=A0 =C2=A0 =C2=A0 =C2=A0 sem autoriza=C3=A7=C3=A3o pode estar proibida e= m virtude da legisla=C3=A7=C3=A3o
=C2=A0 =C2=A0 =C2=A0 =C2=A0 vigente. Se recebeu esta mensagem por erro, rog= amos-lhe que nos
=C2=A0 =C2=A0 =C2=A0 =C2=A0 o comunique imediatamente por esta mesma via e = proceda a sua
=C2=A0 =C2=A0 =C2=A0 =C2=A0 destrui=C3=A7=C3=A3o



--001a11c25b46a24f4105254bd6c2-- From nobody Tue Nov 24 08:53:44 2015 Return-Path: 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 2524B1B2D0D for ; Tue, 24 Nov 2015 08:53:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 IEihecx5nNdd for ; Tue, 24 Nov 2015 08:53:40 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F3531B2D05 for ; Tue, 24 Nov 2015 08:53:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 3A883259F28; Tue, 24 Nov 2015 08:53:40 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 487C724126D; Tue, 24 Nov 2015 08:53:39 -0800 (PST) To: Andy Bierman References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> <563A97AA.5020308@joelhalpern.com> <00f301d11761$61699130$243cb390$@gmail.com> <563AA59C.4060809@joelhalpern.com> <018101d11764$66b82e50$34288af0$@gmail.com> <20151119203509.GA22415@pfrc.org> <5B54713B-CDE6-4F65-BE79-91F5B9FF3850@telefonica.com> <008d01d12390$064987c0$12dc9740$@gmail.com> <99B64F3B-20A1-4D3C-A445-46D235EDB44D@telefonica.com> <014a01d12394$ec5ffa60$c51fef20$@gmail.com> <87361DB1-DC6F-4023-A807-4003B436B472@telefonica.com> <012501d125e7$62e457e0$28ad07a0$@gmail.com> <0EAC7123-CECA-4C34-B5E3-E89F0C8DBF94@telefonica.com> <56548418.6060603@joelhalpern.com> <56548CF8.8030900@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <5654960C.7040203@joelhalpern.com> Date: Tue, 24 Nov 2015 11:53:32 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Jeffrey Haas , PEDRO ANDRES ARANDA GUTIERREZ , Susan Hares , Russ White <7riw77@gmail.com>, "i2rs@ietf.org" Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 16:53:43 -0000 That is indeed a good question. As I understand the WG agreement, some validations of changes are to be performed, but as little as possible. So an agent can reject a change for validation, but we hoped to keep it as simple as possible. I am not sure that hop[e is achievable. One of the assumptions in making any ephemeral change is that if some other changes can affect what a client has done, it is the clients responsibility to subscribe to notifications about those other changes, and to undertake remedial actions if a problem is introduced. So if /foo[19] and /bar[1] interact with /baz[7] (or /foo[42]) then it is the clients job to monitor /baz[7] (or /foo[42]). The agent can't sort that out. As an example of an ugly case, suppose that /baz[7] has a value created by some other I2RS client. The changes to /foo[19] and /bar[1] might depend upon that value. When the other client removes its changes, the value reverts to the config value. That reversion clearly must take place. That can potential create problems for /foo[19] and /bar[1]. It seems to me that we have to leave it to the client to sort that out. Yours, Joel On 11/24/15 11:28 AM, Andy Bierman wrote: > > > On Tue, Nov 24, 2015 at 8:14 AM, Joel M. Halpern > wrote: > > The agent is required to detect and report direct collisions. > It is not required or expected to detect indirect collisions, which > are the complex source of wedgies and other interesting behaviors. > > > OK, punting the problem is fair enough. > > What happens when the YANG validation for /foo[19] and /bar[1] > now fails because /foo[42] was changed? Does the agent reject > the edit from the higher priority client? Does I2RS ignore YANG validation, > assuming the YANG authors really didn't mean what they wrote? > > > Yours, > Joel > > > > Andy > > PS: The WG discussed requiring a maintained connection between the > client and agent, and agreed not to do that. Which means that no, > agents do not delete state just because clients have disappeared. > > > On 11/24/15 11:01 AM, Andy Bierman wrote: > > > > On Tue, Nov 24, 2015 at 7:36 AM, Joel M. Halpern > > >> wrote: > > I believe that determining whether two independent and > internally > consistent sets of changes can, in combination, produce a > wedgie or > other failure is a research problem. > As far as I know, the I2RS working group concluded that it > was a > sufficiently hard problem that we did not expect the I2RS > agent to > get involved in trying to detect, much less remediate, such > cross-object inconsistencies. > > > > But the I2RS agent is responsible for identifying an edit > collision between > a new low-priority request and existing higher priority edits. > That sounds > involved to me. So the agent cannot possibly solve this problem > yet it is responsible for precisely that in order to implement > client > priority. > > The agent can see that /foo[42] exists in the request and > /foo[42] exists > in the ephemeral datastore, and call that a collision. > > However, if /foo[1] or /bar[19] are also part of the "edit", > such that > simply replacing > /foo[42] will break things, then the agent will not know. It > will simply > overwrite > /foo[42] and leave /foo[1] and /bar[19] in the datastore. > > So is the low-priority client responsible for removing /foo[1] > and /bar[19]? > Seems the answer is no. The client can go away and there are no > cleanup > requirements mentioned in the architecture. > > > > Yours, > Joel > > > > Andy > > > On 11/24/15 10:32 AM, PEDRO ANDRES ARANDA GUTIERREZ wrote: > > Hi Russ, > > I’m trying to identify the differences between > interactions with > routing protocols in I2RS and what is purely conflicts > between > clients. Currently I see too many issues overlapping > and I fear > that the trees are not letting us see the forest. > > So my take on routing protocols and wedgies might have > been too > compact :-) Let me give it a second try: Stepping > outside the > I2RS problem space, there is a lot of work that shows > that the > origin for BGP-4 instability is that our beloved route-maps > create metrics that are not monotonically increasing or > decreasing and that makes the routing protocols > meta-stable. > (BTW, I’m the first culprit when it comes to the use of > them, I > have created more than one wedgie :-P ) Acknowledging > that this > is a significant (and quite complex) problem for the > Internet in > general, I feel that it should be treated somewhere > else (GROW?). > > The perspective I would like to take here is: > - assume that we have two or more clients that produce > perfectly > sound routing information (no wedgies there) > - assume they talk to the same agent > - now my questions > 1.- is there any way to detect whether the > clients > produce contradicting/conflicting information? > 2.- is there any way to resolve these > contradictions/conflicts? > > BR, /PA > --- > Dr. Pedro A. Aranda Gutiérrez > > Technology Exploration - > Network Innovation & Virtualisation > email: pedroa d0t aranda At telefonica d0t com > Telefónica, Investigación y Desarrollo > C/ Zurbarán,12 > 28010 Madrid, Spain > > Fragen sind nicht da, um beantwortet zu werden. > Fragen sind da, um gestellt zu werden. > Georg Kreisler > > > > > > > > > -----Mensaje original----- > De: Russ White <7riw77@gmail.com > >> > Fecha: lunes, 23 de noviembre de 2015, 14:06 > Para: paag > >>, 'Jeffrey Haas' > > >> > CC: "i2rs@ietf.org > >" > >>, "'Joel > M. Halpern'" > > >>, 'Andy > Bierman' >>, Sue > Hares > >> > Asunto: RE: [i2rs] Conversation on Priority and Panes > > > Re the metric 'problem', just to be more > precise in what > would be needed, > we are looking a metric that grows or decreases > monotonically across the > whole network. > > > I assume you mean in the routing space, and not in the > controller/client space, correct? In terms of a > distributed > protocol? So, you're saying the delay could use > "metrics" > between 11 and 20, while the bandwidth could use > "metrics" > between 21 and 30, etc? And then you just add them all > together? That's what IS-IS has done for years... > Even BGP > really only has one "metric," with following "tie > breakers..." So if you have something like weight/local > pref/etc, such that they occupy different "spaces" > in a bit > pattern (something suggested, btw, in the original wide > community work, and in other places, as well), you're > actually just building a single metric. > > You've not "solved" the multiple metric problem -- > just done > something a little different than EIGRP's K values to > combine them into a single metric, which is where > you need > to be to have the ability to build a single stable > SPT/DAG. > > The theoretical grounds for this are in T. > Griffin’s and > Sobrinho’s work on BGP-4 and that lies already > a couple > of years ago and that > makes the analysis much ‘easier’ (no worries about > np(complete) problems, > etc.). This could be applied in I2RS at the routing > protocol level. So, we could > discuss where that sits (should be the clients, > right?) > and I don’t know if > that’s been already done, since I’m quite new > to this list. > > > This doesn’t apply to the problem at hand, > though... You > seem to be saying (clarify if wrong) -- > > 1. Give each client some set of bits out of a 128 > bit number > space (or larger, etc.) > 2. Each client can have different "metrics" within > their own > number space > 3. When a client attempts to add some ephemeral > state, they > use a metric within their "space" > 4. The agent can just use the straight number as a > relative > priority for each potential piece of state > > This doesn't do anything different than the current > concept > of priority between clients, only in the current > plan each > client only has one priority, rather than > multiples. I don't > see where this relates to the problem at hand. > > Now, having “solved” that part of the equation > :-) , the > part that interests me > more is the conflicting clients problem, > because this > could be generalised to > other problem spaces in the SDN area. I do > agree that > agents should be able > to catch offending state before installing it > and I’m > looking for ways to specify > a minimal set of features that need to be > supported at > protocol level. > > Anyone else interested? > > > This is precisely where the problem lies. And this > is where > you're going to hit the CAP theorem in full force. > There are > only a few choices -- > > 1. Make the database eventually consistent > 2. Shut down accessibility during changes > 3. ?? > > (1) is the idea of either having the agent call > back to all > the clients when state they installed is overwritten or > allowing the agent to locally store some state where it > already has the information in hand and install it > locally > -- the only real difference between these two > solutions is > the "balance of complexity versus speed..." The entire > discussion here is how much additional complexity > are we > actually adding by doing "panes of glass," which > are just > locally stored state which isn't currently > installed. I'm > arguing that there's minimal complexity added that > you're > not already going to have in the system to allow > the agent > to store information locally _if_ it chooses to. > Jeff is > arguing (I think) that the "panes of glass" concept > is a > coherent way of looking at this problem that will > help us > understand and manage the complexity in a way that > makes > sense. Joel is arguing (I think) that this sort of > solution > is out of the WG charter, and it's too complex. I > _think_ I > have the th > > r > ee general perspectives right, but I don't know if I really > have > so... :-) > > > (2) is the idea of locking the database while you're > changing it. This is explicitly outside the scope > of I2RS > entirely, given we're trying to design something that's > atomic/restful. There are a lot of techniques you > can use to > speed up locking -- row locking, sharding, etc. -- > but none > of these are interesting from the I2RS perspective. > > :-) > > Russ > > > ________________________________ > > Este mensaje y sus adjuntos se dirigen exclusivamente a su > destinatario, puede contener información privilegiada o > confidencial y es para uso exclusivo de la persona o > entidad de > destino. Si no es usted. el destinatario indicado, queda > notificado de que la lectura, utilización, divulgación > y/o copia > sin autorización puede estar prohibida en virtud de la > legislación vigente. Si ha recibido este mensaje por > error, le > rogamos que nos lo comunique inmediatamente por esta > misma vía y > proceda a su destrucción. > > The information contained in this transmission is > privileged and > confidential information intended only for the use of the > individual or entity named above. If the reader of this > message > is not the intended recipient, you are hereby notified > that any > dissemination, distribution or copying of this > communication is > strictly prohibited. If you have received this > transmission in > error, do not read it. Please immediately reply to the > sender > that you have received this communication in error and then > delete it. > > Esta mensagem e seus anexos se dirigem exclusivamente > ao seu > destinatário, pode conter informação privilegiada ou > confidencial e é para uso exclusivo da pessoa ou > entidade de > destino. Se não é vossa senhoria o destinatário > indicado, fica > notificado de que a leitura, utilização, divulgação > e/ou cópia > sem autorização pode estar proibida em virtude da > legislação > vigente. Se recebeu esta mensagem por erro, rogamos-lhe > que nos > o comunique imediatamente por esta mesma via e proceda > a sua > destruição > > > From nobody Tue Nov 24 09:01:46 2015 Return-Path: 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 CD1611B2DBD for ; Tue, 24 Nov 2015 09:01:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, SPF_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 IYFKqqXz5K1j for ; Tue, 24 Nov 2015 09:01:41 -0800 (PST) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (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 128931B2D99 for ; Tue, 24 Nov 2015 09:01:40 -0800 (PST) Received: by lfaz4 with SMTP id z4so29179674lfa.0 for ; Tue, 24 Nov 2015 09:01:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Sz6frGVvoQaA9WtiaxnRkbAKXdVCjT0EdoqGr9p8Vbg=; b=EjnE8oKr9PocwwhoikuYGzz94BuLJoPw1+mORS2SfrFDAPfFyPis/TrtA2bCMGHIwI qe5tNv7EsZ660z+15faxPASdcb4glq6owlj3gBqu7hoekVtw2rgfYaPakNYmygHtkmA0 vELL4Fwd84quFu5Tyil8x9Vm1O1G8oa7aJy6HcSQRfWqIaBVMKe8uPWyGppo65aWAhPu 4MEtN7r3qmRK7vv1g83O7W7jWoqVkP3TK5pZ/xn2o1iXVlPGn3UMMxK5qwJYSlHgaavy KlHupdo/htCDPm3EBKloZCHvO2oY7NmN0QaZkxNumL3eMIenXkZwG6FU3oxSSIo/SGpR 6RFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Sz6frGVvoQaA9WtiaxnRkbAKXdVCjT0EdoqGr9p8Vbg=; b=Ve10BaJRRIjDwHUpznOlhoVfkRxg3RKgkjAmYVJjhaAZdhU579gwhcGXxbYIcajXeE 0HZB5rGDiagh7ySm/75vkR+baAEdFz+z81puLjtwmpp7jp+S5TzV+DOTe6yjXx26n+tk bE0rUFFQtKGA51vNHOVmD01WKM4w0TAuchW2WJdt32RCWTEJlmIf8v/BiA7g4+jFXadc 4xbcfuwFMgeBgUNgY9kEAlTc1PzfvekVgi7c1rMBo/HUV3CXdlblN6cegKQLUHeEEY8V 4AHrwZ7Rp9eVjzyBH/xXahTJ6OspnJ6mVKoRmypYxAjG3rRsMZj2oKijaJzAucvXjDBJ JArA== X-Gm-Message-State: ALoCoQn1n2FRS46q3v8pBGaZobRkkhvkveGQQGHNSFLTZ9FROOr/zsBHF2C/iqA9V17KTxr2iwY9 MIME-Version: 1.0 X-Received: by 10.112.157.166 with SMTP id wn6mr13599922lbb.30.1448384498193; Tue, 24 Nov 2015 09:01:38 -0800 (PST) Received: by 10.112.144.36 with HTTP; Tue, 24 Nov 2015 09:01:37 -0800 (PST) In-Reply-To: <5654960C.7040203@joelhalpern.com> References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> <563A97AA.5020308@joelhalpern.com> <00f301d11761$61699130$243cb390$@gmail.com> <563AA59C.4060809@joelhalpern.com> <018101d11764$66b82e50$34288af0$@gmail.com> <20151119203509.GA22415@pfrc.org> <5B54713B-CDE6-4F65-BE79-91F5B9FF3850@telefonica.com> <008d01d12390$064987c0$12dc9740$@gmail.com> <99B64F3B-20A1-4D3C-A445-46D235EDB44D@telefonica.com> <014a01d12394$ec5ffa60$c51fef20$@gmail.com> <87361DB1-DC6F-4023-A807-4003B436B472@telefonica.com> <012501d125e7$62e457e0$28ad07a0$@gmail.com> <0EAC7123-CECA-4C34-B5E3-E89F0C8DBF94@telefonica.com> <56548418.6060603@joelhalpern.com> <56548CF8.8030900@joelhalpern.com> <5654960C.7040203@joelhalpern.com> Date: Tue, 24 Nov 2015 09:01:37 -0800 Message-ID: From: Andy Bierman To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=001a11c2641683726a05254c4b7d Archived-At: Cc: Jeffrey Haas , PEDRO ANDRES ARANDA GUTIERREZ , Susan Hares , Russ White <7riw77@gmail.com>, "i2rs@ietf.org" Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 17:01:46 -0000 --001a11c2641683726a05254c4b7d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Nov 24, 2015 at 8:53 AM, Joel M. Halpern wrote: > That is indeed a good question. > > As I understand the WG agreement, some validations of changes are to be > performed, but as little as possible. So an agent can reject a change fo= r > validation, but we hoped to keep it as simple as possible. > I am not sure that hop[e is achievable. > > One of the assumptions in making any ephemeral change is that if some > other changes can affect what a client has done, it is the clients > responsibility to subscribe to notifications about those other changes, a= nd > to undertake remedial actions if a problem is introduced. So if /foo[19] > and /bar[1] interact with /baz[7] (or /foo[42]) then it is the clients jo= b > to monitor /baz[7] (or /foo[42]). The agent can't sort that out. > As an example of an ugly case, suppose that /baz[7] has a value created b= y > some other I2RS client. The changes to /foo[19] and /bar[1] might depend > upon that value. When the other client removes its changes, the value > reverts to the config value. That reversion clearly must take place. Th= at > can potential create problems for /foo[19] and /bar[1]. It seems to me > that we have to leave it to the client to sort that out. > > This is not much different from clients colliding in persistent config. Operators can use NACM access control to protect one client or another. As you have said, these high level collisions are operational errors. Returning 'access-denied' is better than stomping on data and sorting it out later. > Yours, > Joel > Andy > > On 11/24/15 11:28 AM, Andy Bierman wrote: > >> >> >> On Tue, Nov 24, 2015 at 8:14 AM, Joel M. Halpern > > wrote: >> >> The agent is required to detect and report direct collisions. >> It is not required or expected to detect indirect collisions, which >> are the complex source of wedgies and other interesting behaviors. >> >> >> OK, punting the problem is fair enough. >> >> What happens when the YANG validation for /foo[19] and /bar[1] >> now fails because /foo[42] was changed? Does the agent reject >> the edit from the higher priority client? Does I2RS ignore YANG >> validation, >> assuming the YANG authors really didn't mean what they wrote? >> >> >> Yours, >> Joel >> >> >> >> Andy >> >> PS: The WG discussed requiring a maintained connection between the >> client and agent, and agreed not to do that. Which means that no, >> agents do not delete state just because clients have disappeared. >> >> >> On 11/24/15 11:01 AM, Andy Bierman wrote: >> >> >> >> On Tue, Nov 24, 2015 at 7:36 AM, Joel M. Halpern >> >> >> wrote= : >> >> I believe that determining whether two independent and >> internally >> consistent sets of changes can, in combination, produce a >> wedgie or >> other failure is a research problem. >> As far as I know, the I2RS working group concluded that it >> was a >> sufficiently hard problem that we did not expect the I2RS >> agent to >> get involved in trying to detect, much less remediate, such >> cross-object inconsistencies. >> >> >> >> But the I2RS agent is responsible for identifying an edit >> collision between >> a new low-priority request and existing higher priority edits. >> That sounds >> involved to me. So the agent cannot possibly solve this problem >> yet it is responsible for precisely that in order to implement >> client >> priority. >> >> The agent can see that /foo[42] exists in the request and >> /foo[42] exists >> in the ephemeral datastore, and call that a collision. >> >> However, if /foo[1] or /bar[19] are also part of the "edit", >> such that >> simply replacing >> /foo[42] will break things, then the agent will not know. It >> will simply >> overwrite >> /foo[42] and leave /foo[1] and /bar[19] in the datastore. >> >> So is the low-priority client responsible for removing /foo[1] >> and /bar[19]? >> Seems the answer is no. The client can go away and there are no >> cleanup >> requirements mentioned in the architecture. >> >> >> >> Yours, >> Joel >> >> >> >> Andy >> >> >> On 11/24/15 10:32 AM, PEDRO ANDRES ARANDA GUTIERREZ wrote: >> >> Hi Russ, >> >> I=E2=80=99m trying to identify the differences between >> interactions with >> routing protocols in I2RS and what is purely conflicts >> between >> clients. Currently I see too many issues overlapping >> and I fear >> that the trees are not letting us see the forest. >> >> So my take on routing protocols and wedgies might have >> been too >> compact :-) Let me give it a second try: Stepping >> outside the >> I2RS problem space, there is a lot of work that shows >> that the >> origin for BGP-4 instability is that our beloved >> route-maps >> create metrics that are not monotonically increasing or >> decreasing and that makes the routing protocols >> meta-stable. >> (BTW, I=E2=80=99m the first culprit when it comes to th= e use of >> them, I >> have created more than one wedgie :-P ) Acknowledging >> that this >> is a significant (and quite complex) problem for the >> Internet in >> general, I feel that it should be treated somewhere >> else (GROW?). >> >> The perspective I would like to take here is: >> - assume that we have two or more clients that produce >> perfectly >> sound routing information (no wedgies there) >> - assume they talk to the same agent >> - now my questions >> 1.- is there any way to detect whether the >> clients >> produce contradicting/conflicting information? >> 2.- is there any way to resolve these >> contradictions/conflicts? >> >> BR, /PA >> --- >> Dr. Pedro A. Aranda Guti=C3=A9rrez >> >> Technology Exploration - >> Network Innovation & Virtualisation >> email: pedroa d0t aranda At telefonica d0t com >> Telef=C3=B3nica, Investigaci=C3=B3n y Desarrollo >> C/ Zurbar=C3=A1n,12 >> 28010 Madrid, Spain >> >> Fragen sind nicht da, um beantwortet zu werden. >> Fragen sind da, um gestellt zu werden. >> Georg Kreisler >> >> >> >> >> >> >> >> >> -----Mensaje original----- >> De: Russ White <7riw77@gmail.com >> > >> >> Fecha: lunes, 23 de noviembre de 2015, 14:06 >> Para: paag > >> > >>, 'Jeffrey Haas' >> >> >> >> CC: "i2rs@ietf.org >> >" > >> >>, "'Joel >> M. Halpern'" >> >> >>, 'And= y >> Bierman' > > >>, Sue >> Hares >> >> >> Asunto: RE: [i2rs] Conversation on Priority and Panes >> >> >> Re the metric 'problem', just to be more >> precise in what >> would be needed, >> we are looking a metric that grows or decreases >> monotonically across the >> whole network. >> >> >> I assume you mean in the routing space, and not in >> the >> controller/client space, correct? In terms of a >> distributed >> protocol? So, you're saying the delay could use >> "metrics" >> between 11 and 20, while the bandwidth could use >> "metrics" >> between 21 and 30, etc? And then you just add them >> all >> together? That's what IS-IS has done for years... >> Even BGP >> really only has one "metric," with following "tie >> breakers..." So if you have something like >> weight/local >> pref/etc, such that they occupy different "spaces" >> in a bit >> pattern (something suggested, btw, in the original >> wide >> community work, and in other places, as well), you'= re >> actually just building a single metric. >> >> You've not "solved" the multiple metric problem -- >> just done >> something a little different than EIGRP's K values = to >> combine them into a single metric, which is where >> you need >> to be to have the ability to build a single stable >> SPT/DAG. >> >> The theoretical grounds for this are in T. >> Griffin=E2=80=99s and >> Sobrinho=E2=80=99s work on BGP-4 and that lies = already >> a couple >> of years ago and that >> makes the analysis much =E2=80=98easier=E2=80= =99 (no worries >> about >> np(complete) problems, >> etc.). This could be applied in I2RS at the >> routing >> protocol level. So, we could >> discuss where that sits (should be the clients, >> right?) >> and I don=E2=80=99t know if >> that=E2=80=99s been already done, since I=E2=80= =99m quite new >> to this list. >> >> >> This doesn=E2=80=99t apply to the problem at hand, >> though... You >> seem to be saying (clarify if wrong) -- >> >> 1. Give each client some set of bits out of a 128 >> bit number >> space (or larger, etc.) >> 2. Each client can have different "metrics" within >> their own >> number space >> 3. When a client attempts to add some ephemeral >> state, they >> use a metric within their "space" >> 4. The agent can just use the straight number as a >> relative >> priority for each potential piece of state >> >> This doesn't do anything different than the current >> concept >> of priority between clients, only in the current >> plan each >> client only has one priority, rather than >> multiples. I don't >> see where this relates to the problem at hand. >> >> Now, having =E2=80=9Csolved=E2=80=9D that part = of the equation >> :-) , the >> part that interests me >> more is the conflicting clients problem, >> because this >> could be generalised to >> other problem spaces in the SDN area. I do >> agree that >> agents should be able >> to catch offending state before installing it >> and I=E2=80=99m >> looking for ways to specify >> a minimal set of features that need to be >> supported at >> protocol level. >> >> Anyone else interested? >> >> >> This is precisely where the problem lies. And this >> is where >> you're going to hit the CAP theorem in full force. >> There are >> only a few choices -- >> >> 1. Make the database eventually consistent >> 2. Shut down accessibility during changes >> 3. ?? >> >> (1) is the idea of either having the agent call >> back to all >> the clients when state they installed is overwritte= n >> or >> allowing the agent to locally store some state wher= e >> it >> already has the information in hand and install it >> locally >> -- the only real difference between these two >> solutions is >> the "balance of complexity versus speed..." The >> entire >> discussion here is how much additional complexity >> are we >> actually adding by doing "panes of glass," which >> are just >> locally stored state which isn't currently >> installed. I'm >> arguing that there's minimal complexity added that >> you're >> not already going to have in the system to allow >> the agent >> to store information locally _if_ it chooses to. >> Jeff is >> arguing (I think) that the "panes of glass" concept >> is a >> coherent way of looking at this problem that will >> help us >> understand and manage the complexity in a way that >> makes >> sense. Joel is arguing (I think) that this sort of >> solution >> is out of the WG charter, and it's too complex. I >> _think_ I >> have the th >> >> r >> ee general perspectives right, but I don't know if I really >> have >> so... :-) >> >> >> (2) is the idea of locking the database while you'r= e >> changing it. This is explicitly outside the scope >> of I2RS >> entirely, given we're trying to design something >> that's >> atomic/restful. There are a lot of techniques you >> can use to >> speed up locking -- row locking, sharding, etc. -- >> but none >> of these are interesting from the I2RS perspective. >> >> :-) >> >> Russ >> >> >> ________________________________ >> >> Este mensaje y sus adjuntos se dirigen exclusivamente a >> su >> destinatario, puede contener informaci=C3=B3n privilegi= ada o >> confidencial y es para uso exclusivo de la persona o >> entidad de >> destino. Si no es usted. el destinatario indicado, qued= a >> notificado de que la lectura, utilizaci=C3=B3n, divulga= ci=C3=B3n >> y/o copia >> sin autorizaci=C3=B3n puede estar prohibida en virtud d= e la >> legislaci=C3=B3n vigente. Si ha recibido este mensaje p= or >> error, le >> rogamos que nos lo comunique inmediatamente por esta >> misma v=C3=ADa y >> proceda a su destrucci=C3=B3n. >> >> The information contained in this transmission is >> privileged and >> confidential information intended only for the use of t= he >> individual or entity named above. If the reader of this >> message >> is not the intended recipient, you are hereby notified >> that any >> dissemination, distribution or copying of this >> communication is >> strictly prohibited. If you have received this >> transmission in >> error, do not read it. Please immediately reply to the >> sender >> that you have received this communication in error and >> then >> delete it. >> >> Esta mensagem e seus anexos se dirigem exclusivamente >> ao seu >> destinat=C3=A1rio, pode conter informa=C3=A7=C3=A3o pri= vilegiada ou >> confidencial e =C3=A9 para uso exclusivo da pessoa ou >> entidade de >> destino. Se n=C3=A3o =C3=A9 vossa senhoria o destinat= =C3=A1rio >> indicado, fica >> notificado de que a leitura, utiliza=C3=A7=C3=A3o, divu= lga=C3=A7=C3=A3o >> e/ou c=C3=B3pia >> sem autoriza=C3=A7=C3=A3o pode estar proibida em virtud= e da >> legisla=C3=A7=C3=A3o >> vigente. Se recebeu esta mensagem por erro, rogamos-lhe >> que nos >> o comunique imediatamente por esta mesma via e proceda >> a sua >> destrui=C3=A7=C3=A3o >> >> >> >> --001a11c2641683726a05254c4b7d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+PGRpdiBjbGFz cz0iZ21haWxfcXVvdGUiPk9uIFR1ZSwgTm92IDI0LCAyMDE1IGF0IDg6NTMgQU0sIEpvZWwgTS4g SGFscGVybiA8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBl cm4uY29tIiB0YXJnZXQ9Il9ibGFuayI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7PC9zcGFu PiB3cm90ZTo8YnI+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2lu OjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+ VGhhdCBpcyBpbmRlZWQgYSBnb29kIHF1ZXN0aW9uLjxicj4NCjxicj4NCkFzIEkgdW5kZXJzdGFu ZCB0aGUgV0cgYWdyZWVtZW50LCBzb21lIHZhbGlkYXRpb25zIG9mIGNoYW5nZXMgYXJlIHRvIGJl IHBlcmZvcm1lZCwgYnV0IGFzIGxpdHRsZSBhcyBwb3NzaWJsZS7CoCBTbyBhbiBhZ2VudCBjYW4g cmVqZWN0IGEgY2hhbmdlIGZvciB2YWxpZGF0aW9uLCBidXQgd2UgaG9wZWQgdG8ga2VlcCBpdCBh cyBzaW1wbGUgYXMgcG9zc2libGUuPGJyPg0KSSBhbSBub3Qgc3VyZSB0aGF0IGhvcFtlIGlzIGFj aGlldmFibGUuPGJyPg0KPGJyPg0KT25lIG9mIHRoZSBhc3N1bXB0aW9ucyBpbiBtYWtpbmcgYW55 IGVwaGVtZXJhbCBjaGFuZ2UgaXMgdGhhdCBpZiBzb21lIG90aGVyIGNoYW5nZXMgY2FuIGFmZmVj dCB3aGF0IGEgY2xpZW50IGhhcyBkb25lLCBpdCBpcyB0aGUgY2xpZW50cyByZXNwb25zaWJpbGl0 eSB0byBzdWJzY3JpYmUgdG8gbm90aWZpY2F0aW9ucyBhYm91dCB0aG9zZSBvdGhlciBjaGFuZ2Vz LCBhbmQgdG8gdW5kZXJ0YWtlIHJlbWVkaWFsIGFjdGlvbnMgaWYgYSBwcm9ibGVtIGlzIGludHJv ZHVjZWQuwqAgU28gaWYgL2Zvb1sxOV0gYW5kIC9iYXJbMV0gaW50ZXJhY3Qgd2l0aCAvYmF6Wzdd IChvciAvZm9vWzQyXSkgdGhlbiBpdCBpcyB0aGUgY2xpZW50cyBqb2IgdG8gbW9uaXRvciAvYmF6 WzddIChvciAvZm9vWzQyXSkuwqAgVGhlIGFnZW50IGNhbiYjMzk7dCBzb3J0IHRoYXQgb3V0Ljxi cj4NCkFzIGFuIGV4YW1wbGUgb2YgYW4gdWdseSBjYXNlLCBzdXBwb3NlIHRoYXQgL2Jhels3XSBo YXMgYSB2YWx1ZSBjcmVhdGVkIGJ5IHNvbWUgb3RoZXIgSTJSUyBjbGllbnQuwqAgVGhlIGNoYW5n ZXMgdG8gL2Zvb1sxOV0gYW5kIC9iYXJbMV0gbWlnaHQgZGVwZW5kIHVwb24gdGhhdCB2YWx1ZS7C oCBXaGVuIHRoZSBvdGhlciBjbGllbnQgcmVtb3ZlcyBpdHMgY2hhbmdlcywgdGhlIHZhbHVlIHJl dmVydHMgdG8gdGhlIGNvbmZpZyB2YWx1ZS7CoCBUaGF0IHJldmVyc2lvbiBjbGVhcmx5IG11c3Qg dGFrZSBwbGFjZS7CoCBUaGF0IGNhbiBwb3RlbnRpYWwgY3JlYXRlIHByb2JsZW1zIGZvciAvZm9v WzE5XSBhbmQgL2JhclsxXS7CoCBJdCBzZWVtcyB0byBtZSB0aGF0IHdlIGhhdmUgdG8gbGVhdmUg aXQgdG8gdGhlIGNsaWVudCB0byBzb3J0IHRoYXQgb3V0Ljxicj4NCjxicj48L2Jsb2NrcXVvdGU+ PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5UaGlzIGlzIG5vdCBtdWNoIGRpZmZl cmVudCBmcm9tIGNsaWVudHMgY29sbGlkaW5nIGluIHBlcnNpc3RlbnQgY29uZmlnLjwvZGl2Pjxk aXY+T3BlcmF0b3JzIGNhbiB1c2UgTkFDTSBhY2Nlc3MgY29udHJvbCB0byBwcm90ZWN0IG9uZSBj bGllbnQgb3IgYW5vdGhlci48L2Rpdj48ZGl2PkFzIHlvdSBoYXZlIHNhaWQsIHRoZXNlIGhpZ2gg bGV2ZWwgY29sbGlzaW9ucyBhcmUgb3BlcmF0aW9uYWwgZXJyb3JzLjwvZGl2PjxkaXY+UmV0dXJu aW5nICYjMzk7YWNjZXNzLWRlbmllZCYjMzk7IGlzIGJldHRlciB0aGFuIHN0b21waW5nIG9uIGRh dGEgYW5kIHNvcnRpbmcgaXQgb3V0IGxhdGVyLjwvZGl2PjxkaXY+wqA8YnI+PC9kaXY+PGJsb2Nr cXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVy LWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQpZb3Vycyw8YnI+DQpKb2Vs PGJyPjwvYmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj48ZGl2PkFuZHk8L2Rpdj48ZGl2PsKgPC9k aXY+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44 ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8YnI+DQpP biAxMS8yNC8xNSAxMToyOCBBTSwgQW5keSBCaWVybWFuIHdyb3RlOjxicj4NCjxibG9ja3F1b3Rl IGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0 OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGJyPg0KPGJyPg0KT24gVHVlLCBO b3YgMjQsIDIwMTUgYXQgODoxNCBBTSwgSm9lbCBNLiBIYWxwZXJuICZsdDs8YSBocmVmPSJtYWls dG86am1oQGpvZWxoYWxwZXJuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmptaEBqb2VsaGFscGVybi5j b208L2E+PGJyPg0KJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmptaEBqb2VsaGFscGVybi5jb208L2E+Jmd0OyZndDsgd3JvdGU6 PGJyPg0KPGJyPg0KwqAgwqAgVGhlIGFnZW50IGlzIHJlcXVpcmVkIHRvIGRldGVjdCBhbmQgcmVw b3J0IGRpcmVjdCBjb2xsaXNpb25zLjxicj4NCsKgIMKgIEl0IGlzIG5vdCByZXF1aXJlZCBvciBl eHBlY3RlZCB0byBkZXRlY3QgaW5kaXJlY3QgY29sbGlzaW9ucywgd2hpY2g8YnI+DQrCoCDCoCBh cmUgdGhlIGNvbXBsZXggc291cmNlIG9mIHdlZGdpZXMgYW5kIG90aGVyIGludGVyZXN0aW5nIGJl aGF2aW9ycy48YnI+DQo8YnI+DQo8YnI+DQpPSywgcHVudGluZyB0aGUgcHJvYmxlbSBpcyBmYWly IGVub3VnaC48YnI+DQo8YnI+DQpXaGF0IGhhcHBlbnMgd2hlbiB0aGUgWUFORyB2YWxpZGF0aW9u IGZvciAvZm9vWzE5XSBhbmQgL2JhclsxXTxicj4NCm5vdyBmYWlscyBiZWNhdXNlIC9mb29bNDJd IHdhcyBjaGFuZ2VkP8KgIERvZXMgdGhlIGFnZW50IHJlamVjdDxicj4NCnRoZSBlZGl0IGZyb20g dGhlIGhpZ2hlciBwcmlvcml0eSBjbGllbnQ/wqAgRG9lcyBJMlJTIGlnbm9yZSBZQU5HIHZhbGlk YXRpb24sPGJyPg0KYXNzdW1pbmcgdGhlIFlBTkcgYXV0aG9ycyByZWFsbHkgZGlkbiYjMzk7dCBt ZWFuIHdoYXQgdGhleSB3cm90ZT88YnI+DQo8YnI+DQo8YnI+DQrCoCDCoCBZb3Vycyw8YnI+DQrC oCDCoCBKb2VsPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KQW5keTxicj4NCjxicj4NCsKgIMKgIFBT OiBUaGUgV0cgZGlzY3Vzc2VkIHJlcXVpcmluZyBhIG1haW50YWluZWQgY29ubmVjdGlvbiBiZXR3 ZWVuIHRoZTxicj4NCsKgIMKgIGNsaWVudCBhbmQgYWdlbnQsIGFuZCBhZ3JlZWQgbm90IHRvIGRv IHRoYXQuwqAgV2hpY2ggbWVhbnMgdGhhdCBubyw8YnI+DQrCoCDCoCBhZ2VudHMgZG8gbm90IGRl bGV0ZSBzdGF0ZSBqdXN0IGJlY2F1c2UgY2xpZW50cyBoYXZlIGRpc2FwcGVhcmVkLjxicj4NCjxi cj4NCjxicj4NCsKgIMKgIE9uIDExLzI0LzE1IDExOjAxIEFNLCBBbmR5IEJpZXJtYW4gd3JvdGU6 PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgT24gVHVlLCBOb3YgMjQsIDIwMTUg YXQgNzozNiBBTSwgSm9lbCBNLiBIYWxwZXJuPGJyPg0KwqAgwqAgwqAgwqAgJmx0OzxhIGhyZWY9 Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIiB0YXJnZXQ9Il9ibGFuayI+am1oQGpvZWxoYWxw ZXJuLmNvbTwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmptaEBqb2VsaGFscGVybi5jb208L2E+Jmd0Ozxicj4NCsKgIMKg IMKgIMKgICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iIHRh cmdldD0iX2JsYW5rIj5qbWhAam9lbGhhbHBlcm4uY29tPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9 Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIiB0YXJnZXQ9Il9ibGFuayI+am1oQGpvZWxoYWxw ZXJuLmNvbTwvYT4mZ3Q7Jmd0OyZndDsgd3JvdGU6PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqBJIGJlbGlldmUgdGhhdCBkZXRlcm1pbmluZyB3aGV0aGVyIHR3byBpbmRlcGVuZGVudCBh bmQ8YnI+DQrCoCDCoCDCoCDCoCBpbnRlcm5hbGx5PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqBj b25zaXN0ZW50IHNldHMgb2YgY2hhbmdlcyBjYW4sIGluIGNvbWJpbmF0aW9uLCBwcm9kdWNlIGE8 YnI+DQrCoCDCoCDCoCDCoCB3ZWRnaWUgb3I8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoG90aGVy IGZhaWx1cmUgaXMgYSByZXNlYXJjaCBwcm9ibGVtLjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg QXMgZmFyIGFzIEkga25vdywgdGhlIEkyUlMgd29ya2luZyBncm91cCBjb25jbHVkZWQgdGhhdCBp dDxicj4NCsKgIMKgIMKgIMKgIHdhcyBhPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqBzdWZmaWNp ZW50bHkgaGFyZCBwcm9ibGVtIHRoYXQgd2UgZGlkIG5vdCBleHBlY3QgdGhlIEkyUlM8YnI+DQrC oCDCoCDCoCDCoCBhZ2VudCB0bzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgZ2V0IGludm9sdmVk IGluIHRyeWluZyB0byBkZXRlY3QsIG11Y2ggbGVzcyByZW1lZGlhdGUsIHN1Y2g8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoGNyb3NzLW9iamVjdCBpbmNvbnNpc3RlbmNpZXMuPGJyPg0KPGJyPg0K PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgQnV0IHRoZSBJMlJTIGFnZW50IGlzIHJlc3BvbnNpYmxl IGZvciBpZGVudGlmeWluZyBhbiBlZGl0PGJyPg0KwqAgwqAgwqAgwqAgY29sbGlzaW9uIGJldHdl ZW48YnI+DQrCoCDCoCDCoCDCoCBhIG5ldyBsb3ctcHJpb3JpdHkgcmVxdWVzdCBhbmQgZXhpc3Rp bmcgaGlnaGVyIHByaW9yaXR5IGVkaXRzLjxicj4NCsKgIMKgIMKgIMKgIFRoYXQgc291bmRzPGJy Pg0KwqAgwqAgwqAgwqAgaW52b2x2ZWQgdG8gbWUuwqAgU28gdGhlIGFnZW50IGNhbm5vdCBwb3Nz aWJseSBzb2x2ZSB0aGlzIHByb2JsZW08YnI+DQrCoCDCoCDCoCDCoCB5ZXQgaXQgaXMgcmVzcG9u c2libGUgZm9yIHByZWNpc2VseSB0aGF0IGluIG9yZGVyIHRvIGltcGxlbWVudDxicj4NCsKgIMKg IMKgIMKgIGNsaWVudDxicj4NCsKgIMKgIMKgIMKgIHByaW9yaXR5Ljxicj4NCjxicj4NCsKgIMKg IMKgIMKgIFRoZSBhZ2VudCBjYW4gc2VlIHRoYXQgL2Zvb1s0Ml0gZXhpc3RzIGluIHRoZSByZXF1 ZXN0IGFuZDxicj4NCsKgIMKgIMKgIMKgIC9mb29bNDJdIGV4aXN0czxicj4NCsKgIMKgIMKgIMKg IGluIHRoZSBlcGhlbWVyYWwgZGF0YXN0b3JlLCBhbmQgY2FsbCB0aGF0IGEgY29sbGlzaW9uLjxi cj4NCjxicj4NCsKgIMKgIMKgIMKgIEhvd2V2ZXIsIGlmIC9mb29bMV0gb3IgL2JhclsxOV0gYXJl IGFsc28gcGFydCBvZiB0aGUgJnF1b3Q7ZWRpdCZxdW90Oyw8YnI+DQrCoCDCoCDCoCDCoCBzdWNo IHRoYXQ8YnI+DQrCoCDCoCDCoCDCoCBzaW1wbHkgcmVwbGFjaW5nPGJyPg0KwqAgwqAgwqAgwqAg L2Zvb1s0Ml0gd2lsbCBicmVhayB0aGluZ3MsIHRoZW4gdGhlIGFnZW50IHdpbGwgbm90IGtub3cu IEl0PGJyPg0KwqAgwqAgwqAgwqAgd2lsbCBzaW1wbHk8YnI+DQrCoCDCoCDCoCDCoCBvdmVyd3Jp dGU8YnI+DQrCoCDCoCDCoCDCoCAvZm9vWzQyXSBhbmQgbGVhdmUgL2Zvb1sxXSBhbmQgL2Jhclsx OV0gaW4gdGhlIGRhdGFzdG9yZS48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCBTbyBpcyB0aGUgbG93 LXByaW9yaXR5IGNsaWVudCByZXNwb25zaWJsZSBmb3IgcmVtb3ZpbmcgL2Zvb1sxXTxicj4NCsKg IMKgIMKgIMKgIGFuZCAvYmFyWzE5XT88YnI+DQrCoCDCoCDCoCDCoCBTZWVtcyB0aGUgYW5zd2Vy IGlzIG5vLiBUaGUgY2xpZW50IGNhbiBnbyBhd2F5IGFuZCB0aGVyZSBhcmUgbm88YnI+DQrCoCDC oCDCoCDCoCBjbGVhbnVwPGJyPg0KwqAgwqAgwqAgwqAgcmVxdWlyZW1lbnRzIG1lbnRpb25lZCBp biB0aGUgYXJjaGl0ZWN0dXJlLjxicj4NCjxicj4NCjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgWW91cnMsPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqBKb2VsPGJyPg0KPGJyPg0KPGJy Pg0KPGJyPg0KwqAgwqAgwqAgwqAgQW5keTxicj4NCjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgT24gMTEvMjQvMTUgMTA6MzIgQU0sIFBFRFJPIEFORFJFUyBBUkFOREEgR1VUSUVSUkVa IHdyb3RlOjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgSGkgUnVzcyw8YnI+ DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoEnigJltIHRyeWluZyB0byBpZGVudGlm eSB0aGUgZGlmZmVyZW5jZXMgYmV0d2Vlbjxicj4NCsKgIMKgIMKgIMKgIGludGVyYWN0aW9ucyB3 aXRoPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqByb3V0aW5nIHByb3RvY29scyBpbiBJ MlJTIGFuZCB3aGF0IGlzIHB1cmVseSBjb25mbGljdHM8YnI+DQrCoCDCoCDCoCDCoCBiZXR3ZWVu PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBjbGllbnRzLiBDdXJyZW50bHkgSSBzZWUg dG9vIG1hbnkgaXNzdWVzIG92ZXJsYXBwaW5nPGJyPg0KwqAgwqAgwqAgwqAgYW5kIEkgZmVhcjxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgdGhhdCB0aGUgdHJlZXMgYXJlIG5vdCBsZXR0 aW5nIHVzIHNlZSB0aGUgZm9yZXN0Ljxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgU28gbXkgdGFrZSBvbiByb3V0aW5nIHByb3RvY29scyBhbmQgd2VkZ2llcyBtaWdodCBoYXZl PGJyPg0KwqAgwqAgwqAgwqAgYmVlbiB0b288YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oGNvbXBhY3QgOi0pIExldCBtZSBnaXZlIGl0IGEgc2Vjb25kIHRyeTogU3RlcHBpbmc8YnI+DQrC oCDCoCDCoCDCoCBvdXRzaWRlIHRoZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgSTJS UyBwcm9ibGVtIHNwYWNlLCB0aGVyZSBpcyBhIGxvdCBvZiB3b3JrIHRoYXQgc2hvd3M8YnI+DQrC oCDCoCDCoCDCoCB0aGF0IHRoZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgb3JpZ2lu IGZvciBCR1AtNCBpbnN0YWJpbGl0eSBpcyB0aGF0IG91ciBiZWxvdmVkIHJvdXRlLW1hcHM8YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGNyZWF0ZSBtZXRyaWNzIHRoYXQgYXJlIG5vdCBt b25vdG9uaWNhbGx5IGluY3JlYXNpbmcgb3I8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oGRlY3JlYXNpbmcgYW5kIHRoYXQgbWFrZXMgdGhlIHJvdXRpbmcgcHJvdG9jb2xzPGJyPg0KwqAg wqAgwqAgwqAgbWV0YS1zdGFibGUuPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAoQlRX LCBJ4oCZbSB0aGUgZmlyc3QgY3VscHJpdCB3aGVuIGl0IGNvbWVzIHRvIHRoZSB1c2Ugb2Y8YnI+ DQrCoCDCoCDCoCDCoCB0aGVtLCBJPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBoYXZl IGNyZWF0ZWQgbW9yZSB0aGFuIG9uZSB3ZWRnaWUgOi1QICkgQWNrbm93bGVkZ2luZzxicj4NCsKg IMKgIMKgIMKgIHRoYXQgdGhpczxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgaXMgYSBz aWduaWZpY2FudCAoYW5kIHF1aXRlIGNvbXBsZXgpIHByb2JsZW0gZm9yIHRoZTxicj4NCsKgIMKg IMKgIMKgIEludGVybmV0IGluPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBnZW5lcmFs LCBJIGZlZWwgdGhhdCBpdCBzaG91bGQgYmUgdHJlYXRlZCBzb21ld2hlcmU8YnI+DQrCoCDCoCDC oCDCoCBlbHNlIChHUk9XPykuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBU aGUgcGVyc3BlY3RpdmUgSSB3b3VsZCBsaWtlIHRvIHRha2UgaGVyZSBpczo8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoC0gYXNzdW1lIHRoYXQgd2UgaGF2ZSB0d28gb3IgbW9yZSBjbGll bnRzIHRoYXQgcHJvZHVjZTxicj4NCsKgIMKgIMKgIMKgIHBlcmZlY3RseTxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgc291bmQgcm91dGluZyBpbmZvcm1hdGlvbiAobm8gd2VkZ2llcyB0 aGVyZSk8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoC0gYXNzdW1lIHRoZXkgdGFsayB0 byB0aGUgc2FtZSBhZ2VudDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgLSBub3cgbXkg cXVlc3Rpb25zPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAx Li0gaXMgdGhlcmUgYW55IHdheSB0byBkZXRlY3Qgd2hldGhlciB0aGU8YnI+DQrCoCDCoCDCoCDC oCBjbGllbnRzPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBwcm9kdWNlIGNvbnRyYWRp Y3RpbmcvY29uZmxpY3RpbmcgaW5mb3JtYXRpb24/PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAyLi0gaXMgdGhlcmUgYW55IHdheSB0byByZXNvbHZlIHRoZXNl PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBjb250cmFkaWN0aW9ucy9jb25mbGljdHM/ PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBCUiwgL1BBPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAtLS08YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoERy LiBQZWRybyBBLiBBcmFuZGEgR3V0acOpcnJlejxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgVGVjaG5vbG9neSBFeHBsb3JhdGlvbiAtPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqBOZXR3b3JrIElubm92YXRpb24gJmFtcDsgVmlydHVhbGlzYXRpb248YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoGVtYWlsOiBwZWRyb2EgZDB0IGFyYW5kYSBBdCB0ZWxlZm9u aWNhIGQwdCBjb208YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoFRlbGVmw7NuaWNhLCBJ bnZlc3RpZ2FjacOzbiB5IERlc2Fycm9sbG88YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oEMvIFp1cmJhcsOhbiwxMjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgMjgwMTAgTWFk cmlkLCBTcGFpbjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgRnJhZ2VuIHNp bmQgbmljaHQgZGEsIHVtIGJlYW50d29ydGV0IHp1IHdlcmRlbi48YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoEZyYWdlbiBzaW5kIGRhLCB1bSBnZXN0ZWxsdCB6dSB3ZXJkZW4uPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBHZW9yZyBLcmVpc2xlcjxicj4NCjxicj4NCjxicj4N Cjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgLS0tLS1NZW5zYWplIG9yaWdpbmFsLS0tLS08YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoERlOiBSdXNzIFdoaXRlICZsdDs8YSBocmVmPSJtYWlsdG86N3Jpdzc3QGdtYWlsLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPjdyaXc3N0BnbWFpbC5jb208L2E+PGJyPg0KwqAgwqAgwqAgwqAg Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86N3Jpdzc3QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPjdyaXc3N0BnbWFpbC5jb208L2E+Jmd0OyAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzo3 cml3NzdAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+N3Jpdzc3QGdtYWlsLmNvbTwvYT48YnI+ DQrCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzo3cml3NzdAZ21haWwuY29t IiB0YXJnZXQ9Il9ibGFuayI+N3Jpdzc3QGdtYWlsLmNvbTwvYT4mZ3Q7Jmd0OyZndDs8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoEZlY2hhOiBsdW5lcywgMjMgZGUgbm92aWVtYnJlIGRl IDIwMTUsIDE0OjA2PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBQYXJhOiBwYWFnICZs dDs8YSBocmVmPSJtYWlsdG86cGVkcm9hLmFyYW5kYUB0ZWxlZm9uaWNhLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPnBlZHJvYS5hcmFuZGFAdGVsZWZvbmljYS5jb208L2E+PGJyPg0KwqAgwqAgwqAgwqAg Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86cGVkcm9hLmFyYW5kYUB0ZWxlZm9uaWNhLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPnBlZHJvYS5hcmFuZGFAdGVsZWZvbmljYS5jb208L2E+Jmd0Ozxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86cGVk cm9hLmFyYW5kYUB0ZWxlZm9uaWNhLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBlZHJvYS5hcmFuZGFA dGVsZWZvbmljYS5jb208L2E+PGJyPg0KwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJt YWlsdG86cGVkcm9hLmFyYW5kYUB0ZWxlZm9uaWNhLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBlZHJv YS5hcmFuZGFAdGVsZWZvbmljYS5jb208L2E+Jmd0OyZndDsmZ3Q7LCAmIzM5O0plZmZyZXkgSGFh cyYjMzk7PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAmbHQ7PGEgaHJlZj0ibWFpbHRv OmpoYWFzQHBmcmMub3JnIiB0YXJnZXQ9Il9ibGFuayI+amhhYXNAcGZyYy5vcmc8L2E+ICZsdDtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOmpoYWFzQHBmcmMub3JnIiB0YXJnZXQ9Il9ibGFuayI+amhh YXNAcGZyYy5vcmc8L2E+Jmd0Ozxicj4NCsKgIMKgIMKgIMKgICZsdDttYWlsdG86PGEgaHJlZj0i bWFpbHRvOmpoYWFzQHBmcmMub3JnIiB0YXJnZXQ9Il9ibGFuayI+amhhYXNAcGZyYy5vcmc8L2E+ ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmpoYWFzQHBmcmMub3JnIiB0YXJnZXQ9Il9ibGFu ayI+amhhYXNAcGZyYy5vcmc8L2E+Jmd0OyZndDsmZ3Q7PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqBDQzogJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmkycnNAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5pMnJzQGlldGYub3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzppMnJz QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aTJyc0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KwqAg wqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86aTJyc0BpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPmkycnNAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmky cnNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pMnJzQGlldGYub3JnPC9hPiZndDsmZ3Q7JnF1 b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86aTJyc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmky cnNAaWV0Zi5vcmc8L2E+PGJyPg0KwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWls dG86aTJyc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmkycnNAaWV0Zi5vcmc8L2E+Jmd0Ozxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86 aTJyc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmkycnNAaWV0Zi5vcmc8L2E+ICZsdDttYWls dG86PGEgaHJlZj0ibWFpbHRvOmkycnNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pMnJzQGll dGYub3JnPC9hPiZndDsmZ3Q7Jmd0OywgJnF1b3Q7JiMzOTtKb2VsPGJyPg0KwqAgwqAgwqAgwqAg TS4gSGFscGVybiYjMzk7JnF1b3Q7PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iIHRhcmdldD0iX2JsYW5rIj5qbWhA am9lbGhhbHBlcm4uY29tPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhh bHBlcm4uY29tIiB0YXJnZXQ9Il9ibGFuayI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7PGJy Pg0KwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJu LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmptaEBqb2VsaGFscGVybi5jb208L2E+ICZsdDttYWlsdG86 PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iIHRhcmdldD0iX2JsYW5rIj5qbWhA am9lbGhhbHBlcm4uY29tPC9hPiZndDsmZ3Q7Jmd0OywgJiMzOTtBbmR5PGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqBCaWVybWFuJiMzOTsgJmx0OzxhIGhyZWY9Im1haWx0bzphbmR5QHl1 bWF3b3Jrcy5jb20iIHRhcmdldD0iX2JsYW5rIj5hbmR5QHl1bWF3b3Jrcy5jb208L2E+PGJyPg0K wqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86YW5keUB5dW1hd29ya3MuY29t IiB0YXJnZXQ9Il9ibGFuayI+YW5keUB5dW1hd29ya3MuY29tPC9hPiZndDsgJmx0O21haWx0bzo8 YSBocmVmPSJtYWlsdG86YW5keUB5dW1hd29ya3MuY29tIiB0YXJnZXQ9Il9ibGFuayI+YW5keUB5 dW1hd29ya3MuY29tPC9hPjxicj4NCsKgIMKgIMKgIMKgICZsdDttYWlsdG86PGEgaHJlZj0ibWFp bHRvOmFuZHlAeXVtYXdvcmtzLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFuZHlAeXVtYXdvcmtzLmNv bTwvYT4mZ3Q7Jmd0OyZndDssIFN1ZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgSGFy ZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpzaGFyZXNAbmR6aC5jb20iIHRhcmdldD0iX2JsYW5rIj5z aGFyZXNAbmR6aC5jb208L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnNoYXJlc0BuZHpo LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNoYXJlc0BuZHpoLmNvbTwvYT4mZ3Q7PGJyPg0KwqAgwqAg wqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86c2hhcmVzQG5kemguY29tIiB0YXJnZXQ9 Il9ibGFuayI+c2hhcmVzQG5kemguY29tPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpz aGFyZXNAbmR6aC5jb20iIHRhcmdldD0iX2JsYW5rIj5zaGFyZXNAbmR6aC5jb208L2E+Jmd0OyZn dDsmZ3Q7PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBBc3VudG86IFJFOiBbaTJyc10g Q29udmVyc2F0aW9uIG9uIFByaW9yaXR5IGFuZCBQYW5lczxicj4NCjxicj4NCjxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgUmUgdGhlIG1ldHJpYyAmIzM5O3Byb2Js ZW0mIzM5OywganVzdCB0byBiZSBtb3JlPGJyPg0KwqAgwqAgwqAgwqAgcHJlY2lzZSBpbiB3aGF0 PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB3b3VsZCBiZSBuZWVk ZWQsPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB3ZSBhcmUgbG9v a2luZyBhIG1ldHJpYyB0aGF0IGdyb3dzIG9yIGRlY3JlYXNlczxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgbW9ub3RvbmljYWxseSBhY3Jvc3MgdGhlPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB3aG9sZSBuZXR3b3JrLjxicj4NCjxi cj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgSSBhc3N1bWUgeW91IG1l YW4gaW4gdGhlIHJvdXRpbmcgc3BhY2UsIGFuZCBub3QgaW4gdGhlPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqBjb250cm9sbGVyL2NsaWVudCBzcGFjZSwgY29ycmVjdD8gSW4g dGVybXMgb2YgYTxicj4NCsKgIMKgIMKgIMKgIGRpc3RyaWJ1dGVkPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqBwcm90b2NvbD8gU28sIHlvdSYjMzk7cmUgc2F5aW5nIHRoZSBk ZWxheSBjb3VsZCB1c2U8YnI+DQrCoCDCoCDCoCDCoCAmcXVvdDttZXRyaWNzJnF1b3Q7PGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBiZXR3ZWVuIDExIGFuZCAyMCwgd2hpbGUg dGhlIGJhbmR3aWR0aCBjb3VsZCB1c2U8YnI+DQrCoCDCoCDCoCDCoCAmcXVvdDttZXRyaWNzJnF1 b3Q7PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBiZXR3ZWVuIDIxIGFuZCAz MCwgZXRjPyBBbmQgdGhlbiB5b3UganVzdCBhZGQgdGhlbSBhbGw8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoHRvZ2V0aGVyPyBUaGF0JiMzOTtzIHdoYXQgSVMtSVMgaGFzIGRv bmUgZm9yIHllYXJzLi4uPGJyPg0KwqAgwqAgwqAgwqAgRXZlbiBCR1A8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoHJlYWxseSBvbmx5IGhhcyBvbmUgJnF1b3Q7bWV0cmljLCZx dW90OyB3aXRoIGZvbGxvd2luZyAmcXVvdDt0aWU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoGJyZWFrZXJzLi4uJnF1b3Q7IFNvIGlmIHlvdSBoYXZlIHNvbWV0aGluZyBsaWtl IHdlaWdodC9sb2NhbDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgcHJlZi9l dGMsIHN1Y2ggdGhhdCB0aGV5IG9jY3VweSBkaWZmZXJlbnQgJnF1b3Q7c3BhY2VzJnF1b3Q7PGJy Pg0KwqAgwqAgwqAgwqAgaW4gYSBiaXQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoHBhdHRlcm4gKHNvbWV0aGluZyBzdWdnZXN0ZWQsIGJ0dywgaW4gdGhlIG9yaWdpbmFsIHdp ZGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGNvbW11bml0eSB3b3JrLCBh bmQgaW4gb3RoZXIgcGxhY2VzLCBhcyB3ZWxsKSwgeW91JiMzOTtyZTxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgYWN0dWFsbHkganVzdCBidWlsZGluZyBhIHNpbmdsZSBtZXRy aWMuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBZb3UmIzM5O3Zl IG5vdCAmcXVvdDtzb2x2ZWQmcXVvdDsgdGhlIG11bHRpcGxlIG1ldHJpYyBwcm9ibGVtIC0tPGJy Pg0KwqAgwqAgwqAgwqAganVzdCBkb25lPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqBzb21ldGhpbmcgYSBsaXR0bGUgZGlmZmVyZW50IHRoYW4gRUlHUlAmIzM5O3MgSyB2YWx1 ZXMgdG88YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGNvbWJpbmUgdGhlbSBp bnRvIGEgc2luZ2xlIG1ldHJpYywgd2hpY2ggaXMgd2hlcmU8YnI+DQrCoCDCoCDCoCDCoCB5b3Ug bmVlZDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgdG8gYmUgdG8gaGF2ZSB0 aGUgYWJpbGl0eSB0byBidWlsZCBhIHNpbmdsZSBzdGFibGU8YnI+DQrCoCDCoCDCoCDCoCBTUFQv REFHLjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgVGhl IHRoZW9yZXRpY2FsIGdyb3VuZHMgZm9yIHRoaXMgYXJlIGluIFQuPGJyPg0KwqAgwqAgwqAgwqAg R3JpZmZpbuKAmXMgYW5kPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqBTb2JyaW5ob+KAmXMgd29yayBvbiBCR1AtNCBhbmQgdGhhdCBsaWVzIGFscmVhZHk8YnI+DQrC oCDCoCDCoCDCoCBhIGNvdXBsZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgb2YgeWVhcnMgYWdvIGFuZCB0aGF0PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqBtYWtlcyB0aGUgYW5hbHlzaXMgbXVjaCDigJhlYXNpZXLigJkgKG5vIHdv cnJpZXMgYWJvdXQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoG5w KGNvbXBsZXRlKSBwcm9ibGVtcyw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoGV0Yy4pLiBUaGlzIGNvdWxkIGJlIGFwcGxpZWQgaW4gSTJSUyBhdCB0aGUgcm91dGlu Zzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgcHJvdG9jb2wgbGV2 ZWwuIFNvLCB3ZSBjb3VsZDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgZGlzY3VzcyB3aGVyZSB0aGF0IHNpdHMgKHNob3VsZCBiZSB0aGUgY2xpZW50cyw8YnI+DQrC oCDCoCDCoCDCoCByaWdodD8pPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqBhbmQgSSBkb27igJl0IGtub3cgaWY8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoHRoYXTigJlzIGJlZW4gYWxyZWFkeSBkb25lLCBzaW5jZSBJ4oCZbSBxdWl0 ZSBuZXc8YnI+DQrCoCDCoCDCoCDCoCB0byB0aGlzIGxpc3QuPGJyPg0KPGJyPg0KPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBUaGlzIGRvZXNu4oCZdCBhcHBseSB0byB0aGUg cHJvYmxlbSBhdCBoYW5kLDxicj4NCsKgIMKgIMKgIMKgIHRob3VnaC4uLiBZb3U8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHNlZW0gdG8gYmUgc2F5aW5nIChjbGFyaWZ5IGlm IHdyb25nKSAtLTxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgMS4g R2l2ZSBlYWNoIGNsaWVudCBzb21lIHNldCBvZiBiaXRzIG91dCBvZiBhIDEyODxicj4NCsKgIMKg IMKgIMKgIGJpdCBudW1iZXI8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHNw YWNlIChvciBsYXJnZXIsIGV0Yy4pPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAyLiBFYWNoIGNsaWVudCBjYW4gaGF2ZSBkaWZmZXJlbnQgJnF1b3Q7bWV0cmljcyZxdW90OyB3 aXRoaW48YnI+DQrCoCDCoCDCoCDCoCB0aGVpciBvd248YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoG51bWJlciBzcGFjZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgMy4gV2hlbiBhIGNsaWVudCBhdHRlbXB0cyB0byBhZGQgc29tZSBlcGhlbWVyYWw8YnI+ DQrCoCDCoCDCoCDCoCBzdGF0ZSwgdGhleTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgdXNlIGEgbWV0cmljIHdpdGhpbiB0aGVpciAmcXVvdDtzcGFjZSZxdW90Ozxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgNC4gVGhlIGFnZW50IGNhbiBqdXN0IHVzZSB0 aGUgc3RyYWlnaHQgbnVtYmVyIGFzIGE8YnI+DQrCoCDCoCDCoCDCoCByZWxhdGl2ZTxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgcHJpb3JpdHkgZm9yIGVhY2ggcG90ZW50aWFs IHBpZWNlIG9mIHN0YXRlPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqBUaGlzIGRvZXNuJiMzOTt0IGRvIGFueXRoaW5nIGRpZmZlcmVudCB0aGFuIHRoZSBjdXJyZW50 PGJyPg0KwqAgwqAgwqAgwqAgY29uY2VwdDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgb2YgcHJpb3JpdHkgYmV0d2VlbiBjbGllbnRzLCBvbmx5IGluIHRoZSBjdXJyZW50PGJy Pg0KwqAgwqAgwqAgwqAgcGxhbiBlYWNoPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqBjbGllbnQgb25seSBoYXMgb25lIHByaW9yaXR5LCByYXRoZXIgdGhhbjxicj4NCsKgIMKg IMKgIMKgIG11bHRpcGxlcy4gSSBkb24mIzM5O3Q8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoHNlZSB3aGVyZSB0aGlzIHJlbGF0ZXMgdG8gdGhlIHByb2JsZW0gYXQgaGFuZC48 YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoE5vdywgaGF2 aW5nIOKAnHNvbHZlZOKAnSB0aGF0IHBhcnQgb2YgdGhlIGVxdWF0aW9uPGJyPg0KwqAgwqAgwqAg wqAgOi0pICwgdGhlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBw YXJ0IHRoYXQgaW50ZXJlc3RzIG1lPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqBtb3JlIGlzIHRoZSBjb25mbGljdGluZyBjbGllbnRzIHByb2JsZW0sPGJyPg0KwqAg wqAgwqAgwqAgYmVjYXVzZSB0aGlzPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqBjb3VsZCBiZSBnZW5lcmFsaXNlZCB0bzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgb3RoZXIgcHJvYmxlbSBzcGFjZXMgaW4gdGhlIFNETiBhcmVhLiBJ IGRvPGJyPg0KwqAgwqAgwqAgwqAgYWdyZWUgdGhhdDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgYWdlbnRzIHNob3VsZCBiZSBhYmxlPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB0byBjYXRjaCBvZmZlbmRpbmcgc3RhdGUgYmVmb3Jl IGluc3RhbGxpbmcgaXQ8YnI+DQrCoCDCoCDCoCDCoCBhbmQgSeKAmW08YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGxvb2tpbmcgZm9yIHdheXMgdG8gc3BlY2lmeTxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYSBtaW5pbWFsIHNldCBv ZiBmZWF0dXJlcyB0aGF0IG5lZWQgdG8gYmU8YnI+DQrCoCDCoCDCoCDCoCBzdXBwb3J0ZWQgYXQ8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHByb3RvY29sIGxldmVs Ljxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgQW55b25l IGVsc2UgaW50ZXJlc3RlZD88YnI+DQo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoFRoaXMgaXMgcHJlY2lzZWx5IHdoZXJlIHRoZSBwcm9ibGVtIGxpZXMuIEFuZCB0 aGlzPGJyPg0KwqAgwqAgwqAgwqAgaXMgd2hlcmU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoHlvdSYjMzk7cmUgZ29pbmcgdG8gaGl0IHRoZSBDQVAgdGhlb3JlbSBpbiBmdWxs IGZvcmNlLjxicj4NCsKgIMKgIMKgIMKgIFRoZXJlIGFyZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgb25seSBhIGZldyBjaG9pY2VzIC0tPGJyPg0KPGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAxLiBNYWtlIHRoZSBkYXRhYmFzZSBldmVudHVhbGx5IGNv bnNpc3RlbnQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoDIuIFNodXQgZG93 biBhY2Nlc3NpYmlsaXR5IGR1cmluZyBjaGFuZ2VzPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAzLiA/Pzxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgKDEpIGlzIHRoZSBpZGVhIG9mIGVpdGhlciBoYXZpbmcgdGhlIGFnZW50IGNhbGw8YnI+DQrC oCDCoCDCoCDCoCBiYWNrIHRvIGFsbDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgdGhlIGNsaWVudHMgd2hlbiBzdGF0ZSB0aGV5IGluc3RhbGxlZCBpcyBvdmVyd3JpdHRlbiBv cjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYWxsb3dpbmcgdGhlIGFnZW50 IHRvIGxvY2FsbHkgc3RvcmUgc29tZSBzdGF0ZSB3aGVyZSBpdDxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgYWxyZWFkeSBoYXMgdGhlIGluZm9ybWF0aW9uIGluIGhhbmQgYW5k IGluc3RhbGwgaXQ8YnI+DQrCoCDCoCDCoCDCoCBsb2NhbGx5PGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAtLSB0aGUgb25seSByZWFsIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGVz ZSB0d288YnI+DQrCoCDCoCDCoCDCoCBzb2x1dGlvbnMgaXM8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoHRoZSAmcXVvdDtiYWxhbmNlIG9mIGNvbXBsZXhpdHkgdmVyc3VzIHNw ZWVkLi4uJnF1b3Q7IFRoZSBlbnRpcmU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoGRpc2N1c3Npb24gaGVyZSBpcyBob3cgbXVjaCBhZGRpdGlvbmFsIGNvbXBsZXhpdHk8YnI+ DQrCoCDCoCDCoCDCoCBhcmUgd2U8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oGFjdHVhbGx5IGFkZGluZyBieSBkb2luZyAmcXVvdDtwYW5lcyBvZiBnbGFzcywmcXVvdDsgd2hp Y2g8YnI+DQrCoCDCoCDCoCDCoCBhcmUganVzdDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgbG9jYWxseSBzdG9yZWQgc3RhdGUgd2hpY2ggaXNuJiMzOTt0IGN1cnJlbnRseTxi cj4NCsKgIMKgIMKgIMKgIGluc3RhbGxlZC4gSSYjMzk7bTxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgYXJndWluZyB0aGF0IHRoZXJlJiMzOTtzIG1pbmltYWwgY29tcGxleGl0 eSBhZGRlZCB0aGF0PGJyPg0KwqAgwqAgwqAgwqAgeW91JiMzOTtyZTxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgbm90IGFscmVhZHkgZ29pbmcgdG8gaGF2ZSBpbiB0aGUgc3lz dGVtIHRvIGFsbG93PGJyPg0KwqAgwqAgwqAgwqAgdGhlIGFnZW50PGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqB0byBzdG9yZSBpbmZvcm1hdGlvbiBsb2NhbGx5IF9pZl8gaXQg Y2hvb3NlcyB0by48YnI+DQrCoCDCoCDCoCDCoCBKZWZmIGlzPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqBhcmd1aW5nIChJIHRoaW5rKSB0aGF0IHRoZSAmcXVvdDtwYW5lcyBv ZiBnbGFzcyZxdW90OyBjb25jZXB0PGJyPg0KwqAgwqAgwqAgwqAgaXMgYTxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgY29oZXJlbnQgd2F5IG9mIGxvb2tpbmcgYXQgdGhpcyBw cm9ibGVtIHRoYXQgd2lsbDxicj4NCsKgIMKgIMKgIMKgIGhlbHAgdXM8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoHVuZGVyc3RhbmQgYW5kIG1hbmFnZSB0aGUgY29tcGxleGl0 eSBpbiBhIHdheSB0aGF0PGJyPg0KwqAgwqAgwqAgwqAgbWFrZXM8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoHNlbnNlLiBKb2VsIGlzIGFyZ3VpbmcgKEkgdGhpbmspIHRoYXQg dGhpcyBzb3J0IG9mPGJyPg0KwqAgwqAgwqAgwqAgc29sdXRpb248YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoGlzIG91dCBvZiB0aGUgV0cgY2hhcnRlciwgYW5kIGl0JiMzOTtz IHRvbyBjb21wbGV4LiBJPGJyPg0KwqAgwqAgwqAgwqAgX3RoaW5rXyBJPGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBoYXZlIHRoZSB0aDxicj4NCjxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgcjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgZWUgZ2VuZXJhbCBwZXJzcGVjdGl2 ZXMgcmlnaHQsIGJ1dCBJIGRvbiYjMzk7dCBrbm93IGlmIEkgcmVhbGx5PGJyPg0KwqAgwqAgwqAg wqAgaGF2ZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgc28uLi4gOi0pPGJyPg0KPGJyPg0KPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAoMikgaXMgdGhlIGlkZWEgb2YgbG9j a2luZyB0aGUgZGF0YWJhc2Ugd2hpbGUgeW91JiMzOTtyZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgY2hhbmdpbmcgaXQuIFRoaXMgaXMgZXhwbGljaXRseSBvdXRzaWRlIHRo ZSBzY29wZTxicj4NCsKgIMKgIMKgIMKgIG9mIEkyUlM8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoGVudGlyZWx5LCBnaXZlbiB3ZSYjMzk7cmUgdHJ5aW5nIHRvIGRlc2lnbiBz b21ldGhpbmcgdGhhdCYjMzk7czxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg YXRvbWljL3Jlc3RmdWwuIFRoZXJlIGFyZSBhIGxvdCBvZiB0ZWNobmlxdWVzIHlvdTxicj4NCsKg IMKgIMKgIMKgIGNhbiB1c2UgdG88YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oHNwZWVkIHVwIGxvY2tpbmcgLS0gcm93IGxvY2tpbmcsIHNoYXJkaW5nLCBldGMuIC0tPGJyPg0K wqAgwqAgwqAgwqAgYnV0IG5vbmU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oG9mIHRoZXNlIGFyZSBpbnRlcmVzdGluZyBmcm9tIHRoZSBJMlJTIHBlcnNwZWN0aXZlLjxicj4N Cjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgOi0pPGJyPg0KPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBSdXNzPGJyPg0KPGJyPg0KPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N Cjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgRXN0ZSBtZW5zYWplIHkgc3VzIGFkanVu dG9zIHNlIGRpcmlnZW4gZXhjbHVzaXZhbWVudGUgYSBzdTxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgZGVzdGluYXRhcmlvLCBwdWVkZSBjb250ZW5lciBpbmZvcm1hY2nDs24gcHJpdmls ZWdpYWRhIG88YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGNvbmZpZGVuY2lhbCB5IGVz IHBhcmEgdXNvIGV4Y2x1c2l2byBkZSBsYSBwZXJzb25hIG88YnI+DQrCoCDCoCDCoCDCoCBlbnRp ZGFkIGRlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBkZXN0aW5vLiBTaSBubyBlcyB1 c3RlZC4gZWwgZGVzdGluYXRhcmlvIGluZGljYWRvLCBxdWVkYTxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgbm90aWZpY2FkbyBkZSBxdWUgbGEgbGVjdHVyYSwgdXRpbGl6YWNpw7NuLCBk aXZ1bGdhY2nDs248YnI+DQrCoCDCoCDCoCDCoCB5L28gY29waWE8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoHNpbiBhdXRvcml6YWNpw7NuIHB1ZWRlIGVzdGFyIHByb2hpYmlkYSBlbiB2 aXJ0dWQgZGUgbGE8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGxlZ2lzbGFjacOzbiB2 aWdlbnRlLiBTaSBoYSByZWNpYmlkbyBlc3RlIG1lbnNhamUgcG9yPGJyPg0KwqAgwqAgwqAgwqAg ZXJyb3IsIGxlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqByb2dhbW9zIHF1ZSBub3Mg bG8gY29tdW5pcXVlIGlubWVkaWF0YW1lbnRlIHBvciBlc3RhPGJyPg0KwqAgwqAgwqAgwqAgbWlz bWEgdsOtYSB5PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBwcm9jZWRhIGEgc3UgZGVz dHJ1Y2Npw7NuLjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgVGhlIGluZm9y bWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIHRyYW5zbWlzc2lvbiBpczxicj4NCsKgIMKgIMKgIMKg IHByaXZpbGVnZWQgYW5kPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBjb25maWRlbnRp YWwgaW5mb3JtYXRpb24gaW50ZW5kZWQgb25seSBmb3IgdGhlIHVzZSBvZiB0aGU8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoGluZGl2aWR1YWwgb3IgZW50aXR5IG5hbWVkIGFib3ZlLiBJ ZiB0aGUgcmVhZGVyIG9mIHRoaXM8YnI+DQrCoCDCoCDCoCDCoCBtZXNzYWdlPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqBpcyBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFy ZSBoZXJlYnkgbm90aWZpZWQ8YnI+DQrCoCDCoCDCoCDCoCB0aGF0IGFueTxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uIG9yIGNvcHlpbmcg b2YgdGhpczxicj4NCsKgIMKgIMKgIMKgIGNvbW11bmljYXRpb24gaXM8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXM8YnI+DQrCoCDCoCDCoCDCoCB0cmFuc21pc3Npb24gaW48YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoGVycm9yLCBkbyBub3QgcmVhZCBpdC4gUGxlYXNlIGltbWVkaWF0ZWx5IHJl cGx5IHRvIHRoZTxicj4NCsKgIMKgIMKgIMKgIHNlbmRlcjxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgdGhhdCB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJy b3IgYW5kIHRoZW48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGRlbGV0ZSBpdC48YnI+ DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoEVzdGEgbWVuc2FnZW0gZSBzZXVzIGFu ZXhvcyBzZSBkaXJpZ2VtIGV4Y2x1c2l2YW1lbnRlPGJyPg0KwqAgwqAgwqAgwqAgYW8gc2V1PGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBkZXN0aW5hdMOhcmlvLCBwb2RlIGNvbnRlciBp bmZvcm1hw6fDo28gcHJpdmlsZWdpYWRhIG91PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqBjb25maWRlbmNpYWwgZSDDqSBwYXJhIHVzbyBleGNsdXNpdm8gZGEgcGVzc29hIG91PGJyPg0K wqAgwqAgwqAgwqAgZW50aWRhZGUgZGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGRl c3Rpbm8uIFNlIG7Do28gw6kgdm9zc2Egc2VuaG9yaWEgbyBkZXN0aW5hdMOhcmlvPGJyPg0KwqAg wqAgwqAgwqAgaW5kaWNhZG8sIGZpY2E8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoG5v dGlmaWNhZG8gZGUgcXVlIGEgbGVpdHVyYSwgdXRpbGl6YcOnw6NvLCBkaXZ1bGdhw6fDo288YnI+ DQrCoCDCoCDCoCDCoCBlL291IGPDs3BpYTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg c2VtIGF1dG9yaXphw6fDo28gcG9kZSBlc3RhciBwcm9pYmlkYSBlbSB2aXJ0dWRlIGRhPGJyPg0K wqAgwqAgwqAgwqAgbGVnaXNsYcOnw6NvPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB2 aWdlbnRlLiBTZSByZWNlYmV1IGVzdGEgbWVuc2FnZW0gcG9yIGVycm8sIHJvZ2Ftb3MtbGhlPGJy Pg0KwqAgwqAgwqAgwqAgcXVlIG5vczxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgbyBj b211bmlxdWUgaW1lZGlhdGFtZW50ZSBwb3IgZXN0YSBtZXNtYSB2aWEgZSBwcm9jZWRhPGJyPg0K wqAgwqAgwqAgwqAgYSBzdWE8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGRlc3RydWnD p8Ojbzxicj4NCjxicj4NCjxicj4NCjxicj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT48 L2Rpdj48YnI+PC9kaXY+PC9kaXY+DQo= --001a11c2641683726a05254c4b7d-- From nobody Tue Nov 24 09:08:34 2015 Return-Path: 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 BC6C81B2E11 for ; Tue, 24 Nov 2015 09:08:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 scnBzS6Nj11j for ; Tue, 24 Nov 2015 09:08:28 -0800 (PST) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 3E2C51B2E25 for ; Tue, 24 Nov 2015 09:08:19 -0800 (PST) Received: by oige206 with SMTP id e206so13652734oig.2 for ; Tue, 24 Nov 2015 09:08:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ljiabYteQ3fcvKx/VYSUtbeO0Rq3Pv1EJnAXCKAh/Gs=; b=BdpZMkTDsD4t8Q+SR/yr5eUKsZ0lOms2dzhG8tQ63PK3viIzKpjJB5onqbHq05wd5d QW16NId78Lsgz2l9ML3GUSe14R1EnMIyXjbzMatq790OhRgXJtBeRYbp+1NgB79olaj8 QM/byCUfPjjimYLR+5ol2UBaSunCXcsO8MwAn1FYXgKUhoPPDbg7OEi00/smBbOQO4lY j9CzP1c2O4/LNYQe33f35i8Kd7sbfPlnlKeZRrFGyGhduOP1GZe2hSBKTGYctavpnBn/ qQy6A5NTZJK1+6IHB0e7A41+3lD3d1202hWby1sFJpDuB325rj1Sb4H8iAn07dauRnHq R0Cg== MIME-Version: 1.0 X-Received: by 10.202.74.69 with SMTP id x66mr20143061oia.96.1448384898600; Tue, 24 Nov 2015 09:08:18 -0800 (PST) Received: by 10.60.177.103 with HTTP; Tue, 24 Nov 2015 09:08:18 -0800 (PST) In-Reply-To: References: <20151123071558.25655.92641.idtracker@ietfa.amsl.com> <8D628270-A455-4E01-881F-BA20D544228D@ericsson.com> <041001d12640$9d5104b0$d7f30e10$@ndzh.com> <047901d12663$cb716880$62543980$@ndzh.com> Date: Tue, 24 Nov 2015 12:08:18 -0500 Message-ID: From: Alia Atlas To: "Acee Lindem (acee)" Content-Type: multipart/alternative; boundary=001a1134f38261149305254c63fa Archived-At: Cc: Jeffrey Haas , "i2rs@ietf.org" , Jeff Tantsura , Susan Hares Subject: Re: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 17:08:33 -0000 --001a1134f38261149305254c63fa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Acee, As Sue has said, the I2RS Info Model has passed WGLC and is just waiting for the DM to be done in order to progress. Obviously, substantial technical concerns are always welcome - there's a long way between WGLC and final IESG approval; I do not think that you have clearly described your technical concerns. Are you mixing up using a tunnel for forwarding with provisioning the tunnel?? The I2RS RIB model is not for provisioning tunnels. It is intended so that traffic can be forwarded properly, regardless of the abstraction. For instance, with MPLS, a packet could be sent out with an arbitrary label or label stack, a packet could follow an LSP, or a packet could follow a tunnel. By providing the ability to forward via these different layers of abstraction, the RIB model allows forwarding to occur correctly even when a tunnel or LSP changes - just like a next-hop can be specified to forward like a different prefix and then follows that prefix. I certainly do not see the I2RS RIB model as creating tunnels - but merely being able to use ones that already exist. Now, if your objection is that the I2RS RIB model should use a common grouping that describes all types of tunnels, I have yet to see one. The efforts to provide YANG models for tunnels are still quite immature. Describing what types of groupings would be useful is the type of work that I hope the design team will do. Asking I2RS to stall until time can be dedicated isn't appropriate. Regards, Alia On Tue, Nov 24, 2015 at 8:34 AM, Acee Lindem (acee) wrote: > From: Susan Hares > Date: Monday, November 23, 2015 at 9:57 PM > To: Acee Lindem , "i2rs@ietf.org" > Cc: Alia Atlas , Jeff Haas , Jeff > Tantsura > Subject: RE: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt > > Acee: > > > > Is your input individual input or input from the routing architecture for > yang models? > > > Individual. > > > > > > > The routing architecture for yang models is incomplete without the > consideration of the I2RS ephemeral state and I2RS architecture. Asking > the I2RS WG to change a document that is in WG LC based on an incomplete > architectural document is not reasonable. > > > My comment with respect to tunnel provisioning is not based on any > architecture document. > > An alignment between > https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ without > the consideration of the I2RS ephemeral state is an incomplete alignment > and a problematic approach for I2RS WG=E2=80=99s efforts. > > > I2RS models should augment the base models with ephemeral state. > > > > > In a volunteer organization, each person has the right to makes choices i= n > what they have time to do. If you do not have bandwidth to provide an > adequate routing architecture for yang models that considers ephemeral > state or its needs, that is your choice. Unless you have a concrete > proposal for the ephemeral state that covers I2RS RIB and > https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/, the I2RS > WG LC will be closed after 2 week (11/23 =E2=80=93 12/7) WG review of the= in draft-ietf-i2rs-rib-data-model-04.txt. > > > > We have proposed tunnel models, draft-ietf-netmod-routing-cfg is not mean= t > to supplant them. BTW, we don=E2=80=99t plan to > update draft-ietf-i2rs-rib-data-model-04.txt. Updates based on I2RS will = be > in the a next-hop augmentation draft that extends > draft-ietf-netmod-rtg-cfg. > > > > > > Please remember that the I2RS RIB model has two parts: I2RS Informationa= l > Model and I2RS Data Model. The I2RS Informational Model and the I2RS > Data Model have descriptions on the soft tunnel provisioning as > mechanisms. Questions at this point must demonstrate a knowledge of thes= e > documents or suggest specific changes to the documents. If you wish to > raise the following questions, please do this in light of specific sectio= ns > that include both the I2RS Informational Model, the I2RS Data Model, and > I2RS architecture. > > > > a) I2RS tunnels must include additions beyond encapsulation, > > b) Why the I2RS Informational Model and the I2RS Data Model do not > provide the soft tunnel provisioning or describe the specifics of this > provision? > > > > The I2RS Informational Model has examples for these tunnels. You are > welcome to make proposal for specific changes to the I2RS Informational > Model or the I2RS Data Model. The I2RS Informational Model has completed > WG LC so the bar for substantive comments is high. > > > I don=E2=80=99t believe this excerpt from the RIB information models desc= ribes > soft tunnel provisioning for each of the tunnels proposed in the RIB data > model: > > 7.2.1. Tunnel nexthops > > A tunnel nexthop points to a tunnel of some kind. Traffic that goes > over the tunnel gets encapsulated with the tunnel encap. Tunnel > nexthops are useful for abstracting out details of the network, by > having the traffic seamlessly route between network edges. At the > end of a tunnel, the tunnel will get decapsulated. Thus the grammar > supports two kinds of operations, one for encap and another for > decap. > > Acee > > > > > > > > > Cheers, > > > > Sue Hares > > > > *From:* i2rs [mailto:i2rs-bounces@ietf.org ] *On > Behalf Of *Acee Lindem (acee) > *Sent:* Monday, November 23, 2015 7:30 PM > *To:* Susan Hares; i2rs@ietf.org > *Subject:* Re: [i2rs] FW: I-D Action: > draft-ietf-i2rs-rib-data-model-04.txt > > > > Sue, > > > > *From: *i2rs on behalf of Susan Hares < > shares@ndzh.com> > *Date: *Monday, November 23, 2015 at 5:45 PM > *To: *"i2rs@ietf.org" > *Subject: *[i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt > > > > Resending to I2RS WG. > > > > *From:* Susan Hares [mailto:shares@ndzh.com ] > *Sent:* Monday, November 23, 2015 5:33 PM > *To:* 'Jeff Tantsura'; 'Acee Lindem (acee)'; 'Mach Chen'; 'i2rs@ietf.org' > *Cc:* 'Jeffrey Haas'; 'Alia Atlas'; 'Benoit Claise (bclaise)' > *Subject:* RE: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.txt > > > > Jeff and Acee: > > > > Your suggested change goes against the WG adopted RIB Information draft > that has been discussed for over 2 years. The informational draft has be= en > through WG LC and you did not make any suggestions or comments during the > WG LC. Any change of this matter is not simply something you indicate to > the authors, but needs to be discussed on the WG as a direction change fo= r > the RIB IM/DM models. > > > > Independent of the I2RS efforts, milestones, and processes, I think we > need to address whether provisioning all these tunnels via RIB installati= on > is appropriate and, additionally, consistent with other WG YANG models. = In > many cases, it would seem there are tunnel attributes other than the enca= ps > that need to be provisioned. At a minimum, I think you=E2=80=99d need to = either > reference an RFC describing soft tunnel provisioning or describe the > specifics of this provisioning. > > > > > > Prior to moving this change through WG adoption cycle, the routing > architectural team needs to have: a) concrete proposal for the ephemeral > state that covers I2RS RIB and > https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ and b) > I requested this input of Acee Lindem as a representative of the routing > architecture team. > > > > The identification of this problem with tunnel provisioning is a direct > outcome of this effort. > > > > > > > > I will be glad to work with you on a concrete proposal that you can send > to the email list and present at the I2RS interim meeting on 12/16/2015 > (10-11:30am ET). > > > > I will continue to work on ietf-routing alignment but don=E2=80=99t have = the > bandwidth for the above. > > > > Acee > > > > > > > > > > > > Sue Hares > > > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org ] On > Behalf Of Jeff Tantsura > Sent: Monday, November 23, 2015 4:27 PM > To: Acee Lindem (acee); Mach Chen; i2rs@ietf.org > Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.txt > > > > Hi Mach, > > > > I agree with Acee=E2=80=99s comments and would encourage you to use > generic/existing tunnel model(s), please see comments provided during RTG= WG > meeting in Yokohama. > > There are already too many, we need to rationalize this work. > > > > This is what has been discussed in Yokohama, Robin presented > > > > -- draft-li-rtgwg-utunnel-yang > > -- draft-li-rtgwg-tunnel-policy-yang > > -- draft-wwz-netmod-yang-tunnel-cfg > > -- draft-zheng-intarea-gre-yang > > -- draft-liu-intarea-gre-tunnel-yang > > -- draft-liu-intarea-ipipv4-tunnel-yang > > > > Cheers, > > Jeff > > > > > > > > > > > > > > On 11/23/15, 11:56, "i2rs on behalf of Acee Lindem (acee)" on behalf of acee@cisco.com > > wrote: > > > > >Hi Mach, > > > > > >I=E2=80=99m looking at draft-ietf-i2rs-rib-data-model-04.txt and it stil= l > > >includes all the tunnel encaps. I know you received several comments > > >that those should be in the tunnel model(s) and this I2RS RIB model > > >should merely reference an imported tunnel abstraction. How are you > > >going to address this? It seemed that the consensus (and an opinion > > >that I share) was that this model should not attempt to generically > > >created tunnels via RIB/FIB entries. > > >Thanks, > > >Acee > > > > > >On 11/23/15, 2:23 AM, "i2rs on behalf of Mach Chen" > > > wrote: > > > > > >>Hi, > > >> > > >>We just uploaded an update that addresses the comments received > > >>(include online and offline) recently. Please review the draft and > comment! > > >> > > >>Thanks, > > >>Mach > > >> > > >>> -----Original Message----- > > >>> From: i2rs [mailto:i2rs-bounces@ietf.org ] On > Behalf Of > > >>>internet-drafts@ietf.org > > >>> Sent: Monday, November 23, 2015 3:16 PM > > >>> To: i-d-announce@ietf.org > > >>> Cc: i2rs@ietf.org > > >>> Subject: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.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 : A YANG Data Model for Routing Information > Base > > >>> (RIB) > > >>> Authors : Lixing Wang > > >>> Hariharan Ananthakrishnan > > >>> Mach(Guoyi) Chen > > >>> Amit Dass > > >>> Sriganesh Kini > > >>> Nitin Bahadur > > >>> Filename : draft-ietf-i2rs-rib-data-model-04.txt > > >>> Pages : 65 > > >>> Date : 2015-11-22 > > >>> > > >>> Abstract: > > >>> This document defines a YANG data model for Routing Information Ba= se > > >>> (RIB) that aligns with the I2RS RIB information model. > > >>> > > >>> > > >>> > > >>> The IETF datatracker status page for this draft is: > > >>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/ > > >>> > > >>> There's also a htmlized version available at: > > >>> https://tools.ietf.org/html/draft-ietf-i2rs-rib-data-model-04 > > >>> > > >>> A diff from the previous version is available at: > > >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2rs-rib-data-model-04 > > >>> > > >>> > > >>> 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 > > >>> 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 > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > --001a1134f38261149305254c63fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Acee,

As Sue has said, the I2RS Info Mo= del has passed WGLC and is just waiting for the DM to be done in order to p= rogress.=C2=A0 Obviously, substantial technical concerns are always welcome= - there's a long way between WGLC and final IESG approval; I do not th= ink that you have clearly described your technical concerns.=C2=A0 Are you = mixing up using a tunnel for forwarding with provisioning the tunnel?? =C2= =A0

The I2RS RIB model is not for provisioning tun= nels.=C2=A0 It is intended so that traffic can be forwarded properly, regar= dless of the abstraction.=C2=A0 For instance, with MPLS, a packet could be = sent out with an arbitrary label or label stack, a packet could follow an L= SP, or a packet could follow a tunnel. =C2=A0 By providing the ability to f= orward via these different layers of abstraction, the RIB model allows forw= arding to occur correctly even when a tunnel or LSP changes - just like a n= ext-hop can be specified to forward like a different prefix and then follow= s that prefix.

I certainly do not see the I2RS RIB= model as creating tunnels - but merely being able to use ones that already= exist.

Now, if your objection is that the I2RS RI= B model should use a common grouping that describes all types of tunnels, I= have yet to see one.=C2=A0 The efforts to provide YANG models for tunnels = are still quite immature.
Describing what types of groupings woul= d be useful is the type of work that I hope the design team will do.
<= div>Asking I2RS to stall until time can be dedicated isn't appropriate.=

Regards,
Alia

=

O= n Tue, Nov 24, 2015 at 8:34 AM, Acee Lindem (acee) <acee@cisco.com> wrote:
From: <= /span> Susan Hares <<= a href=3D"mailto:shares@ndzh.com" style=3D"font-family:Calibri;font-size:11= pt" target=3D"_blank">shares@ndzh.com>
Date: Monday, November 23, 2015 at = 9:57 PM
To: Acee Lindem <acee@cisco.com>, "i2rs@ietf.org" <i2rs@ietf.org>
Cc: Alia Atlas <akatlas@gmail.com>, Jeff Haas= <jhaas@pfrc.org= >, Jeff Tantsura <jeff.tantsura@ericsson.com>
Subject: RE: [i2rs] FW: I-D Action:= draft-ietf-i2rs-rib-data-model-04.txt

Acee:

=C2=A0

Is your input individual input or input from the rou= ting architecture for yang models?

Individual.=C2=A0


=C2=A0

<I2RS chair hat on>

The routing architecture for yang models is incomplete without the consi= deration of the I2RS ephemeral state and I2RS architecture.=C2=A0 Asking th= e I2RS WG to change a document that is in WG LC based on an incomplete arch= itectural document is not reasonable. =C2=A0

My comment with respect to tunnel provisioning is not based on any architec= ture document.=C2=A0

An alignment between https://datatracker.ietf.org/doc/draft-iet= f-netmod-routing-cfg/=C2=A0without t= he consideration of the I2RS ephemeral state is an incomplete alignment and= a problematic =C2=A0approach for I2RS WG=E2=80=99s efforts. =C2=A0=C2=A0

I2RS models should augment the base models with ephemeral state.=C2=A0


=C2=A0

In a volunteer organization, each person has the rig= ht to makes choices in what they have time to do.=C2=A0=C2=A0 If you do not= have bandwidth to provide an adequate routing architecture for yang models= that considers ephemeral state or its needs, that is your choice.=C2=A0 Unless you have a concrete proposal for the eph= emeral state that covers I2RS RIB and https://datatracker.iet= f.org/doc/draft-ietf-netmod-routing-cfg/, the I2RS WG LC will be= closed after 2 week (11/23 =E2=80=93 12/7) WG review of the in draft-ietf-i2rs-rib-data-model-04.txt.=C2=A0 =C2=A0=C2=A0

We have proposed tunnel models, draft-ietf-netmod-routing-cfg is not meant = to supplant them. BTW, we don=E2=80=99t plan to update=C2=A0draft-ietf-i2rs= -rib-data-model-04.txt. Updates based on I2RS will be in the a next-hop aug= mentation draft that extends draft-ietf-netmod-rtg-cfg.=C2=A0

=C2=A0

=C2=A0

Please remember that the I2RS RIB model has two part= s:=C2=A0 I2RS Informational Model and I2RS Data Model.=C2=A0 The I2RS Informational Model and the I2RS Data = Model have descriptions on the soft tunnel provisioning as mechanisms.=C2= =A0 Questions at this point must demonstrate a knowledge of these documents= or suggest specific changes to the documents. =C2=A0=C2=A0If you wish to raise the following questions, please do this i= n light of specific sections that include both the I2RS Informational Model= , the I2RS Data Model, and I2RS architecture.

=C2=A0

a)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I2RS tunnels must include additions beyond encapsulation,

b)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Why the I2RS Informational Model and the I2RS Data Model do n= ot provide the soft tunnel provisioning or describe the specifics of this p= rovision?=C2=A0

=C2=A0

The I2RS Informational Model has examples for these = tunnels.=C2=A0 You are welcome to make proposal for specific changes to the= I2RS Informational Model or the I2RS Data Model.=C2=A0 The I2RS Informatio= nal Model has completed WG LC so the bar for substantive comments is high.

I don=E2=80=99t believe this excerpt from the RIB information models descri= bes soft tunnel provisioning for each of the tunnels proposed in the RIB da= ta model:

7.2.1.=C2=A0 Tunnel nexthops<= /div>

=C2=A0 =C2=A0A tunnel nexthop points= to a tunnel of some kind.=C2=A0 Traffic that goes
=C2=A0 =C2=A0over the tunnel gets en= capsulated with the tunnel encap.=C2=A0 Tunnel
=C2=A0 =C2=A0nexthops are useful for= abstracting out details of the network, by
=C2=A0 =C2=A0having the traffic seam= lessly route between network edges.=C2=A0 At the
=C2=A0 =C2=A0end of a tunnel, the tu= nnel will get decapsulated.=C2=A0 Thus the grammar
=C2=A0 =C2=A0supports two kinds of o= perations, one for encap and another for
=C2=A0 =C2=A0decap.

Acee=C2=A0


=C2=A0 =C2=A0=C2=A0

<I2RS chair hat off>

=C2=A0

Cheers, =

=C2=A0

Sue Har= es

=C2=A0

From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Monday, November 23, 2015 7:30 PM
To: Susan Hares; = i2rs@ietf.org
Subject: Re: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-0= 4.txt

=C2=A0

Sue,=C2= =A0

= =C2=A0

From: i2rs <i2rs-bounces@ietf.org> on behalf of Susan Hares <= ;shares@ndzh.com&g= t;
Date: Monday, November 23, 2015 at 5:45 PM
To: "i2rs@ie= tf.org" <i2r= s@ietf.org>
Subject: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.tx= t

= =C2=A0

Resending to I2RS WG. =

=C2=A0

From: Susan Hares [mailto:shares@ndzh.com]
Sent: Monday, November 23, 2015 5:33 PM
To: 'Jeff Tantsura'; 'Acee Lindem (acee)'; 'Mach= Chen'; 'i2rs@ietf.org'
Cc: 'Jeffrey Haas'; 'Alia Atlas'; 'Benoit Claise= (bclaise)'
Subject: RE: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.tx= t

=C2=A0

Jeff and Acee:

=C2=A0

Your suggested change goes against the WG ad= opted RIB Information draft that has been discussed for over 2 years.=C2=A0= The informational draft has been through WG LC and you did not make any su= ggestions or comments during the WG LC.=C2=A0 Any change of this matter is not simply something = you indicate to the authors, but needs to be discussed on the WG as a direc= tion change for the RIB IM/DM models.

= =C2=A0

Indepen= dent of the I2RS efforts, milestones, and processes, I think we need to add= ress whether provisioning all these tunnels via RIB installation is =C2=A0a= ppropriate and, additionally, consistent with other WG YANG models. In many cases, it would seem there are tunnel a= ttributes other than the encaps that need to be provisioned. At a minimum, = I think you=E2=80=99d need to either reference an RFC describing soft tunne= l provisioning or describe the specifics of this provisioning.=C2=A0

= =C2=A0

=C2=A0

Prior to moving this change through WG adopt= ion cycle, the routing architectural team needs to have: a) concrete propos= al for the ephemeral state that covers I2RS RIB and https://datatracker.ietf.org/doc/draft-ietf-netmod-routi= ng-cfg/ =C2=A0and =C2=A0b) I requested this input of Acee Lindem as a r= epresentative of the routing architecture team. =C2=A0=C2=A0<= /span>

= =C2=A0

The =C2= =A0identification of this problem with tunnel provisioning is a direct outc= ome of this effort.=C2=A0

= =C2=A0

=C2=A0

=C2=A0

I will be glad to work with you on a concret= e proposal that you can send to the email list and present at the I2RS inte= rim meeting on 12/16/2015 (10-11:30am ET).

= =C2=A0

I will = continue to work on ietf-routing alignment but don=E2=80=99t have the bandw= idth for the above.=C2=A0

= =C2=A0

Acee=C2= =A0

= =C2=A0

= =C2=A0

= =C2=A0

= =C2=A0

=C2=A0

=C2=A0Sue Hares

=C2=A0

-----Original Message-----
From: i2rs [mail= to:i2rs-bounces@ietf.org] On Behalf Of Jeff Tantsura
Sent: Monday, November 23, 2015 4:27 PM
To: Acee Lindem (acee); Mach Chen; i2rs@ietf.org
Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.txt

=C2=A0

Hi Mach,

=C2=A0

I agree with Acee=E2=80=99s comments and wou= ld encourage you to use generic/existing tunnel model(s), please see commen= ts provided during RTGWG meeting in Yokohama.

There are already too many, we need to ratio= nalize this work.

=C2=A0

This is what has been discussed in Yokohama,= Robin presented

=C2=A0

-- draft-li-rtgwg-utunnel-yang=

=C2=A0=C2=A0 -- draft-li-rtgwg-tunnel-policy= -yang

=C2=A0=C2=A0 -- draft-wwz-netmod-yang-tunnel= -cfg

=C2=A0=C2=A0 -- draft-zheng-intarea-gre-yang=

=C2=A0=C2=A0 -- draft-liu-intarea-gre-tunnel= -yang

=C2=A0=C2=A0 -- draft-liu-intarea-ipipv4-tun= nel-yang

=C2=A0

Cheers,

Jeff

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On 11/23/15, 11:56, "i2rs on behalf of = Acee Lindem (acee)" <i2rs-bounces@ietf.org on behalf of acee@cisco.com> wrote:

=C2=A0

>Hi Mach,

>=C2=A0

>I=E2=80=99m looking at draft-ietf-i2rs-r= ib-data-model-04.txt and it still

>includes all the tunnel encaps. I know y= ou received several comments

>that those should be in the tunnel model= (s) and this I2RS RIB model

>should merely reference an imported tunn= el abstraction. How are you

>going to address this? It seemed that th= e consensus (and an opinion

>that I share) was that this model should= not attempt to generically

>created tunnels via RIB/FIB entries.<= /u>

>Thanks,

>Acee

>=C2=A0

>On 11/23/15, 2:23 AM, "i2rs on beha= lf of Mach Chen"

><i2rs-bounces@ietf.org on behalf= of mach.chen@huawei.com> wrote:

>=C2=A0

>>Hi,

>>=C2=A0

>>We just uploaded an update that addr= esses the comments received

>>(include online and offline) recentl= y. Please review the draft and comment!

>>=C2=A0

>>Thanks,

>>Mach

>>=C2=A0

>>> -----Original Message-----

>>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of

>>>internet-drafts@ietf.org

>>> Sent: Monday, November 23, 2015= 3:16 PM

>>> To: i-d-announce@ietf.org=

>>> Cc: i2rs@ietf.org<= /a>

>>> Subject: [i2rs] I-D Action: dra= ft-ietf-i2rs-rib-data-model-04.txt

>>>

>>>

>>> A New Internet-Draft is availab= le from the on-line Internet-Drafts

>>>directories.

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

>>>Working Group=C2=A0 of the IETF.=

>>>

>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Title=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 : A YANG Data Model for Routing Information Base

>>> (RIB)

>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Authors=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = : Lixing Wang

>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Hariharan Ananthakrishn= an

>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Mach(Guoyi) Chen=

>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Amit Dass=

>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Sriganesh Kini

>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Nitin Bahadur=

>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Filename=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : draft-ietf-i2rs= -rib-data-model-04.txt

>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Pages=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : = 65

>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Date=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 : 2015-11-22

>>>

>>> Abstract:<= /p>

>>>=C2=A0=C2=A0=C2=A0 This document= defines a YANG data model for Routing Information Base

>>>=C2=A0=C2=A0=C2=A0 (RIB) that al= igns with the I2RS RIB information model.

>>>

>>>

>>>

>>> The IETF datatracker status pag= e for this draft is:

>>> https://datatracker.i= etf.org/doc/draft-ietf-i2rs-rib-data-model/=

>>>

>>> There's also a htmlized ver= sion available at:

>>> https://tools.ietf.or= g/html/draft-ietf-i2rs-rib-data-model-04

>>>

>>> A diff from the previous versio= n is available at:

>>> https://www.ietf.org/= rfcdiff?url2=3Ddraft-ietf-i2rs-rib-data-model-04

>>>

>>>

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

>>>submission=C2=A0 until the htmli= zed version and diff are available at

>>>tools.ietf.org.

>>>

>>> Internet-Drafts are also availa= ble by anonymous FTP at:

>>> ftp://ftp.ietf.org/in= ternet-drafts/

>>>

>>> _______________________________= ________________

>>> i2rs mailing list=

>>> i2rs@ietf.org<= /a>

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

>>=C2=A0

>>____________________________________= ___________

>>i2rs mailing list

>>i2rs@i= etf.org

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

>=C2=A0

>________________________________________= _______

>i2rs mailing list

>i2rs@ietf= .org

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

____________________________________________= ___

i2rs mailing list

i2rs@ietf.org<= /span>

https://www.ietf.org/mailman/listinfo/i2rs=


--001a1134f38261149305254c63fa-- From nobody Tue Nov 24 09:19:47 2015 Return-Path: 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 66D3B1B2EF9 for ; Tue, 24 Nov 2015 09:19:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.085 X-Spam-Level: X-Spam-Status: No, score=-15.085 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 3F_G4-mT76EB for ; Tue, 24 Nov 2015 09:19:34 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0DE11B2EFF for ; Tue, 24 Nov 2015 09:19:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=75023; q=dns/txt; s=iport; t=1448385573; x=1449595173; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=X80LAyqScQoW/gPYjc2iVzpKJ10VeyF9WAt/2MLrOyY=; b=F89LCKFRqMTOaNsEq5w4FQX6YLeUcAvAD54+6NXY54BmDL3lkeB7A/52 gQ6wGEEp5y0l5K56umQ4/H4R87NFaWECSUjYupJ3QENTreYzKxzn7wGZr 10Qdo8cBeTMFf+z9nG8xf7/rjYBwKcypwQhz1lamJmqUi9ndcmUdQ9lWE s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D/AQDsmlRW/49dJa1egm5NU28GvjYBD?= =?us-ascii?q?YFiAxcBCYVuAhyBJTgUAQEBAQEBAYEKhDQBAQEDAQEBARcJSwsMBAIBCA4DAQI?= =?us-ascii?q?BAQEhAQYDAgICHwYLFAMFAQgCBA4FiBkDCggNrh2LOg2EbQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBARiLUoJTgVcRASUQCg0JAgaCXIFEBZJrg2UBhSOCcoMlgXaBW0m?= =?us-ascii?q?Dd4c1hiaBAoNhg3EBEQ4BAUKCER2BVnIBg2k6gQcBAQE?= X-IronPort-AV: E=Sophos;i="5.20,339,1444694400"; d="scan'208,217";a="210924048" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Nov 2015 17:19:32 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id tAOHJV2q001994 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 24 Nov 2015 17:19:32 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 24 Nov 2015 12:19:31 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.000; Tue, 24 Nov 2015 12:19:31 -0500 From: "Acee Lindem (acee)" To: Alia Atlas Thread-Topic: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt Thread-Index: AQHRJtq4i8gYen3cvkK93qfxlwQz+p6ratQA Date: Tue, 24 Nov 2015 17:19:30 +0000 Message-ID: References: <20151123071558.25655.92641.idtracker@ietfa.amsl.com> <8D628270-A455-4E01-881F-BA20D544228D@ericsson.com> <041001d12640$9d5104b0$d7f30e10$@ndzh.com> <047901d12663$cb716880$62543980$@ndzh.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: multipart/alternative; boundary="_000_D27A04393F032aceeciscocom_" MIME-Version: 1.0 Archived-At: Cc: Jeffrey Haas , "i2rs@ietf.org" , Jeff Tantsura , Susan Hares Subject: Re: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 17:19:40 -0000 --_000_D27A04393F032aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWxpYSwNCg0KRnJvbTogQWxpYSBBdGxhcyA8YWthdGxhc0BnbWFpbC5jb208bWFpbHRvOmFrYXRs YXNAZ21haWwuY29tPj4NCkRhdGU6IFR1ZXNkYXksIE5vdmVtYmVyIDI0LCAyMDE1IGF0IDEyOjA4 IFBNDQpUbzogQWNlZSBMaW5kZW0gPGFjZWVAY2lzY28uY29tPG1haWx0bzphY2VlQGNpc2NvLmNv bT4+DQpDYzogU3VzYW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbTxtYWlsdG86c2hhcmVzQG5kemgu Y29tPj4sICJpMnJzQGlldGYub3JnPG1haWx0bzppMnJzQGlldGYub3JnPiIgPGkycnNAaWV0Zi5v cmc8bWFpbHRvOmkycnNAaWV0Zi5vcmc+PiwgSmVmZiBIYWFzIDxqaGFhc0BwZnJjLm9yZzxtYWls dG86amhhYXNAcGZyYy5vcmc+PiwgSmVmZiBUYW50c3VyYSA8amVmZi50YW50c3VyYUBlcmljc3Nv bi5jb208bWFpbHRvOmplZmYudGFudHN1cmFAZXJpY3Nzb24uY29tPj4NClN1YmplY3Q6IFJlOiBb aTJyc10gRlc6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtaTJycy1yaWItZGF0YS1tb2RlbC0wNC50 eHQNCg0KQWNlZSwNCg0KQXMgU3VlIGhhcyBzYWlkLCB0aGUgSTJSUyBJbmZvIE1vZGVsIGhhcyBw YXNzZWQgV0dMQyBhbmQgaXMganVzdCB3YWl0aW5nIGZvciB0aGUgRE0gdG8gYmUgZG9uZSBpbiBv cmRlciB0byBwcm9ncmVzcy4gIE9idmlvdXNseSwgc3Vic3RhbnRpYWwgdGVjaG5pY2FsIGNvbmNl cm5zIGFyZSBhbHdheXMgd2VsY29tZSAtIHRoZXJlJ3MgYSBsb25nIHdheSBiZXR3ZWVuIFdHTEMg YW5kIGZpbmFsIElFU0cgYXBwcm92YWw7IEkgZG8gbm90IHRoaW5rIHRoYXQgeW91IGhhdmUgY2xl YXJseSBkZXNjcmliZWQgeW91ciB0ZWNobmljYWwgY29uY2VybnMuICBBcmUgeW91IG1peGluZyB1 cCB1c2luZyBhIHR1bm5lbCBmb3IgZm9yd2FyZGluZyB3aXRoIHByb3Zpc2lvbmluZyB0aGUgdHVu bmVsPz8NCg0KDQpUaGUgSTJSUyBSSUIgbW9kZWwgaXMgbm90IGZvciBwcm92aXNpb25pbmcgdHVu bmVscy4gIEl0IGlzIGludGVuZGVkIHNvIHRoYXQgdHJhZmZpYyBjYW4gYmUgZm9yd2FyZGVkIHBy b3Blcmx5LCByZWdhcmRsZXNzIG9mIHRoZSBhYnN0cmFjdGlvbi4gIEZvciBpbnN0YW5jZSwgd2l0 aCBNUExTLCBhIHBhY2tldCBjb3VsZCBiZSBzZW50IG91dCB3aXRoIGFuIGFyYml0cmFyeSBsYWJl bCBvciBsYWJlbCBzdGFjaywgYSBwYWNrZXQgY291bGQgZm9sbG93IGFuIExTUCwgb3IgYSBwYWNr ZXQgY291bGQgZm9sbG93IGEgdHVubmVsLiAgIEJ5IHByb3ZpZGluZyB0aGUgYWJpbGl0eSB0byBm b3J3YXJkIHZpYSB0aGVzZSBkaWZmZXJlbnQgbGF5ZXJzIG9mIGFic3RyYWN0aW9uLCB0aGUgUklC IG1vZGVsIGFsbG93cyBmb3J3YXJkaW5nIHRvIG9jY3VyIGNvcnJlY3RseSBldmVuIHdoZW4gYSB0 dW5uZWwgb3IgTFNQIGNoYW5nZXMgLSBqdXN0IGxpa2UgYSBuZXh0LWhvcCBjYW4gYmUgc3BlY2lm aWVkIHRvIGZvcndhcmQgbGlrZSBhIGRpZmZlcmVudCBwcmVmaXggYW5kIHRoZW4gZm9sbG93cyB0 aGF0IHByZWZpeC4NCg0KSSBjZXJ0YWlubHkgZG8gbm90IHNlZSB0aGUgSTJSUyBSSUIgbW9kZWwg YXMgY3JlYXRpbmcgdHVubmVscyAtIGJ1dCBtZXJlbHkgYmVpbmcgYWJsZSB0byB1c2Ugb25lcyB0 aGF0IGFscmVhZHkgZXhpc3QuDQoNCkkgYmVsaWV2ZSB0aGUgaW50ZW5zaW9uIG9mIHRoZSBtb2Rl bCBpcyBjbGVhcmx5IHRvIGR5bmFtaWNhbGx5IGNyZWF0ZSB0aGUgdHVubmVscy4NCg0KICAgVHVu bmVsIG5leHRob3BzIGFsbG93IGFuIGV4dGVybmFsIGVudGl0eSB0byBwcm9ncmFtIHN0YXRpYyB0 dW5uZWwNCiAgIGhlYWRlcnMuICBUaGVyZSBjYW4gYmUgY2FzZXMgd2hlcmUgdGhlIHJlbW90ZSB0 dW5uZWwgZW5kLXBvaW50IGRvZXMNCiAgIG5vdCBzdXBwb3J0IGR5bmFtaWMgc2lnbmFsaW5nIChl LmcuIG5vIExEUCBzdXBwb3J0IG9uIGEgaG9zdCkgYW5kIGluDQogICB0aG9zZSBjYXNlcyB0aGUg ZXh0ZXJuYWwgZW50aXR5IG1pZ2h0IHdhbnQgdG8gcHJvZ3JhbSB0aGUgdHVubmVsDQogICBoZWFk ZXIgb24gYm90aCBlbmRzIG9mIHRoZSB0dW5uZWwuICBUaGUgdHVubmVsIG5leHRob3AgaXMga2Vw dA0KICAgZ2VuZXJpYyB3aXRoIHNwZWNpZmljYXRpb25zIHByb3ZpZGVkIGZvciBzb21lIGNvbW1v bmx5IHVzZWQgdHVubmVscy4NCiAgIEl0IGlzIGV4cGVjdGVkIHRoYXQgdGhlIGRhdGEtbW9kZWwg d2lsbCBtb2RlbCB0aGVzZSB0dW5uZWwgdHlwZXMgd2l0aA0KICAgY29tcGxldGUgYWNjdXJhY3ku DQoNCg0KTm93LCBpZiB5b3VyIG9iamVjdGlvbiBpcyB0aGF0IHRoZSBJMlJTIFJJQiBtb2RlbCBz aG91bGQgdXNlIGEgY29tbW9uIGdyb3VwaW5nIHRoYXQgZGVzY3JpYmVzIGFsbCB0eXBlcyBvZiB0 dW5uZWxzLCBJIGhhdmUgeWV0IHRvIHNlZSBvbmUuICBUaGUgZWZmb3J0cyB0byBwcm92aWRlIFlB TkcgbW9kZWxzIGZvciB0dW5uZWxzIGFyZSBzdGlsbCBxdWl0ZSBpbW1hdHVyZS4NCkRlc2NyaWJp bmcgd2hhdCB0eXBlcyBvZiBncm91cGluZ3Mgd291bGQgYmUgdXNlZnVsIGlzIHRoZSB0eXBlIG9m IHdvcmsgdGhhdCBJIGhvcGUgdGhlIGRlc2lnbiB0ZWFtIHdpbGwgZG8uDQpBc2tpbmcgSTJSUyB0 byBzdGFsbCB1bnRpbCB0aW1lIGNhbiBiZSBkZWRpY2F0ZWQgaXNuJ3QgYXBwcm9wcmlhdGUuDQoN Ck5vciBpcyBub3QgYWRkcmVzc2luZyBjb21tZW50cyBvbiBXRyBkcmFmdHPigKYNCg0KQWNlZQ0K DQoNCg0KUmVnYXJkcywNCkFsaWENCg0KDQoNCk9uIFR1ZSwgTm92IDI0LCAyMDE1IGF0IDg6MzQg QU0sIEFjZWUgTGluZGVtIChhY2VlKSA8YWNlZUBjaXNjby5jb208bWFpbHRvOmFjZWVAY2lzY28u Y29tPj4gd3JvdGU6DQpGcm9tOiBTdXNhbiBIYXJlcyA8c2hhcmVzQG5kemguY29tPG1haWx0bzpz aGFyZXNAbmR6aC5jb20+Pg0KRGF0ZTogTW9uZGF5LCBOb3ZlbWJlciAyMywgMjAxNSBhdCA5OjU3 IFBNDQpUbzogQWNlZSBMaW5kZW0gPGFjZWVAY2lzY28uY29tPG1haWx0bzphY2VlQGNpc2NvLmNv bT4+LCAiaTJyc0BpZXRmLm9yZzxtYWlsdG86aTJyc0BpZXRmLm9yZz4iIDxpMnJzQGlldGYub3Jn PG1haWx0bzppMnJzQGlldGYub3JnPj4NCkNjOiBBbGlhIEF0bGFzIDxha2F0bGFzQGdtYWlsLmNv bTxtYWlsdG86YWthdGxhc0BnbWFpbC5jb20+PiwgSmVmZiBIYWFzIDxqaGFhc0BwZnJjLm9yZzxt YWlsdG86amhhYXNAcGZyYy5vcmc+PiwgSmVmZiBUYW50c3VyYSA8amVmZi50YW50c3VyYUBlcmlj c3Nvbi5jb208bWFpbHRvOmplZmYudGFudHN1cmFAZXJpY3Nzb24uY29tPj4NClN1YmplY3Q6IFJF OiBbaTJyc10gRlc6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtaTJycy1yaWItZGF0YS1tb2RlbC0w NC50eHQNCg0KQWNlZToNCg0KSXMgeW91ciBpbnB1dCBpbmRpdmlkdWFsIGlucHV0IG9yIGlucHV0 IGZyb20gdGhlIHJvdXRpbmcgYXJjaGl0ZWN0dXJlIGZvciB5YW5nIG1vZGVscz8NCg0KSW5kaXZp ZHVhbC4NCg0KDQoNCjxJMlJTIGNoYWlyIGhhdCBvbj4NCg0KVGhlIHJvdXRpbmcgYXJjaGl0ZWN0 dXJlIGZvciB5YW5nIG1vZGVscyBpcyBpbmNvbXBsZXRlIHdpdGhvdXQgdGhlIGNvbnNpZGVyYXRp b24gb2YgdGhlIEkyUlMgZXBoZW1lcmFsIHN0YXRlIGFuZCBJMlJTIGFyY2hpdGVjdHVyZS4gIEFz a2luZyB0aGUgSTJSUyBXRyB0byBjaGFuZ2UgYSBkb2N1bWVudCB0aGF0IGlzIGluIFdHIExDIGJh c2VkIG9uIGFuIGluY29tcGxldGUgYXJjaGl0ZWN0dXJhbCBkb2N1bWVudCBpcyBub3QgcmVhc29u YWJsZS4NCg0KTXkgY29tbWVudCB3aXRoIHJlc3BlY3QgdG8gdHVubmVsIHByb3Zpc2lvbmluZyBp cyBub3QgYmFzZWQgb24gYW55IGFyY2hpdGVjdHVyZSBkb2N1bWVudC4NCg0KDQpBbiBhbGlnbm1l bnQgYmV0d2VlbiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW5l dG1vZC1yb3V0aW5nLWNmZy8gd2l0aG91dCB0aGUgY29uc2lkZXJhdGlvbiBvZiB0aGUgSTJSUyBl cGhlbWVyYWwgc3RhdGUgaXMgYW4gaW5jb21wbGV0ZSBhbGlnbm1lbnQgYW5kIGEgcHJvYmxlbWF0 aWMgIGFwcHJvYWNoIGZvciBJMlJTIFdH4oCZcyBlZmZvcnRzLg0KDQpJMlJTIG1vZGVscyBzaG91 bGQgYXVnbWVudCB0aGUgYmFzZSBtb2RlbHMgd2l0aCBlcGhlbWVyYWwgc3RhdGUuDQoNCg0KDQpJ biBhIHZvbHVudGVlciBvcmdhbml6YXRpb24sIGVhY2ggcGVyc29uIGhhcyB0aGUgcmlnaHQgdG8g bWFrZXMgY2hvaWNlcyBpbiB3aGF0IHRoZXkgaGF2ZSB0aW1lIHRvIGRvLiAgIElmIHlvdSBkbyBu b3QgaGF2ZSBiYW5kd2lkdGggdG8gcHJvdmlkZSBhbiBhZGVxdWF0ZSByb3V0aW5nIGFyY2hpdGVj dHVyZSBmb3IgeWFuZyBtb2RlbHMgdGhhdCBjb25zaWRlcnMgZXBoZW1lcmFsIHN0YXRlIG9yIGl0 cyBuZWVkcywgdGhhdCBpcyB5b3VyIGNob2ljZS4gIFVubGVzcyB5b3UgaGF2ZSBhIGNvbmNyZXRl IHByb3Bvc2FsIGZvciB0aGUgZXBoZW1lcmFsIHN0YXRlIHRoYXQgY292ZXJzIEkyUlMgUklCIGFu ZCBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW5ldG1vZC1yb3V0 aW5nLWNmZy8sIHRoZSBJMlJTIFdHIExDIHdpbGwgYmUgY2xvc2VkIGFmdGVyIDIgd2VlayAoMTEv MjMg4oCTIDEyLzcpIFdHIHJldmlldyBvZiB0aGUgaW4gZHJhZnQtaWV0Zi1pMnJzLXJpYi1kYXRh LW1vZGVsLTA0LnR4dC4NCg0KV2UgaGF2ZSBwcm9wb3NlZCB0dW5uZWwgbW9kZWxzLCBkcmFmdC1p ZXRmLW5ldG1vZC1yb3V0aW5nLWNmZyBpcyBub3QgbWVhbnQgdG8gc3VwcGxhbnQgdGhlbS4gQlRX LCB3ZSBkb27igJl0IHBsYW4gdG8gdXBkYXRlIGRyYWZ0LWlldGYtaTJycy1yaWItZGF0YS1tb2Rl bC0wNC50eHQuIFVwZGF0ZXMgYmFzZWQgb24gSTJSUyB3aWxsIGJlIGluIHRoZSBhIG5leHQtaG9w IGF1Z21lbnRhdGlvbiBkcmFmdCB0aGF0IGV4dGVuZHMgZHJhZnQtaWV0Zi1uZXRtb2QtcnRnLWNm Zy4NCg0KDQoNClBsZWFzZSByZW1lbWJlciB0aGF0IHRoZSBJMlJTIFJJQiBtb2RlbCBoYXMgdHdv IHBhcnRzOiAgSTJSUyBJbmZvcm1hdGlvbmFsIE1vZGVsIGFuZCBJMlJTIERhdGEgTW9kZWwuICBU aGUgSTJSUyBJbmZvcm1hdGlvbmFsIE1vZGVsIGFuZCB0aGUgSTJSUyBEYXRhIE1vZGVsIGhhdmUg ZGVzY3JpcHRpb25zIG9uIHRoZSBzb2Z0IHR1bm5lbCBwcm92aXNpb25pbmcgYXMgbWVjaGFuaXNt cy4gIFF1ZXN0aW9ucyBhdCB0aGlzIHBvaW50IG11c3QgZGVtb25zdHJhdGUgYSBrbm93bGVkZ2Ug b2YgdGhlc2UgZG9jdW1lbnRzIG9yIHN1Z2dlc3Qgc3BlY2lmaWMgY2hhbmdlcyB0byB0aGUgZG9j dW1lbnRzLiAgIElmIHlvdSB3aXNoIHRvIHJhaXNlIHRoZSBmb2xsb3dpbmcgcXVlc3Rpb25zLCBw bGVhc2UgZG8gdGhpcyBpbiBsaWdodCBvZiBzcGVjaWZpYyBzZWN0aW9ucyB0aGF0IGluY2x1ZGUg Ym90aCB0aGUgSTJSUyBJbmZvcm1hdGlvbmFsIE1vZGVsLCB0aGUgSTJSUyBEYXRhIE1vZGVsLCBh bmQgSTJSUyBhcmNoaXRlY3R1cmUuDQoNCg0KYSkgICAgICBJMlJTIHR1bm5lbHMgbXVzdCBpbmNs dWRlIGFkZGl0aW9ucyBiZXlvbmQgZW5jYXBzdWxhdGlvbiwNCg0KYikgICAgICBXaHkgdGhlIEky UlMgSW5mb3JtYXRpb25hbCBNb2RlbCBhbmQgdGhlIEkyUlMgRGF0YSBNb2RlbCBkbyBub3QgcHJv dmlkZSB0aGUgc29mdCB0dW5uZWwgcHJvdmlzaW9uaW5nIG9yIGRlc2NyaWJlIHRoZSBzcGVjaWZp Y3Mgb2YgdGhpcyBwcm92aXNpb24/DQoNClRoZSBJMlJTIEluZm9ybWF0aW9uYWwgTW9kZWwgaGFz IGV4YW1wbGVzIGZvciB0aGVzZSB0dW5uZWxzLiAgWW91IGFyZSB3ZWxjb21lIHRvIG1ha2UgcHJv cG9zYWwgZm9yIHNwZWNpZmljIGNoYW5nZXMgdG8gdGhlIEkyUlMgSW5mb3JtYXRpb25hbCBNb2Rl bCBvciB0aGUgSTJSUyBEYXRhIE1vZGVsLiAgVGhlIEkyUlMgSW5mb3JtYXRpb25hbCBNb2RlbCBo YXMgY29tcGxldGVkIFdHIExDIHNvIHRoZSBiYXIgZm9yIHN1YnN0YW50aXZlIGNvbW1lbnRzIGlz IGhpZ2guDQoNCkkgZG9u4oCZdCBiZWxpZXZlIHRoaXMgZXhjZXJwdCBmcm9tIHRoZSBSSUIgaW5m b3JtYXRpb24gbW9kZWxzIGRlc2NyaWJlcyBzb2Z0IHR1bm5lbCBwcm92aXNpb25pbmcgZm9yIGVh Y2ggb2YgdGhlIHR1bm5lbHMgcHJvcG9zZWQgaW4gdGhlIFJJQiBkYXRhIG1vZGVsOg0KDQo3LjIu MS4gIFR1bm5lbCBuZXh0aG9wcw0KDQogICBBIHR1bm5lbCBuZXh0aG9wIHBvaW50cyB0byBhIHR1 bm5lbCBvZiBzb21lIGtpbmQuICBUcmFmZmljIHRoYXQgZ29lcw0KICAgb3ZlciB0aGUgdHVubmVs IGdldHMgZW5jYXBzdWxhdGVkIHdpdGggdGhlIHR1bm5lbCBlbmNhcC4gIFR1bm5lbA0KICAgbmV4 dGhvcHMgYXJlIHVzZWZ1bCBmb3IgYWJzdHJhY3Rpbmcgb3V0IGRldGFpbHMgb2YgdGhlIG5ldHdv cmssIGJ5DQogICBoYXZpbmcgdGhlIHRyYWZmaWMgc2VhbWxlc3NseSByb3V0ZSBiZXR3ZWVuIG5l dHdvcmsgZWRnZXMuICBBdCB0aGUNCiAgIGVuZCBvZiBhIHR1bm5lbCwgdGhlIHR1bm5lbCB3aWxs IGdldCBkZWNhcHN1bGF0ZWQuICBUaHVzIHRoZSBncmFtbWFyDQogICBzdXBwb3J0cyB0d28ga2lu ZHMgb2Ygb3BlcmF0aW9ucywgb25lIGZvciBlbmNhcCBhbmQgYW5vdGhlciBmb3INCiAgIGRlY2Fw Lg0KDQpBY2VlDQoNCg0KDQo8STJSUyBjaGFpciBoYXQgb2ZmPg0KDQpDaGVlcnMsDQoNClN1ZSBI YXJlcw0KDQpGcm9tOiBpMnJzIFttYWlsdG86aTJycy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgQWNlZSBMaW5kZW0gKGFjZWUpDQpTZW50OiBNb25kYXksIE5vdmVtYmVyIDIzLCAyMDE1 IDc6MzAgUE0NClRvOiBTdXNhbiBIYXJlczsgaTJyc0BpZXRmLm9yZzxtYWlsdG86aTJyc0BpZXRm Lm9yZz4NClN1YmplY3Q6IFJlOiBbaTJyc10gRlc6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtaTJy cy1yaWItZGF0YS1tb2RlbC0wNC50eHQNCg0KU3VlLA0KDQpGcm9tOiBpMnJzIDxpMnJzLWJvdW5j ZXNAaWV0Zi5vcmc8bWFpbHRvOmkycnMtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBT dXNhbiBIYXJlcyA8c2hhcmVzQG5kemguY29tPG1haWx0bzpzaGFyZXNAbmR6aC5jb20+Pg0KRGF0 ZTogTW9uZGF5LCBOb3ZlbWJlciAyMywgMjAxNSBhdCA1OjQ1IFBNDQpUbzogImkycnNAaWV0Zi5v cmc8bWFpbHRvOmkycnNAaWV0Zi5vcmc+IiA8aTJyc0BpZXRmLm9yZzxtYWlsdG86aTJyc0BpZXRm Lm9yZz4+DQpTdWJqZWN0OiBbaTJyc10gRlc6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtaTJycy1y aWItZGF0YS1tb2RlbC0wNC50eHQNCg0KUmVzZW5kaW5nIHRvIEkyUlMgV0cuDQoNCkZyb206IFN1 c2FuIEhhcmVzIFttYWlsdG86c2hhcmVzQG5kemguY29tXQ0KU2VudDogTW9uZGF5LCBOb3ZlbWJl ciAyMywgMjAxNSA1OjMzIFBNDQpUbzogJ0plZmYgVGFudHN1cmEnOyAnQWNlZSBMaW5kZW0gKGFj ZWUpJzsgJ01hY2ggQ2hlbic7ICdpMnJzQGlldGYub3JnPG1haWx0bzonaTJyc0BpZXRmLm9yZz4n DQpDYzogJ0plZmZyZXkgSGFhcyc7ICdBbGlhIEF0bGFzJzsgJ0Jlbm9pdCBDbGFpc2UgKGJjbGFp c2UpJw0KU3ViamVjdDogUkU6IFtpMnJzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWkycnMtcmli LWRhdGEtbW9kZWwtMDQudHh0DQoNCg0KSmVmZiBhbmQgQWNlZToNCg0KDQoNCllvdXIgc3VnZ2Vz dGVkIGNoYW5nZSBnb2VzIGFnYWluc3QgdGhlIFdHIGFkb3B0ZWQgUklCIEluZm9ybWF0aW9uIGRy YWZ0IHRoYXQgaGFzIGJlZW4gZGlzY3Vzc2VkIGZvciBvdmVyIDIgeWVhcnMuICBUaGUgaW5mb3Jt YXRpb25hbCBkcmFmdCBoYXMgYmVlbiB0aHJvdWdoIFdHIExDIGFuZCB5b3UgZGlkIG5vdCBtYWtl IGFueSBzdWdnZXN0aW9ucyBvciBjb21tZW50cyBkdXJpbmcgdGhlIFdHIExDLiAgQW55IGNoYW5n ZSBvZiB0aGlzIG1hdHRlciBpcyBub3Qgc2ltcGx5IHNvbWV0aGluZyB5b3UgaW5kaWNhdGUgdG8g dGhlIGF1dGhvcnMsIGJ1dCBuZWVkcyB0byBiZSBkaXNjdXNzZWQgb24gdGhlIFdHIGFzIGEgZGly ZWN0aW9uIGNoYW5nZSBmb3IgdGhlIFJJQiBJTS9ETSBtb2RlbHMuDQoNCkluZGVwZW5kZW50IG9m IHRoZSBJMlJTIGVmZm9ydHMsIG1pbGVzdG9uZXMsIGFuZCBwcm9jZXNzZXMsIEkgdGhpbmsgd2Ug bmVlZCB0byBhZGRyZXNzIHdoZXRoZXIgcHJvdmlzaW9uaW5nIGFsbCB0aGVzZSB0dW5uZWxzIHZp YSBSSUIgaW5zdGFsbGF0aW9uIGlzICBhcHByb3ByaWF0ZSBhbmQsIGFkZGl0aW9uYWxseSwgY29u c2lzdGVudCB3aXRoIG90aGVyIFdHIFlBTkcgbW9kZWxzLiBJbiBtYW55IGNhc2VzLCBpdCB3b3Vs ZCBzZWVtIHRoZXJlIGFyZSB0dW5uZWwgYXR0cmlidXRlcyBvdGhlciB0aGFuIHRoZSBlbmNhcHMg dGhhdCBuZWVkIHRvIGJlIHByb3Zpc2lvbmVkLiBBdCBhIG1pbmltdW0sIEkgdGhpbmsgeW914oCZ ZCBuZWVkIHRvIGVpdGhlciByZWZlcmVuY2UgYW4gUkZDIGRlc2NyaWJpbmcgc29mdCB0dW5uZWwg cHJvdmlzaW9uaW5nIG9yIGRlc2NyaWJlIHRoZSBzcGVjaWZpY3Mgb2YgdGhpcyBwcm92aXNpb25p bmcuDQoNCg0KDQoNClByaW9yIHRvIG1vdmluZyB0aGlzIGNoYW5nZSB0aHJvdWdoIFdHIGFkb3B0 aW9uIGN5Y2xlLCB0aGUgcm91dGluZyBhcmNoaXRlY3R1cmFsIHRlYW0gbmVlZHMgdG8gaGF2ZTog YSkgY29uY3JldGUgcHJvcG9zYWwgZm9yIHRoZSBlcGhlbWVyYWwgc3RhdGUgdGhhdCBjb3ZlcnMg STJSUyBSSUIgYW5kIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt bmV0bW9kLXJvdXRpbmctY2ZnLyAgYW5kICBiKSBJIHJlcXVlc3RlZCB0aGlzIGlucHV0IG9mIEFj ZWUgTGluZGVtIGFzIGEgcmVwcmVzZW50YXRpdmUgb2YgdGhlIHJvdXRpbmcgYXJjaGl0ZWN0dXJl IHRlYW0uDQoNClRoZSAgaWRlbnRpZmljYXRpb24gb2YgdGhpcyBwcm9ibGVtIHdpdGggdHVubmVs IHByb3Zpc2lvbmluZyBpcyBhIGRpcmVjdCBvdXRjb21lIG9mIHRoaXMgZWZmb3J0Lg0KDQoNCg0K DQoNCg0KSSB3aWxsIGJlIGdsYWQgdG8gd29yayB3aXRoIHlvdSBvbiBhIGNvbmNyZXRlIHByb3Bv c2FsIHRoYXQgeW91IGNhbiBzZW5kIHRvIHRoZSBlbWFpbCBsaXN0IGFuZCBwcmVzZW50IGF0IHRo ZSBJMlJTIGludGVyaW0gbWVldGluZyBvbiAxMi8xNi8yMDE1ICgxMC0xMTozMGFtIEVUKS4NCg0K SSB3aWxsIGNvbnRpbnVlIHRvIHdvcmsgb24gaWV0Zi1yb3V0aW5nIGFsaWdubWVudCBidXQgZG9u 4oCZdCBoYXZlIHRoZSBiYW5kd2lkdGggZm9yIHRoZSBhYm92ZS4NCg0KQWNlZQ0KDQoNCg0KDQoN Cg0KDQogU3VlIEhhcmVzDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog aTJycyBbbWFpbHRvOmkycnMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEplZmYgVGFu dHN1cmENClNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMjMsIDIwMTUgNDoyNyBQTQ0KVG86IEFjZWUg TGluZGVtIChhY2VlKTsgTWFjaCBDaGVuOyBpMnJzQGlldGYub3JnPG1haWx0bzppMnJzQGlldGYu b3JnPg0KU3ViamVjdDogUmU6IFtpMnJzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWkycnMtcmli LWRhdGEtbW9kZWwtMDQudHh0DQoNCg0KDQpIaSBNYWNoLA0KDQoNCg0KSSBhZ3JlZSB3aXRoIEFj ZWXigJlzIGNvbW1lbnRzIGFuZCB3b3VsZCBlbmNvdXJhZ2UgeW91IHRvIHVzZSBnZW5lcmljL2V4 aXN0aW5nIHR1bm5lbCBtb2RlbChzKSwgcGxlYXNlIHNlZSBjb21tZW50cyBwcm92aWRlZCBkdXJp bmcgUlRHV0cgbWVldGluZyBpbiBZb2tvaGFtYS4NCg0KVGhlcmUgYXJlIGFscmVhZHkgdG9vIG1h bnksIHdlIG5lZWQgdG8gcmF0aW9uYWxpemUgdGhpcyB3b3JrLg0KDQoNCg0KVGhpcyBpcyB3aGF0 IGhhcyBiZWVuIGRpc2N1c3NlZCBpbiBZb2tvaGFtYSwgUm9iaW4gcHJlc2VudGVkDQoNCg0KDQot LSBkcmFmdC1saS1ydGd3Zy11dHVubmVsLXlhbmcNCg0KICAgLS0gZHJhZnQtbGktcnRnd2ctdHVu bmVsLXBvbGljeS15YW5nDQoNCiAgIC0tIGRyYWZ0LXd3ei1uZXRtb2QteWFuZy10dW5uZWwtY2Zn DQoNCiAgIC0tIGRyYWZ0LXpoZW5nLWludGFyZWEtZ3JlLXlhbmcNCg0KICAgLS0gZHJhZnQtbGl1 LWludGFyZWEtZ3JlLXR1bm5lbC15YW5nDQoNCiAgIC0tIGRyYWZ0LWxpdS1pbnRhcmVhLWlwaXB2 NC10dW5uZWwteWFuZw0KDQoNCg0KQ2hlZXJzLA0KDQpKZWZmDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCk9uIDExLzIzLzE1LCAxMTo1NiwgImkycnMgb24gYmVoYWxmIG9mIEFjZWUgTGluZGVt IChhY2VlKSIgPGkycnMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgYWNlZUBjaXNjby5j b208bWFpbHRvOmkycnMtYm91bmNlc0BpZXRmLm9yZyUyMG9uJTIwYmVoYWxmJTIwb2YlMjBhY2Vl QGNpc2NvLmNvbT4+IHdyb3RlOg0KDQoNCg0KPkhpIE1hY2gsDQoNCj4NCg0KPknigJltIGxvb2tp bmcgYXQgZHJhZnQtaWV0Zi1pMnJzLXJpYi1kYXRhLW1vZGVsLTA0LnR4dCBhbmQgaXQgc3RpbGwN Cg0KPmluY2x1ZGVzIGFsbCB0aGUgdHVubmVsIGVuY2Fwcy4gSSBrbm93IHlvdSByZWNlaXZlZCBz ZXZlcmFsIGNvbW1lbnRzDQoNCj50aGF0IHRob3NlIHNob3VsZCBiZSBpbiB0aGUgdHVubmVsIG1v ZGVsKHMpIGFuZCB0aGlzIEkyUlMgUklCIG1vZGVsDQoNCj5zaG91bGQgbWVyZWx5IHJlZmVyZW5j ZSBhbiBpbXBvcnRlZCB0dW5uZWwgYWJzdHJhY3Rpb24uIEhvdyBhcmUgeW91DQoNCj5nb2luZyB0 byBhZGRyZXNzIHRoaXM/IEl0IHNlZW1lZCB0aGF0IHRoZSBjb25zZW5zdXMgKGFuZCBhbiBvcGlu aW9uDQoNCj50aGF0IEkgc2hhcmUpIHdhcyB0aGF0IHRoaXMgbW9kZWwgc2hvdWxkIG5vdCBhdHRl bXB0IHRvIGdlbmVyaWNhbGx5DQoNCj5jcmVhdGVkIHR1bm5lbHMgdmlhIFJJQi9GSUIgZW50cmll cy4NCg0KPlRoYW5rcywNCg0KPkFjZWUNCg0KPg0KDQo+T24gMTEvMjMvMTUsIDI6MjMgQU0sICJp MnJzIG9uIGJlaGFsZiBvZiBNYWNoIENoZW4iDQoNCj48aTJycy1ib3VuY2VzQGlldGYub3JnIG9u IGJlaGFsZiBvZiBtYWNoLmNoZW5AaHVhd2VpLmNvbTxtYWlsdG86aTJycy1ib3VuY2VzQGlldGYu b3JnJTIwb24lMjBiZWhhbGYlMjBvZiUyMG1hY2guY2hlbkBodWF3ZWkuY29tPj4gd3JvdGU6DQoN Cj4NCg0KPj5IaSwNCg0KPj4NCg0KPj5XZSBqdXN0IHVwbG9hZGVkIGFuIHVwZGF0ZSB0aGF0IGFk ZHJlc3NlcyB0aGUgY29tbWVudHMgcmVjZWl2ZWQNCg0KPj4oaW5jbHVkZSBvbmxpbmUgYW5kIG9m ZmxpbmUpIHJlY2VudGx5LiBQbGVhc2UgcmV2aWV3IHRoZSBkcmFmdCBhbmQgY29tbWVudCENCg0K Pj4NCg0KPj5UaGFua3MsDQoNCj4+TWFjaA0KDQo+Pg0KDQo+Pj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCg0KPj4+IEZyb206IGkycnMgW21haWx0bzppMnJzLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZg0KDQo+Pj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZz4NCg0KPj4+IFNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMjMsIDIw MTUgMzoxNiBQTQ0KDQo+Pj4gVG86IGktZC1hbm5vdW5jZUBpZXRmLm9yZzxtYWlsdG86aS1kLWFu bm91bmNlQGlldGYub3JnPg0KDQo+Pj4gQ2M6IGkycnNAaWV0Zi5vcmc8bWFpbHRvOmkycnNAaWV0 Zi5vcmc+DQoNCj4+PiBTdWJqZWN0OiBbaTJyc10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1pMnJz LXJpYi1kYXRhLW1vZGVsLTA0LnR4dA0KDQo+Pj4NCg0KPj4+DQoNCj4+PiBBIE5ldyBJbnRlcm5l dC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMNCg0K Pj4+ZGlyZWN0b3JpZXMuDQoNCj4+PiAgVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUg SW50ZXJmYWNlIHRvIHRoZSBSb3V0aW5nIFN5c3RlbQ0KDQo+Pj5Xb3JraW5nIEdyb3VwICBvZiB0 aGUgSUVURi4NCg0KPj4+DQoNCj4+PiAgICAgICAgIFRpdGxlICAgICAgICAgICA6IEEgWUFORyBE YXRhIE1vZGVsIGZvciBSb3V0aW5nIEluZm9ybWF0aW9uIEJhc2UNCg0KPj4+IChSSUIpDQoNCj4+ PiAgICAgICAgIEF1dGhvcnMgICAgICAgICA6IExpeGluZyBXYW5nDQoNCj4+PiAgICAgICAgICAg ICAgICAgICAgICAgICAgIEhhcmloYXJhbiBBbmFudGhha3Jpc2huYW4NCg0KPj4+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgTWFjaChHdW95aSkgQ2hlbg0KDQo+Pj4gICAgICAgICAgICAgICAg ICAgICAgICAgICBBbWl0IERhc3MNCg0KPj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgU3Jp Z2FuZXNoIEtpbmkNCg0KPj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgTml0aW4gQmFoYWR1 cg0KDQo+Pj4gICAgICAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtaTJycy1yaWItZGF0 YS1tb2RlbC0wNC50eHQNCg0KPj4+ICAgICAgICBQYWdlcyAgICAgICAgICAgOiA2NQ0KDQo+Pj4g ICAgICAgIERhdGUgICAgICAgICAgICA6IDIwMTUtMTEtMjINCg0KPj4+DQoNCj4+PiBBYnN0cmFj dDoNCg0KPj4+ICAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIFlBTkcgZGF0YSBtb2RlbCBmb3Ig Um91dGluZyBJbmZvcm1hdGlvbiBCYXNlDQoNCj4+PiAgICAoUklCKSB0aGF0IGFsaWducyB3aXRo IHRoZSBJMlJTIFJJQiBpbmZvcm1hdGlvbiBtb2RlbC4NCg0KPj4+DQoNCj4+Pg0KDQo+Pj4NCg0K Pj4+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0K DQo+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJzLXJp Yi1kYXRhLW1vZGVsLw0KDQo+Pj4NCg0KPj4+IFRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNp b24gYXZhaWxhYmxlIGF0Og0KDQo+Pj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtaTJycy1yaWItZGF0YS1tb2RlbC0wNA0KDQo+Pj4NCg0KPj4+IEEgZGlmZiBmcm9tIHRo ZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCg0KPj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWkycnMtcmliLWRhdGEtbW9kZWwtMDQNCg0K Pj4+DQoNCj4+Pg0KDQo+Pj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBv ZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCg0KPj4+c3VibWlzc2lvbiAgdW50aWwgdGhlIGh0 bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdA0KDQo+Pj50b29scy5pZXRm Lm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmc+Lg0KDQo+Pj4NCg0KPj4+IEludGVybmV0LURyYWZ0 cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCg0KPj4+IGZ0cDovL2Z0 cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQoNCj4+Pg0KDQo+Pj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KPj4+IGkycnMgbWFpbGluZyBsaXN0 DQoNCj4+PiBpMnJzQGlldGYub3JnPG1haWx0bzppMnJzQGlldGYub3JnPg0KDQo+Pj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMnJzDQoNCj4+DQoNCj4+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KPj5pMnJzIG1haWxpbmcg bGlzdA0KDQo+PmkycnNAaWV0Zi5vcmc8bWFpbHRvOmkycnNAaWV0Zi5vcmc+DQoNCj4+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMnJzDQoNCj4NCg0KPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCj5pMnJzIG1haWxpbmcgbGlz dA0KDQo+aTJyc0BpZXRmLm9yZzxtYWlsdG86aTJyc0BpZXRmLm9yZz4NCg0KPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJycw0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KDQppMnJzIG1haWxpbmcgbGlzdA0KDQppMnJzQGll dGYub3JnPG1haWx0bzppMnJzQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2kycnMNCg0K --_000_D27A04393F032aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <01CD13175E90744FA9FC6F5698CA4D01@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0K QWxpYSwmbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxicj4NCjwv ZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIiBzdHlsZT0iY29sb3I6IHJnYigw LCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRw eDsiPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRl eHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBC T1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVG VDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlk OyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0 eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+QWxpYSBBdGxhcyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmFrYXRsYXNAZ21haWwuY29tIj5ha2F0bGFzQGdtYWlsLmNvbTwvYT4mZ3Q7PGJy Pg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5UdWVzZGF5LCBO b3ZlbWJlciAyNCwgMjAxNSBhdCAxMjowOCBQTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdo dDpib2xkIj5UbzogPC9zcGFuPkFjZWUgTGluZGVtICZsdDs8YSBocmVmPSJtYWlsdG86YWNlZUBj aXNjby5jb20iPmFjZWVAY2lzY28uY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13 ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj5TdXNhbiBIYXJlcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNo YXJlc0BuZHpoLmNvbSI+c2hhcmVzQG5kemguY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1h aWx0bzppMnJzQGlldGYub3JnIj5pMnJzQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOmkycnNAaWV0Zi5vcmciPmkycnNAaWV0Zi5vcmc8L2E+Jmd0OywgSmVmZiBIYWFzICZs dDs8YSBocmVmPSJtYWlsdG86amhhYXNAcGZyYy5vcmciPmpoYWFzQHBmcmMub3JnPC9hPiZndDss DQogSmVmZiBUYW50c3VyYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmplZmYudGFudHN1cmFAZXJpY3Nz b24uY29tIj5qZWZmLnRhbnRzdXJhQGVyaWNzc29uLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5 bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogW2kycnNdIEZXOiBJLUQg QWN0aW9uOiBkcmFmdC1pZXRmLWkycnMtcmliLWRhdGEtbW9kZWwtMDQudHh0PGJyPg0KPC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVU SU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURE SU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJs dHIiPkFjZWUsDQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5BcyBTdWUgaGFzIHNhaWQsIHRoZSBJ MlJTIEluZm8gTW9kZWwgaGFzIHBhc3NlZCBXR0xDIGFuZCBpcyBqdXN0IHdhaXRpbmcgZm9yIHRo ZSBETSB0byBiZSBkb25lIGluIG9yZGVyIHRvIHByb2dyZXNzLiZuYnNwOyBPYnZpb3VzbHksIHN1 YnN0YW50aWFsIHRlY2huaWNhbCBjb25jZXJucyBhcmUgYWx3YXlzIHdlbGNvbWUgLSB0aGVyZSdz IGEgbG9uZyB3YXkgYmV0d2VlbiBXR0xDIGFuZCBmaW5hbCBJRVNHIGFwcHJvdmFsOyBJIGRvIG5v dCB0aGluaw0KIHRoYXQgeW91IGhhdmUgY2xlYXJseSBkZXNjcmliZWQgeW91ciB0ZWNobmljYWwg Y29uY2VybnMuJm5ic3A7IEFyZSB5b3UgbWl4aW5nIHVwIHVzaW5nIGEgdHVubmVsIGZvciBmb3J3 YXJkaW5nIHdpdGggcHJvdmlzaW9uaW5nIHRoZSB0dW5uZWw/PyAmbmJzcDs8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjxkaXYgc3R5bGU9ImNv bG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250 LXNpemU6IDE0cHg7Ij4NCjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNU SU9OIiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09L X0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNv bGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2Pg0KPGRpdj4NCjxk aXYgZGlyPSJsdHIiPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhlIEkyUlMgUklCIG1vZGVs IGlzIG5vdCBmb3IgcHJvdmlzaW9uaW5nIHR1bm5lbHMuJm5ic3A7IEl0IGlzIGludGVuZGVkIHNv IHRoYXQgdHJhZmZpYyBjYW4gYmUgZm9yd2FyZGVkIHByb3Blcmx5LCByZWdhcmRsZXNzIG9mIHRo ZSBhYnN0cmFjdGlvbi4mbmJzcDsgRm9yIGluc3RhbmNlLCB3aXRoIE1QTFMsIGEgcGFja2V0IGNv dWxkIGJlIHNlbnQgb3V0IHdpdGggYW4gYXJiaXRyYXJ5IGxhYmVsIG9yIGxhYmVsIHN0YWNrLCBh IHBhY2tldCBjb3VsZCBmb2xsb3cNCiBhbiBMU1AsIG9yIGEgcGFja2V0IGNvdWxkIGZvbGxvdyBh IHR1bm5lbC4gJm5ic3A7IEJ5IHByb3ZpZGluZyB0aGUgYWJpbGl0eSB0byBmb3J3YXJkIHZpYSB0 aGVzZSBkaWZmZXJlbnQgbGF5ZXJzIG9mIGFic3RyYWN0aW9uLCB0aGUgUklCIG1vZGVsIGFsbG93 cyBmb3J3YXJkaW5nIHRvIG9jY3VyIGNvcnJlY3RseSBldmVuIHdoZW4gYSB0dW5uZWwgb3IgTFNQ IGNoYW5nZXMgLSBqdXN0IGxpa2UgYSBuZXh0LWhvcCBjYW4gYmUgc3BlY2lmaWVkIHRvIGZvcndh cmQNCiBsaWtlIGEgZGlmZmVyZW50IHByZWZpeCBhbmQgdGhlbiBmb2xsb3dzIHRoYXQgcHJlZml4 LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSBjZXJ0YWlubHkgZG8gbm90IHNlZSB0 aGUgSTJSUyBSSUIgbW9kZWwgYXMgY3JlYXRpbmcgdHVubmVscyAtIGJ1dCBtZXJlbHkgYmVpbmcg YWJsZSB0byB1c2Ugb25lcyB0aGF0IGFscmVhZHkgZXhpc3QuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdi KDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAx NHB4OyI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCkkgYmVs aWV2ZSB0aGUgaW50ZW5zaW9uIG9mIHRoZSBtb2RlbCBpcyBjbGVhcmx5IHRvIGR5bmFtaWNhbGx5 IGNyZWF0ZSB0aGUgdHVubmVscy4gJm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdi KDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAx NHB4OyI+DQo8YnI+DQo8L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlm Ij4mbmJzcDsgJm5ic3A7VHVubmVsIG5leHRob3BzIGFsbG93IGFuIGV4dGVybmFsIGVudGl0eSB0 byBwcm9ncmFtIHN0YXRpYyB0dW5uZWw8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNh bGlicmksc2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO2hlYWRlcnMuICZuYnNwO1RoZXJlIGNhbiBi ZSBjYXNlcyB3aGVyZSB0aGUgcmVtb3RlIHR1bm5lbCBlbmQtcG9pbnQgZG9lczwvZm9udD48L2Rp dj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7bm90 IHN1cHBvcnQgZHluYW1pYyBzaWduYWxpbmcgKGUuZy4gbm8gTERQIHN1cHBvcnQgb24gYSBob3N0 KSBhbmQgaW48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJp ZiI+Jm5ic3A7ICZuYnNwO3Rob3NlIGNhc2VzIHRoZSBleHRlcm5hbCBlbnRpdHkgbWlnaHQgd2Fu dCB0byBwcm9ncmFtIHRoZSB0dW5uZWw8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNh bGlicmksc2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO2hlYWRlciBvbiBib3RoIGVuZHMgb2YgdGhl IHR1bm5lbC4gJm5ic3A7VGhlIHR1bm5lbCBuZXh0aG9wIGlzIGtlcHQ8L2ZvbnQ+PC9kaXY+DQo8 ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO2dlbmVyaWMg d2l0aCBzcGVjaWZpY2F0aW9ucyBwcm92aWRlZCBmb3Igc29tZSBjb21tb25seSB1c2VkIHR1bm5l bHMuPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPiZu YnNwOyAmbmJzcDtJdCBpcyBleHBlY3RlZCB0aGF0IHRoZSBkYXRhLW1vZGVsIHdpbGwgbW9kZWwg dGhlc2UgdHVubmVsIHR5cGVzIHdpdGg8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNh bGlicmksc2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO2NvbXBsZXRlIGFjY3VyYWN5LjwvZm9udD48 L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxicj4NCjwvZGl2Pg0KPHNwYW4g aWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGJsb2Nr cXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JE RVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1 OyI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk aXY+Tm93LCBpZiB5b3VyIG9iamVjdGlvbiBpcyB0aGF0IHRoZSBJMlJTIFJJQiBtb2RlbCBzaG91 bGQgdXNlIGEgY29tbW9uIGdyb3VwaW5nIHRoYXQgZGVzY3JpYmVzIGFsbCB0eXBlcyBvZiB0dW5u ZWxzLCBJIGhhdmUgeWV0IHRvIHNlZSBvbmUuJm5ic3A7IFRoZSBlZmZvcnRzIHRvIHByb3ZpZGUg WUFORyBtb2RlbHMgZm9yIHR1bm5lbHMgYXJlIHN0aWxsIHF1aXRlIGltbWF0dXJlLjwvZGl2Pg0K PGRpdj5EZXNjcmliaW5nIHdoYXQgdHlwZXMgb2YgZ3JvdXBpbmdzIHdvdWxkIGJlIHVzZWZ1bCBp cyB0aGUgdHlwZSBvZiB3b3JrIHRoYXQgSSBob3BlIHRoZSBkZXNpZ24gdGVhbSB3aWxsIGRvLjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPjxzcGFu IGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxibG9j a3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9S REVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAg NTsiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXY+QXNraW5nIEkyUlMgdG8g c3RhbGwgdW50aWwgdGltZSBjYW4gYmUgZGVkaWNhdGVkIGlzbid0IGFwcHJvcHJpYXRlLjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxkaXY+Tm9yIGlzIG5vdCBhZGRyZXNzaW5nIGNvbW1lbnRzIG9uIFdHIGRy YWZ0c+KApiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QWNlZSZuYnNwOzwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xL X1NSQ19CT0RZX1NFQ1RJT04iIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8YmxvY2txdW90ZSBp ZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZU OiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxk aXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5SZWdh cmRzLDwvZGl2Pg0KPGRpdj5BbGlhPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj4NCjxkaXYgY2xh c3M9ImdtYWlsX3F1b3RlIj5PbiBUdWUsIE5vdiAyNCwgMjAxNSBhdCA4OjM0IEFNLCBBY2VlIExp bmRlbSAoYWNlZSkgPHNwYW4gZGlyPSJsdHIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzphY2VlQGNp c2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFjZWVAY2lzY28uY29tPC9hPiZndDs8L3NwYW4+IHdy b3RlOjxicj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjow IDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0K PGRpdiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBzdHlsZT0iY29sb3I6cmdi KDAsMCwwKTtmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7Zm9udC1zaXplOjE0cHgiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2ZvbnQtc2l6ZToxMXB0O2ZvbnQtd2VpZ2h0 OmJvbGQiPkZyb206DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Zm9u dC1zaXplOjExcHQiPlN1c2FuIEhhcmVzICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnNoYXJl c0BuZHpoLmNvbSIgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Zm9udC1zaXplOjExcHQiIHRh cmdldD0iX2JsYW5rIj5zaGFyZXNAbmR6aC5jb208L2E+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OkNhbGlicmk7Zm9udC1zaXplOjExcHQiPiZndDs8L3NwYW4+PC9kaXY+DQo8c3BhbiBzdHlsZT0i Y29sb3I6cmdiKDAsMCwwKTtmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7Zm9udC1zaXpl OjE0cHgiPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtmb250LXNpemU6MTFwdDt0 ZXh0LWFsaWduOmxlZnQ7Y29sb3I6YmxhY2s7Qk9SREVSLUJPVFRPTTptZWRpdW0gbm9uZTtCT1JE RVItTEVGVDptZWRpdW0gbm9uZTtQQURESU5HLUJPVFRPTTowaW47UEFERElORy1MRUZUOjBpbjtQ QURESU5HLVJJR0hUOjBpbjtCT1JERVItVE9QOiNiNWM0ZGYgMXB0IHNvbGlkO0JPUkRFUi1SSUdI VDptZWRpdW0gbm9uZTtQQURESU5HLVRPUDozcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0 OmJvbGQiPkRhdGU6IDwvc3Bhbj5Nb25kYXksIE5vdmVtYmVyIDIzLCAyMDE1IGF0IDk6NTcgUE08 YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj5BY2VlIExpbmRl bSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFjZWVAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+YWNl ZUBjaXNjby5jb208L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmkycnNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5pMnJzQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFp bHRvOmkycnNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pMnJzQGlldGYub3JnPC9hPiZndDs8 YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj5BbGlhIEF0bGFz ICZsdDs8YSBocmVmPSJtYWlsdG86YWthdGxhc0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5h a2F0bGFzQGdtYWlsLmNvbTwvYT4mZ3Q7LCBKZWZmIEhhYXMgJmx0OzxhIGhyZWY9Im1haWx0bzpq aGFhc0BwZnJjLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmpoYWFzQHBmcmMub3JnPC9hPiZndDssIEpl ZmYgVGFudHN1cmEgJmx0OzxhIGhyZWY9Im1haWx0bzpqZWZmLnRhbnRzdXJhQGVyaWNzc29uLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmplZmYudGFudHN1cmFAZXJpY3Nzb24uY29tPC9hPiZndDs8YnI+ DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJFOiBbaTJy c10gRlc6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtaTJycy1yaWItZGF0YS1tb2RlbC0wNC50eHQ8 YnI+DQo8L2Rpdj4NCjxzcGFuIGNsYXNzPSIiPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJCT1JERVItTEVGVDojYjVjNGRmIDUgc29saWQ7UEFERElORzowIDAgMCA1O01B UkdJTjowIDAgMCA1Ij4NCjxkaXY+DQo8ZGl2IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BY2VlOiA8dT48L3U+PHU+ PC91PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SXMgeW91ciBpbnB1dCBpbmRpdmlkdWFsIGlucHV0IG9yIGlu cHV0IGZyb20gdGhlIHJvdXRpbmcgYXJjaGl0ZWN0dXJlIGZvciB5YW5nIG1vZGVscz88L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+PC9zcGFuPg0KPGRp diBzdHlsZT0iY29sb3I6cmdiKDAsMCwwKTtmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7 Zm9udC1zaXplOjE0cHgiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6cmdiKDAsMCww KTtmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7Zm9udC1zaXplOjE0cHgiPkluZGl2aWR1 YWwuJm5ic3A7PC9kaXY+DQo8c3BhbiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNvbG9yOnJnYigw LDAsMCk7Zm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxNHB4Ij48YnI+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOnJnYigwLDAsMCk7Zm9udC1mYW1pbHk6Q2FsaWJy aSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxNHB4Ij48YnI+DQo8L2Rpdj4NCjxzcGFuIHN0eWxlPSJj b2xvcjpyZ2IoMCwwLDApO2ZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjtmb250LXNpemU6 MTRweCI+DQo8YmxvY2txdW90ZSBzdHlsZT0iQk9SREVSLUxFRlQ6I2I1YzRkZiA1IHNvbGlkO1BB RERJTkc6MCAwIDAgNTtNQVJHSU46MCAwIDAgNSI+DQo8ZGl2Pg0KPGRpdiBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHU+PC91Pjx1PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+ PC91PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZsdDtJMlJTIGNoYWlyIGhhdCBvbiZndDsg PHU+PC91Pjx1PjwvdT48L3A+DQo8cD5UaGUgcm91dGluZyBhcmNoaXRlY3R1cmUgZm9yIHlhbmcg bW9kZWxzIGlzIGluY29tcGxldGUgd2l0aG91dCB0aGUgY29uc2lkZXJhdGlvbiBvZiB0aGUgSTJS UyBlcGhlbWVyYWwgc3RhdGUgYW5kIEkyUlMgYXJjaGl0ZWN0dXJlLiZuYnNwOyBBc2tpbmcgdGhl IEkyUlMgV0cgdG8gY2hhbmdlIGEgZG9jdW1lbnQgdGhhdCBpcyBpbiBXRyBMQyBiYXNlZCBvbiBh biBpbmNvbXBsZXRlIGFyY2hpdGVjdHVyYWwgZG9jdW1lbnQgaXMgbm90IHJlYXNvbmFibGUuDQog Jm5ic3A7PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFu Pg0KPGRpdiBzdHlsZT0iY29sb3I6cmdiKDAsMCwwKTtmb250LWZhbWlseTpDYWxpYnJpLHNhbnMt c2VyaWY7Zm9udC1zaXplOjE0cHgiPjxicj4NCjwvZGl2Pg0KPC9zcGFuPg0KPGRpdiBzdHlsZT0i Y29sb3I6cmdiKDAsMCwwKTtmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7Zm9udC1zaXpl OjE0cHgiPk15IGNvbW1lbnQgd2l0aCByZXNwZWN0IHRvIHR1bm5lbCBwcm92aXNpb25pbmcgaXMg bm90IGJhc2VkIG9uIGFueSBhcmNoaXRlY3R1cmUgZG9jdW1lbnQuJm5ic3A7PC9kaXY+DQo8c3Bh biBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNvbG9yOnJnYigwLDAsMCk7Zm9udC1mYW1pbHk6Q2Fs aWJyaSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxNHB4Ij48YnI+DQo8L2Rpdj4NCjxzcGFuIHN0eWxl PSJjb2xvcjpyZ2IoMCwwLDApO2ZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjtmb250LXNp emU6MTRweCI+DQo8YmxvY2txdW90ZSBzdHlsZT0iQk9SREVSLUxFRlQ6I2I1YzRkZiA1IHNvbGlk O1BBRERJTkc6MCAwIDAgNTtNQVJHSU46MCAwIDAgNSI+DQo8ZGl2Pg0KPGRpdiBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2Pg0KPHA+QW4gYWxpZ25tZW50IGJl dHdlZW4gPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0 Zi1uZXRtb2Qtcm91dGluZy1jZmcvIiB0YXJnZXQ9Il9ibGFuayI+DQo8c3BhbiBzdHlsZT0iY29s b3I6d2luZG93dGV4dCI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0 Zi1uZXRtb2Qtcm91dGluZy1jZmcvPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwO3dpdGhvdXQgdGhlIGNvbnNpZGVyYXRpb24gb2YgdGhlIEkyUlMgZXBoZW1lcmFsIHN0 YXRlIGlzIGFuIGluY29tcGxldGUgYWxpZ25tZW50IGFuZCBhIHByb2JsZW1hdGljICZuYnNwO2Fw cHJvYWNoIGZvciBJMlJTIFdH4oCZcyBlZmZvcnRzLg0KICZuYnNwOyZuYnNwOzwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8ZGl2IHN0 eWxlPSJjb2xvcjpyZ2IoMCwwLDApO2ZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjtmb250 LXNpemU6MTRweCI+PGJyPg0KPC9kaXY+DQo8L3NwYW4+DQo8ZGl2IHN0eWxlPSJjb2xvcjpyZ2Io MCwwLDApO2ZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjtmb250LXNpemU6MTRweCI+STJS UyBtb2RlbHMgc2hvdWxkIGF1Z21lbnQgdGhlIGJhc2UgbW9kZWxzIHdpdGggZXBoZW1lcmFsIHN0 YXRlLiZuYnNwOzwvZGl2Pg0KPHNwYW4gY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjb2xvcjpyZ2Io MCwwLDApO2ZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjtmb250LXNpemU6MTRweCI+PGJy Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjpyZ2IoMCwwLDApO2ZvbnQtZmFtaWx5OkNhbGli cmksc2Fucy1zZXJpZjtmb250LXNpemU6MTRweCI+PGJyPg0KPC9kaXY+DQo8c3BhbiBzdHlsZT0i Y29sb3I6cmdiKDAsMCwwKTtmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7Zm9udC1zaXpl OjE0cHgiPg0KPGJsb2NrcXVvdGUgc3R5bGU9IkJPUkRFUi1MRUZUOiNiNWM0ZGYgNSBzb2xpZDtQ QURESU5HOjAgMCAwIDU7TUFSR0lOOjAgMCAwIDUiPg0KPGRpdj4NCjxkaXYgbGFuZz0iRU4tVVMi IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdj4NCjxwPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBhIHZvbHVu dGVlciBvcmdhbml6YXRpb24sIGVhY2ggcGVyc29uIGhhcyB0aGUgcmlnaHQgdG8gbWFrZXMgY2hv aWNlcyBpbiB3aGF0IHRoZXkgaGF2ZSB0aW1lIHRvIGRvLiZuYnNwOyZuYnNwOyBJZiB5b3UgZG8g bm90IGhhdmUgYmFuZHdpZHRoIHRvIHByb3ZpZGUgYW4gYWRlcXVhdGUgcm91dGluZyBhcmNoaXRl Y3R1cmUgZm9yIHlhbmcgbW9kZWxzIHRoYXQgY29uc2lkZXJzIGVwaGVtZXJhbCBzdGF0ZSBvciBp dHMgbmVlZHMsDQogdGhhdCBpcyB5b3VyIGNob2ljZS4mbmJzcDsgVW5sZXNzIHlvdSBoYXZlIGEg Y29uY3JldGUgcHJvcG9zYWwgZm9yIHRoZSBlcGhlbWVyYWwgc3RhdGUgdGhhdCBjb3ZlcnMgSTJS UyBSSUIgYW5kDQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1pZXRmLW5ldG1vZC1yb3V0aW5nLWNmZy8iIHRhcmdldD0iX2JsYW5rIj4NCjxzcGFuIHN0eWxl PSJjb2xvcjp3aW5kb3d0ZXh0Ij5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1pZXRmLW5ldG1vZC1yb3V0aW5nLWNmZy88L3NwYW4+PC9hPiwgdGhlIEkyUlMgV0cgTEMgd2ls bCBiZSBjbG9zZWQgYWZ0ZXIgMiB3ZWVrICgxMS8yMyDigJMgMTIvNykgV0cgcmV2aWV3IG9mIHRo ZSBpbg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5kcmFmdC1pZXRmLWkycnMtcmliLWRhdGEt bW9kZWwtMDQudHh0LiZuYnNwOyA8L3NwYW4+Jm5ic3A7Jm5ic3A7PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0KPGRpdiBzdHlsZT0iY29sb3I6cmdi KDAsMCwwKTtmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7Zm9udC1zaXplOjE0cHgiPjxi cj4NCjwvZGl2Pg0KPC9zcGFuPg0KPGRpdiBzdHlsZT0iY29sb3I6cmdiKDAsMCwwKTtmb250LWZh bWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7Zm9udC1zaXplOjE0cHgiPldlIGhhdmUgcHJvcG9zZWQg dHVubmVsIG1vZGVscywgZHJhZnQtaWV0Zi1uZXRtb2Qtcm91dGluZy1jZmcgaXMgbm90IG1lYW50 IHRvIHN1cHBsYW50IHRoZW0uIEJUVywgd2UgZG9u4oCZdCBwbGFuIHRvIHVwZGF0ZSZuYnNwO2Ry YWZ0LWlldGYtaTJycy1yaWItZGF0YS1tb2RlbC0wNC50eHQuIFVwZGF0ZXMgYmFzZWQgb24gSTJS Uw0KIHdpbGwgYmUgaW4gdGhlIGEgbmV4dC1ob3AgYXVnbWVudGF0aW9uIGRyYWZ0IHRoYXQgZXh0 ZW5kcyBkcmFmdC1pZXRmLW5ldG1vZC1ydGctY2ZnLiZuYnNwOzwvZGl2Pg0KPHNwYW4gY2xhc3M9 IiI+DQo8ZGl2IHN0eWxlPSJjb2xvcjpyZ2IoMCwwLDApO2ZvbnQtZmFtaWx5OkNhbGlicmksc2Fu cy1zZXJpZjtmb250LXNpemU6MTRweCI+PGJyPg0KPC9kaXY+DQo8c3BhbiBzdHlsZT0iY29sb3I6 cmdiKDAsMCwwKTtmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7Zm9udC1zaXplOjE0cHgi Pg0KPGJsb2NrcXVvdGUgc3R5bGU9IkJPUkRFUi1MRUZUOiNiNWM0ZGYgNSBzb2xpZDtQQURESU5H OjAgMCAwIDU7TUFSR0lOOjAgMCAwIDUiPg0KPGRpdj4NCjxkaXYgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw Ozx1PjwvdT48dT48L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1 PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QbGVhc2UgcmVtZW1iZXIgdGhhdCB0aGUg STJSUyBSSUIgbW9kZWwgaGFzIHR3byBwYXJ0czombmJzcDsgSTJSUyBJbmZvcm1hdGlvbmFsIE1v ZGVsIGFuZCBJMlJTIERhdGEgTW9kZWwuJm5ic3A7DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PlRoZSBJMlJTIEluZm9ybWF0aW9uYWwgTW9kZWwgYW5kIHRoZSBJMlJTIERhdGEgTW9kZWwgaGF2 ZSBkZXNjcmlwdGlvbnMgb24gdGhlIHNvZnQgdHVubmVsIHByb3Zpc2lvbmluZyBhcyBtZWNoYW5p c21zLiZuYnNwOyBRdWVzdGlvbnMgYXQgdGhpcyBwb2ludCBtdXN0IGRlbW9uc3RyYXRlIGEga25v d2xlZGdlIG9mIHRoZXNlIGRvY3VtZW50cyBvciBzdWdnZXN0IHNwZWNpZmljIGNoYW5nZXMgdG8g dGhlIGRvY3VtZW50cy4NCiAmbmJzcDsmbmJzcDtJZiB5b3Ugd2lzaCB0byByYWlzZSB0aGUgZm9s bG93aW5nIHF1ZXN0aW9ucywgcGxlYXNlIGRvIHRoaXMgaW4gbGlnaHQgb2Ygc3BlY2lmaWMgc2Vj dGlvbnMgdGhhdCBpbmNsdWRlIGJvdGggdGhlIEkyUlMgSW5mb3JtYXRpb25hbCBNb2RlbCwgdGhl IEkyUlMgRGF0YSBNb2RlbCwgYW5kIEkyUlMgYXJjaGl0ZWN0dXJlLg0KPHU+PC91Pjx1PjwvdT48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+ DQo8cD48c3Bhbj5hKTxzcGFuIHN0eWxlPSJmb250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQ6 bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtmb250LXNpemU6N3B0O2xpbmUtaGVpZ2h0Om5vcm1h bDtmb250LWZhbWlseTonVGltZXMgTmV3IFJvbWFuJyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPkkyUlMgdHVubmVscyBtdXN0IGluY2x1ZGUgYWRkaXRpb25z IGJleW9uZCBlbmNhcHN1bGF0aW9uLCA8dT48L3U+PHU+PC91PjwvcD4NCjxwPjxzcGFuPmIpPHNw YW4gc3R5bGU9ImZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudDpub3JtYWw7Zm9udC13ZWln aHQ6bm9ybWFsO2ZvbnQtc2l6ZTo3cHQ7bGluZS1oZWlnaHQ6bm9ybWFsO2ZvbnQtZmFtaWx5OidU aW1lcyBOZXcgUm9tYW4nIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48 L3NwYW4+V2h5IHRoZSBJMlJTIEluZm9ybWF0aW9uYWwgTW9kZWwgYW5kIHRoZSBJMlJTIERhdGEg TW9kZWwgZG8gbm90IHByb3ZpZGUgdGhlIHNvZnQgdHVubmVsIHByb3Zpc2lvbmluZyBvciBkZXNj cmliZSB0aGUgc3BlY2lmaWNzIG9mIHRoaXMgcHJvdmlzaW9uPyZuYnNwOw0KPHU+PC91Pjx1Pjwv dT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBJMlJTIEluZm9ybWF0aW9uYWwgTW9kZWwgaGFzIGV4YW1w bGVzIGZvciB0aGVzZSB0dW5uZWxzLiZuYnNwOyBZb3UgYXJlIHdlbGNvbWUgdG8gbWFrZSBwcm9w b3NhbCBmb3Igc3BlY2lmaWMgY2hhbmdlcyB0byB0aGUgSTJSUyBJbmZvcm1hdGlvbmFsIE1vZGVs IG9yIHRoZSBJMlJTIERhdGEgTW9kZWwuJm5ic3A7IFRoZSBJMlJTIEluZm9ybWF0aW9uYWwgTW9k ZWwgaGFzIGNvbXBsZXRlZCBXRyBMQyBzbyB0aGUgYmFyIGZvcg0KIHN1YnN0YW50aXZlIGNvbW1l bnRzIGlzIGhpZ2guPC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9zcGFuPg0KPGRpdiBzdHlsZT0iY29sb3I6cmdiKDAsMCwwKTtmb250LWZhbWlseTpDYWxpYnJp LHNhbnMtc2VyaWY7Zm9udC1zaXplOjE0cHgiPjxicj4NCjwvZGl2Pg0KPC9zcGFuPg0KPGRpdiBz dHlsZT0iY29sb3I6cmdiKDAsMCwwKTtmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7Zm9u dC1zaXplOjE0cHgiPkkgZG9u4oCZdCBiZWxpZXZlIHRoaXMgZXhjZXJwdCBmcm9tIHRoZSBSSUIg aW5mb3JtYXRpb24gbW9kZWxzIGRlc2NyaWJlcyBzb2Z0IHR1bm5lbCBwcm92aXNpb25pbmcgZm9y IGVhY2ggb2YgdGhlIHR1bm5lbHMgcHJvcG9zZWQgaW4gdGhlIFJJQiBkYXRhIG1vZGVsOjwvZGl2 Pg0KPGRpdiBzdHlsZT0iY29sb3I6cmdiKDAsMCwwKTtmb250LWZhbWlseTpDYWxpYnJpLHNhbnMt c2VyaWY7Zm9udC1zaXplOjE0cHgiPjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+PGZvbnQgZmFj ZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj43LjIuMS4mbmJzcDsgVHVubmVsIG5leHRob3BzPC9mb250 PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPjxicj4NCjwvZm9u dD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4mbmJzcDsgJm5i c3A7QSB0dW5uZWwgbmV4dGhvcCBwb2ludHMgdG8gYSB0dW5uZWwgb2Ygc29tZSBraW5kLiZuYnNw OyBUcmFmZmljIHRoYXQgZ29lczwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJy aSxzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7b3ZlciB0aGUgdHVubmVsIGdldHMgZW5jYXBzdWxh dGVkIHdpdGggdGhlIHR1bm5lbCBlbmNhcC4mbmJzcDsgVHVubmVsPC9mb250PjwvZGl2Pg0KPGRp dj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtuZXh0aG9wcyBh cmUgdXNlZnVsIGZvciBhYnN0cmFjdGluZyBvdXQgZGV0YWlscyBvZiB0aGUgbmV0d29yaywgYnk8 L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+Jm5ic3A7 ICZuYnNwO2hhdmluZyB0aGUgdHJhZmZpYyBzZWFtbGVzc2x5IHJvdXRlIGJldHdlZW4gbmV0d29y ayBlZGdlcy4mbmJzcDsgQXQgdGhlPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxp YnJpLHNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtlbmQgb2YgYSB0dW5uZWwsIHRoZSB0dW5uZWwg d2lsbCBnZXQgZGVjYXBzdWxhdGVkLiZuYnNwOyBUaHVzIHRoZSBncmFtbWFyPC9mb250PjwvZGl2 Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtzdXBw b3J0cyB0d28ga2luZHMgb2Ygb3BlcmF0aW9ucywgb25lIGZvciBlbmNhcCBhbmQgYW5vdGhlciBm b3I8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+Jm5i c3A7ICZuYnNwO2RlY2FwLjwvZm9udD48L2Rpdj4NCjxzcGFuIGNsYXNzPSJIT0VuWmIiPjxmb250 IGNvbG9yPSIjODg4ODg4Ij48L2ZvbnQ+PC9zcGFuPjwvZGl2Pg0KPHNwYW4gY2xhc3M9IkhPRW5a YiI+PGZvbnQgY29sb3I9IiM4ODg4ODgiPg0KPGRpdiBzdHlsZT0iY29sb3I6cmdiKDAsMCwwKTtm b250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7Zm9udC1zaXplOjE0cHgiPjxicj4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0iY29sb3I6cmdiKDAsMCwwKTtmb250LWZhbWlseTpDYWxpYnJpLHNhbnMt c2VyaWY7Zm9udC1zaXplOjE0cHgiPkFjZWUmbmJzcDs8L2Rpdj4NCjwvZm9udD48L3NwYW4+DQo8 ZGl2Pg0KPGRpdiBjbGFzcz0iaDUiPg0KPGRpdiBzdHlsZT0iY29sb3I6cmdiKDAsMCwwKTtmb250 LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7Zm9udC1zaXplOjE0cHgiPjxicj4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0iY29sb3I6cmdiKDAsMCwwKTtmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2Vy aWY7Zm9udC1zaXplOjE0cHgiPjxicj4NCjwvZGl2Pg0KPHNwYW4gc3R5bGU9ImNvbG9yOnJnYigw LDAsMCk7Zm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxNHB4Ij4NCjxi bG9ja3F1b3RlIHN0eWxlPSJCT1JERVItTEVGVDojYjVjNGRmIDUgc29saWQ7UEFERElORzowIDAg MCA1O01BUkdJTjowIDAgMCA1Ij4NCjxkaXY+DQo8ZGl2IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5i c3A7Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbHQ7STJS UyBjaGFpciBoYXQgb2ZmJmd0OyA8dT48L3U+PHU+PC91PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMWY0OTdkIj48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFmNDk3ZCI+ Q2hlZXJzLCA8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFmNDk3ZCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29s b3I6YmxhY2siPlN1ZSBIYXJlcyA8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFmNDk3ZCI+PHU+PC91PiZuYnNwOzx1Pjwv dT48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI2I1YzRkZiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTBwdDtmb250LWZhbWlseTpU YWhvbWEsc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTBwdDtmb250LWZhbWlseTpUYWhvbWEsc2Fucy1zZXJpZiI+IGkycnMgWzxhIGhyZWY9Im1haWx0 bzppMnJzLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86aTJycy1ib3Vu Y2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QWNlZSBMaW5kZW0gKGFjZWUp PGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgTm92ZW1iZXIgMjMsIDIwMTUgNzozMCBQTTxicj4N CjxiPlRvOjwvYj4gU3VzYW4gSGFyZXM7IDxhIGhyZWY9Im1haWx0bzppMnJzQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+aTJyc0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFtpMnJzXSBGVzogSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1pMnJzLXJpYi1kYXRhLW1vZGVsLTA0 LnR4dDx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+U3VlLCZu YnNwOzx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48dT48 L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI2I1YzRkZiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPmkycnMgJmx0OzxhIGhy ZWY9Im1haWx0bzppMnJzLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pMnJzLWJv dW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgU3VzYW4gSGFyZXMgJmx0OzxhIGhy ZWY9Im1haWx0bzpzaGFyZXNAbmR6aC5jb20iIHRhcmdldD0iX2JsYW5rIj5zaGFyZXNAbmR6aC5j b208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5Nb25kYXksIE5vdmVtYmVyIDIzLCAyMDE1IGF0 IDU6NDUgUE08YnI+DQo8Yj5UbzogPC9iPiZxdW90OzxhIGhyZWY9Im1haWx0bzppMnJzQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+aTJyc0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9 Im1haWx0bzppMnJzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aTJyc0BpZXRmLm9yZzwvYT4m Z3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPltpMnJzXSBGVzogSS1EIEFjdGlvbjogZHJhZnQtaWV0 Zi1pMnJzLXJpYi1kYXRhLW1vZGVsLTA0LnR4dDx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2NvbG9yOmJsYWNrIj48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjYjVj NGRmIDQuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21h cmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFmNDk3ZCI+UmVzZW5kaW5nIHRvIEkyUlMgV0cuIDwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMWY0OTdkIj4mbmJzcDs8L3NwYW4+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjYjVjNGRmIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMHB0O2ZvbnQtZmFtaWx5OlRhaG9tYSxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMHB0O2ZvbnQt ZmFtaWx5OlRhaG9tYSxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4gU3VzYW4gSGFyZXMgWzxhIGhy ZWY9Im1haWx0bzpzaGFyZXNAbmR6aC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86c2hhcmVz QG5kemguY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE5vdmVtYmVyIDIzLCAy MDE1IDU6MzMgUE08YnI+DQo8Yj5Ubzo8L2I+ICdKZWZmIFRhbnRzdXJhJzsgJ0FjZWUgTGluZGVt IChhY2VlKSc7ICdNYWNoIENoZW4nOyA8YSBocmVmPSJtYWlsdG86J2kycnNAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj4NCidpMnJzQGlldGYub3JnPC9hPic8YnI+DQo8Yj5DYzo8L2I+ICdKZWZm cmV5IEhhYXMnOyAnQWxpYSBBdGxhcyc7ICdCZW5vaXQgQ2xhaXNlIChiY2xhaXNlKSc8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUkU6IFtpMnJzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWkycnMtcmli LWRhdGEtbW9kZWwtMDQudHh0PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PHU+PC91 Pjx1PjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9w Pg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5KZWZmIGFuZCBBY2VlOiA8dT48L3U+PHU+ PC91Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzx1Pjwv dT48dT48L3U+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+WW91ciBz dWdnZXN0ZWQgY2hhbmdlIGdvZXMgYWdhaW5zdCB0aGUgV0cgYWRvcHRlZCBSSUIgSW5mb3JtYXRp b24gZHJhZnQgdGhhdCBoYXMgYmVlbiBkaXNjdXNzZWQgZm9yIG92ZXIgMiB5ZWFycy4mbmJzcDsg VGhlIGluZm9ybWF0aW9uYWwgZHJhZnQgaGFzIGJlZW4gdGhyb3VnaCBXRyBMQyBhbmQgeW91IGRp ZCBub3QgbWFrZSBhbnkgc3VnZ2VzdGlvbnMgb3IgY29tbWVudHMgZHVyaW5nIHRoZSBXRyBMQy4m bmJzcDsNCiBBbnkgY2hhbmdlIG9mIHRoaXMgbWF0dGVyIGlzIG5vdCBzaW1wbHkgc29tZXRoaW5n IHlvdSBpbmRpY2F0ZSB0byB0aGUgYXV0aG9ycywgYnV0IG5lZWRzIHRvIGJlIGRpc2N1c3NlZCBv biB0aGUgV0cgYXMgYSBkaXJlY3Rpb24gY2hhbmdlIGZvciB0aGUgUklCIElNL0RNIG1vZGVscy48 dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2NvbG9yOmJsYWNrIj48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtj b2xvcjpibGFjayI+SW5kZXBlbmRlbnQgb2YgdGhlIEkyUlMgZWZmb3J0cywgbWlsZXN0b25lcywg YW5kIHByb2Nlc3NlcywgSSB0aGluayB3ZSBuZWVkIHRvIGFkZHJlc3Mgd2hldGhlciBwcm92aXNp b25pbmcgYWxsIHRoZXNlIHR1bm5lbHMgdmlhIFJJQiBpbnN0YWxsYXRpb24gaXMgJm5ic3A7YXBw cm9wcmlhdGUgYW5kLCBhZGRpdGlvbmFsbHksIGNvbnNpc3RlbnQNCiB3aXRoIG90aGVyIFdHIFlB TkcgbW9kZWxzLiBJbiBtYW55IGNhc2VzLCBpdCB3b3VsZCBzZWVtIHRoZXJlIGFyZSB0dW5uZWwg YXR0cmlidXRlcyBvdGhlciB0aGFuIHRoZSBlbmNhcHMgdGhhdCBuZWVkIHRvIGJlIHByb3Zpc2lv bmVkLiBBdCBhIG1pbmltdW0sIEkgdGhpbmsgeW914oCZZCBuZWVkIHRvIGVpdGhlciByZWZlcmVu Y2UgYW4gUkZDIGRlc2NyaWJpbmcgc29mdCB0dW5uZWwgcHJvdmlzaW9uaW5nIG9yIGRlc2NyaWJl IHRoZSBzcGVjaWZpY3MNCiBvZiB0aGlzIHByb3Zpc2lvbmluZy4mbmJzcDs8dT48L3U+PHU+PC91 Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PHU+PC91PiZuYnNwOzx1PjwvdT48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI2I1YzRkZiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdp bi1sZWZ0OjMuNzVwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHA+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cD48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlByaW9yIHRvIG1vdmluZyB0aGlzIGNoYW5nZSB0aHJv dWdoIFdHIGFkb3B0aW9uIGN5Y2xlLCB0aGUgcm91dGluZyBhcmNoaXRlY3R1cmFsIHRlYW0gbmVl ZHMgdG8gaGF2ZTogYSkgY29uY3JldGUgcHJvcG9zYWwgZm9yIHRoZSBlcGhlbWVyYWwgc3RhdGUg dGhhdCBjb3ZlcnMgSTJSUyBSSUIgYW5kDQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLW5ldG1vZC1yb3V0aW5nLWNmZy8iIHRhcmdldD0iX2JsYW5r Ij4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0bW9kLXJv dXRpbmctY2ZnLzwvYT4gJm5ic3A7YW5kICZuYnNwO2IpIEkgcmVxdWVzdGVkIHRoaXMgaW5wdXQg b2YgQWNlZSBMaW5kZW0gYXMgYSByZXByZXNlbnRhdGl2ZSBvZiB0aGUgcm91dGluZyBhcmNoaXRl Y3R1cmUgdGVhbS4gJm5ic3A7Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PHU+PC91PiZuYnNwOzx1Pjwv dT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPlRoZSAmbmJzcDtpZGVudGlmaWNh dGlvbiBvZiB0aGlzIHByb2JsZW0gd2l0aCB0dW5uZWwgcHJvdmlzaW9uaW5nIGlzIGEgZGlyZWN0 IG91dGNvbWUgb2YgdGhpcyBlZmZvcnQuJm5ic3A7PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Y29sb3I6YmxhY2siPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNi NWM0ZGYgNC41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7 bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4mbmJzcDs8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPkkgd2lsbCBiZSBnbGFkIHRvIHdvcmsgd2l0aCB5b3Ugb24gYSBjb25j cmV0ZSBwcm9wb3NhbCB0aGF0IHlvdSBjYW4gc2VuZCB0byB0aGUgZW1haWwgbGlzdCBhbmQgcHJl c2VudCBhdCB0aGUgSTJSUyBpbnRlcmltIG1lZXRpbmcgb24gMTIvMTYvMjAxNSAoMTAtMTE6MzBh bSBFVCkuPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtjb2xvcjpibGFjayI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Y29sb3I6YmxhY2siPkkgd2lsbCBjb250aW51ZSB0byB3b3JrIG9uIGlldGYtcm91dGlu ZyBhbGlnbm1lbnQgYnV0IGRvbuKAmXQgaGF2ZSB0aGUgYmFuZHdpZHRoIGZvciB0aGUgYWJvdmUu Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPjx1 PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5BY2Vl Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPjx1 PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48dT48 L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PHU+PC91 PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPjx1PjwvdT4m bmJzcDs8dT48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNiNWM0ZGYgNC41cHQ7cGFkZGluZzowaW4gMGluIDBp biA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRp dj4NCjxwPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3Nw YW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDtTdWUgSGFyZXMgPHU+ PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDs8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogaTJycyBbPGEgaHJlZj0ibWFp bHRvOmkycnMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzppMnJzLWJv dW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgSmVmZiBUYW50c3VyYTxicj4NClNlbnQ6 IE1vbmRheSwgTm92ZW1iZXIgMjMsIDIwMTUgNDoyNyBQTTxicj4NClRvOiBBY2VlIExpbmRlbSAo YWNlZSk7IE1hY2ggQ2hlbjsgPGEgaHJlZj0ibWFpbHRvOmkycnNAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj4NCmkycnNAaWV0Zi5vcmc8L2E+PGJyPg0KU3ViamVjdDogUmU6IFtpMnJzXSBJLUQg QWN0aW9uOiBkcmFmdC1pZXRmLWkycnMtcmliLWRhdGEtbW9kZWwtMDQudHh0PHU+PC91Pjx1Pjwv dT48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8dT48L3U+ PHU+PC91Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkhpIE1hY2gs PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDs8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPkkgYWdyZWUgd2l0aCBBY2Vl4oCZcyBjb21tZW50cyBhbmQgd291bGQgZW5jb3VyYWdlIHlv dSB0byB1c2UgZ2VuZXJpYy9leGlzdGluZyB0dW5uZWwgbW9kZWwocyksIHBsZWFzZSBzZWUgY29t bWVudHMgcHJvdmlkZWQgZHVyaW5nIFJUR1dHIG1lZXRpbmcgaW4gWW9rb2hhbWEuPHU+PC91Pjx1 PjwvdT48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGVyZSBhcmUg YWxyZWFkeSB0b28gbWFueSwgd2UgbmVlZCB0byByYXRpb25hbGl6ZSB0aGlzIHdvcmsuPHU+PC91 Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8 dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRo aXMgaXMgd2hhdCBoYXMgYmVlbiBkaXNjdXNzZWQgaW4gWW9rb2hhbWEsIFJvYmluIHByZXNlbnRl ZDx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4tLSBkcmFmdC1saS1ydGd3Zy11dHVubmVsLXlhbmc8dT48L3U+PHU+PC91Pjwvc3Bhbj48 L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyAtLSBkcmFmdC1s aS1ydGd3Zy10dW5uZWwtcG9saWN5LXlhbmc8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cD48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyAtLSBkcmFmdC13d3otbmV0bW9k LXlhbmctdHVubmVsLWNmZzx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IC0tIGRyYWZ0LXpoZW5nLWludGFyZWEtZ3JlLXlh bmc8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyAtLSBkcmFmdC1saXUtaW50YXJlYS1ncmUtdHVubmVsLXlhbmc8dT48L3U+ PHU+PC91Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyAtLSBkcmFmdC1saXUtaW50YXJlYS1pcGlwdjQtdHVubmVsLXlhbmc8dT48L3U+PHU+PC91 Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzx1PjwvdT48 dT48L3U+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Q2hlZXJzLDx1 PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SmVm Zjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDs8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOzx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHA+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cD48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4N CjxwPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+T24gMTEvMjMvMTUsIDExOjU2LCAmcXVvdDtp MnJzIG9uIGJlaGFsZiBvZiBBY2VlIExpbmRlbSAoYWNlZSkmcXVvdDsgJmx0OzxhIGhyZWY9Im1h aWx0bzppMnJzLWJvdW5jZXNAaWV0Zi5vcmclMjBvbiUyMGJlaGFsZiUyMG9mJTIwYWNlZUBjaXNj by5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0 LWRlY29yYXRpb246bm9uZSI+aTJycy1ib3VuY2VzQGlldGYub3JnIG9uDQogYmVoYWxmIG9mIGFj ZWVAY2lzY28uY29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjx1PjwvdT48dT48L3U+PC9zcGFuPjwv cD4NCjxwPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3Nw YW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7SGkgTWFjaCw8dT48L3U+ PHU+PC91Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsmbmJz cDs8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZndDtJ4oCZbSBsb29raW5nIGF0IGRyYWZ0LWlldGYtaTJycy1yaWItZGF0YS1tb2RlbC0wNC50 eHQgYW5kIGl0IHN0aWxsDQo8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZndDtpbmNsdWRlcyBhbGwgdGhlIHR1bm5lbCBlbmNhcHMuIEkga25v dyB5b3UgcmVjZWl2ZWQgc2V2ZXJhbCBjb21tZW50cw0KPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9w Pg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7dGhhdCB0aG9zZSBzaG91bGQgYmUg aW4gdGhlIHR1bm5lbCBtb2RlbChzKSBhbmQgdGhpcyBJMlJTIFJJQiBtb2RlbA0KPHU+PC91Pjx1 PjwvdT48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7c2hvdWxk IG1lcmVseSByZWZlcmVuY2UgYW4gaW1wb3J0ZWQgdHVubmVsIGFic3RyYWN0aW9uLiBIb3cgYXJl IHlvdQ0KPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mZ3Q7Z29pbmcgdG8gYWRkcmVzcyB0aGlzPyBJdCBzZWVtZWQgdGhhdCB0aGUgY29uc2Vu c3VzIChhbmQgYW4gb3Bpbmlvbg0KPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHA+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7dGhhdCBJIHNoYXJlKSB3YXMgdGhhdCB0aGlzIG1vZGVs IHNob3VsZCBub3QgYXR0ZW1wdCB0byBnZW5lcmljYWxseQ0KPHU+PC91Pjx1PjwvdT48L3NwYW4+ PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Y3JlYXRlZCB0dW5uZWxzIHZp YSBSSUIvRklCIGVudHJpZXMuPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7VGhhbmtzLDx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxw PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0O0FjZWU8dT48L3U+PHU+PC91Pjwvc3Bhbj48 L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsmbmJzcDs8dT48L3U+PHU+PC91 Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDtPbiAxMS8yMy8x NSwgMjoyMyBBTSwgJnF1b3Q7aTJycyBvbiBiZWhhbGYgb2YgTWFjaCBDaGVuJnF1b3Q7DQo8dT48 L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsm bHQ7PGEgaHJlZj0ibWFpbHRvOmkycnMtYm91bmNlc0BpZXRmLm9yZyUyMG9uJTIwYmVoYWxmJTIw b2YlMjBtYWNoLmNoZW5AaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJj b2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5pMnJzLWJvdW5jZXNAaWV0Zi5v cmcgb24gYmVoYWxmIG9mIG1hY2guY2hlbkBodWF3ZWkuY29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3Rl Ojx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jmd0OyZuYnNwOzx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jmd0OyZndDtIaSw8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZndDsmZ3Q7Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9w Pg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0O1dlIGp1c3QgdXBsb2FkZWQg YW4gdXBkYXRlIHRoYXQgYWRkcmVzc2VzIHRoZSBjb21tZW50cyByZWNlaXZlZA0KPHU+PC91Pjx1 PjwvdT48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0Oyhp bmNsdWRlIG9ubGluZSBhbmQgb2ZmbGluZSkgcmVjZW50bHkuIFBsZWFzZSByZXZpZXcgdGhlIGRy YWZ0IGFuZCBjb21tZW50ITx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jmd0OyZndDsmbmJzcDs8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8 cD48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsmZ3Q7VGhhbmtzLDx1PjwvdT48dT48L3U+ PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDtNYWNoPHU+ PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7 Jmd0OyZuYnNwOzx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jmd0OyZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPHU+PC91Pjx1 PjwvdT48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0OyZn dDsgRnJvbTogaTJycyBbPGEgaHJlZj0ibWFpbHRvOmkycnMtYm91bmNlc0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlv bjpub25lIj5tYWlsdG86aTJycy1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT5dIE9uIEJlaGFs ZiBPZg0KPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mZ3Q7Jmd0OyZndDs8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNv cmF0aW9uOm5vbmUiPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvc3Bhbj48L2E+PHU+PC91Pjx1 PjwvdT48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0OyZn dDsgU2VudDogTW9uZGF5LCBOb3ZlbWJlciAyMywgMjAxNSAzOjE2IFBNPHU+PC91Pjx1PjwvdT48 L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0OyZndDsgVG86 IDxhIGhyZWY9Im1haWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4N CjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5pLWQt YW5ub3VuY2VAaWV0Zi5vcmc8L3NwYW4+PC9hPjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxw PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDsmZ3Q7IENjOiA8YSBocmVmPSJtYWls dG86aTJyc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndp bmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmkycnNAaWV0Zi5vcmc8L3NwYW4+PC9hPjx1 PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0 OyZndDsmZ3Q7IFN1YmplY3Q6IFtpMnJzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWkycnMtcmli LWRhdGEtbW9kZWwtMDQudHh0PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0OyZndDsgPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0K PHA+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0OyZndDsgPHU+PC91Pjx1PjwvdT48 L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0OyZndDsgQSBO ZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQt RHJhZnRzDQo8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZndDsmZ3Q7Jmd0O2RpcmVjdG9yaWVzLjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4N CjxwPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDsmZ3Q7Jm5ic3A7IFRoaXMgZHJh ZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIEludGVyZmFjZSB0byB0aGUgUm91dGluZyBTeXN0ZW0N Cjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jmd0OyZndDsmZ3Q7V29ya2luZyBHcm91cCZuYnNwOyBvZiB0aGUgSUVURi48dT48L3U+PHU+PC91 Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsmZ3Q7Jmd0OyA8 dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZn dDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBUaXRsZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyA6IEEgWUFORyBEYXRhIE1vZGVsIGZvciBSb3V0aW5nIEluZm9ybWF0aW9uIEJh c2U8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZndDsmZ3Q7Jmd0OyAoUklCKTx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEF1dGhvcnMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgOiBMaXhpbmcgV2FuZzx1PjwvdT48dT48L3U+PC9zcGFuPjwv cD4NCjxwPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEhhcmloYXJhbiBBbmFudGhha3Jpc2huYW48 dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZn dDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBNYWNo KEd1b3lpKSBDaGVuPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4mZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgQW1pdCBEYXNzPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgU3JpZ2FuZXNoIEtpbmk8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8 cD48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBOaXRpbiBCYWhhZHVyPHU+PC91Pjx1PjwvdT48L3Nw YW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0OyZndDsgJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZpbGVuYW1lJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogZHJhZnQtaWV0Zi1pMnJzLXJpYi1kYXRhLW1vZGVs LTA0LnR4dDx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jmd0OyZndDsmZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBQ YWdlcyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyA6IDY1PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4mZ3Q7Jmd0OyZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IERhdGUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgOiAyMDE1LTExLTIyPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0K PHA+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0OyZndDsgPHU+PC91Pjx1PjwvdT48 L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0OyZndDsgQWJz dHJhY3Q6PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhpcyBkb2N1bWVudCBkZWZpbmVz IGEgWUFORyBkYXRhIG1vZGVsIGZvciBSb3V0aW5nIEluZm9ybWF0aW9uIEJhc2U8dT48L3U+PHU+ PC91Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsmZ3Q7Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyAoUklCKSB0aGF0IGFsaWducyB3aXRoIHRoZSBJMlJTIFJJQiBp bmZvcm1hdGlvbiBtb2RlbC48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZndDsmZ3Q7Jmd0OyA8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8 cD48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsmZ3Q7Jmd0OyA8dT48L3U+PHU+PC91Pjwv c3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsmZ3Q7Jmd0OyA8dT48 L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsm Z3Q7Jmd0OyBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBp czo8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLWkycnMtcmliLWRhdGEtbW9kZWwvIiB0YXJnZXQ9Il9ibGFuayI+DQo8c3BhbiBz dHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJzLXJpYi1kYXRhLW1vZGVsLzwvc3Bh bj48L2E+PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mZ3Q7Jmd0OyZndDsgPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0OyZndDsgVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVy c2lvbiBhdmFpbGFibGUgYXQ6PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtaTJycy1yaWItZGF0YS1tb2RlbC0wNCIgdGFyZ2V0PSJfYmxh bmsiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUi Pmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWkycnMtcmliLWRhdGEtbW9k ZWwtMDQ8L3NwYW4+PC9hPjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jmd0OyZndDsmZ3Q7IDx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxw PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDsmZ3Q7IEEgZGlmZiBmcm9tIHRoZSBw cmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDo8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+ DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1pMnJzLXJpYi1kYXRhLW1v ZGVsLTA0IiB0YXJnZXQ9Il9ibGFuayI+DQo8c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0 ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRy YWZ0LWlldGYtaTJycy1yaWItZGF0YS1tb2RlbC0wNDwvc3Bhbj48L2E+PHU+PC91Pjx1PjwvdT48 L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0OyZndDsgPHU+ PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7 Jmd0OyZndDsgPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4mZ3Q7Jmd0OyZndDsgUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBs ZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4N CjxwPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDsmZ3Q7c3VibWlzc2lvbiZuYnNw OyB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0DQo8 dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZn dDsmZ3Q7Jmd0OzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PnRvb2xzLmlldGYub3JnPC9hPi48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZndDsmZ3Q7Jmd0OyA8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+ DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsmZ3Q7Jmd0OyBJbnRlcm5ldC1EcmFm dHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6PHU+PC91Pjx1PjwvdT48 L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0OyZndDsgPGEg aHJlZj0iZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8iIHRhcmdldD0iX2JsYW5r Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5m dHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLzwvc3Bhbj48L2E+PHU+PC91Pjx1Pjwv dT48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jmd0OyZndDsg PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m Z3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZndDsmZ3Q7Jmd0OyBpMnJzIG1haWxpbmcgbGlzdDx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4N CjxwPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0 bzppMnJzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRv d3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmkycnNAaWV0Zi5vcmc8L3NwYW4+PC9hPjx1Pjwv dT48dT48L3U+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZn dDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJy cyIgdGFyZ2V0PSJfYmxhbmsiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1k ZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJy czwvc3Bhbj48L2E+PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4mZ3Q7Jmd0OyZuYnNwOzx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDtfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDtpMnJzIG1haWxpbmcgbGlzdDx1PjwvdT48dT48 L3U+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZndDs8YSBo cmVmPSJtYWlsdG86aTJyc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJj b2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5pMnJzQGlldGYub3JnPC9zcGFu PjwvYT48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZndDsmZ3Q7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9pMnJzIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4 dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aTJyczwvc3Bhbj48L2E+PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHA+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZndDtpMnJzIG1haWxpbmcgbGlzdDx1PjwvdT48dT48L3U+PC9zcGFu PjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OzxhIGhyZWY9Im1haWx0bzpp MnJzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3Rl eHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmkycnNAaWV0Zi5vcmc8L3NwYW4+PC9hPjx1PjwvdT48 dT48L3U+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OzxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJycyIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25l Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2kycnM8L3NwYW4+PC9hPjx1 PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188dT48L3U+PHU+PC91 Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPmkycnMgbWFpbGluZyBs aXN0PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij48YSBocmVmPSJtYWlsdG86aTJyc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0 eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5pMnJzQGlldGYub3Jn PC9zcGFuPjwvYT48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aTJycyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQt ZGVjb3JhdGlvbjpub25lIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ky cnM8L3NwYW4+PC9hPjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3Nw YW4+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_D27A04393F032aceeciscocom_-- From nobody Tue Nov 24 09:28:48 2015 Return-Path: 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 EAF431B3004 for ; Tue, 24 Nov 2015 09:28:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 0TU08bjC_dqb for ; Tue, 24 Nov 2015 09:28:41 -0800 (PST) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (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 320C51B3003 for ; Tue, 24 Nov 2015 09:28:41 -0800 (PST) Received: by oiww189 with SMTP id w189so14054565oiw.3 for ; Tue, 24 Nov 2015 09:28:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UAkAZ6HsRVOwj/STQTWoJyJ4Wu2YoiBUk8JMOkxSl9I=; b=BBfWr59G+1KvzdJv8YYcwXOFgVkHZhgwamVwyPEw4yjuX3wTlNyaIWvmzAMxJrdEa1 tF2dfAoz4ULdM67SrV50igM6iTn3jpGATSHlCVS7gC7hfrRdXuHCradQ2CAS8KYxZr3/ qFVmGHrcBuePZwQ7RA1lEd1ok8SV6IK62BjBm3pYAdg3/TIkRDVhHQd8WlK2nhZhJDau O/mRki+sp+OLt0G3JfUI93vDvKyF7pmuJ5BAGj1y0haHPgf6vyDhFEgJu6OVSE6ZHJ+/ PHbCVRgsDsdHc8OAcr44l0MwtzeP3Oj1tDIgRKh+NjTwJa1gmpwWsUB64fZs2oJgJy/K lXPw== MIME-Version: 1.0 X-Received: by 10.202.74.69 with SMTP id x66mr20220133oia.96.1448386120590; Tue, 24 Nov 2015 09:28:40 -0800 (PST) Received: by 10.60.177.103 with HTTP; Tue, 24 Nov 2015 09:28:40 -0800 (PST) In-Reply-To: References: <20151123071558.25655.92641.idtracker@ietfa.amsl.com> <8D628270-A455-4E01-881F-BA20D544228D@ericsson.com> <041001d12640$9d5104b0$d7f30e10$@ndzh.com> <047901d12663$cb716880$62543980$@ndzh.com> Date: Tue, 24 Nov 2015 12:28:40 -0500 Message-ID: From: Alia Atlas To: "Acee Lindem (acee)" Content-Type: multipart/alternative; boundary=001a1134f382372cdf05254cac9e Archived-At: Cc: Jeffrey Haas , "i2rs@ietf.org" , Jeff Tantsura , Susan Hares Subject: Re: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 17:28:47 -0000 --001a1134f382372cdf05254cac9e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Acee, In-line, as always. On Tue, Nov 24, 2015 at 12:19 PM, Acee Lindem (acee) wrote= : > Alia, > > From: Alia Atlas > Date: Tuesday, November 24, 2015 at 12:08 PM > To: Acee Lindem > Cc: Susan Hares , "i2rs@ietf.org" , Jeff > Haas , Jeff Tantsura > Subject: Re: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt > > Acee, > > As Sue has said, the I2RS Info Model has passed WGLC and is just waiting > for the DM to be done in order to progress. Obviously, substantial > technical concerns are always welcome - there's a long way between WGLC a= nd > final IESG approval; I do not think that you have clearly described your > technical concerns. Are you mixing up using a tunnel for forwarding with > provisioning the tunnel?? > > > > The I2RS RIB model is not for provisioning tunnels. It is intended so > that traffic can be forwarded properly, regardless of the abstraction. F= or > instance, with MPLS, a packet could be sent out with an arbitrary label o= r > label stack, a packet could follow an LSP, or a packet could follow a > tunnel. By providing the ability to forward via these different layers = of > abstraction, the RIB model allows forwarding to occur correctly even when= a > tunnel or LSP changes - just like a next-hop can be specified to forward > like a different prefix and then follows that prefix. > > I certainly do not see the I2RS RIB model as creating tunnels - but merel= y > being able to use ones that already exist. > > > I believe the intension of the model is clearly to dynamically create the > tunnels. > > Tunnel nexthops allow an external entity to program static tunnel > headers. There can be cases where the remote tunnel end-point does > not support dynamic signaling (e.g. no LDP support on a host) and in > those cases the external entity might want to program the tunnel > header on both ends of the tunnel. The tunnel nexthop is kept > generic with specifications provided for some commonly used tunnels. > It is expected that the data-model will model these tunnel types with > complete accuracy. > If the text makes you believe that it is dynamically creating tunnels, then that text should be improved. It shouldn't be creating the tunnel - but what "creating a tunnel" means may also be open for interpretation. For instance, a next-hop might include an MPLS label or label-stack - but that isn't creating an LSP. It is allowing a packet that matches to be forwarded with that label-stack. A next-hop may include a tunnel name - but that is a reference to an existing tunnel (or a tunnel that doesn't exist and therefore won't resolve). Now, if your objection is that the I2RS RIB model should use a common > grouping that describes all types of tunnels, I have yet to see one. The > efforts to provide YANG models for tunnels are still quite immature. > Describing what types of groupings would be useful is the type of work > that I hope the design team will do. > > Asking I2RS to stall until time can be dedicated isn't appropriate. > > > Nor is not addressing comments on WG drafts=E2=80=A6 > Absolutely - regardless of when they come in. But this is the first clear pointing to what you see as the problem with the draft. Thanks for clarifying. Regards, Alia > Acee > > > > Regards, > Alia > > > > On Tue, Nov 24, 2015 at 8:34 AM, Acee Lindem (acee) > wrote: > >> From: Susan Hares >> Date: Monday, November 23, 2015 at 9:57 PM >> To: Acee Lindem , "i2rs@ietf.org" >> Cc: Alia Atlas , Jeff Haas , Jeff >> Tantsura >> Subject: RE: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.tx= t >> >> Acee: >> >> >> >> Is your input individual input or input from the routing architecture fo= r >> yang models? >> >> >> Individual. >> >> >> >> >> >> >> The routing architecture for yang models is incomplete without the >> consideration of the I2RS ephemeral state and I2RS architecture. Asking >> the I2RS WG to change a document that is in WG LC based on an incomplete >> architectural document is not reasonable. >> >> >> My comment with respect to tunnel provisioning is not based on any >> architecture document. >> >> An alignment between >> https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ without >> the consideration of the I2RS ephemeral state is an incomplete alignment >> and a problematic approach for I2RS WG=E2=80=99s efforts. >> >> >> I2RS models should augment the base models with ephemeral state. >> >> >> >> >> In a volunteer organization, each person has the right to makes choices >> in what they have time to do. If you do not have bandwidth to provide = an >> adequate routing architecture for yang models that considers ephemeral >> state or its needs, that is your choice. Unless you have a concrete >> proposal for the ephemeral state that covers I2RS RIB and >> https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/, the >> I2RS WG LC will be closed after 2 week (11/23 =E2=80=93 12/7) WG review = of the in draft-ietf-i2rs-rib-data-model-04.txt. >> >> >> >> We have proposed tunnel models, draft-ietf-netmod-routing-cfg is not >> meant to supplant them. BTW, we don=E2=80=99t plan to >> update draft-ietf-i2rs-rib-data-model-04.txt. Updates based on I2RS will= be >> in the a next-hop augmentation draft that extends >> draft-ietf-netmod-rtg-cfg. >> >> >> >> >> >> Please remember that the I2RS RIB model has two parts: I2RS >> Informational Model and I2RS Data Model. The I2RS Informational Model >> and the I2RS Data Model have descriptions on the soft tunnel provisionin= g >> as mechanisms. Questions at this point must demonstrate a knowledge of >> these documents or suggest specific changes to the documents. If you w= ish >> to raise the following questions, please do this in light of specific >> sections that include both the I2RS Informational Model, the I2RS Data >> Model, and I2RS architecture. >> >> >> >> a) I2RS tunnels must include additions beyond encapsulation, >> >> b) Why the I2RS Informational Model and the I2RS Data Model do not >> provide the soft tunnel provisioning or describe the specifics of this >> provision? >> >> >> >> The I2RS Informational Model has examples for these tunnels. You are >> welcome to make proposal for specific changes to the I2RS Informational >> Model or the I2RS Data Model. The I2RS Informational Model has complete= d >> WG LC so the bar for substantive comments is high. >> >> >> I don=E2=80=99t believe this excerpt from the RIB information models des= cribes >> soft tunnel provisioning for each of the tunnels proposed in the RIB dat= a >> model: >> >> 7.2.1. Tunnel nexthops >> >> A tunnel nexthop points to a tunnel of some kind. Traffic that goes >> over the tunnel gets encapsulated with the tunnel encap. Tunnel >> nexthops are useful for abstracting out details of the network, by >> having the traffic seamlessly route between network edges. At the >> end of a tunnel, the tunnel will get decapsulated. Thus the grammar >> supports two kinds of operations, one for encap and another for >> decap. >> >> Acee >> >> >> >> >> >> >> >> >> Cheers, >> >> >> >> Sue Hares >> >> >> >> *From:* i2rs [mailto:i2rs-bounces@ietf.org ] *On >> Behalf Of *Acee Lindem (acee) >> *Sent:* Monday, November 23, 2015 7:30 PM >> *To:* Susan Hares; i2rs@ietf.org >> *Subject:* Re: [i2rs] FW: I-D Action: >> draft-ietf-i2rs-rib-data-model-04.txt >> >> >> >> Sue, >> >> >> >> *From: *i2rs on behalf of Susan Hares < >> shares@ndzh.com> >> *Date: *Monday, November 23, 2015 at 5:45 PM >> *To: *"i2rs@ietf.org" >> *Subject: *[i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt >> >> >> >> Resending to I2RS WG. >> >> >> >> *From:* Susan Hares [mailto:shares@ndzh.com ] >> *Sent:* Monday, November 23, 2015 5:33 PM >> *To:* 'Jeff Tantsura'; 'Acee Lindem (acee)'; 'Mach Chen'; 'i2rs@ietf.org= ' >> *Cc:* 'Jeffrey Haas'; 'Alia Atlas'; 'Benoit Claise (bclaise)' >> *Subject:* RE: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.txt >> >> >> >> Jeff and Acee: >> >> >> >> Your suggested change goes against the WG adopted RIB Information draft >> that has been discussed for over 2 years. The informational draft has b= een >> through WG LC and you did not make any suggestions or comments during th= e >> WG LC. Any change of this matter is not simply something you indicate t= o >> the authors, but needs to be discussed on the WG as a direction change f= or >> the RIB IM/DM models. >> >> >> >> Independent of the I2RS efforts, milestones, and processes, I think we >> need to address whether provisioning all these tunnels via RIB installat= ion >> is appropriate and, additionally, consistent with other WG YANG models.= In >> many cases, it would seem there are tunnel attributes other than the enc= aps >> that need to be provisioned. At a minimum, I think you=E2=80=99d need to= either >> reference an RFC describing soft tunnel provisioning or describe the >> specifics of this provisioning. >> >> >> >> >> >> Prior to moving this change through WG adoption cycle, the routing >> architectural team needs to have: a) concrete proposal for the ephemeral >> state that covers I2RS RIB and >> https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ and b) >> I requested this input of Acee Lindem as a representative of the routing >> architecture team. >> >> >> >> The identification of this problem with tunnel provisioning is a direct >> outcome of this effort. >> >> >> >> >> >> >> >> I will be glad to work with you on a concrete proposal that you can send >> to the email list and present at the I2RS interim meeting on 12/16/2015 >> (10-11:30am ET). >> >> >> >> I will continue to work on ietf-routing alignment but don=E2=80=99t have= the >> bandwidth for the above. >> >> >> >> Acee >> >> >> >> >> >> >> >> >> >> >> >> Sue Hares >> >> >> >> -----Original Message----- >> From: i2rs [mailto:i2rs-bounces@ietf.org ] On >> Behalf Of Jeff Tantsura >> Sent: Monday, November 23, 2015 4:27 PM >> To: Acee Lindem (acee); Mach Chen; i2rs@ietf.org >> Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.txt >> >> >> >> Hi Mach, >> >> >> >> I agree with Acee=E2=80=99s comments and would encourage you to use >> generic/existing tunnel model(s), please see comments provided during RT= GWG >> meeting in Yokohama. >> >> There are already too many, we need to rationalize this work. >> >> >> >> This is what has been discussed in Yokohama, Robin presented >> >> >> >> -- draft-li-rtgwg-utunnel-yang >> >> -- draft-li-rtgwg-tunnel-policy-yang >> >> -- draft-wwz-netmod-yang-tunnel-cfg >> >> -- draft-zheng-intarea-gre-yang >> >> -- draft-liu-intarea-gre-tunnel-yang >> >> -- draft-liu-intarea-ipipv4-tunnel-yang >> >> >> >> Cheers, >> >> Jeff >> >> >> >> >> >> >> >> >> >> >> >> >> >> On 11/23/15, 11:56, "i2rs on behalf of Acee Lindem (acee)" > on behalf of acee@cisco.com >> > wrote: >> >> >> >> >Hi Mach, >> >> > >> >> >I=E2=80=99m looking at draft-ietf-i2rs-rib-data-model-04.txt and it sti= ll >> >> >includes all the tunnel encaps. I know you received several comments >> >> >that those should be in the tunnel model(s) and this I2RS RIB model >> >> >should merely reference an imported tunnel abstraction. How are you >> >> >going to address this? It seemed that the consensus (and an opinion >> >> >that I share) was that this model should not attempt to generically >> >> >created tunnels via RIB/FIB entries. >> >> >Thanks, >> >> >Acee >> >> > >> >> >On 11/23/15, 2:23 AM, "i2rs on behalf of Mach Chen" >> >> > wrote: >> >> > >> >> >>Hi, >> >> >> >> >> >>We just uploaded an update that addresses the comments received >> >> >>(include online and offline) recently. Please review the draft and >> comment! >> >> >> >> >> >>Thanks, >> >> >>Mach >> >> >> >> >> >>> -----Original Message----- >> >> >>> From: i2rs [mailto:i2rs-bounces@ietf.org ] On >> Behalf Of >> >> >>>internet-drafts@ietf.org >> >> >>> Sent: Monday, November 23, 2015 3:16 PM >> >> >>> To: i-d-announce@ietf.org >> >> >>> Cc: i2rs@ietf.org >> >> >>> Subject: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.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 : A YANG Data Model for Routing Information >> Base >> >> >>> (RIB) >> >> >>> Authors : Lixing Wang >> >> >>> Hariharan Ananthakrishnan >> >> >>> Mach(Guoyi) Chen >> >> >>> Amit Dass >> >> >>> Sriganesh Kini >> >> >>> Nitin Bahadur >> >> >>> Filename : draft-ietf-i2rs-rib-data-model-04.txt >> >> >>> Pages : 65 >> >> >>> Date : 2015-11-22 >> >> >>> >> >> >>> Abstract: >> >> >>> This document defines a YANG data model for Routing Information >> Base >> >> >>> (RIB) that aligns with the I2RS RIB information model. >> >> >>> >> >> >>> >> >> >>> >> >> >>> The IETF datatracker status page for this draft is: >> >> >>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/ >> >> >>> >> >> >>> There's also a htmlized version available at: >> >> >>> https://tools.ietf.org/html/draft-ietf-i2rs-rib-data-model-04 >> >> >>> >> >> >>> A diff from the previous version is available at: >> >> >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2rs-rib-data-model-0= 4 >> >> >>> >> >> >>> >> >> >>> 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 >> >> >>> 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 >> >> _______________________________________________ >> >> i2rs mailing list >> >> i2rs@ietf.org >> >> https://www.ietf.org/mailman/listinfo/i2rs >> >> > --001a1134f382372cdf05254cac9e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Acee,
=C2=A0
In-line, as always.

On Tue, Nov 24, 2015 at= 12:19 PM, Acee Lindem (acee) <acee@cisco.com> wrote:
Alia,=C2=A0

From: Alia Atlas <akatlas@gmail.com>
Date: Tuesday, November 24, 2015 at= 12:08 PM
To: Acee Lindem <acee@cisco.com>
Cc: Susan Hares <shares@ndzh.com>, "i2rs@ietf.org" <i2rs@ietf.org>, Jef= f Haas <jhaas@pfrc.o= rg>, Jeff Tantsura <jeff.tantsura@ericsson.com>
Subject: Re: [i2rs] FW: I-D Action:= draft-ietf-i2rs-rib-data-model-04.txt

Acee,

As Sue has said, the I2RS Info Model has passed WGLC and is just waiti= ng for the DM to be done in order to progress.=C2=A0 Obviously, substantial= technical concerns are always welcome - there's a long way between WGL= C and final IESG approval; I do not think that you have clearly described your technical concerns.=C2=A0 Are you mix= ing up using a tunnel for forwarding with provisioning the tunnel?? =C2=A0<= /div>


The I2RS RIB model is not for provisioning tunnels.=C2=A0 It is intend= ed so that traffic can be forwarded properly, regardless of the abstraction= .=C2=A0 For instance, with MPLS, a packet could be sent out with an arbitra= ry label or label stack, a packet could follow an LSP, or a packet could follow a tunnel. =C2=A0 By providing the ability= to forward via these different layers of abstraction, the RIB model allows= forwarding to occur correctly even when a tunnel or LSP changes - just lik= e a next-hop can be specified to forward like a different prefix and then follows that prefix.

I certainly do not see the I2RS RIB model as creating tunnels - but me= rely being able to use ones that already exist.

I believe the intension of the model is clearly to dynamically create the t= unnels. =C2=A0

=C2=A0 =C2=A0Tunnel nexthops allow a= n external entity to program static tunnel
=C2=A0 =C2=A0headers.=C2=A0 There ca= n be cases where the remote tunnel end-point does
=C2=A0 =C2=A0not support dynamic sig= naling (e.g. no LDP support on a host) and in
=C2=A0 =C2=A0those cases the externa= l entity might want to program the tunnel
=C2=A0 =C2=A0header on both ends of = the tunnel.=C2=A0 The tunnel nexthop is kept
=C2=A0 =C2=A0generic with specificat= ions provided for some commonly used tunnels.
=C2=A0 =C2=A0It is expected that the= data-model will model these tunnel types with
=C2=A0 =C2=A0complete accuracy.

If the text makes you believ= e that it is dynamically creating tunnels, then that text should be improve= d.
It shouldn't be creating the tunnel - but what "creat= ing a tunnel" means may also be open for interpretation.
For= instance, a next-hop might include an MPLS label or label-stack - but that= isn't creating an LSP.=C2=A0 It
is allowing a packet that ma= tches to be forwarded with that label-stack.=C2=A0 A next-hop may include a= tunnel name - but that is a reference to an existing tunnel (or a tunnel t= hat doesn't exist and therefore won't resolve).

Now, if your objection is that the I2RS RIB model should use a common = grouping that describes all types of tunnels, I have yet to see one.=C2=A0 = The efforts to provide YANG models for tunnels are still quite immature.
Describing what types of groupings would be useful is the type of work= that I hope the design team will do.
Asking I2RS to stall until time can be dedicated isn't appropriate= .

Nor is not addressing comments on WG drafts=E2=80=A6=C2=A0

Absolutely - regardless of when the= y come in.=C2=A0 But this is the first clear pointing to what you see
=
as the problem with the draft. =C2=A0 Thanks for clarifying.

Regards,
Alia=C2=A0
=C2=A0
Acee=C2=A0



Regards,
Alia



On Tue, Nov 24, 2015 at 8:34 AM, Acee Lindem (ac= ee) <acee@cisco.com&= gt; wrote:
From= : Susan Hares <<= /span>shares@ndzh.com>
Date: Monday, November 23, 2015 at = 9:57 PM
To: Acee Lindem <acee@cisco.com>, "i2rs@ietf.org" <i2rs@ietf.org>
Cc: Alia Atlas <akatlas@gmail.com>, Jeff Haas= <jhaas@pfrc.org= >, Jeff Tantsura <jeff.tantsura@ericsson.com>
Subject: RE: [i2rs] FW: I-D Action:= draft-ietf-i2rs-rib-data-model-04.txt

Acee:

=C2=A0

Is your input individual input or input from the rou= ting architecture for yang models?

Individual.=C2=A0


=C2=A0

<I2RS chair hat on>

The routing architecture for yang models is incomplete without the consi= deration of the I2RS ephemeral state and I2RS architecture.=C2=A0 Asking th= e I2RS WG to change a document that is in WG LC based on an incomplete arch= itectural document is not reasonable. =C2=A0

My comment with respect to tunnel provisioning is not based on any archi= tecture document.=C2=A0

An alignment between https://datatracker.ietf.org/doc/draft-iet= f-netmod-routing-cfg/=C2=A0without t= he consideration of the I2RS ephemeral state is an incomplete alignment and= a problematic =C2=A0approach for I2RS WG=E2=80=99s efforts. =C2=A0=C2=A0

I2RS models should augment the base models with ephemeral state.=C2=A0


=C2=A0

In a volunteer organization, each person has the rig= ht to makes choices in what they have time to do.=C2=A0=C2=A0 If you do not= have bandwidth to provide an adequate routing architecture for yang models= that considers ephemeral state or its needs, that is your choice.=C2=A0 Unless you have a concrete proposal for the eph= emeral state that covers I2RS RIB and https://datatracker.ietf.org/doc/draft-iet= f-netmod-routing-cfg/, the I2RS WG LC will be closed after 2 wee= k (11/23 =E2=80=93 12/7) WG review of the in draft-ietf-i2rs-rib-data-model-04.txt.=C2=A0 =C2=A0=C2=A0

We have proposed tunnel models, draft-ietf-netmod-routing-cfg is not mea= nt to supplant them. BTW, we don=E2=80=99t plan to update=C2=A0draft-ietf-i= 2rs-rib-data-model-04.txt. Updates based on I2RS will be in the a next-hop augmentation draft that extends draft-ietf-netmo= d-rtg-cfg.=C2=A0

=C2=A0

=C2=A0

Please remember that the I2RS RIB model has two part= s:=C2=A0 I2RS Informational Model and I2RS Data Model.=C2=A0 The I2RS Informational Model and the I2RS Data = Model have descriptions on the soft tunnel provisioning as mechanisms.=C2= =A0 Questions at this point must demonstrate a knowledge of these documents= or suggest specific changes to the documents. =C2=A0=C2=A0If you wish to raise the following questions, please do this i= n light of specific sections that include both the I2RS Informational Model= , the I2RS Data Model, and I2RS architecture.

=C2=A0

a)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I2RS tunnels must include additions beyond encapsulation, =

b)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Why the I2RS Informational Model and the I2RS Data Model do n= ot provide the soft tunnel provisioning or describe the specifics of this p= rovision?=C2=A0

=C2=A0

The I2RS Informational Model has examples for these = tunnels.=C2=A0 You are welcome to make proposal for specific changes to the= I2RS Informational Model or the I2RS Data Model.=C2=A0 The I2RS Informatio= nal Model has completed WG LC so the bar for substantive comments is high.

I don=E2=80=99t believe this excerpt from the RIB information models des= cribes soft tunnel provisioning for each of the tunnels proposed in the RIB= data model:

7.2.1.=C2=A0 Tunnel nexthops<= /div>

=C2=A0 =C2=A0A tunnel nexthop points= to a tunnel of some kind.=C2=A0 Traffic that goes
=C2=A0 =C2=A0over the tunnel gets en= capsulated with the tunnel encap.=C2=A0 Tunnel
=C2=A0 =C2=A0nexthops are useful for= abstracting out details of the network, by
=C2=A0 =C2=A0having the traffic seam= lessly route between network edges.=C2=A0 At the
=C2=A0 =C2=A0end of a tunnel, the tu= nnel will get decapsulated.=C2=A0 Thus the grammar
=C2=A0 =C2=A0supports two kinds of o= perations, one for encap and another for
=C2=A0 =C2=A0decap.

Acee=C2=A0


=C2=A0 =C2=A0=C2=A0

<I2RS chair hat off>

=C2=A0

Cheers, =

=C2=A0

Sue Har= es

=C2=A0

From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Monday, November 23, 2015 7:30 PM
To: Susan Hares; = i2rs@ietf.org
Subject: Re: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-0= 4.txt

=C2=A0

Sue,=C2= =A0

= =C2=A0

From: i2rs <i2rs-bounces@ietf.org> on behalf of Susan Hares <= ;shares@ndzh.com&g= t;
Date: Monday, November 23, 2015 at 5:45 PM
To: "i2rs@ie= tf.org" <i2r= s@ietf.org>
Subject: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.tx= t

= =C2=A0

Resending to I2RS WG. =

=C2=A0

From: Susan Hares [mailto:shares@ndzh.com]
Sent: Monday, November 23, 2015 5:33 PM
To: 'Jeff Tantsura'; 'Acee Lindem (acee)'; 'Mach= Chen'; 'i2rs@ietf.org'
Cc: 'Jeffrey Haas'; 'Alia Atlas'; 'Benoit Claise= (bclaise)'
Subject: RE: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.tx= t

=C2=A0

Jeff and Acee:

=C2=A0

Your suggested change goes against the WG ad= opted RIB Information draft that has been discussed for over 2 years.=C2=A0= The informational draft has been through WG LC and you did not make any su= ggestions or comments during the WG LC.=C2=A0 Any change of this matter is not simply something you indicate to the auth= ors, but needs to be discussed on the WG as a direction change for the RIB = IM/DM models.

= =C2=A0

Indepen= dent of the I2RS efforts, milestones, and processes, I think we need to add= ress whether provisioning all these tunnels via RIB installation is =C2=A0a= ppropriate and, additionally, consistent with other WG YANG models. In many cases, it would seem there are tunnel a= ttributes other than the encaps that need to be provisioned. At a minimum, = I think you=E2=80=99d need to either reference an RFC describing soft tunne= l provisioning or describe the specifics of this provisioning.=C2=A0

= =C2=A0

=C2=A0

Prior to moving this change through WG adopt= ion cycle, the routing architectural team needs to have: a) concrete propos= al for the ephemeral state that covers I2RS RIB and https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ =C2=A0a= nd =C2=A0b) I requested this input of Acee Lindem as a representative of th= e routing architecture team. =C2=A0=C2=A0

= =C2=A0

The =C2= =A0identification of this problem with tunnel provisioning is a direct outc= ome of this effort.=C2=A0

= =C2=A0

=C2=A0

=C2=A0

I will be glad to work with you on a concret= e proposal that you can send to the email list and present at the I2RS inte= rim meeting on 12/16/2015 (10-11:30am ET).

= =C2=A0

I will = continue to work on ietf-routing alignment but don=E2=80=99t have the bandw= idth for the above.=C2=A0

= =C2=A0

Acee=C2= =A0

= =C2=A0

= =C2=A0

= =C2=A0

= =C2=A0

=C2=A0

=C2=A0Sue Hares

=C2=A0

-----Original Message-----
From: i2rs [mail= to:i2rs-bounces@ietf.org] On Behalf Of Jeff Tantsura
Sent: Monday, November 23, 2015 4:27 PM
To: Acee Lindem (acee); Mach Chen; i2rs@ietf.org
Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.txt

=C2=A0

Hi Mach,

=C2=A0

I agree with Acee=E2=80=99s comments and wou= ld encourage you to use generic/existing tunnel model(s), please see commen= ts provided during RTGWG meeting in Yokohama.

There are already too many, we need to ratio= nalize this work.

=C2=A0

This is what has been discussed in Yokohama,= Robin presented

=C2=A0

-- draft-li-rtgwg-utunnel-yang=

=C2=A0=C2=A0 -- draft-li-rtgwg-tunnel-policy= -yang

=C2=A0=C2=A0 -- draft-wwz-netmod-yang-tunnel= -cfg

=C2=A0=C2=A0 -- draft-zheng-intarea-gre-yang=

=C2=A0=C2=A0 -- draft-liu-intarea-gre-tunnel= -yang

=C2=A0=C2=A0 -- draft-liu-intarea-ipipv4-tun= nel-yang

=C2=A0

Cheers,

Jeff

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On 11/23/15, 11:56, "i2rs on behalf of = Acee Lindem (acee)" <i2rs-bounces@ietf.org on behalf of acee@cisco.com> wrote:

=C2=A0

>Hi Mach,

>=C2=A0

>I=E2=80=99m looking at draft-ietf-i2rs-r= ib-data-model-04.txt and it still

>includes all the tunnel encaps. I know y= ou received several comments

>that those should be in the tunnel model= (s) and this I2RS RIB model

>should merely reference an imported tunn= el abstraction. How are you

>going to address this? It seemed that th= e consensus (and an opinion

>that I share) was that this model should= not attempt to generically

>created tunnels via RIB/FIB entries.<= /u>

>Thanks,

>Acee

>=C2=A0

>On 11/23/15, 2:23 AM, "i2rs on beha= lf of Mach Chen"

><i2rs-bounces@ietf.org on behalf= of mach.chen@huawei.com> wrote:

>=C2=A0

>>Hi,

>>=C2=A0

>>We just uploaded an update that addr= esses the comments received

>>(include online and offline) recentl= y. Please review the draft and comment!

>>=C2=A0

>>Thanks,

>>Mach

>>=C2=A0

>>> -----Original Message-----

>>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of

>>>internet-drafts@ietf.org

>>> Sent: Monday, November 23, 2015= 3:16 PM

>>> To: i-d-announce@ietf.org=

>>> Cc: i2rs@ietf.org<= /a>

>>> Subject: [i2rs] I-D Action: dra= ft-ietf-i2rs-rib-data-model-04.txt

>>>

>>>

>>> A New Internet-Draft is availab= le from the on-line Internet-Drafts

>>>directories.

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

>>>Working Group=C2=A0 of the IETF.=

>>>

>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Title=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 : A YANG Data Model for Routing Information Base

>>> (RIB)

>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Authors=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = : Lixing Wang

>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Hariharan Ananthakrishn= an

>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Mach(Guoyi) Chen=

>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Amit Dass=

>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Sriganesh Kini

>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Nitin Bahadur=

>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Filename=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : draft-ietf-i2rs= -rib-data-model-04.txt

>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Pages=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : = 65

>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Date=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 : 2015-11-22

>>>

>>> Abstract:<= /p>

>>>=C2=A0=C2=A0=C2=A0 This document= defines a YANG data model for Routing Information Base

>>>=C2=A0=C2=A0=C2=A0 (RIB) that al= igns with the I2RS RIB information model.

>>>

>>>

>>>

>>> The IETF datatracker status pag= e for this draft is:

>>> https://datatracker.i= etf.org/doc/draft-ietf-i2rs-rib-data-model/=

>>>

>>> There's also a htmlized ver= sion available at:

>>> https://tools.ietf.or= g/html/draft-ietf-i2rs-rib-data-model-04

>>>

>>> A diff from the previous versio= n is available at:

>>> https://www.ietf.org/= rfcdiff?url2=3Ddraft-ietf-i2rs-rib-data-model-04

>>>

>>>

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

>>>submission=C2=A0 until the htmli= zed version and diff are available at

>>>tools.ietf.org.

>>>

>>> Internet-Drafts are also availa= ble by anonymous FTP at:

>>> ftp://ftp.ietf.org/in= ternet-drafts/

>>>

>>> _______________________________= ________________

>>> i2rs mailing list=

>>> i= 2rs@ietf.org

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

>>=C2=A0

>>____________________________________= ___________

>>i2rs mailing list

>>i2rs@i= etf.org

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

>=C2=A0

>________________________________________= _______

>i2rs mailing list

>i2rs@ietf= .org

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

____________________________________________= ___

i2rs mailing list

i2rs@ietf.org<= /span>

https://www.ietf.org/mailman/listinfo/i2rs=



--001a1134f382372cdf05254cac9e-- From nobody Tue Nov 24 09:44:13 2015 Return-Path: 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 7349E1B2FFD for ; Tue, 24 Nov 2015 09:44:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 uYkrVq-TkYE5 for ; Tue, 24 Nov 2015 09:44:06 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC9B81A6FC3 for ; Tue, 24 Nov 2015 09:44:05 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=99.82.244.89; From: "Susan Hares" To: "'Acee Lindem \(acee\)'" , "'Alia Atlas'" References: <20151123071558.25655.92641.idtracker@ietfa.amsl.com> <8D628270-A455-4E01-881F-BA20D544228D@ericsson.com> <041001d12640$9d5104b0$d7f30e10$@ndzh.com> <047901d12663$cb716880$62543980$@ndzh.com> In-Reply-To: Date: Tue, 24 Nov 2015 12:43:49 -0500 Message-ID: <002a01d126df$ad7dcb80$08796280$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002B_01D126B5.C4B57F20" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLzNuIIn4QWw/Hs75J8GiGq3b7+uQJO1DWoAiHpGU0CXgkCwwFVd58VAjQ3mH8CkBQvUAHQKi79AqSmpN8B9BrQK5vMwWQQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' , i2rs@ietf.org, 'Jeff Tantsura' Subject: Re: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 17:44:11 -0000 This is a multipart message in MIME format. ------=_NextPart_000_002B_01D126B5.C4B57F20 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Acee:=20 =20 Ah.. the light of understanding dawns. You think that the I2RS is = provisioning the tunnel rather than just pointing to it. I=E2=80=99ve = re-read the text again to see if I can understand it. =20 =20 Section 2.4.3 in the RIB Info model specifies how we will find the next = hop specified. The references all reduce to some combination of = interface to interfaces and/or addresses. The tunnel interface is just = another interface like egress interfaces. The reading of 7.2.1 is = expanding this section. The I2RS RIB does not provision the tunnel = because we expect other mechanisms within the system (like the proposed = tunnel drafts) would create these tunnels. =20 =20 Would a statement in 2.4.3 or 7.2 that I2RS RIB is utilizing tunnels or = interfaces created by other mechanisms be helpful?=20 =20 =20 Sue=20 =20 From: Acee Lindem (acee) [mailto:acee@cisco.com]=20 Sent: Tuesday, November 24, 2015 12:20 PM To: Alia Atlas Cc: Susan Hares; i2rs@ietf.org; Jeffrey Haas; Jeff Tantsura Subject: Re: [i2rs] FW: I-D Action: = draft-ietf-i2rs-rib-data-model-04.txt =20 Alia,=20 =20 From: Alia Atlas Date: Tuesday, November 24, 2015 at 12:08 PM To: Acee Lindem Cc: Susan Hares , "i2rs@ietf.org" , Jeff = Haas , Jeff Tantsura Subject: Re: [i2rs] FW: I-D Action: = draft-ietf-i2rs-rib-data-model-04.txt =20 Acee,=20 =20 As Sue has said, the I2RS Info Model has passed WGLC and is just waiting = for the DM to be done in order to progress. Obviously, substantial = technical concerns are always welcome - there's a long way between WGLC = and final IESG approval; I do not think that you have clearly described = your technical concerns. Are you mixing up using a tunnel for = forwarding with provisioning the tunnel?? =20 =20 =20 The I2RS RIB model is not for provisioning tunnels. It is intended so = that traffic can be forwarded properly, regardless of the abstraction. = For instance, with MPLS, a packet could be sent out with an arbitrary = label or label stack, a packet could follow an LSP, or a packet could = follow a tunnel. By providing the ability to forward via these = different layers of abstraction, the RIB model allows forwarding to = occur correctly even when a tunnel or LSP changes - just like a next-hop = can be specified to forward like a different prefix and then follows = that prefix. =20 I certainly do not see the I2RS RIB model as creating tunnels - but = merely being able to use ones that already exist. =20 I believe the intension of the model is clearly to dynamically create = the tunnels. =20 =20 Tunnel nexthops allow an external entity to program static tunnel headers. There can be cases where the remote tunnel end-point does not support dynamic signaling (e.g. no LDP support on a host) and in those cases the external entity might want to program the tunnel header on both ends of the tunnel. The tunnel nexthop is kept generic with specifications provided for some commonly used tunnels. It is expected that the data-model will model these tunnel types with complete accuracy. =20 =20 Now, if your objection is that the I2RS RIB model should use a common = grouping that describes all types of tunnels, I have yet to see one. = The efforts to provide YANG models for tunnels are still quite immature. Describing what types of groupings would be useful is the type of work = that I hope the design team will do. Asking I2RS to stall until time can be dedicated isn't appropriate. =20 Nor is not addressing comments on WG drafts=E2=80=A6=20 =20 Acee=20 =20 =20 =20 Regards, Alia =20 =20 =20 On Tue, Nov 24, 2015 at 8:34 AM, Acee Lindem (acee) = wrote: From: Susan Hares < shares@ndzh.com> Date: Monday, November 23, 2015 at 9:57 PM To: Acee Lindem , "i2rs@ietf.org" Cc: Alia Atlas , Jeff Haas , Jeff = Tantsura Subject: RE: [i2rs] FW: I-D Action: = draft-ietf-i2rs-rib-data-model-04.txt =20 Acee:=20 =20 Is your input individual input or input from the routing architecture = for yang models? =20 Individual.=20 =20 =20 =20 =20 The routing architecture for yang models is incomplete without the = consideration of the I2RS ephemeral state and I2RS architecture. Asking = the I2RS WG to change a document that is in WG LC based on an incomplete = architectural document is not reasonable. =20 =20 My comment with respect to tunnel provisioning is not based on any = architecture document.=20 =20 An alignment between = = https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ without = the consideration of the I2RS ephemeral state is an incomplete alignment = and a problematic approach for I2RS WG=E2=80=99s efforts. =20 =20 I2RS models should augment the base models with ephemeral state.=20 =20 =20 =20 In a volunteer organization, each person has the right to makes choices = in what they have time to do. If you do not have bandwidth to provide = an adequate routing architecture for yang models that considers = ephemeral state or its needs, that is your choice. Unless you have a = concrete proposal for the ephemeral state that covers I2RS RIB and = = https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/, the = I2RS WG LC will be closed after 2 week (11/23 =E2=80=93 12/7) WG review = of the in draft-ietf-i2rs-rib-data-model-04.txt. =20 =20 We have proposed tunnel models, draft-ietf-netmod-routing-cfg is not = meant to supplant them. BTW, we don=E2=80=99t plan to update = draft-ietf-i2rs-rib-data-model-04.txt. Updates based on I2RS will be in = the a next-hop augmentation draft that extends = draft-ietf-netmod-rtg-cfg.=20 =20 =20 =20 Please remember that the I2RS RIB model has two parts: I2RS = Informational Model and I2RS Data Model. The I2RS Informational Model = and the I2RS Data Model have descriptions on the soft tunnel = provisioning as mechanisms. Questions at this point must demonstrate a = knowledge of these documents or suggest specific changes to the = documents. If you wish to raise the following questions, please do = this in light of specific sections that include both the I2RS = Informational Model, the I2RS Data Model, and I2RS architecture.=20 =20 a) I2RS tunnels must include additions beyond encapsulation,=20 b) Why the I2RS Informational Model and the I2RS Data Model do not = provide the soft tunnel provisioning or describe the specifics of this = provision? =20 =20 The I2RS Informational Model has examples for these tunnels. You are = welcome to make proposal for specific changes to the I2RS Informational = Model or the I2RS Data Model. The I2RS Informational Model has = completed WG LC so the bar for substantive comments is high. =20 I don=E2=80=99t believe this excerpt from the RIB information models = describes soft tunnel provisioning for each of the tunnels proposed in = the RIB data model: =20 7.2.1. Tunnel nexthops =20 A tunnel nexthop points to a tunnel of some kind. Traffic that goes over the tunnel gets encapsulated with the tunnel encap. Tunnel nexthops are useful for abstracting out details of the network, by having the traffic seamlessly route between network edges. At the end of a tunnel, the tunnel will get decapsulated. Thus the grammar supports two kinds of operations, one for encap and another for decap. =20 Acee=20 =20 =20 =20 =20 =20 Cheers,=20 =20 Sue Hares=20 =20 From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Acee Lindem = (acee) Sent: Monday, November 23, 2015 7:30 PM To: Susan Hares; i2rs@ietf.org Subject: Re: [i2rs] FW: I-D Action: = draft-ietf-i2rs-rib-data-model-04.txt =20 Sue,=20 =20 From: i2rs on behalf of Susan Hares = Date: Monday, November 23, 2015 at 5:45 PM To: "i2rs@ietf.org" Subject: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt =20 Resending to I2RS WG.=20 =20 From: Susan Hares [mailto:shares@ndzh.com]=20 Sent: Monday, November 23, 2015 5:33 PM To: 'Jeff Tantsura'; 'Acee Lindem (acee)'; 'Mach Chen'; 'i2rs@ietf.org' Cc: 'Jeffrey Haas'; 'Alia Atlas'; 'Benoit Claise (bclaise)' Subject: RE: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.txt =20 Jeff and Acee:=20 =20 Your suggested change goes against the WG adopted RIB Information draft = that has been discussed for over 2 years. The informational draft has = been through WG LC and you did not make any suggestions or comments = during the WG LC. Any change of this matter is not simply something you = indicate to the authors, but needs to be discussed on the WG as a = direction change for the RIB IM/DM models. =20 Independent of the I2RS efforts, milestones, and processes, I think we = need to address whether provisioning all these tunnels via RIB = installation is appropriate and, additionally, consistent with other WG = YANG models. In many cases, it would seem there are tunnel attributes = other than the encaps that need to be provisioned. At a minimum, I think = you=E2=80=99d need to either reference an RFC describing soft tunnel = provisioning or describe the specifics of this provisioning.=20 =20 =20 Prior to moving this change through WG adoption cycle, the routing = architectural team needs to have: a) concrete proposal for the ephemeral = state that covers I2RS RIB and = https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ and b) = I requested this input of Acee Lindem as a representative of the routing = architecture team. =20 =20 The identification of this problem with tunnel provisioning is a direct = outcome of this effort.=20 =20 =20 =20 I will be glad to work with you on a concrete proposal that you can send = to the email list and present at the I2RS interim meeting on 12/16/2015 = (10-11:30am ET). =20 I will continue to work on ietf-routing alignment but don=E2=80=99t have = the bandwidth for the above.=20 =20 Acee=20 =20 =20 =20 =20 =20 Sue Hares=20 =20 -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Jeff Tantsura Sent: Monday, November 23, 2015 4:27 PM To: Acee Lindem (acee); Mach Chen; i2rs@ietf.org Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.txt =20 Hi Mach, =20 I agree with Acee=E2=80=99s comments and would encourage you to use = generic/existing tunnel model(s), please see comments provided during = RTGWG meeting in Yokohama. There are already too many, we need to rationalize this work. =20 This is what has been discussed in Yokohama, Robin presented =20 -- draft-li-rtgwg-utunnel-yang -- draft-li-rtgwg-tunnel-policy-yang -- draft-wwz-netmod-yang-tunnel-cfg -- draft-zheng-intarea-gre-yang -- draft-liu-intarea-gre-tunnel-yang -- draft-liu-intarea-ipipv4-tunnel-yang =20 Cheers, Jeff =20 =20 =20 =20 =20 =20 On 11/23/15, 11:56, "i2rs on behalf of Acee Lindem (acee)" < = = i2rs-bounces@ietf.org on behalf of acee@cisco.com> wrote: =20 >Hi Mach, >=20 >I=E2=80=99m looking at draft-ietf-i2rs-rib-data-model-04.txt and it = still=20 >includes all the tunnel encaps. I know you received several comments=20 >that those should be in the tunnel model(s) and this I2RS RIB model=20 >should merely reference an imported tunnel abstraction. How are you=20 >going to address this? It seemed that the consensus (and an opinion=20 >that I share) was that this model should not attempt to generically=20 >created tunnels via RIB/FIB entries. >Thanks, >Acee >=20 >On 11/23/15, 2:23 AM, "i2rs on behalf of Mach Chen"=20 >< = = i2rs-bounces@ietf.org on behalf of mach.chen@huawei.com> wrote: >=20 >>Hi, >>=20 >>We just uploaded an update that addresses the comments received=20 >>(include online and offline) recently. Please review the draft and = comment! >>=20 >>Thanks, >>Mach >>=20 >>> -----Original Message----- >>> From: i2rs [ = mailto:i2rs-bounces@ietf.org] On Behalf Of=20 >>> internet-drafts@ietf.org >>> Sent: Monday, November 23, 2015 3:16 PM >>> To: i-d-announce@ietf.org >>> Cc: i2rs@ietf.org >>> Subject: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.txt >>>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts=20 >>>directories. >>> This draft is a work item of the Interface to the Routing System=20 >>>Working Group of the IETF. >>>=20 >>> Title : A YANG Data Model for Routing Information = Base >>> (RIB) >>> Authors : Lixing Wang >>> Hariharan Ananthakrishnan >>> Mach(Guoyi) Chen >>> Amit Dass >>> Sriganesh Kini >>> Nitin Bahadur >>> Filename : draft-ietf-i2rs-rib-data-model-04.txt >>> Pages : 65 >>> Date : 2015-11-22 >>>=20 >>> Abstract: >>> This document defines a YANG data model for Routing Information = Base >>> (RIB) that aligns with the I2RS RIB information model. >>>=20 >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> = https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/ >>>=20 >>> There's also a htmlized version available at: >>> = https://tools.ietf.org/html/draft-ietf-i2rs-rib-data-model-04 >>>=20 >>> A diff from the previous version is available at: >>> = = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2rs-rib-data-model-04 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of=20 >>>submission until the htmlized version and diff are available at=20 >>>tools.ietf.org. >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> = ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> = https://www.ietf.org/mailman/listinfo/i2rs >>=20 >>_______________________________________________ >>i2rs mailing list >> i2rs@ietf.org >> = https://www.ietf.org/mailman/listinfo/i2rs >=20 >_______________________________________________ >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 =20 ------=_NextPart_000_002B_01D126B5.C4B57F20 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Acee:

<WG hat off>

Ah.. the light of understanding dawns. =C2=A0You think that the I2RS = is provisioning the tunnel rather than just pointing to it.=C2=A0=C2=A0 = I=E2=80=99ve re-read the text again to see if I can understand it.=C2=A0 =

 

Section 2.4.3 in the RIB Info model specifies how we will find the = next hop specified.=C2=A0 The references all reduce to some combination = of interface to interfaces and/or addresses.=C2=A0 The tunnel interface = is just another interface like egress interfaces. =C2=A0=C2=A0The = reading of 7.2.1 =C2=A0is expanding this section.=C2=A0 =C2=A0=C2=A0The = I2RS RIB does not provision the tunnel because we expect other = mechanisms within the system (like the proposed tunnel drafts) would = create these tunnels.=C2=A0 =C2=A0

 

Would a statement in 2.4.3 or 7.2 that I2RS RIB is utilizing tunnels = or interfaces created by other mechanisms be helpful? =

<WG hat on>

 

Sue

 

From:= = Acee Lindem (acee) [mailto:acee@cisco.com]
Sent: Tuesday, = November 24, 2015 12:20 PM
To: Alia Atlas
Cc: Susan = Hares; i2rs@ietf.org; Jeffrey Haas; Jeff Tantsura
Subject: Re: = [i2rs] FW: I-D Action: = draft-ietf-i2rs-rib-data-model-04.txt

 

Alia, 

 

From: Alia Atlas <akatlas@gmail.com>
Date: = Tuesday, November 24, 2015 at 12:08 PM
To: Acee Lindem = <acee@cisco.com>
Cc: = Susan Hares <shares@ndzh.com>, "i2rs@ietf.org" <i2rs@ietf.org>, Jeff Haas <jhaas@pfrc.org>, Jeff Tantsura = <jeff.tantsura@ericsson.com= >
Subject: Re: [i2rs] FW: I-D Action: = draft-ietf-i2rs-rib-data-model-04.txt

 

Acee,

 

As Sue has said, the I2RS Info Model has passed WGLC and is just = waiting for the DM to be done in order to progress.  Obviously, = substantial technical concerns are always welcome - there's a long way = between WGLC and final IESG approval; I do not think that you have = clearly described your technical concerns.  Are you mixing up using = a tunnel for forwarding with provisioning the tunnel?? =  

 

 

The I2RS RIB model is not for provisioning tunnels.  It is = intended so that traffic can be forwarded properly, regardless of the = abstraction.  For instance, with MPLS, a packet could be sent out = with an arbitrary label or label stack, a packet could follow an LSP, or = a packet could follow a tunnel.   By providing the ability to = forward via these different layers of abstraction, the RIB model allows = forwarding to occur correctly even when a tunnel or LSP changes - just = like a next-hop can be specified to forward like a different prefix and = then follows that prefix.

 

I certainly do not see the I2RS RIB model as creating tunnels - but = merely being able to use ones that already = exist.

 

I believe the intension of the model is clearly to dynamically create = the tunnels.  

 

   Tunnel = nexthops allow an external entity to program static = tunnel

   headers. =  There can be cases where the remote tunnel end-point = does

   not support = dynamic signaling (e.g. no LDP support on a host) and = in

   those cases = the external entity might want to program the = tunnel

   header on both = ends of the tunnel.  The tunnel nexthop is = kept

   generic with = specifications provided for some commonly used = tunnels.

   It is expected = that the data-model will model these tunnel types = with

   complete = accuracy.

 

 

Now, if your objection is that the I2RS RIB model should use a common = grouping that describes all types of tunnels, I have yet to see = one.  The efforts to provide YANG models for tunnels are still = quite immature.

Describing what types of groupings would be useful is the type of work = that I hope the design team will = do.

Asking I2RS to stall until time can be dedicated isn't = appropriate.

 

Nor is not addressing comments on WG = drafts=E2=80=A6 

 

Acee 

 

 

 

Regards,

Alia

 

 

 

On Tue, Nov 24, 2015 at 8:34 AM, Acee Lindem (acee) <acee@cisco.com> = wrote:

From: Susan Hares <shares@ndzh.com>

Date: Monday, November 23, 2015 at 9:57 PM
To: Acee Lindem <acee@cisco.com>, = "i2rs@ietf.org" <i2rs@ietf.org>
Cc: Alia Atlas <akatlas@gmail.com>, Jeff Haas <jhaas@pfrc.org>, = Jeff Tantsura <jeff.tantsura@ericsson.com>
Subject: = RE: [i2rs] FW: I-D Action: = draft-ietf-i2rs-rib-data-model-04.txt

 

Acee:

 

Is your input individual input or input from the = routing architecture for yang = models?

 

Individual. 

 

 

 

<I2RS chair hat on> =

The routing architecture for yang models is incomplete without the = consideration of the I2RS ephemeral state and I2RS architecture.  = Asking the I2RS WG to change a document that is in WG LC based on an = incomplete architectural document is not reasonable. =  

 

My comment with respect to tunnel provisioning is not based on any = architecture document. 

 

An alignment between https://datatracker.ietf.org/doc/draft-ietf-ne= tmod-routing-cfg/ without the consideration of the I2RS = ephemeral state is an incomplete alignment and a problematic =  approach for I2RS WG=E2=80=99s efforts. =   

 

I2RS models should augment the base models with ephemeral = state. 

 

 

 

In a volunteer organization, each person has the = right to makes choices in what they have time to do.   If you = do not have bandwidth to provide an adequate routing architecture for = yang models that considers ephemeral state or its needs, that is your = choice.  Unless you have a concrete proposal for the ephemeral = state that covers I2RS RIB and https://datatracker.ietf.org/doc/draft-ietf-ne= tmod-routing-cfg/, the I2RS WG LC will be closed after 2 week = (11/23 =E2=80=93 12/7) WG review of the in = draft-ietf-i2rs-rib-data-model-04.txt.  =   

 

We have proposed tunnel models, draft-ietf-netmod-routing-cfg is not = meant to supplant them. BTW, we don=E2=80=99t plan to = update draft-ietf-i2rs-rib-data-model-04.txt. Updates based on I2RS = will be in the a next-hop augmentation draft that extends = draft-ietf-netmod-rtg-cfg. 

 

 

 

Please remember that the I2RS RIB model has two = parts:  I2RS Informational Model and I2RS Data Model.  The = I2RS Informational Model and the I2RS Data Model have descriptions on = the soft tunnel provisioning as mechanisms.  Questions at this = point must demonstrate a knowledge of these documents or suggest = specific changes to the documents.   If you wish to raise the = following questions, please do this in light of specific sections that = include both the I2RS Informational Model, the I2RS Data Model, and I2RS = architecture.

 

a)      = I2RS tunnels must include additions beyond encapsulation, =

b)      = Why the I2RS Informational Model and the I2RS Data Model do not provide = the soft tunnel provisioning or describe the specifics of this = provision? 

 

The I2RS Informational Model has examples for = these tunnels.  You are welcome to make proposal for specific = changes to the I2RS Informational Model or the I2RS Data Model.  = The I2RS Informational Model has completed WG LC so the bar for = substantive comments is = high.

 

I don=E2=80=99t believe this excerpt from the RIB information models = describes soft tunnel provisioning for each of the tunnels proposed in = the RIB data model:

 

7.2.1.  Tunnel nexthops

 

   A tunnel nexthop points to a tunnel of some kind.  = Traffic that goes

   over the tunnel gets encapsulated with the tunnel = encap.  Tunnel

   nexthops are useful for abstracting out details of the = network, by

   having the traffic seamlessly route between network = edges.  At the

   end of a tunnel, the tunnel will get decapsulated.  = Thus the grammar

   supports two kinds of operations, one for encap and = another for

   decap.

 

Acee 

 

 

    

<I2RS chair hat off> =

 

Cheers,

 

Sue Hares

 

= From:= i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of = Acee Lindem (acee)
Sent: Monday, November 23, 2015 7:30 = PM
To: Susan Hares; i2rs@ietf.org
Subject: Re: [i2rs] FW: = I-D Action: draft-ietf-i2rs-rib-data-model-04.txt

 

Sue, 

 

From: i2rs = <i2rs-bounces@ietf.org> on behalf of Susan Hares = <shares@ndzh.com>
Date: Monday, = November 23, 2015 at 5:45 PM
To: "i2rs@ietf.org" = <i2rs@ietf.org>
Subject: [i2rs] FW: = I-D Action: = draft-ietf-i2rs-rib-data-model-04.txt

 

Resending to I2RS WG.

 

= From:= Susan Hares [mailto:shares@ndzh.com]
Sent: Monday, = November 23, 2015 5:33 PM
To: 'Jeff Tantsura'; 'Acee Lindem = (acee)'; 'Mach Chen'; 'i2rs@ietf.org'
Cc: 'Jeffrey Haas'; = 'Alia Atlas'; 'Benoit Claise (bclaise)'
Subject: RE: [i2rs] = I-D Action: draft-ietf-i2rs-rib-data-model-04.txt

 

Jeff and Acee:

 

Your suggested change goes against the WG adopted RIB Information draft = that has been discussed for over 2 years.  The informational draft = has been through WG LC and you did not make any suggestions or comments = during the WG LC.  Any change of this matter is not simply = something you indicate to the authors, but needs to be discussed on the = WG as a direction change for the RIB IM/DM = models.

 

Independent of the I2RS efforts, = milestones, and processes, I think we need to address whether = provisioning all these tunnels via RIB installation is  appropriate = and, additionally, consistent with other WG YANG models. In many cases, = it would seem there are tunnel attributes other than the encaps that = need to be provisioned. At a minimum, I think you=E2=80=99d need to = either reference an RFC describing soft tunnel provisioning or describe = the specifics of this provisioning. 

 

 

Prior to moving this change through WG adoption cycle, the routing = architectural team needs to have: a) concrete proposal for the ephemeral = state that covers I2RS RIB and https://datatracker.ietf.org/doc/draft-ietf-netmod-rout= ing-cfg/  and  b) I requested this input of Acee Lindem as = a representative of the routing architecture team. =   

 

The  identification of this = problem with tunnel provisioning is a direct outcome of this = effort. 

 

 

 

I will be glad to work with you on a concrete proposal that you can = send to the email list and present at the I2RS interim meeting on = 12/16/2015 (10-11:30am = ET).

 

I will continue to work on = ietf-routing alignment but don=E2=80=99t have the bandwidth for the = above. 

 

Acee 

 

 

 

 

 

 Sue Hares

 

-----Original Message-----
From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Jeff = Tantsura
Sent: Monday, November 23, 2015 4:27 PM
To: Acee Lindem = (acee); Mach Chen; i2rs@ietf.org
Subject: Re: [i2rs] I-D Action: = draft-ietf-i2rs-rib-data-model-04.txt

 

Hi Mach,

 

I agree with Acee=E2=80=99s comments and would encourage you to use = generic/existing tunnel model(s), please see comments provided during = RTGWG meeting in Yokohama.

There are already too many, we need to rationalize this = work.

 

This is what has been discussed in Yokohama, Robin = presented

 

-- draft-li-rtgwg-utunnel-yang

   -- = draft-li-rtgwg-tunnel-policy-yang

   -- = draft-wwz-netmod-yang-tunnel-cfg

   -- = draft-zheng-intarea-gre-yang

   -- = draft-liu-intarea-gre-tunnel-yang

   -- = draft-liu-intarea-ipipv4-tunnel-yang

 

Cheers,

Jeff

 

 

 

 

 

 

On 11/23/15, 11:56, "i2rs on behalf of Acee Lindem (acee)" = <i2rs-bounces@ietf.org on = behalf of acee@cisco.com> = wrote:

 

>Hi Mach,

> 

>I=E2=80=99m looking at draft-ietf-i2rs-rib-data-model-04.txt and it = still

>includes all the tunnel encaps. I know you received several = comments

>that those should be in the tunnel model(s) and this I2RS RIB model =

>should merely reference an imported tunnel abstraction. How are you =

>going to address this? It seemed that the consensus (and an opinion =

>that I share) was that this model should not attempt to generically =

>created tunnels via RIB/FIB entries.

>Thanks,

>Acee

> 

>On 11/23/15, 2:23 AM, "i2rs on behalf of Mach Chen" =

><i2rs-bounces@ietf.org on = behalf of mach.chen@huawei.com> = wrote:

> 

>>Hi,

>> 

>>We just uploaded an update that addresses the comments received =

>>(include online and offline) recently. Please review the draft = and comment!

>> 

>>Thanks,

>>Mach

>> 

>>> -----Original Message-----

>>> From: i2rs [mailto:i2rs-bounces@ietf.= org] On Behalf Of

>>>internet-drafts@ietf.org<= /span>

>>> Sent: Monday, November 23, 2015 3:16 = PM

>>> To: i-d-announce@ietf.org

>>> Cc: i2rs@ietf.org<= o:p>

>>> Subject: [i2rs] I-D Action: = draft-ietf-i2rs-rib-data-model-04.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           : A = YANG Data Model for Routing Information = Base

>>> (RIB)

>>>         = Authors         : Lixing = Wang

>>>          =             &= nbsp;    Hariharan = Ananthakrishnan

>>>          =             &= nbsp;    Mach(Guoyi) Chen

>>>          =             &= nbsp;    Amit Dass

>>>          =             &= nbsp;    Sriganesh Kini

>>>          =             &= nbsp;    Nitin Bahadur

>>>        = Filename        : = draft-ietf-i2rs-rib-data-model-04.txt

>>>        = Pages           : = 65

>>>        = Date            : = 2015-11-22

>>>

>>> Abstract:

>>>    This document defines a YANG data model = for Routing Information Base

>>>    (RIB) that aligns with the I2RS RIB = information model.

>>>

>>>

>>>

>>> The IETF datatracker status page for this draft = is:

>>> https://datatracker.ietf.= org/doc/draft-ietf-i2rs-rib-data-model/

<= p>>>>

>>> There's also a htmlized version available = at:

>>> https://tools.ietf.org/ht= ml/draft-ietf-i2rs-rib-data-model-04

<= span = style=3D'font-size:10.5pt;font-family:"Calibri","sans-serif";color:black'= >>>>

>>> A diff from the previous version is available = at:

>>> https://www.ietf.org/rfcd= iff?url2=3Ddraft-ietf-i2rs-rib-data-model-04=

>>>

>>>

>>> 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/intern= et-drafts/

>>>

>>> = _______________________________________________

<= span = style=3D'font-size:10.5pt;font-family:"Calibri","sans-serif";color:black'= >>>> i2rs mailing list

>>> i2rs@ietf.org<= o:p>

>>> https://www.ietf.org/mail= man/listinfo/i2rs

>> 

>>_______________________________________________

>>i2rs mailing list

>>i2rs@ietf.org<= o:p>

>>https://www.ietf.org/mail= man/listinfo/i2rs

> 

>_______________________________________________

>i2rs mailing list

>i2rs@ietf.org<= o:p>

>https://www.ietf.org/mail= man/listinfo/i2rs

_______________________________________________

= i2rs mailing list

i2rs@ietf.org<= o:p>

https://www.ietf.org/mail= man/listinfo/i2rs

 

= ------=_NextPart_000_002B_01D126B5.C4B57F20-- From nobody Tue Nov 24 12:22:56 2015 Return-Path: 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 82C3B1A8968 for ; Tue, 24 Nov 2015 12:22:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 js3A-vgQ5lIY for ; Tue, 24 Nov 2015 12:22:52 -0800 (PST) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (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 7F52B1A895C for ; Tue, 24 Nov 2015 12:22:52 -0800 (PST) Received: by qgec40 with SMTP id c40so18803204qge.2 for ; Tue, 24 Nov 2015 12:22:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Z0xX0vxlAcnBdIZd/mVPRWWGuW/nV0SnMZ+F7goX1rE=; b=gUavqFS0OxD8hWQDgLHFsbUqbyuglNS3cEIYLGmNquIbSTwx1foO/V07Oni6Hcfb/0 XI4sUJMEFug1VQZylwKOH5IlrM1ayJY7aC1uttoIFK1MqhADsmIzGCMUBpAZCzsdGrjm G4qdSTJxum9TBZeutlG+yPPKKnNydMaaq4GHHq+ncZqOkJZlNb9rT4QLdFV3cI5otVgm fT2XxwzMBHARbINcap6LfLeIkCGLOtnY1EnqSBDg3b6m7tMIr+qRQ5Dx+m4zMVRQ1sKA IO0LFw+s6eHH2Sytl11JyU4ehv9a3Xurh8UvpVTt+jabGuSykDGD62YQASSMBxMiKGf+ fAxA== X-Received: by 10.140.92.16 with SMTP id a16mr35942220qge.54.1448396571682; Tue, 24 Nov 2015 12:22:51 -0800 (PST) Received: from [192.168.128.73] ([192.64.64.178]) by smtp.gmail.com with ESMTPSA id g84sm4633443qkb.10.2015.11.24.12.22.50 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 24 Nov 2015 12:22:51 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_869EC6D3-2EDA-4BE9-8693-5705C57974DE" Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Dean Bogdanovic In-Reply-To: <047901d12663$cb716880$62543980$@ndzh.com> Date: Tue, 24 Nov 2015 15:22:50 -0500 Message-Id: <3DD0B55F-79B0-4C04-8F68-41DEFB7C512D@gmail.com> References: <20151123071558.25655.92641.idtracker@ietfa.amsl.com> <8D628270-A455-4E01-881F-BA20D544228D@ericsson.com> <041001d12640$9d5104b0$d7f30e10$@ndzh.com> <047901d12663$cb716880$62543980$@ndzh.com> To: Susan Hares X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: Jeffrey Haas , i2rs@ietf.org, "Acee Lindem \(acee\)" , Jeff Tantsura , Alia Atlas Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 20:22:54 -0000 --Apple-Mail=_869EC6D3-2EDA-4BE9-8693-5705C57974DE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Sue, As Alia says, in-line as always :) > On Nov 23, 2015, at 9:57 PM, Susan Hares wrote: >=20 > Acee:=20 > =20 > Is your input individual input or input from the routing architecture = for yang models?=20 > =20 > =20 > The routing architecture for yang models is incomplete without the = consideration of the I2RS ephemeral state and I2RS architecture. Asking = the I2RS WG to change a document that is in WG LC based on an incomplete = architectural document is not reasonable. An alignment between = https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ = = without the consideration of the I2RS ephemeral state is an incomplete = alignment and a problematic approach for I2RS WG=E2=80=99s efforts. =20= I=E2=80=99m still trying to figure out what is exactly I2RS ephemeral = state. RIB and FIB by definition are ephemeral. Results of routing = protocols are ephemeral. The only persistence in it are input parameters = that will define the initial behavior of the protocol, but after that = everything is ephemeral. IMO, I2RS agent should almost have no persistence configuration, except = basic management and the I2RS client definitions. Dean --Apple-Mail=_869EC6D3-2EDA-4BE9-8693-5705C57974DE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Sue,

As = Alia says, in-line as always :)

On = Nov 23, 2015, at 9:57 PM, Susan Hares <shares@ndzh.com> = wrote:

Acee: 
 
Is your = input individual input or input from the routing architecture for yang = models? 
 
<I2RS = chair hat on> 
The = routing architecture for yang models is incomplete without the = consideration of the I2RS ephemeral state and I2RS architecture.  = Asking the I2RS WG to change a document that is in WG LC based on an = incomplete architectural document is not reasonable.  An alignment = between https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/=  without the consideration = of the I2RS ephemeral state is an incomplete alignment and a problematic =  approach for I2RS WG=E2=80=99s efforts. =   

I=E2=80=99m still trying to figure out what = is exactly I2RS ephemeral state. RIB and FIB by definition are = ephemeral. Results of routing protocols are ephemeral. The only = persistence in it are input parameters that will define the initial = behavior of the protocol, but after that everything is = ephemeral.
IMO, I2RS agent should almost have no persistence = configuration, except basic management and the I2RS client = definitions.

Dean

= --Apple-Mail=_869EC6D3-2EDA-4BE9-8693-5705C57974DE-- From nobody Tue Nov 24 13:24:42 2015 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 75CB31A8A45; Tue, 24 Nov 2015 13:24:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF Announcement List" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151124212440.16836.87222.idtracker@ietfa.amsl.com> Date: Tue, 24 Nov 2015 13:24:40 -0800 Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] I2RS WG Virtual Interim Meetings X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 21:24:40 -0000 The Interface to the Routing System (I2RS) Working Group will hold a series of virtual interim meetings as follows: Date: 2015-12-16 Time: 10:00-11:30 EST / 15:00-16:30 UTC Ephemeral State, Protocol Strawman, FB-RIB, Service Topology Date: 2016-01-13 Time: 10:00-11:30 EST / 15:00-16:30 UTC I2RS Protocol update, I2RS BGP, OSPF, ISIS Models Date: 2016-01-27 Time: 10:00-11:30 EST / 15:00-16:30 UTC I2RS protocol Update, TRILL, MPLS, BGP Extended Models Date: 2016-02-10 Time: 10:00-11:30 EST / 15:00-16:30 UTC I2RS protocol proposal Date: 2016-02-24 Time: 10:00-11:30 EST / 15:00-16:30 UTC I2RS Protocol and I2RS Data Model Date: 2016-03-09 Time: 10:00-11:30 EST / 15:00-16:30 UTC I2RS Protocol and Data Models On 2015-12-16, 2016-01-27, 2016-02-24, and 2016-03-09, there will be a second set of virtual meetings at 10:00-11:30pm EST to take input from the Asia timezones. Topics are as follows: Date: 2015-12-16 Time: 21:00-22:30 EST / 02:00-03:30 UTC (2015-12-17) / 10:00-11:30 China Ephemeral State, Protocol Strawman, FB-RIB, Service Topology Date: 2016-01-27 Time: 21:00-22:30 EST / 02:00-03:30 UTC (2016-01-28) / 10:00-11:30 China I2RS protocol Update, TRILL, MPLS, BGP Extended Models Date: 2016-02-24 Time: 21:00-22:30 EST / 02:00-03:30 UTC (2016-02-25) / 10:00-11:30 China I2RS Protocol and I2RS Data Model Date: 2016-03-09 Time: 21:00-22:30 EST / 02:00-03:30 UTC (2016-03-10) / 10:00-11:30 China I2RS Protocol and Data Models WebEx details will follow on the I2RS mailing list. From nobody Tue Nov 24 17:34:40 2015 Return-Path: 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 A26D71ACAD5 for ; Tue, 24 Nov 2015 17:34:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.786 X-Spam-Level: X-Spam-Status: No, score=-4.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham 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 ZXp-uYp-qmTj for ; Tue, 24 Nov 2015 17:34:38 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 140571ACAD8 for ; Tue, 24 Nov 2015 17:34:34 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CAT57561; Wed, 25 Nov 2015 01:34:32 +0000 (GMT) Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 25 Nov 2015 01:34:32 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.73]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0235.001; Wed, 25 Nov 2015 09:34:24 +0800 From: Mach Chen To: "Acee Lindem (acee)" , "i2rs@ietf.org" Thread-Topic: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.txt Thread-Index: AQHRJb7gDQr+c8ugKk+zT8tYpLAi3J6pMp/ggABNzICAAUjpIA== Date: Wed, 25 Nov 2015 01:34:24 +0000 Message-ID: References: <20151123071558.25655.92641.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.135] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.56551029.0046, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.73, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a43e0b35c4c1724f11c96fd0896ae150 Archived-At: Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 01:34:39 -0000 SGkgQWNlZSwNCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzIQ0KDQpUaGlzIGRhdGEgbW9kZWwg aXMgdG90YWxseSBhbGlnbmVkIHdpdGggdGhlIGRlZmluaXRpb24gb2YgdGhlIGluZm8gbW9kZWwg dGhhdCBoYXMgYWxyZWFkeSBwYXNzZWQgdGhlIFdHIExDLiBTbywgSSB0aGluayB0aGUgZmlyc3Qg c3RlcCBpcyB0byBkaXNjdXNzIHdoZXRoZXIgdGhlIGNoYW5nZXMgc2hvdWxkIGJlIG1hZGUgdG8g dGhlIGluZm8gbW9kZWwuIElmIHRoZXJlIGlzIGEgY29uc2Vuc3VzIHRvIG1ha2UgdGhlIGNoYW5n ZXMsIGl0IHNob3VsZCBiZSBlYXN5IHRvIHVwZGF0ZSB0aGUgZGF0YSBtb2RlbCBhY2NvcmRpbmds eS4gDQoNCkluIHRoZSBtb2RlbCwgdGhlIGRlc2NyaXB0aW9uIG9mIHRoZSB0dW5uZWwtZW5jYXAg bmV4dGhvcCBzYXlzOg0KDQoiVGhpcyBjYW4gYmUgYW4gZW5jYXAgcmVwcmVzZW50aW5nIGFuIElQ IHR1bm5lbCBvcg0KICAgICAgICAgICAgIE1QTFMgdHVubmVsIG9yIG90aGVycyBhcyBkZWZpbmVk IGluIGluZm8gbW9kZWwuDQogICAgICAgICAgICAgQW4gb3B0aW9uYWwgZWdyZXNzIGludGVyZmFj ZSBjYW4gYmUgY2hhaW5lZCB0byB0aGUNCiAgICAgICAgICAgICB0dW5uZWwgZW5jYXAgdG8gaW5k aWNhdGUgd2hpY2ggaW50ZXJmYWNlIHRvIHNlbmQNCiAgICAgICAgICAgICB0aGUgcGFja2V0IG91 dC4gIFRoZSBlZ3Jlc3MgaW50ZXJmYWNlIGlzIHVzZWZ1bA0KICAgICAgICAgICAgIHdoZW4gdGhl IG5ldHdvcmsgZGV2aWNlIGNvbnRhaW5zIEV0aGVybmV0IGludGVyZmFjZXMNCiAgICAgICAgICAg ICBhbmQgb25lIG5lZWRzIHRvIHBlcmZvcm0gYWRkcmVzcyByZXNvbHV0aW9uIGZvciB0aGUNCiAg ICAgICAgICAgICBJUCBwYWNrZXQuIjsNCg0KU28sIElNSE8sIHRoZSBtb2RlbCBqdXN0IHRyZWF0 cyBhIHR1bm5lbCBhcyB0aGUgbmV4dGhvcCwgaXQgZG9lcyBub3QgaW50ZW5kIHRvIGNyZWF0ZSBh IHR1bm5lbCBhbmQganVzdCB1c2VzIGFuIGV4aXN0aW5nIG9uZS4gDQoNCkJlc3QgcmVnYXJkcywN Ck1hY2gNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBY2VlIExpbmRl bSAoYWNlZSkgW21haWx0bzphY2VlQGNpc2NvLmNvbV0NCj4gU2VudDogVHVlc2RheSwgTm92ZW1i ZXIgMjQsIDIwMTUgMzo1NiBBTQ0KPiBUbzogTWFjaCBDaGVuOyBpMnJzQGlldGYub3JnDQo+IFN1 YmplY3Q6IFJlOiBbaTJyc10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1pMnJzLXJpYi1kYXRhLW1v ZGVsLTA0LnR4dA0KPiANCj4gSGkgTWFjaCwNCj4gDQo+IEnigJltIGxvb2tpbmcgYXQgZHJhZnQt aWV0Zi1pMnJzLXJpYi1kYXRhLW1vZGVsLTA0LnR4dCBhbmQgaXQgc3RpbGwgaW5jbHVkZXMgYWxs IHRoZQ0KPiB0dW5uZWwgZW5jYXBzLiBJIGtub3cgeW91IHJlY2VpdmVkIHNldmVyYWwgY29tbWVu dHMgdGhhdCB0aG9zZSBzaG91bGQgYmUgaW4NCj4gdGhlIHR1bm5lbCBtb2RlbChzKSBhbmQgdGhp cyBJMlJTIFJJQiBtb2RlbCBzaG91bGQgbWVyZWx5IHJlZmVyZW5jZSBhbg0KPiBpbXBvcnRlZCB0 dW5uZWwgYWJzdHJhY3Rpb24uIEhvdyBhcmUgeW91IGdvaW5nIHRvIGFkZHJlc3MgdGhpcz8gSXQg c2VlbWVkDQo+IHRoYXQgdGhlIGNvbnNlbnN1cyAoYW5kIGFuIG9waW5pb24gdGhhdCBJIHNoYXJl KSB3YXMgdGhhdCB0aGlzIG1vZGVsIHNob3VsZCBub3QNCj4gYXR0ZW1wdCB0byBnZW5lcmljYWxs eSBjcmVhdGVkIHR1bm5lbHMgdmlhIFJJQi9GSUIgZW50cmllcy4NCj4gVGhhbmtzLA0KPiBBY2Vl DQo+IA0KPiBPbiAxMS8yMy8xNSwgMjoyMyBBTSwgImkycnMgb24gYmVoYWxmIG9mIE1hY2ggQ2hl biIgPGkycnMtYm91bmNlc0BpZXRmLm9yZw0KPiBvbiBiZWhhbGYgb2YgbWFjaC5jaGVuQGh1YXdl aS5jb20+IHdyb3RlOg0KPiANCj4gPkhpLA0KPiA+DQo+ID5XZSBqdXN0IHVwbG9hZGVkIGFuIHVw ZGF0ZSB0aGF0IGFkZHJlc3NlcyB0aGUgY29tbWVudHMgcmVjZWl2ZWQNCj4gPihpbmNsdWRlIG9u bGluZSBhbmQgb2ZmbGluZSkgcmVjZW50bHkuIFBsZWFzZSByZXZpZXcgdGhlIGRyYWZ0IGFuZCBj b21tZW50IQ0KPiA+DQo+ID5UaGFua3MsDQo+ID5NYWNoDQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogaTJycyBbbWFpbHRvOmkycnMtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mDQo+ID4+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQo+ID4+IFNl bnQ6IE1vbmRheSwgTm92ZW1iZXIgMjMsIDIwMTUgMzoxNiBQTQ0KPiA+PiBUbzogaS1kLWFubm91 bmNlQGlldGYub3JnDQo+ID4+IENjOiBpMnJzQGlldGYub3JnDQo+ID4+IFN1YmplY3Q6IFtpMnJz XSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWkycnMtcmliLWRhdGEtbW9kZWwtMDQudHh0DQo+ID4+ DQo+ID4+DQo+ID4+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBv bi1saW5lIEludGVybmV0LURyYWZ0cw0KPiA+PmRpcmVjdG9yaWVzLg0KPiA+PiAgVGhpcyBkcmFm dCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgSW50ZXJmYWNlIHRvIHRoZSBSb3V0aW5nIFN5c3RlbQ0K PiA+PldvcmtpbmcgR3JvdXAgIG9mIHRoZSBJRVRGLg0KPiA+Pg0KPiA+PiAgICAgICAgIFRpdGxl ICAgICAgICAgICA6IEEgWUFORyBEYXRhIE1vZGVsIGZvciBSb3V0aW5nIEluZm9ybWF0aW9uDQo+ IEJhc2UNCj4gPj4gKFJJQikNCj4gPj4gICAgICAgICBBdXRob3JzICAgICAgICAgOiBMaXhpbmcg V2FuZw0KPiA+PiAgICAgICAgICAgICAgICAgICAgICAgICAgIEhhcmloYXJhbiBBbmFudGhha3Jp c2huYW4NCj4gPj4gICAgICAgICAgICAgICAgICAgICAgICAgICBNYWNoKEd1b3lpKSBDaGVuDQo+ ID4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgQW1pdCBEYXNzDQo+ID4+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgU3JpZ2FuZXNoIEtpbmkNCj4gPj4gICAgICAgICAgICAgICAgICAgICAg ICAgICBOaXRpbiBCYWhhZHVyDQo+ID4+IAlGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWky cnMtcmliLWRhdGEtbW9kZWwtMDQudHh0DQo+ID4+IAlQYWdlcyAgICAgICAgICAgOiA2NQ0KPiA+ PiAJRGF0ZSAgICAgICAgICAgIDogMjAxNS0xMS0yMg0KPiA+Pg0KPiA+PiBBYnN0cmFjdDoNCj4g Pj4gICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgWUFORyBkYXRhIG1vZGVsIGZvciBSb3V0aW5n IEluZm9ybWF0aW9uIEJhc2UNCj4gPj4gICAgKFJJQikgdGhhdCBhbGlnbnMgd2l0aCB0aGUgSTJS UyBSSUIgaW5mb3JtYXRpb24gbW9kZWwuDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IFRoZSBJRVRG IGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPiA+PiBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWkycnMtcmliLWRhdGEtbW9kZWwv DQo+ID4+DQo+ID4+IFRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0 Og0KPiA+PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pMnJzLXJpYi1k YXRhLW1vZGVsLTA0DQo+ID4+DQo+ID4+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9u IGlzIGF2YWlsYWJsZSBhdDoNCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwy PWRyYWZ0LWlldGYtaTJycy1yaWItZGF0YS1tb2RlbC0wNA0KPiA+Pg0KPiA+Pg0KPiA+PiBQbGVh c2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGlt ZSBvZg0KPiA+PnN1Ym1pc3Npb24gIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZm IGFyZSBhdmFpbGFibGUgYXQNCj4gPj50b29scy5pZXRmLm9yZy4NCj4gPj4NCj4gPj4gSW50ZXJu ZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPiA+PiBm dHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPiA+Pg0KPiA+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiBpMnJzIG1haWxpbmcg bGlzdA0KPiA+PiBpMnJzQGlldGYub3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaTJycw0KPiA+DQo+ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+aTJycyBtYWlsaW5nIGxpc3QNCj4gPmkycnNAaWV0Zi5vcmcN Cj4gPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJycw0KDQo= From nobody Tue Nov 24 18:03:26 2015 Return-Path: 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 4A64E1ACD8C for ; Tue, 24 Nov 2015 18:03:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.786 X-Spam-Level: X-Spam-Status: No, score=-4.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham 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 2hHPpwUGBYTB for ; Tue, 24 Nov 2015 18:03:22 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A844F1ACD89 for ; Tue, 24 Nov 2015 18:03:21 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CEO33378; Wed, 25 Nov 2015 02:03:19 +0000 (GMT) Received: from SZXEMA414-HUB.china.huawei.com (10.82.72.73) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 25 Nov 2015 02:03:17 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.73]) by SZXEMA414-HUB.china.huawei.com ([10.82.72.73]) with mapi id 14.03.0235.001; Wed, 25 Nov 2015 10:03:14 +0800 From: Mach Chen To: Alia Atlas , "Acee Lindem (acee)" Thread-Topic: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt Thread-Index: AQHRJtrKHIeC3DY8u0KVWIoMo7l5y56r/FoQgAAAK7A= Date: Wed, 25 Nov 2015 02:03:12 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.135] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.565516E7.0090, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.73, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: fff93857598fc410cc7c7df501dba5fd Archived-At: Cc: Jeffrey Haas , "i2rs@ietf.org" , Susan Hares , Jeff Tantsura Subject: Re: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 02:03:25 -0000 SGkgQWxpYSwgQWNlZSBhbmQgb3RoZXJzLA0KDQo+IEZyb206IGkycnMgW21haWx0bzppMnJzLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbGlhIEF0bGFzDQo+IFNlbnQ6IFdlZG5lc2Rh eSwgTm92ZW1iZXIgMjUsIDIwMTUgMTowOCBBTQ0KPiBUbzogQWNlZSBMaW5kZW0gKGFjZWUpDQo+ IENjOiBKZWZmcmV5IEhhYXM7IGkycnNAaWV0Zi5vcmc7IEplZmYgVGFudHN1cmE7IFN1c2FuIEhh cmVzDQo+IFN1YmplY3Q6IFJlOiBbaTJyc10gRlc6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtaTJy cy1yaWItZGF0YS1tb2RlbC0wNC50eHQNCj4gDQo+IEFjZWUsDQo+IA0KPiBBcyBTdWUgaGFzIHNh aWQsIHRoZSBJMlJTIEluZm8gTW9kZWwgaGFzIHBhc3NlZCBXR0xDIGFuZCBpcyBqdXN0IHdhaXRp bmcgZm9yDQo+IHRoZSBETSB0byBiZSBkb25lIGluIG9yZGVyIHRvIHByb2dyZXNzLsKgIE9idmlv dXNseSwgc3Vic3RhbnRpYWwgdGVjaG5pY2FsDQo+IGNvbmNlcm5zIGFyZSBhbHdheXMgd2VsY29t ZSAtIHRoZXJlJ3MgYSBsb25nIHdheSBiZXR3ZWVuIFdHTEMgYW5kIGZpbmFsDQo+IElFU0cgYXBw cm92YWw7IEkgZG8gbm90IHRoaW5rIHRoYXQgeW91IGhhdmUgY2xlYXJseSBkZXNjcmliZWQgeW91 ciB0ZWNobmljYWwNCj4gY29uY2VybnMuwqAgQXJlIHlvdSBtaXhpbmcgdXAgdXNpbmcgYSB0dW5u ZWwgZm9yIGZvcndhcmRpbmcgd2l0aCBwcm92aXNpb25pbmcNCj4gdGhlIHR1bm5lbD8/DQo+IA0K PiBUaGUgSTJSUyBSSUIgbW9kZWwgaXMgbm90IGZvciBwcm92aXNpb25pbmcgdHVubmVscy7CoCBJ dCBpcyBpbnRlbmRlZCBzbyB0aGF0DQo+IHRyYWZmaWMgY2FuIGJlIGZvcndhcmRlZCBwcm9wZXJs eSwgcmVnYXJkbGVzcyBvZiB0aGUgYWJzdHJhY3Rpb24uwqAgRm9yIGluc3RhbmNlLA0KPiB3aXRo IE1QTFMsIGEgcGFja2V0IGNvdWxkIGJlIHNlbnQgb3V0IHdpdGggYW4gYXJiaXRyYXJ5IGxhYmVs IG9yIGxhYmVsIHN0YWNrLCBhDQo+IHBhY2tldCBjb3VsZCBmb2xsb3cgYW4gTFNQLCBvciBhIHBh Y2tldCBjb3VsZCBmb2xsb3cgYSB0dW5uZWwuIMKgIEJ5IHByb3ZpZGluZw0KPiB0aGUgYWJpbGl0 eSB0byBmb3J3YXJkIHZpYSB0aGVzZSBkaWZmZXJlbnQgbGF5ZXJzIG9mIGFic3RyYWN0aW9uLCB0 aGUgUklCIG1vZGVsDQo+IGFsbG93cyBmb3J3YXJkaW5nIHRvIG9jY3VyIGNvcnJlY3RseSBldmVu IHdoZW4gYSB0dW5uZWwgb3IgTFNQIGNoYW5nZXMgLSBqdXN0DQo+IGxpa2UgYSBuZXh0LWhvcCBj YW4gYmUgc3BlY2lmaWVkIHRvIGZvcndhcmQgbGlrZSBhIGRpZmZlcmVudCBwcmVmaXggYW5kIHRo ZW4NCj4gZm9sbG93cyB0aGF0IHByZWZpeC4NCj4gDQo+IEkgY2VydGFpbmx5IGRvIG5vdCBzZWUg dGhlIEkyUlMgUklCIG1vZGVsIGFzIGNyZWF0aW5nIHR1bm5lbHMgLSBidXQgbWVyZWx5IGJlaW5n DQo+IGFibGUgdG8gdXNlIG9uZXMgdGhhdCBhbHJlYWR5IGV4aXN0Lg0KDQpJIHRvdGFsbHkgYWdy ZWUgd2l0aCB0aGlzLg0KDQpCZXN0IHJlZ2FyZHMsDQpNYWNoDQo+IA0KPiBOb3csIGlmIHlvdXIg b2JqZWN0aW9uIGlzIHRoYXQgdGhlIEkyUlMgUklCIG1vZGVsIHNob3VsZCB1c2UgYSBjb21tb24N Cj4gZ3JvdXBpbmcgdGhhdCBkZXNjcmliZXMgYWxsIHR5cGVzIG9mIHR1bm5lbHMsIEkgaGF2ZSB5 ZXQgdG8gc2VlIG9uZS7CoCBUaGUgZWZmb3J0cw0KPiB0byBwcm92aWRlIFlBTkcgbW9kZWxzIGZv ciB0dW5uZWxzIGFyZSBzdGlsbCBxdWl0ZSBpbW1hdHVyZS4NCj4gRGVzY3JpYmluZyB3aGF0IHR5 cGVzIG9mIGdyb3VwaW5ncyB3b3VsZCBiZSB1c2VmdWwgaXMgdGhlIHR5cGUgb2Ygd29yayB0aGF0 IEkNCj4gaG9wZSB0aGUgZGVzaWduIHRlYW0gd2lsbCBkby4NCj4gQXNraW5nIEkyUlMgdG8gc3Rh bGwgdW50aWwgdGltZSBjYW4gYmUgZGVkaWNhdGVkIGlzbid0IGFwcHJvcHJpYXRlLg0KPiANCj4g UmVnYXJkcywNCj4gQWxpYQ0KPiANCj4gDQo+IA0KPiBPbiBUdWUsIE5vdiAyNCwgMjAxNSBhdCA4 OjM0IEFNLCBBY2VlIExpbmRlbSAoYWNlZSkgPGFjZWVAY2lzY28uY29tPg0KPiB3cm90ZToNCj4g RnJvbTogU3VzYW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbT4NCj4gRGF0ZTogTW9uZGF5LCBOb3Zl bWJlciAyMywgMjAxNSBhdCA5OjU3IFBNDQo+IFRvOiBBY2VlIExpbmRlbSA8YWNlZUBjaXNjby5j b20+LCAiaTJyc0BpZXRmLm9yZyIgPGkycnNAaWV0Zi5vcmc+DQo+IENjOiBBbGlhIEF0bGFzIDxh a2F0bGFzQGdtYWlsLmNvbT4sIEplZmYgSGFhcyA8amhhYXNAcGZyYy5vcmc+LCBKZWZmIFRhbnRz dXJhDQo+IDxqZWZmLnRhbnRzdXJhQGVyaWNzc29uLmNvbT4NCj4gU3ViamVjdDogUkU6IFtpMnJz XSBGVzogSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1pMnJzLXJpYi1kYXRhLW1vZGVsLTA0LnR4dA0K PiANCj4gQWNlZToNCj4gDQo+IElzIHlvdXIgaW5wdXQgaW5kaXZpZHVhbCBpbnB1dCBvciBpbnB1 dCBmcm9tIHRoZSByb3V0aW5nIGFyY2hpdGVjdHVyZSBmb3IgeWFuZw0KPiBtb2RlbHM/DQo+IA0K PiBJbmRpdmlkdWFsLg0KPiANCj4gDQo+IA0KPiA8STJSUyBjaGFpciBoYXQgb24+DQo+IFRoZSBy b3V0aW5nIGFyY2hpdGVjdHVyZSBmb3IgeWFuZyBtb2RlbHMgaXMgaW5jb21wbGV0ZSB3aXRob3V0 IHRoZQ0KPiBjb25zaWRlcmF0aW9uIG9mIHRoZSBJMlJTIGVwaGVtZXJhbCBzdGF0ZSBhbmQgSTJS UyBhcmNoaXRlY3R1cmUuwqAgQXNraW5nIHRoZQ0KPiBJMlJTIFdHIHRvIGNoYW5nZSBhIGRvY3Vt ZW50IHRoYXQgaXMgaW4gV0cgTEMgYmFzZWQgb24gYW4gaW5jb21wbGV0ZQ0KPiBhcmNoaXRlY3R1 cmFsIGRvY3VtZW50IGlzIG5vdCByZWFzb25hYmxlLg0KPiANCj4gTXkgY29tbWVudCB3aXRoIHJl c3BlY3QgdG8gdHVubmVsIHByb3Zpc2lvbmluZyBpcyBub3QgYmFzZWQgb24gYW55DQo+IGFyY2hp dGVjdHVyZSBkb2N1bWVudC4NCj4gDQo+IEFuIGFsaWdubWVudCBiZXR3ZWVuDQo+IGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0bW9kLXJvdXRpbmctY2ZnL8Kg d2l0aG91dCB0aGUNCj4gY29uc2lkZXJhdGlvbiBvZiB0aGUgSTJSUyBlcGhlbWVyYWwgc3RhdGUg aXMgYW4gaW5jb21wbGV0ZSBhbGlnbm1lbnQgYW5kIGENCj4gcHJvYmxlbWF0aWMgwqBhcHByb2Fj aCBmb3IgSTJSUyBXR+KAmXMgZWZmb3J0cy4NCj4gDQo+IEkyUlMgbW9kZWxzIHNob3VsZCBhdWdt ZW50IHRoZSBiYXNlIG1vZGVscyB3aXRoIGVwaGVtZXJhbCBzdGF0ZS4NCj4gDQo+IA0KPiANCj4g SW4gYSB2b2x1bnRlZXIgb3JnYW5pemF0aW9uLCBlYWNoIHBlcnNvbiBoYXMgdGhlIHJpZ2h0IHRv IG1ha2VzIGNob2ljZXMgaW4gd2hhdA0KPiB0aGV5IGhhdmUgdGltZSB0byBkby7CoMKgIElmIHlv dSBkbyBub3QgaGF2ZSBiYW5kd2lkdGggdG8gcHJvdmlkZSBhbiBhZGVxdWF0ZQ0KPiByb3V0aW5n IGFyY2hpdGVjdHVyZSBmb3IgeWFuZyBtb2RlbHMgdGhhdCBjb25zaWRlcnMgZXBoZW1lcmFsIHN0 YXRlIG9yIGl0cw0KPiBuZWVkcywgdGhhdCBpcyB5b3VyIGNob2ljZS7CoCBVbmxlc3MgeW91IGhh dmUgYSBjb25jcmV0ZSBwcm9wb3NhbCBmb3IgdGhlDQo+IGVwaGVtZXJhbCBzdGF0ZSB0aGF0IGNv dmVycyBJMlJTIFJJQiBhbmQNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1uZXRtb2Qtcm91dGluZy1jZmcvLCB0aGUgSTJSUyBXRw0KPiBMQyB3aWxsIGJlIGNs b3NlZCBhZnRlciAyIHdlZWsgKDExLzIzIOKAkyAxMi83KSBXRyByZXZpZXcgb2YgdGhlIGluDQo+ IGRyYWZ0LWlldGYtaTJycy1yaWItZGF0YS1tb2RlbC0wNC50eHQuDQo+IA0KPiBXZSBoYXZlIHBy b3Bvc2VkIHR1bm5lbCBtb2RlbHMsIGRyYWZ0LWlldGYtbmV0bW9kLXJvdXRpbmctY2ZnIGlzIG5v dCBtZWFudCB0bw0KPiBzdXBwbGFudCB0aGVtLiBCVFcsIHdlIGRvbuKAmXQgcGxhbiB0bw0KPiB1 cGRhdGXCoGRyYWZ0LWlldGYtaTJycy1yaWItZGF0YS1tb2RlbC0wNC50eHQuIFVwZGF0ZXMgYmFz ZWQgb24gSTJSUyB3aWxsIGJlIGluDQo+IHRoZSBhIG5leHQtaG9wIGF1Z21lbnRhdGlvbiBkcmFm dCB0aGF0IGV4dGVuZHMgZHJhZnQtaWV0Zi1uZXRtb2QtcnRnLWNmZy4NCj4gDQo+IA0KPiANCj4g UGxlYXNlIHJlbWVtYmVyIHRoYXQgdGhlIEkyUlMgUklCIG1vZGVsIGhhcyB0d28gcGFydHM6wqAg STJSUyBJbmZvcm1hdGlvbmFsDQo+IE1vZGVsIGFuZCBJMlJTIERhdGEgTW9kZWwuwqAgVGhlIEky UlMgSW5mb3JtYXRpb25hbCBNb2RlbCBhbmQgdGhlIEkyUlMNCj4gRGF0YSBNb2RlbCBoYXZlIGRl c2NyaXB0aW9ucyBvbiB0aGUgc29mdCB0dW5uZWwgcHJvdmlzaW9uaW5nIGFzDQo+IG1lY2hhbmlz bXMuwqAgUXVlc3Rpb25zIGF0IHRoaXMgcG9pbnQgbXVzdCBkZW1vbnN0cmF0ZSBhIGtub3dsZWRn ZSBvZg0KPiB0aGVzZSBkb2N1bWVudHMgb3Igc3VnZ2VzdCBzcGVjaWZpYyBjaGFuZ2VzIHRvIHRo ZSBkb2N1bWVudHMuIMKgwqBJZiB5b3Ugd2lzaA0KPiB0byByYWlzZSB0aGUgZm9sbG93aW5nIHF1 ZXN0aW9ucywgcGxlYXNlIGRvIHRoaXMgaW4gbGlnaHQgb2Ygc3BlY2lmaWMgc2VjdGlvbnMgdGhh dA0KPiBpbmNsdWRlIGJvdGggdGhlIEkyUlMgSW5mb3JtYXRpb25hbCBNb2RlbCwgdGhlIEkyUlMg RGF0YSBNb2RlbCwgYW5kIEkyUlMNCj4gYXJjaGl0ZWN0dXJlLg0KPiANCj4gYSnCoMKgwqDCoMKg IEkyUlMgdHVubmVscyBtdXN0IGluY2x1ZGUgYWRkaXRpb25zIGJleW9uZCBlbmNhcHN1bGF0aW9u LA0KPiBiKcKgwqDCoMKgwqAgV2h5IHRoZSBJMlJTIEluZm9ybWF0aW9uYWwgTW9kZWwgYW5kIHRo ZSBJMlJTIERhdGEgTW9kZWwgZG8gbm90DQo+IHByb3ZpZGUgdGhlIHNvZnQgdHVubmVsIHByb3Zp c2lvbmluZyBvciBkZXNjcmliZSB0aGUgc3BlY2lmaWNzIG9mIHRoaXMgcHJvdmlzaW9uPw0KPiAN Cj4gVGhlIEkyUlMgSW5mb3JtYXRpb25hbCBNb2RlbCBoYXMgZXhhbXBsZXMgZm9yIHRoZXNlIHR1 bm5lbHMuwqAgWW91IGFyZQ0KPiB3ZWxjb21lIHRvIG1ha2UgcHJvcG9zYWwgZm9yIHNwZWNpZmlj IGNoYW5nZXMgdG8gdGhlIEkyUlMgSW5mb3JtYXRpb25hbA0KPiBNb2RlbCBvciB0aGUgSTJSUyBE YXRhIE1vZGVsLsKgIFRoZSBJMlJTIEluZm9ybWF0aW9uYWwgTW9kZWwgaGFzIGNvbXBsZXRlZA0K PiBXRyBMQyBzbyB0aGUgYmFyIGZvciBzdWJzdGFudGl2ZSBjb21tZW50cyBpcyBoaWdoLg0KPiAN Cj4gSSBkb27igJl0IGJlbGlldmUgdGhpcyBleGNlcnB0IGZyb20gdGhlIFJJQiBpbmZvcm1hdGlv biBtb2RlbHMgZGVzY3JpYmVzIHNvZnQNCj4gdHVubmVsIHByb3Zpc2lvbmluZyBmb3IgZWFjaCBv ZiB0aGUgdHVubmVscyBwcm9wb3NlZCBpbiB0aGUgUklCIGRhdGEgbW9kZWw6DQo+IA0KPiA3LjIu MS7CoCBUdW5uZWwgbmV4dGhvcHMNCj4gDQo+IMKgIMKgQSB0dW5uZWwgbmV4dGhvcCBwb2ludHMg dG8gYSB0dW5uZWwgb2Ygc29tZSBraW5kLsKgIFRyYWZmaWMgdGhhdCBnb2VzDQo+IMKgIMKgb3Zl ciB0aGUgdHVubmVsIGdldHMgZW5jYXBzdWxhdGVkIHdpdGggdGhlIHR1bm5lbCBlbmNhcC7CoCBU dW5uZWwNCj4gwqAgwqBuZXh0aG9wcyBhcmUgdXNlZnVsIGZvciBhYnN0cmFjdGluZyBvdXQgZGV0 YWlscyBvZiB0aGUgbmV0d29yaywgYnkNCj4gwqAgwqBoYXZpbmcgdGhlIHRyYWZmaWMgc2VhbWxl c3NseSByb3V0ZSBiZXR3ZWVuIG5ldHdvcmsgZWRnZXMuwqAgQXQgdGhlDQo+IMKgIMKgZW5kIG9m IGEgdHVubmVsLCB0aGUgdHVubmVsIHdpbGwgZ2V0IGRlY2Fwc3VsYXRlZC7CoCBUaHVzIHRoZSBn cmFtbWFyDQo+IMKgIMKgc3VwcG9ydHMgdHdvIGtpbmRzIG9mIG9wZXJhdGlvbnMsIG9uZSBmb3Ig ZW5jYXAgYW5kIGFub3RoZXIgZm9yDQo+IMKgIMKgZGVjYXAuDQo+IA0KPiBBY2VlDQo+IA0KPiAN Cj4gDQo+IDxJMlJTIGNoYWlyIGhhdCBvZmY+DQo+IA0KPiBDaGVlcnMsDQo+IA0KPiBTdWUgSGFy ZXMNCj4gDQo+IEZyb206IGkycnMgW21haWx0bzppMnJzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBBY2VlIExpbmRlbSAoYWNlZSkNCj4gU2VudDogTW9uZGF5LCBOb3ZlbWJlciAyMywg MjAxNSA3OjMwIFBNDQo+IFRvOiBTdXNhbiBIYXJlczsgaTJyc0BpZXRmLm9yZw0KPiBTdWJqZWN0 OiBSZTogW2kycnNdIEZXOiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWkycnMtcmliLWRhdGEtbW9k ZWwtMDQudHh0DQo+IA0KPiBTdWUsDQo+IA0KPiBGcm9tOiBpMnJzIDxpMnJzLWJvdW5jZXNAaWV0 Zi5vcmc+IG9uIGJlaGFsZiBvZiBTdXNhbiBIYXJlcw0KPiA8c2hhcmVzQG5kemguY29tPg0KPiBE YXRlOiBNb25kYXksIE5vdmVtYmVyIDIzLCAyMDE1IGF0IDU6NDUgUE0NCj4gVG86ICJpMnJzQGll dGYub3JnIiA8aTJyc0BpZXRmLm9yZz4NCj4gU3ViamVjdDogW2kycnNdIEZXOiBJLUQgQWN0aW9u OiBkcmFmdC1pZXRmLWkycnMtcmliLWRhdGEtbW9kZWwtMDQudHh0DQo+IA0KPiBSZXNlbmRpbmcg dG8gSTJSUyBXRy4NCj4gDQo+IEZyb206IFN1c2FuIEhhcmVzIFttYWlsdG86c2hhcmVzQG5kemgu Y29tXQ0KPiBTZW50OiBNb25kYXksIE5vdmVtYmVyIDIzLCAyMDE1IDU6MzMgUE0NCj4gVG86ICdK ZWZmIFRhbnRzdXJhJzsgJ0FjZWUgTGluZGVtIChhY2VlKSc7ICdNYWNoIENoZW4nOyAnaTJyc0Bp ZXRmLm9yZycNCj4gQ2M6ICdKZWZmcmV5IEhhYXMnOyAnQWxpYSBBdGxhcyc7ICdCZW5vaXQgQ2xh aXNlIChiY2xhaXNlKScNCj4gU3ViamVjdDogUkU6IFtpMnJzXSBJLUQgQWN0aW9uOiBkcmFmdC1p ZXRmLWkycnMtcmliLWRhdGEtbW9kZWwtMDQudHh0DQo+IA0KPiBKZWZmIGFuZCBBY2VlOg0KPiAN Cj4gWW91ciBzdWdnZXN0ZWQgY2hhbmdlIGdvZXMgYWdhaW5zdCB0aGUgV0cgYWRvcHRlZCBSSUIg SW5mb3JtYXRpb24gZHJhZnQNCj4gdGhhdCBoYXMgYmVlbiBkaXNjdXNzZWQgZm9yIG92ZXIgMiB5 ZWFycy7CoCBUaGUgaW5mb3JtYXRpb25hbCBkcmFmdCBoYXMgYmVlbg0KPiB0aHJvdWdoIFdHIExD IGFuZCB5b3UgZGlkIG5vdCBtYWtlIGFueSBzdWdnZXN0aW9ucyBvciBjb21tZW50cyBkdXJpbmcg dGhlDQo+IFdHIExDLsKgIEFueSBjaGFuZ2Ugb2YgdGhpcyBtYXR0ZXIgaXMgbm90IHNpbXBseSBz b21ldGhpbmcgeW91IGluZGljYXRlIHRvIHRoZQ0KPiBhdXRob3JzLCBidXQgbmVlZHMgdG8gYmUg ZGlzY3Vzc2VkIG9uIHRoZSBXRyBhcyBhIGRpcmVjdGlvbiBjaGFuZ2UgZm9yIHRoZSBSSUINCj4g SU0vRE0gbW9kZWxzLg0KPiANCj4gSW5kZXBlbmRlbnQgb2YgdGhlIEkyUlMgZWZmb3J0cywgbWls ZXN0b25lcywgYW5kIHByb2Nlc3NlcywgSSB0aGluayB3ZSBuZWVkIHRvDQo+IGFkZHJlc3Mgd2hl dGhlciBwcm92aXNpb25pbmcgYWxsIHRoZXNlIHR1bm5lbHMgdmlhIFJJQiBpbnN0YWxsYXRpb24N Cj4gaXMgwqBhcHByb3ByaWF0ZSBhbmQsIGFkZGl0aW9uYWxseSwgY29uc2lzdGVudCB3aXRoIG90 aGVyIFdHIFlBTkcgbW9kZWxzLiBJbg0KPiBtYW55IGNhc2VzLCBpdCB3b3VsZCBzZWVtIHRoZXJl IGFyZSB0dW5uZWwgYXR0cmlidXRlcyBvdGhlciB0aGFuIHRoZSBlbmNhcHMNCj4gdGhhdCBuZWVk IHRvIGJlIHByb3Zpc2lvbmVkLiBBdCBhIG1pbmltdW0sIEkgdGhpbmsgeW914oCZZCBuZWVkIHRv IGVpdGhlcg0KPiByZWZlcmVuY2UgYW4gUkZDIGRlc2NyaWJpbmcgc29mdCB0dW5uZWwgcHJvdmlz aW9uaW5nIG9yIGRlc2NyaWJlIHRoZSBzcGVjaWZpY3Mgb2YNCj4gdGhpcyBwcm92aXNpb25pbmcu DQo+IA0KPiANCj4gUHJpb3IgdG8gbW92aW5nIHRoaXMgY2hhbmdlIHRocm91Z2ggV0cgYWRvcHRp b24gY3ljbGUsIHRoZSByb3V0aW5nDQo+IGFyY2hpdGVjdHVyYWwgdGVhbSBuZWVkcyB0byBoYXZl OiBhKSBjb25jcmV0ZSBwcm9wb3NhbCBmb3IgdGhlIGVwaGVtZXJhbCBzdGF0ZQ0KPiB0aGF0IGNv dmVycyBJMlJTIFJJQiBhbmQNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1uZXRtb2Qtcm91dGluZy1jZmcvIMKgYW5kIMKgYikgSQ0KPiByZXF1ZXN0ZWQgdGhp cyBpbnB1dCBvZiBBY2VlIExpbmRlbSBhcyBhIHJlcHJlc2VudGF0aXZlIG9mIHRoZSByb3V0aW5n DQo+IGFyY2hpdGVjdHVyZSB0ZWFtLg0KPiANCj4gVGhlIMKgaWRlbnRpZmljYXRpb24gb2YgdGhp cyBwcm9ibGVtIHdpdGggdHVubmVsIHByb3Zpc2lvbmluZyBpcyBhIGRpcmVjdCBvdXRjb21lDQo+ IG9mIHRoaXMgZWZmb3J0Lg0KPiANCj4gDQo+IA0KPiBJIHdpbGwgYmUgZ2xhZCB0byB3b3JrIHdp dGggeW91IG9uIGEgY29uY3JldGUgcHJvcG9zYWwgdGhhdCB5b3UgY2FuIHNlbmQgdG8gdGhlDQo+ IGVtYWlsIGxpc3QgYW5kIHByZXNlbnQgYXQgdGhlIEkyUlMgaW50ZXJpbSBtZWV0aW5nIG9uIDEy LzE2LzIwMTUgKDEwLTExOjMwYW0NCj4gRVQpLg0KPiANCj4gSSB3aWxsIGNvbnRpbnVlIHRvIHdv cmsgb24gaWV0Zi1yb3V0aW5nIGFsaWdubWVudCBidXQgZG9u4oCZdCBoYXZlIHRoZSBiYW5kd2lk dGgNCj4gZm9yIHRoZSBhYm92ZS4NCj4gDQo+IEFjZWUNCj4gDQo+IA0KPiANCj4gDQo+IA0KPiDC oFN1ZSBIYXJlcw0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaTJy cyBbbWFpbHRvOmkycnMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEplZmYgVGFudHN1 cmENCj4gU2VudDogTW9uZGF5LCBOb3ZlbWJlciAyMywgMjAxNSA0OjI3IFBNDQo+IFRvOiBBY2Vl IExpbmRlbSAoYWNlZSk7IE1hY2ggQ2hlbjsgaTJyc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTog W2kycnNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtaTJycy1yaWItZGF0YS1tb2RlbC0wNC50eHQN Cj4gDQo+IEhpIE1hY2gsDQo+IA0KPiBJIGFncmVlIHdpdGggQWNlZeKAmXMgY29tbWVudHMgYW5k IHdvdWxkIGVuY291cmFnZSB5b3UgdG8gdXNlDQo+IGdlbmVyaWMvZXhpc3RpbmcgdHVubmVsIG1v ZGVsKHMpLCBwbGVhc2Ugc2VlIGNvbW1lbnRzIHByb3ZpZGVkIGR1cmluZw0KPiBSVEdXRyBtZWV0 aW5nIGluIFlva29oYW1hLg0KPiBUaGVyZSBhcmUgYWxyZWFkeSB0b28gbWFueSwgd2UgbmVlZCB0 byByYXRpb25hbGl6ZSB0aGlzIHdvcmsuDQo+IA0KPiBUaGlzIGlzIHdoYXQgaGFzIGJlZW4gZGlz Y3Vzc2VkIGluIFlva29oYW1hLCBSb2JpbiBwcmVzZW50ZWQNCj4gDQo+IC0tIGRyYWZ0LWxpLXJ0 Z3dnLXV0dW5uZWwteWFuZw0KPiDCoMKgIC0tIGRyYWZ0LWxpLXJ0Z3dnLXR1bm5lbC1wb2xpY3kt eWFuZw0KPiDCoMKgIC0tIGRyYWZ0LXd3ei1uZXRtb2QteWFuZy10dW5uZWwtY2ZnDQo+IMKgwqAg LS0gZHJhZnQtemhlbmctaW50YXJlYS1ncmUteWFuZw0KPiDCoMKgIC0tIGRyYWZ0LWxpdS1pbnRh cmVhLWdyZS10dW5uZWwteWFuZw0KPiDCoMKgIC0tIGRyYWZ0LWxpdS1pbnRhcmVhLWlwaXB2NC10 dW5uZWwteWFuZw0KPiANCj4gQ2hlZXJzLA0KPiBKZWZmDQo+IA0KPiANCj4gDQo+IA0KPiANCj4g DQo+IE9uIDExLzIzLzE1LCAxMTo1NiwgImkycnMgb24gYmVoYWxmIG9mIEFjZWUgTGluZGVtIChh Y2VlKSINCj4gPGkycnMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgYWNlZUBjaXNjby5j b20+IHdyb3RlOg0KPiANCj4gPkhpIE1hY2gsDQo+ID4NCj4gPknigJltIGxvb2tpbmcgYXQgZHJh ZnQtaWV0Zi1pMnJzLXJpYi1kYXRhLW1vZGVsLTA0LnR4dCBhbmQgaXQgc3RpbGwNCj4gPmluY2x1 ZGVzIGFsbCB0aGUgdHVubmVsIGVuY2Fwcy4gSSBrbm93IHlvdSByZWNlaXZlZCBzZXZlcmFsIGNv bW1lbnRzDQo+ID50aGF0IHRob3NlIHNob3VsZCBiZSBpbiB0aGUgdHVubmVsIG1vZGVsKHMpIGFu ZCB0aGlzIEkyUlMgUklCIG1vZGVsDQo+ID5zaG91bGQgbWVyZWx5IHJlZmVyZW5jZSBhbiBpbXBv cnRlZCB0dW5uZWwgYWJzdHJhY3Rpb24uIEhvdyBhcmUgeW91DQo+ID5nb2luZyB0byBhZGRyZXNz IHRoaXM/IEl0IHNlZW1lZCB0aGF0IHRoZSBjb25zZW5zdXMgKGFuZCBhbiBvcGluaW9uDQo+ID50 aGF0IEkgc2hhcmUpIHdhcyB0aGF0IHRoaXMgbW9kZWwgc2hvdWxkIG5vdCBhdHRlbXB0IHRvIGdl bmVyaWNhbGx5DQo+ID5jcmVhdGVkIHR1bm5lbHMgdmlhIFJJQi9GSUIgZW50cmllcy4NCj4gPlRo YW5rcywNCj4gPkFjZWUNCj4gPg0KPiA+T24gMTEvMjMvMTUsIDI6MjMgQU0sICJpMnJzIG9uIGJl aGFsZiBvZiBNYWNoIENoZW4iDQo+ID48aTJycy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBv ZiBtYWNoLmNoZW5AaHVhd2VpLmNvbT4gd3JvdGU6DQo+ID4NCj4gPj5IaSwNCj4gPj4NCj4gPj5X ZSBqdXN0IHVwbG9hZGVkIGFuIHVwZGF0ZSB0aGF0IGFkZHJlc3NlcyB0aGUgY29tbWVudHMgcmVj ZWl2ZWQNCj4gPj4oaW5jbHVkZSBvbmxpbmUgYW5kIG9mZmxpbmUpIHJlY2VudGx5LiBQbGVhc2Ug cmV2aWV3IHRoZSBkcmFmdCBhbmQgY29tbWVudCENCj4gPj4NCj4gPj5UaGFua3MsDQo+ID4+TWFj aA0KPiA+Pg0KPiA+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+IEZyb206IGky cnMgW21haWx0bzppMnJzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiA+Pj5pbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmcNCj4gPj4+IFNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMjMsIDIw MTUgMzoxNiBQTQ0KPiA+Pj4gVG86IGktZC1hbm5vdW5jZUBpZXRmLm9yZw0KPiA+Pj4gQ2M6IGky cnNAaWV0Zi5vcmcNCj4gPj4+IFN1YmplY3Q6IFtpMnJzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRm LWkycnMtcmliLWRhdGEtbW9kZWwtMDQudHh0DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IEEgTmV3IElu dGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0 cw0KPiA+Pj5kaXJlY3Rvcmllcy4NCj4gPj4+wqAgVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBv ZiB0aGUgSW50ZXJmYWNlIHRvIHRoZSBSb3V0aW5nIFN5c3RlbQ0KPiA+Pj5Xb3JraW5nIEdyb3Vw wqAgb2YgdGhlIElFVEYuDQo+ID4+Pg0KPiA+Pj7CoMKgwqDCoMKgwqDCoMKgIFRpdGxlwqDCoMKg wqDCoMKgwqDCoMKgwqAgOiBBIFlBTkcgRGF0YSBNb2RlbCBmb3IgUm91dGluZw0KPiBJbmZvcm1h dGlvbg0KPiA+Pj5CYXNlDQo+ID4+PiAoUklCKQ0KPiA+Pj7CoMKgwqDCoMKgwqDCoMKgIEF1dGhv cnPCoMKgwqDCoMKgwqDCoMKgIDogTGl4aW5nIFdhbmcNCj4gPj4+wqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBIYXJpaGFyYW4gQW5hbnRoYWtyaXNo bmFuDQo+ID4+PsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqAgTWFjaChHdW95aSkgQ2hlbg0KPiA+Pj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIEFtaXQgRGFzcw0KPiA+Pj7CoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFNyaWdhbmVzaCBLaW5pDQo+ID4+ PsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgTml0 aW4gQmFoYWR1cg0KPiA+Pj4gwqDCoMKgwqDCoMKgIEZpbGVuYW1lwqDCoMKgwqDCoMKgwqAgOiBk cmFmdC1pZXRmLWkycnMtcmliLWRhdGEtbW9kZWwtMDQudHh0DQo+ID4+PiDCoMKgwqDCoMKgwqAg UGFnZXPCoMKgwqDCoMKgwqDCoMKgwqDCoCA6IDY1DQo+ID4+PiDCoMKgwqDCoMKgwqAgRGF0ZcKg wqDCoMKgwqDCoMKgwqDCoMKgwqAgOiAyMDE1LTExLTIyDQo+ID4+Pg0KPiA+Pj4gQWJzdHJhY3Q6 DQo+ID4+PsKgwqDCoCBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBZQU5HIGRhdGEgbW9kZWwgZm9y IFJvdXRpbmcgSW5mb3JtYXRpb24NCj4gPj4+QmFzZQ0KPiA+Pj7CoMKgwqAgKFJJQikgdGhhdCBh bGlnbnMgd2l0aCB0aGUgSTJSUyBSSUIgaW5mb3JtYXRpb24gbW9kZWwuDQo+ID4+Pg0KPiA+Pj4N Cj4gPj4+DQo+ID4+PiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBk cmFmdCBpczoNCj4gPj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtaTJycy1yaWItZGF0YS1tb2RlbC8NCj4gPj4+DQo+ID4+PiBUaGVyZSdzIGFsc28gYSBodG1s aXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj4gPj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLWkycnMtcmliLWRhdGEtbW9kZWwtMDQNCj4gPj4+DQo+ID4+PiBBIGRp ZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+ID4+PiBodHRw czovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1pMnJzLXJpYi1kYXRhLW1v ZGVsLTA0DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2Ug YSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+ID4+PnN1Ym1pc3Npb27CoCB1 bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0DQo+ID4+ PnRvb2xzLmlldGYub3JnLg0KPiA+Pj4NCj4gPj4+IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBh dmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gPj4+IGZ0cDovL2Z0cC5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvDQo+ID4+Pg0KPiA+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gPj4+IGkycnMgbWFpbGluZyBsaXN0DQo+ID4+PiBpMnJz QGlldGYub3JnDQo+ID4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ky cnMNCj4gPj4NCj4gPj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiA+PmkycnMgbWFpbGluZyBsaXN0DQo+ID4+aTJyc0BpZXRmLm9yZw0KPiA+Pmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJycw0KPiA+DQo+ID5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+aTJycyBtYWlsaW5nIGxp c3QNCj4gPmkycnNAaWV0Zi5vcmcNCj4gPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaTJycw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiBpMnJzIG1haWxpbmcgbGlzdA0KPiBpMnJzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJycw0KDQo= From nobody Fri Nov 27 03:37:23 2015 Return-Path: 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 AA1671B32D2 for ; Fri, 27 Nov 2015 03:37:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_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 u67ymDKCuwk6 for ; Fri, 27 Nov 2015 03:37:21 -0800 (PST) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (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 59B4E1B32CA for ; Fri, 27 Nov 2015 03:37:21 -0800 (PST) Received: by vkha189 with SMTP id a189so67255513vkh.2 for ; Fri, 27 Nov 2015 03:37:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=uh4XUYkdx/1vaIVIMIFKGXEAiVvt2gd1cAM7xV6Y6EM=; b=ioUptRewA9aihdnPe5A6eio1xudN6zyEi4Llv0UcvnJglQg/Zs+MZRkxJ7+Lyba7pc D5ElG0dWJ4zp++Dy2Ddhvvc4yClYjWUMHUvlZzYTJN+ZwQUu6vyk+wypV+o284fnV/3c WnExlGL4s1rU4yzl5wZwtmrgaqaAoS/FOMR5JEFSsq2iW4281eJmK+X8mpkNageJOT99 8A78qgdQKyra3lJ5Qm32zbaLdbuSmF1J2AuIygjhHNu/YpPRWZ2U/rK2L1rJyLWAaWoh hiLU9IUvkTuLo0OfwK844fODmI8Qmd3DrRPmxUAgWwh0W8rFqQCRW9kpRjkdV8ZsbkXI fgXQ== X-Received: by 10.31.171.83 with SMTP id u80mr22582890vke.104.1448624240514; Fri, 27 Nov 2015 03:37:20 -0800 (PST) MIME-Version: 1.0 Sender: edwinsc@gmail.com Received: by 10.31.2.214 with HTTP; Fri, 27 Nov 2015 03:36:51 -0800 (PST) From: Edwin Cordeiro Date: Fri, 27 Nov 2015 12:36:51 +0100 X-Google-Sender-Auth: e4kRjwHdJBrYIkw_D2MCcYVZWrE Message-ID: To: i2rs@ietf.org Content-Type: multipart/alternative; boundary=001a114391e444dc020525841d02 Archived-At: Subject: [i2rs] I2RS in IETF 94 Hackaton X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2015 11:37:22 -0000 --001a114391e444dc020525841d02 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello all, On my PhD research I plan to use I2RS to make some "real-time" changes to the network and I was looking for I2RS prototypes or implementations to use and to help with the development. I was unable to find any implementation, but saw that the I2RS won =E2=80= =9CMost Helpful Failure=E2=80=9D in IETF 94 Hackaton. Can anyone help me to understand what =E2=80=9CMost Helpful Failure=E2=80= =9D means and why it failed? Are you aware of any other I2RS implementation effort? Thank you for any assistance you may provide. Best Regards, -- Edwin Cordeiro, M.Eng. Network Architectures and Services T: +49 89 289 18550 Department of Computer Science M: +49 175 215 6481 Technische Universit=C3=A4t M=C3=BCnchen --001a114391e444dc020525841d02 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello all,

On my PhD= research I plan to use I2RS to make some "real-time" changes to = the network and I was looking for I2RS prototypes or implementations to use= and to help with the development.

I was unable to find any i= mplementation, but saw that the=C2=A0I2RS won =E2=80=9CMost Helpful Failure=E2= =80=9D=C2=A0in IETF 94 Hackaton.

Can anyone help me to understand what=C2=A0=E2=80=9CMost Helpful Fai= lure=E2=80=9D=C2=A0means and why it failed?
=
Are you aware of any other I2RS implementation effort= ?

Thank you for any assist= ance you may provide.

Best= Regards,

--
Edwin Cordeiro, M.Eng. =C2=A0 =C2=A0Network Architectures and= Services
T:=C2=A0+49 89 289 18550=C2=A0=C2=A0 =C2=A0 =C2=A0= Department of Computer Science
M:=C2=A0+49 175 215 6481=C2= =A0=C2=A0 =C2=A0 =C2=A0Technische Universit=C3=A4t M=C3=BCnchen
--001a114391e444dc020525841d02-- From nobody Mon Nov 30 05:31:59 2015 Return-Path: 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 D391B1ACD02; Mon, 30 Nov 2015 05:31:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 reNf5g5Utuxf; Mon, 30 Nov 2015 05:31:53 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9267E1ACCF9; Mon, 30 Nov 2015 05:31:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17041; q=dns/txt; s=iport; t=1448890312; x=1450099912; h=to:cc:from:subject:message-id:date:mime-version; bh=vFcJhXo8/pb/tTIFwI72hH9mpHayvf36OIpXUqEvMq8=; b=QgBjbkattW1qi+PvJ9WGsBF12JeRxXl/svFf2n5MEoLwyKwzDW0Zqu0G 5u1TMgw6ett60QwCidGnc9K8BWCJD93HdLHbwtmhWmLyGemrlwXr1PGA2 b5GB0G3RUXi56ywgFAmEyD2yb6sHbyThFq32JwzwPr92/9YJNSA9wo8p7 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CqBABBTlxW/xbLJq1ehA5vvBSEDiOFb?= =?us-ascii?q?IF8AQEBAQEBgQALhDcnVQE8FgsCCwMCAQIBSw0GAgEBFogUDak5kCwBAQEBAQU?= =?us-ascii?q?BAQEBAQEBARuGVIoGgm2BRAWNIoVNg2iFKogOgVtJhnyPT4NyY4IRHYFXPTQBh?= =?us-ascii?q?XABAQE?= X-IronPort-AV: E=Sophos;i="5.20,364,1444694400"; d="scan'208,217";a="608621987" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Nov 2015 13:31:49 +0000 Received: from [10.60.67.93] (ams-bclaise-89112.cisco.com [10.60.67.93]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id tAUDVnGI020691; Mon, 30 Nov 2015 13:31:49 GMT To: "i2rs@ietf.org" From: Benoit Claise Message-ID: <565C4FC4.6050607@cisco.com> Date: Mon, 30 Nov 2015 14:31:48 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------020706050602060508080606" Archived-At: Cc: "yang-coord@ietf.org" , Martin Bjorklund Subject: [i2rs] YANG data models in I2RS: extraction and compilation feedback X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 13:31:59 -0000 This is a multi-part message in MIME format. --------------020706050602060508080606 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, I looked at the YANG models in the I2RS WG documents, from a compilation point of view (NOT a YANG design point of view): http://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/ http://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l2-network-topology/ http://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ http://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/ See the compilation results, updated daily, at http://www.claise.be/IETFYANGPageCompilation.html _draft-ietf-i2rs-yang-network-topo-01_ As mentioned in https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-05, the correct way to use is The "" tag SHOULD be followed by a string identifying the file name specified in Section 5.2 of [I-D.ietf-netmod-rfc6020bis ]. The following example is for the '2010-01-18' revision of the 'ietf-foo' module: file "ietf-foo@2010-01-18.yang" module ietf-foo { // ... revision 2010-01-18 { description "Latest revision"; reference "RFC XXXX"; } // ... } In your draft, here is what you should change: OLD: file "ietf-network@2015-06-08.yang" module ietf-network { yang-version 1; namespace "urn:ietf:params:xml:ns:yang:ietf-network"; prefix nd; NEW: file "ietf-network@2015-06-08.yang" module ietf-network { yang-version 1; namespace "urn:ietf:params:xml:ns:yang:ietf-network"; prefix nd; OLD: file "ietf-network-topology@2015-06-08.yang" module ietf-network-topology { NEW: file "ietf-network-topology@2015-06-08.yang" module ietf-network-topology { However, we were able to extract those two models, and they compile correctly . _draft-ietf-i2rs-yang-l2-network-topology-01.txt_ Same remark: OLD: file "ietf-l2-topology@2015-06-23.yang" module ietf-l2-topology { NEW: file "ietf-l2-topology@2015-06-23.yang" module ietf-l2-topology { However, we were able to extract this model, and as of this morning, it compiled with some warnings : ietf-l2-topology.yang:490 (at ietf-l2-topology.yang:349): warning: explicit config statement is ignored Good news. Martin Bjorklund troubleshooted this one, and found a bug in pyang, which is already fixed! Thanks Martin So get the latest pyang version at https://github.com/mbj4668/pyang _draft-ietf-i2rs-yang-l3-topology-00_ Same remark. OLD: file "l3-unicast-igp-topology@2015-06-08.yang" module l3-unicast-igp-topology { NEW: file "l3-unicast-igp-topology@2015-06-08.yang" module l3-unicast-igp-topology { OLD: file "ospf-topology@2015-06-08.yang" module ospf-topology { NEW: file "ospf-topology@2015-06-08.yang" module ospf-topology { OLD: file "isis-topology@2015-06-08.yang" module isis-topology { NEW: file "isis-topology@2015-06-08.yang" module isis-topology { However, we were able to extract these models, and, as of this morning, they compiled with the following warnings : l3-unicast-igp-topology.yang:1: warning: RFC 6087: 4.1: no module name prefix used, suggest ietf-l3-unicast-igp-topology isis-topology.yang:1: warning: RFC 6087: 4.1: no module name prefix used, suggest ietf-isis-topology ospf-topology.yang:1: warning: RFC 6087: 4.1: no module name prefix used, suggest ietf-ospf-topology The error messages were not optimal: indeed, they complain about the module name, and not the prefix YANG keyword. Martin improved this error message already: isis-topology.yang:1: warning: RFC 6087: 4.1: the module name should start with one of the strings "ietf-" or "iana-" This relates to https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-05 It is suggested that a stable prefix be selected representing the entire organization. All normative YANG modules published by the IETF MUST begin with the prefix "ietf-". Another standards organization, such as the IEEE, might use the prefix "ieee-" for all YANG modules. However, this was not a MUST in RFC6087 (as opposed to RFC6087bis). When RFC6087bis will be published, pyang will be adapted accordingly (error as opposed to warning). In the mean time, you can already fix the YANG modules like this: it will get rid of the warnings and future errors. OLD: file "l3-unicast-igp-topology@2015-06-08.yang" module l3-unicast-igp-topology { yang-version 1; namespace "urn:ietf:params:xml:ns:yang:l3-unicast-igp-topology"; prefix "l3t"; NEW: file "ietf-l3-unicast-igp-topology@2015-06-08.yang" module l3-unicast-igp-topology { yang-version 1; namespace "urn:ietf:params:xml:ns:yang:ietf-l3-unicast-igp-topology"; prefix "l3t"; OLD: file "isis-topology@2015-06-08.yang" module isis-topology { yang-version 1; namespace "urn:ietf:params:xml:ns:yang:isis-topology"; prefix "isis"; NEW: file "ietf-isis-topology@2015-06-08.yang" module isis-topology { yang-version 1; namespace "urn:ietf:params:xml:ns:yang:ietf-isis-topology"; prefix "isis"; OLD: file "ospf-topology@2015-06-08.yang" module ospf-topology { yang-version 1; namespace "urn:ietf:params:xml:ns:yang:ospf-topology"; prefix "ospf"; NEW: file "ietf-ospf-topology@2015-06-08.yang" module ospf-topology { yang-version 1; namespace "urn:ietf:params:xml:ns:yang:ietf-ospf-topology"; prefix "ospf"; _draft-ietf-i2rs-rib-data-model-04.txt_ This one extracts and compiles without any issues. Thanks. Regards, Benoit --------------020706050602060508080606 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Dear all,

I looked at the YANG models in the I2RS WG documents, from a compilation point of view (NOT a YANG design point of view):
http://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/
http://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l2-network-topology/
http://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/
http://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/

See the compilation results, updated daily, at http://www.claise.be/IETFYANGPageCompilation.html

draft-ietf-i2rs-yang-network-topo-01
As mentioned in https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-05, the correct way to use <CODE BEGINS> <CODE ENDS> is 

   The "<CODE BEGINS>" tag SHOULD be followed by a string identifying
   the file name specified in Section 5.2 of
   [I-D.ietf-netmod-rfc6020bis].  The following example is for the
   '2010-01-18' revision of the 'ietf-foo' module:

     <CODE BEGINS> file "ietf-foo@2010-01-18.yang"
       module ietf-foo {
         // ...
         revision 2010-01-18 {
           description "Latest revision";
           reference "RFC XXXX";
         }
         // ...
       }
     <CODE ENDS>
In your draft, here is what you should change:
OLD:
   <CODE BEGINS>
   file "ietf-network@2015-06-08.yang"
   module ietf-network {
     yang-version 1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-network";
     prefix nd;
NEW:
   <CODE BEGINS> file "ietf-network@2015-06-08.yang"
   module ietf-network {
     yang-version 1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-network";
     prefix nd;

OLD:
 <CODE BEGINS>
 file "ietf-network-topology@2015-06-08.yang"
 module ietf-network-topology {

NEW:
 <CODE BEGINS> file "ietf-network-topology@2015-06-08.yang"
 module ietf-network-topology {


However, we were able to extract those two models, and they compile correctly.


draft-ietf-i2rs-yang-l2-network-topology-01.txt

Same remark:
OLD:
   <CODE BEGINS>
   file "ietf-l2-topology@2015-06-23.yang"
   module ietf-l2-topology {
NEW:
   <CODE BEGINS> file "ietf-l2-topology@2015-06-23.yang"
   module ietf-l2-topology {

However, we were able to extract this model, and as of this morning, it compiled with some warnings:
    ietf-l2-topology.yang:490 (at ietf-l2-topology.yang:349): warning: explicit config statement is ignored

Good news.
Martin Bjorklund troubleshooted this one, and found a bug in pyang, which is already fixed! Thanks Martin
So get the latest pyang version at https://github.com/mbj4668/pyang


draft-ietf-i2rs-yang-l3-topology-00

Same remark.

OLD:
   <CODE BEGINS>
   file "l3-unicast-igp-topology@2015-06-08.yang"
   module l3-unicast-igp-topology {

NEW:
   <CODE BEGINS> file "l3-unicast-igp-topology@2015-06-08.yang"
   module l3-unicast-igp-topology {

OLD:
   <CODE BEGINS>
   file "ospf-topology@2015-06-08.yang"
   module ospf-topology {

NEW:
   <CODE BEGINS> file "ospf-topology@2015-06-08.yang"
   module ospf-topology {


OLD:
   <CODE BEGINS>
   file "isis-topology@2015-06-08.yang"
   module isis-topology {

NEW:
   <CODE BEGINS> file "isis-topology@2015-06-08.yang"
   module isis-topology {

However, we were able to extract these models, and, as of this morning, they compiled with the following warnings:
l3-unicast-igp-topology.yang:1: warning: RFC 6087: 4.1: no module name prefix used, suggest ietf-l3-unicast-igp-topology
isis-topology.yang:1: warning: RFC 6087: 4.1: no module name prefix used, suggest ietf-isis-topology
ospf-topology.yang:1: warning: RFC 6087: 4.1: no module name prefix used, suggest ietf-ospf-topology
The error messages were not optimal: indeed, they complain about the module name, and not the prefix YANG keyword.
Martin improved this error message already:
isis-topology.yang:1: warning: RFC 6087: 4.1: the module name should start with one of the strings "ietf-" or "iana-"

This relates to https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-05
   It is suggested that a stable prefix be selected representing the
   entire organization.  All normative YANG modules published by the
   IETF MUST begin with the prefix "ietf-".  Another standards
   organization, such as the IEEE, might use the prefix "ieee-" for all
   YANG modules.
However, this was not a MUST in RFC6087 (as opposed to RFC6087bis). When RFC6087bis will be published, pyang will be adapted accordingly (error as opposed to warning). In the mean time, you can already fix the YANG modules like this: it will get rid of the warnings and future errors.

OLD:
   <CODE BEGINS>
   file "l3-unicast-igp-topology@2015-06-08.yang"
   module l3-unicast-igp-topology {
     yang-version 1;
     namespace "urn:ietf:params:xml:ns:yang:l3-unicast-igp-topology";
     prefix "l3t";
NEW:
   <CODE BEGINS> file "ietf-l3-unicast-igp-topology@2015-06-08.yang"
   module l3-unicast-igp-topology {
     yang-version 1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-l3-unicast-igp-topology";
     prefix "l3t";


OLD:
   <CODE BEGINS>
   file "isis-topology@2015-06-08.yang"
   module isis-topology {
     yang-version 1;
     namespace "urn:ietf:params:xml:ns:yang:isis-topology";
     prefix "isis";

NEW:
   <CODE BEGINS> file "ietf-isis-topology@2015-06-08.yang"
   module isis-topology {
     yang-version 1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-isis-topology";
     prefix "isis";

OLD:
   <CODE BEGINS>
   file "ospf-topology@2015-06-08.yang"
   module ospf-topology {
     yang-version 1;
     namespace "urn:ietf:params:xml:ns:yang:ospf-topology";
     prefix "ospf";

NEW:
   <CODE BEGINS> file "ietf-ospf-topology@2015-06-08.yang"
   module ospf-topology {
     yang-version 1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-ospf-topology";
     prefix "ospf";

draft-ietf-i2rs-rib-data-model-04.txt
This one extracts and compiles without any issues. Thanks.

Regards, Benoit
--------------020706050602060508080606-- From nobody Mon Nov 30 07:11:57 2015 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 330371B2E16; Mon, 30 Nov 2015 07:11:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151130151155.6768.83284.idtracker@ietfa.amsl.com> Date: Mon, 30 Nov 2015 07:11:55 -0800 Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-architecture-10.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 15:11:55 -0000 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 : An Architecture for the Interface to the Routing System Authors : Alia Atlas Joel Halpern Susan Hares Dave Ward Thomas D. Nadeau Filename : draft-ietf-i2rs-architecture-10.txt Pages : 32 Date : 2015-11-30 Abstract: This document describes an architecture for a standard, programmatic interface for state transfer in and out of the Internet routing system. It describes the basic architecture, the components, and their interfaces with particular focus on those to be standardized as part of the Interface to Routing System (I2RS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-i2rs-architecture-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-architecture-10 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 nobody Mon Nov 30 07:14:30 2015 Return-Path: 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 EB06D1B2E3F for ; Mon, 30 Nov 2015 07:14:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.055 X-Spam-Level: X-Spam-Status: No, score=-99.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] 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 LPQM_r8WnvB4 for ; Mon, 30 Nov 2015 07:14:27 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9679B1B2E0C for ; Mon, 30 Nov 2015 07:14:27 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.177; From: "Susan Hares" To: References: <20151130151155.6768.82397.idtracker@ietfa.amsl.com> In-Reply-To: <20151130151155.6768.82397.idtracker@ietfa.amsl.com> Date: Mon, 30 Nov 2015 10:14:27 -0500 Message-ID: <01ac01d12b81$ce2df930$6a89eb90$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJYwBD9rp3LaR7zqLETxeLzjmGODZ2lgtCA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' , 'Alia Atlas' Subject: [i2rs] FW: New Version Notification for draft-ietf-i2rs-architecture-10.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 15:14:29 -0000 I2RS WG:=20 This draft simple changes the revision number. Another revision will = appear this week with changes to address the ADs comments.=20 Sue=20 -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Monday, November 30, 2015 10:12 AM To: David Ward; Thomas D. Nadeau; Susan Hares; Alia Atlas; Joel M. = Halpern; Thomas Nadeau; Dave Ward; Joel Halpern Subject: New Version Notification for = draft-ietf-i2rs-architecture-10.txt A new version of I-D, draft-ietf-i2rs-architecture-10.txt has been successfully submitted by Susan Hares and posted to the IETF = repository. Name: draft-ietf-i2rs-architecture Revision: 10 Title: An Architecture for the Interface to the Routing System Document date: 2015-11-30 Group: i2rs Pages: 32 URL: = https://www.ietf.org/internet-drafts/draft-ietf-i2rs-architecture-10.txt Status: = https://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/ Htmlized: = https://tools.ietf.org/html/draft-ietf-i2rs-architecture-10 Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2rs-architecture-10 Abstract: This document describes an architecture for a standard, programmatic interface for state transfer in and out of the Internet routing system. It describes the basic architecture, the components, and their interfaces with particular focus on those to be standardized as part of the Interface to Routing System (I2RS). = =20 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. The IETF Secretariat From nobody Mon Nov 30 07:17:04 2015 Return-Path: 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 6B1C81B2E28; Mon, 30 Nov 2015 07:17:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 p8bDyqqS-LBY; Mon, 30 Nov 2015 07:16:59 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 666DB1B2E3A; Mon, 30 Nov 2015 07:16:59 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.177; From: "Susan Hares" To: "'Benoit Claise'" , References: <565C4FC4.6050607@cisco.com> In-Reply-To: <565C4FC4.6050607@cisco.com> Date: Mon, 30 Nov 2015 10:16:59 -0500 Message-ID: <01c401d12b82$28f25cd0$7ad71670$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01C5_01D12B58.401F6210" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGsCMR5Npf77+Ui+YyxLAAAt7bje57+8mrg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: yang-coord@ietf.org, 'Martin Bjorklund' Subject: Re: [i2rs] YANG data models in I2RS: extraction and compilation feedback X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 15:17:02 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01C5_01D12B58.401F6210 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Benoit:=20 =20 Thanks for sending these compilation errors. We will address these = errors this week.=20 =20 Cheers, Sue=20 =20 From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Benoit Claise Sent: Monday, November 30, 2015 8:32 AM To: i2rs@ietf.org Cc: yang-coord@ietf.org; Martin Bjorklund Subject: [i2rs] YANG data models in I2RS: extraction and compilation = feedback =20 Dear all, I looked at the YANG models in the I2RS WG documents, from a compilation = point of view (NOT a YANG design point of view): http://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/ http://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l2-network-topology/= http://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ http://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/ See the compilation results, updated daily, at = http://www.claise.be/IETFYANGPageCompilation.html draft-ietf-i2rs-yang-network-topo-01 As mentioned in = https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-05, the correct = way to use is=20 The "" tag SHOULD be followed by a string identifying the file name specified in Section 5.2 of [I-D.ietf-netmod-rfc6020bis = ]. The following example is for the '2010-01-18' revision of the 'ietf-foo' module: =20 file = "ietf-foo@2010-01-18.yang" module ietf-foo { // ... revision 2010-01-18 { description "Latest revision"; reference "RFC XXXX"; } // ... } In your draft, here is what you should change: OLD: file = "ietf-network@2015-06-08.yang" module ietf-network { yang-version 1; namespace "urn:ietf:params:xml:ns:yang:ietf-network"; prefix nd; NEW: file = "ietf-network@2015-06-08.yang" module ietf-network { yang-version 1; namespace "urn:ietf:params:xml:ns:yang:ietf-network"; prefix nd; OLD: file = "ietf-network-topology@2015-06-08.yang" module ietf-network-topology { NEW: file = "ietf-network-topology@2015-06-08.yang" module ietf-network-topology { However, we were able to extract those two models, and they compile = correctly . draft-ietf-i2rs-yang-l2-network-topology-01.txt Same remark: OLD: file = "ietf-l2-topology@2015-06-23.yang" module ietf-l2-topology { NEW: file = "ietf-l2-topology@2015-06-23.yang" module ietf-l2-topology { However, we were able to extract this model, and as of this morning, it = compiled with some warnings = : ietf-l2-topology.yang:490 (at ietf-l2-topology.yang:349): warning: = explicit config statement is ignored Good news. Martin Bjorklund troubleshooted this one, and found a bug in pyang, = which is already fixed! Thanks Martin So get the latest pyang version at https://github.com/mbj4668/pyang draft-ietf-i2rs-yang-l3-topology-00 Same remark. OLD: file = "l3-unicast-igp-topology@2015-06-08.yang" module l3-unicast-igp-topology { NEW: file = "l3-unicast-igp-topology@2015-06-08.yang" module l3-unicast-igp-topology { OLD: file = "ospf-topology@2015-06-08.yang" module ospf-topology { NEW: file = "ospf-topology@2015-06-08.yang" module ospf-topology { OLD: file = "isis-topology@2015-06-08.yang" module isis-topology { NEW: file = "isis-topology@2015-06-08.yang" module isis-topology { However, we were able to extract these models, and, as of this morning, = they compiled with the following warnings = : l3-unicast-igp-topology.yang:1: warning: RFC 6087: 4.1: no module name = prefix used, suggest ietf-l3-unicast-igp-topology isis-topology.yang:1: warning: RFC 6087: 4.1: no module name prefix = used, suggest ietf-isis-topology ospf-topology.yang:1: warning: RFC 6087: 4.1: no module name prefix = used, suggest ietf-ospf-topology The error messages were not optimal: indeed, they complain about the = module name, and not the prefix YANG keyword. Martin improved this error message already:=20 isis-topology.yang:1: warning: RFC 6087: 4.1: the module name should = start with one of the strings "ietf-" or "iana-" This relates to = https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-05 It is suggested that a stable prefix be selected representing the entire organization. All normative YANG modules published by the IETF MUST begin with the prefix "ietf-". Another standards organization, such as the IEEE, might use the prefix "ieee-" for all YANG modules. =20 However, this was not a MUST in RFC6087 (as opposed to RFC6087bis). When = RFC6087bis will be published, pyang will be adapted accordingly (error = as opposed to warning). In the mean time, you can already fix the YANG = modules like this: it will get rid of the warnings and future errors. OLD: file = "l3-unicast-igp-topology@2015-06-08.yang" module l3-unicast-igp-topology { yang-version 1; namespace "urn:ietf:params:xml:ns:yang:l3-unicast-igp-topology"; prefix "l3t"; NEW: file = = "ietf-l3-unicast-igp-topology@2015-06-08.yang" module l3-unicast-igp-topology { yang-version 1; namespace = "urn:ietf:params:xml:ns:yang:ietf-l3-unicast-igp-topology"; prefix "l3t"; OLD: file = "isis-topology@2015-06-08.yang" module isis-topology { yang-version 1; namespace "urn:ietf:params:xml:ns:yang:isis-topology"; prefix "isis"; NEW: file = "ietf-isis-topology@2015-06-08.yang" module isis-topology { yang-version 1; namespace "urn:ietf:params:xml:ns:yang:ietf-isis-topology"; prefix "isis"; OLD: file = "ospf-topology@2015-06-08.yang" module ospf-topology { yang-version 1; namespace "urn:ietf:params:xml:ns:yang:ospf-topology"; prefix "ospf"; NEW: file = "ietf-ospf-topology@2015-06-08.yang" module ospf-topology { yang-version 1; namespace "urn:ietf:params:xml:ns:yang:ietf-ospf-topology"; prefix "ospf"; draft-ietf-i2rs-rib-data-model-04.txt This one extracts and compiles without any issues. Thanks. Regards, Benoit ------=_NextPart_000_01C5_01D12B58.401F6210 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Benoit:

 

Thanks for sending these compilation errors.=C2=A0 =C2=A0We will = address these errors this week.

 

Cheers,

Sue

 

From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Benoit = Claise
Sent: Monday, November 30, 2015 8:32 AM
To: = i2rs@ietf.org
Cc: yang-coord@ietf.org; Martin = Bjorklund
Subject: [i2rs] YANG data models in I2RS: extraction = and compilation feedback

 

Dear all,

I looked at the YANG = models in the I2RS WG documents, from a compilation point of view (NOT a = YANG design point of view):
http://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/=
http://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l2-network= -topology/
http://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/= http://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/
See the compilation results, updated daily, at http://www.cla= ise.be/IETFYANGPageCompilation.html

draft-ietf-i2rs-yang-ne= twork-topo-01
As mentioned in http= s://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-05, the correct = way to use <CODE BEGINS> <CODE ENDS> is = 

=C2=A0=C2=A0=C2=A0The "<CODE =
BEGINS>" tag SHOULD be followed by a string =
identifying
=C2=A0=C2=A0 the file name specified in =
Section 5.2 of
=C2=A0=C2=A0 [I-D.ietf-netmod-rfc6020bis].=C2=A0 The =
following example is for the
=C2=A0=C2=A0 =
'2010-01-18' revision of the 'ietf-foo' =
module:
 
=C2=A0=C2=A0=C2=A0=
=C2=A0 <CODE BEGINS> file "ietf-foo@2010-01-18.yang&q=
uot;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
module ietf-foo =
{
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
// =
...
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 revision 2010-01-18 =
{
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 description "Latest =
revision";
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 reference "RFC =
XXXX";
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 =
}
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
// ...
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
}
=C2=A0=C2=A0=C2=A0=C2=A0 <CODE =
ENDS>

In your draft, here is = what you should change:
OLD:

=C2=A0=C2=A0 <CODE =
BEGINS>
=C2=A0=C2=A0 file "ietf-network@2015-06-0=
8.yang"
=C2=A0=C2=A0 module ietf-network =
{
=C2=A0=C2=A0=C2=A0=C2=A0 yang-version =
1;
=C2=A0=C2=A0=C2=A0=C2=A0 namespace =
"urn:ietf:params:xml:ns:yang:ietf-network";
=C2=A0=C2=A0=C2=A0=C2=A0 prefix nd;

NEW:

=C2=A0=C2=A0 <CODE =
BEGINS> file "ietf-network@2015-06-0=
8.yang"
=C2=A0=C2=A0 module ietf-network =
{
=C2=A0=C2=A0=C2=A0=C2=A0 yang-version =
1;
=C2=A0=C2=A0=C2=A0=C2=A0 namespace =
"urn:ietf:params:xml:ns:yang:ietf-network";
=C2=A0=C2=A0=C2=A0=C2=A0 prefix nd;


OLD:

 <CODE =
BEGINS>
 file "ietf-network-=
topology@2015-06-08.yang"
 module =
ietf-network-topology {


NEW:

 <CODE BEGINS> file =
"ietf-network-=
topology@2015-06-08.yang"
 module =
ietf-network-topology {



However, we were able to extract those two = models, and they compile correctly.=


draft-ietf-i2rs-yang-l2-network-topology-01.txt
Same remark:
OLD:

=C2=A0=C2=A0 <CODE =
BEGINS>
=C2=A0=C2=A0 file "ietf-l2-topology@2=
015-06-23.yang"
=C2=A0=C2=A0 module =
ietf-l2-topology {

NEW:

=C2=A0=C2=A0 <CODE =
BEGINS> file "ietf-l2-topology@2=
015-06-23.yang"
=C2=A0=C2=A0 module =
ietf-l2-topology {


However, we = were able to extract this model, and as of this morning, it compiled = with some warnings:<= br>    ietf-l2-topology.yang:490 (at = ietf-l2-topology.yang:349): warning: explicit config statement is = ignored

Good news.
Martin Bjorklund troubleshooted this one, = and found a bug in pyang, which is already fixed! Thanks Martin
So = get the latest pyang version at https://github.com/mbj4668/pyan= g


draft-ietf-i2rs-yang-l3-topology-00

Same = remark.

OLD:

=C2=A0=C2=A0 <CODE =
BEGINS>
=C2=A0=C2=A0 file "l3-unicast-=
igp-topology@2015-06-08.yang"
=C2=A0=C2=A0 =
module l3-unicast-igp-topology {


NEW:

=C2=A0=C2=A0 <CODE =
BEGINS> file "l3-unicast-=
igp-topology@2015-06-08.yang"
=C2=A0=C2=A0 =
module l3-unicast-igp-topology {


OLD:

=C2=A0=C2=A0 <CODE =
BEGINS>
=C2=A0=C2=A0 file "ospf-topology@2015-06=
-08.yang"
=C2=A0=C2=A0 module =
ospf-topology {


NEW:

=C2=A0=C2=A0 <CODE =
BEGINS> file "ospf-topology@2015-06=
-08.yang"
=C2=A0=C2=A0 module =
ospf-topology {



OLD:

=C2=A0=C2=A0 <CODE =
BEGINS>
=C2=A0=C2=A0 file "isis-topology@2015-06=
-08.yang"
=C2=A0=C2=A0 module =
isis-topology {


NEW:

=C2=A0=C2=A0 <CODE =
BEGINS> file "isis-topology@2015-06=
-08.yang"
=C2=A0=C2=A0 module =
isis-topology {


However, we = were able to extract these models, and, as of this morning, they = compiled with the following warnings:<= o:p>

l3-unicast-igp-topology.yang:1: = warning: RFC 6087: 4.1: no module name prefix used, suggest = ietf-l3-unicast-igp-topology
isis-topology.yang:1: warning: RFC 6087: = 4.1: no module name prefix used, suggest = ietf-isis-topology
ospf-topology.yang:1: warning: RFC 6087: 4.1: no = module name prefix used, suggest ietf-ospf-topology

The error messages were not optimal: indeed, they = complain about the module name, and not the prefix YANG = keyword.
Martin improved this error message already: =
isis-topology.yang:1: warning: RFC 6087: 4.1: the module name should = start with one of the strings "ietf-" or = "iana-"

This relates to http= s://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-05

=C2=A0=C2=A0 It is suggested that a stable prefix be selected =
representing the
=C2=A0=C2=A0 entire =
organization.=C2=A0 All normative YANG modules published by =
the
=C2=A0=C2=A0 IETF MUST begin with the prefix =
"ietf-".=C2=A0 Another =
standards
=C2=A0=C2=A0 organization, such as the =
IEEE, might use the prefix "ieee-" for =
all
=C2=A0=C2=A0 YANG =
modules.
 

However, this was not a MUST in RFC6087 (as opposed to = RFC6087bis). When RFC6087bis will be published, pyang will be adapted = accordingly (error as opposed to warning). In the mean time, you can = already fix the YANG modules like this: it will get rid of the warnings = and future errors.

OLD:

=C2=A0=C2=A0 <CODE =
BEGINS>
=C2=A0=C2=A0 file "l3-unicast-=
igp-topology@2015-06-08.yang"
=C2=A0=C2=A0 =
module l3-unicast-igp-topology =
{
=C2=A0=C2=A0=C2=A0=C2=A0 yang-version =
1;
=C2=A0=C2=A0=C2=A0=C2=A0 namespace =
"urn:ietf:params:xml:ns:yang:l3-unicast-igp-topology";
=C2=A0=C2=A0=C2=A0=C2=A0 prefix =
"l3t";

NEW:

=C2=A0=C2=A0 <CODE =
BEGINS> file "ietf-l=
3-unicast-igp-topology@2015-06-08.yang"
=C2=
=A0=C2=A0 module l3-unicast-igp-topology =
{
=C2=A0=C2=A0=C2=A0=C2=A0 yang-version =
1;
=C2=A0=C2=A0=C2=A0=C2=A0 namespace =
"urn:ietf:params:xml:ns:yang:ietf-l3-unicast-igp-topology";
=C2=A0=C2=A0=C2=A0=C2=A0 prefix =
"l3t";



OLD:

=C2=A0=C2=A0 <CODE =
BEGINS>
=C2=A0=C2=A0 file "isis-topology@2015-06=
-08.yang"
=C2=A0=C2=A0 module =
isis-topology {
=C2=A0=C2=A0=C2=A0=C2=A0 =
yang-version 1;
=C2=A0=C2=A0=C2=A0=C2=A0 namespace =
"urn:ietf:params:xml:ns:yang:isis-topology";
=C2=A0=C2=A0=C2=A0=C2=A0 prefix "isis";


NEW:

=C2=A0=C2=A0 <CODE =
BEGINS> file "ietf-isis-topolo=
gy@2015-06-08.yang"
=C2=A0=C2=A0 module =
isis-topology {
=C2=A0=C2=A0=C2=A0=C2=A0 =
yang-version 1;
=C2=A0=C2=A0=C2=A0=C2=A0 namespace =
"urn:ietf:params:xml:ns:yang:ietf-isis-topology";
=C2=A0=C2=A0=C2=A0=C2=A0 prefix =
"isis";

OLD:
=C2=A0=C2=A0 <CODE =
BEGINS>
=C2=A0=C2=A0 file "ospf-topology@2015-06=
-08.yang"
=C2=A0=C2=A0 module =
ospf-topology {
=C2=A0=C2=A0=C2=A0=C2=A0 =
yang-version 1;
=C2=A0=C2=A0=C2=A0=C2=A0 namespace =
"urn:ietf:params:xml:ns:yang:ospf-topology";
=C2=A0=C2=A0=C2=A0=C2=A0 prefix "ospf";


NEW:

=C2=A0=C2=A0 <CODE =
BEGINS> file "ietf-ospf-topolo=
gy@2015-06-08.yang"
=C2=A0=C2=A0 module =
ospf-topology {
=C2=A0=C2=A0=C2=A0=C2=A0 =
yang-version 1;
=C2=A0=C2=A0=C2=A0=C2=A0 namespace =
"urn:ietf:params:xml:ns:yang:ietf-ospf-topology";
=C2=A0=C2=A0=C2=A0=C2=A0 prefix =
"ospf";

draft-ietf-i2rs-rib-data-model-04.txt
Thi=
s one extracts and compiles without any issues. Thanks.

Regards, =
Benoit
------=_NextPart_000_01C5_01D12B58.401F6210-- From nobody Mon Nov 30 09:49:28 2015 Return-Path: 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 8C75E1B2A69 for ; Mon, 30 Nov 2015 09:49:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.155 X-Spam-Level: X-Spam-Status: No, score=-95.155 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, USER_IN_WHITELIST=-100] 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 onxhOCOooupU for ; Mon, 30 Nov 2015 09:49:25 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FD041B2A5E for ; Mon, 30 Nov 2015 09:49:25 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.177; From: "Susan Hares" To: "'PEDRO ANDRES ARANDA GUTIERREZ'" , "'Jeffrey Haas'" , "'Russ White'" <7riw77@gmail.com> References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> <563A97AA.5020308@joelhalpern.com> <00f301d11761$61699130$243cb390$@gmail.com> <563AA59C.4060809@joelhalpern.com> <018101d11764$66b82e50$34288af0$@gmail.com> <20151119203509.GA22415@pfrc.org> <5B54713B-CDE6-4F65-BE79-91F5B9FF3850@telefonica.com> In-Reply-To: <5B54713B-CDE6-4F65-BE79-91F5B9FF3850@telefonica.com> Date: Mon, 30 Nov 2015 12:49:18 -0500 Message-ID: <028701d12b97$6ff6b3f0$4fe41bd0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLwMtmz+XLO8+uQ7j5WaenA2rWXRwHVfCJTAW3ySwACzWyr4AJQYvqoAmia70sCRUpXGQJL52qvAewKHZECaD7TrgHLBOvzm8r2S6A= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, "'Joel M. Halpern'" , 'Andy Bierman' Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 17:49:27 -0000 Pedro:=20 I welcome your insights on this problem space.=20 Sue=20 -----Original Message----- From: PEDRO ANDRES ARANDA GUTIERREZ = [mailto:pedroa.aranda@telefonica.com]=20 Sent: Friday, November 20, 2015 2:13 AM To: Jeffrey Haas; Russ White Cc: i2rs@ietf.org; 'Joel M. Halpern'; 'Andy Bierman'; 'Susan Hares' Subject: Re: [i2rs] Conversation on Priority and Panes HI list, I=E2=80=99m working on a project were we are also taking on this problem = space. Although we are currently OpenFlow based, we are trying to = generalise our mechanisms. We hope we may be able to contribute in this = discussion. Best, /PA PS: answers inline --- Dr. Pedro A. Aranda Guti=C3=A9rrez Technology Exploration - Network Innovation & Virtualisation email: pedroa d0t aranda At telefonica d0t com Telef=C3=B3nica, = Investigaci=C3=B3n y Desarrollo C/ Zurbar=C3=A1n,12 28010 Madrid, Spain Fragen sind nicht da, um beantwortet zu werden. Fragen sind da, um gestellt zu werden. Georg Kreisler >An API based mechanism addresses the issue, but the question basically=20 >comes down to how to expose the remainder of the associated state for=20 >the RIB in such an implementation. Do we expose operational state? If = >so, we can have a config=3Dfalse representation of that state. You either expose the state or you require the different apps to = maintain a copy of the state, which is sort of A) dangerous, because an app could be building a corrupted/biased view = of the state if they cannot =E2=80=9Cspoof" the configuration traffic = from other apps and then start creating havoc B) tedious, because we need all apps to replicate the state >How do we expose the provisioned state? Do we require the user to=20 >issue a series of RPCs to get the state? It would be very convenient=20 >if it were present as a config=3Dtrue set of nodes, but this is the=20 >problem we're avoiding. What we'd end up with is potentially something = >similar to what the OpenConfig group wants: state that is provisioned,=20 >but distinct from the operational state of the system. In this=20 >example, it'd be effectively a second piece of operational state. I see the benefits of that approach. However there is a drawback there = and that is the responsiveness and how to control race conditions there: APP1: gets (and locks) the state, calculates the new state and then = writes (and unlocks) the state APP2: sees the state is locked and waits until it is unlocked to get and = lock it to do its operations That A) may slow down apps a lot. (Dunno if that can be even desirable to = avoid oscillation) B) rings some bells in the back of my mind regarding deadlocks I studied = (long ago) at the university :-) like what happens if APP1 and APP2 = access the state at the same time, etc. > >I'm thinking more and more that a significant portion of our problem=20 >spaces come down to some form of the above discussion. I2RS priority=20 >is rather painful to create and enforce when your interface to=20 >provision it is config=3Dtrue nodes in an ephemeral datastore. It's a=20 >bit clearer when it is provisioned via RPC instead. > >-- Jeff > >_______________________________________________ >i2rs mailing list >i2rs@ietf.org >https://www.ietf.org/mailman/listinfo/i2rs ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, = puede contener informaci=C3=B3n privilegiada o confidencial y es para = uso exclusivo de la persona o entidad de destino. Si no es usted. el = destinatario indicado, queda notificado de que la lectura, = utilizaci=C3=B3n, divulgaci=C3=B3n y/o copia sin autorizaci=C3=B3n puede = estar prohibida en virtud de la legislaci=C3=B3n vigente. Si ha recibido = este mensaje por error, le rogamos que nos lo comunique inmediatamente = por esta misma v=C3=ADa y proceda a su destrucci=C3=B3n. The information contained in this transmission is privileged and = confidential information intended only for the use of the individual or = entity named above. If the reader of this message is not the intended = recipient, you are hereby notified that any dissemination, distribution = or copying of this communication is strictly prohibited. If you have = received this transmission in error, do not read it. Please immediately = reply to the sender that you have received this communication in error = and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu = destinat=C3=A1rio, pode conter informa=C3=A7=C3=A3o privilegiada ou = confidencial e =C3=A9 para uso exclusivo da pessoa ou entidade de = destino. Se n=C3=A3o =C3=A9 vossa senhoria o destinat=C3=A1rio indicado, = fica notificado de que a leitura, utiliza=C3=A7=C3=A3o, = divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem autoriza=C3=A7=C3=A3o pode = estar proibida em virtude da legisla=C3=A7=C3=A3o vigente. Se recebeu = esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente = por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o From nobody Mon Nov 30 10:15:13 2015 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F3EE41B2F84; Tue, 24 Nov 2015 02:55:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151124105507.12354.2122.idtracker@ietfa.amsl.com> Date: Tue, 24 Nov 2015 02:55:07 -0800 Archived-At: X-Mailman-Approved-At: Mon, 30 Nov 2015 10:15:13 -0800 Subject: [i2rs] The I2RS WG has placed draft-psarkar-idr-bgp-ls-node-admin-tag-extension in state "Call For Adoption By WG Issued" X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 10:55:08 -0000 The I2RS WG has placed draft-psarkar-idr-bgp-ls-node-admin-tag-extension in state Call For Adoption By WG Issued (entered by Susan Hares) The document is available at https://datatracker.ietf.org/doc/draft-psarkar-idr-bgp-ls-node-admin-tag-extension/ Comment: Adoption passed, awaits the IPR response from authors. From nobody Mon Nov 30 10:18:57 2015 Return-Path: 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 A91EC1B2F7C for ; Mon, 30 Nov 2015 10:18:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.156 X-Spam-Level: X-Spam-Status: No, score=-97.156 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] 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 RWzvhHrxIRhg for ; Mon, 30 Nov 2015 10:18:55 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 573791B2F7B for ; Mon, 30 Nov 2015 10:18:55 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.177; From: "Susan Hares" To: "'Russ White'" <7riw77@gmail.com>, "'PEDRO ANDRES ARANDA GUTIERREZ'" , "'Jeffrey Haas'" References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> <563A97AA.5020308@joelhalpern.com> <00f301d11761$61699130$243cb390$@gmail.com> <563AA59C.4060809@joelhalpern.com> <018101d11764$66b82e50$34288af0$@gmail.com> <20151119203509.GA22415@pfrc.org> <5B54713B-CDE6-4F65-BE79-91F5B9FF3850@telefonica.com> <008d01d12390$064987c0$12dc9740$@gmail.com> <99B64F3B-20A1-4D3C-A445-46D235EDB44D@telefonica.com> <014a01d12394$ec5ffa60$c51fef20$@gmail.com> In-Reply-To: <014a01d12394$ec5ffa60$c51fef20$@gmail.com> Date: Mon, 30 Nov 2015 13:18:39 -0500 Message-ID: <02ae01d12b9b$8a06ed10$9e14c730$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLwMtmz+XLO8+uQ7j5WaenA2rWXRwHVfCJTAW3ySwACzWyr4AJQYvqoAmia70sCRUpXGQJL52qvAewKHZECaD7TrgHLBOvzApMDTUsCqh6d6wGYO72Jm5RSgXA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, "'Joel M. Halpern'" , 'Andy Bierman' Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 18:18:57 -0000 Russ:=20 [Still Catching up on old email.. ] The I2RS priority in the architecture requires each client has 1 = priority. The architecture allows for multiple clients to have the same = priority (client 1 priority 1; client 2 priority 2). The resolution for = two clients having the same priority is first-one at a priority level = wins.=20 I agree that the protocol can only be accurate. The final solution is = the metric that resolves all contention on priority and ties on = priority. =20 Sue=20 -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Russ White Sent: Friday, November 20, 2015 8:11 AM To: 'PEDRO ANDRES ARANDA GUTIERREZ'; 'Jeffrey Haas' Cc: i2rs@ietf.org; 'Joel M. Halpern'; 'Andy Bierman'; 'Susan Hares' Subject: Re: [i2rs] Conversation on Priority and Panes > The danger I see there is that a specific policy applied by one client = > (app) may trigger unintended changes in a part of the "planes of=20 > glass" it is not aware of. Hence a full copy is needed in each client=20 > (app) may be needed=E2=80=A6 This also holds for subscribing to change = > notifications. How can I subscribe to a change notification of = something I=E2=80=99m not or I don=E2=80=99t want to be aware of? I don't see how that's going to be any different whether the alternate = states are held in the agent or on the clients -- either way, doing "x" = might trigger some other client to do "y." The only difference is how = long it takes for the first client to see the second client doing "y," = and then reacting to it by doing "z." Even trying to make certain every = client has a full list of all possible conditions there will still be = race conditions in the mix, so that won't solve the problem, either. At = some point, you're going to hit your head against CAP -- it's just a = matter of where, when, and how to manage it.=20 The only real solution to this sort of problem is to have a definitive = single "metric" that provides an answer to every situation. Just like = with a routing protocol, you can't build a distributed system that uses = more than one metric without ending up with wedgies (hence BGP). Mike = Shand once told me this is an np(complete) problem -- I'm guessing Mike = is right on this one. It seems, to me, that this is precisely what the = "priority" in this system provides -- in any case, the client with the = best priority wins. As no two clients can have the same priority (it's = tied to the client id, from what I remember), it "just works." The one situation you can get in to is when client 1 says "do x," client = 2 says, "do y," and you end up with a routing loop or contradictory = policies applied. This is going to be a problem no matter where the = information is stored. I don't think we can address this at the protocol = level -- all the protocol can do is be as accurate about current state = as it's installed as possible. The agent should be able to detect some = situations like this and refuse to install the offending state. The = clients may be able to detect some of this, as well, and fix things. But = I don't see how we could specify such a thing in the protocol. Or = rather, if we do, when we'd ever be able to stop specifying such = things...=20 :-) Russ _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Mon Nov 30 10:20:14 2015 Return-Path: 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 C43B21B2F83 for ; Mon, 30 Nov 2015 10:20:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.655 X-Spam-Level: X-Spam-Status: No, score=-97.655 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] 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 zHQiV6EaBCDd for ; Mon, 30 Nov 2015 10:20:11 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72FAA1B2C2B for ; Mon, 30 Nov 2015 10:20:11 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.177; From: "Susan Hares" To: "'Russ White'" <7riw77@gmail.com>, "'Alia Atlas'" , "'Andy Bierman'" References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> <563A97AA.5020308@joelhalpern.com> <005101d11798$549a6f10$fdcf4d30$@ndzh.com> <563B0750.70009@joelhalpern.com> <034901d117a1$79a6e7d0$6cf4b770$@gmail.com> <006501d11a35$55b59f10$0120dd30$@gmail.com> In-Reply-To: <006501d11a35$55b59f10$0120dd30$@gmail.com> Date: Mon, 30 Nov 2015 13:20:10 -0500 Message-ID: <02b001d12b9b$c008c320$401a4960$@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: AQLwMtmz+XLO8+uQ7j5WaenA2rWXRwHVfCJTAW3ySwACzWyr4AJQYvqoAmia70sBb/tJ5QHaZBpQAchizYgBnpuM2wGw4AIiAdHBa9abzrTgQA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, "'Joel M. Halpern'" Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 18:20:13 -0000 Russ: Andy has mentioned the latency problem of not having back-up routes repeatedly. My message at IETF 94 was encourage this type of thing to get the I2RS protocol and module out of the "just another configuration model". Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Russ White Sent: Sunday, November 08, 2015 9:54 AM To: 'Alia Atlas'; 'Andy Bierman' Cc: i2rs@ietf.org; 'Joel M. Halpern'; 'Susan Hares' Subject: Re: [i2rs] Conversation on Priority and Panes > ideas of store-if-not-best and handling overwrites and so on. There > was a very clear push back against any such complexity. Feel free to > take a read through the archive. IMHO, then, is severely diminished to the point of being non-useful work. If there is no way to store a "backup route," then any use of I2RS to install LFAs, backup tunnels, and even temporary changes in the routing table, are out of bounds, and I2RS becomes "yet another configuration mechanism." Russ _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Mon Nov 30 10:37:29 2015 Return-Path: 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 0E0E61A066C for ; Mon, 30 Nov 2015 10:37:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 0Y5XhJcElXkv for ; Mon, 30 Nov 2015 10:37:27 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B28DD1A0545 for ; Mon, 30 Nov 2015 10:37:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 9D2636E08A3; Mon, 30 Nov 2015 10:37:27 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id EEBB06E089E; Mon, 30 Nov 2015 10:37:26 -0800 (PST) To: Susan Hares , 'Russ White' <7riw77@gmail.com>, 'Alia Atlas' , 'Andy Bierman' References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> <563A97AA.5020308@joelhalpern.com> <005101d11798$549a6f10$fdcf4d30$@ndzh.com> <563B0750.70009@joelhalpern.com> <034901d117a1$79a6e7d0$6cf4b770$@gmail.com> <006501d11a35$55b59f10$0120dd30$@gmail.com> <02b001d12b9b$c008c320$401a4960$@ndzh.com> From: "Joel M. Halpern" Message-ID: <565C9764.3000401@joelhalpern.com> Date: Mon, 30 Nov 2015 13:37:24 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <02b001d12b9b$c008c320$401a4960$@ndzh.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: i2rs@ietf.org Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 18:37:29 -0000 I think it is important that we either decide that all we care about are route entries, or that we still have a broader scope. If all we want are RIB entries then I suspect we can solve the backup problem in a reasonable fashion. However, when the WG started it was agreed that our scope was significantly larger than just the RIB. With that larger scope, the potential for interactions and similar issues make solving the storage of backup entries significantly more complex, which is a major part of why the WG decided against such an approach. Yours, Joel On 11/30/15 1:20 PM, Susan Hares wrote: > Russ: > > Andy has mentioned the latency problem of not having back-up routes > repeatedly. > > My message at IETF 94 was encourage this type of thing to get the I2RS > protocol and module out of the "just another configuration model". > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Russ White > Sent: Sunday, November 08, 2015 9:54 AM > To: 'Alia Atlas'; 'Andy Bierman' > Cc: i2rs@ietf.org; 'Joel M. Halpern'; 'Susan Hares' > Subject: Re: [i2rs] Conversation on Priority and Panes > > >> ideas of store-if-not-best and handling overwrites and so on. There >> was a very clear push back against any such complexity. Feel free to >> take a read through the archive. > > IMHO, then, is severely diminished to the point of being non-useful work. If > there is no way to store a "backup route," then any use of I2RS to install > LFAs, backup tunnels, and even temporary changes in the routing table, are > out of bounds, and I2RS becomes "yet another configuration mechanism." > > Russ > > _______________________________________________ > 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 > From nobody Mon Nov 30 10:49:45 2015 Return-Path: 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 8B38E1A011C for ; Mon, 30 Nov 2015 10:49:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 cxpHqegFi-q0 for ; Mon, 30 Nov 2015 10:49:41 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DE001A6F12 for ; Mon, 30 Nov 2015 10:49:40 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.177; From: "Susan Hares" To: "'PEDRO ANDRES ARANDA GUTIERREZ'" , "'Russ White'" <7riw77@gmail.com>, "'Jeffrey Haas'" References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> <563A97AA.5020308@joelhalpern.com> <00f301d11761$61699130$243cb390$@gmail.com> <563AA59C.4060809@joelhalpern.com> <018101d11764$66b82e50$34288af0$@gmail.com> <20151119203509.GA22415@pfrc.org> <5B54713B-CDE6-4F65-BE79-91F5B9FF3850@telefonica.com> <008d01d12390$064987c0$12dc9740$@gmail.com> <99B64F3B-20A1-4D3C-A445-46D235EDB44D@telefonica.com> <014a01d12394$ec5ffa60$c51fef20$@gmail.com> <87361DB1-DC6F-4023-A807-4003B436B472@telefonica.com> <012501d125e7$62e457e0$28ad07a0$@gmail.com> <0EAC7123-CECA-4C34-B5E3-E89F0C8DBF94@telefonica.com> In-Reply-To: <0EAC7123-CECA-4C34-B5E3-E89F0C8DBF94@telefonica.com> Date: Mon, 30 Nov 2015 13:49:26 -0500 Message-ID: <02b901d12b9f$d6d012d0$84703870$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02BA_01D12B75.EE01ABF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLwMtmz+XLO8+uQ7j5WaenA2rWXRwHVfCJTAW3ySwACzWyr4AJQYvqoAmia70sCRUpXGQJL52qvAewKHZECaD7TrgHLBOvzApMDTUsCqh6d6wGYO72JAaqfRnQB3roy9wI57+drm2ZAarA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, "'Joel M. Halpern'" , 'Andy Bierman' Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 18:49:44 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02BA_01D12B75.EE01ABF0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Pedro:=20 =20 =20 For my person insight (as IDR chair) I would like to hear off-list how = you think Griffin's work applies to the I2RS context. Russ has given = his reason why. =20 =20 I agree I2RS is now discussion the conflict of configuration between = clients=20 =C2=B7 assume that we have two or more clients that produce = perfectly sound routing information (no wedgies there),=20 =C2=B7 assume they talk to the same agent For your questions:=20 1.- is there any way to detect whether the clients produce = contradicting/conflicting information? 2.- is there any way to resolve these contradictions/conflicts? =20 =C2=B7 I think you must break determine if you are working on = the same data model or linked models. =20 =C2=B7 Currently we use the priority metric + First wins.=20 =20 I=E2=80=99m interest to hear about alternative ways. =20 Please note that I have not changed what will be in I2RS protocol = version 1, but it is important to provide additional insight to = NETCONF/RESTCONF-I2RS protocol team on what might come in generation 2 = of the I2RS protocol.=20 =20 Sue=20 -----Original Message----- From: PEDRO ANDRES ARANDA GUTIERREZ = [mailto:pedroa.aranda@telefonica.com]=20 Sent: Tuesday, November 24, 2015 10:32 AM To: Russ White; 'Jeffrey Haas' Cc: i2rs@ietf.org; 'Joel M. Halpern'; 'Andy Bierman'; 'Susan Hares' Subject: Re: [i2rs] Conversation on Priority and Panes =20 Hi Russ, =20 I=E2=80=99m trying to identify the differences between interactions with = routing protocols in I2RS and what is purely conflicts between clients. = Currently I see too many issues overlapping and I fear that the trees = are not letting us see the forest. =20 So my take on routing protocols and wedgies might have been too compact = :-) Let me give it a second try: Stepping outside the I2RS problem = space, there is a lot of work that shows that the origin for BGP-4 = instability is that our beloved route-maps create metrics that are not = monotonically increasing or decreasing and that makes the routing = protocols meta-stable. (BTW, I=E2=80=99m the first culprit when it comes = to the use of them, I have created more than one wedgie :-P ) = Acknowledging that this is a significant (and quite complex) problem for = the Internet in general, I feel that it should be treated somewhere else = (GROW?). =20 The perspective I would like to take here is: - assume that we have two or more clients that produce perfectly sound = routing information (no wedgies there) - assume they talk to the same agent - now my questions 1.- is there any way to detect whether the clients produce = contradicting/conflicting information? 2.- is there any way to resolve these contradictions/conflicts? =20 BR, /PA --- Dr. Pedro A. Aranda Guti=C3=A9rrez =20 Technology Exploration - Network Innovation & Virtualisation email: pedroa d0t aranda At telefonica d0t com Telef=C3=B3nica, = Investigaci=C3=B3n y Desarrollo C/ Zurbar=C3=A1n,12 28010 Madrid, Spain =20 Fragen sind nicht da, um beantwortet zu werden. Fragen sind da, um gestellt zu werden. Georg Kreisler =20 =20 =20 =20 =20 =20 =20 =20 -----Mensaje original----- De: Russ White < 7riw77@gmail.com> Fecha: lunes, 23 de noviembre de 2015, 14:06 Para: paag < = pedroa.aranda@telefonica.com>, 'Jeffrey Haas' < = jhaas@pfrc.org> CC: " i2rs@ietf.org" < = i2rs@ietf.org>, "'Joel M. Halpern'" < = jmh@joelhalpern.com>, 'Andy Bierman' < = andy@yumaworks.com>, Sue Hares < = shares@ndzh.com> Asunto: RE: [i2rs] Conversation on Priority and Panes =20 >=20 >> Re the metric 'problem', just to be more precise in what would be=20 >> needed, we are looking a metric that grows or decreases monotonically = >> across the whole network. >=20 >I assume you mean in the routing space, and not in the = controller/client space, correct? In terms of a distributed protocol? = So, you're saying the delay could use "metrics" between 11 and 20, while = the bandwidth could use "metrics" between 21 and 30, etc? And then you = just add them all together? That's what IS-IS has done for years... Even = BGP really only has one "metric," with following "tie breakers..." So if = you have something like weight/local pref/etc, such that they occupy = different "spaces" in a bit pattern (something suggested, btw, in the = original wide community work, and in other places, as well), you're = actually just building a single metric. >=20 >You've not "solved" the multiple metric problem -- just done something = a little different than EIGRP's K values to combine them into a single = metric, which is where you need to be to have the ability to build a = single stable SPT/DAG. >=20 >> The theoretical grounds for this are in T. Griffin=E2=80=99s and = Sobrinho=E2=80=99s=20 >> work on BGP-4 and that lies already a couple of years ago and that=20 >> makes the analysis much =E2=80=98easier=E2=80=99 (no worries about = np(complete)=20 >> problems, etc.). This could be applied in I2RS at the routing=20 >> protocol level. So, we could discuss where that sits (should be the=20 >> clients, right?) and I don=E2=80=99t know if that=E2=80=99s been = already done, since I=E2=80=99m quite new to this list. >=20 >This doesn=E2=80=99t apply to the problem at hand, though... You seem = to be=20 >saying (clarify if wrong) -- >=20 >1. Give each client some set of bits out of a 128 bit number space (or=20 >larger, etc.) 2. Each client can have different "metrics" within their=20 >own number space 3. When a client attempts to add some ephemeral state, = they use a metric within their "space" >4. The agent can just use the straight number as a relative priority=20 >for each potential piece of state >=20 >This doesn't do anything different than the current concept of priority = between clients, only in the current plan each client only has one = priority, rather than multiples. I don't see where this relates to the = problem at hand. >=20 >> Now, having =E2=80=9Csolved=E2=80=9D that part of the equation :-) , = the part that=20 >> interests me more is the conflicting clients problem, because this=20 >> could be generalised to other problem spaces in the SDN area. I do=20 >> agree that agents should be able to catch offending state before=20 >> installing it and I=E2=80=99m looking for ways to specify a minimal = set of features that need to be supported at protocol level. >>=20 >> Anyone else interested? >=20 >This is precisely where the problem lies. And this is where you're=20 >going to hit the CAP theorem in full force. There are only a few=20 >choices -- >=20 >1. Make the database eventually consistent 2. Shut down accessibility=20 >during changes 3. ?? >=20 >(1) is the idea of either having the agent call back to all the clients = >when state they installed is overwritten or allowing the agent to=20 >locally store some state where it already has the information in hand=20 >and install it locally -- the only real difference between these two=20 >solutions is the "balance of complexity versus speed..." The entire=20 >discussion here is how much additional complexity are we actually=20 >adding by doing "panes of glass," which are just locally stored state=20 >which isn't currently installed. I'm arguing that there's minimal=20 >complexity added that you're not already going to have in the system to = >allow the agent to store information locally _if_ it chooses to. Jeff=20 >is arguing (I think) that the "panes of glass" concept is a coherent=20 >way of looking at this problem that will help us understand and manage=20 >the complexity in a way that makes sense. Joel is arguing (I think)=20 >that this sort of solution is out of the WG charter, and it's too=20 >complex. I _think_ I have the three general perspectives right, but I=20 >don't know if I really have so... :-) >=20 >(2) is the idea of locking the database while you're changing it. This = is explicitly outside the scope of I2RS entirely, given we're trying to = design something that's atomic/restful. There are a lot of techniques = you can use to speed up locking -- row locking, sharding, etc. -- but = none of these are interesting from the I2RS perspective. >=20 >:-) >=20 >Russ >=20 =20 ________________________________ =20 Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, = puede contener informaci=C3=B3n privilegiada o confidencial y es para = uso exclusivo de la persona o entidad de destino. Si no es usted. el = destinatario indicado, queda notificado de que la lectura, = utilizaci=C3=B3n, divulgaci=C3=B3n y/o copia sin autorizaci=C3=B3n puede = estar prohibida en virtud de la legislaci=C3=B3n vigente. Si ha recibido = este mensaje por error, le rogamos que nos lo comunique inmediatamente = por esta misma v=C3=ADa y proceda a su destrucci=C3=B3n. =20 The information contained in this transmission is privileged and = confidential information intended only for the use of the individual or = entity named above. If the reader of this message is not the intended = recipient, you are hereby notified that any dissemination, distribution = or copying of this communication is strictly prohibited. If you have = received this transmission in error, do not read it. Please immediately = reply to the sender that you have received this communication in error = and then delete it. =20 Esta mensagem e seus anexos se dirigem exclusivamente ao seu = destinat=C3=A1rio, pode conter informa=C3=A7=C3=A3o privilegiada ou = confidencial e =C3=A9 para uso exclusivo da pessoa ou entidade de = destino. Se n=C3=A3o =C3=A9 vossa senhoria o destinat=C3=A1rio indicado, = fica notificado de que a leitura, utiliza=C3=A7=C3=A3o, = divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem autoriza=C3=A7=C3=A3o pode = estar proibida em virtude da legisla=C3=A7=C3=A3o vigente. Se recebeu = esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente = por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o ------=_NextPart_000_02BA_01D12B75.EE01ABF0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Pedro: =

 

<WG hat off>

For my person insight (as IDR chair) I would like = to hear off-list how you think Griffin's work applies to the I2RS = context.=C2=A0 Russ has given his reason why.=C2=A0

 

I = agree I2RS is now discussion the conflict of configuration between = clients

=C2=B7         = assume that we have two or more clients = that produce perfectly sound routing information (no wedgies there), =

=C2=B7         = =C2=A0assume they talk to the same = agent

For your questions:

=C2=A0=C2=A0=C2=A01.- is there any way to detect = whether the clients produce contradicting/conflicting = information?

=C2=A0 2.- is there = any way to resolve these contradictions/conflicts?

 

=C2=B7         = I think you must break determine if you = are working on the same data model or linked models.=C2=A0 =

=C2=B7         = Currently we use the priority metric + = First wins.

 

I=E2=80=99m interest to hear about alternative = ways.

<WG Hat on> =

Please note that I have not = changed what will be in I2RS protocol version 1, but it is important to = provide additional insight to NETCONF/RESTCONF-I2RS protocol team on = what might come=C2=A0 in generation 2 of the I2RS protocol. =

<WG Hat off> =

Sue

-----Original Message-----
From: PEDRO ANDRES = ARANDA GUTIERREZ [mailto:pedroa.aranda@telefonica.com]
Sent: = Tuesday, November 24, 2015 10:32 AM
To: Russ White; 'Jeffrey = Haas'
Cc: i2rs@ietf.org; 'Joel M. Halpern'; 'Andy Bierman'; 'Susan = Hares'
Subject: Re: [i2rs] Conversation on Priority and Panes

 

Hi = Russ,

 

I=E2=80=99m trying to identify the differences = between interactions with routing protocols in I2RS and what is purely = conflicts between clients. Currently I see too many issues overlapping = and I fear that the trees are not letting us see the = forest.

 

So my take on routing protocols and wedgies might = have been too compact :-) Let me give it a second try: Stepping outside = the I2RS problem space, there is a lot of work that shows that the = origin for BGP-4 instability is that our beloved route-maps create = metrics that are not monotonically increasing or decreasing and that = makes the routing protocols meta-stable. (BTW, I=E2=80=99m the first = culprit when it comes to the use of them, I have created more than one = wedgie :-P ) Acknowledging that this is a significant (and quite = complex) problem for the Internet in general, I feel that it should be = treated somewhere else (GROW?).

 

The = perspective I would like to take here is:

- assume that we have two or more clients that = produce perfectly sound routing information (no wedgies = there)

- assume they talk to the = same agent

- now my = questions

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1.- is = there any way to detect whether the clients produce = contradicting/conflicting information?

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2.- is = there any way to resolve these = contradictions/conflicts?

 

BR, = /PA

---

Dr. Pedro A. Aranda Guti=C3=A9rrez

 

Technology Exploration -

Network Innovation & = Virtualisation

email: pedroa d0t = aranda At telefonica d0t com Telef=C3=B3nica, Investigaci=C3=B3n y = Desarrollo C/ Zurbar=C3=A1n,12

28010 Madrid, Spain

 

Fragen = sind nicht da, um beantwortet zu werden.

Fragen sind da, um gestellt zu = werden.

Georg = Kreisler

 

 

 

 

 

 

 

 

-----Mensaje original-----

De: Russ White <7riw77@gmail.com>

Fecha: lunes, 23 de = noviembre de 2015, 14:06

Para: = paag <pedroa.aranda@telefonica.= com>, 'Jeffrey Haas' <jhaas@pfrc.org= >

CC: "i2rs@ietf.org&= quot; <i2rs@ietf.org&= gt;, "'Joel M. Halpern'" <jmh@joelhalpern.com>, 'Andy Bierman' <andy@yumaworks.com= >, Sue Hares <shares@ndzh.com>

Asunto: RE: [i2rs] = Conversation on Priority and Panes

 

> 

>> Re the metric 'problem', just to be more = precise in what would be

>> = needed, we are looking a metric that grows or decreases monotonically =

>> across the whole = network.

> 

>I assume you mean in the routing space, and not = in the controller/client space, correct? In terms of a distributed = protocol? So, you're saying the delay could use "metrics" = between 11 and 20, while the bandwidth could use "metrics" = between 21 and 30, etc? And then you just add them all together? That's = what IS-IS has done for years... Even BGP really only has one = "metric," with following "tie breakers..." So if you = have something like weight/local pref/etc, such that they occupy = different "spaces" in a bit pattern (something suggested, btw, = in the original wide community work, and in other places, as well), = you're actually just building a single metric.

> 

>You've not "solved" the multiple = metric problem -- just done something a little different than EIGRP's K = values to combine them into a single metric, which is where you need to = be to have the ability to build a single stable = SPT/DAG.

> 

>> The theoretical grounds for this are in T. = Griffin=E2=80=99s and Sobrinho=E2=80=99s

>> work on BGP-4 and that lies already a = couple of years ago and that

>> makes the analysis much = =E2=80=98easier=E2=80=99 (no worries about np(complete) =

>> problems, etc.). This = could be applied in I2RS at the routing

>> protocol level. So, we could discuss where = that sits (should be the

>> = clients, right?) and I don=E2=80=99t know if that=E2=80=99s been already = done, since I=E2=80=99m quite new to this list.

> 

>This doesn=E2=80=99t apply to the problem at = hand, though... You seem to be

>saying (clarify if wrong) --

> 

>1. Give each client some set of bits out of a = 128 bit number space (or

>larger, etc.) 2. Each client can have different = "metrics" within their

>own number space 3. When a client attempts to = add some ephemeral state, they use a metric within their = "space"

>4. The agent = can just use the straight number as a relative priority =

>for each potential piece of = state

> 

>This doesn't do anything different than the = current concept of priority between clients, only in the current plan = each client only has one priority, rather than multiples. I don't see = where this relates to the problem at hand.

> 

>> Now, having =E2=80=9Csolved=E2=80=9D that = part of the equation :-) , the part that

>> interests me more is the conflicting = clients problem, because this

>> could be generalised to other problem = spaces in the SDN area. I do

>> agree that agents should be able to catch = offending state before

>> = installing it and I=E2=80=99m looking for ways to specify a minimal set = of features that need to be supported at protocol = level.

>> 

>> Anyone else interested?

> 

>This is precisely where the problem lies. And = this is where you're

>going to = hit the CAP theorem in full force. There are only a few =

>choices --

> 

>1. Make the database eventually consistent 2. = Shut down accessibility

>during changes 3. ??

> 

>(1) is the idea of either having the agent call = back to all the clients

>when = state they installed is overwritten or allowing the agent to =

>locally store some state = where it already has the information in hand

>and install it locally -- the only real = difference between these two

>solutions is the "balance of complexity = versus speed..." The entire

>discussion here is how much additional = complexity are we actually

>adding by doing "panes of glass," = which are just locally stored state

>which isn't currently installed. I'm arguing = that there's minimal

>complexity added that you're not already going = to have in the system to

>allow the agent to store information locally = _if_ it chooses to. Jeff

>is = arguing (I think) that the "panes of glass" concept is a = coherent

>way of looking at = this problem that will help us understand and manage

>the complexity in a way that makes sense. Joel = is arguing (I think)

>that = this sort of solution is out of the WG charter, and it's too =

>complex. I _think_ I have the = three general perspectives right, but I

>don't know if I really have so... = :-)

> 

>(2) is the idea of locking the database while = you're changing it. This is explicitly outside the scope of I2RS = entirely, given we're trying to design something that's atomic/restful. = There are a lot of techniques you can use to speed up locking -- row = locking, sharding, etc. -- but none of these are interesting from the = I2RS perspective.

> 

>:-)

> 

>Russ

> 

 

________________________________

 

Este = mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, = puede contener informaci=C3=B3n privilegiada o confidencial y es para = uso exclusivo de la persona o entidad de destino. Si no es usted. el = destinatario indicado, queda notificado de que la lectura, = utilizaci=C3=B3n, divulgaci=C3=B3n y/o copia sin autorizaci=C3=B3n puede = estar prohibida en virtud de la legislaci=C3=B3n vigente. Si ha recibido = este mensaje por error, le rogamos que nos lo comunique inmediatamente = por esta misma v=C3=ADa y proceda a su = destrucci=C3=B3n.

 

The = information contained in this transmission is privileged and = confidential information intended only for the use of the individual or = entity named above. If the reader of this message is not the intended = recipient, you are hereby notified that any dissemination, distribution = or copying of this communication is strictly prohibited. If you have = received this transmission in error, do not read it. Please immediately = reply to the sender that you have received this communication in error = and then delete it.

 

Esta = mensagem e seus anexos se dirigem exclusivamente ao seu = destinat=C3=A1rio, pode conter informa=C3=A7=C3=A3o privilegiada ou = confidencial e =C3=A9 para uso exclusivo da pessoa ou entidade de = destino. Se n=C3=A3o =C3=A9 vossa senhoria o destinat=C3=A1rio indicado, = fica notificado de que a leitura, utiliza=C3=A7=C3=A3o, = divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem autoriza=C3=A7=C3=A3o pode = estar proibida em virtude da legisla=C3=A7=C3=A3o vigente. Se recebeu = esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente = por esta mesma via e proceda a sua = destrui=C3=A7=C3=A3o

------=_NextPart_000_02BA_01D12B75.EE01ABF0-- From nobody Mon Nov 30 11:03:57 2015 Return-Path: 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 7125C1ACE13 for ; Mon, 30 Nov 2015 11:03:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 rYwgXXEYJ9G6 for ; Mon, 30 Nov 2015 11:03:52 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 617571A9037 for ; Mon, 30 Nov 2015 11:03:52 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.177; From: "Susan Hares" To: "'Joel M. Halpern'" , "'PEDRO ANDRES ARANDA GUTIERREZ'" , "'Russ White'" <7riw77@gmail.com>, "'Jeffrey Haas'" References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> <563A97AA.5020308@joelhalpern.com> <00f301d11761$61699130$243cb390$@gmail.com> <563AA59C.4060809@joelhalpern.com> <018101d11764$66b82e50$34288af0$@gmail.com> <20151119203509.GA22415@pfrc.org> <5B54713B-CDE6-4F65-BE79-91F5B9FF3850@telefonica.com> <008d01d12390$064987c0$12dc9740$@gmail.com> <99B64F3B-20A1-4D3C-A445-46D235EDB44D@telefonica.com> <014a01d12394$ec5ffa60$c51fef20$@gmail.com> <87361DB1-DC6F-4023-A807-4003B436B472@telefonica.com> <012501d125e7$62e457e0$28ad07a0$@gmail.com> <0EAC7123-CECA-4C34-B5E3-E89F0C8DBF94@telefonica.com> <56548418.6060603@joelhalpern.com> In-Reply-To: <56548418.6060603@joelhalpern.com> Date: Mon, 30 Nov 2015 14:03:38 -0500 Message-ID: <02d301d12ba1$d2b6f630$7824e290$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02D4_01D12B77.E9E88F50" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLwMtmz+XLO8+uQ7j5WaenA2rWXRwHVfCJTAW3ySwACzWyr4AJQYvqoAmia70sCRUpXGQJL52qvAewKHZECaD7TrgHLBOvzApMDTUsCqh6d6wGYO72JAaqfRnQB3roy9wI57+drAP23N4mbXlYS8A== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, 'Andy Bierman' Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 19:03:56 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02D4_01D12B77.E9E88F50 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Joel:=20 I2RS agreed the following for the first version of the I2RS protocol and = models.=20 =20 As far as I know, the I2RS working group concluded that it was a = sufficiently hard problem that we did not expect the I2RS agent to get = involved in trying to detect, much less remediate, such cross-object = inconsistencies. =20 If I2RS WG members think this is valuable for a future version of the = I2RS protocol, it is important to indicate this point. =20 =20 If I2RS WG members feel that this mediation is necessarily for a = successful I2RS protocol, the chair would like to hear why and in what = operational use cases. Can we deploy simple applications using I2RS = without it? This question should be taken in context of the I2RS = requirements process which has complete WG LC, but if you have a major = error. =20 =20 =20 =20 On whether the statement of: =E2=80=9Cwhether two independent and = internally consistent sets of changes can, in combination, produce a = wedgie or other failure is a research problem.=E2=80=9D=20 I do not think this was Pedro=E2=80=99s point, but I=E2=80=99ll let him = respond to this point.=20 =20 Sue=20 -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Tuesday, November 24, 2015 10:37 AM To: PEDRO ANDRES ARANDA GUTIERREZ; Russ White; 'Jeffrey Haas' Cc: i2rs@ietf.org; 'Joel M. Halpern'; 'Andy Bierman'; 'Susan Hares' Subject: Re: [i2rs] Conversation on Priority and Panes =20 I believe that determining whether two independent and internally = consistent sets of changes can, in combination, produce a wedgie or = other failure is a research problem. As far as I know, the I2RS working group concluded that it was a = sufficiently hard problem that we did not expect the I2RS agent to get = involved in trying to detect, much less remediate, such cross-object = inconsistencies. =20 Yours, Joel =20 On 11/24/15 10:32 AM, PEDRO ANDRES ARANDA GUTIERREZ wrote: > Hi Russ, >=20 > I=E2=80=99m trying to identify the differences between interactions = with routing protocols in I2RS and what is purely conflicts between = clients. Currently I see too many issues overlapping and I fear that the = trees are not letting us see the forest. >=20 > So my take on routing protocols and wedgies might have been too = compact :-) Let me give it a second try: Stepping outside the I2RS = problem space, there is a lot of work that shows that the origin for = BGP-4 instability is that our beloved route-maps create metrics that are = not monotonically increasing or decreasing and that makes the routing = protocols meta-stable. (BTW, I=E2=80=99m the first culprit when it comes = to the use of them, I have created more than one wedgie :-P ) = Acknowledging that this is a significant (and quite complex) problem for = the Internet in general, I feel that it should be treated somewhere else = (GROW?). >=20 > The perspective I would like to take here is: > - assume that we have two or more clients that produce perfectly sound = > routing information (no wedgies there) > - assume they talk to the same agent > - now my questions > 1.- is there any way to detect whether the clients produce = contradicting/conflicting information? > 2.- is there any way to resolve these = contradictions/conflicts? >=20 > BR, /PA > --- > Dr. Pedro A. Aranda Guti=C3=A9rrez >=20 > Technology Exploration - > Network Innovation & Virtualisation > email: pedroa d0t aranda At telefonica d0t com Telef=C3=B3nica,=20 > Investigaci=C3=B3n y Desarrollo C/ Zurbar=C3=A1n,12 > 28010 Madrid, Spain >=20 > Fragen sind nicht da, um beantwortet zu werden. > Fragen sind da, um gestellt zu werden. > Georg Kreisler >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -----Mensaje original----- > De: Russ White < 7riw77@gmail.com> > Fecha: lunes, 23 de noviembre de 2015, 14:06 > Para: paag < = pedroa.aranda@telefonica.com>, 'Jeffrey Haas'=20 > < jhaas@pfrc.org> > CC: " i2rs@ietf.org" < = i2rs@ietf.org>, "'Joel M. Halpern'"=20 > < jmh@joelhalpern.com>, 'Andy Bierman' < = andy@yumaworks.com>, Sue Hares=20 > < shares@ndzh.com> > Asunto: RE: [i2rs] Conversation on Priority and Panes >=20 >>=20 >>> Re the metric 'problem', just to be more precise in what would be=20 >>> needed, we are looking a metric that grows or decreases=20 >>> monotonically across the whole network. >>=20 >> I assume you mean in the routing space, and not in the = controller/client space, correct? In terms of a distributed protocol? = So, you're saying the delay could use "metrics" between 11 and 20, while = the bandwidth could use "metrics" between 21 and 30, etc? And then you = just add them all together? That's what IS-IS has done for years... Even = BGP really only has one "metric," with following "tie breakers..." So if = you have something like weight/local pref/etc, such that they occupy = different "spaces" in a bit pattern (something suggested, btw, in the = original wide community work, and in other places, as well), you're = actually just building a single metric. >>=20 >> You've not "solved" the multiple metric problem -- just done = something a little different than EIGRP's K values to combine them into = a single metric, which is where you need to be to have the ability to = build a single stable SPT/DAG. >>=20 >>> The theoretical grounds for this are in T. Griffin=E2=80=99s and = Sobrinho=E2=80=99s=20 >>> work on BGP-4 and that lies already a couple of years ago and that=20 >>> makes the analysis much =E2=80=98easier=E2=80=99 (no worries about = np(complete)=20 >>> problems, etc.). This could be applied in I2RS at the routing=20 >>> protocol level. So, we could discuss where that sits (should be the=20 >>> clients, right?) and I don=E2=80=99t know if that=E2=80=99s been = already done, since I=E2=80=99m quite new to this list. >>=20 >> This doesn=E2=80=99t apply to the problem at hand, though... You seem = to be=20 >> saying (clarify if wrong) -- >>=20 >> 1. Give each client some set of bits out of a 128 bit number space=20 >> (or larger, etc.) 2. Each client can have different "metrics" within=20 >> their own number space 3. When a client attempts to add some = ephemeral state, they use a metric within their "space" >> 4. The agent can just use the straight number as a relative priority=20 >> for each potential piece of state >>=20 >> This doesn't do anything different than the current concept of = priority between clients, only in the current plan each client only has = one priority, rather than multiples. I don't see where this relates to = the problem at hand. >>=20 >>> Now, having =E2=80=9Csolved=E2=80=9D that part of the equation :-) , = the part that=20 >>> interests me more is the conflicting clients problem, because this=20 >>> could be generalised to other problem spaces in the SDN area. I do=20 >>> agree that agents should be able to catch offending state before=20 >>> installing it and I=E2=80=99m looking for ways to specify a minimal = set of features that need to be supported at protocol level. >>>=20 >>> Anyone else interested? >>=20 >> This is precisely where the problem lies. And this is where you're=20 >> going to hit the CAP theorem in full force. There are only a few=20 >> choices -- >>=20 >> 1. Make the database eventually consistent 2. Shut down accessibility = >> during changes 3. ?? >>=20 >> (1) is the idea of either having the agent call back to all the=20 >> clients when state they installed is overwritten or allowing the=20 >> agent to locally store some state where it already has the=20 >> information in hand and install it locally -- the only real=20 >> difference between these two solutions is the "balance of complexity=20 >> versus speed..." The entire discussion here is how much additional=20 >> complexity are we actually adding by doing "panes of glass," which=20 >> are just locally stored state which isn't currently installed. I'm=20 >> arguing that there's minimal complexity added that you're not already = >> going to have in the system to allow the agent to store information=20 >> locally _if_ it chooses to. Jeff is arguing (I think) that the "panes = >> of glass" concept is a coherent way of looking at this problem that=20 >> will help us understand and manage the complexity in a way that makes = >> sense. Joel is arguing (I think) that this sort of solution is out of = >> the WG charter, and it's too complex. I _think_ I have the th r ee general perspectives right, but I don't know if I really have so... = :-) >>=20 >> (2) is the idea of locking the database while you're changing it. = This is explicitly outside the scope of I2RS entirely, given we're = trying to design something that's atomic/restful. There are a lot of = techniques you can use to speed up locking -- row locking, sharding, = etc. -- but none of these are interesting from the I2RS perspective. >>=20 >> :-) >>=20 >> Russ >>=20 >=20 > ________________________________ >=20 > Este mensaje y sus adjuntos se dirigen exclusivamente a su = destinatario, puede contener informaci=C3=B3n privilegiada o = confidencial y es para uso exclusivo de la persona o entidad de destino. = Si no es usted. el destinatario indicado, queda notificado de que la = lectura, utilizaci=C3=B3n, divulgaci=C3=B3n y/o copia sin = autorizaci=C3=B3n puede estar prohibida en virtud de la legislaci=C3=B3n = vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=C3=ADa y proceda a su = destrucci=C3=B3n. >=20 > The information contained in this transmission is privileged and = confidential information intended only for the use of the individual or = entity named above. If the reader of this message is not the intended = recipient, you are hereby notified that any dissemination, distribution = or copying of this communication is strictly prohibited. If you have = received this transmission in error, do not read it. Please immediately = reply to the sender that you have received this communication in error = and then delete it. >=20 > Esta mensagem e seus anexos se dirigem exclusivamente ao seu=20 > destinat=C3=A1rio, pode conter informa=C3=A7=C3=A3o privilegiada ou = confidencial e =C3=A9 para uso exclusivo da pessoa ou entidade de = destino. Se n=C3=A3o =C3=A9 vossa senhoria o destinat=C3=A1rio indicado, = fica notificado de que a leitura, utiliza=C3=A7=C3=A3o, = divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem autoriza=C3=A7=C3=A3o pode = estar proibida em virtude da legisla=C3=A7=C3=A3o vigente. Se recebeu = esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente = por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o >=20 ------=_NextPart_000_02D4_01D12B77.E9E88F50 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Joel: =

<WG Hat = on>

I2RS agreed the following = for the first version of the I2RS protocol and models.

 

As far = as I know, the I2RS working group concluded that it was a sufficiently = hard problem that we did not expect the I2RS agent to get involved in = trying to detect, much less remediate, such cross-object = inconsistencies.

 

If = I2RS WG members think this is valuable for a future version of the I2RS = protocol, it is important to indicate this point. = =C2=A0

 

If I2RS WG members feel that this mediation is = necessarily for a successful I2RS protocol, the chair would like to hear = why and in what operational use cases.=C2=A0 Can we deploy simple = applications using I2RS without it? =C2=A0This question should be taken = in context of the I2RS requirements process which has complete WG LC, = but if you have a major error.=C2=A0

 

</WG hat off>

 

On = whether the statement of: =C2=A0=E2=80=9Cwhether two independent and = internally consistent sets of changes can, in combination, produce a = wedgie or other failure is a research problem.=E2=80=9D =

I do not think this was = Pedro=E2=80=99s point, but I=E2=80=99ll let him respond to this point. =

 

Sue

-----Original Message-----
From: Joel M. Halpern = [mailto:jmh@joelhalpern.com]
Sent: Tuesday, November 24, 2015 10:37 = AM
To: PEDRO ANDRES ARANDA GUTIERREZ; Russ White; 'Jeffrey = Haas'
Cc: i2rs@ietf.org; 'Joel M. Halpern'; 'Andy Bierman'; 'Susan = Hares'
Subject: Re: [i2rs] Conversation on Priority and Panes

 

I = believe that determining whether two independent and internally = consistent sets of changes can, in combination, produce a wedgie or = other failure is a research problem.

As far as I know, the I2RS working group concluded = that it was a sufficiently hard problem that we did not expect the I2RS = agent to get involved in trying to detect, much less remediate, such = cross-object inconsistencies.

 

Yours,

Joel

 

On = 11/24/15 10:32 AM, PEDRO ANDRES ARANDA GUTIERREZ wrote:

> Hi Russ,

> 

> I=E2=80=99m trying to identify the differences = between interactions with routing protocols in I2RS and what is purely = conflicts between clients. Currently I see too many issues overlapping = and I fear that the trees are not letting us see the = forest.

> 

> So my take on routing protocols and wedgies = might have been too compact :-) Let me give it a second try: Stepping = outside the I2RS problem space, there is a lot of work that shows that = the origin for BGP-4 instability is that our beloved route-maps create = metrics that are not monotonically increasing or decreasing and that = makes the routing protocols meta-stable. (BTW, I=E2=80=99m the first = culprit when it comes to the use of them, I have created more than one = wedgie :-P ) Acknowledging that this is a significant (and quite = complex) problem for the Internet in general, I feel that it should be = treated somewhere else (GROW?).

> 

> The perspective I would like to take here = is:

> - assume that we have two = or more clients that produce perfectly sound

> routing information (no wedgies = there)

> - assume they talk to = the same agent

> - now my = questions

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 1.- is there any way to detect whether the clients produce = contradicting/conflicting information?

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 2.- is there any way to resolve these = contradictions/conflicts?

> 

> BR, /PA

> ---

> = Dr. Pedro A. Aranda Guti=C3=A9rrez

> 

> Technology Exploration -

> Network Innovation & = Virtualisation

> email: pedroa = d0t aranda At telefonica d0t com Telef=C3=B3nica,

> Investigaci=C3=B3n y Desarrollo C/ = Zurbar=C3=A1n,12

> 28010 = Madrid, Spain

> 

> Fragen sind nicht da, um beantwortet zu = werden.

> Fragen sind da, um = gestellt zu werden.

> Georg = Kreisler

> 

> 

> 

> 

> 

> 

> 

> 

> -----Mensaje original-----

> De: Russ White <7riw77@gmail.com>

> Fecha: lunes, 23 de = noviembre de 2015, 14:06

> = Para: paag <pedroa.aranda@telefonica.= com>, 'Jeffrey Haas'

> <jhaas@pfrc.org= >

> CC: "i2rs@ietf.org&= quot; <i2rs@ietf.org&= gt;, "'Joel M. Halpern'"

> <jmh@joelhalpern.com>, 'Andy Bierman' <andy@yumaworks.com= >, Sue Hares

> <shares@ndzh.com>

> Asunto: RE: [i2rs] = Conversation on Priority and Panes

> 

>> 

>>> Re the metric 'problem', just to be = more precise in what would be

>>> needed, we are looking a metric that = grows or decreases

>>> = monotonically across the whole network.

>> 

>> I assume you mean in the routing space, = and not in the controller/client space, correct? In terms of a = distributed protocol? So, you're saying the delay could use = "metrics" between 11 and 20, while the bandwidth could use = "metrics" between 21 and 30, etc? And then you just add them = all together? That's what IS-IS has done for years... Even BGP really = only has one "metric," with following "tie = breakers..." So if you have something like weight/local pref/etc, = such that they occupy different "spaces" in a bit pattern = (something suggested, btw, in the original wide community work, and in = other places, as well), you're actually just building a single = metric.

>> 

>> You've not "solved" the multiple = metric problem -- just done something a little different than EIGRP's K = values to combine them into a single metric, which is where you need to = be to have the ability to build a single stable = SPT/DAG.

>> 

>>> The theoretical grounds for this are = in T. Griffin=E2=80=99s and Sobrinho=E2=80=99s

>>> work on BGP-4 and that lies already a = couple of years ago and that

>>> makes the analysis much = =E2=80=98easier=E2=80=99 (no worries about np(complete) =

>>> problems, etc.). = This could be applied in I2RS at the routing

>>> protocol level. So, we could discuss = where that sits (should be the

>>> clients, right?) and I don=E2=80=99t = know if that=E2=80=99s been already done, since I=E2=80=99m quite new to = this list.

>> 

>> This doesn=E2=80=99t apply to the problem = at hand, though... You seem to be

>> saying (clarify if wrong) = --

>> 

>> 1. Give each client some set of bits out = of a 128 bit number space

>> (or larger, etc.) 2. Each client can have = different "metrics" within

>> their own number space 3. When a client = attempts to add some ephemeral state, they use a metric within their = "space"

>> 4. The = agent can just use the straight number as a relative priority =

>> for each potential piece = of state

>> 

>> This doesn't do anything different than = the current concept of priority between clients, only in the current = plan each client only has one priority, rather than multiples. I don't = see where this relates to the problem at hand.

>> 

>>> Now, having =E2=80=9Csolved=E2=80=9D = that part of the equation :-) , the part that

>>> interests me more is the conflicting = clients problem, because this

>>> could be generalised to other problem = spaces in the SDN area. I do

>>> agree that agents should be able to = catch offending state before

>>> installing it and I=E2=80=99m looking = for ways to specify a minimal set of features that need to be supported = at protocol level.

>>> 

>>> Anyone else = interested?

>> 

>> This is precisely where the problem lies. = And this is where you're

>> = going to hit the CAP theorem in full force. There are only a few =

>> choices = --

>> 

>> 1. Make the database eventually consistent = 2. Shut down accessibility

>> during changes 3. ??

>> 

>> (1) is the idea of either having the agent = call back to all the

>> = clients when state they installed is overwritten or allowing the =

>> agent to locally store = some state where it already has the

>> information in hand and install it locally = -- the only real

>> = difference between these two solutions is the "balance of = complexity

>> versus = speed..." The entire discussion here is how much additional =

>> complexity are we = actually adding by doing "panes of glass," which =

>> are just locally stored = state which isn't currently installed. I'm

>> arguing that there's minimal complexity = added that you're not already

>> going to have in the system to allow the = agent to store information

>> locally _if_ it chooses to. Jeff is = arguing (I think) that the "panes

>> of glass" concept is a coherent way = of looking at this problem that

>> will help us understand and manage the = complexity in a way that makes

>> sense. Joel is arguing (I think) that this = sort of solution is out of

>> the WG charter, and it's too complex. I = _think_ I have the th

= r

ee general perspectives right, = but I don't know if I really have so... :-)

>> 

>> (2) is the idea of locking the database = while you're changing it. This is explicitly outside the scope of I2RS = entirely, given we're trying to design something that's atomic/restful. = There are a lot of techniques you can use to speed up locking -- row = locking, sharding, etc. -- but none of these are interesting from the = I2RS perspective.

>> 

>> :-)

>> 

>> Russ

>> 

> 

> = ________________________________

> 

> Este mensaje y sus adjuntos se dirigen = exclusivamente a su destinatario, puede contener informaci=C3=B3n = privilegiada o confidencial y es para uso exclusivo de la persona o = entidad de destino. Si no es usted. el destinatario indicado, queda = notificado de que la lectura, utilizaci=C3=B3n, divulgaci=C3=B3n y/o = copia sin autorizaci=C3=B3n puede estar prohibida en virtud de la = legislaci=C3=B3n vigente. Si ha recibido este mensaje por error, le = rogamos que nos lo comunique inmediatamente por esta misma v=C3=ADa y = proceda a su destrucci=C3=B3n.

> 

> The information contained in this transmission = is privileged and confidential information intended only for the use of = the individual or entity named above. If the reader of this message is = not the intended recipient, you are hereby notified that any = dissemination, distribution or copying of this communication is strictly = prohibited. If you have received this transmission in error, do not read = it. Please immediately reply to the sender that you have received this = communication in error and then delete it.

> 

> Esta mensagem e seus anexos se dirigem = exclusivamente ao seu

> = destinat=C3=A1rio, pode conter informa=C3=A7=C3=A3o privilegiada ou = confidencial e =C3=A9 para uso exclusivo da pessoa ou entidade de = destino. Se n=C3=A3o =C3=A9 vossa senhoria o destinat=C3=A1rio indicado, = fica notificado de que a leitura, utiliza=C3=A7=C3=A3o, = divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem autoriza=C3=A7=C3=A3o pode = estar proibida em virtude da legisla=C3=A7=C3=A3o vigente. Se recebeu = esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente = por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o

> 

------=_NextPart_000_02D4_01D12B77.E9E88F50-- From nobody Mon Nov 30 11:14:36 2015 Return-Path: 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 5A7D51B2B20 for ; Mon, 30 Nov 2015 11:14:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.055 X-Spam-Level: X-Spam-Status: No, score=-99.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] 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 LTNriLBMm5Zo for ; Mon, 30 Nov 2015 11:14:31 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64EBE1B2B17 for ; Mon, 30 Nov 2015 11:14:31 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.177; From: "Susan Hares" To: "'PEDRO ANDRES ARANDA GUTIERREZ'" , "'Russ White'" <7riw77@gmail.com>, "'Jeffrey Haas'" References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> <563A97AA.5020308@joelhalpern.com> <00f301d11761$61699130$243cb390$@gmail.com> <563AA59C.4060809@joelhalpern.com> <018101d11764$66b82e50$34288af0$@gmail.com> <20151119203509.GA22415@pfrc.org> <5B54713B-CDE6-4F65-BE79-91F5B9FF3850@telefonica.com> <008d01d12390$064987c0$12dc9740$@gmail.com> <99B64F3B-20A1-4D3C-A445-46D235EDB44D@telefonica.com> <014a01d12394$ec5ffa60$c51fef20$@gmail.com> <87361DB1-DC6F-4023-A807-4003B436B472@telefonica.com> In-Reply-To: <87361DB1-DC6F-4023-A807-4003B436B472@telefonica.com> Date: Mon, 30 Nov 2015 14:14:21 -0500 Message-ID: <032701d12ba3$51e0b6c0$f5a22440$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLwMtmz+XLO8+uQ7j5WaenA2rWXRwHVfCJTAW3ySwACzWyr4AJQYvqoAmia70sCRUpXGQJL52qvAewKHZECaD7TrgHLBOvzApMDTUsCqh6d6wGYO72JAaqfRnSbhwHjQA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, "'Joel M. Halpern'" , 'Andy Bierman' Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 19:14:34 -0000 Pedro:=20 [Catching up with last week's email]. =20 I am aware of T. Griffin's and Sobrinho's work on a metric that can be = applied across the network. I am interested to see how this could be = applied to I2RS protocol. Could you provide off-list with an example of = how this might work.=20 On conflicting stages,=20 Catching conflicting states on a configuration is single node has been = done in many routers for syntax and for context. However, catching = conflicting states across the network is more difficult. Parts of the = configuration may vary from router to router. For example, if you focus = on flow of data packets, You must have a higher level abstraction that = validates the flow of data controlled by routes in routers, interfaces, = and policy.=20 =20 Initial I2RS work examined some of these topics, but we agree this work = was out of scope for the version of the protocol. If you feel there = flaw in our first version of I2RS, please indicate this point. If you = feel this topic should be addressed in a second version, please let me = know.=20 =20 =20 -----Original Message----- From: PEDRO ANDRES ARANDA GUTIERREZ = [mailto:pedroa.aranda@telefonica.com]=20 Sent: Monday, November 23, 2015 2:04 AM To: Russ White; 'Jeffrey Haas' Cc: i2rs@ietf.org; 'Joel M. Halpern'; 'Andy Bierman'; 'Susan Hares' Subject: Re: [i2rs] Conversation on Priority and Panes Hi, Re the metric 'problem', just to be more precise in what would be = needed, we are looking a metric that grows or decreases monotonically = across the whole network. The theoretical grounds for this are in T. = Griffin=E2=80=99s and Sobrinho=E2=80=99s work on BGP-4 and that lies = already a couple of years ago and that makes the analysis much = =E2=80=98easier=E2=80=99 (no worries about np(complete) problems, etc.). = This could be applied in I2RS at the routing protocol level. So, we = could discuss where that sits (should be the clients, right?) and I = don=E2=80=99t know if that=E2=80=99s been already done, since = I=E2=80=99m quite new to this list. Now, having =E2=80=9Csolved=E2=80=9D that part of the equation :-) , the = part that interests me more is the conflicting clients problem, because = this could be generalised to other problem spaces in the SDN area. I do = agree that agents should be able to catch offending state before = installing it and I=E2=80=99m looking for ways to specify a minimal set = of features that need to be supported at protocol level. Anyone else interested? BR, /PA --- Dr. Pedro A. Aranda Guti=C3=A9rrez Technology Exploration - Network Innovation & Virtualisation email: pedroa d0t aranda At telefonica d0t com Telef=C3=B3nica, = Investigaci=C3=B3n y Desarrollo C/ Zurbar=C3=A1n,12 28010 Madrid, Spain Fragen sind nicht da, um beantwortet zu werden. Fragen sind da, um gestellt zu werden. Georg Kreisler -----Mensaje original----- De: Russ White <7riw77@gmail.com> Fecha: viernes, 20 de noviembre de 2015, 14:11 Para: paag , 'Jeffrey Haas' = CC: "i2rs@ietf.org" , "'Joel M. Halpern'" = , 'Andy Bierman' , Sue Hares = Asunto: RE: [i2rs] Conversation on Priority and Panes > >> The danger I see there is that a specific policy applied by one=20 >> client (app) may trigger unintended changes in a part of the "planes=20 >> of glass" it is not aware of. Hence a full copy is needed in each=20 >> client (app) may be needed=E2=80=A6 This also holds for subscribing = to change=20 >> notifications. How can I subscribe to a change notification of = something I=E2=80=99m not or I don=E2=80=99t want to be aware of? > >I don't see how that's going to be any different whether the alternate = states are held in the agent or on the clients -- either way, doing "x" = might trigger some other client to do "y." The only difference is how = long it takes for the first client to see the second client doing "y," = and then reacting to it by doing "z." Even trying to make certain every = client has a full list of all possible conditions there will still be = race conditions in the mix, so that won't solve the problem, either. At = some point, you're going to hit your head against CAP -- it's just a = matter of where, when, and how to manage it. > >The only real solution to this sort of problem is to have a definitive = single "metric" that provides an answer to every situation. Just like = with a routing protocol, you can't build a distributed system that uses = more than one metric without ending up with wedgies (hence BGP). Mike = Shand once told me this is an np(complete) problem -- I'm guessing Mike = is right on this one. It seems, to me, that this is precisely what the = "priority" in this system provides -- in any case, the client with the = best priority wins. As no two clients can have the same priority (it's = tied to the client id, from what I remember), it "just works." > >The one situation you can get in to is when client 1 says "do x," = client 2 says, "do y," and you end up with a routing loop or = contradictory policies applied. This is going to be a problem no matter = where the information is stored. I don't think we can address this at = the protocol level -- all the protocol can do is be as accurate about = current state as it's installed as possible. The agent should be able to = detect some situations like this and refuse to install the offending = state. The clients may be able to detect some of this, as well, and fix = things. But I don't see how we could specify such a thing in the = protocol. Or rather, if we do, when we'd ever be able to stop specifying = such things... > >:-) > >Russ > ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, = puede contener informaci=C3=B3n privilegiada o confidencial y es para = uso exclusivo de la persona o entidad de destino. Si no es usted. el = destinatario indicado, queda notificado de que la lectura, = utilizaci=C3=B3n, divulgaci=C3=B3n y/o copia sin autorizaci=C3=B3n puede = estar prohibida en virtud de la legislaci=C3=B3n vigente. Si ha recibido = este mensaje por error, le rogamos que nos lo comunique inmediatamente = por esta misma v=C3=ADa y proceda a su destrucci=C3=B3n. The information contained in this transmission is privileged and = confidential information intended only for the use of the individual or = entity named above. If the reader of this message is not the intended = recipient, you are hereby notified that any dissemination, distribution = or copying of this communication is strictly prohibited. If you have = received this transmission in error, do not read it. Please immediately = reply to the sender that you have received this communication in error = and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu = destinat=C3=A1rio, pode conter informa=C3=A7=C3=A3o privilegiada ou = confidencial e =C3=A9 para uso exclusivo da pessoa ou entidade de = destino. Se n=C3=A3o =C3=A9 vossa senhoria o destinat=C3=A1rio indicado, = fica notificado de que a leitura, utiliza=C3=A7=C3=A3o, = divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem autoriza=C3=A7=C3=A3o pode = estar proibida em virtude da legisla=C3=A7=C3=A3o vigente. Se recebeu = esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente = por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o From nobody Mon Nov 30 11:23:49 2015 Return-Path: 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 205131B2B58 for ; Mon, 30 Nov 2015 11:23:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 dd9hnTppjaFR for ; Mon, 30 Nov 2015 11:23:42 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FCB81B2B74 for ; Mon, 30 Nov 2015 11:23:42 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.177; From: "Susan Hares" To: "'Joel M. Halpern'" , "'Andy Bierman'" References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> <563A97AA.5020308@joelhalpern.com> <00f301d11761$61699130$243cb390$@gmail.com> <563AA59C.4060809@joelhalpern.com> <018101d11764$66b82e50$34288af0$@gmail.com> <20151119203509.GA22415@pfrc.org> <5B54713B-CDE6-4F65-BE79-91F5B9FF3850@telefonica.com> <008d01d12390$064987c0$12dc9740$@gmail.com> <99B64F3B-20A1-4D3C-A445-46D235EDB44D@telefonica.com> <014a01d12394$ec5ffa60$c51fef20$@gmail.com> <87361DB1-DC6F-4023-A807-4003B436B472@telefonica.com> <012501d125e7$62e457e0$28ad07a0$@gmail.com> <0EAC7123-CECA-4C34-B5E3-E89F0C8DBF94@telefonica.com> <56548418.6060603@joelhalpern.com> <56548CF8.8030900@joelhalpern.com> In-Reply-To: <56548CF8.8030900@joelhalpern.com> Date: Mon, 30 Nov 2015 14:23:32 -0500 Message-ID: <032901d12ba4$9a6a3e60$cf3ebb20$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_032A_01D12B7A.B198CA40" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLwMtmz+XLO8+uQ7j5WaenA2rWXRwHVfCJTAW3ySwACzWyr4AJQYvqoAmia70sCRUpXGQJL52qvAewKHZECaD7TrgHLBOvzApMDTUsCqh6d6wGYO72JAaqfRnQB3roy9wI57+drAP23N4kCTrnGiAGg1cSkmz7fqhA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' , 'PEDRO ANDRES ARANDA GUTIERREZ' , 'Russ White' <7riw77@gmail.com>, i2rs@ietf.org Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 19:23:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_032A_01D12B7A.B198CA40 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Joel and Andy:=20 =20 For the first version of the I2RS protocol, the WG did agree that the = I2RS agent is required to detect and report on collisions. However, = Andy is asking a valid question on how to detect the linkage within = models or between models.=20 =20 Andy's example is one of the group portions of a model (eg. An I2RS RIB = route) or group portions between multiple models (BGP policy + BGP peer = or BGP Policy and BGP local route).=20 =20 I tried to present this concept at IETF 94 to start this discussion.=20 =20 The solutions can be: a) model structure or language in yang to detect = grouping within a model, b) Yang library information to detect modules, = or c) something else.=20 =20 Sue=20 =20 -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Tuesday, November 24, 2015 11:15 AM To: Andy Bierman Cc: Jeffrey Haas; PEDRO ANDRES ARANDA GUTIERREZ; Susan Hares; Russ = White; i2rs@ietf.org Subject: Re: [i2rs] Conversation on Priority and Panes =20 The agent is required to detect and report direct collisions. It is not required or expected to detect indirect collisions, which are = the complex source of wedgies and other interesting behaviors. =20 Yours, Joel =20 PS: The WG discussed requiring a maintained connection between the = client and agent, and agreed not to do that. Which means that no, = agents do not delete state just because clients have disappeared. =20 =20 On 11/24/15 11:01 AM, Andy Bierman wrote: >=20 >=20 > On Tue, Nov 24, 2015 at 7:36 AM, Joel M. Halpern < mailto:jmh@joelhalpern.com>> wrote: >=20 > I believe that determining whether two independent and internally > consistent sets of changes can, in combination, produce a wedgie = or > other failure is a research problem. > As far as I know, the I2RS working group concluded that it was a > sufficiently hard problem that we did not expect the I2RS agent to > get involved in trying to detect, much less remediate, such > cross-object inconsistencies. >=20 >=20 >=20 > But the I2RS agent is responsible for identifying an edit collision=20 > between a new low-priority request and existing higher priority edits. = > That sounds involved to me. So the agent cannot possibly solve this=20 > problem yet it is responsible for precisely that in order to implement = > client priority. >=20 > The agent can see that /foo[42] exists in the request and /foo[42]=20 > exists in the ephemeral datastore, and call that a collision. >=20 > However, if /foo[1] or /bar[19] are also part of the "edit", such that = > simply replacing /foo[42] will break things, then the agent will not=20 > know. It will simply overwrite /foo[42] and leave /foo[1] and /bar[19] = > in the datastore. >=20 > So is the low-priority client responsible for removing /foo[1] and = /bar[19]? > Seems the answer is no. The client can go away and there are no=20 > cleanup requirements mentioned in the architecture. >=20 >=20 >=20 > Yours, > Joel >=20 >=20 >=20 > Andy >=20 >=20 > On 11/24/15 10:32 AM, PEDRO ANDRES ARANDA GUTIERREZ wrote: >=20 > Hi Russ, >=20 > I=E2=80=99m trying to identify the differences between = interactions with > routing protocols in I2RS and what is purely conflicts between > clients. Currently I see too many issues overlapping and I = fear > that the trees are not letting us see the forest. >=20 > So my take on routing protocols and wedgies might have been = too > compact :-) Let me give it a second try: Stepping outside the > I2RS problem space, there is a lot of work that shows that the > origin for BGP-4 instability is that our beloved route-maps > create metrics that are not monotonically increasing or > decreasing and that makes the routing protocols meta-stable. > (BTW, I=E2=80=99m the first culprit when it comes to the use = of them, I > have created more than one wedgie :-P ) Acknowledging that = this > is a significant (and quite complex) problem for the Internet = in > general, I feel that it should be treated somewhere else = (GROW?). >=20 > The perspective I would like to take here is: > - assume that we have two or more clients that produce = perfectly > sound routing information (no wedgies there) > - assume they talk to the same agent > - now my questions > 1.- is there any way to detect whether the clients > produce contradicting/conflicting information? > 2.- is there any way to resolve these > contradictions/conflicts? >=20 > BR, /PA > --- > Dr. Pedro A. Aranda Guti=C3=A9rrez >=20 > Technology Exploration - > Network Innovation & Virtualisation > email: pedroa d0t aranda At telefonica d0t com > Telef=C3=B3nica, Investigaci=C3=B3n y Desarrollo > C/ Zurbar=C3=A1n,12 > 28010 Madrid, Spain >=20 > Fragen sind nicht da, um beantwortet zu werden. > Fragen sind da, um gestellt zu werden. > Georg Kreisler >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -----Mensaje original----- > De: Russ White < = 7riw77@gmail.com = > > Fecha: lunes, 23 de noviembre de 2015, 14:06 > Para: paag < = mailto:pedroa.aranda@telefonica.com>>, 'Jeffrey Haas' > < = jhaas@pfrc.org > > CC: " = i2rs@ietf.org " < mailto:i2rs@ietf.org>>, "'Joel M. = Halpern'" > < = jmh@joelhalpern.com >, 'Andy > Bierman' < = = andy@yumaworks.com >, Sue > Hares < = shares@ndzh.com > > Asunto: RE: [i2rs] Conversation on Priority and Panes >=20 >=20 > Re the metric 'problem', just to be more precise in = what > would be needed, > we are looking a metric that grows or decreases > monotonically across the > whole network. >=20 >=20 > I assume you mean in the routing space, and not in the > controller/client space, correct? In terms of a = distributed > protocol? So, you're saying the delay could use "metrics" > between 11 and 20, while the bandwidth could use "metrics" > between 21 and 30, etc? And then you just add them all > together? That's what IS-IS has done for years... Even BGP > really only has one "metric," with following "tie > breakers..." So if you have something like weight/local > pref/etc, such that they occupy different "spaces" in a = bit > pattern (something suggested, btw, in the original wide > community work, and in other places, as well), you're > actually just building a single metric. >=20 > You've not "solved" the multiple metric problem -- just = done > something a little different than EIGRP's K values to > combine them into a single metric, which is where you need > to be to have the ability to build a single stable = SPT/DAG. >=20 > The theoretical grounds for this are in T. = Griffin=E2=80=99s and > Sobrinho=E2=80=99s work on BGP-4 and that lies already = a couple > of years ago and that > makes the analysis much =E2=80=98easier=E2=80=99 (no = worries about > np(complete) problems, > etc.). This could be applied in I2RS at the routing > protocol level. So, we could > discuss where that sits (should be the clients, = right?) > and I don=E2=80=99t know if > that=E2=80=99s been already done, since I=E2=80=99m = quite new to this list. >=20 >=20 > This doesn=E2=80=99t apply to the problem at hand, = though... You > seem to be saying (clarify if wrong) -- >=20 > 1. Give each client some set of bits out of a 128 bit = number > space (or larger, etc.) > 2. Each client can have different "metrics" within their = own > number space > 3. When a client attempts to add some ephemeral state, = they > use a metric within their "space" > 4. The agent can just use the straight number as a = relative > priority for each potential piece of state >=20 > This doesn't do anything different than the current = concept > of priority between clients, only in the current plan each > client only has one priority, rather than multiples. I = don't > see where this relates to the problem at hand. >=20 > Now, having =E2=80=9Csolved=E2=80=9D that part of the = equation :-) , the > part that interests me > more is the conflicting clients problem, because this > could be generalised to > other problem spaces in the SDN area. I do agree that > agents should be able > to catch offending state before installing it and = I=E2=80=99m > looking for ways to specify > a minimal set of features that need to be supported at > protocol level. >=20 > Anyone else interested? >=20 >=20 > This is precisely where the problem lies. And this is = where > you're going to hit the CAP theorem in full force. There = are > only a few choices -- >=20 > 1. Make the database eventually consistent > 2. Shut down accessibility during changes > 3. ?? >=20 > (1) is the idea of either having the agent call back to = all > the clients when state they installed is overwritten or > allowing the agent to locally store some state where it > already has the information in hand and install it locally > -- the only real difference between these two solutions is > the "balance of complexity versus speed..." The entire > discussion here is how much additional complexity are we > actually adding by doing "panes of glass," which are just > locally stored state which isn't currently installed. I'm > arguing that there's minimal complexity added that you're > not already going to have in the system to allow the agent > to store information locally _if_ it chooses to. Jeff is > arguing (I think) that the "panes of glass" concept is a > coherent way of looking at this problem that will help us > understand and manage the complexity in a way that makes > sense. Joel is arguing (I think) that this sort of = solution > is out of the WG charter, and it's too complex. I _think_ = I > have the th >=20 > r > ee general perspectives right, but I don't know if I really have > so... :-) >=20 >=20 > (2) is the idea of locking the database while you're > changing it. This is explicitly outside the scope of I2RS > entirely, given we're trying to design something that's > atomic/restful. There are a lot of techniques you can use = to > speed up locking -- row locking, sharding, etc. -- but = none > of these are interesting from the I2RS perspective. >=20 > :-) >=20 > Russ >=20 >=20 > ________________________________ >=20 > Este mensaje y sus adjuntos se dirigen exclusivamente a su > destinatario, puede contener informaci=C3=B3n privilegiada o > confidencial y es para uso exclusivo de la persona o entidad = de > destino. Si no es usted. el destinatario indicado, queda > notificado de que la lectura, utilizaci=C3=B3n, = divulgaci=C3=B3n y/o copia > sin autorizaci=C3=B3n puede estar prohibida en virtud de la > legislaci=C3=B3n vigente. Si ha recibido este mensaje por = error, le > rogamos que nos lo comunique inmediatamente por esta misma = v=C3=ADa y > proceda a su destrucci=C3=B3n. >=20 > The information contained in this transmission is privileged = and > confidential information intended only for the use of the > individual or entity named above. If the reader of this = message > is not the intended recipient, you are hereby notified that = any > dissemination, distribution or copying of this communication = is > strictly prohibited. If you have received this transmission in > error, do not read it. Please immediately reply to the sender > that you have received this communication in error and then > delete it. >=20 > Esta mensagem e seus anexos se dirigem exclusivamente ao seu > destinat=C3=A1rio, pode conter informa=C3=A7=C3=A3o = privilegiada ou > confidencial e =C3=A9 para uso exclusivo da pessoa ou entidade = de > destino. Se n=C3=A3o =C3=A9 vossa senhoria o destinat=C3=A1rio = indicado, fica > notificado de que a leitura, utiliza=C3=A7=C3=A3o, = divulga=C3=A7=C3=A3o e/ou c=C3=B3pia > sem autoriza=C3=A7=C3=A3o pode estar proibida em virtude da = legisla=C3=A7=C3=A3o > vigente. Se recebeu esta mensagem por erro, rogamos-lhe que = nos > o comunique imediatamente por esta mesma via e proceda a sua > destrui=C3=A7=C3=A3o >=20 >=20 =20 _______________________________________________ i2rs mailing list i2rs@ietf.org = https://www.ietf.org/mailman/listinfo/i2rs ------=_NextPart_000_032A_01D12B7A.B198CA40 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Joel = and Andy:

 

For the first version of the I2RS protocol, the WG = did agree that the I2RS agent is required to detect and report on = collisions. =C2=A0However, Andy is asking a valid question on how to = detect the linkage within models or between models.

 

Andy's = example is one of the group portions of a model (eg. An I2RS RIB route) = or group portions between multiple models (BGP policy + BGP peer or BGP = Policy and BGP local route).

 

I = tried to present this concept at IETF 94 to start this discussion. =

 

The solutions can be: a) =C2=A0model structure or = language in yang to detect grouping within a model, b) Yang library = information to detect modules, or c) something else.

 

Sue =

 

-----Original Message-----
From: i2rs = [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. Halpern
Sent: = Tuesday, November 24, 2015 11:15 AM
To: Andy Bierman
Cc: Jeffrey = Haas; PEDRO ANDRES ARANDA GUTIERREZ; Susan Hares; Russ White; = i2rs@ietf.org
Subject: Re: [i2rs] Conversation on Priority and = Panes

 

The agent is required to detect and report direct = collisions.

It is not required or = expected to detect indirect collisions, which are the complex source of = wedgies and other interesting behaviors.

 

Yours,

Joel

 

PS: = The WG discussed requiring a maintained connection between the client = and agent, and agreed not to do that.=C2=A0 Which means that no, agents = do not delete state just because clients have = disappeared.

 

 

On = 11/24/15 11:01 AM, Andy Bierman wrote:

> 

> 

> On Tue, Nov 24, 2015 at 7:36 AM, Joel M. = Halpern <jmh@joelhalpern.com

> <mailto:jmh@joelhalpern.co= m>> wrote:

> 

>=C2=A0=C2=A0=C2=A0=C2=A0 I believe that = determining whether two independent and internally

>=C2=A0=C2=A0=C2=A0=C2=A0 consistent sets of = changes can, in combination, produce a wedgie or

>=C2=A0=C2=A0 =C2=A0=C2=A0other failure is a = research problem.

>=C2=A0=C2=A0=C2=A0=C2=A0 As far as I know, the = I2RS working group concluded that it was a

>=C2=A0=C2=A0=C2=A0=C2=A0 sufficiently hard = problem that we did not expect the I2RS agent to

>=C2=A0=C2=A0=C2=A0=C2=A0 get involved in trying = to detect, much less remediate, such

>=C2=A0=C2=A0=C2=A0=C2=A0 cross-object = inconsistencies.

> 

> 

> 

> But the I2RS agent is responsible for = identifying an edit collision

> between a new low-priority request and = existing higher priority edits.

> That sounds involved to me.=C2=A0 So the agent = cannot possibly solve this

> = problem yet it is responsible for precisely that in order to implement =

> client = priority.

> 

> The agent can see that /foo[42] exists in the = request and /foo[42]

> exists = in the ephemeral datastore, and call that a collision.

> 

> However, if /foo[1] or /bar[19] are also part = of the "edit", such that

> simply replacing /foo[42] will break things, = then the agent will not

> = know. It will simply overwrite /foo[42] and leave /foo[1] and /bar[19] =

> in the = datastore.

> 

> So is the low-priority client responsible for = removing /foo[1] and /bar[19]?

> Seems the answer is no. The client can go away = and there are no

> cleanup = requirements mentioned in the architecture.

> 

> 

> 

>=C2=A0=C2=A0=C2=A0=C2=A0 = Yours,

>=C2=A0=C2=A0=C2=A0=C2=A0 Joel

> 

> 

> 

> Andy

> 

> 

>=C2=A0=C2=A0=C2=A0=C2=A0 On 11/24/15 10:32 AM, = PEDRO ANDRES ARANDA GUTIERREZ wrote:

> 

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Hi Russ,

> 

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= I=E2=80=99m trying to identify the differences between interactions = with

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= routing protocols in I2RS and what is purely conflicts = between

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= clients. Currently I see too many issues overlapping and I = fear

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= that the trees are not letting us see the forest.

> 

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= So my take on routing protocols and wedgies might have been = too

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= compact :-) Let me give it a second try: Stepping outside = the

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= I2RS problem space, there is a lot of work that shows that = the

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= origin for BGP-4 instability is that our beloved = route-maps

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= create metrics that are not monotonically increasing = or

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= decreasing and that makes the routing protocols = meta-stable.

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= (BTW, I=E2=80=99m the first culprit when it comes to the use of them, = I

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= have created more than one wedgie :-P ) Acknowledging that = this

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= is a significant (and quite complex) problem for the Internet = in

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = =C2=A0general, I feel that it should be treated somewhere else = (GROW?).

> 

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= The perspective I would like to take here is:

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= - assume that we have two or more clients that produce = perfectly

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= sound routing information (no wedgies there)

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= - assume they talk to the same agent

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= - now my questions

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1.- is = there any way to detect whether the clients

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= produce contradicting/conflicting information?

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2.- is = there any way to resolve these

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= contradictions/conflicts?

> 

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= BR, /PA

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= ---

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Dr. Pedro A. Aranda Guti=C3=A9rrez

> 

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Technology Exploration -

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Network Innovation & Virtualisation

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= email: pedroa d0t aranda At telefonica d0t com

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Telef=C3=B3nica, Investigaci=C3=B3n y Desarrollo

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= C/ Zurbar=C3=A1n,12

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= 28010 Madrid, Spain

> 

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Fragen sind nicht da, um beantwortet zu werden.

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Fragen sind da, um gestellt zu werden.

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Georg Kreisler

> 

> 

> 

> 

> 

> 

> 

> 

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= -----Mensaje original-----

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= De: Russ White <7riw77@gmail.com = <mailto:7riw77@gmail.com>>

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Fecha: lunes, 23 de noviembre de 2015, 14:06

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Para: paag <pedroa.aranda@telefonica.com

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= <mailto:pedroa.aranda@tele= fonica.com>>, 'Jeffrey Haas'

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= <jhaas@pfrc.org = <mailto:jhaas@pfrc.org>>

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= CC: "i2rs@ietf.org = <mailto:i2rs@ietf.org>" = <i2rs@ietf.org

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= <mailto:i2rs@ietf.org>>, "'Joel M. Halpern'"

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= <jmh@joelhalpern.com = <mailto:jmh@joelhalpern.com>>, = 'Andy

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Bierman' <andy@yumaworks.com = <mailto:andy@yumaworks.com>>, Sue

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Hares <shares@ndzh.com = <mailto:shares@ndzh.com>>

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Asunto: RE: [i2rs] Conversation on Priority and Panes

> 

> 

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Re the metric = 'problem', just to be more precise in what

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 would be = needed,

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 we are looking a metric = that grows or decreases

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 monotonically across = the

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 whole = network.

> 

> 

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 I assume you mean in the routing space, and not = in the

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 controller/client space, correct? In terms of a = distributed

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 protocol? So, you're saying the delay could use = "metrics"

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 between 11 and 20, while the bandwidth could = use "metrics"

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 between 21 and 30, etc? And then you just add = them all

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 together? That's what IS-IS has done for = years... Even BGP

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 really only has one "metric," with = following "tie

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 breakers..." So if you have something like = weight/local

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 pref/etc, such that they occupy different = "spaces" in a bit

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 pattern (something suggested, btw, in the = original wide

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 community work, and in other places, as well), = you're

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 actually just building a single = metric.

> 

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 You've not "solved" the multiple = metric problem -- just done

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 something a little different than EIGRP's K = values to

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 combine them into a single metric, which is = where you need

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 to be to have the ability to build a single = stable SPT/DAG.

> 

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The theoretical grounds = for this are in T. Griffin=E2=80=99s and

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Sobrinho=E2=80=99s work = on BGP-4 and that lies already a couple

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0of = years ago and that

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 makes the analysis much = =E2=80=98easier=E2=80=99 (no worries about

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 np(complete) = problems,

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 etc.). This could be = applied in I2RS at the routing

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 protocol level. So, we = could

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 discuss where that sits = (should be the clients, right?)

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and I don=E2=80=99t = know if

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 that=E2=80=99s been = already done, since I=E2=80=99m quite new to this list.

> 

> 

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 This doesn=E2=80=99t apply to the problem at = hand, though... You

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 seem to be saying (clarify if wrong) = --

> 

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 1. Give each client some set of bits out of a = 128 bit number

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 space (or larger, etc.)

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 2. Each client can have different = "metrics" within their own

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 number space

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 3. When a client attempts to add some ephemeral = state, they

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 use a metric within their = "space"

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 4. The agent can just use the straight number = as a relative

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 priority for each potential piece of = state

> 

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 This doesn't do anything different than the = current concept

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 of priority between clients, only in the = current plan each

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 client only has one priority, rather than = multiples. I don't

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 see where this relates to the problem at = hand.

> 

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Now, having = =E2=80=9Csolved=E2=80=9D that part of the equation :-) , = the

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 part that interests = me

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 more is the conflicting = clients problem, because this

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 could be generalised = to

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 other problem spaces in = the SDN area. I do agree that

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 agents should be = able

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 to catch offending = state before installing it and I=E2=80=99m

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 looking for ways to = specify

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 a minimal set of = features that need to be supported at

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 protocol = level.

> 

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Anyone else = interested?

> 

> 

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 This is precisely where the problem lies. And = this is where

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 you're going to hit the CAP theorem in full = force. There are

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 only a few choices --

> 

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 1. Make the database eventually = consistent

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 =C2=A0=C2=A02. Shut down accessibility during = changes

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 3. ??

> 

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 (1) is the idea of either having the agent call = back to all

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 the clients when state they installed is = overwritten or

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 allowing the agent to locally store some state = where it

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 already has the information in hand and install = it locally

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 -- the only real difference between these two = solutions is

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 the "balance of complexity versus = speed..." The entire

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 discussion here is how much additional = complexity are we

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 actually adding by doing "panes of = glass," which are just

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 locally stored state which isn't currently = installed. I'm

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 arguing that there's minimal complexity added = that you're

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 not already going to have in the system to = allow the agent

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 to store information locally _if_ it chooses = to. Jeff is

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 arguing (I think) that the "panes of = glass" concept is a

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 coherent way of looking at this problem that = will help us

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 understand and manage the complexity in a way = that makes

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 sense. Joel is arguing (I think) that this sort = of solution

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 is out of the WG charter, and it's too complex. = I _think_ I

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 have the th

> 

>=C2=A0=C2=A0=C2=A0=C2=A0 r

>=C2=A0=C2=A0=C2=A0=C2=A0 ee general = perspectives right, but I don't know if I really have

>=C2=A0=C2=A0=C2=A0=C2=A0 so... = :-)

> 

> 

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 (2) is the idea of locking the database while = you're

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 changing it. This is explicitly outside the = scope of I2RS

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 entirely, given we're trying to design = something that's

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 atomic/restful. There are a lot of techniques = you can use to

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 speed up locking -- row locking, sharding, etc. = -- but none

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 of these are interesting from the I2RS = perspective.

> 

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 :-)

> 

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Russ

> 

> 

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= ________________________________

> 

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Este mensaje y sus adjuntos se dirigen exclusivamente a = su

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= destinatario, puede contener informaci=C3=B3n privilegiada = o

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= confidencial y es para uso exclusivo de la persona o entidad = de

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= destino. Si no es usted. el destinatario indicado, = queda

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= notificado de que la lectura, utilizaci=C3=B3n, divulgaci=C3=B3n y/o = copia

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= sin autorizaci=C3=B3n puede estar prohibida en virtud de = la

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= legislaci=C3=B3n vigente. Si ha recibido este mensaje por error, = le

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= rogamos que nos lo comunique inmediatamente por esta misma v=C3=ADa = y

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= proceda a su destrucci=C3=B3n.

> 

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= The information contained in this transmission is privileged = and

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= confidential information intended only for the use of = the

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= individual or entity named above. If the reader of this = message

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= is not the intended recipient, you are hereby notified that = any

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= dissemination, distribution or copying of this communication = is

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= strictly prohibited. If you have received this transmission = in

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= error, do not read it. Please immediately reply to the = sender

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= that you have received this communication in error and = then

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= delete it.

> 

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Esta mensagem e seus anexos se dirigem exclusivamente ao = seu

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= destinat=C3=A1rio, pode conter informa=C3=A7=C3=A3o privilegiada = ou

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= confidencial e =C3=A9 para uso exclusivo da pessoa ou entidade = de

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= destino. Se n=C3=A3o =C3=A9 vossa senhoria o destinat=C3=A1rio = indicado, fica

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= notificado de que a leitura, utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o = e/ou c=C3=B3pia

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= sem autoriza=C3=A7=C3=A3o pode estar proibida em virtude da = legisla=C3=A7=C3=A3o

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= vigente. Se recebeu esta mensagem por erro, rogamos-lhe que = nos

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= o comunique imediatamente por esta mesma via e proceda a = sua

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= destrui=C3=A7=C3=A3o

> 

> 

 

_______________________________________________=

i2rs mailing list

i2rs@ietf.org<= o:p>

https://www.ietf.org/mail= man/listinfo/i2rs

------=_NextPart_000_032A_01D12B7A.B198CA40-- From nobody Mon Nov 30 11:30:42 2015 Return-Path: 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 706A31B2E15 for ; Mon, 30 Nov 2015 11:30:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 pN-BC_FMXw8f for ; Mon, 30 Nov 2015 11:30:37 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B4801B2CF4 for ; Mon, 30 Nov 2015 11:30:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 48AFD1C075B; Mon, 30 Nov 2015 11:30:37 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 596AB1C0E2D; Mon, 30 Nov 2015 11:30:36 -0800 (PST) To: Susan Hares , 'Andy Bierman' References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> <563A97AA.5020308@joelhalpern.com> <00f301d11761$61699130$243cb390$@gmail.com> <563AA59C.4060809@joelhalpern.com> <018101d11764$66b82e50$34288af0$@gmail.com> <20151119203509.GA22415@pfrc.org> <5B54713B-CDE6-4F65-BE79-91F5B9FF3850@telefonica.com> <008d01d12390$064987c0$12dc9740$@gmail.com> <99B64F3B-20A1-4D3C-A445-46D235EDB44D@telefonica.com> <014a01d12394$ec5ffa60$c51fef20$@gmail.com> <87361DB1-DC6F-4023-A807-4003B436B472@telefonica.com> <012501d125e7$62e457e0$28ad07a0$@gmail.com> <0EAC7123-CECA-4C34-B5E3-E89F0C8DBF94@telefonica.com> <56548418.6060603@joelhalpern.com> <56548CF8.8030900@joelhalpern.com> <032901d12ba4$9a6a3e60$cf3ebb20$@ndzh.com> From: "Joel M. Halpern" Message-ID: <565CA3DA.808@joelhalpern.com> Date: Mon, 30 Nov 2015 14:30:34 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <032901d12ba4$9a6a3e60$cf3ebb20$@ndzh.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: 'Jeffrey Haas' , 'PEDRO ANDRES ARANDA GUTIERREZ' , 'Russ White' <7riw77@gmail.com>, i2rs@ietf.org Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 19:30:40 -0000 I am not understanding your comment. As I understand it, Andy was asking about indirect collisions or side effects, where modification of item A by entity B (either an over-write or just a modification of something that was in base config) make the modification C that was done by entity D incorrect. We had discussed that, and agreed that as a general matter, such indirect problem detection was not something we want (wanted) to address. There are some cases that are represented by YANG constraints. I don't think our decision on this reflects an opinion on what and which YANG constraints should be enforced by I2RS. The issue is generally about side effects that are not anticipated by model designers. The assumption ew made was that at least the application designer had a hope of anticipating them, and therefore the client could monitor objects when there is a state dependency. (If no one realizes there is a dependence, things will break. I don't see a way around that.) Yours, Joel On 11/30/15 2:23 PM, Susan Hares wrote: > Joel and Andy: > > For the first version of the I2RS protocol, the WG did agree that the > I2RS agent is required to detect and report on collisions. However, > Andy is asking a valid question on how to detect the linkage within > models or between models. > > Andy's example is one of the group portions of a model (eg. An I2RS RIB > route) or group portions between multiple models (BGP policy + BGP peer > or BGP Policy and BGP local route). > > I tried to present this concept at IETF 94 to start this discussion. > > The solutions can be: a) model structure or language in yang to detect > grouping within a model, b) Yang library information to detect modules, > or c) something else. > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Tuesday, November 24, 2015 11:15 AM > To: Andy Bierman > Cc: Jeffrey Haas; PEDRO ANDRES ARANDA GUTIERREZ; Susan Hares; Russ > White; i2rs@ietf.org > Subject: Re: [i2rs] Conversation on Priority and Panes > > The agent is required to detect and report direct collisions. > > It is not required or expected to detect indirect collisions, which are > the complex source of wedgies and other interesting behaviors. > > Yours, > > Joel > > PS: The WG discussed requiring a maintained connection between the > client and agent, and agreed not to do that. Which means that no, > agents do not delete state just because clients have disappeared. > > On 11/24/15 11:01 AM, Andy Bierman wrote: > > > > > > > > > On Tue, Nov 24, 2015 at 7:36 AM, Joel M. Halpern > > > wrote: > > > > > > I believe that determining whether two independent and internally > > > consistent sets of changes can, in combination, produce a wedgie or > > > other failure is a research problem. > > > As far as I know, the I2RS working group concluded that it was a > > > sufficiently hard problem that we did not expect the I2RS agent to > > > get involved in trying to detect, much less remediate, such > > > cross-object inconsistencies. > > > > > > > > > > > > But the I2RS agent is responsible for identifying an edit collision > > > between a new low-priority request and existing higher priority edits. > > > That sounds involved to me. So the agent cannot possibly solve this > > > problem yet it is responsible for precisely that in order to implement > > > client priority. > > > > > > The agent can see that /foo[42] exists in the request and /foo[42] > > > exists in the ephemeral datastore, and call that a collision. > > > > > > However, if /foo[1] or /bar[19] are also part of the "edit", such that > > > simply replacing /foo[42] will break things, then the agent will not > > > know. It will simply overwrite /foo[42] and leave /foo[1] and /bar[19] > > > in the datastore. > > > > > > So is the low-priority client responsible for removing /foo[1] and > /bar[19]? > > > Seems the answer is no. The client can go away and there are no > > > cleanup requirements mentioned in the architecture. > > > > > > > > > > > > Yours, > > > Joel > > > > > > > > > > > > Andy > > > > > > > > > On 11/24/15 10:32 AM, PEDRO ANDRES ARANDA GUTIERREZ wrote: > > > > > > Hi Russ, > > > > > > I’m trying to identify the differences between interactions with > > > routing protocols in I2RS and what is purely conflicts between > > > clients. Currently I see too many issues overlapping and I fear > > > that the trees are not letting us see the forest. > > > > > > So my take on routing protocols and wedgies might have been too > > > compact :-) Let me give it a second try: Stepping outside the > > > I2RS problem space, there is a lot of work that shows that the > > > origin for BGP-4 instability is that our beloved route-maps > > > create metrics that are not monotonically increasing or > > > decreasing and that makes the routing protocols meta-stable. > > > (BTW, I’m the first culprit when it comes to the use of them, I > > > have created more than one wedgie :-P ) Acknowledging that this > > > is a significant (and quite complex) problem for the Internet in > > > general, I feel that it should be treated somewhere else (GROW?). > > > > > > The perspective I would like to take here is: > > > - assume that we have two or more clients that produce perfectly > > > sound routing information (no wedgies there) > > > - assume they talk to the same agent > > > - now my questions > > > 1.- is there any way to detect whether the clients > > > produce contradicting/conflicting information? > > > 2.- is there any way to resolve these > > > contradictions/conflicts? > > > > > > BR, /PA > > > --- > > > Dr. Pedro A. Aranda Gutiérrez > > > > > > Technology Exploration - > > > Network Innovation & Virtualisation > > > email: pedroa d0t aranda At telefonica d0t com > > > Telefónica, Investigación y Desarrollo > > > C/ Zurbarán,12 > > > 28010 Madrid, Spain > > > > > > Fragen sind nicht da, um beantwortet zu werden. > > > Fragen sind da, um gestellt zu werden. > > > Georg Kreisler > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Mensaje original----- > > > De: Russ White <7riw77@gmail.com >> > > > Fecha: lunes, 23 de noviembre de 2015, 14:06 > > > Para: paag > > >, 'Jeffrey Haas' > > > >> > > > CC: "i2rs@ietf.org > " > > >, "'Joel M. Halpern'" > > > >>, 'Andy > > > Bierman' >>, Sue > > > Hares >> > > > Asunto: RE: [i2rs] Conversation on Priority and Panes > > > > > > > > > Re the metric 'problem', just to be more precise in what > > > would be needed, > > > we are looking a metric that grows or decreases > > > monotonically across the > > > whole network. > > > > > > > > > I assume you mean in the routing space, and not in the > > > controller/client space, correct? In terms of a distributed > > > protocol? So, you're saying the delay could use "metrics" > > > between 11 and 20, while the bandwidth could use "metrics" > > > between 21 and 30, etc? And then you just add them all > > > together? That's what IS-IS has done for years... Even BGP > > > really only has one "metric," with following "tie > > > breakers..." So if you have something like weight/local > > > pref/etc, such that they occupy different "spaces" in a bit > > > pattern (something suggested, btw, in the original wide > > > community work, and in other places, as well), you're > > > actually just building a single metric. > > > > > > You've not "solved" the multiple metric problem -- just done > > > something a little different than EIGRP's K values to > > > combine them into a single metric, which is where you need > > > to be to have the ability to build a single stable SPT/DAG. > > > > > > The theoretical grounds for this are in T. Griffin’s and > > > Sobrinho’s work on BGP-4 and that lies already a couple > > > of years ago and that > > > makes the analysis much ‘easier’ (no worries about > > > np(complete) problems, > > > etc.). This could be applied in I2RS at the routing > > > protocol level. So, we could > > > discuss where that sits (should be the clients, right?) > > > and I don’t know if > > > that’s been already done, since I’m quite new to this > list. > > > > > > > > > This doesn’t apply to the problem at hand, though... You > > > seem to be saying (clarify if wrong) -- > > > > > > 1. Give each client some set of bits out of a 128 bit number > > > space (or larger, etc.) > > > 2. Each client can have different "metrics" within their own > > > number space > > > 3. When a client attempts to add some ephemeral state, they > > > use a metric within their "space" > > > 4. The agent can just use the straight number as a relative > > > priority for each potential piece of state > > > > > > This doesn't do anything different than the current concept > > > of priority between clients, only in the current plan each > > > client only has one priority, rather than multiples. I don't > > > see where this relates to the problem at hand. > > > > > > Now, having “solved” that part of the equation :-) , the > > > part that interests me > > > more is the conflicting clients problem, because this > > > could be generalised to > > > other problem spaces in the SDN area. I do agree that > > > agents should be able > > > to catch offending state before installing it and I’m > > > looking for ways to specify > > > a minimal set of features that need to be supported at > > > protocol level. > > > > > > Anyone else interested? > > > > > > > > > This is precisely where the problem lies. And this is where > > > you're going to hit the CAP theorem in full force. There are > > > only a few choices -- > > > > > > 1. Make the database eventually consistent > > > 2. Shut down accessibility during changes > > > 3. ?? > > > > > > (1) is the idea of either having the agent call back to all > > > the clients when state they installed is overwritten or > > > allowing the agent to locally store some state where it > > > already has the information in hand and install it locally > > > -- the only real difference between these two solutions is > > > the "balance of complexity versus speed..." The entire > > > discussion here is how much additional complexity are we > > > actually adding by doing "panes of glass," which are just > > > locally stored state which isn't currently installed. I'm > > > arguing that there's minimal complexity added that you're > > > not already going to have in the system to allow the agent > > > to store information locally _if_ it chooses to. Jeff is > > > arguing (I think) that the "panes of glass" concept is a > > > coherent way of looking at this problem that will help us > > > understand and manage the complexity in a way that makes > > > sense. Joel is arguing (I think) that this sort of solution > > > is out of the WG charter, and it's too complex. I _think_ I > > > have the th > > > > > > r > > > ee general perspectives right, but I don't know if I really have > > > so... :-) > > > > > > > > > (2) is the idea of locking the database while you're > > > changing it. This is explicitly outside the scope of I2RS > > > entirely, given we're trying to design something that's > > > atomic/restful. There are a lot of techniques you can use to > > > speed up locking -- row locking, sharding, etc. -- but none > > > of these are interesting from the I2RS perspective. > > > > > > :-) > > > > > > Russ > > > > > > > > > ________________________________ > > > > > > Este mensaje y sus adjuntos se dirigen exclusivamente a su > > > destinatario, puede contener información privilegiada o > > > confidencial y es para uso exclusivo de la persona o entidad de > > > destino. Si no es usted. el destinatario indicado, queda > > > notificado de que la lectura, utilización, divulgación y/o copia > > > sin autorización puede estar prohibida en virtud de la > > > legislación vigente. Si ha recibido este mensaje por error, le > > > rogamos que nos lo comunique inmediatamente por esta misma vía y > > > proceda a su destrucción. > > > > > > The information contained in this transmission is privileged and > > > confidential information intended only for the use of the > > > individual or entity named above. If the reader of this message > > > is not the intended recipient, you are hereby notified that any > > > dissemination, distribution or copying of this communication is > > > strictly prohibited. If you have received this transmission in > > > error, do not read it. Please immediately reply to the sender > > > that you have received this communication in error and then > > > delete it. > > > > > > Esta mensagem e seus anexos se dirigem exclusivamente ao seu > > > destinatário, pode conter informação privilegiada ou > > > confidencial e é para uso exclusivo da pessoa ou entidade de > > > destino. Se não é vossa senhoria o destinatário indicado, fica > > > notificado de que a leitura, utilização, divulgação e/ou cópia > > > sem autorização pode estar proibida em virtude da legislação > > > vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos > > > o comunique imediatamente por esta mesma via e proceda a sua > > > destruição > > > > > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Mon Nov 30 12:11:03 2015 Return-Path: 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 75E1B1A01AE for ; Mon, 30 Nov 2015 12:11:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.055 X-Spam-Level: X-Spam-Status: No, score=-99.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] 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 DLc7uHcseMxi for ; Mon, 30 Nov 2015 12:10:59 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF6FD1B301F for ; Mon, 30 Nov 2015 12:10:58 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.177; From: "Susan Hares" To: "'Joel M. Halpern'" , "'Andy Bierman'" References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> <563A97AA.5020308@joelhalpern.com> <00f301d11761$61699130$243cb390$@gmail.com> <563AA59C.4060809@joelhalpern.com> <018101d11764$66b82e50$34288af0$@gmail.com> <20151119203509.GA22415@pfrc.org> <5B54713B-CDE6-4F65-BE79-91F5B9FF3850@telefonica.com> <008d01d12390$064987c0$12dc9740$@gmail.com> <99B64F3B-20A1-4D3C-A445-46D235EDB44D@telefonica.com> <014a01d12394$ec5ffa60$c51fef20$@gmail.com> <87361DB1-DC6F-4023-A807-4003B436B472@telefonica.com> <012501d125e7$62e457e0$28ad07a0$@gmail.com> <0EAC7123-CECA-4C34-B5E3-E89F0C8DBF94@telefonica.com> <56548418.6060603@joelhalpern.com> <56548CF8.8030900@joelhalpern.com> <032901d12ba4$9a6a3e60$cf3ebb20$@ndzh.com> <565CA3DA.808@joelhalpern.com> In-Reply-To: <565CA3DA.808@joelhalpern.com> Date: Mon, 30 Nov 2015 15:10:49 -0500 Message-ID: <036501d12bab$3555c330$a0014990$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLwMtmz+XLO8+uQ7j5WaenA2rWXRwHVfCJTAW3ySwACzWyr4AJQYvqoAmia70sCRUpXGQJL52qvAewKHZECaD7TrgHLBOvzApMDTUsCqh6d6wGYO72JAaqfRnQB3roy9wI57+drAP23N4kCTrnGiAGg1cSkAePxGCoCWv095Zsc9Kyg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' , 'PEDRO ANDRES ARANDA GUTIERREZ' , 'Russ White' <7riw77@gmail.com>, i2rs@ietf.org Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 20:11:02 -0000 Joel:=20 The "group" concept comes up in I2RS RIB data and FB-RIB entries which = use combine entries such as route. This may be your dependencies. For = I2RS protocol version 1, we must solve this issue.=20 Route group: prefix, next-hop-id, interface=20 Highest priority wins:=20 If client 1 (priority 4) writes prefix, next-hop-id, and interface=20 If client 2 (priority 5) writes next-hop-id=20 It impacts the route, and may not be valid if the interface does not = lead out to the next-hop.=20 Do we simply notify that next-hop is being over-written, or do we notify = the route is over-written to client 1? The argument is that we need to = notify client 1 that the components of the route has changed and the = next-hop-id is being overwritten. =20 The question is: A) Can we indicate this group in yang? (by a = grouping statement) B) Should our next-hop change notification and route notification be = triggered by this event.=20 This is what I mean by group entries. The application designer will = anticipate it, but the data model can also indicate it.=20 Sue=20 -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Monday, November 30, 2015 2:31 PM To: Susan Hares; 'Andy Bierman' Cc: 'Jeffrey Haas'; 'PEDRO ANDRES ARANDA GUTIERREZ'; 'Russ White'; = i2rs@ietf.org Subject: Re: [i2rs] Conversation on Priority and Panes I am not understanding your comment. As I understand it, Andy was asking about indirect collisions or side = effects, where modification of item A by entity B (either an over-write = or just a modification of something that was in base config) make the = modification C that was done by entity D incorrect. We had discussed = that, and agreed that as a general matter, such indirect problem = detection was not something we want (wanted) to address. There are some cases that are represented by YANG constraints. I don't = think our decision on this reflects an opinion on what and which YANG = constraints should be enforced by I2RS. The issue is generally about = side effects that are not anticipated by model designers. The assumption ew made was that at least the application designer had a = hope of anticipating them, and therefore the client could monitor = objects when there is a state dependency. (If no one realizes there is = a dependence, things will break. I don't see a way around that.) Yours, Joel On 11/30/15 2:23 PM, Susan Hares wrote: > Joel and Andy: > > For the first version of the I2RS protocol, the WG did agree that the=20 > I2RS agent is required to detect and report on collisions. However,=20 > Andy is asking a valid question on how to detect the linkage within=20 > models or between models. > > Andy's example is one of the group portions of a model (eg. An I2RS=20 > RIB > route) or group portions between multiple models (BGP policy + BGP=20 > peer or BGP Policy and BGP local route). > > I tried to present this concept at IETF 94 to start this discussion. > > The solutions can be: a) model structure or language in yang to=20 > detect grouping within a model, b) Yang library information to detect=20 > modules, or c) something else. > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Tuesday, November 24, 2015 11:15 AM > To: Andy Bierman > Cc: Jeffrey Haas; PEDRO ANDRES ARANDA GUTIERREZ; Susan Hares; Russ=20 > White; i2rs@ietf.org > Subject: Re: [i2rs] Conversation on Priority and Panes > > The agent is required to detect and report direct collisions. > > It is not required or expected to detect indirect collisions, which=20 > are the complex source of wedgies and other interesting behaviors. > > Yours, > > Joel > > PS: The WG discussed requiring a maintained connection between the=20 > client and agent, and agreed not to do that. Which means that no,=20 > agents do not delete state just because clients have disappeared. > > On 11/24/15 11:01 AM, Andy Bierman wrote: > > > > > > > > > On Tue, Nov 24, 2015 at 7:36 AM, Joel M. Halpern=20 > > > > wrote: > > > > > > I believe that determining whether two independent and = internally > > > consistent sets of changes can, in combination, produce a = wedgie or > > > other failure is a research problem. > > > As far as I know, the I2RS working group concluded that it was = a > > > sufficiently hard problem that we did not expect the I2RS agent = to > > > get involved in trying to detect, much less remediate, such > > > cross-object inconsistencies. > > > > > > > > > > > > But the I2RS agent is responsible for identifying an edit collision > > > between a new low-priority request and existing higher priority = edits. > > > That sounds involved to me. So the agent cannot possibly solve=20 > this > > > problem yet it is responsible for precisely that in order to=20 > implement > > > client priority. > > > > > > The agent can see that /foo[42] exists in the request and /foo[42] > > > exists in the ephemeral datastore, and call that a collision. > > > > > > However, if /foo[1] or /bar[19] are also part of the "edit", such=20 > that > > > simply replacing /foo[42] will break things, then the agent will=20 > not > > > know. It will simply overwrite /foo[42] and leave /foo[1] and=20 > /bar[19] > > > in the datastore. > > > > > > So is the low-priority client responsible for removing /foo[1] and=20 > /bar[19]? > > > Seems the answer is no. The client can go away and there are no > > > cleanup requirements mentioned in the architecture. > > > > > > > > > > > > Yours, > > > Joel > > > > > > > > > > > > Andy > > > > > > > > > On 11/24/15 10:32 AM, PEDRO ANDRES ARANDA GUTIERREZ wrote: > > > > > > Hi Russ, > > > > > > I=E2=80=99m trying to identify the differences between = interactions with > > > routing protocols in I2RS and what is purely conflicts = between > > > clients. Currently I see too many issues overlapping and I = fear > > > that the trees are not letting us see the forest. > > > > > > So my take on routing protocols and wedgies might have been = too > > > compact :-) Let me give it a second try: Stepping outside = the > > > I2RS problem space, there is a lot of work that shows that = the > > > origin for BGP-4 instability is that our beloved route-maps > > > create metrics that are not monotonically increasing or > > > decreasing and that makes the routing protocols = meta-stable. > > > (BTW, I=E2=80=99m the first culprit when it comes to the = use of them, I > > > have created more than one wedgie :-P ) Acknowledging that = this > > > is a significant (and quite complex) problem for the = Internet in > > > general, I feel that it should be treated somewhere else = (GROW?). > > > > > > The perspective I would like to take here is: > > > - assume that we have two or more clients that produce = perfectly > > > sound routing information (no wedgies there) > > > - assume they talk to the same agent > > > - now my questions > > > 1.- is there any way to detect whether the = clients > > > produce contradicting/conflicting information? > > > 2.- is there any way to resolve these > > > contradictions/conflicts? > > > > > > BR, /PA > > > --- > > > Dr. Pedro A. Aranda Guti=C3=A9rrez > > > > > > Technology Exploration - > > > Network Innovation & Virtualisation > > > email: pedroa d0t aranda At telefonica d0t com > > > Telef=C3=B3nica, Investigaci=C3=B3n y Desarrollo > > > C/ Zurbar=C3=A1n,12 > > > 28010 Madrid, Spain > > > > > > Fragen sind nicht da, um beantwortet zu werden. > > > Fragen sind da, um gestellt zu werden. > > > Georg Kreisler > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Mensaje original----- > > > De: Russ White <7riw77@gmail.com >> > > > Fecha: lunes, 23 de noviembre de 2015, 14:06 > > > Para: paag > > >, 'Jeffrey Haas' > > > >> > > > CC: "i2rs@ietf.org > " > > >, "'Joel M. Halpern'" > > > >>, 'Andy > > > Bierman' >>, Sue > > > Hares >> > > > Asunto: RE: [i2rs] Conversation on Priority and Panes > > > > > > > > > Re the metric 'problem', just to be more precise in = what > > > would be needed, > > > we are looking a metric that grows or decreases > > > monotonically across the > > > whole network. > > > > > > > > > I assume you mean in the routing space, and not in the > > > controller/client space, correct? In terms of a = distributed > > > protocol? So, you're saying the delay could use = "metrics" > > > between 11 and 20, while the bandwidth could use = "metrics" > > > between 21 and 30, etc? And then you just add them all > > > together? That's what IS-IS has done for years... Even = BGP > > > really only has one "metric," with following "tie > > > breakers..." So if you have something like weight/local > > > pref/etc, such that they occupy different "spaces" in a = bit > > > pattern (something suggested, btw, in the original wide > > > community work, and in other places, as well), you're > > > actually just building a single metric. > > > > > > You've not "solved" the multiple metric problem -- just = done > > > something a little different than EIGRP's K values to > > > combine them into a single metric, which is where you = need > > > to be to have the ability to build a single stable = SPT/DAG. > > > > > > The theoretical grounds for this are in T. = Griffin=E2=80=99s and > > > Sobrinho=E2=80=99s work on BGP-4 and that lies = already a couple > > > of years ago and that > > > makes the analysis much =E2=80=98easier=E2=80=99 = (no worries about > > > np(complete) problems, > > > etc.). This could be applied in I2RS at the routing > > > protocol level. So, we could > > > discuss where that sits (should be the clients, = right?) > > > and I don=E2=80=99t know if > > > that=E2=80=99s been already done, since I=E2=80=99m = quite new to this > list. > > > > > > > > > This doesn=E2=80=99t apply to the problem at hand, = though... You > > > seem to be saying (clarify if wrong) -- > > > > > > 1. Give each client some set of bits out of a 128 bit = number > > > space (or larger, etc.) > > > 2. Each client can have different "metrics" within = their own > > > number space > > > 3. When a client attempts to add some ephemeral state, = they > > > use a metric within their "space" > > > 4. The agent can just use the straight number as a = relative > > > priority for each potential piece of state > > > > > > This doesn't do anything different than the current = concept > > > of priority between clients, only in the current plan = each > > > client only has one priority, rather than multiples. I = don't > > > see where this relates to the problem at hand. > > > > > > Now, having =E2=80=9Csolved=E2=80=9D that part of = the equation :-) , the > > > part that interests me > > > more is the conflicting clients problem, because = this > > > could be generalised to > > > other problem spaces in the SDN area. I do agree = that > > > agents should be able > > > to catch offending state before installing it and = I=E2=80=99m > > > looking for ways to specify > > > a minimal set of features that need to be supported = at > > > protocol level. > > > > > > Anyone else interested? > > > > > > > > > This is precisely where the problem lies. And this is = where > > > you're going to hit the CAP theorem in full force. = There are > > > only a few choices -- > > > > > > 1. Make the database eventually consistent > > > 2. Shut down accessibility during changes > > > 3. ?? > > > > > > (1) is the idea of either having the agent call back to = all > > > the clients when state they installed is overwritten or > > > allowing the agent to locally store some state where it > > > already has the information in hand and install it = locally > > > -- the only real difference between these two solutions = is > > > the "balance of complexity versus speed..." The entire > > > discussion here is how much additional complexity are = we > > > actually adding by doing "panes of glass," which are = just > > > locally stored state which isn't currently installed. = I'm > > > arguing that there's minimal complexity added that = you're > > > not already going to have in the system to allow the = agent > > > to store information locally _if_ it chooses to. Jeff = is > > > arguing (I think) that the "panes of glass" concept is = a > > > coherent way of looking at this problem that will help = us > > > understand and manage the complexity in a way that = makes > > > sense. Joel is arguing (I think) that this sort of = solution > > > is out of the WG charter, and it's too complex. I = _think_ I > > > have the th > > > > > > r > > > ee general perspectives right, but I don't know if I really = have > > > so... :-) > > > > > > > > > (2) is the idea of locking the database while you're > > > changing it. This is explicitly outside the scope of = I2RS > > > entirely, given we're trying to design something that's > > > atomic/restful. There are a lot of techniques you can = use to > > > speed up locking -- row locking, sharding, etc. -- but = none > > > of these are interesting from the I2RS perspective. > > > > > > :-) > > > > > > Russ > > > > > > > > > ________________________________ > > > > > > Este mensaje y sus adjuntos se dirigen exclusivamente a su > > > destinatario, puede contener informaci=C3=B3n privilegiada = o > > > confidencial y es para uso exclusivo de la persona o = entidad de > > > destino. Si no es usted. el destinatario indicado, queda > > > notificado de que la lectura, utilizaci=C3=B3n, = divulgaci=C3=B3n y/o copia > > > sin autorizaci=C3=B3n puede estar prohibida en virtud de la > > > legislaci=C3=B3n vigente. Si ha recibido este mensaje por = error, le > > > rogamos que nos lo comunique inmediatamente por esta misma = v=C3=ADa y > > > proceda a su destrucci=C3=B3n. > > > > > > The information contained in this transmission is = privileged and > > > confidential information intended only for the use of the > > > individual or entity named above. If the reader of this = message > > > is not the intended recipient, you are hereby notified that = any > > > dissemination, distribution or copying of this = communication is > > > strictly prohibited. If you have received this transmission = in > > > error, do not read it. Please immediately reply to the = sender > > > that you have received this communication in error and then > > > delete it. > > > > > > Esta mensagem e seus anexos se dirigem exclusivamente ao = seu > > > destinat=C3=A1rio, pode conter informa=C3=A7=C3=A3o = privilegiada ou > > > confidencial e =C3=A9 para uso exclusivo da pessoa ou = entidade de > > > destino. Se n=C3=A3o =C3=A9 vossa senhoria o = destinat=C3=A1rio indicado, fica > > > notificado de que a leitura, utiliza=C3=A7=C3=A3o, = divulga=C3=A7=C3=A3o e/ou c=C3=B3pia > > > sem autoriza=C3=A7=C3=A3o pode estar proibida em virtude da = legisla=C3=A7=C3=A3o > > > vigente. Se recebeu esta mensagem por erro, rogamos-lhe que = nos > > > o comunique imediatamente por esta mesma via e proceda a = sua > > > destrui=C3=A7=C3=A3o > > > > > > > > _______________________________________________ > > 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 From nobody Mon Nov 30 12:16:34 2015 Return-Path: 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 A81791B3070 for ; Mon, 30 Nov 2015 12:16:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.455 X-Spam-Level: X-Spam-Status: No, score=-98.455 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, J_CHICKENPOX_31=0.6, USER_IN_WHITELIST=-100] 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 8Yc0fRxlafCs for ; Mon, 30 Nov 2015 12:16:30 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6CBB1B306C for ; Mon, 30 Nov 2015 12:16:29 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.177; From: "Susan Hares" To: "'Joel M. Halpern'" , "'Andy Bierman'" References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> <563A97AA.5020308@joelhalpern.com> <00f301d11761$61699130$243cb390$@gmail.com> <563AA59C.4060809@joelhalpern.com> <018101d11764$66b82e50$34288af0$@gmail.com> <20151119203509.GA22415@pfrc.org> <5B54713B-CDE6-4F65-BE79-91F5B9FF3850@telefonica.com> <008d01d12390$064987c0$12dc9740$@gmail.com> <99B64F3B-20A1-4D3C-A445-46D235EDB44D@telefonica.com> <014a01d12394$ec5ffa60$c51fef20$@gmail.com> <87361DB1-DC6F-4023-A807-4003B436B472@telefonica.com> <012501d125e7$62e457e0$28ad07a0$@gmail.com> <0EAC7123-CECA-4C34-B5E3-E89F0C8DBF94@telefonica.com> <56548418.6060603@joelhalpern.com> <56548CF8.8030900@joelhalpern.com> <56549 60C.7040203@jo elhalpern.com> In-Reply-To: <5654960C.7040203@joelhalpern.com> Date: Mon, 30 Nov 2015 15:16:22 -0500 Message-ID: <036701d12bab$fb5ea1a0$f21be4e0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLwMtmz+XLO8+uQ7j5WaenA2rWXRwHVfCJTAW3ySwACzWyr4AJQYvqoAmia70sCRUpXGQJL52qvAewKHZECaD7TrgHLBOvzApMDTUsCqh6d6wGYO72JAaqfRnQB3roy9wI57+drAP23N4kCTrnGiAGg1cSkAnDz6+cCFejKKZsauCjA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' , 'PEDRO ANDRES ARANDA GUTIERREZ' , 'Russ White' <7riw77@gmail.com>, i2rs@ietf.org Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 20:16:33 -0000 Joel:=20 =20 In reference to this example, I was focused on the few examples (routes, = filter-based entries, and topology entries) of groups of entries that = must be combined. To have things workable, we must track the priority = overwrite with thing such as route notification or next-hop = notification. =20 My earlier answer was not about the orthogonal entries that are not = grouped).=20 Sue=20 -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Tuesday, November 24, 2015 11:54 AM To: Andy Bierman Cc: Jeffrey Haas; PEDRO ANDRES ARANDA GUTIERREZ; Susan Hares; Russ = White; i2rs@ietf.org Subject: Re: [i2rs] Conversation on Priority and Panes That is indeed a good question. As I understand the WG agreement, some validations of changes are to be = performed, but as little as possible. So an agent can reject a change = for validation, but we hoped to keep it as simple as possible. I am not sure that hop[e is achievable. One of the assumptions in making any ephemeral change is that if some = other changes can affect what a client has done, it is the clients = responsibility to subscribe to notifications about those other changes, = and to undertake remedial actions if a problem is introduced. So if = /foo[19] and /bar[1] interact with /baz[7] (or /foo[42]) then it is the = clients job to monitor /baz[7] (or /foo[42]). The agent can't sort that = out. As an example of an ugly case, suppose that /baz[7] has a value created = by some other I2RS client. The changes to /foo[19] and /bar[1] might = depend upon that value. When the other client removes its changes, the = value reverts to the config value. That reversion clearly must take = place. That can potential create problems for /foo[19] and /bar[1]. It = seems to me that we have to leave it to the client to sort that out. Yours, Joel On 11/24/15 11:28 AM, Andy Bierman wrote: > > > On Tue, Nov 24, 2015 at 8:14 AM, Joel M. Halpern > wrote: > > The agent is required to detect and report direct collisions. > It is not required or expected to detect indirect collisions, = which > are the complex source of wedgies and other interesting behaviors. > > > OK, punting the problem is fair enough. > > What happens when the YANG validation for /foo[19] and /bar[1] now=20 > fails because /foo[42] was changed? Does the agent reject the edit=20 > from the higher priority client? Does I2RS ignore YANG validation,=20 > assuming the YANG authors really didn't mean what they wrote? > > > Yours, > Joel > > > > Andy > > PS: The WG discussed requiring a maintained connection between the > client and agent, and agreed not to do that. Which means that no, > agents do not delete state just because clients have disappeared. > > > On 11/24/15 11:01 AM, Andy Bierman wrote: > > > > On Tue, Nov 24, 2015 at 7:36 AM, Joel M. Halpern > > >> = wrote: > > I believe that determining whether two independent and > internally > consistent sets of changes can, in combination, produce a > wedgie or > other failure is a research problem. > As far as I know, the I2RS working group concluded that = it > was a > sufficiently hard problem that we did not expect the I2RS > agent to > get involved in trying to detect, much less remediate, = such > cross-object inconsistencies. > > > > But the I2RS agent is responsible for identifying an edit > collision between > a new low-priority request and existing higher priority edits. > That sounds > involved to me. So the agent cannot possibly solve this = problem > yet it is responsible for precisely that in order to implement > client > priority. > > The agent can see that /foo[42] exists in the request and > /foo[42] exists > in the ephemeral datastore, and call that a collision. > > However, if /foo[1] or /bar[19] are also part of the "edit", > such that > simply replacing > /foo[42] will break things, then the agent will not know. It > will simply > overwrite > /foo[42] and leave /foo[1] and /bar[19] in the datastore. > > So is the low-priority client responsible for removing /foo[1] > and /bar[19]? > Seems the answer is no. The client can go away and there are = no > cleanup > requirements mentioned in the architecture. > > > > Yours, > Joel > > > > Andy > > > On 11/24/15 10:32 AM, PEDRO ANDRES ARANDA GUTIERREZ = wrote: > > Hi Russ, > > I=E2=80=99m trying to identify the differences = between > interactions with > routing protocols in I2RS and what is purely = conflicts > between > clients. Currently I see too many issues overlapping > and I fear > that the trees are not letting us see the forest. > > So my take on routing protocols and wedgies might = have > been too > compact :-) Let me give it a second try: Stepping > outside the > I2RS problem space, there is a lot of work that shows > that the > origin for BGP-4 instability is that our beloved = route-maps > create metrics that are not monotonically increasing = or > decreasing and that makes the routing protocols > meta-stable. > (BTW, I=E2=80=99m the first culprit when it comes to = the use of > them, I > have created more than one wedgie :-P ) Acknowledging > that this > is a significant (and quite complex) problem for the > Internet in > general, I feel that it should be treated somewhere > else (GROW?). > > The perspective I would like to take here is: > - assume that we have two or more clients that = produce > perfectly > sound routing information (no wedgies there) > - assume they talk to the same agent > - now my questions > 1.- is there any way to detect whether the > clients > produce contradicting/conflicting information? > 2.- is there any way to resolve these > contradictions/conflicts? > > BR, /PA > --- > Dr. Pedro A. Aranda Guti=C3=A9rrez > > Technology Exploration - > Network Innovation & Virtualisation > email: pedroa d0t aranda At telefonica d0t com > Telef=C3=B3nica, Investigaci=C3=B3n y Desarrollo > C/ Zurbar=C3=A1n,12 > 28010 Madrid, Spain > > Fragen sind nicht da, um beantwortet zu werden. > Fragen sind da, um gestellt zu werden. > Georg Kreisler > > > > > > > > > -----Mensaje original----- > De: Russ White <7riw77@gmail.com > >> > Fecha: lunes, 23 de noviembre de 2015, 14:06 > Para: paag > >>, 'Jeffrey Haas' > > >> > CC: "i2rs@ietf.org > >" > >>, = "'Joel > M. Halpern'" > > >>, = 'Andy > Bierman' >>, Sue > Hares > >> > Asunto: RE: [i2rs] Conversation on Priority and Panes > > > Re the metric 'problem', just to be more > precise in what > would be needed, > we are looking a metric that grows or = decreases > monotonically across the > whole network. > > > I assume you mean in the routing space, and not = in the > controller/client space, correct? In terms of a > distributed > protocol? So, you're saying the delay could use > "metrics" > between 11 and 20, while the bandwidth could use > "metrics" > between 21 and 30, etc? And then you just add = them all > together? That's what IS-IS has done for years... > Even BGP > really only has one "metric," with following "tie > breakers..." So if you have something like = weight/local > pref/etc, such that they occupy different = "spaces" > in a bit > pattern (something suggested, btw, in the = original wide > community work, and in other places, as well), = you're > actually just building a single metric. > > You've not "solved" the multiple metric problem = -- > just done > something a little different than EIGRP's K = values to > combine them into a single metric, which is where > you need > to be to have the ability to build a single = stable > SPT/DAG. > > The theoretical grounds for this are in T. > Griffin=E2=80=99s and > Sobrinho=E2=80=99s work on BGP-4 and that = lies already > a couple > of years ago and that > makes the analysis much = =E2=80=98easier=E2=80=99 (no worries about > np(complete) problems, > etc.). This could be applied in I2RS at the = routing > protocol level. So, we could > discuss where that sits (should be the = clients, > right?) > and I don=E2=80=99t know if > that=E2=80=99s been already done, since = I=E2=80=99m quite new > to this list. > > > This doesn=E2=80=99t apply to the problem at = hand, > though... You > seem to be saying (clarify if wrong) -- > > 1. Give each client some set of bits out of a 128 > bit number > space (or larger, etc.) > 2. Each client can have different "metrics" = within > their own > number space > 3. When a client attempts to add some ephemeral > state, they > use a metric within their "space" > 4. The agent can just use the straight number as = a > relative > priority for each potential piece of state > > This doesn't do anything different than the = current > concept > of priority between clients, only in the current > plan each > client only has one priority, rather than > multiples. I don't > see where this relates to the problem at hand. > > Now, having =E2=80=9Csolved=E2=80=9D that = part of the equation > :-) , the > part that interests me > more is the conflicting clients problem, > because this > could be generalised to > other problem spaces in the SDN area. I do > agree that > agents should be able > to catch offending state before installing it > and I=E2=80=99m > looking for ways to specify > a minimal set of features that need to be > supported at > protocol level. > > Anyone else interested? > > > This is precisely where the problem lies. And = this > is where > you're going to hit the CAP theorem in full = force. > There are > only a few choices -- > > 1. Make the database eventually consistent > 2. Shut down accessibility during changes > 3. ?? > > (1) is the idea of either having the agent call > back to all > the clients when state they installed is = overwritten or > allowing the agent to locally store some state = where it > already has the information in hand and install = it > locally > -- the only real difference between these two > solutions is > the "balance of complexity versus speed..." The = entire > discussion here is how much additional complexity > are we > actually adding by doing "panes of glass," which > are just > locally stored state which isn't currently > installed. I'm > arguing that there's minimal complexity added = that > you're > not already going to have in the system to allow > the agent > to store information locally _if_ it chooses to. > Jeff is > arguing (I think) that the "panes of glass" = concept > is a > coherent way of looking at this problem that will > help us > understand and manage the complexity in a way = that > makes > sense. Joel is arguing (I think) that this sort = of > solution > is out of the WG charter, and it's too complex. I > _think_ I > have the th > > r > ee general perspectives right, but I don't know if I = really > have > so... :-) > > > (2) is the idea of locking the database while = you're > changing it. This is explicitly outside the scope > of I2RS > entirely, given we're trying to design something = that's > atomic/restful. There are a lot of techniques you > can use to > speed up locking -- row locking, sharding, etc. = -- > but none > of these are interesting from the I2RS = perspective. > > :-) > > Russ > > > ________________________________ > > Este mensaje y sus adjuntos se dirigen exclusivamente = a su > destinatario, puede contener informaci=C3=B3n = privilegiada o > confidencial y es para uso exclusivo de la persona o > entidad de > destino. Si no es usted. el destinatario indicado, = queda > notificado de que la lectura, utilizaci=C3=B3n, = divulgaci=C3=B3n > y/o copia > sin autorizaci=C3=B3n puede estar prohibida en virtud = de la > legislaci=C3=B3n vigente. Si ha recibido este mensaje = por > error, le > rogamos que nos lo comunique inmediatamente por esta > misma v=C3=ADa y > proceda a su destrucci=C3=B3n. > > The information contained in this transmission is > privileged and > confidential information intended only for the use of = the > individual or entity named above. If the reader of = this > message > is not the intended recipient, you are hereby = notified > that any > dissemination, distribution or copying of this > communication is > strictly prohibited. If you have received this > transmission in > error, do not read it. Please immediately reply to = the > sender > that you have received this communication in error = and then > delete it. > > Esta mensagem e seus anexos se dirigem exclusivamente > ao seu > destinat=C3=A1rio, pode conter informa=C3=A7=C3=A3o = privilegiada ou > confidencial e =C3=A9 para uso exclusivo da pessoa ou > entidade de > destino. Se n=C3=A3o =C3=A9 vossa senhoria o = destinat=C3=A1rio > indicado, fica > notificado de que a leitura, utiliza=C3=A7=C3=A3o, = divulga=C3=A7=C3=A3o > e/ou c=C3=B3pia > sem autoriza=C3=A7=C3=A3o pode estar proibida em = virtude da > legisla=C3=A7=C3=A3o > vigente. Se recebeu esta mensagem por erro, = rogamos-lhe > que nos > o comunique imediatamente por esta mesma via e = proceda > a sua > destrui=C3=A7=C3=A3o > > > _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Mon Nov 30 12:20:46 2015 Return-Path: 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 673041B306D for ; Mon, 30 Nov 2015 12:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_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 HQllyv0ZwR9F for ; Mon, 30 Nov 2015 12:20:40 -0800 (PST) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (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 670CB1B305C for ; Mon, 30 Nov 2015 12:20:39 -0800 (PST) Received: by lfaz4 with SMTP id z4so212961254lfa.0 for ; Mon, 30 Nov 2015 12:20:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mAOxoKejZZjXCQwtSBS86wxtNm9Cjnu2I+54HU/qirY=; b=k5mAm6N+FUK+5pkxhkV1UG9Cq7oufLXU5kFdzZo2KALNP7DxA+om61oo5I9IsG75Fh euEcBJYUA1McL8vPUpbC+U6IjXusXChsr6SjocqSKYAzPZNUXQbFjzrV1lqhbLoKWPtF zp1yM6pwIW7nB6usT5OX4FykbJ6gjS/RGJrClMvMnPRiacRClWFM9hszLfH0BE51V/qT qC3l1JNvqLOdwrAIKUvO7i5krojTvPyfKHskFgC+DeVK8nzD4rp/XW6EW7rtJ+IOUvun wFOWW8vFY1XRcNfLqBRIrwQhy5tJWBjScvFYPGOZtuir2bdwVHSwoum/UIE5yi4YmCtA qwkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mAOxoKejZZjXCQwtSBS86wxtNm9Cjnu2I+54HU/qirY=; b=d6HXWkMIwrc1jdeO1myoWcjnkpcer/d3oDRTLZ9yLPPDXETJ+ulYw+jO4i/DAnW3P/ f03ZO1hF412otZfzNzCpzuLp+T5eYFuNhkTnPOQjRbQrE/ERM8P9Wl+nTp8JDmnX1ch3 Rt1GGhn55FA5HWWpAKxxYCISaCiKnVw8Zp2cqHyUzxAla1xoryHQ+pLpRBLigEtxeoJA F/u613EXHRxLj4krlTmcFuwYwrEBMsek254lqaYUMgpfTvEAV8OMM/enWODWKqtoSw79 ZL0DkbCq1VIFoqlwSqiUQ8lAYT0g23qAYi/37DLjfXTE6SfPXazoPsmpC9Aw3E8Id2oT QFig== X-Gm-Message-State: ALoCoQljk8Tj58SvBSjMLqjVQHvZIhbqSFRQJsRDegvl+N/vvL7u3WsNgSrNldieHqgcyt9Hp4dv MIME-Version: 1.0 X-Received: by 10.25.88.67 with SMTP id m64mr27491904lfb.23.1448914837354; Mon, 30 Nov 2015 12:20:37 -0800 (PST) Received: by 10.112.144.36 with HTTP; Mon, 30 Nov 2015 12:20:37 -0800 (PST) In-Reply-To: <565CA3DA.808@joelhalpern.com> References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> <563A97AA.5020308@joelhalpern.com> <00f301d11761$61699130$243cb390$@gmail.com> <563AA59C.4060809@joelhalpern.com> <018101d11764$66b82e50$34288af0$@gmail.com> <20151119203509.GA22415@pfrc.org> <5B54713B-CDE6-4F65-BE79-91F5B9FF3850@telefonica.com> <008d01d12390$064987c0$12dc9740$@gmail.com> <99B64F3B-20A1-4D3C-A445-46D235EDB44D@telefonica.com> <014a01d12394$ec5ffa60$c51fef20$@gmail.com> <87361DB1-DC6F-4023-A807-4003B436B472@telefonica.com> <012501d125e7$62e457e0$28ad07a0$@gmail.com> <0EAC7123-CECA-4C34-B5E3-E89F0C8DBF94@telefonica.com> <56548418.6060603@joelhalpern.com> <56548CF8.8030900@joelhalpern.com> <032901d12ba4$9a6a3e60$cf3ebb20$@ndzh.com> <565CA3DA.808@joelhalpern.com> Date: Mon, 30 Nov 2015 12:20:37 -0800 Message-ID: From: Andy Bierman To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=001a1141a07c30d5510525c7c626 Archived-At: Cc: Jeffrey Haas , PEDRO ANDRES ARANDA GUTIERREZ , Russ White <7riw77@gmail.com>, Susan Hares , "i2rs@ietf.org" Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 20:20:45 -0000 --001a1141a07c30d5510525c7c626 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I think it is fairly clear that the server will only be able to detect a direct overlap. In any case, the client that is getting data removed needs to use pub/sub to be told what is going on. The I2RS agent will not set up any pub/sub for any client. The client must do this itself via pub/sub configuration. The agent will just return an error if the edit is not accepted. The current YANG design is clear: No client is allowed to cause an edit that will leave the datastore invalid wrt/ YANG validation. That means that a high priority client WILL LOSE if it attempts to overwrite partial data in a way that breaks validation. (This is not what the I2RS arch says to do). A "solution" might be to ignore all YANG validation in the ephemeral datastore. Full YANG validation will be slow and even more complicated than plain NETCONF. No validation will be a huge security hole. Andy On Mon, Nov 30, 2015 at 11:30 AM, Joel M. Halpern wrote: > I am not understanding your comment. > As I understand it, Andy was asking about indirect collisions or side > effects, where modification of item A by entity B (either an over-write o= r > just a modification of something that was in base config) make the > modification C that was done by entity D incorrect. We had discussed tha= t, > and agreed that as a general matter, such indirect problem detection was > not something we want (wanted) to address. > There are some cases that are represented by YANG constraints. I don't > think our decision on this reflects an opinion on what and which YANG > constraints should be enforced by I2RS. The issue is generally about sid= e > effects that are not anticipated by model designers. > > The assumption ew made was that at least the application designer had a > hope of anticipating them, and therefore the client could monitor objects > when there is a state dependency. (If no one realizes there is a > dependence, things will break. I don't see a way around that.) > > Yours, > Joel > > On 11/30/15 2:23 PM, Susan Hares wrote: > >> Joel and Andy: >> >> For the first version of the I2RS protocol, the WG did agree that the >> I2RS agent is required to detect and report on collisions. However, >> Andy is asking a valid question on how to detect the linkage within >> models or between models. >> >> Andy's example is one of the group portions of a model (eg. An I2RS RIB >> route) or group portions between multiple models (BGP policy + BGP peer >> or BGP Policy and BGP local route). >> >> I tried to present this concept at IETF 94 to start this discussion. >> >> The solutions can be: a) model structure or language in yang to detect >> grouping within a model, b) Yang library information to detect modules, >> or c) something else. >> >> Sue >> >> -----Original Message----- >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. Halpern >> Sent: Tuesday, November 24, 2015 11:15 AM >> To: Andy Bierman >> Cc: Jeffrey Haas; PEDRO ANDRES ARANDA GUTIERREZ; Susan Hares; Russ >> White; i2rs@ietf.org >> Subject: Re: [i2rs] Conversation on Priority and Panes >> >> The agent is required to detect and report direct collisions. >> >> It is not required or expected to detect indirect collisions, which are >> the complex source of wedgies and other interesting behaviors. >> >> Yours, >> >> Joel >> >> PS: The WG discussed requiring a maintained connection between the >> client and agent, and agreed not to do that. Which means that no, >> agents do not delete state just because clients have disappeared. >> >> On 11/24/15 11:01 AM, Andy Bierman wrote: >> >> > >> >> > >> >> > On Tue, Nov 24, 2015 at 7:36 AM, Joel M. Halpern > >> > > wrote: >> >> > >> >> > I believe that determining whether two independent and internally >> >> > consistent sets of changes can, in combination, produce a wedgie = or >> >> > other failure is a research problem. >> >> > As far as I know, the I2RS working group concluded that it was a >> >> > sufficiently hard problem that we did not expect the I2RS agent t= o >> >> > get involved in trying to detect, much less remediate, such >> >> > cross-object inconsistencies. >> >> > >> >> > >> >> > >> >> > But the I2RS agent is responsible for identifying an edit collision >> >> > between a new low-priority request and existing higher priority edits= . >> >> > That sounds involved to me. So the agent cannot possibly solve this >> >> > problem yet it is responsible for precisely that in order to implemen= t >> >> > client priority. >> >> > >> >> > The agent can see that /foo[42] exists in the request and /foo[42] >> >> > exists in the ephemeral datastore, and call that a collision. >> >> > >> >> > However, if /foo[1] or /bar[19] are also part of the "edit", such tha= t >> >> > simply replacing /foo[42] will break things, then the agent will not >> >> > know. It will simply overwrite /foo[42] and leave /foo[1] and /bar[19= ] >> >> > in the datastore. >> >> > >> >> > So is the low-priority client responsible for removing /foo[1] and >> /bar[19]? >> >> > Seems the answer is no. The client can go away and there are no >> >> > cleanup requirements mentioned in the architecture. >> >> > >> >> > >> >> > >> >> > Yours, >> >> > Joel >> >> > >> >> > >> >> > >> >> > Andy >> >> > >> >> > >> >> > On 11/24/15 10:32 AM, PEDRO ANDRES ARANDA GUTIERREZ wrote: >> >> > >> >> > Hi Russ, >> >> > >> >> > I=E2=80=99m trying to identify the differences between intera= ctions >> with >> >> > routing protocols in I2RS and what is purely conflicts betwee= n >> >> > clients. Currently I see too many issues overlapping and I fe= ar >> >> > that the trees are not letting us see the forest. >> >> > >> >> > So my take on routing protocols and wedgies might have been t= oo >> >> > compact :-) Let me give it a second try: Stepping outside the >> >> > I2RS problem space, there is a lot of work that shows that th= e >> >> > origin for BGP-4 instability is that our beloved route-maps >> >> > create metrics that are not monotonically increasing or >> >> > decreasing and that makes the routing protocols meta-stable. >> >> > (BTW, I=E2=80=99m the first culprit when it comes to the use = of them, I >> >> > have created more than one wedgie :-P ) Acknowledging that th= is >> >> > is a significant (and quite complex) problem for the Internet >> in >> >> > general, I feel that it should be treated somewhere else >> (GROW?). >> >> > >> >> > The perspective I would like to take here is: >> >> > - assume that we have two or more clients that produce >> perfectly >> >> > sound routing information (no wedgies there) >> >> > - assume they talk to the same agent >> >> > - now my questions >> >> > 1.- is there any way to detect whether the clients >> >> > produce contradicting/conflicting information? >> >> > 2.- is there any way to resolve these >> >> > contradictions/conflicts? >> >> > >> >> > BR, /PA >> >> > --- >> >> > Dr. Pedro A. Aranda Guti=C3=A9rrez >> >> > >> >> > Technology Exploration - >> >> > Network Innovation & Virtualisation >> >> > email: pedroa d0t aranda At telefonica d0t com >> >> > Telef=C3=B3nica, Investigaci=C3=B3n y Desarrollo >> >> > C/ Zurbar=C3=A1n,12 >> >> > 28010 Madrid, Spain >> >> > >> >> > Fragen sind nicht da, um beantwortet zu werden. >> >> > Fragen sind da, um gestellt zu werden. >> >> > Georg Kreisler >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > -----Mensaje original----- >> >> > De: Russ White <7riw77@gmail.com > >> >> >> > Fecha: lunes, 23 de noviembre de 2015, 14:06 >> >> > Para: paag > >> > >, 'Jeffrey Haas' >> >> > > >> >> >> > CC: "i2rs@ietf.org >> " > >> > >, "'Joel M. Halpern'" >> >> > > >>, 'Andy >> >> > Bierman' > >>, Sue >> >> > Hares > >> >> >> > Asunto: RE: [i2rs] Conversation on Priority and Panes >> >> > >> >> > >> >> > Re the metric 'problem', just to be more precise in >> what >> >> > would be needed, >> >> > we are looking a metric that grows or decreases >> >> > monotonically across the >> >> > whole network. >> >> > >> >> > >> >> > I assume you mean in the routing space, and not in the >> >> > controller/client space, correct? In terms of a distribut= ed >> >> > protocol? So, you're saying the delay could use "metrics" >> >> > between 11 and 20, while the bandwidth could use "metrics= " >> >> > between 21 and 30, etc? And then you just add them all >> >> > together? That's what IS-IS has done for years... Even BG= P >> >> > really only has one "metric," with following "tie >> >> > breakers..." So if you have something like weight/local >> >> > pref/etc, such that they occupy different "spaces" in a b= it >> >> > pattern (something suggested, btw, in the original wide >> >> > community work, and in other places, as well), you're >> >> > actually just building a single metric. >> >> > >> >> > You've not "solved" the multiple metric problem -- just >> done >> >> > something a little different than EIGRP's K values to >> >> > combine them into a single metric, which is where you nee= d >> >> > to be to have the ability to build a single stable SPT/DA= G. >> >> > >> >> > The theoretical grounds for this are in T. Griffin=E2= =80=99s >> and >> >> > Sobrinho=E2=80=99s work on BGP-4 and that lies alread= y a couple >> >> > of years ago and that >> >> > makes the analysis much =E2=80=98easier=E2=80=99 (no = worries about >> >> > np(complete) problems, >> >> > etc.). This could be applied in I2RS at the routing >> >> > protocol level. So, we could >> >> > discuss where that sits (should be the clients, right= ?) >> >> > and I don=E2=80=99t know if >> >> > that=E2=80=99s been already done, since I=E2=80=99m q= uite new to this >> list. >> >> > >> >> > >> >> > This doesn=E2=80=99t apply to the problem at hand, though= ... You >> >> > seem to be saying (clarify if wrong) -- >> >> > >> >> > 1. Give each client some set of bits out of a 128 bit >> number >> >> > space (or larger, etc.) >> >> > 2. Each client can have different "metrics" within their >> own >> >> > number space >> >> > 3. When a client attempts to add some ephemeral state, th= ey >> >> > use a metric within their "space" >> >> > 4. The agent can just use the straight number as a relati= ve >> >> > priority for each potential piece of state >> >> > >> >> > This doesn't do anything different than the current conce= pt >> >> > of priority between clients, only in the current plan eac= h >> >> > client only has one priority, rather than multiples. I >> don't >> >> > see where this relates to the problem at hand. >> >> > >> >> > Now, having =E2=80=9Csolved=E2=80=9D that part of the= equation :-) , >> the >> >> > part that interests me >> >> > more is the conflicting clients problem, because this >> >> > could be generalised to >> >> > other problem spaces in the SDN area. I do agree that >> >> > agents should be able >> >> > to catch offending state before installing it and I= =E2=80=99m >> >> > looking for ways to specify >> >> > a minimal set of features that need to be supported a= t >> >> > protocol level. >> >> > >> >> > Anyone else interested? >> >> > >> >> > >> >> > This is precisely where the problem lies. And this is whe= re >> >> > you're going to hit the CAP theorem in full force. There >> are >> >> > only a few choices -- >> >> > >> >> > 1. Make the database eventually consistent >> >> > 2. Shut down accessibility during changes >> >> > 3. ?? >> >> > >> >> > (1) is the idea of either having the agent call back to a= ll >> >> > the clients when state they installed is overwritten or >> >> > allowing the agent to locally store some state where it >> >> > already has the information in hand and install it locall= y >> >> > -- the only real difference between these two solutions i= s >> >> > the "balance of complexity versus speed..." The entire >> >> > discussion here is how much additional complexity are we >> >> > actually adding by doing "panes of glass," which are just >> >> > locally stored state which isn't currently installed. I'm >> >> > arguing that there's minimal complexity added that you're >> >> > not already going to have in the system to allow the agen= t >> >> > to store information locally _if_ it chooses to. Jeff is >> >> > arguing (I think) that the "panes of glass" concept is a >> >> > coherent way of looking at this problem that will help us >> >> > understand and manage the complexity in a way that makes >> >> > sense. Joel is arguing (I think) that this sort of soluti= on >> >> > is out of the WG charter, and it's too complex. I _think_= I >> >> > have the th >> >> > >> >> > r >> >> > ee general perspectives right, but I don't know if I really have >> >> > so... :-) >> >> > >> >> > >> >> > (2) is the idea of locking the database while you're >> >> > changing it. This is explicitly outside the scope of I2RS >> >> > entirely, given we're trying to design something that's >> >> > atomic/restful. There are a lot of techniques you can use >> to >> >> > speed up locking -- row locking, sharding, etc. -- but no= ne >> >> > of these are interesting from the I2RS perspective. >> >> > >> >> > :-) >> >> > >> >> > Russ >> >> > >> >> > >> >> > ________________________________ >> >> > >> >> > Este mensaje y sus adjuntos se dirigen exclusivamente a su >> >> > destinatario, puede contener informaci=C3=B3n privilegiada o >> >> > confidencial y es para uso exclusivo de la persona o entidad = de >> >> > destino. Si no es usted. el destinatario indicado, queda >> >> > notificado de que la lectura, utilizaci=C3=B3n, divulgaci=C3= =B3n y/o >> copia >> >> > sin autorizaci=C3=B3n puede estar prohibida en virtud de la >> >> > legislaci=C3=B3n vigente. Si ha recibido este mensaje por err= or, le >> >> > rogamos que nos lo comunique inmediatamente por esta misma v= =C3=ADa >> y >> >> > proceda a su destrucci=C3=B3n. >> >> > >> >> > The information contained in this transmission is privileged >> and >> >> > confidential information intended only for the use of the >> >> > individual or entity named above. If the reader of this messa= ge >> >> > is not the intended recipient, you are hereby notified that a= ny >> >> > dissemination, distribution or copying of this communication = is >> >> > strictly prohibited. If you have received this transmission i= n >> >> > error, do not read it. Please immediately reply to the sender >> >> > that you have received this communication in error and then >> >> > delete it. >> >> > >> >> > Esta mensagem e seus anexos se dirigem exclusivamente ao seu >> >> > destinat=C3=A1rio, pode conter informa=C3=A7=C3=A3o privilegi= ada ou >> >> > confidencial e =C3=A9 para uso exclusivo da pessoa ou entidad= e de >> >> > destino. Se n=C3=A3o =C3=A9 vossa senhoria o destinat=C3=A1ri= o indicado, fica >> >> > notificado de que a leitura, utiliza=C3=A7=C3=A3o, divulga=C3= =A7=C3=A3o e/ou c=C3=B3pia >> >> > sem autoriza=C3=A7=C3=A3o pode estar proibida em virtude da l= egisla=C3=A7=C3=A3o >> >> > vigente. Se recebeu esta mensagem por erro, rogamos-lhe que n= os >> >> > o comunique imediatamente por esta mesma via e proceda a sua >> >> > destrui=C3=A7=C3=A3o >> >> > >> >> > >> >> _______________________________________________ >> >> i2rs mailing list >> >> i2rs@ietf.org >> >> https://www.ietf.org/mailman/listinfo/i2rs >> >> --001a1141a07c30d5510525c7c626 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I think it is fairly clear that the= server will only be able to
detect a direct overlap.=C2=A0 In an= y case, the client that is getting
data removed needs to use pub/= sub to be told what is going on.
The I2RS agent will not set up a= ny pub/sub for any client.
The client must do this itself via =C2= =A0pub/sub configuration.
The agent will just return an error if = the edit is not accepted.

The current YANG design = is clear: No client is allowed to cause
an edit that will leave t= he datastore invalid wrt/ YANG validation.
That means that a high= priority client WILL LOSE if it attempts
to overwrite partial da= ta in a way that breaks validation.
(This is not what the I2RS ar= ch says to do).=C2=A0 A "solution" might be
to ignore a= ll YANG validation in the ephemeral datastore.
Full YANG validati= on will be slow and even more complicated
than plain NETCONF. No = validation will be a huge security hole.



Andy




On Mon, Nov= 30, 2015 at 11:30 AM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
I am not understanding your com= ment.
As I understand it, Andy was asking about indirect collisions or side effec= ts, where modification of item A by entity B (either an over-write or just = a modification of something that was in base config) make the modification = C that was done by entity D incorrect.=C2=A0 We had discussed that, and agr= eed that as a general matter, such indirect problem detection was not somet= hing we want (wanted) to address.
There are some cases that are represented by YANG constraints.=C2=A0 I don&= #39;t think our decision on this reflects an opinion on what and which YANG= constraints should be enforced by I2RS.=C2=A0 The issue is generally about= side effects that are not anticipated by model designers.

The assumption ew made was that at least the application designer had a hop= e of anticipating them, and therefore the client could monitor objects when= there is a state dependency.=C2=A0 (If no one realizes there is a dependen= ce, things will break.=C2=A0 I don't see a way around that.)

Yours,
Joel

On 11/30/15 2:23 PM, Susan Hares wrote:
Joel and Andy:

For the first version of the I2RS protocol, the WG did agree that the
I2RS agent is required to detect and report on collisions.=C2=A0 However, Andy is asking a valid question on how to detect the linkage within
models or between models.

Andy's example is one of the group portions of a model (eg. An I2RS RIB=
route) or group portions between multiple models (BGP policy + BGP peer
or BGP Policy and BGP local route).

I tried to present this concept at IETF 94 to start this discussion.

The solutions can be: a)=C2=A0 model structure or language in yang to detec= t
grouping within a model, b) Yang library information to detect modules,
or c) something else.

Sue

-----Original Message-----
From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. Halpern
Sent: Tuesday, November 24, 2015 11:15 AM
To: Andy Bierman
Cc: Jeffrey Haas; PEDRO ANDRES ARANDA GUTIERREZ; Susan Hares; Russ
White; i2rs@ietf.org=
Subject: Re: [i2rs] Conversation on Priority and Panes

The agent is required to detect and report direct collisions.

It is not required or expected to detect indirect collisions, which are
the complex source of wedgies and other interesting behaviors.

Yours,

Joel

PS: The WG discussed requiring a maintained connection between the
client and agent, and agreed not to do that.=C2=A0 Which means that no,
agents do not delete state just because clients have disappeared.

On 11/24/15 11:01 AM, Andy Bierman wrote:

=C2=A0>

=C2=A0>

=C2=A0> On Tue, Nov 24, 2015 at 7:36 AM, Joel M. Halpern <jmh@joelhalpern.com

=C2=A0> <mailto:jmh@joelhalpern.com>> wrote:

=C2=A0>

=C2=A0>=C2=A0 =C2=A0 =C2=A0I believe that determining whether two indepe= ndent and internally

=C2=A0>=C2=A0 =C2=A0 =C2=A0consistent sets of changes can, in combinatio= n, produce a wedgie or

=C2=A0>=C2=A0 =C2=A0 =C2=A0other failure is a research problem.

=C2=A0>=C2=A0 =C2=A0 =C2=A0As far as I know, the I2RS working group conc= luded that it was a

=C2=A0>=C2=A0 =C2=A0 =C2=A0sufficiently hard problem that we did not exp= ect the I2RS agent to

=C2=A0>=C2=A0 =C2=A0 =C2=A0get involved in trying to detect, much less r= emediate, such

=C2=A0>=C2=A0 =C2=A0 =C2=A0cross-object inconsistencies.

=C2=A0>

=C2=A0>

=C2=A0>

=C2=A0> But the I2RS agent is responsible for identifying an edit collis= ion

=C2=A0> between a new low-priority request and existing higher priority = edits.

=C2=A0> That sounds involved to me.=C2=A0 So the agent cannot possibly s= olve this

=C2=A0> problem yet it is responsible for precisely that in order to imp= lement

=C2=A0> client priority.

=C2=A0>

=C2=A0> The agent can see that /foo[42] exists in the request and /foo[4= 2]

=C2=A0> exists in the ephemeral datastore, and call that a collision.
=C2=A0>

=C2=A0> However, if /foo[1] or /bar[19] are also part of the "edit&= quot;, such that

=C2=A0> simply replacing /foo[42] will break things, then the agent will= not

=C2=A0> know. It will simply overwrite /foo[42] and leave /foo[1] and /b= ar[19]

=C2=A0> in the datastore.

=C2=A0>

=C2=A0> So is the low-priority client responsible for removing /foo[1] a= nd
/bar[19]?

=C2=A0> Seems the answer is no. The client can go away and there are no<= br>
=C2=A0> cleanup requirements mentioned in the architecture.

=C2=A0>

=C2=A0>

=C2=A0>

=C2=A0>=C2=A0 =C2=A0 =C2=A0Yours,

=C2=A0>=C2=A0 =C2=A0 =C2=A0Joel

=C2=A0>

=C2=A0>

=C2=A0>

=C2=A0> Andy

=C2=A0>

=C2=A0>

=C2=A0>=C2=A0 =C2=A0 =C2=A0On 11/24/15 10:32 AM, PEDRO ANDRES ARANDA GUT= IERREZ wrote:

=C2=A0>

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Russ,

=C2=A0>

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I=E2=80=99m trying to identify = the differences between interactions with

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0routing protocols in I2RS and w= hat is purely conflicts between

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0clients. Currently I see too ma= ny issues overlapping and I fear

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that the trees are not letting = us see the forest.

=C2=A0>

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0So my take on routing protocols= and wedgies might have been too

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0compact :-) Let me give it a se= cond try: Stepping outside the

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I2RS problem space, there is a = lot of work that shows that the

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0origin for BGP-4 instability is= that our beloved route-maps

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0create metrics that are not mon= otonically increasing or

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0decreasing and that makes the r= outing protocols meta-stable.

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(BTW, I=E2=80=99m the first cul= prit when it comes to the use of them, I

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0have created more than one wedg= ie :-P ) Acknowledging that this

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is a significant (and quite com= plex) problem for the Internet in

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0general, I feel that it should = be treated somewhere else (GROW?).

=C2=A0>

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The perspective I would like to= take here is:

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- assume that we have two or mo= re clients that produce perfectly

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sound routing information (no w= edgies there)

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- assume they talk to the same = agent

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- now my questions

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A01.- is there any way to detect whether the clients

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0produce contradicting/conflicti= ng information?

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A02.- is there any way to resolve these

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0contradictions/conflicts?

=C2=A0>

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BR, /PA

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0---

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Dr. Pedro A. Aranda Guti=C3=A9r= rez

=C2=A0>

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Technology Exploration -

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Network Innovation & Virtua= lisation

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0email: pedroa d0t aranda At tel= efonica d0t com

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Telef=C3=B3nica, Investigaci=C3= =B3n y Desarrollo

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0C/ Zurbar=C3=A1n,12

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A028010 Madrid, Spain

=C2=A0>

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Fragen sind nicht da, um beantw= ortet zu werden.

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Fragen sind da, um gestellt zu = werden.

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Georg Kreisler

=C2=A0>

=C2=A0>

=C2=A0>

=C2=A0>

=C2=A0>

=C2=A0>

=C2=A0>

=C2=A0>

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-----Mensaje original-----

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0De: Russ White <7riw77@gmail.com <mailto:<= a href=3D"mailto:7riw77@gmail.com" target=3D"_blank">7riw77@gmail.com <mailto:7riw77@gma= il.com%20%3cmailto:7riw77@gmail.com>>>

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Fecha: lunes, 23 de noviembre d= e 2015, 14:06

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Para: paag <pedroa.aranda@telefonica.= com

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:pedroa.aranda@telefonica.com<= /a>>>, 'Jeffrey Haas'

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<jhaas@pfrc.org <mailto:jhaas@pfrc.org
<mailto:jhaas@pfrc.o= rg%= 20%3cmailto:jhaas@pfrc.org>>>

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0CC: "i2rs@ietf.org <mailto:i2rs@ietf.org>
<mailto:i2rs@ietf.org= %20%= 3cmailto:i2rs@ietf.org%3e>" <i2rs@ietf.org

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:i2rs@ietf.org>>, "'Joel M= . Halpern'"

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<jmh@joelhalpern.com <mailto:jmh@joelhalpern.com
<mailto:jmh@joe= lhalpern.com%20%3cmailto:jmh@joelhalpern.com>>>, 'Andy
=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Bierman' <andy@yumaworks.com <mailto= :andy@yumaworks.com=
<mailto:andy@yum= aworks.com%20%3cmailto:andy@yumaworks.com>>>, Sue

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hares <shares@ndzh.com <mailto:shares@ndzh.com
<mailto:shares@ndzh= .com%20%3cmailto:shares@ndzh.com>>>

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Asunto: RE: [i2rs] Conversation= on Priority and Panes

=C2=A0>

=C2=A0>

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Re = the metric 'problem', just to be more precise in what

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0wou= ld be needed,

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0we = are looking a metric that grows or decreases

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mon= otonically across the

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0who= le network.

=C2=A0>

=C2=A0>

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I assume you mean= in the routing space, and not in the

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0controller/client= space, correct? In terms of a distributed

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0protocol? So, you= 're saying the delay could use "metrics"

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0between 11 and 20= , while the bandwidth could use "metrics"

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0between 21 and 30= , etc? And then you just add them all

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0together? That= 9;s what IS-IS has done for years... Even BGP

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0really only has o= ne "metric," with following "tie

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0breakers..."= So if you have something like weight/local

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pref/etc, such th= at they occupy different "spaces" in a bit

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pattern (somethin= g suggested, btw, in the original wide

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0community work, a= nd in other places, as well), you're

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0actually just bui= lding a single metric.

=C2=A0>

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0You've not &q= uot;solved" the multiple metric problem -- just done

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0something a littl= e different than EIGRP's K values to

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0combine them into= a single metric, which is where you need

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to be to have the= ability to build a single stable SPT/DAG.

=C2=A0>

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The= theoretical grounds for this are in T. Griffin=E2=80=99s and

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sob= rinho=E2=80=99s work on BGP-4 and that lies already a couple

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of = years ago and that

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mak= es the analysis much =E2=80=98easier=E2=80=99 (no worries about

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0np(= complete) problems,

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0etc= .). This could be applied in I2RS at the routing

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pro= tocol level. So, we could

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dis= cuss where that sits (should be the clients, right?)

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and= I don=E2=80=99t know if

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tha= t=E2=80=99s been already done, since I=E2=80=99m quite new to this
list.

=C2=A0>

=C2=A0>

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This doesn=E2=80= =99t apply to the problem at hand, though... You

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0seem to be saying= (clarify if wrong) --

=C2=A0>

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01. Give each clie= nt some set of bits out of a 128 bit number

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0space (or larger,= etc.)

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02. Each client ca= n have different "metrics" within their own

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0number space

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03. When a client = attempts to add some ephemeral state, they

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0use a metric with= in their "space"

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A04. The agent can = just use the straight number as a relative

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0priority for each= potential piece of state

=C2=A0>

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This doesn't = do anything different than the current concept

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of priority betwe= en clients, only in the current plan each

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0client only has o= ne priority, rather than multiples. I don't

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0see where this re= lates to the problem at hand.

=C2=A0>

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Now= , having =E2=80=9Csolved=E2=80=9D that part of the equation :-) , the

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0par= t that interests me

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mor= e is the conflicting clients problem, because this

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cou= ld be generalised to

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0oth= er problem spaces in the SDN area. I do agree that

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0age= nts should be able

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to = catch offending state before installing it and I=E2=80=99m

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0loo= king for ways to specify

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a m= inimal set of features that need to be supported at

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pro= tocol level.

=C2=A0>

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Any= one else interested?

=C2=A0>

=C2=A0>

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This is precisely= where the problem lies. And this is where

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0you're going = to hit the CAP theorem in full force. There are

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0only a few choice= s --

=C2=A0>

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01. Make the datab= ase eventually consistent

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02. Shut down acce= ssibility during changes

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03. ??

=C2=A0>

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(1) is the idea o= f either having the agent call back to all

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the clients when = state they installed is overwritten or

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0allowing the agen= t to locally store some state where it

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0already has the i= nformation in hand and install it locally

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- the only real = difference between these two solutions is

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the "balance= of complexity versus speed..." The entire

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0discussion here i= s how much additional complexity are we

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0actually adding b= y doing "panes of glass," which are just

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0locally stored st= ate which isn't currently installed. I'm

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0arguing that ther= e's minimal complexity added that you're

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0not already going= to have in the system to allow the agent

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to store informat= ion locally _if_ it chooses to. Jeff is

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0arguing (I think)= that the "panes of glass" concept is a

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0coherent way of l= ooking at this problem that will help us

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0understand and ma= nage the complexity in a way that makes

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sense. Joel is ar= guing (I think) that this sort of solution

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is out of the WG = charter, and it's too complex. I _think_ I

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0have the th

=C2=A0>

=C2=A0>=C2=A0 =C2=A0 =C2=A0r

=C2=A0>=C2=A0 =C2=A0 =C2=A0ee general perspectives right, but I don'= t know if I really have

=C2=A0>=C2=A0 =C2=A0 =C2=A0so... :-)

=C2=A0>

=C2=A0>

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(2) is the idea o= f locking the database while you're

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0changing it. This= is explicitly outside the scope of I2RS

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0entirely, given w= e're trying to design something that's

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0atomic/restful. T= here are a lot of techniques you can use to

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0speed up locking = -- row locking, sharding, etc. -- but none

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of these are inte= resting from the I2RS perspective.

=C2=A0>

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:-)

=C2=A0>

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Russ

=C2=A0>

=C2=A0>

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_______________________________= _

=C2=A0>

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Este mensaje y sus adjuntos se = dirigen exclusivamente a su

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0destinatario, puede contener in= formaci=C3=B3n privilegiada o

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0confidencial y es para uso excl= usivo de la persona o entidad de

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0destino. Si no es usted. el des= tinatario indicado, queda

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0notificado de que la lectura, u= tilizaci=C3=B3n, divulgaci=C3=B3n y/o copia

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sin autorizaci=C3=B3n puede est= ar prohibida en virtud de la

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0legislaci=C3=B3n vigente. Si ha= recibido este mensaje por error, le

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rogamos que nos lo comunique in= mediatamente por esta misma v=C3=ADa y

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0proceda a su destrucci=C3=B3n.<= br>
=C2=A0>

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The information contained in th= is transmission is privileged and

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0confidential information intend= ed only for the use of the

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0individual or entity named abov= e. If the reader of this message

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is not the intended recipient, = you are hereby notified that any

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dissemination, distribution or = copying of this communication is

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0strictly prohibited. If you hav= e received this transmission in

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0error, do not read it. Please i= mmediately reply to the sender

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that you have received this com= munication in error and then

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0delete it.

=C2=A0>

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Esta mensagem e seus anexos se = dirigem exclusivamente ao seu

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0destinat=C3=A1rio, pode conter = informa=C3=A7=C3=A3o privilegiada ou

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0confidencial e =C3=A9 para uso = exclusivo da pessoa ou entidade de

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0destino. Se n=C3=A3o =C3=A9 vos= sa senhoria o destinat=C3=A1rio indicado, fica

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0notificado de que a leitura, ut= iliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sem autoriza=C3=A7=C3=A3o pode = estar proibida em virtude da legisla=C3=A7=C3=A3o

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0vigente. Se recebeu esta mensag= em por erro, rogamos-lhe que nos

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0o comunique imediatamente por e= sta mesma via e proceda a sua

=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0destrui=C3=A7=C3=A3o

=C2=A0>

=C2=A0>

_______________________________________________

i2rs mailing list

i2rs@ietf.org <ma= ilto:i2rs@ietf.org&g= t;

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


--001a1141a07c30d5510525c7c626-- From nobody Mon Nov 30 12:25:44 2015 Return-Path: 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 383E71B3087 for ; Mon, 30 Nov 2015 12:25:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.155 X-Spam-Level: X-Spam-Status: No, score=-97.155 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 CLhE3n_ErFUp for ; Mon, 30 Nov 2015 12:25:41 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD3C51B3094 for ; Mon, 30 Nov 2015 12:25:40 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.177; From: "Susan Hares" To: "'Joel M. Halpern'" , "'Andy Bierman'" , "'Alia Atlas'" References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> <563A97AA.5020308@joelhalpern.com> <005101d11798$549a6f10$fdcf4d30$@ndzh.com> <563B0750.70009@joelhalpern.com> <034901d117a1$79a6e7d0$6cf4b770$@gmail.com> <563F8349.4030600@joelhalpern.com> In-Reply-To: <563F8349.4030600@joelhalpern.com> Date: Mon, 30 Nov 2015 15:25:39 -0500 Message-ID: <037201d12bad$47a139a0$d6e3ace0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0373_01D12B83.5ECFC580" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLwMtmz+XLO8+uQ7j5WaenA2rWXRwHVfCJTAW3ySwACzWyr4AJQYvqoAmia70sBb/tJ5QHaZBpQAchizYgBnpuM2wGw4AIiAYh+eNYBFEN8HZvIYIyg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, 'Russ White' <7riw77@gmail.com> Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 20:25:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0373_01D12B83.5ECFC580 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Joel, Andy, and Alia.=20 =20 Due to a lengthy post-IETF illness, I am catching up on email threads = (11/8 to 11/27). This message is a bit longer to respond to multiple = threads.=20 =20 =20 The specific WG agreement was to focus the first release of the I2RS = protocol on control loop with changes and errors. Our purpose in doing = this was to get the I2RS simple protocol with the following:=20 =20 =C2=B7 netconf/restconf with configuration and query/response=20 =C2=B7 secondary feeds (netconf pub/sub, netconf traceability, = IPFIX, google protocol buffers), =C2=B7 protocol independent models (RIB, FB-RIB, and Topology = models, and=20 =C2=B7 initial protocol dependent modules. =20 The WG=E2=80=99s goal was to enable useful applications to be built with = these tools. =20 =20 Completing 2015=E2=80=99s work At IETF 94, I indicated that I2RS 2015-2016 would be wrapping up the = initial set of documents(problem, architecture, problem statement, and = I2RS protocol requirements) in December. I2RS will wrap up the initial = protocol module drafts (RIB, Topology (RIB, Topology (L2 and L3) and = FB-RIB) in December. Our goal in early 2016 is to get implementations = of I2RS agents that support these protocol-independent modules. =20 =20 2016 Approved New work=20 In 2016, we will also review protocol specific I2RS modules and = application drafts.=20 =20 2016 Possible Work=20 If individuals want to work on proposal to include backup/cache issues = in a second I2RS protocol, I am willing to have a small group create = such a proposal and initial concept drafts. Jeff, I and Alia and I = would sit down with the individuals working and review their ideas. = After the AD approves, we can bring to the WG as something that should = go in the charter. =20 =20 After listening to Russ and Andy=E2=80=99s concerns, it is important to = capture the operators input, protocol issues (NETCONF, RESTCONF and = other protocols), and implementation issues. I=E2=80=99m interested in = getting this discussions started now so that we can provide these early = concepts as ideas to the I2RS protocol design team.=20 =20 =20 Thanks for all your thoughts and emails this last few weeks. Each email = has helped me gain a larger understanding of the problem.=20 =20 Sue=20 =20 =20 -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Sunday, November 08, 2015 12:16 PM To: Andy Bierman; Alia Atlas Cc: Russ White; i2rs@ietf.org; Susan Hares Subject: Re: [i2rs] Conversation on Priority and Panes =20 Aince the working group agreement and the request Alia is making is NOt = to store backup / cache, but to use the control loop to deal with = changes and errors, I do not follow what your comment 2 is raising? =20 Yours, Joel =20 On 11/8/15 11:51 AM, Andy Bierman wrote: >=20 >=20 > On Sun, Nov 8, 2015 at 6:36 AM, Alia Atlas < mailto:akatlas@gmail.com>> wrote: >=20 > Hi Russ & Andy, >=20 > I certainly understand the desire for different behavior when a > priority override happens. > However, this is one area where the working group was extremely > clear. Sue and I had > ideas of store-if-not-best and handling overwrites and so on. = There > was a very clear > push back against any such complexity. Feel free to take a read > through the archive. >=20 > While it is tempting to expand the scope and functionality of I2RS > to handle this as not > an error, I would ask that we respect the WG consensus and get > agreement and implementations > going on the basics. >=20 > We have a serious case of too many saying "This is an interesting > soup. Let's watch it." and > far too few people putting wood on the fire and experimenting. >=20 ... > (2) what needs to happen in the client and server to make the backup=20 > data active? > It concerns me that the implementations of proprietary I2RS use=20 > caching instead of introducing a distributed control loop here. If=20 > you think caching is hard, just wait until you try to get 10X - 100X=20 > faster performance out of your notification system to implement a=20 > tight control loop. There is complexity in both approaches. The=20 > pub/sub work is brand new as well, so it will not be stable for=20 > awhile. ... ------=_NextPart_000_0373_01D12B83.5ECFC580 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Joel, = Andy, and Alia.

 

Due to = a lengthy post-IETF illness, I am catching up on email threads (11/8 to = 11/27).=C2=A0=C2=A0 This message is a bit longer to respond to multiple = threads.

 

<WG chair hat on>

The specific WG agreement was to focus the first = release of the I2RS protocol on control loop with changes and = errors.=C2=A0 =C2=A0Our purpose in doing this was to get the I2RS simple = protocol with the following:

=C2=A0

=C2=B7         = netconf/restconf with configuration and = query/response

=C2=B7         = secondary feeds (netconf pub/sub, netconf = traceability, IPFIX, google protocol buffers),

=C2=B7         = protocol independent models (RIB, FB-RIB, = and Topology models, and

=C2=B7         = initial protocol dependent = modules.

 

The WG=E2=80=99s goal was to enable useful = applications to be built with these tools. =C2=A0

 

Completing 2015=E2=80=99s = work

At IETF 94, I indicated = that I2RS 2015-2016 would be wrapping up the initial set of = documents(problem, architecture, problem statement, and I2RS protocol = requirements) in December. =C2=A0I2RS will wrap up the initial protocol = module drafts (RIB, Topology (RIB, Topology (L2 and L3) and FB-RIB) in = December. =C2=A0=C2=A0Our goal in early 2016 is to get implementations = of I2RS agents that support these protocol-independent modules. = =C2=A0

 

2016 Approved New work

In 2016, we will also review protocol specific I2RS = modules and application drafts.

 

2016 Possible Work

If individuals want to work on proposal to include = backup/cache issues in a second I2RS protocol, I am willing to have a = small group create such a proposal and initial concept = drafts.=C2=A0=C2=A0 Jeff, I and Alia and I would sit down with the = individuals working and review their ideas.=C2=A0 After the AD approves, = we can bring to the WG as something that should go in the charter. = =C2=A0

 

After listening to Russ and Andy=E2=80=99s = concerns, it is important to capture the operators input, protocol = issues (NETCONF, RESTCONF and other protocols), and implementation = issues.=C2=A0 I=E2=80=99m interested in getting this discussions started = now so that we can provide these early concepts as ideas to the I2RS = protocol design team.

<WG hat = off>

 

Thanks for all your thoughts and emails this last = few weeks.=C2=A0 Each email has helped me gain a larger understanding of = the problem.

=C2=A0

Sue =

=C2=A0=C2=A0=C2=A0

 

-----Original Message-----
From: Joel M. Halpern = [mailto:jmh@joelhalpern.com]
Sent: Sunday, November 08, 2015 12:16 = PM
To: Andy Bierman; Alia Atlas
Cc: Russ White; i2rs@ietf.org; = Susan Hares
Subject: Re: [i2rs] Conversation on Priority and = Panes

 

Aince the working group agreement and the request = Alia is making is NOt to store backup / cache, but to use the control = loop to deal with changes and errors, I do not follow what your comment = 2 is raising?

 

Yours,

Joel

 

On = 11/8/15 11:51 AM, Andy Bierman wrote:

> 

> 

> On Sun, Nov 8, 2015 at 6:36 AM, Alia Atlas = <akatlas@gmail.com

> <mailto:akatlas@gmail.com<= /span>>> wrote:

> 

>=C2=A0=C2=A0=C2=A0=C2=A0 Hi Russ & = Andy,

> 

>=C2=A0=C2=A0=C2=A0=C2=A0 I certainly understand = the desire for different behavior when a

>=C2=A0=C2=A0=C2=A0=C2=A0 priority override = happens.

>=C2=A0=C2=A0=C2=A0=C2=A0 However, this is one = area where the working group was extremely

>=C2=A0=C2=A0=C2=A0=C2=A0 clear.=C2=A0 Sue and I = had

>=C2=A0=C2=A0=C2=A0=C2=A0 = ideas of store-if-not-best and handling overwrites and so on.=C2=A0 = There

>=C2=A0=C2=A0=C2=A0=C2=A0 = was a very clear

>=C2=A0=C2=A0=C2=A0=C2=A0 push back against any = such complexity.=C2=A0 Feel free to take a read

>=C2=A0=C2=A0=C2=A0=C2=A0 through the = archive.

> 

>=C2=A0=C2=A0=C2=A0=C2=A0 While it is tempting = to expand the scope and functionality of I2RS

>=C2=A0=C2=A0=C2=A0=C2=A0 to handle this as = not

>=C2=A0=C2=A0=C2=A0=C2=A0 = an error, I would ask that we respect the WG consensus and = get

>=C2=A0=C2=A0=C2=A0=C2=A0 = agreement and implementations

>=C2=A0=C2=A0=C2=A0=C2=A0 going on the = basics.

> 

>=C2=A0=C2=A0=C2=A0=C2=A0 We have a serious case = of too many saying "This is an interesting

>=C2=A0=C2=A0=C2=A0=C2=A0 soup.=C2=A0 Let's = watch it." and

>=C2=A0=C2=A0=C2=A0=C2=A0 far too few people = putting wood on the fire and experimenting.

> 

...

> (2) = what needs to happen in the client and server to make the backup =

> data = active?

> It concerns me that = the implementations of proprietary I2RS use

> caching instead of introducing a distributed = control loop here.=C2=A0 If

> = you think caching is hard, just wait until you try to get 10X - 100X =

> faster performance out of = your notification system to implement a

> tight control loop.=C2=A0 There is complexity = in both approaches. The

> = pub/sub work is brand new as well, so it will not be stable for =

> awhile.

...

------=_NextPart_000_0373_01D12B83.5ECFC580-- From nobody Mon Nov 30 12:32:33 2015 Return-Path: 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 7E0F41B30BC for ; Mon, 30 Nov 2015 12:32:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.399 X-Spam-Level: X-Spam-Status: No, score=-101.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 PeXaC7Xrw8U7 for ; Mon, 30 Nov 2015 12:32:30 -0800 (PST) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (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 143F51B30B9 for ; Mon, 30 Nov 2015 12:32:30 -0800 (PST) Received: by oies6 with SMTP id s6so104102870oie.1 for ; Mon, 30 Nov 2015 12:32:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qBFDrqGPwZvOmsCulcav0vbPXO6dnSa/TGnzm0K/sGE=; b=jLxzVGSS+JE+SCZnrxkx32aT1919jsqxWcH0C4CmDZcmPwoQuCwRgOJhuOaV7D8UX0 ZRGZVYJcVW6s8JQ8wWrIZCYXvDeE6hqTBr2jyCLqVAvtXgZNm57BPnkBp7BVY50nqSDX CkTnhNrnyY3TJ/SL1uwPyGWfT58oObM6p+u+Wlu/4al38cL03WRb3Fs42xK0EVrjuSjj 8UPNre4XUjLUcttD9UUO8dpSP/zVY+g6sAZ2h9X1EiJg2RYtQ47lYkuRQOkYN3WPOYEF Dv8UHsed1YvFGpqU8nhA9pFIlJzAlnZeqrMjljDHwRtPBwuujiUg6xSHVt7cHgYrk7dJ JmTw== MIME-Version: 1.0 X-Received: by 10.202.86.202 with SMTP id k193mr44542748oib.115.1448915549393; Mon, 30 Nov 2015 12:32:29 -0800 (PST) Received: by 10.60.177.103 with HTTP; Mon, 30 Nov 2015 12:32:29 -0800 (PST) In-Reply-To: References: Date: Mon, 30 Nov 2015 15:32:29 -0500 Message-ID: From: Alia Atlas To: Mach Chen Content-Type: multipart/alternative; boundary=001a113adad4a199380525c7f09b Archived-At: Cc: "Jeffrey \(Zhaohui\) Zhang" , Nitin Bahadur , "Manish Kumar \(manishkr\)" , Chris Bowers , "i2rs@ietf.org" Subject: Re: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 20:32:32 -0000 --001a113adad4a199380525c7f09b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable >From my perspective, adding encap for a next-hop in the RIB makes sense. >From one perspective, this is just putting, for instance, an MPLS label on. However, the RIB supports using additional higher-level abstractions. So - the RIB might use an interface that is to a tunnel - but the RIB may also have a next-hop that indicates adding the encap associated with an LSP or a tunnel. This allows the RIB's next-hop to stay the same when the LSP or tunnel changes. I don't see the same rationale for decap. I'm most familiar with MPLS - where the label has an operation that is popping or swapping. For VXLAN or GRE, the outer dest IP address would indicate the router and thus be decapsulated. I see the role of the RIB as specifying what packets should go out what interface with appropriate encaps. It's not creating the tunnel but merely putting packet(s) into the tunnel (or LSP or MPLS label stack) at the desired level of abstraction. The discussion about decapsulation feels much more to me like it is creating the tunnel. Obviously, I'm happy to listen to other perspectives. Regards, Alia On Wed, Nov 18, 2015 at 3:36 AM, Mach Chen wrote: > Indeed, I agree with Jeffery here. > > I'd suggest we keep the current model as is and address the vxlan/nvgre > decap in other places. > > Best regards, > Mach > > > -----Original Message----- > > From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] > > Sent: Tuesday, November 17, 2015 6:00 AM > > To: Nitin Bahadur; Manish Kumar (manishkr); Chris Bowers; Mach Chen; > > i2rs@ietf.org > > Subject: RE: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 > > > > Current RIB has ieee-mac RIB, which could use vxlan encap nexthops. > > > > BTW, mpls encap/decap is needed even for non-segmenting scenarios - pla= in > > old l3vpn, vpls, or evpn with mpls data plane. > > > > Jeffrey > > > > > -----Original Message----- > > > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Nitin Bahadur > > > Sent: Monday, November 16, 2015 4:16 PM > > > To: Manish Kumar (manishkr) ; Chris Bowers > > > ; Mach Chen ; > > i2rs@ietf.org > > > Subject: Re: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 > > > > > > > > > We need a minimal tunnel encap for MPLS.so that mpls labels can be > > > pushed and popped. So I do want to keep basic (aka mpls) tunnel > > > encap/decap in this draft. This will also enable development of > > > solutions based on Segment routing (or whatever it's called these > days). > > > > > > Nitin > > > > > > On 11/16/15, 12:17 PM, "Manish Kumar (manishkr)" > > > wrote: > > > > > > >Encap/Decap belong to a different layer (actually one that ties two > > > layers > > > >together) and RIB doesn't look the right place for encap/decap to me= . > > > > > > > >Thanks, > > > >Manish > > > > > > > >On 17/11/15 1:25 am, "i2rs on behalf of Nitin Bahadur" > > > > wrote: > > > > > > > >> > > > >> > > > >>>I find it odd that the current data model provides the ability to > > > >>>configure encap, but not decap, for VXLAN. This would require the > > > >>>user of the data model to configure VXLAN tunnel-encap using one > data > > model > > > >>>and vxlan-decap using another data model. I think this is perhap= s > an > > > >>>indication that VXLAN encap does not belong in the RIB data model > > > >>>either. > > > >> > > > >>I=C2=B9ll buy that argument. And I believe we can extend that argum= ent to > > > >>GRE & NVGRE as well. > > > >> > > > >>Anyone on the list have comments related to this? > > > >> > > > >>Thanks > > > >>Nitin > > > >> > > > >> > > > >>_______________________________________________ > > > >>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 > --001a113adad4a199380525c7f09b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<no-hat>

From my perspective, add= ing encap for a next-hop in the RIB makes sense.=C2=A0 From one perspective= ,
this is just putting, for instance, an MPLS label on.=C2=A0 How= ever, the RIB supports using additional
higher-level abstractions= .=C2=A0 So - the RIB might use an interface that is to a tunnel - but the R= IB may
also have a next-hop that indicates adding the encap assoc= iated with an LSP or a tunnel.=C2=A0 This=C2=A0
allows the RIB= 9;s next-hop to stay the same when the LSP or tunnel changes.
I don't see the same rationale for decap.=C2=A0 I'm mos= t familiar with MPLS - where the label has an
operation that is p= opping or swapping.=C2=A0 For VXLAN or GRE, the outer dest IP address would=
indicate the router and thus be decapsulated.

I see the role of the RIB as specifying what packets should go out w= hat interface with appropriate
encaps.=C2=A0 It's not creatin= g the tunnel but merely putting packet(s) into the tunnel (or LSP or MPLS l= abel stack)
=C2=A0at the desired level of abstraction.=C2=A0 The = discussion about decapsulation feels much more to me like it is creating th= e tunnel.

Obviously, I'm happy to listen to ot= her perspectives.

Regards,
Alia
</no-hat>

On Wed, Nov 18, 2015 at 3:36 AM, Mach Chen &l= t;mach.chen@huawe= i.com> wrote:
Indeed, I agr= ee with Jeffery here.

I'd suggest we keep the current model as is and address the vxlan/nvgre= decap in other places.

Best regards,
Mach

> -----Original Message-----
> From: Jeffrey (Zhaohui) Zhang [mailto= :zzhang@juniper.net]
> Sent: Tuesday, November 17, 2015 6:00 AM
> To: Nitin Bahadur; Manish Kumar (manishkr); Chris Bowers; Mach Chen; > i2rs@ietf.org
> Subject: RE: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03
>
> Current RIB has ieee-ma= c RIB, which could use vxlan encap nexthops.
>
> BTW, mpls encap/decap is needed even for non-segmenting scenarios - pl= ain
> old l3vpn, vpls, or evpn with mpls data plane.
>
> Jeffrey
>
> > -----Original Message-----
> > From: i2rs [mailto:i2rs-= bounces@ietf.org] On Behalf Of Nitin Bahadur
> > Sent: Monday, November 16, 2015 4:16 PM
> > To: Manish Kumar (manishkr) <manishkr@cisco.com>; Chris Bowers
> > <cbowers@juniper.net>; Mach Chen <mach.chen@huaw= ei.com>;
> i2rs@ietf.org
> > Subject: Re: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03=
> >
> >
> > We need a minimal tunnel encap for MPLS.so that mpls labels can b= e
> > pushed and popped. So I do want to keep basic (aka mpls) tunnel > > encap/decap in this draft. This will also enable development of > > solutions based on Segment routing (or whatever it's called t= hese days).
> >
> > Nitin
> >
> > On 11/16/15, 12:17 PM, "Manish Kumar (manishkr)" <manishkr@cisco.com>
> > wrote:
> >
> > >Encap/Decap belong to a different layer (actually one that ti= es two
> > layers
> > >together) and RIB doesn't look the right place for encap/= decap to me.
> > >
> > >Thanks,
> > >Manish
> > >
> > >On 17/11/15 1:25 am, "i2rs on behalf of Nitin Bahadur&qu= ot;
> > ><i2rs-bounces@iet= f.org on behalf of nitin_bah= adur@yahoo.com> wrote:
> > >
> > >>
> > >>
> > >>>I find it odd that the current data model provides th= e ability to
> > >>>configure encap, but not decap, for VXLAN.=C2=A0 This= would require the
> > >>>user of the data model to configure VXLAN tunnel-enca= p=C2=A0 using one data
> model
> > >>>and vxlan-decap using another data model.=C2=A0 =C2= =A0I think this is perhaps an
> > >>>indication that VXLAN encap does not belong in the RI= B data model
> > >>>either.
> > >>
> > >>I=C2=B9ll buy that argument. And I believe we can extend = that argument to
> > >>GRE & NVGRE as well.
> > >>
> > >>Anyone on the list have comments related to this?
> > >>
> > >>Thanks
> > >>Nitin
> > >>
> > >>
> > >>_______________________________________________
> > >>i2rs mailing list
> > >>i2rs@ietf.org
> > >>https://www.ietf.org/mailman/listinfo/i2= rs
> > >
> >
> >
> > _______________________________________________
> > 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

--001a113adad4a199380525c7f09b-- From nobody Mon Nov 30 12:42:28 2015 Return-Path: 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 3FE981B30EF for ; Mon, 30 Nov 2015 12:42:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 5VJLf8WRa49a for ; Mon, 30 Nov 2015 12:42:24 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0123.outbound.protection.outlook.com [65.55.169.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A700E1B30ED for ; Mon, 30 Nov 2015 12:42:21 -0800 (PST) Received: from BY2PR05MB614.namprd05.prod.outlook.com (10.141.218.148) by BY2PR05MB613.namprd05.prod.outlook.com (10.141.218.145) with Microsoft SMTP Server (TLS) id 15.1.331.20; Mon, 30 Nov 2015 20:42:18 +0000 Received: from BY2PR05MB614.namprd05.prod.outlook.com ([10.141.218.148]) by BY2PR05MB614.namprd05.prod.outlook.com ([10.141.218.148]) with mapi id 15.01.0331.023; Mon, 30 Nov 2015 20:42:18 +0000 From: Chris Bowers To: "i2rs@ietf.org" Thread-Topic: more feedback on draft-ietf-i2rs-rib-data-model (issues #2 and #3) Thread-Index: AdErrnerlpOCI4MHS5SP05shPreTcw== Date: Mon, 30 Nov 2015 20:42:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=cbowers@juniper.net; x-originating-ip: [66.129.239.13] x-microsoft-exchange-diagnostics: 1; BY2PR05MB613; 5:h88+vzEhguhm46WsZ15vIzxc5zCgAlege9VEAnxmg/R52ZsOYD/9ByTIg8dblAGzH1iBTYT41ujeTRxSzYwc1ImnIjVcnVacEs5RbE1WDy2qomFFKaorwq398BF5BpyvevB1ioJ3Dqi5p6691WykwQ==; 24:mY+jyO16Kib9WbkO6Dcu7731h0biVFCaVcIIjc7R+Y9ZjHrDoJLznKz9lE3+2Ee68r8N2//OtmszVQy7r79pfdKg5pS5nyQrEbQGym0qbIU= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB613; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(10201501046)(3002001); SRVR:BY2PR05MB613; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB613; x-forefront-prvs: 0776C39A48 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(164054003)(199003)(77096005)(5003600100002)(19300405004)(19617315012)(99286002)(19625215002)(106356001)(2900100001)(230783001)(15975445007)(54356999)(19580395003)(5002640100001)(122556002)(86362001)(575784001)(450100001)(1220700001)(105586002)(40100003)(2501003)(50986999)(790700001)(5004730100002)(586003)(2351001)(92566002)(97736004)(74316001)(5001960100002)(107886002)(3846002)(81156007)(66066001)(87936001)(11100500001)(189998001)(5008740100001)(1096002)(33656002)(6116002)(76576001)(102836003)(10400500002)(110136002)(16236675004)(101416001)(229853001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB613; H:BY2PR05MB614.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR05MB61434B552390F7E082D8B13A9000BY2PR05MB614namprd_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Nov 2015 20:42:18.4629 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB613 Archived-At: Subject: [i2rs] more feedback on draft-ietf-i2rs-rib-data-model (issues #2 and #3) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 20:42:27 -0000 --_000_BY2PR05MB61434B552390F7E082D8B13A9000BY2PR05MB614namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I2RS WG and draft authors, I created two more issues related to draft-ietf-i2rs-rib-data-model on the = I2RS Wiki: http://trac.tools.ietf.org/wg/i2rs/trac/wiki/IssuesRibDataModel They are copied below as well. Thanks, Chris Issue 2: Make definition of route state "active" more precise: Current definition in section 2.3 (repeated in 2.6) * ACTIVE: Indicates whether a route is fully resolved and is a candidat= e for selection. Propose to replace with: * ACTIVE: Indicates whether a route has at least one fully resolved nex= thop and is therefore eligible for installation in the FIB. Issue 3: route-change notification The current route-change notification seems to have many of the right compo= nents. However, the usage is ambiguous. Below is proposed text to clarify t= he usage as well as some modifications of the data model to make this usage= clearer. An implementation of this RIB data model MUST support sending route-change = notifications whenever a route transitions between the following states: * from the active state to the inactive state * from the inactive state to the active state * from the installed state to the uninstalled state * from the uninstalled state to the installed state A single notification MAY be used when a route transitions from inactive/un= installed to active/installed or in the other direction. ________________________________ The following changes to the yang model affecting the route-change notifica= tion, in particular the route-change-reasons should also be considered. It = may also make sense to make the route-change-reason a list in order to retu= rn multiple route-change0reasons. This would be useful for the the case whe= re a nexthop becoming resolved makes a route A active which is of better pr= eference than a currently active route B, which results in the route A bein= g installed. Or the text should clarify that this case requires two notific= ations. Or the text should clarify which single reason should be given in t= his case. notification route-change { description "Route change notification."; leaf rib-name { type string; mandatory true; description "A reference to the name of a rib."; } leaf rib-family { type rib-family-def; mandatory true; description "A reference to address family of a rib."; } uses route-prefix; leaf route-installed-state { type route-installed-state-def; mandatory true; description "Indicates whether the route is currently installed in the FIB o= r uninstalled."; } leaf route-state { type route-state-def; mandatory true; description "Indicates whether a route is active or inactive."; } leaf route-change-reason { type route-change-reason-def; mandatory true; description "Return the reason that caused the route change."; } } identity route-change-reason { description "Base identify from which all route change reasons are derived."; } identity lower-route-preference { base "route-change-reason"; description "This route was installed in the FIB because it had a lower route = preference value (and thus a higher route preference) than the route it rep= laced."; } identity higher-route-preference { base "route-change-reason"; description "This route was uninstalled from the FIB because it had a higher r= oute preference value (and thus a lower route preference) than the route th= at replaced it."; } # Based on the current data model, which does not appear to define a route = metric, # it is not clear what scenario will result in higher metric being the rout= e change reason. identity higher-metric { base "route-change-reason"; description "Higher metric "; } identity resolved-nexthop { base "route-change-reason"; description "This route was made active because at least one of its nexthops w= as resolved."; } identity unresolved-nexthop { base "route-change-reason"; description "This route was made inactive because all of its nexthops are unre= solved."; } typedef route-change-reason-def { type identityref { base "route-change-reason"; } description "Route change reason def."; } --_000_BY2PR05MB61434B552390F7E082D8B13A9000BY2PR05MB614namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I2RS WG and draft authors,

I created two more issues related= to draft-ietf-i2rs-rib-data-model on the I2RS Wiki:

http://trac.tools.ietf.org/wg/i2= rs/trac/wiki/IssuesRibDataModel

They are copied below as well.

Thanks,

Chris

 

Issue 2: Make definition of route state "active" = more precise:

Current definition in section 2.3 (repeated in 2.6)

  • ACTIVE: Indicates whether a route is fully resolved and is a candidate = for selection.

Propose to replace with:

  • ACTIVE: Indicates whether a route has at least one fully resolved nexth= op and is therefore eligible for installation in the FIB.

Issue 3: route-change notification

The current route-change notification seems to have many of th= e right components. However, the usage is ambiguous. Below is proposed text to clarify the usage as well as some modifications = of the data model to make this usage clearer.

An implementation of this RIB data model MUST support sending = route-change notifications whenever a route transitions between the following states:

  • from the active state to the inactive state
  • from the inactive state to the active state
  • from the installed state to the uninstalled state
  • from the uninstalled state to the installed state

A single notification MAY be used when a route transitions fro= m inactive/uninstalled to active/installed or in the other direction.

The following changes to the yang model affecting the route-ch= ange notification, in particular the route-change-reasons should also be considered. It may also make sense to make the route-change= -reason a list in order to return multiple route-change0reasons. This would= be useful for the the case where a nexthop becoming resolved makes a route= A active which is of better preference than a currently active route B, which results in the route A being instal= led. Or the text should clarify that this case requires two notifications. = Or the text should clarify which single reason should be given in this case= .

     notification route-change {<= o:p>

       description

         "Rou= te change notification.";

       leaf rib-name {<= /o:p>

         type stri= ng;

         mandatory= true;

         descripti= on

         &nbs= p; "A reference to the name of a rib.";

       }

       leaf rib-family {

         type rib-= family-def;

         mandatory= true;

         descripti= on

         &nbs= p; "A reference to address family of a rib.";

       }

       uses route-prefix;

       leaf route-installed-= state {

         type rout= e-installed-state-def;

         mandatory= true;

         descripti= on

         &nbs= p; "Indicates whether the route is currently installed in the FIB or u= ninstalled.";

       }

       leaf route-state {

         type rout= e-state-def;

         mandatory= true;

         descripti= on

         &nbs= p; "Indicates whether a route is active or inactive.";=

       }

       leaf route-change-rea= son {

         type rout= e-change-reason-def;

         mandatory= true;

         descripti= on

         &nbs= p; "Return the reason that caused the route change.";<= /span>

       }

     }

       

     identity route-change-reason= {

       description

         "Bas= e identify from which all route change

          rea= sons are derived.";

     }

 

     identity lower-route-preference {=

       base "route-chan= ge-reason";

       description

         "Thi= s route was installed in the FIB because it had a lower route preference va= lue (and thus a higher route preference) than the route it replaced.";=

     }

       

     identity higher-route-prefer= ence {

       base "route-chan= ge-reason";

       description

         "Thi= s route was uninstalled from the FIB because it had a higher route preferen= ce value (and thus a lower route preference) than the route that replaced i= t.";

     }

       

# Based on the current data model, which does not appear t= o define a route metric,

# it is not clear what scenario will result in higher metr= ic being the route change reason.

     identity higher-metric {

       base "route-chan= ge-reason";

       description

         "Hig= her metric ";

     }

 

     identity resolved-nexthop {<= /o:p>

       base "route-chan= ge-reason";

       description

         "Thi= s route was made active because at least one of its nexthops was resolved.&= quot;;

     }

 

     identity unresolved-nexthop {

       base "route-chan= ge-reason";

       description

         "Thi= s route was made inactive because all of its nexthops are unresolved."= ;

     }

 

     typedef route-change-reason-def {=

       type identityref {

         base &quo= t;route-change-reason";

       }

       description

         "Rou= te change reason def.";

     }

       

 

--_000_BY2PR05MB61434B552390F7E082D8B13A9000BY2PR05MB614namprd_-- From nobody Mon Nov 30 13:26:41 2015 Return-Path: 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 943C01B344E for ; Mon, 30 Nov 2015 13:26:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.477 X-Spam-Level: X-Spam-Status: No, score=-1.477 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTTP_ESCAPED_HOST=1.125, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_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 75FbqnBru6uF for ; Mon, 30 Nov 2015 13:26:36 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70BD71B3452 for ; Mon, 30 Nov 2015 13:26:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 5B5BA1C0445; Mon, 30 Nov 2015 13:26:36 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 675521C038E; Mon, 30 Nov 2015 13:26:35 -0800 (PST) To: Andy Bierman References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> <563A97AA.5020308@joelhalpern.com> <00f301d11761$61699130$243cb390$@gmail.com> <563AA59C.4060809@joelhalpern.com> <018101d11764$66b82e50$34288af0$@gmail.com> <20151119203509.GA22415@pfrc.org> <5B54713B-CDE6-4F65-BE79-91F5B9FF3850@telefonica.com> <008d01d12390$064987c0$12dc9740$@gmail.com> <99B64F3B-20A1-4D3C-A445-46D235EDB44D@telefonica.com> <014a01d12394$ec5ffa60$c51fef20$@gmail.com> <87361DB1-DC6F-4023-A807-4003B436B472@telefonica.com> <012501d125e7$62e457e0$28ad07a0$@gmail.com> <0EAC7123-CECA-4C34-B5E3-E89F0C8DBF94@telefonica.com> <56548418.6060603@joelhalpern.com> <56548CF8.8030900@joelhalpern.com> <032901d12ba4$9a6a3e60$cf3ebb20$@ndzh.com> <565CA3DA.808@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <565CBF08.7030301@joelhalpern.com> Date: Mon, 30 Nov 2015 16:26:32 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Jeffrey Haas , PEDRO ANDRES ARANDA GUTIERREZ , Russ White <7riw77@gmail.com>, Susan Hares , "i2rs@ietf.org" Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 21:26:39 -0000 I agree Andy. We have our choice of poison. We can perform full validation, which is likely to be slow, but very useful. Or we can omit validation, which introduces risks. I don't know if I would call those security risks in general, although one can probably get some security risks out of validation failures. (We do still assume that permissions are checked.) The conclusion after discussion last time around, and particularly the request from the operators who were in the room at the time, was that the operators were happy with a situation where they could gain significant performance at the risk of shooting themselves in the foot. Yours, Joel On 11/30/15 3:20 PM, Andy Bierman wrote: > Hi, > > I think it is fairly clear that the server will only be able to > detect a direct overlap. In any case, the client that is getting > data removed needs to use pub/sub to be told what is going on. > The I2RS agent will not set up any pub/sub for any client. > The client must do this itself via pub/sub configuration. > The agent will just return an error if the edit is not accepted. > > The current YANG design is clear: No client is allowed to cause > an edit that will leave the datastore invalid wrt/ YANG validation. > That means that a high priority client WILL LOSE if it attempts > to overwrite partial data in a way that breaks validation. > (This is not what the I2RS arch says to do). A "solution" might be > to ignore all YANG validation in the ephemeral datastore. > Full YANG validation will be slow and even more complicated > than plain NETCONF. No validation will be a huge security hole. > > > > Andy > > > > > On Mon, Nov 30, 2015 at 11:30 AM, Joel M. Halpern > wrote: > > I am not understanding your comment. > As I understand it, Andy was asking about indirect collisions or > side effects, where modification of item A by entity B (either an > over-write or just a modification of something that was in base > config) make the modification C that was done by entity D > incorrect. We had discussed that, and agreed that as a general > matter, such indirect problem detection was not something we want > (wanted) to address. > There are some cases that are represented by YANG constraints. I > don't think our decision on this reflects an opinion on what and > which YANG constraints should be enforced by I2RS. The issue is > generally about side effects that are not anticipated by model > designers. > > The assumption ew made was that at least the application designer > had a hope of anticipating them, and therefore the client could > monitor objects when there is a state dependency. (If no one > realizes there is a dependence, things will break. I don't see a > way around that.) > > Yours, > Joel > > On 11/30/15 2:23 PM, Susan Hares wrote: > > Joel and Andy: > > For the first version of the I2RS protocol, the WG did agree > that the > I2RS agent is required to detect and report on collisions. However, > Andy is asking a valid question on how to detect the linkage within > models or between models. > > Andy's example is one of the group portions of a model (eg. An > I2RS RIB > route) or group portions between multiple models (BGP policy + > BGP peer > or BGP Policy and BGP local route). > > I tried to present this concept at IETF 94 to start this discussion. > > The solutions can be: a) model structure or language in yang to > detect > grouping within a model, b) Yang library information to detect > modules, > or c) something else. > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org > ] On Behalf Of Joel M. Halpern > Sent: Tuesday, November 24, 2015 11:15 AM > To: Andy Bierman > Cc: Jeffrey Haas; PEDRO ANDRES ARANDA GUTIERREZ; Susan Hares; Russ > White; i2rs@ietf.org > Subject: Re: [i2rs] Conversation on Priority and Panes > > The agent is required to detect and report direct collisions. > > It is not required or expected to detect indirect collisions, > which are > the complex source of wedgies and other interesting behaviors. > > Yours, > > Joel > > PS: The WG discussed requiring a maintained connection between the > client and agent, and agreed not to do that. Which means that no, > agents do not delete state just because clients have disappeared. > > On 11/24/15 11:01 AM, Andy Bierman wrote: > > > > > > > > > On Tue, Nov 24, 2015 at 7:36 AM, Joel M. Halpern > > > > >> > wrote: > > > > > > I believe that determining whether two independent and > internally > > > consistent sets of changes can, in combination, produce > a wedgie or > > > other failure is a research problem. > > > As far as I know, the I2RS working group concluded that > it was a > > > sufficiently hard problem that we did not expect the > I2RS agent to > > > get involved in trying to detect, much less remediate, such > > > cross-object inconsistencies. > > > > > > > > > > > > But the I2RS agent is responsible for identifying an edit > collision > > > between a new low-priority request and existing higher > priority edits. > > > That sounds involved to me. So the agent cannot possibly > solve this > > > problem yet it is responsible for precisely that in order to > implement > > > client priority. > > > > > > The agent can see that /foo[42] exists in the request and > /foo[42] > > > exists in the ephemeral datastore, and call that a collision. > > > > > > However, if /foo[1] or /bar[19] are also part of the "edit", > such that > > > simply replacing /foo[42] will break things, then the agent > will not > > > know. It will simply overwrite /foo[42] and leave /foo[1] > and /bar[19] > > > in the datastore. > > > > > > So is the low-priority client responsible for removing > /foo[1] and > /bar[19]? > > > Seems the answer is no. The client can go away and there are no > > > cleanup requirements mentioned in the architecture. > > > > > > > > > > > > Yours, > > > Joel > > > > > > > > > > > > Andy > > > > > > > > > On 11/24/15 10:32 AM, PEDRO ANDRES ARANDA GUTIERREZ wrote: > > > > > > Hi Russ, > > > > > > I’m trying to identify the differences between > interactions with > > > routing protocols in I2RS and what is purely > conflicts between > > > clients. Currently I see too many issues overlapping > and I fear > > > that the trees are not letting us see the forest. > > > > > > So my take on routing protocols and wedgies might > have been too > > > compact :-) Let me give it a second try: Stepping > outside the > > > I2RS problem space, there is a lot of work that > shows that the > > > origin for BGP-4 instability is that our beloved > route-maps > > > create metrics that are not monotonically increasing or > > > decreasing and that makes the routing protocols > meta-stable. > > > (BTW, I’m the first culprit when it comes to the use > of them, I > > > have created more than one wedgie :-P ) > Acknowledging that this > > > is a significant (and quite complex) problem for the > Internet in > > > general, I feel that it should be treated somewhere > else (GROW?). > > > > > > The perspective I would like to take here is: > > > - assume that we have two or more clients that > produce perfectly > > > sound routing information (no wedgies there) > > > - assume they talk to the same agent > > > - now my questions > > > 1.- is there any way to detect whether the > clients > > > produce contradicting/conflicting information? > > > 2.- is there any way to resolve these > > > contradictions/conflicts? > > > > > > BR, /PA > > > --- > > > Dr. Pedro A. Aranda Gutiérrez > > > > > > Technology Exploration - > > > Network Innovation & Virtualisation > > > email: pedroa d0t aranda At telefonica d0t com > > > Telefónica, Investigación y Desarrollo > > > C/ Zurbarán,12 > > > 28010 Madrid, Spain > > > > > > Fragen sind nicht da, um beantwortet zu werden. > > > Fragen sind da, um gestellt zu werden. > > > Georg Kreisler > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Mensaje original----- > > > De: Russ White <7riw77@gmail.com > > %20%3cmailto:7riw77@gmail.com > >>> > > > Fecha: lunes, 23 de noviembre de 2015, 14:06 > > > Para: paag > > > >>, 'Jeffrey Haas' > > > > > %20%3cmailto:jhaas@pfrc.org > >>> > > > CC: "i2rs@ietf.org > > > %20%3cmailto:i2rs@ietf.org > %3e>" > > > >>, > "'Joel M. Halpern'" > > > > > %20%3cmailto:jmh@joelhalpern.com > >>>, 'Andy > > > Bierman' > %20%3cmailto:andy@yumaworks.com > >>>, Sue > > > Hares > > %20%3cmailto:shares@ndzh.com > >>> > > > Asunto: RE: [i2rs] Conversation on Priority and Panes > > > > > > > > > Re the metric 'problem', just to be more > precise in what > > > would be needed, > > > we are looking a metric that grows or decreases > > > monotonically across the > > > whole network. > > > > > > > > > I assume you mean in the routing space, and not > in the > > > controller/client space, correct? In terms of a > distributed > > > protocol? So, you're saying the delay could use > "metrics" > > > between 11 and 20, while the bandwidth could use > "metrics" > > > between 21 and 30, etc? And then you just add > them all > > > together? That's what IS-IS has done for > years... Even BGP > > > really only has one "metric," with following "tie > > > breakers..." So if you have something like > weight/local > > > pref/etc, such that they occupy different > "spaces" in a bit > > > pattern (something suggested, btw, in the > original wide > > > community work, and in other places, as well), > you're > > > actually just building a single metric. > > > > > > You've not "solved" the multiple metric problem > -- just done > > > something a little different than EIGRP's K > values to > > > combine them into a single metric, which is > where you need > > > to be to have the ability to build a single > stable SPT/DAG. > > > > > > The theoretical grounds for this are in T. > Griffin’s and > > > Sobrinho’s work on BGP-4 and that lies > already a couple > > > of years ago and that > > > makes the analysis much ‘easier’ (no worries > about > > > np(complete) problems, > > > etc.). This could be applied in I2RS at the > routing > > > protocol level. So, we could > > > discuss where that sits (should be the > clients, right?) > > > and I don’t know if > > > that’s been already done, since I’m quite > new to this > list. > > > > > > > > > This doesn’t apply to the problem at hand, > though... You > > > seem to be saying (clarify if wrong) -- > > > > > > 1. Give each client some set of bits out of a > 128 bit number > > > space (or larger, etc.) > > > 2. Each client can have different "metrics" > within their own > > > number space > > > 3. When a client attempts to add some ephemeral > state, they > > > use a metric within their "space" > > > 4. The agent can just use the straight number as > a relative > > > priority for each potential piece of state > > > > > > This doesn't do anything different than the > current concept > > > of priority between clients, only in the current > plan each > > > client only has one priority, rather than > multiples. I don't > > > see where this relates to the problem at hand. > > > > > > Now, having “solved” that part of the > equation :-) , the > > > part that interests me > > > more is the conflicting clients problem, > because this > > > could be generalised to > > > other problem spaces in the SDN area. I do > agree that > > > agents should be able > > > to catch offending state before installing > it and I’m > > > looking for ways to specify > > > a minimal set of features that need to be > supported at > > > protocol level. > > > > > > Anyone else interested? > > > > > > > > > This is precisely where the problem lies. And > this is where > > > you're going to hit the CAP theorem in full > force. There are > > > only a few choices -- > > > > > > 1. Make the database eventually consistent > > > 2. Shut down accessibility during changes > > > 3. ?? > > > > > > (1) is the idea of either having the agent call > back to all > > > the clients when state they installed is > overwritten or > > > allowing the agent to locally store some state > where it > > > already has the information in hand and install > it locally > > > -- the only real difference between these two > solutions is > > > the "balance of complexity versus speed..." The > entire > > > discussion here is how much additional > complexity are we > > > actually adding by doing "panes of glass," which > are just > > > locally stored state which isn't currently > installed. I'm > > > arguing that there's minimal complexity added > that you're > > > not already going to have in the system to allow > the agent > > > to store information locally _if_ it chooses to. > Jeff is > > > arguing (I think) that the "panes of glass" > concept is a > > > coherent way of looking at this problem that > will help us > > > understand and manage the complexity in a way > that makes > > > sense. Joel is arguing (I think) that this sort > of solution > > > is out of the WG charter, and it's too complex. > I _think_ I > > > have the th > > > > > > r > > > ee general perspectives right, but I don't know if I > really have > > > so... :-) > > > > > > > > > (2) is the idea of locking the database while you're > > > changing it. This is explicitly outside the > scope of I2RS > > > entirely, given we're trying to design something > that's > > > atomic/restful. There are a lot of techniques > you can use to > > > speed up locking -- row locking, sharding, etc. > -- but none > > > of these are interesting from the I2RS perspective. > > > > > > :-) > > > > > > Russ > > > > > > > > > ________________________________ > > > > > > Este mensaje y sus adjuntos se dirigen > exclusivamente a su > > > destinatario, puede contener información privilegiada o > > > confidencial y es para uso exclusivo de la persona o > entidad de > > > destino. Si no es usted. el destinatario indicado, queda > > > notificado de que la lectura, utilización, > divulgación y/o copia > > > sin autorización puede estar prohibida en virtud de la > > > legislación vigente. Si ha recibido este mensaje por > error, le > > > rogamos que nos lo comunique inmediatamente por esta > misma vía y > > > proceda a su destrucción. > > > > > > The information contained in this transmission is > privileged and > > > confidential information intended only for the use > of the > > > individual or entity named above. If the reader of > this message > > > is not the intended recipient, you are hereby > notified that any > > > dissemination, distribution or copying of this > communication is > > > strictly prohibited. If you have received this > transmission in > > > error, do not read it. Please immediately reply to > the sender > > > that you have received this communication in error > and then > > > delete it. > > > > > > Esta mensagem e seus anexos se dirigem > exclusivamente ao seu > > > destinatário, pode conter informação privilegiada ou > > > confidencial e é para uso exclusivo da pessoa ou > entidade de > > > destino. Se não é vossa senhoria o destinatário > indicado, fica > > > notificado de que a leitura, utilização, divulgação > e/ou cópia > > > sem autorização pode estar proibida em virtude da > legislação > > > vigente. Se recebeu esta mensagem por erro, > rogamos-lhe que nos > > > o comunique imediatamente por esta mesma via e > proceda a sua > > > destruição > > > > > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > > https://www.ietf.org/mailman/listinfo/i2rs > > From nobody Mon Nov 30 22:11:20 2015 Return-Path: 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 CE45F1A6FD6 for ; Mon, 30 Nov 2015 22:11:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 RjszSabRMSpu for ; Mon, 30 Nov 2015 22:11:13 -0800 (PST) Received: from smtptc.telefonica.com (smtptc.telefonica.com [195.76.34.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49C7C1A6FE9 for ; Mon, 30 Nov 2015 22:11:12 -0800 (PST) Received: from smtptc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B4A213707AA; Tue, 1 Dec 2015 07:11:09 +0100 (CET) Received: from ESTGVMSP112.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtptc.telefonica.com (Postfix) with ESMTPS id 9E708370792; Tue, 1 Dec 2015 07:11:09 +0100 (CET) Received: from emea01-db3-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.93.6.54) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 1 Dec 2015 07:11:09 +0100 Received: from DB4PR06MB0639.eurprd06.prod.outlook.com (10.161.13.145) by DB4PR06MB0639.eurprd06.prod.outlook.com (10.161.13.145) with Microsoft SMTP Server (TLS) id 15.1.331.20; Tue, 1 Dec 2015 06:11:06 +0000 Received: from DB4PR06MB0639.eurprd06.prod.outlook.com ([10.161.13.145]) by DB4PR06MB0639.eurprd06.prod.outlook.com ([10.161.13.145]) with mapi id 15.01.0331.023; Tue, 1 Dec 2015 06:11:06 +0000 From: PEDRO ANDRES ARANDA GUTIERREZ To: Susan Hares , "i2rs@ietf.org" Thread-Topic: [i2rs] Conversation on Priority and Panes Thread-Index: AQHRIwm/+3O1h73j5ke4p1jGIHLAp56kkHqAgABJfACAABYNgP//88AAgARhSwCAC7uAgIAAyEOA Date: Tue, 1 Dec 2015 06:11:06 +0000 Message-ID: <5DE8FD78-5B55-4F7A-9FDD-A89A6F10F38E@telefonica.com> References: <00c501d115d0$1ae8cba0$50ba62e0$@gmail.com> <001601d115f0$a0ebb030$e2c31090$@ndzh.com> <563947F3.10805@joelhalpern.com> <00cc01d1174f$77edbf60$67c93e20$@ndzh.com> <563A97AA.5020308@joelhalpern.com> <00f301d11761$61699130$243cb390$@gmail.com> <563AA59C.4060809@joelhalpern.com> <018101d11764$66b82e50$34288af0$@gmail.com> <20151119203509.GA22415@pfrc.org> <5B54713B-CDE6-4F65-BE79-91F5B9FF3850@telefonica.com> <008d01d12390$064987c0$12dc9740$@gmail.com> <99B64F3B-20A1-4D3C-A445-46D235EDB44D@telefonica.com> <014a01d12394$ec5ffa60$c51fef20$@gmail.com> <87361DB1-DC6F-4023-A807-4003B436B472@telefonica.com> <032701d12ba3$51e0b6c0$f5a22440$@ndzh.com> In-Reply-To: <032701d12ba3$51e0b6c0$f5a22440$@ndzh.com> Accept-Language: es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151105 authentication-results: spf=none (sender IP is ) smtp.mailfrom=pedroa.aranda@telefonica.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [83.236.242.66] x-microsoft-exchange-diagnostics: 1; DB4PR06MB0639; 5:4VbvgZYjQueOZtO8UA8vpO6w/QH25/HFs184o7oKp+t2HWbt/jqwgRaeCJHHR/5x5gG0mGOGqK+OGyY1FIfCv3HHSStksVdL/fwyqGHg4BTDB/D/DPlTXxMsEXPaFfJHBfeDz2AX+0QNMfU0qEHqZg==; 24:t1YnX01NfwzkJRcW3rmJ/Zj2Qr5stHNhBLwTmBIlC+BwtKw9nJIK4hO7TVB4hv41y3p9WcqPkKPxIvdt2AEPHIYkJh6FDU+5bUG/be6+UPk= x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(42139001); SRVR:DB4PR06MB0639; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(40392960112811); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(10201501046)(3002001); SRVR:DB4PR06MB0639; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0639; x-forefront-prvs: 07778E4001 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(13464003)(59124004)(189002)(40134004)(377454003)(25724002)(54356999)(33656002)(101416001)(2900100001)(19580395003)(2950100001)(4001350100001)(5002640100001)(76176999)(81156007)(122556002)(2501003)(97736004)(82746002)(40100003)(5004730100002)(36756003)(83506001)(19580405001)(11100500001)(92566002)(5008740100001)(77096005)(66066001)(86362001)(87936001)(83716003)(1096002)(93886004)(50986999)(10400500002)(575784001)(5001960100002)(105586002)(586003)(1220700001)(3846002)(189998001)(6116002)(106356001)(106116001)(5001770100001)(102836003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB0639; H:DB4PR06MB0639.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Dec 2015 06:11:06.3525 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB0639 X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: Cc: 'Jeffrey Haas' , 'Andy Bierman' , 'Russ White' <7riw77@gmail.com> Subject: Re: [i2rs] Conversation on Priority and Panes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 06:11:19 -0000 Q2F0Y2hpbmcgdXAgbXlzZWxmIHRvb+KApg0KDQoxKSBJIHRoaW5rIEkgZGlkbuKAmXQgZ2V0IG15 IG1lc3NhZ2UgdGhyb3VnaCBXUlQgR3JpZmZpbi9Tb2JyaW5oby4gSSB3b3VsZCBjb25zdHJpY3Qg dGhhdCBraW5kIG9mIGVmZmVjdHMgdG8gdGhlIHJvdXRpbmcgcHJvdG9jb2wgKHJ1bm5pbmcgYXMg YW4gQXBwIGFuZCBzZW5kaW5nIE5FVENPTkYgY29tbWFuZHMgdG8gdGhlIGRldmljZXMgdG8gY29u ZmlndXJlIHRoZSByb3V0ZXMgaXQgY29tcHV0ZXMpLCByYXRoZXIgdGhhbiBpbmNsdWRpbmcgdGhp cyBraW5kIG9mIHByb2JsZW0gaW4gdGhlIEkyUlMgc3BhY2UuIEl0IHNlZW1zIHRvIG1lIHRoYXQg d2Ugd291bGQgYmUgdW5uZWNlc3NhcmlseSBjb21wbGljYXRpbmcgdGhlIHByb2JsZW0sICh3aGlj aCBCVFcgaXMgY29tcGxleCBlbm91Z2ggcmlnaHQgbm93KQ0KDQoyKSAgSSBzZWUgbm8gZmxhdyBp biB2MS4gSG93ZXZlciwgY29uZmxpY3QgcmVzb2x1dGlvbiBpbiBnZW5lcmFsIGlzIGEgdG9waWMg SeKAmW0gd29ya2luZyBvbiBhbmQgaWYgd29yayBvbiB2MiB3b3VsZCBpbmNsdWRlIHJlbGF0ZWQg dG9waWNzLCBJ4oCZZCBiZSBnbGFkIHRvIHRyeSB0byBjb250cmlidXRlLA0KDQpCZXN0LCAvUEEN Ci0tLQ0KRHIuIFBlZHJvIEEuIEFyYW5kYSBHdXRpw6lycmV6DQoNClRlY2hub2xvZ3kgRXhwbG9y YXRpb24gLQ0KTmV0d29yayBJbm5vdmF0aW9uICYgVmlydHVhbGlzYXRpb24NCmVtYWlsOiBwZWRy b2EgZDB0IGFyYW5kYSBBdCB0ZWxlZm9uaWNhIGQwdCBjb20NClRlbGVmw7NuaWNhLCBJbnZlc3Rp Z2FjacOzbiB5IERlc2Fycm9sbG8NCkMvIFp1cmJhcsOhbiwxMg0KMjgwMTAgTWFkcmlkLCBTcGFp bg0KDQpGcmFnZW4gc2luZCBuaWNodCBkYSwgdW0gYmVhbnR3b3J0ZXQgenUgd2VyZGVuLg0KRnJh Z2VuIHNpbmQgZGEsIHVtIGdlc3RlbGx0IHp1IHdlcmRlbi4NCkdlb3JnIEtyZWlzbGVyDQoNCg0K DQoNCg0KDQoNCg0KDQotLS0tLU1lbnNhamUgb3JpZ2luYWwtLS0tLQ0KRGU6IFN1ZSBIYXJlcyA8 c2hhcmVzQG5kemguY29tPg0KRmVjaGE6IGx1bmVzLCAzMCBkZSBub3ZpZW1icmUgZGUgMjAxNSwg MjA6MTQNClBhcmE6IHBhYWcgPHBlZHJvYS5hcmFuZGFAdGVsZWZvbmljYS5jb20+LCAnUnVzcyBX aGl0ZScgPDdyaXc3N0BnbWFpbC5jb20+LCAnSmVmZnJleSBIYWFzJyA8amhhYXNAcGZyYy5vcmc+ DQpDQzogImkycnNAaWV0Zi5vcmciIDxpMnJzQGlldGYub3JnPiwgIidKb2VsIE0uIEhhbHBlcm4n IiA8am1oQGpvZWxoYWxwZXJuLmNvbT4sICdBbmR5IEJpZXJtYW4nIDxhbmR5QHl1bWF3b3Jrcy5j b20+DQpBc3VudG86IFJFOiBbaTJyc10gQ29udmVyc2F0aW9uIG9uIFByaW9yaXR5IGFuZCBQYW5l cw0KDQo+UGVkcm86DQo+DQo+W0NhdGNoaW5nIHVwIHdpdGggbGFzdCB3ZWVrJ3MgZW1haWxdLg0K PjxXRyBjaGFpciBoYXQgb2ZmPg0KPkkgYW0gYXdhcmUgb2YgVC4gR3JpZmZpbidzIGFuZCBTb2Jy aW5obydzIHdvcmsgb24gYSBtZXRyaWMgdGhhdCBjYW4gYmUgYXBwbGllZCBhY3Jvc3MgdGhlIG5l dHdvcmsuICBJIGFtIGludGVyZXN0ZWQgdG8gc2VlIGhvdyB0aGlzIGNvdWxkIGJlIGFwcGxpZWQg dG8gSTJSUyBwcm90b2NvbC4gIENvdWxkIHlvdSBwcm92aWRlIG9mZi1saXN0IHdpdGggYW4gZXhh bXBsZSBvZiBob3cgdGhpcyBtaWdodCB3b3JrLg0KPg0KPk9uIGNvbmZsaWN0aW5nIHN0YWdlcywN Cj5DYXRjaGluZyBjb25mbGljdGluZyBzdGF0ZXMgb24gYSBjb25maWd1cmF0aW9uIGlzIHNpbmds ZSBub2RlIGhhcyBiZWVuIGRvbmUgaW4gbWFueSByb3V0ZXJzIGZvciBzeW50YXggYW5kIGZvciBj b250ZXh0LiAgSG93ZXZlciwgY2F0Y2hpbmcgY29uZmxpY3Rpbmcgc3RhdGVzIGFjcm9zcyB0aGUg bmV0d29yayBpcyBtb3JlIGRpZmZpY3VsdC4gIFBhcnRzIG9mIHRoZSBjb25maWd1cmF0aW9uIG1h eSB2YXJ5IGZyb20gcm91dGVyIHRvIHJvdXRlci4gIEZvciBleGFtcGxlLCBpZiB5b3UgZm9jdXMg b24gZmxvdyBvZiBkYXRhIHBhY2tldHMsICBZb3UgbXVzdCBoYXZlIGEgaGlnaGVyIGxldmVsIGFi c3RyYWN0aW9uIHRoYXQgdmFsaWRhdGVzIHRoZSBmbG93IG9mIGRhdGEgY29udHJvbGxlZCBieSBy b3V0ZXMgaW4gcm91dGVycywgaW50ZXJmYWNlcywgYW5kIHBvbGljeS4NCj4NCj48V0cgY2hhaXIg aGF0IG9uPg0KPkluaXRpYWwgSTJSUyB3b3JrIGV4YW1pbmVkIHNvbWUgb2YgdGhlc2UgdG9waWNz LCBidXQgd2UgYWdyZWUgdGhpcyB3b3JrIHdhcyBvdXQgb2Ygc2NvcGUgZm9yIHRoZSB2ZXJzaW9u IG9mIHRoZSBwcm90b2NvbC4gIElmIHlvdSBmZWVsIHRoZXJlIGZsYXcgaW4gb3VyIGZpcnN0IHZl cnNpb24gb2YgSTJSUywgIHBsZWFzZSBpbmRpY2F0ZSB0aGlzIHBvaW50LiAgSWYgeW91IGZlZWwg dGhpcyB0b3BpYyBzaG91bGQgYmUgYWRkcmVzc2VkIGluIGEgc2Vjb25kIHZlcnNpb24sIHBsZWFz ZSBsZXQgbWUga25vdy4NCj4NCj48V0cgQ2hhaXIgaGF0IG9mZj4NCj4NCj4NCj4tLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IFBFRFJPIEFORFJFUyBBUkFOREEgR1VUSUVSUkVaIFtt YWlsdG86cGVkcm9hLmFyYW5kYUB0ZWxlZm9uaWNhLmNvbV0NCj5TZW50OiBNb25kYXksIE5vdmVt YmVyIDIzLCAyMDE1IDI6MDQgQU0NCj5UbzogUnVzcyBXaGl0ZTsgJ0plZmZyZXkgSGFhcycNCj5D YzogaTJyc0BpZXRmLm9yZzsgJ0pvZWwgTS4gSGFscGVybic7ICdBbmR5IEJpZXJtYW4nOyAnU3Vz YW4gSGFyZXMnDQo+U3ViamVjdDogUmU6IFtpMnJzXSBDb252ZXJzYXRpb24gb24gUHJpb3JpdHkg YW5kIFBhbmVzDQo+DQo+SGksDQo+DQo+UmUgdGhlIG1ldHJpYyAncHJvYmxlbScsIGp1c3QgdG8g YmUgbW9yZSBwcmVjaXNlIGluIHdoYXQgd291bGQgYmUgbmVlZGVkLCB3ZSBhcmUgbG9va2luZyBh IG1ldHJpYyB0aGF0IGdyb3dzIG9yIGRlY3JlYXNlcyBtb25vdG9uaWNhbGx5IGFjcm9zcyB0aGUg d2hvbGUgbmV0d29yay4gVGhlIHRoZW9yZXRpY2FsIGdyb3VuZHMgZm9yIHRoaXMgYXJlIGluIFQu IEdyaWZmaW7igJlzIGFuZCBTb2JyaW5ob+KAmXMgd29yayBvbiBCR1AtNCBhbmQgdGhhdCBsaWVz IGFscmVhZHkgYSBjb3VwbGUgb2YgeWVhcnMgYWdvIGFuZCB0aGF0IG1ha2VzIHRoZSBhbmFseXNp cyBtdWNoIOKAmGVhc2llcuKAmSAobm8gd29ycmllcyBhYm91dCBucChjb21wbGV0ZSkgcHJvYmxl bXMsIGV0Yy4pLiBUaGlzIGNvdWxkIGJlIGFwcGxpZWQgaW4gSTJSUyBhdCB0aGUgcm91dGluZyBw cm90b2NvbCBsZXZlbC4gU28sIHdlIGNvdWxkIGRpc2N1c3Mgd2hlcmUgdGhhdCBzaXRzIChzaG91 bGQgYmUgdGhlIGNsaWVudHMsIHJpZ2h0PykgYW5kIEkgZG9u4oCZdCBrbm93IGlmIHRoYXTigJlz IGJlZW4gYWxyZWFkeSBkb25lLCBzaW5jZSBJ4oCZbSBxdWl0ZSBuZXcgdG8gdGhpcyBsaXN0Lg0K Pg0KPk5vdywgaGF2aW5nIOKAnHNvbHZlZOKAnSB0aGF0IHBhcnQgb2YgdGhlIGVxdWF0aW9uIDot KSAsIHRoZSBwYXJ0IHRoYXQgaW50ZXJlc3RzIG1lIG1vcmUgaXMgdGhlIGNvbmZsaWN0aW5nIGNs aWVudHMgcHJvYmxlbSwgYmVjYXVzZSB0aGlzIGNvdWxkIGJlIGdlbmVyYWxpc2VkIHRvIG90aGVy IHByb2JsZW0gc3BhY2VzIGluIHRoZSBTRE4gYXJlYS4gSSBkbyBhZ3JlZSB0aGF0IGFnZW50cyBz aG91bGQgYmUgYWJsZSB0byBjYXRjaCBvZmZlbmRpbmcgc3RhdGUgYmVmb3JlIGluc3RhbGxpbmcg aXQgYW5kIEnigJltIGxvb2tpbmcgZm9yIHdheXMgdG8gc3BlY2lmeSBhIG1pbmltYWwgc2V0IG9m IGZlYXR1cmVzIHRoYXQgbmVlZCB0byBiZSBzdXBwb3J0ZWQgYXQgcHJvdG9jb2wgbGV2ZWwuDQo+ DQo+QW55b25lIGVsc2UgaW50ZXJlc3RlZD8NCj4NCj5CUiwgL1BBDQo+LS0tDQo+RHIuIFBlZHJv IEEuIEFyYW5kYSBHdXRpw6lycmV6DQo+DQo+VGVjaG5vbG9neSBFeHBsb3JhdGlvbiAtDQo+TmV0 d29yayBJbm5vdmF0aW9uICYgVmlydHVhbGlzYXRpb24NCj5lbWFpbDogcGVkcm9hIGQwdCBhcmFu ZGEgQXQgdGVsZWZvbmljYSBkMHQgY29tIFRlbGVmw7NuaWNhLCBJbnZlc3RpZ2FjacOzbiB5IERl c2Fycm9sbG8gQy8gWnVyYmFyw6FuLDEyDQo+MjgwMTAgTWFkcmlkLCBTcGFpbg0KPg0KPkZyYWdl biBzaW5kIG5pY2h0IGRhLCB1bSBiZWFudHdvcnRldCB6dSB3ZXJkZW4uDQo+RnJhZ2VuIHNpbmQg ZGEsIHVtIGdlc3RlbGx0IHp1IHdlcmRlbi4NCj5HZW9yZyBLcmVpc2xlcg0KPg0KPg0KPg0KPg0K Pg0KPg0KPg0KPg0KPi0tLS0tTWVuc2FqZSBvcmlnaW5hbC0tLS0tDQo+RGU6IFJ1c3MgV2hpdGUg PDdyaXc3N0BnbWFpbC5jb20+DQo+RmVjaGE6IHZpZXJuZXMsIDIwIGRlIG5vdmllbWJyZSBkZSAy MDE1LCAxNDoxMQ0KPlBhcmE6IHBhYWcgPHBlZHJvYS5hcmFuZGFAdGVsZWZvbmljYS5jb20+LCAn SmVmZnJleSBIYWFzJyA8amhhYXNAcGZyYy5vcmc+DQo+Q0M6ICJpMnJzQGlldGYub3JnIiA8aTJy c0BpZXRmLm9yZz4sICInSm9lbCBNLiBIYWxwZXJuJyIgPGptaEBqb2VsaGFscGVybi5jb20+LCAn QW5keSBCaWVybWFuJyA8YW5keUB5dW1hd29ya3MuY29tPiwgU3VlIEhhcmVzIDxzaGFyZXNAbmR6 aC5jb20+DQo+QXN1bnRvOiBSRTogW2kycnNdIENvbnZlcnNhdGlvbiBvbiBQcmlvcml0eSBhbmQg UGFuZXMNCj4NCj4+DQo+Pj4gVGhlIGRhbmdlciBJIHNlZSB0aGVyZSBpcyB0aGF0IGEgc3BlY2lm aWMgcG9saWN5IGFwcGxpZWQgYnkgb25lDQo+Pj4gY2xpZW50IChhcHApIG1heSB0cmlnZ2VyIHVu aW50ZW5kZWQgY2hhbmdlcyBpbiBhIHBhcnQgb2YgdGhlICJwbGFuZXMNCj4+PiBvZiBnbGFzcyIg aXQgaXMgbm90IGF3YXJlIG9mLiBIZW5jZSBhIGZ1bGwgY29weSBpcyBuZWVkZWQgaW4gZWFjaA0K Pj4+IGNsaWVudCAoYXBwKSBtYXkgYmUgbmVlZGVk4oCmIFRoaXMgYWxzbyBob2xkcyBmb3Igc3Vi c2NyaWJpbmcgdG8gY2hhbmdlDQo+Pj4gbm90aWZpY2F0aW9ucy4gSG93IGNhbiBJIHN1YnNjcmli ZSB0byBhIGNoYW5nZSBub3RpZmljYXRpb24gb2Ygc29tZXRoaW5nIEnigJltIG5vdCBvciBJIGRv buKAmXQgd2FudCB0byBiZSBhd2FyZSBvZj8NCj4+DQo+PkkgZG9uJ3Qgc2VlIGhvdyB0aGF0J3Mg Z29pbmcgdG8gYmUgYW55IGRpZmZlcmVudCB3aGV0aGVyIHRoZSBhbHRlcm5hdGUgc3RhdGVzIGFy ZSBoZWxkIGluIHRoZSBhZ2VudCBvciBvbiB0aGUgY2xpZW50cyAtLSBlaXRoZXIgd2F5LCBkb2lu ZyAieCIgbWlnaHQgdHJpZ2dlciBzb21lIG90aGVyIGNsaWVudCB0byBkbyAieS4iIFRoZSBvbmx5 IGRpZmZlcmVuY2UgaXMgaG93IGxvbmcgaXQgdGFrZXMgZm9yIHRoZSBmaXJzdCBjbGllbnQgdG8g c2VlIHRoZSBzZWNvbmQgY2xpZW50IGRvaW5nICJ5LCIgYW5kIHRoZW4gcmVhY3RpbmcgdG8gaXQg YnkgZG9pbmcgInouIiBFdmVuIHRyeWluZyB0byBtYWtlIGNlcnRhaW4gZXZlcnkgY2xpZW50IGhh cyBhIGZ1bGwgbGlzdCBvZiBhbGwgcG9zc2libGUgY29uZGl0aW9ucyB0aGVyZSB3aWxsIHN0aWxs IGJlIHJhY2UgY29uZGl0aW9ucyBpbiB0aGUgbWl4LCBzbyB0aGF0IHdvbid0IHNvbHZlIHRoZSBw cm9ibGVtLCBlaXRoZXIuIEF0IHNvbWUgcG9pbnQsIHlvdSdyZSBnb2luZyB0byBoaXQgeW91ciBo ZWFkIGFnYWluc3QgQ0FQIC0tIGl0J3MganVzdCBhIG1hdHRlciBvZiB3aGVyZSwgd2hlbiwgYW5k IGhvdyB0byBtYW5hZ2UgaXQuDQo+Pg0KPj5UaGUgb25seSByZWFsIHNvbHV0aW9uIHRvIHRoaXMg c29ydCBvZiBwcm9ibGVtIGlzIHRvIGhhdmUgYSBkZWZpbml0aXZlIHNpbmdsZSAibWV0cmljIiB0 aGF0IHByb3ZpZGVzIGFuIGFuc3dlciB0byBldmVyeSBzaXR1YXRpb24uIEp1c3QgbGlrZSB3aXRo IGEgcm91dGluZyBwcm90b2NvbCwgeW91IGNhbid0IGJ1aWxkIGEgZGlzdHJpYnV0ZWQgc3lzdGVt IHRoYXQgdXNlcyBtb3JlIHRoYW4gb25lIG1ldHJpYyB3aXRob3V0IGVuZGluZyB1cCB3aXRoIHdl ZGdpZXMgKGhlbmNlIEJHUCkuIE1pa2UgU2hhbmQgb25jZSB0b2xkIG1lIHRoaXMgaXMgYW4gbnAo Y29tcGxldGUpIHByb2JsZW0gLS0gSSdtIGd1ZXNzaW5nIE1pa2UgaXMgcmlnaHQgb24gdGhpcyBv bmUuIEl0IHNlZW1zLCB0byBtZSwgdGhhdCB0aGlzIGlzIHByZWNpc2VseSB3aGF0IHRoZSAicHJp b3JpdHkiIGluIHRoaXMgc3lzdGVtIHByb3ZpZGVzIC0tIGluIGFueSBjYXNlLCB0aGUgY2xpZW50 IHdpdGggdGhlIGJlc3QgcHJpb3JpdHkgd2lucy4gQXMgbm8gdHdvIGNsaWVudHMgY2FuIGhhdmUg dGhlIHNhbWUgcHJpb3JpdHkgKGl0J3MgdGllZCB0byB0aGUgY2xpZW50IGlkLCBmcm9tIHdoYXQg SSByZW1lbWJlciksIGl0ICJqdXN0IHdvcmtzLiINCj4+DQo+PlRoZSBvbmUgc2l0dWF0aW9uIHlv dSBjYW4gZ2V0IGluIHRvIGlzIHdoZW4gY2xpZW50IDEgc2F5cyAiZG8geCwiIGNsaWVudCAyIHNh eXMsICJkbyB5LCIgYW5kIHlvdSBlbmQgdXAgd2l0aCBhIHJvdXRpbmcgbG9vcCBvciBjb250cmFk aWN0b3J5IHBvbGljaWVzIGFwcGxpZWQuIFRoaXMgaXMgZ29pbmcgdG8gYmUgYSBwcm9ibGVtIG5v IG1hdHRlciB3aGVyZSB0aGUgaW5mb3JtYXRpb24gaXMgc3RvcmVkLiBJIGRvbid0IHRoaW5rIHdl IGNhbiBhZGRyZXNzIHRoaXMgYXQgdGhlIHByb3RvY29sIGxldmVsIC0tIGFsbCB0aGUgcHJvdG9j b2wgY2FuIGRvIGlzIGJlIGFzIGFjY3VyYXRlIGFib3V0IGN1cnJlbnQgc3RhdGUgYXMgaXQncyBp bnN0YWxsZWQgYXMgcG9zc2libGUuIFRoZSBhZ2VudCBzaG91bGQgYmUgYWJsZSB0byBkZXRlY3Qg c29tZSBzaXR1YXRpb25zIGxpa2UgdGhpcyBhbmQgcmVmdXNlIHRvIGluc3RhbGwgdGhlIG9mZmVu ZGluZyBzdGF0ZS4gVGhlIGNsaWVudHMgbWF5IGJlIGFibGUgdG8gZGV0ZWN0IHNvbWUgb2YgdGhp cywgYXMgd2VsbCwgYW5kIGZpeCB0aGluZ3MuIEJ1dCBJIGRvbid0IHNlZSBob3cgd2UgY291bGQg c3BlY2lmeSBzdWNoIGEgdGhpbmcgaW4gdGhlIHByb3RvY29sLiBPciByYXRoZXIsIGlmIHdlIGRv LCB3aGVuIHdlJ2QgZXZlciBiZSBhYmxlIHRvIHN0b3Agc3BlY2lmeWluZyBzdWNoIHRoaW5ncy4u Lg0KPj4NCj4+Oi0pDQo+Pg0KPj5SdXNzDQo+Pg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+DQo+RXN0ZSBtZW5zYWplIHkgc3VzIGFkanVudG9zIHNlIGRpcmlnZW4gZXhj bHVzaXZhbWVudGUgYSBzdSBkZXN0aW5hdGFyaW8sIHB1ZWRlIGNvbnRlbmVyIGluZm9ybWFjacOz biBwcml2aWxlZ2lhZGEgbyBjb25maWRlbmNpYWwgeSBlcyBwYXJhIHVzbyBleGNsdXNpdm8gZGUg bGEgcGVyc29uYSBvIGVudGlkYWQgZGUgZGVzdGluby4gU2kgbm8gZXMgdXN0ZWQuIGVsIGRlc3Rp bmF0YXJpbyBpbmRpY2FkbywgcXVlZGEgbm90aWZpY2FkbyBkZSBxdWUgbGEgbGVjdHVyYSwgdXRp bGl6YWNpw7NuLCBkaXZ1bGdhY2nDs24geS9vIGNvcGlhIHNpbiBhdXRvcml6YWNpw7NuIHB1ZWRl IGVzdGFyIHByb2hpYmlkYSBlbiB2aXJ0dWQgZGUgbGEgbGVnaXNsYWNpw7NuIHZpZ2VudGUuIFNp IGhhIHJlY2liaWRvIGVzdGUgbWVuc2FqZSBwb3IgZXJyb3IsIGxlIHJvZ2Ftb3MgcXVlIG5vcyBs byBjb211bmlxdWUgaW5tZWRpYXRhbWVudGUgcG9yIGVzdGEgbWlzbWEgdsOtYSB5IHByb2NlZGEg YSBzdSBkZXN0cnVjY2nDs24uDQo+DQo+VGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlz IHRyYW5zbWlzc2lvbiBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24g aW50ZW5kZWQgb25seSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgbmFt ZWQgYWJvdmUuIElmIHRoZSByZWFkZXIgb2YgdGhpcyBtZXNzYWdlIGlzIG5vdCB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0 aW9uLCBkaXN0cmlidXRpb24gb3IgY29weWluZyBvZiB0aGlzIGNvbW11bmljYXRpb24gaXMgc3Ry aWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24g aW4gZXJyb3IsIGRvIG5vdCByZWFkIGl0LiBQbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhl IHNlbmRlciB0aGF0IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJv ciBhbmQgdGhlbiBkZWxldGUgaXQuDQo+DQo+RXN0YSBtZW5zYWdlbSBlIHNldXMgYW5leG9zIHNl IGRpcmlnZW0gZXhjbHVzaXZhbWVudGUgYW8gc2V1IGRlc3RpbmF0w6FyaW8sIHBvZGUgY29udGVy IGluZm9ybWHDp8OjbyBwcml2aWxlZ2lhZGEgb3UgY29uZmlkZW5jaWFsIGUgw6kgcGFyYSB1c28g ZXhjbHVzaXZvIGRhIHBlc3NvYSBvdSBlbnRpZGFkZSBkZSBkZXN0aW5vLiBTZSBuw6NvIMOpIHZv c3NhIHNlbmhvcmlhIG8gZGVzdGluYXTDoXJpbyBpbmRpY2FkbywgZmljYSBub3RpZmljYWRvIGRl IHF1ZSBhIGxlaXR1cmEsIHV0aWxpemHDp8OjbywgZGl2dWxnYcOnw6NvIGUvb3UgY8OzcGlhIHNl bSBhdXRvcml6YcOnw6NvIHBvZGUgZXN0YXIgcHJvaWJpZGEgZW0gdmlydHVkZSBkYSBsZWdpc2xh w6fDo28gdmlnZW50ZS4gU2UgcmVjZWJldSBlc3RhIG1lbnNhZ2VtIHBvciBlcnJvLCByb2dhbW9z LWxoZSBxdWUgbm9zIG8gY29tdW5pcXVlIGltZWRpYXRhbWVudGUgcG9yIGVzdGEgbWVzbWEgdmlh IGUgcHJvY2VkYSBhIHN1YSBkZXN0cnVpw6fDo28NCj4NCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCg0KRXN0ZSBtZW5zYWplIHkgc3VzIGFkanVudG9zIHNlIGRpcmlnZW4gZXhj bHVzaXZhbWVudGUgYSBzdSBkZXN0aW5hdGFyaW8sIHB1ZWRlIGNvbnRlbmVyIGluZm9ybWFjacOz biBwcml2aWxlZ2lhZGEgbyBjb25maWRlbmNpYWwgeSBlcyBwYXJhIHVzbyBleGNsdXNpdm8gZGUg bGEgcGVyc29uYSBvIGVudGlkYWQgZGUgZGVzdGluby4gU2kgbm8gZXMgdXN0ZWQuIGVsIGRlc3Rp bmF0YXJpbyBpbmRpY2FkbywgcXVlZGEgbm90aWZpY2FkbyBkZSBxdWUgbGEgbGVjdHVyYSwgdXRp bGl6YWNpw7NuLCBkaXZ1bGdhY2nDs24geS9vIGNvcGlhIHNpbiBhdXRvcml6YWNpw7NuIHB1ZWRl IGVzdGFyIHByb2hpYmlkYSBlbiB2aXJ0dWQgZGUgbGEgbGVnaXNsYWNpw7NuIHZpZ2VudGUuIFNp IGhhIHJlY2liaWRvIGVzdGUgbWVuc2FqZSBwb3IgZXJyb3IsIGxlIHJvZ2Ftb3MgcXVlIG5vcyBs byBjb211bmlxdWUgaW5tZWRpYXRhbWVudGUgcG9yIGVzdGEgbWlzbWEgdsOtYSB5IHByb2NlZGEg YSBzdSBkZXN0cnVjY2nDs24uDQoNClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyB0 cmFuc21pc3Npb24gaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGlu dGVuZGVkIG9ubHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IG5hbWVk IGFib3ZlLiBJZiB0aGUgcmVhZGVyIG9mIHRoaXMgbWVzc2FnZSBpcyBub3QgdGhlIGludGVuZGVk IHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlv biwgZGlzdHJpYnV0aW9uIG9yIGNvcHlpbmcgb2YgdGhpcyBjb21tdW5pY2F0aW9uIGlzIHN0cmlj dGx5IHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGlu IGVycm9yLCBkbyBub3QgcmVhZCBpdC4gUGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBz ZW5kZXIgdGhhdCB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3Ig YW5kIHRoZW4gZGVsZXRlIGl0Lg0KDQpFc3RhIG1lbnNhZ2VtIGUgc2V1cyBhbmV4b3Mgc2UgZGly aWdlbSBleGNsdXNpdmFtZW50ZSBhbyBzZXUgZGVzdGluYXTDoXJpbywgcG9kZSBjb250ZXIgaW5m b3JtYcOnw6NvIHByaXZpbGVnaWFkYSBvdSBjb25maWRlbmNpYWwgZSDDqSBwYXJhIHVzbyBleGNs dXNpdm8gZGEgcGVzc29hIG91IGVudGlkYWRlIGRlIGRlc3Rpbm8uIFNlIG7Do28gw6kgdm9zc2Eg c2VuaG9yaWEgbyBkZXN0aW5hdMOhcmlvIGluZGljYWRvLCBmaWNhIG5vdGlmaWNhZG8gZGUgcXVl IGEgbGVpdHVyYSwgdXRpbGl6YcOnw6NvLCBkaXZ1bGdhw6fDo28gZS9vdSBjw7NwaWEgc2VtIGF1 dG9yaXphw6fDo28gcG9kZSBlc3RhciBwcm9pYmlkYSBlbSB2aXJ0dWRlIGRhIGxlZ2lzbGHDp8Oj byB2aWdlbnRlLiBTZSByZWNlYmV1IGVzdGEgbWVuc2FnZW0gcG9yIGVycm8sIHJvZ2Ftb3MtbGhl IHF1ZSBub3MgbyBjb211bmlxdWUgaW1lZGlhdGFtZW50ZSBwb3IgZXN0YSBtZXNtYSB2aWEgZSBw cm9jZWRhIGEgc3VhIGRlc3RydWnDp8Ojbw0K