From nobody Wed Mar 1 01:39:51 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F26F91298AB for ; Wed, 1 Mar 2017 01:39:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com 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 vbxb8_4HoH7v for ; Wed, 1 Mar 2017 01:39:47 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0133.outbound.protection.outlook.com [104.47.1.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 017A81298A3 for ; Wed, 1 Mar 2017 01:39:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=TNxD39Rf+pzHWkGkmhlPS81VG1RZT+riT3thlZ6+W2k=; b=ViPMa+eTf4NgCQjvakX5WySXW6YV+M19T6k+Lri0Jxmu/qliVIVBtfiqHPQuSNSRd75YbHs3FjN2mS0qIVofkhJoqI9X5phCrOBqlnShfKu3GRbp3ZlHvXqVh9LmFioOw7a84fIHRZZ9l8vLIOrFEQq1fcufRESDxvgPYeV0wIY= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.185.203.75) by HE1PR0701MB2761.eurprd07.prod.outlook.com (10.168.188.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.2; Wed, 1 Mar 2017 09:39:43 +0000 Message-ID: <01ed01d2926f$5a1de720$4001a8c0@gateway.2wire.net> From: t.petch To: routing WG , Stewart Bryant References: <148821563731.21121.441798485413773688.idtracker@ietfa.amsl.com> <492085d7-d2ba-f2ac-80ea-67ffee013041@gmail.com> <054601d291b4$6e249e00$4001a8c0@gateway.2wire.net> <176fc859-9349-2f09-34ea-ef63adf8d547@gmail.com> <011b01d291e7$0a19c6a0$4001a8c0@gateway.2wire.net> Subject: Re: New Version Notification for draft-bryant-rtgwg-param-sync-01.txt Date: Wed, 1 Mar 2017 09:36:41 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.185.203.75] X-ClientProxiedBy: DB6PR0202CA0037.eurprd02.prod.outlook.com (10.171.70.23) To HE1PR0701MB2761.eurprd07.prod.outlook.com (10.168.188.143) X-MS-Office365-Filtering-Correlation-Id: a6329110-1eee-4014-6e28-08d46086e49b X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:HE1PR0701MB2761; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB2761; 3:kSB2yON8Wx9FZOB9ZIPPSbo7AeuVAyc7qIuxIWXhNCByzAdB6sD5ER7M5p9j8CFhm6X7AfDRjhIhccLrQpSG58wbLBfHSQTJij32xLzEAcaNv4mmF+jNjZAIPN0PqHpmH02fHMX1NjAivibvz8C6GukgwNO4zYtML0sJNvEWgSG/tbN5KHU1D0u+n+iSs7osfmtmmYfzdyboetTbIFMRjElvL4YZYkCudQS8iBt5IAPmJNSM0SiKJBmJLe11oO/wC5Hs9e0a97gA+MUdXDNCtQ==; 25:AZRhicBU3DMy7FyLxQh0yQDvyBAkfKVKVdorNU0gf9yGNA/GSJOMn7/0U6L6SDWDenOq595NN1HNM0L14Nkt4uSGe5uU7xkun9+BfxkOIYE4dxuOy0xNVUyXeVf5YttLC1YpmixR93RFQYZSN9VgZCqDNi0lBbBe6w7nWRjQtpiG3LQ18CgVj7VlnTABFJJMJc/iawCA7Sc8mbEfbF5y2eWksTJjJae3vjTZAgUieTBEq4pKmS+bIfEDr6ePqD8RKZEEmQHjpqcc42PNJNrvCGAf85S/kyphVTD8gwfknE0WwJG3LzVPvwyRgoQGQFFSxROzNT5wnm5OIFXmRtKi4RU0iTcduYozPU3GL2HGtuZTil5DX/ehXVpEszf/1tdymBqvjd9oswc2uPJpMUbsZ2M9nV4LI6jOHMNw0DuxXAt4bHEUXZSly9XbRe0fdGYf18s/H7znkoEV9vCeSnERaA== X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB2761; 31:ZV/TWs3YvAWZZ23Ksq2N+2mg3LUuhgizjrDZ18XG2JaN6D6gPfLnQ6sHGafJSyJOVMBhLXn1h5vwOTVAKpVsSXdYprINUWZfM8Qz+O+C3MJXigd4LYUSShhhmHEOacY4xAtiGXqG6XeQ7FpSBPQqR4CuxbGyPy2I9ZxNZ6RCdBXLUpeh8ECAMbYqII+fuppfmtsXiNL9C18o/aH9zmsIDoKPTcBMgsknl7AlWFM9x8eQBLBLstYC0Kl8wgITXEdr23HESpGK7ha0wke4PhXC/A== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105)(192374486261705); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(20161123558025)(6072148); SRVR:HE1PR0701MB2761; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2761; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB2761; 4:5f8O80yV+ukZnqayE6DPqTEjtrvMlB5TEMt3VnP/93wINtx9DV+JjLMLBJnsyViR1ThBqc0e3uvyE3Cx6pmKoHElayJ5ymHxaYwC5bvh+nEjS1DZMltcSlecOAcR2t5YZpBplSlthjetFnJiDKRcnXpkwavvePW//jrUOlZNpK9u3AKIxSGOlH5eZA90fzELqhUgI5v6WTCobOKw4VRpuGufn1uW07teou+pKwHLX/dN0JefD9W0E6BoreV/4wBtNsPWLpqtJ0Dw3P9bttFhJHe5DhWyNirjkVEYnUM1HB7rxnqlqDE7wiilo0paXd8NP9sbKUPRuLjDGui1ccm0SIn0W3ZtyOzXW3owL03SX3KZAclKkQjeHJS5wUHetIx8zHxaI8m3h3camSLo0JuEr2UL2e6ULQJDDD5KVxzXfaoyIEfRp3bNe1DrM/4IQSUFsV9XoeqNSJewrNv/haIAZUinBTFvAbVEUGgbV8urYR78CY3WXomshvyJxsdJVJ4ZeGtvBfZJy6yGL0W64MpxCL7nLKp1LIJgyX6sxSlCYQD+uEmAMYy6Pyqg3MoHmNgdx9Jgk8AaxJp1gRVNFmnm7y1vTQXdJQ7m2lmYsFawGS+xNJJy1JzmUpoBVUnmJdPUhvHINrxq+MoqVXnrRhEdjykVLbE9b7coCZWrmemCP4OGOLv8YFm0lEYcu/LVM9eN X-Forefront-PRVS: 0233768B38 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(39450400003)(24454002)(13464003)(377454003)(8676002)(93886004)(25786008)(6486002)(230700001)(116806002)(50226002)(6246003)(6496005)(53546006)(38730400002)(6116002)(50466002)(81816999)(81686999)(50986999)(76176999)(3846002)(23746002)(229853002)(6306002)(53936002)(1556002)(9686003)(1456003)(44736005)(14496001)(61296003)(15650500001)(5890100001)(189998001)(81166006)(42186005)(84392002)(7736002)(4720700003)(47776003)(33646002)(305945005)(62236002)(2906002)(5660300001)(92566002)(230783001)(66066001)(86362001)(44716002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB2761; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; HE1PR0701MB2761; 23:sCHuZEyZgF5ij0TMgYbHGcEIY6f+vGMKUft?= =?Windows-1252?Q?6kTp6OxspX5WzNcUc8Dm/rwN5jEjHNP/rPuzlVjFhYD9rJhZOYI2V5gb?= =?Windows-1252?Q?pYfiqxyX8Wc4ICpJrJn9he0gyCoBXcYMGQ90TcFBDhtR+KhZPyhz2d6x?= =?Windows-1252?Q?T2J1X1SJj1u2eFZTbF2La21d5R6dMq0AZipv8rbX5IaGuZ5o+l+6Gkh4?= =?Windows-1252?Q?ic4f37a16ObbyIjbq/T02q8118Za1x72pQILgsPG2aHrcNnuPwgBivGL?= =?Windows-1252?Q?cpduwi1oIIoptDFPlLZNoQNbcR3C4zM8mz95KtUOGVvPbz0vSXYI8ALu?= =?Windows-1252?Q?vL6IFyzO1oJlnuYGqzs5XlIoH/AkmRkRC6q/a9mw3D7vx2rXgqQz2FMw?= =?Windows-1252?Q?GpRjm5pavFf7wZ7mLUesBiXlP7YYFR6owIG4I41/3Nl3s5r/e2RMVY6W?= =?Windows-1252?Q?Z52aWuwBz7T17vrcndHuSmlr0uzjarGH7agz3C7vtpk6R0lCQF1quQ/m?= =?Windows-1252?Q?V3FvfrIV5KpoICYcW9dX5sMCptuUcNw931Ckw03epUmizg58g7Wvaebb?= =?Windows-1252?Q?9YFa6LMQ3fS/nZOaRtvENWUwhkgY/wv+d+xjsVVZBuIWN8quNhyrMFvT?= =?Windows-1252?Q?FohDLpYQzkJApoGngIF+2s+V5O7b51gB5R3ihmpLSmUgWXIOnlpFVEOI?= =?Windows-1252?Q?SXmyW4QglTpPmLzpA58pbRwCTtfuYF1+6fcCealYoYV+bPOSuzeE98tV?= =?Windows-1252?Q?Hvg62ZTD5doc1QC/rO046ZzLCJTuzCLc2nIoCKo4CKcEt3LIOHFuQeSC?= =?Windows-1252?Q?Bu73/SgzV8gYqDHXutGd+tQAsj73c6H4Q+Nx2fp9VA7ZzdzA1laFjoX4?= =?Windows-1252?Q?GtB4X/6NOokdPfAZHCpFHfjiZs7lXuHN5rrtbx43wT9/y4iVF+gO4Noj?= =?Windows-1252?Q?RcbqwNvYpcSbDv/I7tMQGebR3jM3NK6LEfj6LfMzA7XZp9I4/HTS9Dvc?= =?Windows-1252?Q?d9m1WZG2Je09pFXS18BXVgh5K2hHNU0qQMnNawpnq0AKleWLuBGG4zZ8?= =?Windows-1252?Q?PwNLTmR6Z5oViAy2jF+oHmSCQRG2pd6N4iqeDR1lM/gvalGAujiMPLXI?= =?Windows-1252?Q?qc7CUx8heLiuDO2ZZisLEUPDghaBuBCFmaK6BX5bPFC8hHtwWXYMNu3G?= =?Windows-1252?Q?48JHu9jzAGmg71//UVjgRfY9DFvV4VrzFAwTTBMODPr0FA2jx8o8m4HM?= =?Windows-1252?Q?k6QrVMqkagxULIsfqVadPJq4S67GGDAd4sZMSfqMSUtWcRCbX1yOlVvb?= =?Windows-1252?Q?3L6J4etpGdP/4v/GgNwXGSB/NSRiCr0jmXBy2wJVyNcfjglpbpnX8qNN?= =?Windows-1252?Q?s1ac/IVTYE6KXvga5WNzBh/3HUDZD1Xw82ENeTJzD1QI14Y19+XwUxmW?= =?Windows-1252?Q?qDJvA9s02QrF3gpS4mvCN?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB2761; 6:Up7TLQlmwzzPS0J7vKxWcLaxU5b9iz2u2zaK04NjkxvnZ23iUSh9fnUdXzkNNvrZANWvBIfbR3hE0hNKKEoXp8fjoWEuE2VteT0+BnRA0CAPrQ/nI50SVkww78/eaHTIJ/B9uR1LIYdMgKl5Am8L9x0r2cN9ZVJUdM2Se7QRrH3mHZcBFTGkIwawcAYRh4z4KmysqO4hBnTaw6extLJCjHqg57JrqsS6WZX9TsDWCJp45RNkLeC2jWWWTUzKZvGg+bHRagMb4Bou2JADOPhIoFR4uajW2PhZ8fgJHrqklhKBPtkLIsphYqXex7Ftzg7aVVcE7gZdU46aBnP324P7gO+w5tckoOJtaaC609NfvfFq+1juNLQ2+W3FTR0wpv0aBsvs3zezhWHrHe0nZAbQiA==; 5:B5SfVLG2B1jjpnaNNCZ99wmA7YtRtwQpTy7qkW77Zj7+RZams3sAnrGTqinRpZR7Nyha/zkn7zqvzWVq9r5Kxr+toomGQnJw4fjqo1DSrJxYdEHK6+HrH9oBsQmFIUN6gcRRX4dFmIB4nEAi24IGQghSj3jvO2ZBp2XXvscOB5U=; 24:9rik+kcG4cIv/U8low/BSeqolb/6hfq8mwDHRorJs8hs6OrJAwyp6ixyJbZRarnb6RQhNEBNH3HW/oYg0N/oU4M2eirELthCMyOc1G75ERg= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB2761; 7:qkZjVHOhr+tORxO18pgz+C5422OU9zMi+Lx3bFIumCht+parODRptS3Hx5O+9KtpPIIJ44UPEM7dJkMSd7/xgABx/L2XBukNTfmzELlKX96QOKbvImFAaHO7pQGHHpV6h7DpgnhzBsSUcx4gVs0kyP0F9dd/5qFy87enWGavY4LGkupTyiL4mgZPmXRGi/jj/30Y1WQMQYsmgAdYN12ALomlf+lQHOtysvaCQto0G8/6RTD1OtP86ZO0I3R2075CMC33M7hp30fGbVtF6gh2Hc3SZzpDFt8lAGqpYI52L2zhZQhfzGdEuCTQe9KGxjLt33spv3apQ+ThZwrIYLpDXA== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Mar 2017 09:39:43.8634 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2761 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 09:39:50 -0000 ----- Original Message ----- From: "Stewart Bryant" Sent: Tuesday, February 28, 2017 7:19 PM > On 28/02/2017 17:20, t.petch wrote: > > ----- Original Message ----- > > From: "Stewart Bryant" > > Sent: Tuesday, February 28, 2017 11:48 AM > > > >> Hi Tom > >> > >> The intent is clear in the rest of the text. > >> > >> This was an oversight in the editing. > >> > >> How about "Network Wide Routing Parameter Registry"? > > Stewart > > > > I would like it to start with 'Routing ...' since that makes it appear > > where I expect to find it in the (flat and very long) IANA parameter > > list. > > > > Routing Parameter Network Wide Registry perhaps > > > > Clumsier I know but I am attached to an initial Routing which collates > > it alongside RIP, RPL and such like. > > Horribly clumsy! It does not scan at all. > > Maybe Routing Parameter Synchronization Registry? > > ... but isn't this in the weeds when we are still at the adoption stag? Weelll I am thinking ahead to what might come next:-) I see MPLS as a good example of how not to think ahead and set up an IANA registry that then costs a lot of time and effort to put right at a later date. Yes, that is how the IETF does things but it is still a waste of scarce resources. My first thought on seeing the registry name was that it was misleading and yes, you agree to change it. My second thought was that there must be a 'Routing ...' Group in IANA under which your original name would be fine since the Gropu name would limit the scope. But no, I see no sign of a 'Routing ..' Group so perhaps now is the time to create one. I do support adoption of the I-D by the way. Tom Petch > - Stewart > > > > > > > Tom Petch > > > >> - Stewart > >> > >> On 28/02/2017 10:54, t.petch wrote: > >>> Stewart > >>> > >>> You say that this protocol is only intended to be used for the > >>> propagation of > >>> parameters needed to support the operation of the routing system but > > the > >>> registry you create is named > >>> Network Wide Parameter Registry > >>> which to me still carries the message that this is all embracing, > > not > >>> just for routing. > >>> > >>> Tom Petch > >>> > >>> ----- Original Message ----- > >>> From: "Stewart Bryant" > >>> Sent: Monday, February 27, 2017 5:23 PM > >>> > >>>> Resend with correct ISIS WG email address > >>>> > >>>> Following discussion at the last IETF, I have made a number > >>>> of changes to the text to emphasis that this protocols > >>>> is only to be used for the synchronization of parameters needs > >>>> by the routing system. > >>>> > >>>> As agreed at the RTGWG meeting I am notifying RTGWG, ISIS and OSPF > >>> WGs. > >>>> The draft can be found here: > >>>> > >>>> URL: > >>>> > > https://www.ietf.org/internet-drafts/draft-bryant-rtgwg-param-sync-01.tx > >>> t > >>>> Status: > >>>> https://datatracker.ietf.org/doc/draft-bryant-rtgwg-param-sync/ > >>>> Htmlized: > >>> https://tools.ietf.org/html/draft-bryant-rtgwg-param-sync-01 > >>>> Diff: > >>>> https://www.ietf.org/rfcdiff?url2=draft-bryant-rtgwg-param-sync-01 > >>>> > >>>> The following is a summary of the changed: > >>>> > >>>> I have changed the title to: > >>>> > >>>> Synchronisation of Routing Parameters > >>>> > >>>> ========= > >>>> > >>>> I have added in the introduction: > >>>> > >>>> Note that this protocol is only intended to be used for the > >>> propagation of > >>>> parameters needed to support the operation of the routing system. > > It > >>>> MUST NOT > >>>> be used as a general purpose parameter exchange protocol, and in > >>>> particular it > >>>> MUST NOT be used as a parameter negotiation protocol, since such > > use > >>> may > >>>> degrade the ability of the underlying link-state routing protocol > > to > >>>> carry our > >>>> its essential purpose. > >>>> > >>>> ======== > >>>> > >>>> I have changed the IANA text to say: > >>>> > >>>> Synchronisation of Routing Parameters > >>>> > >>>> ======== > >>>> > >>>> I have added to the security section: > >>>> > >>>> In specifying a new parameter, consideration must be given > >>>> to the impact of the additional parameter, and in particular the > >>>> rate of change of that parameter, on the dynamics of the link-state > >>>> routing protocol in use. In the specific case of the > >>>> Convergence Timer, the amount of data being carried and the > >>>> rate of change of the parameter value will have a negligible > >>>> impact on the link-state routing protocol in use. > >>>> > >>>> ========= > >>>> > >>>> Incorporated a number of review suggestions by Mohamed Boucadair > > (Mod) > >>>> Added > >>>> > >>>> Such consistency may be ensured by deploying automated > >>>> means such as enforcing the new value by invoking the > >>>> management interface of all involved routers. For example, > >>>> a central management entity may be responsible for > >>>> communicating the new configuration value by means of > >>>> vendor-specific CLI, NETCONF, etc. This approach may be > >>>> attracting if all involved nodes expose technology-agnostic > >>>> and vendor-independent interfaces to tweak a given network-wide > >>>> configuration parameter. > >>>> > >>>> ====== > >>>> > >>>> I would like to propose that we move this forward to become a WG > > draft > >>>> and refine the detail under the WG process. > >>>> > >>>> - Stewart > >>>> > >>>> _______________________________________________ > >>>> rtgwg mailing list > >>>> rtgwg@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/rtgwg > From nobody Wed Mar 1 08:33:35 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC911295C9; Wed, 1 Mar 2017 08:33:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 yqmQCsyyejC1; Wed, 1 Mar 2017 08:33:32 -0800 (PST) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::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 9A3FB1294CF; Wed, 1 Mar 2017 08:33:31 -0800 (PST) Received: by mail-wr0-x233.google.com with SMTP id g10so34042672wrg.2; Wed, 01 Mar 2017 08:33:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Z05CVFSbxb+LESuE3c8uxldkIXBMe6QaY5W8hF+plrI=; b=HO2hYDD77MPML0LwhblFNxp6+/rXmt6dhzsrDMp2g2uBUYY/EoCLO5LGdFiBp+UuQc w5kcXvI6aCI/FWv/yd9xqO1PbtoYV1YHLc63eeWuvMUm8XP0OgatcsR+IuNTcW/691vX EfK1IzcdMCOXnbF5DP54d9LSjpLJgWDEyDpRw4n58O0W/G1tciqthEYM3XumkXw1y5EN Pb6pew/EwI/PXQk1sYfsiACHswKYqvABglJXEzW1HF2lzqQPD/CPLk7T4Unb7TF1WtBt 5b9gMKffMV5Io2Z+4c7CHV/oh8yV0cSGROsYD/YV/iaZDn7neTnr5GMPHmsKLiPdjF5z eBKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Z05CVFSbxb+LESuE3c8uxldkIXBMe6QaY5W8hF+plrI=; b=GUF0+Qez74s2tkxIYsi3wvRnmZ7nDIcQKyzITRiA21zNoiCma0FQUI7k4nb6wscAJJ v9RxW4GLWSpFVrd9LDumKbVtITuLR7lgffoUIghrQpMcvCXSI5jYFgoXqr/229ZrZizV bSHaIWpebyP3Y6o3p2Nc3MoyAKJ0EGEQlVWBSXYLSYbLVaiAjy7fTJ82PCOc8C8VJZmY kQ4xf57Dsd1JPX9m3sPHlMbLUw9KI3ce1Mo38UzRUKMlxloWS8wmqn/NM0tgSI8mVwEG RAAW8wOuURzUz/MLZRuJB6SVpbe7XjoFbxvqqQE6S4hZsMSe3c61IaEhRwbS9QBN0zTL D/WQ== X-Gm-Message-State: AMke39kBlO5iFtecctmMoZTADplFSBw/THFomIe4a0TTSc8KteWFINKe4AX0lFhSFjF1qk383odklRbIfqGWSA== X-Received: by 10.223.136.4 with SMTP id d4mr8193452wrd.44.1488386009765; Wed, 01 Mar 2017 08:33:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.145.5 with HTTP; Wed, 1 Mar 2017 08:33:29 -0800 (PST) In-Reply-To: References: <148821563731.21121.441798485413773688.idtracker@ietfa.amsl.com> <492085d7-d2ba-f2ac-80ea-67ffee013041@gmail.com> From: Alia Atlas Date: Wed, 1 Mar 2017 11:33:29 -0500 Message-ID: Subject: RE: [Isis-wg] New Version Notification for draft-bryant-rtgwg-param-sync-01.txt To: "Les Ginsberg (ginsberg)" Content-Type: multipart/alternative; boundary=001a11461d1866baf30549addfaa Archived-At: Cc: OSPF List , "rtgwg-chairs@ietf.org" , "isis-wg@ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 16:33:34 -0000 --001a11461d1866baf30549addfaa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Feb 28, 2017 10:55 PM, "Les Ginsberg (ginsberg)" wrote: Alia =E2=80=93 Thanx for reminding about the MRT drafts (and so quickly J). Both seem to have expired. :-) The base MRT drafts have been published as RFCs. The MRT LDP extensions is past WGLC now. The ISIS and OSPF MRT drafts have been waiting for the outcome of this discussion. I don=E2=80=99t see the connection between extending the use cases for a convergence time advertisement beyond MRT and the need for encapsulating other unrelated parameters into a single container. Right - it's not clear to me whether there is going to be a finding/use issue with the convergence time advertisement if published as part of the MRT drafts. I am interested to see if there are additional parameters that would make sense to be in the single container. Regards, Alia Les *From:* Isis-wg [mailto:isis-wg-bounces@ietf.org] *On Behalf Of *Alia Atlas *Sent:* Tuesday, February 28, 2017 7:43 PM *To:* Les Ginsberg (ginsberg) *Cc:* isis-wg@ietf.org; rtgwg-chairs@ietf.org; internet-drafts@ietf.org; ospf@ietf.org; rtgwg@ietf.org *Subject:* Re: [Isis-wg] New Version Notification for draft-bryant-rtgwg-param-sync-01.txt Hi Les, I will note that the MRT ISIS and OSPF drafts include the extension for convergence time. I believe this draft was motivated by a concern that those extensions would not be seen and realized to be generally useful. Regards, Alia On Tue, Feb 28, 2017 at 10:35 PM, Les Ginsberg (ginsberg) < ginsberg@cisco.com> wrote: Stewart - This draft discusses two things: 1)You propose to advertise "convergence time" so that routers utilizing a form of FRR can determine when it is safe to start utilizing the post convergence path. All this requires is advertisement of a value and definition of how routers in the network should make use of this value - specifically use the maximum advertised value as the lower bound for how long a repair path should continue to be used. This proposal deserves to be discussed on its own merits - something I will NOT do in this email. 2)Rather than simply define the new advertisement as (for example) a new sub-TLV in IS-IS Router Capability TLV, you have decided that there is "general class of problem" that needs to be addressed and so you have invented a "routing parameter synchronization protocol". This proposes to "encapsulate" the above parameter and some yet to be defined set of future parameters in a common container- suggesting we will have a large number of such parameters in the future and that they have some logical relationship. I find this proposal unnecessary and undesirable. I do not see any value add to encapsulating multiple parameters which are otherwise unrelated in a common container simply because there may be some algorithm (unique to each parameter) which needs to be applied when making use of each parameter. If your concern is consumption of sub-TLV codepoints in IS-IS, it is worth reviewing the current status. RFC 4971 which originally defined the Router Capability TLV was published in 2007. Over the nearly 10 years in which this has been available there have been 21 codepoints assigned. There are two or three more that I am aware of that are in the works, so in 10 years we will have consumed less than 10% of the available codepoints. I am quite comfortable with this rate of consumption. If you believe there is about to be an explosion of code point requests I wish you would be more forthcoming as to what you expect as it would then be appropriate to consider whether this set of candidates is an appropriate use of the routing protocol and the Router Capability TLV. My recommendation is to write a draft confined to the definition of the new convergence time parameter you wish to advertise and let us review that on its own merits. Les > -----Original Message----- > From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Stewart Bryant > Sent: Monday, February 27, 2017 9:23 AM > To: internet-drafts@ietf.org; Chris Bowers; Alia Atlas; rtgwg@ietf.org; rtgwg- > chairs@ietf.org; isis-wg@ietf.org; ospf@ietf.org > Subject: Re: New Version Notification for draft-bryant-rtgwg-param-sync- > 01.txt > > Resend with correct ISIS WG email address > > Following discussion at the last IETF, I have made a number of changes to the > text to emphasis that this protocols is only to be used for the synchronization > of parameters needs by the routing system. > > As agreed at the RTGWG meeting I am notifying RTGWG, ISIS and OSPF WGs. > > The draft can be found here: > > URL: > https://www.ietf.org/internet-drafts/draft-bryant-rtgwg-param-sync-01.txt > Status: > https://datatracker.ietf.org/doc/draft-bryant-rtgwg-param-sync/ > Htmlized: https://tools.ietf.org/html/d raft-bryant-rtgwg-param-sync-01 > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-bryant-rtgwg-param-sync-01 > > The following is a summary of the changed: > > I have changed the title to: > > Synchronisation of Routing Parameters > > =3D=3D=3D=3D=3D=3D=3D=3D=3D > > I have added in the introduction: > > Note that this protocol is only intended to be used for the propagation o= f > parameters needed to support the operation of the routing system. It MUST > NOT be used as a general purpose parameter exchange protocol, and in > particular it MUST NOT be used as a parameter negotiation protocol, since > such use may degrade the ability of the underlying link-state routing protocol > to carry our its essential purpose. > > =3D=3D=3D=3D=3D=3D=3D=3D > > I have changed the IANA text to say: > > Synchronisation of Routing Parameters > > =3D=3D=3D=3D=3D=3D=3D=3D > > I have added to the security section: > > In specifying a new parameter, consideration must be given to the impact of > the additional parameter, and in particular the rate of change of that > parameter, on the dynamics of the link-state routing protocol in use. In the > specific case of the Convergence Timer, the amount of data being carried and > the rate of change of the parameter value will have a negligible impact on the > link-state routing protocol in use. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D > > Incorporated a number of review suggestions by Mohamed Boucadair (Mod) > > Added > > Such consistency may be ensured by deploying automated means such as > enforcing the new value by invoking the management interface of all > involved routers. For example, a central management entity may be > responsible for communicating the new configuration value by means of > vendor-specific CLI, NETCONF, etc. This approach may be attracting if all > involved nodes expose technology-agnostic and vendor-independent > interfaces to tweak a given network-wide configuration parameter. > > =3D=3D=3D=3D=3D=3D > > I would like to propose that we move this forward to become a WG draft an= d > refine the detail under the WG process. > > - Stewart > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg --001a11461d1866baf30549addfaa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Feb 28, 2017 10:55 PM, "Les Ginsberg (ginsberg)&q= uot; <ginsberg@c= isco.com> wrote:

Alia =E2=80=93<= /u>

=C2=A0

Thanx for reminding about= the MRT drafts (and so quickly J). Both seem to have expired.


:-) =C2=A0 The base MRT drafts have been published as RFCs.=C2= =A0 The MRT LDP extensions is past WGLC now.
The ISIS and OSPF MRT drafts have been waiting for the out= come of this discussion.=C2=A0

<= div lang=3D"EN-US" link=3D"blue" vlink=3D"purple">

I don=E2=80=99t see the connection between extending the use cases for a= convergence time advertisement beyond MRT and the need for encapsulating o= ther unrelated parameters into a single container.

=

Right - it's not clear to me whether the= re is going to be a finding/use issue with the convergence time advertiseme= nt if published as part of the MRT drafts.=C2=A0 I am interested to see if = there are additional parameters that would make sense to be in the single c= ontainer.

<= /span>
Regards,
Alia

=C2=A0

=C2=A0=C2=A0 Les

=C2=A0

From: Isis-wg = [mailto:isis-= wg-bounces@ietf.org] On Behalf Of Alia Atlas
Sent: Tuesday, February 28, 2017 7:43 PM
To: Les Ginsberg (ginsberg)
Cc: isis-wg@ie= tf.org; rtgw= g-chairs@ietf.org; internet-drafts@ietf.org; ospf@ietf.org; rtgwg@ietf.org
Subject: Re: [Isis-wg] New Version Notification for draft-bryant-rtg= wg-param-sync-01.txt

=C2=A0

Hi Les,

=C2=A0

I will note that the MRT ISIS and OSPF drafts includ= e the extension for convergence time.

I believe this draft was motivated by a concern that= those extensions would not be seen and

realized to be generally useful.

=C2=A0

Regards,

Alia

=C2=A0

On Tue, Feb 28, 2017 at 10:35 PM, Les Ginsberg (gins= berg) <ginsberg@= cisco.com> wrote:

Stewart -

This draft discusses two things:

1)You propose to advertise "convergence time" so that routers uti= lizing a form of FRR can determine when it is safe to start utilizing the p= ost convergence path. All this requires is advertisement of a value and def= inition of how routers in the network should make use of this value - specifically use the maximum advertised value as = the lower bound for how long a repair path should continue to be used.

This proposal deserves to be discussed on its own merits - something I will= NOT do in this email.

2)Rather than simply define the new advertisement as (for example) a new su= b-TLV in IS-IS Router Capability TLV, you have decided that there is "= general class of problem" that needs to be addressed and so you have i= nvented a "routing parameter synchronization protocol". This proposes to "encapsulate" the above paramet= er and some yet to be defined set of future parameters in a common containe= r- suggesting we will have a large number of such parameters in the future = and that they have some logical relationship.

I find this proposal unnecessary and undesirable. I do not see any value ad= d to encapsulating multiple parameters which are otherwise unrelated in a c= ommon container simply because there may be some algorithm (unique to each = parameter) which needs to be applied when making use of each parameter.

If your concern is consumption of sub-TLV codepoints in IS-IS, it is worth = reviewing the current status. RFC 4971 which originally defined the Router = Capability TLV was published in 2007. Over the nearly 10 years in which thi= s has been available there have been 21 codepoints assigned. There are two or three more that I am aware o= f that are in the works, so in 10 years we will have consumed less than 10%= of the available codepoints. I am quite comfortable with this rate of cons= umption.

If you believe there is about to be an explosion of code point requests I w= ish you would be more forthcoming as to what you expect as it would then be= appropriate to consider whether this set of candidates is an appropriate u= se of the routing protocol and the Router Capability TLV.

My recommendation is to write a draft confined to the definition of the new= convergence time parameter you wish to advertise and let us review that on= its own merits.

=C2=A0 = =C2=A0Les


> -----Original Message-----
> From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Stewart Bryant > Sent: Monday, February 27, 2017 9:23 AM
> To: inte= rnet-drafts@ietf.org; Chris Bowers; Alia Atlas; rtgwg@ietf.org; rtg= wg-
> chairs@ietf.org; isis-wg@ietf.org; os= pf@ietf.org
> Subject: Re: New Version Notification for draft-bryant-rtgwg-param-syn= c-
> 01.txt
>
> Resend with correct ISIS WG email address
>
> Following discussion at the last IETF, I have made a number of changes= to the
> text to emphasis that this protocols is only to be used for the synchr= onization
> of parameters needs by the routing system.
>
> As agreed at the RTGWG meeting I am notifying RTGWG, ISIS and OSPF WGs= .
>
> The draft can be found here:
>
> URL:
> https://www.ietf.org/internet-drafts/draft-bryant-rtgwg-param-syn= c-01.txt
> Status:
> https://datatracker.ietf.org/doc/draft-bryant-rtgwg-param-sync/
> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf= .org/html/draft-bryant-rtgwg-param-sync-01
> Diff:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-bryant-rtgwg-param-sync= -01
>
> The following is a summary of the changed:
>
> I have changed the title to:
>
> Synchronisation of Routing Parameters
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> I have added in the introduction:
>
> Note that this protocol is only intended to be used for the propagatio= n of
> parameters needed to support the operation of the routing system. It M= UST
> NOT be used as a general purpose parameter exchange protocol, and in > particular it MUST NOT be used as a parameter negotiation protocol, si= nce
> such use may degrade the ability of the underlying link-state routing = protocol
> to carry our its essential purpose.
>
> =3D=3D=3D=3D=3D=3D=3D=3D
>
> I have changed the IANA text to say:
>
> Synchronisation of Routing Parameters
>
> =3D=3D=3D=3D=3D=3D=3D=3D
>
> I have added to the security section:
>
> In specifying a new parameter, consideration must be given to the impa= ct of
> the additional parameter, and in particular the rate of change of that=
> parameter, on the dynamics of the link-state routing protocol in use. = In the
> specific case of the Convergence Timer, the amount of data being carri= ed and
> the rate of change of the parameter value will have a negligible impac= t on the
> link-state routing protocol in use.
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> Incorporated a number of review suggestions by Mohamed Boucadair (Mod)=
>
> Added
>
> Such consistency may be ensured by deploying automated means such as > enforcing the new value by invoking the management interface of all > involved routers. For example, a central management entity may be
> responsible for communicating the new configuration value by means of<= br> > vendor-specific CLI, NETCONF, etc. This approach may be attracting if = all
> involved nodes expose technology-agnostic and vendor-independent
> interfaces to tweak a given network-wide configuration parameter.
>
> =3D=3D=3D=3D=3D=3D
>
> I would like to propose that we move this forward to become a WG draft= and
> refine the detail under the WG process.
>
> - Stewart
>

> __________________________________________= _____
> rtgwg mailing list
> rtgwg@ietf.org=
> https://www.ietf.org/mailman/listinfo/rtgwg

=C2=A0



--001a11461d1866baf30549addfaa-- From nobody Wed Mar 1 08:47:19 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C57571295F5; Wed, 1 Mar 2017 08:47:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 J4ro59e0PwD8; Wed, 1 Mar 2017 08:47:09 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72FEF129550; Wed, 1 Mar 2017 08:47:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=40764; q=dns/txt; s=iport; t=1488386829; x=1489596429; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=VtauxKpvPZoMJ9osMvKDCe/BoJJ6HuoiCRTqTdoqZWI=; b=LcNRaZUQIJtZ0mi7/znuzLjx8VOT9a1/xuTEAaLAoKNuV2aXclkNN6S7 IHI2CqGQSksCZM+jpoLi23knsYRQFplC4w1VeVRaWjor7S7+LgBLze3lN HMJkoJwv2lHYWAHDlDBJSoZjI+4I8dVzLoQ3EPpA+LJGDCITpkAgg6KXv Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DeAQCw+bZY/5pdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm45KWGBCQeDVIoIkWaIDI0pggoDHwEMhXYCGoIfPxgBAgEBAQE?= =?us-ascii?q?BAQFiKIRwAQEBBAEBIQo6BwQFAgUHBAIBCA4DBAEBIQEGAwICAh8GCxQJCAIED?= =?us-ascii?q?gUIAYlYAxUOsWKCJoc3DYNeAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYZMhG+CUUa?= =?us-ascii?q?BDxEBMx+CUIJfBYkPiBCKTzoBhnSHFIQgkSeKTYhnAR84eQhUFRgmhk11AYdDg?= =?us-ascii?q?SGBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,226,1484006400"; d="scan'208,217";a="392062760" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Mar 2017 16:47:07 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v21Gl7nC023510 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 1 Mar 2017 16:47:07 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 1 Mar 2017 10:47:07 -0600 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1210.000; Wed, 1 Mar 2017 10:47:07 -0600 From: "Les Ginsberg (ginsberg)" To: Alia Atlas Subject: RE: [Isis-wg] New Version Notification for draft-bryant-rtgwg-param-sync-01.txt Thread-Topic: [Isis-wg] New Version Notification for draft-bryant-rtgwg-param-sync-01.txt Thread-Index: AQHSkqmypXo9bMhZw0SICF+vzWz5TqGAL1RA Date: Wed, 1 Mar 2017 16:47:07 +0000 Message-ID: <618323e0db7c4aca9a7e25410fb9153b@XCH-ALN-001.cisco.com> References: <148821563731.21121.441798485413773688.idtracker@ietfa.amsl.com> <492085d7-d2ba-f2ac-80ea-67ffee013041@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.106.250] Content-Type: multipart/alternative; boundary="_000_618323e0db7c4aca9a7e25410fb9153bXCHALN001ciscocom_" MIME-Version: 1.0 Archived-At: Cc: OSPF List , "rtgwg-chairs@ietf.org" , "isis-wg@ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 16:47:13 -0000 --_000_618323e0db7c4aca9a7e25410fb9153bXCHALN001ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWxpYSAtDQoNCkZyb206IEFsaWEgQXRsYXMgW21haWx0bzpha2F0bGFzQGdtYWlsLmNvbV0NClNl bnQ6IFdlZG5lc2RheSwgTWFyY2ggMDEsIDIwMTcgODozMyBBTQ0KVG86IExlcyBHaW5zYmVyZyAo Z2luc2JlcmcpDQpDYzogT1NQRiBMaXN0OyBpc2lzLXdnQGlldGYub3JnOyBydGd3Zy1jaGFpcnNA aWV0Zi5vcmc7IHJ0Z3dnQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW0lzaXMtd2ddIE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtYnJ5YW50LXJ0Z3dnLXBhcmFtLXN5bmMtMDEudHh0 DQoNCg0KT24gRmViIDI4LCAyMDE3IDEwOjU1IFBNLCAiTGVzIEdpbnNiZXJnIChnaW5zYmVyZyki IDxnaW5zYmVyZ0BjaXNjby5jb208bWFpbHRvOmdpbnNiZXJnQGNpc2NvLmNvbT4+IHdyb3RlOg0K QWxpYSDigJMNCg0KVGhhbnggZm9yIHJlbWluZGluZyBhYm91dCB0aGUgTVJUIGRyYWZ0cyAoYW5k IHNvIHF1aWNrbHkg4pi6KS4gQm90aCBzZWVtIHRvIGhhdmUgZXhwaXJlZC4NCg0KOi0pICAgVGhl IGJhc2UgTVJUIGRyYWZ0cyBoYXZlIGJlZW4gcHVibGlzaGVkIGFzIFJGQ3MuICBUaGUgTVJUIExE UCBleHRlbnNpb25zIGlzIHBhc3QgV0dMQyBub3cuDQpUaGUgSVNJUyBhbmQgT1NQRiBNUlQgZHJh ZnRzIGhhdmUgYmVlbiB3YWl0aW5nIGZvciB0aGUgb3V0Y29tZSBvZiB0aGlzIGRpc2N1c3Npb24u DQoNCkkgZG9u4oCZdCBzZWUgdGhlIGNvbm5lY3Rpb24gYmV0d2VlbiBleHRlbmRpbmcgdGhlIHVz ZSBjYXNlcyBmb3IgYSBjb252ZXJnZW5jZSB0aW1lIGFkdmVydGlzZW1lbnQgYmV5b25kIE1SVCBh bmQgdGhlIG5lZWQgZm9yIGVuY2Fwc3VsYXRpbmcgb3RoZXIgdW5yZWxhdGVkIHBhcmFtZXRlcnMg aW50byBhIHNpbmdsZSBjb250YWluZXIuDQoNClJpZ2h0IC0gaXQncyBub3QgY2xlYXIgdG8gbWUg d2hldGhlciB0aGVyZSBpcyBnb2luZyB0byBiZSBhIGZpbmRpbmcvdXNlIGlzc3VlIHdpdGggdGhl IGNvbnZlcmdlbmNlIHRpbWUgYWR2ZXJ0aXNlbWVudCBpZiBwdWJsaXNoZWQgYXMgcGFydCBvZiB0 aGUgTVJUIGRyYWZ0cy4gIEkgYW0gaW50ZXJlc3RlZCB0byBzZWUgaWYgdGhlcmUgYXJlIGFkZGl0 aW9uYWwgcGFyYW1ldGVycyB0aGF0IHdvdWxkIG1ha2Ugc2Vuc2UgdG8gYmUgaW4gdGhlIHNpbmds ZSBjb250YWluZXIuDQoNCltMZXM6XSBJbiB0aGUgSUFOQSByZWdpc3RyeSB0aGVyZSBpcyBBTFdB WVMgYSBsaW5rIHRvIHRoZSBkZWZpbmluZyBzcGVjaWZpY2F0aW9uIGZvciBldmVyeSBjb2RlcG9p bnQuDQoNCg0KaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9pc2lzLXRsdi1jb2RlcG9p bnRzL2lzaXMtdGx2LWNvZGVwb2ludHMueGh0bWwjaXNpcy10bHYtY29kZXBvaW50cy0yNDINCg0K VGhlcmUgaXMgbm8gcmVhc29uIHdoeSB3ZSBuZWVkIHdvcnJ5IGFib3V0IGhvdyB0byBmaW5kIHRo ZSBzb3VyY2UgZm9yIGEgZGVmaW5pdGlvbi4NCkhvd2V2ZXIsIGlmIHRoZSBjb252ZXJnZW5jZSBh ZHZlcnRpc2VtZW50IGlzIHNlZW4gYXMgaGF2aW5nIG1vcmUgd2lkZXNwcmVhZCB1c2UsIHRoZW4g cGVyaGFwcyBpdCBpcyBiZXR0ZXIgdG8gaGF2ZSBhIHN0YW5kYWxvbmUgZHJhZnQgZm9yIGl0Lg0K Tm90ZSB0aGF0IEkgaGF2ZSBjb25jZXJucyBhYm91dCB0aGUgY29udmVyZ2VuY2UgYWR2ZXJ0aXNl bWVudCDigJMgYnV0IEkgd291bGQgcmF0aGVyIGRpc2N1c3MgdGhhdCBpbiBhIHNlcGFyYXRlIHRo cmVhZC4gSGVyZSB3ZSBhcmUgZGlzY3Vzc2luZyBkcmFmdC1icnlhbnQtcnRnd2ctcGFyYW0tc3lu Yy0wMSBhbmQgdGhlIG5lZWQgZm9yIGEgZ2VuZXJpYyAicm91dGluZyBwYXJhbWV0ZXIgc3luY2hy b25pemF0aW9uIHByb3RvY29sIi4gTGlrZSB0byBzZWUgdXMgcmVhY2ggY29uY2x1c2lvbiBvbiB0 aGF0IGlzc3VlIGluIHRoaXMgdGhyZWFkLg0KDQogICBMZXMNCg0KUmVnYXJkcywNCkFsaWENCg0K DQogICBMZXMNCg0KRnJvbTogSXNpcy13ZyBbbWFpbHRvOmlzaXMtd2ctYm91bmNlc0BpZXRmLm9y ZzxtYWlsdG86aXNpcy13Zy1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEFsaWEgQXRs YXMNClNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDI4LCAyMDE3IDc6NDMgUE0NClRvOiBMZXMgR2lu c2JlcmcgKGdpbnNiZXJnKQ0KQ2M6IGlzaXMtd2dAaWV0Zi5vcmc8bWFpbHRvOmlzaXMtd2dAaWV0 Zi5vcmc+OyBydGd3Zy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOnJ0Z3dnLWNoYWlyc0BpZXRmLm9y Zz47IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnPjsgb3NwZkBpZXRmLm9yZzxtYWlsdG86b3NwZkBpZXRmLm9yZz47IHJ0Z3dnQGlldGYub3Jn PG1haWx0bzpydGd3Z0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbSXNpcy13Z10gTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1icnlhbnQtcnRnd2ctcGFyYW0tc3luYy0wMS50eHQN Cg0KSGkgTGVzLA0KDQpJIHdpbGwgbm90ZSB0aGF0IHRoZSBNUlQgSVNJUyBhbmQgT1NQRiBkcmFm dHMgaW5jbHVkZSB0aGUgZXh0ZW5zaW9uIGZvciBjb252ZXJnZW5jZSB0aW1lLg0KSSBiZWxpZXZl IHRoaXMgZHJhZnQgd2FzIG1vdGl2YXRlZCBieSBhIGNvbmNlcm4gdGhhdCB0aG9zZSBleHRlbnNp b25zIHdvdWxkIG5vdCBiZSBzZWVuIGFuZA0KcmVhbGl6ZWQgdG8gYmUgZ2VuZXJhbGx5IHVzZWZ1 bC4NCg0KUmVnYXJkcywNCkFsaWENCg0KT24gVHVlLCBGZWIgMjgsIDIwMTcgYXQgMTA6MzUgUE0s IExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpIDxnaW5zYmVyZ0BjaXNjby5jb208bWFpbHRvOmdpbnNi ZXJnQGNpc2NvLmNvbT4+IHdyb3RlOg0KU3Rld2FydCAtDQoNClRoaXMgZHJhZnQgZGlzY3Vzc2Vz IHR3byB0aGluZ3M6DQoNCjEpWW91IHByb3Bvc2UgdG8gYWR2ZXJ0aXNlICJjb252ZXJnZW5jZSB0 aW1lIiBzbyB0aGF0IHJvdXRlcnMgdXRpbGl6aW5nIGEgZm9ybSBvZiBGUlIgY2FuIGRldGVybWlu ZSB3aGVuIGl0IGlzIHNhZmUgdG8gc3RhcnQgdXRpbGl6aW5nIHRoZSBwb3N0IGNvbnZlcmdlbmNl IHBhdGguIEFsbCB0aGlzIHJlcXVpcmVzIGlzIGFkdmVydGlzZW1lbnQgb2YgYSB2YWx1ZSBhbmQg ZGVmaW5pdGlvbiBvZiBob3cgcm91dGVycyBpbiB0aGUgbmV0d29yayBzaG91bGQgbWFrZSB1c2Ug b2YgdGhpcyB2YWx1ZSAtIHNwZWNpZmljYWxseSB1c2UgdGhlIG1heGltdW0gYWR2ZXJ0aXNlZCB2 YWx1ZSBhcyB0aGUgbG93ZXIgYm91bmQgZm9yIGhvdyBsb25nIGEgcmVwYWlyIHBhdGggc2hvdWxk IGNvbnRpbnVlIHRvIGJlIHVzZWQuDQoNClRoaXMgcHJvcG9zYWwgZGVzZXJ2ZXMgdG8gYmUgZGlz Y3Vzc2VkIG9uIGl0cyBvd24gbWVyaXRzIC0gc29tZXRoaW5nIEkgd2lsbCBOT1QgZG8gaW4gdGhp cyBlbWFpbC4NCg0KMilSYXRoZXIgdGhhbiBzaW1wbHkgZGVmaW5lIHRoZSBuZXcgYWR2ZXJ0aXNl bWVudCBhcyAoZm9yIGV4YW1wbGUpIGEgbmV3IHN1Yi1UTFYgaW4gSVMtSVMgUm91dGVyIENhcGFi aWxpdHkgVExWLCB5b3UgaGF2ZSBkZWNpZGVkIHRoYXQgdGhlcmUgaXMgImdlbmVyYWwgY2xhc3Mg b2YgcHJvYmxlbSIgdGhhdCBuZWVkcyB0byBiZSBhZGRyZXNzZWQgYW5kIHNvIHlvdSBoYXZlIGlu dmVudGVkIGEgInJvdXRpbmcgcGFyYW1ldGVyIHN5bmNocm9uaXphdGlvbiBwcm90b2NvbCIuIFRo aXMgcHJvcG9zZXMgdG8gImVuY2Fwc3VsYXRlIiB0aGUgYWJvdmUgcGFyYW1ldGVyIGFuZCBzb21l IHlldCB0byBiZSBkZWZpbmVkIHNldCBvZiBmdXR1cmUgcGFyYW1ldGVycyBpbiBhIGNvbW1vbiBj b250YWluZXItIHN1Z2dlc3Rpbmcgd2Ugd2lsbCBoYXZlIGEgbGFyZ2UgbnVtYmVyIG9mIHN1Y2gg cGFyYW1ldGVycyBpbiB0aGUgZnV0dXJlIGFuZCB0aGF0IHRoZXkgaGF2ZSBzb21lIGxvZ2ljYWwg cmVsYXRpb25zaGlwLg0KDQpJIGZpbmQgdGhpcyBwcm9wb3NhbCB1bm5lY2Vzc2FyeSBhbmQgdW5k ZXNpcmFibGUuIEkgZG8gbm90IHNlZSBhbnkgdmFsdWUgYWRkIHRvIGVuY2Fwc3VsYXRpbmcgbXVs dGlwbGUgcGFyYW1ldGVycyB3aGljaCBhcmUgb3RoZXJ3aXNlIHVucmVsYXRlZCBpbiBhIGNvbW1v biBjb250YWluZXIgc2ltcGx5IGJlY2F1c2UgdGhlcmUgbWF5IGJlIHNvbWUgYWxnb3JpdGhtICh1 bmlxdWUgdG8gZWFjaCBwYXJhbWV0ZXIpIHdoaWNoIG5lZWRzIHRvIGJlIGFwcGxpZWQgd2hlbiBt YWtpbmcgdXNlIG9mIGVhY2ggcGFyYW1ldGVyLg0KDQpJZiB5b3VyIGNvbmNlcm4gaXMgY29uc3Vt cHRpb24gb2Ygc3ViLVRMViBjb2RlcG9pbnRzIGluIElTLUlTLCBpdCBpcyB3b3J0aCByZXZpZXdp bmcgdGhlIGN1cnJlbnQgc3RhdHVzLiBSRkMgNDk3MSB3aGljaCBvcmlnaW5hbGx5IGRlZmluZWQg dGhlIFJvdXRlciBDYXBhYmlsaXR5IFRMViB3YXMgcHVibGlzaGVkIGluIDIwMDcuIE92ZXIgdGhl IG5lYXJseSAxMCB5ZWFycyBpbiB3aGljaCB0aGlzIGhhcyBiZWVuIGF2YWlsYWJsZSB0aGVyZSBo YXZlIGJlZW4gMjEgY29kZXBvaW50cyBhc3NpZ25lZC4gVGhlcmUgYXJlIHR3byBvciB0aHJlZSBt b3JlIHRoYXQgSSBhbSBhd2FyZSBvZiB0aGF0IGFyZSBpbiB0aGUgd29ya3MsIHNvIGluIDEwIHll YXJzIHdlIHdpbGwgaGF2ZSBjb25zdW1lZCBsZXNzIHRoYW4gMTAlIG9mIHRoZSBhdmFpbGFibGUg Y29kZXBvaW50cy4gSSBhbSBxdWl0ZSBjb21mb3J0YWJsZSB3aXRoIHRoaXMgcmF0ZSBvZiBjb25z dW1wdGlvbi4NCg0KSWYgeW91IGJlbGlldmUgdGhlcmUgaXMgYWJvdXQgdG8gYmUgYW4gZXhwbG9z aW9uIG9mIGNvZGUgcG9pbnQgcmVxdWVzdHMgSSB3aXNoIHlvdSB3b3VsZCBiZSBtb3JlIGZvcnRo Y29taW5nIGFzIHRvIHdoYXQgeW91IGV4cGVjdCBhcyBpdCB3b3VsZCB0aGVuIGJlIGFwcHJvcHJp YXRlIHRvIGNvbnNpZGVyIHdoZXRoZXIgdGhpcyBzZXQgb2YgY2FuZGlkYXRlcyBpcyBhbiBhcHBy b3ByaWF0ZSB1c2Ugb2YgdGhlIHJvdXRpbmcgcHJvdG9jb2wgYW5kIHRoZSBSb3V0ZXIgQ2FwYWJp bGl0eSBUTFYuDQoNCk15IHJlY29tbWVuZGF0aW9uIGlzIHRvIHdyaXRlIGEgZHJhZnQgY29uZmlu ZWQgdG8gdGhlIGRlZmluaXRpb24gb2YgdGhlIG5ldyBjb252ZXJnZW5jZSB0aW1lIHBhcmFtZXRl ciB5b3Ugd2lzaCB0byBhZHZlcnRpc2UgYW5kIGxldCB1cyByZXZpZXcgdGhhdCBvbiBpdHMgb3du IG1lcml0cy4NCg0KICAgTGVzDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogcnRnd2cgW21haWx0bzpydGd3Zy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpydGd3Zy1ib3Vu Y2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIFN0ZXdhcnQgQnJ5YW50DQo+IFNlbnQ6IE1vbmRh eSwgRmVicnVhcnkgMjcsIDIwMTcgOToyMyBBTQ0KPiBUbzogaW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+OyBDaHJpcyBCb3dlcnM7IEFsaWEg QXRsYXM7IHJ0Z3dnQGlldGYub3JnPG1haWx0bzpydGd3Z0BpZXRmLm9yZz47IHJ0Z3dnLQ0KPiBj aGFpcnNAaWV0Zi5vcmc8bWFpbHRvOmNoYWlyc0BpZXRmLm9yZz47IGlzaXMtd2dAaWV0Zi5vcmc8 bWFpbHRvOmlzaXMtd2dAaWV0Zi5vcmc+OyBvc3BmQGlldGYub3JnPG1haWx0bzpvc3BmQGlldGYu b3JnPg0KPiBTdWJqZWN0OiBSZTogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1i cnlhbnQtcnRnd2ctcGFyYW0tc3luYy0NCj4gMDEudHh0DQo+DQo+IFJlc2VuZCB3aXRoIGNvcnJl Y3QgSVNJUyBXRyBlbWFpbCBhZGRyZXNzDQo+DQo+IEZvbGxvd2luZyBkaXNjdXNzaW9uIGF0IHRo ZSBsYXN0IElFVEYsIEkgaGF2ZSBtYWRlIGEgbnVtYmVyIG9mIGNoYW5nZXMgdG8gdGhlDQo+IHRl eHQgdG8gZW1waGFzaXMgdGhhdCB0aGlzIHByb3RvY29scyBpcyBvbmx5IHRvIGJlIHVzZWQgZm9y IHRoZSBzeW5jaHJvbml6YXRpb24NCj4gb2YgcGFyYW1ldGVycyBuZWVkcyBieSB0aGUgcm91dGlu ZyBzeXN0ZW0uDQo+DQo+IEFzIGFncmVlZCBhdCB0aGUgUlRHV0cgbWVldGluZyBJIGFtIG5vdGlm eWluZyBSVEdXRywgSVNJUyBhbmQgT1NQRiBXR3MuDQo+DQo+IFRoZSBkcmFmdCBjYW4gYmUgZm91 bmQgaGVyZToNCj4NCj4gVVJMOg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtYnJ5YW50LXJ0Z3dnLXBhcmFtLXN5bmMtMDEudHh0DQo+IFN0YXR1czoNCj4gaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYnJ5YW50LXJ0Z3dnLXBhcmFtLXN5 bmMvDQo+IEh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt YnJ5YW50LXJ0Z3dnLXBhcmFtLXN5bmMtMDENCj4gRGlmZjoNCj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvcmZjZGlmZj91cmwyPWRyYWZ0LWJyeWFudC1ydGd3Zy1wYXJhbS1zeW5jLTAxDQo+DQo+IFRo ZSBmb2xsb3dpbmcgaXMgYSBzdW1tYXJ5IG9mIHRoZSBjaGFuZ2VkOg0KPg0KPiBJIGhhdmUgY2hh bmdlZCB0aGUgdGl0bGUgdG86DQo+DQo+IFN5bmNocm9uaXNhdGlvbiBvZiBSb3V0aW5nIFBhcmFt ZXRlcnMNCj4NCj4gPT09PT09PT09DQo+DQo+IEkgaGF2ZSBhZGRlZCBpbiB0aGUgaW50cm9kdWN0 aW9uOg0KPg0KPiBOb3RlIHRoYXQgdGhpcyBwcm90b2NvbCBpcyBvbmx5IGludGVuZGVkIHRvIGJl IHVzZWQgZm9yIHRoZSBwcm9wYWdhdGlvbiBvZg0KPiBwYXJhbWV0ZXJzIG5lZWRlZCB0byBzdXBw b3J0IHRoZSBvcGVyYXRpb24gb2YgdGhlIHJvdXRpbmcgc3lzdGVtLiBJdCBNVVNUDQo+IE5PVCBi ZSB1c2VkIGFzIGEgZ2VuZXJhbCBwdXJwb3NlIHBhcmFtZXRlciBleGNoYW5nZSBwcm90b2NvbCwg YW5kIGluDQo+IHBhcnRpY3VsYXIgaXQgTVVTVCBOT1QgYmUgdXNlZCBhcyBhIHBhcmFtZXRlciBu ZWdvdGlhdGlvbiBwcm90b2NvbCwgc2luY2UNCj4gc3VjaCB1c2UgbWF5IGRlZ3JhZGUgdGhlIGFi aWxpdHkgb2YgdGhlIHVuZGVybHlpbmcgbGluay1zdGF0ZSByb3V0aW5nIHByb3RvY29sDQo+IHRv IGNhcnJ5IG91ciBpdHMgZXNzZW50aWFsIHB1cnBvc2UuDQo+DQo+ID09PT09PT09DQo+DQo+IEkg aGF2ZSBjaGFuZ2VkIHRoZSBJQU5BIHRleHQgdG8gc2F5Og0KPg0KPiBTeW5jaHJvbmlzYXRpb24g b2YgUm91dGluZyBQYXJhbWV0ZXJzDQo+DQo+ID09PT09PT09DQo+DQo+IEkgaGF2ZSBhZGRlZCB0 byB0aGUgc2VjdXJpdHkgc2VjdGlvbjoNCj4NCj4gSW4gc3BlY2lmeWluZyBhIG5ldyBwYXJhbWV0 ZXIsIGNvbnNpZGVyYXRpb24gbXVzdCBiZSBnaXZlbiB0byB0aGUgaW1wYWN0IG9mDQo+IHRoZSBh ZGRpdGlvbmFsIHBhcmFtZXRlciwgYW5kIGluIHBhcnRpY3VsYXIgdGhlIHJhdGUgb2YgY2hhbmdl IG9mIHRoYXQNCj4gcGFyYW1ldGVyLCBvbiB0aGUgZHluYW1pY3Mgb2YgdGhlIGxpbmstc3RhdGUg cm91dGluZyBwcm90b2NvbCBpbiB1c2UuIEluIHRoZQ0KPiBzcGVjaWZpYyBjYXNlIG9mIHRoZSBD b252ZXJnZW5jZSBUaW1lciwgdGhlIGFtb3VudCBvZiBkYXRhIGJlaW5nIGNhcnJpZWQgYW5kDQo+ IHRoZSByYXRlIG9mIGNoYW5nZSBvZiB0aGUgcGFyYW1ldGVyIHZhbHVlIHdpbGwgaGF2ZSBhIG5l Z2xpZ2libGUgaW1wYWN0IG9uIHRoZQ0KPiBsaW5rLXN0YXRlIHJvdXRpbmcgcHJvdG9jb2wgaW4g dXNlLg0KPg0KPiA9PT09PT09PT0NCj4NCj4gSW5jb3Jwb3JhdGVkIGEgbnVtYmVyIG9mIHJldmll dyBzdWdnZXN0aW9ucyBieSBNb2hhbWVkIEJvdWNhZGFpciAoTW9kKQ0KPg0KPiBBZGRlZA0KPg0K PiBTdWNoIGNvbnNpc3RlbmN5IG1heSBiZSBlbnN1cmVkIGJ5IGRlcGxveWluZyBhdXRvbWF0ZWQg bWVhbnMgc3VjaCBhcw0KPiBlbmZvcmNpbmcgdGhlIG5ldyB2YWx1ZSBieSBpbnZva2luZyB0aGUg bWFuYWdlbWVudCBpbnRlcmZhY2Ugb2YgYWxsDQo+IGludm9sdmVkIHJvdXRlcnMuIEZvciBleGFt cGxlLCBhIGNlbnRyYWwgbWFuYWdlbWVudCBlbnRpdHkgbWF5IGJlDQo+IHJlc3BvbnNpYmxlIGZv ciBjb21tdW5pY2F0aW5nIHRoZSBuZXcgY29uZmlndXJhdGlvbiB2YWx1ZSBieSBtZWFucyBvZg0K PiB2ZW5kb3Itc3BlY2lmaWMgQ0xJLCBORVRDT05GLCBldGMuIFRoaXMgYXBwcm9hY2ggbWF5IGJl IGF0dHJhY3RpbmcgaWYgYWxsDQo+IGludm9sdmVkIG5vZGVzIGV4cG9zZSB0ZWNobm9sb2d5LWFn bm9zdGljIGFuZCB2ZW5kb3ItaW5kZXBlbmRlbnQNCj4gaW50ZXJmYWNlcyB0byB0d2VhayBhIGdp dmVuIG5ldHdvcmstd2lkZSBjb25maWd1cmF0aW9uIHBhcmFtZXRlci4NCj4NCj4gPT09PT09DQo+ DQo+IEkgd291bGQgbGlrZSB0byBwcm9wb3NlIHRoYXQgd2UgbW92ZSB0aGlzIGZvcndhcmQgdG8g YmVjb21lIGEgV0cgZHJhZnQgYW5kDQo+IHJlZmluZSB0aGUgZGV0YWlsIHVuZGVyIHRoZSBXRyBw cm9jZXNzLg0KPg0KPiAtIFN0ZXdhcnQNCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gcnRnd2cgbWFpbGluZyBsaXN0DQo+IHJ0Z3dnQGlldGYu b3JnPG1haWx0bzpydGd3Z0BpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9ydGd3Zw0KDQoNCg== --_000_618323e0db7c4aca9a7e25410fb9153bXCHALN001ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJ bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0K CWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLm0tNzQ3NzYzNTQ3NTc1 NzE0MDk2Mm0tMzEyNDk3MTk0MjEwOTI3MTU0OWhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTptXy03 NDc3NjM1NDc1NzU3MTQwOTYybV8tMzEyNDk3MTk0MjEwOTI3MTU0OWhvZW56Yjt9DQpzcGFuLkVt YWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29u VGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1m YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QWxpYSAtPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEFsaWEgQXRsYXMgW21haWx0 bzpha2F0bGFzQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE1hcmNo IDAxLCAyMDE3IDg6MzMgQU08YnI+DQo8Yj5Ubzo8L2I+IExlcyBHaW5zYmVyZyAoZ2luc2Jlcmcp PGJyPg0KPGI+Q2M6PC9iPiBPU1BGIExpc3Q7IGlzaXMtd2dAaWV0Zi5vcmc7IHJ0Z3dnLWNoYWly c0BpZXRmLm9yZzsgcnRnd2dAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtJc2lz LXdnXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWJyeWFudC1ydGd3Zy1wYXJh bS1zeW5jLTAxLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZlYiAyOCwgMjAxNyAxMDo1NSBQTSwgJnF1b3Q7TGVzIEdp bnNiZXJnIChnaW5zYmVyZykmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpnaW5zYmVyZ0BjaXNj by5jb20iIHRhcmdldD0iX2JsYW5rIj5naW5zYmVyZ0BjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QWxpYSDigJM8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5UaGFueCBmb3IgcmVtaW5kaW5nIGFib3V0IHRoZSBNUlQgZHJhZnRzIChhbmQgc28gcXVp Y2tseQ0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5Oldp bmdkaW5ncztjb2xvcjojMUY0OTdEIj5KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4pLiBCb3RoIHNlZW0gdG8gaGF2ZSBleHBpcmVkLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjotKSAmbmJzcDsgVGhlIGJhc2UgTVJUIGRy YWZ0cyBoYXZlIGJlZW4gcHVibGlzaGVkIGFzIFJGQ3MuJm5ic3A7IFRoZSBNUlQgTERQIGV4dGVu c2lvbnMgaXMgcGFzdCBXR0xDIG5vdy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+VGhlIElTSVMgYW5kIE9TUEYgTVJUIGRyYWZ0cyBoYXZlIGJlZW4gd2FpdGlu ZyBmb3IgdGhlIG91dGNvbWUgb2YgdGhpcyBkaXNjdXNzaW9uLiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBkb27igJl0 IHNlZSB0aGUgY29ubmVjdGlvbiBiZXR3ZWVuIGV4dGVuZGluZyB0aGUgdXNlIGNhc2VzIGZvciBh IGNvbnZlcmdlbmNlIHRpbWUgYWR2ZXJ0aXNlbWVudCBiZXlvbmQNCiBNUlQgYW5kIHRoZSBuZWVk IGZvciBlbmNhcHN1bGF0aW5nIG90aGVyIHVucmVsYXRlZCBwYXJhbWV0ZXJzIGludG8gYSBzaW5n bGUgY29udGFpbmVyLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5SaWdodCAtIGl0J3Mgbm90IGNsZWFyIHRvIG1lIHdoZXRoZXIg dGhlcmUgaXMgZ29pbmcgdG8gYmUgYSBmaW5kaW5nL3VzZSBpc3N1ZSB3aXRoIHRoZSBjb252ZXJn ZW5jZSB0aW1lIGFkdmVydGlzZW1lbnQgaWYgcHVibGlzaGVkIGFzIHBhcnQgb2YgdGhlIE1SVCBk cmFmdHMuJm5ic3A7DQogSSBhbSBpbnRlcmVzdGVkIHRvIHNlZSBpZiB0aGVyZSBhcmUgYWRkaXRp b25hbCBwYXJhbWV0ZXJzIHRoYXQgd291bGQgbWFrZSBzZW5zZSB0byBiZSBpbiB0aGUgc2luZ2xl IGNvbnRhaW5lci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltMZXM6XSBJbiB0aGUg SUFOQSByZWdpc3RyeSB0aGVyZSBpcyBBTFdBWVMgYSBsaW5rIHRvIHRoZSBkZWZpbmluZyBzcGVj aWZpY2F0aW9uIGZvciBldmVyeSBjb2RlcG9pbnQuPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PGEgaHJlZj0iaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9pc2lzLXRsdi1j b2RlcG9pbnRzL2lzaXMtdGx2LWNvZGVwb2ludHMueGh0bWwjaXNpcy10bHYtY29kZXBvaW50cy0y NDIiPmh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvaXNpcy10bHYtY29kZXBvaW50cy9p c2lzLXRsdi1jb2RlcG9pbnRzLnhodG1sI2lzaXMtdGx2LWNvZGVwb2ludHMtMjQyPC9hPjxvOnA+ PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZXJlIGlzIG5vIHJlYXNvbiB3aHkg d2UgbmVlZCB3b3JyeSBhYm91dCBob3cgdG8gZmluZCB0aGUgc291cmNlIGZvciBhIGRlZmluaXRp b24uPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SG93ZXZlciwg aWYgdGhlIGNvbnZlcmdlbmNlIGFkdmVydGlzZW1lbnQgaXMgc2VlbiBhcyBoYXZpbmcgbW9yZSB3 aWRlc3ByZWFkIHVzZSwgdGhlbiBwZXJoYXBzIGl0IGlzIGJldHRlciB0byBoYXZlIGEgc3RhbmRh bG9uZSBkcmFmdCBmb3IgaXQuPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Tm90ZSB0aGF0IEkgaGF2ZSBjb25jZXJucyBhYm91dCB0aGUgY29udmVyZ2VuY2UgYWR2 ZXJ0aXNlbWVudCDigJMgYnV0IEkgd291bGQgcmF0aGVyIGRpc2N1c3MgdGhhdCBpbiBhIHNlcGFy YXRlIHRocmVhZC4gSGVyZSB3ZSBhcmUgZGlzY3Vzc2luZyBkcmFmdC1icnlhbnQtcnRnd2ctcGFy YW0tc3luYy0wMQ0KIGFuZCB0aGUgbmVlZCBmb3IgYSBnZW5lcmljICZxdW90O3JvdXRpbmcgcGFy YW1ldGVyIHN5bmNocm9uaXphdGlvbiBwcm90b2NvbCZxdW90Oy4gTGlrZSB0byBzZWUgdXMgcmVh Y2ggY29uY2x1c2lvbiBvbiB0aGF0IGlzc3VlIGluIHRoaXMgdGhyZWFkLjxvOnA+PC9vOnA+PC9z cGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv aT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBMZXM8bzpwPjwvbzpwPjwvc3Bh bj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+QWxpYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDsmbmJzcDsgTGVzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiBJc2lzLXdnIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmlzaXMtd2ctYm91bmNlc0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlzaXMtd2ctYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8 Yj5PbiBCZWhhbGYgT2YgPC9iPkFsaWEgQXRsYXM8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwg RmVicnVhcnkgMjgsIDIwMTcgNzo0MyBQTTxicj4NCjxiPlRvOjwvYj4gTGVzIEdpbnNiZXJnIChn aW5zYmVyZyk8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzppc2lzLXdnQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+aXNpcy13Z0BpZXRmLm9yZzwvYT47DQo8YSBocmVmPSJtYWlsdG86 cnRnd2ctY2hhaXJzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRnd2ctY2hhaXJzQGlldGYu b3JnPC9hPjsNCjxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+Ow0KPGEgaHJlZj0ibWFpbHRv Om9zcGZAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vc3BmQGlldGYub3JnPC9hPjsgPGEgaHJl Zj0ibWFpbHRvOnJ0Z3dnQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpydGd3Z0BpZXRmLm9y ZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJc2lzLXdnXSBOZXcgVmVyc2lvbiBOb3Rp ZmljYXRpb24gZm9yIGRyYWZ0LWJyeWFudC1ydGd3Zy1wYXJhbS1zeW5jLTAxLnR4dDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PkhpIExlcyw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5JIHdpbGwgbm90ZSB0aGF0IHRoZSBNUlQgSVNJUyBhbmQgT1NQRiBkcmFmdHMgaW5jbHVkZSB0 aGUgZXh0ZW5zaW9uIGZvciBjb252ZXJnZW5jZSB0aW1lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGJlbGlldmUgdGhpcyBkcmFmdCB3YXMg bW90aXZhdGVkIGJ5IGEgY29uY2VybiB0aGF0IHRob3NlIGV4dGVuc2lvbnMgd291bGQgbm90IGJl IHNlZW4gYW5kPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPnJlYWxpemVkIHRvIGJlIGdlbmVyYWxseSB1c2VmdWwuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5SZWdhcmRzLDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BbGlhPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBU dWUsIEZlYiAyOCwgMjAxNyBhdCAxMDozNSBQTSwgTGVzIEdpbnNiZXJnIChnaW5zYmVyZykgJmx0 OzxhIGhyZWY9Im1haWx0bzpnaW5zYmVyZ0BjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5naW5z YmVyZ0BjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+U3Rld2FydCAtPGJyPg0KPGJyPg0KVGhpcyBkcmFmdCBkaXNjdXNzZXMgdHdv IHRoaW5nczo8YnI+DQo8YnI+DQoxKVlvdSBwcm9wb3NlIHRvIGFkdmVydGlzZSAmcXVvdDtjb252 ZXJnZW5jZSB0aW1lJnF1b3Q7IHNvIHRoYXQgcm91dGVycyB1dGlsaXppbmcgYSBmb3JtIG9mIEZS UiBjYW4gZGV0ZXJtaW5lIHdoZW4gaXQgaXMgc2FmZSB0byBzdGFydCB1dGlsaXppbmcgdGhlIHBv c3QgY29udmVyZ2VuY2UgcGF0aC4gQWxsIHRoaXMgcmVxdWlyZXMgaXMgYWR2ZXJ0aXNlbWVudCBv ZiBhIHZhbHVlIGFuZCBkZWZpbml0aW9uIG9mIGhvdyByb3V0ZXJzIGluIHRoZSBuZXR3b3JrIHNo b3VsZA0KIG1ha2UgdXNlIG9mIHRoaXMgdmFsdWUgLSBzcGVjaWZpY2FsbHkgdXNlIHRoZSBtYXhp bXVtIGFkdmVydGlzZWQgdmFsdWUgYXMgdGhlIGxvd2VyIGJvdW5kIGZvciBob3cgbG9uZyBhIHJl cGFpciBwYXRoIHNob3VsZCBjb250aW51ZSB0byBiZSB1c2VkLjxicj4NCjxicj4NClRoaXMgcHJv cG9zYWwgZGVzZXJ2ZXMgdG8gYmUgZGlzY3Vzc2VkIG9uIGl0cyBvd24gbWVyaXRzIC0gc29tZXRo aW5nIEkgd2lsbCBOT1QgZG8gaW4gdGhpcyBlbWFpbC48YnI+DQo8YnI+DQoyKVJhdGhlciB0aGFu IHNpbXBseSBkZWZpbmUgdGhlIG5ldyBhZHZlcnRpc2VtZW50IGFzIChmb3IgZXhhbXBsZSkgYSBu ZXcgc3ViLVRMViBpbiBJUy1JUyBSb3V0ZXIgQ2FwYWJpbGl0eSBUTFYsIHlvdSBoYXZlIGRlY2lk ZWQgdGhhdCB0aGVyZSBpcyAmcXVvdDtnZW5lcmFsIGNsYXNzIG9mIHByb2JsZW0mcXVvdDsgdGhh dCBuZWVkcyB0byBiZSBhZGRyZXNzZWQgYW5kIHNvIHlvdSBoYXZlIGludmVudGVkIGEgJnF1b3Q7 cm91dGluZyBwYXJhbWV0ZXIgc3luY2hyb25pemF0aW9uDQogcHJvdG9jb2wmcXVvdDsuIFRoaXMg cHJvcG9zZXMgdG8gJnF1b3Q7ZW5jYXBzdWxhdGUmcXVvdDsgdGhlIGFib3ZlIHBhcmFtZXRlciBh bmQgc29tZSB5ZXQgdG8gYmUgZGVmaW5lZCBzZXQgb2YgZnV0dXJlIHBhcmFtZXRlcnMgaW4gYSBj b21tb24gY29udGFpbmVyLSBzdWdnZXN0aW5nIHdlIHdpbGwgaGF2ZSBhIGxhcmdlIG51bWJlciBv ZiBzdWNoIHBhcmFtZXRlcnMgaW4gdGhlIGZ1dHVyZSBhbmQgdGhhdCB0aGV5IGhhdmUgc29tZSBs b2dpY2FsIHJlbGF0aW9uc2hpcC48YnI+DQo8YnI+DQpJIGZpbmQgdGhpcyBwcm9wb3NhbCB1bm5l Y2Vzc2FyeSBhbmQgdW5kZXNpcmFibGUuIEkgZG8gbm90IHNlZSBhbnkgdmFsdWUgYWRkIHRvIGVu Y2Fwc3VsYXRpbmcgbXVsdGlwbGUgcGFyYW1ldGVycyB3aGljaCBhcmUgb3RoZXJ3aXNlIHVucmVs YXRlZCBpbiBhIGNvbW1vbiBjb250YWluZXIgc2ltcGx5IGJlY2F1c2UgdGhlcmUgbWF5IGJlIHNv bWUgYWxnb3JpdGhtICh1bmlxdWUgdG8gZWFjaCBwYXJhbWV0ZXIpIHdoaWNoIG5lZWRzIHRvIGJl IGFwcGxpZWQNCiB3aGVuIG1ha2luZyB1c2Ugb2YgZWFjaCBwYXJhbWV0ZXIuPGJyPg0KPGJyPg0K SWYgeW91ciBjb25jZXJuIGlzIGNvbnN1bXB0aW9uIG9mIHN1Yi1UTFYgY29kZXBvaW50cyBpbiBJ Uy1JUywgaXQgaXMgd29ydGggcmV2aWV3aW5nIHRoZSBjdXJyZW50IHN0YXR1cy4gUkZDIDQ5NzEg d2hpY2ggb3JpZ2luYWxseSBkZWZpbmVkIHRoZSBSb3V0ZXIgQ2FwYWJpbGl0eSBUTFYgd2FzIHB1 Ymxpc2hlZCBpbiAyMDA3LiBPdmVyIHRoZSBuZWFybHkgMTAgeWVhcnMgaW4gd2hpY2ggdGhpcyBo YXMgYmVlbiBhdmFpbGFibGUgdGhlcmUgaGF2ZQ0KIGJlZW4gMjEgY29kZXBvaW50cyBhc3NpZ25l ZC4gVGhlcmUgYXJlIHR3byBvciB0aHJlZSBtb3JlIHRoYXQgSSBhbSBhd2FyZSBvZiB0aGF0IGFy ZSBpbiB0aGUgd29ya3MsIHNvIGluIDEwIHllYXJzIHdlIHdpbGwgaGF2ZSBjb25zdW1lZCBsZXNz IHRoYW4gMTAlIG9mIHRoZSBhdmFpbGFibGUgY29kZXBvaW50cy4gSSBhbSBxdWl0ZSBjb21mb3J0 YWJsZSB3aXRoIHRoaXMgcmF0ZSBvZiBjb25zdW1wdGlvbi48YnI+DQo8YnI+DQpJZiB5b3UgYmVs aWV2ZSB0aGVyZSBpcyBhYm91dCB0byBiZSBhbiBleHBsb3Npb24gb2YgY29kZSBwb2ludCByZXF1 ZXN0cyBJIHdpc2ggeW91IHdvdWxkIGJlIG1vcmUgZm9ydGhjb21pbmcgYXMgdG8gd2hhdCB5b3Ug ZXhwZWN0IGFzIGl0IHdvdWxkIHRoZW4gYmUgYXBwcm9wcmlhdGUgdG8gY29uc2lkZXIgd2hldGhl ciB0aGlzIHNldCBvZiBjYW5kaWRhdGVzIGlzIGFuIGFwcHJvcHJpYXRlIHVzZSBvZiB0aGUgcm91 dGluZyBwcm90b2NvbCBhbmQgdGhlDQogUm91dGVyIENhcGFiaWxpdHkgVExWLjxicj4NCjxicj4N Ck15IHJlY29tbWVuZGF0aW9uIGlzIHRvIHdyaXRlIGEgZHJhZnQgY29uZmluZWQgdG8gdGhlIGRl ZmluaXRpb24gb2YgdGhlIG5ldyBjb252ZXJnZW5jZSB0aW1lIHBhcmFtZXRlciB5b3Ugd2lzaCB0 byBhZHZlcnRpc2UgYW5kIGxldCB1cyByZXZpZXcgdGhhdCBvbiBpdHMgb3duIG1lcml0cy48YnI+ DQo8c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0KPHNwYW4gY2xhc3M9Im0tNzQ3NzYz NTQ3NTc1NzE0MDk2Mm0tMzEyNDk3MTk0MjEwOTI3MTU0OWhvZW56YiI+Jm5ic3A7ICZuYnNwO0xl czwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PGJyPg0KJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZn dDsgRnJvbTogcnRnd2cgW21haWx0bzo8YSBocmVmPSJtYWlsdG86cnRnd2ctYm91bmNlc0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Z3dnLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhh bGYgT2YgU3Rld2FydCBCcnlhbnQ8YnI+DQomZ3Q7IFNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMjcs IDIwMTcgOToyMyBBTTxicj4NCiZndDsgVG86IDxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+ OyBDaHJpcyBCb3dlcnM7IEFsaWEgQXRsYXM7DQo8YSBocmVmPSJtYWlsdG86cnRnd2dAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5ydGd3Z0BpZXRmLm9yZzwvYT47IHJ0Z3dnLTxicj4NCiZndDsg PGEgaHJlZj0ibWFpbHRvOmNoYWlyc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmNoYWlyc0Bp ZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzppc2lzLXdnQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+DQppc2lzLXdnQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOm9zcGZAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5vc3BmQGlldGYub3JnPC9hPjxicj4NCiZndDsgU3ViamVjdDog UmU6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtYnJ5YW50LXJ0Z3dnLXBhcmFt LXN5bmMtPGJyPg0KJmd0OyAwMS50eHQ8YnI+DQomZ3Q7PGJyPg0KJmd0OyBSZXNlbmQgd2l0aCBj b3JyZWN0IElTSVMgV0cgZW1haWwgYWRkcmVzczxicj4NCiZndDs8YnI+DQomZ3Q7IEZvbGxvd2lu ZyBkaXNjdXNzaW9uIGF0IHRoZSBsYXN0IElFVEYsIEkgaGF2ZSBtYWRlIGEgbnVtYmVyIG9mIGNo YW5nZXMgdG8gdGhlPGJyPg0KJmd0OyB0ZXh0IHRvIGVtcGhhc2lzIHRoYXQgdGhpcyBwcm90b2Nv bHMgaXMgb25seSB0byBiZSB1c2VkIGZvciB0aGUgc3luY2hyb25pemF0aW9uPGJyPg0KJmd0OyBv ZiBwYXJhbWV0ZXJzIG5lZWRzIGJ5IHRoZSByb3V0aW5nIHN5c3RlbS48YnI+DQomZ3Q7PGJyPg0K Jmd0OyBBcyBhZ3JlZWQgYXQgdGhlIFJUR1dHIG1lZXRpbmcgSSBhbSBub3RpZnlpbmcgUlRHV0cs IElTSVMgYW5kIE9TUEYgV0dzLjxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZSBkcmFmdCBjYW4gYmUg Zm91bmQgaGVyZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBVUkw6PGJyPg0KJmd0OyA8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtYnJ5YW50LXJ0Z3dnLXBh cmFtLXN5bmMtMDEudHh0IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtYnJ5YW50LXJ0Z3dnLXBhcmFtLXN5bmMtMDEudHh0PC9hPjxi cj4NCiZndDsgU3RhdHVzOjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtYnJ5YW50LXJ0Z3dnLXBhcmFtLXN5bmMvIiB0YXJnZXQ9Il9ibGFu ayI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1icnlhbnQtcnRnd2ct cGFyYW0tc3luYy88L2E+PGJyPg0KJmd0OyBIdG1saXplZDombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYnJ5YW50LXJ0 Z3dnLXBhcmFtLXN5bmMtMDEiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtYnJ5YW50LXJ0Z3dnLXBhcmFtLXN5bmMtMDE8L2E+PGJyPg0KJmd0OyBEaWZm Ojxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRy YWZ0LWJyeWFudC1ydGd3Zy1wYXJhbS1zeW5jLTAxIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczov L3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtYnJ5YW50LXJ0Z3dnLXBhcmFtLXN5bmMt MDE8L2E+PGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlIGZvbGxvd2luZyBpcyBhIHN1bW1hcnkgb2Yg dGhlIGNoYW5nZWQ6PGJyPg0KJmd0Ozxicj4NCiZndDsgSSBoYXZlIGNoYW5nZWQgdGhlIHRpdGxl IHRvOjxicj4NCiZndDs8YnI+DQomZ3Q7IFN5bmNocm9uaXNhdGlvbiBvZiBSb3V0aW5nIFBhcmFt ZXRlcnM8YnI+DQomZ3Q7PGJyPg0KJmd0OyA9PT09PT09PT08YnI+DQomZ3Q7PGJyPg0KJmd0OyBJ IGhhdmUgYWRkZWQgaW4gdGhlIGludHJvZHVjdGlvbjo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBOb3Rl IHRoYXQgdGhpcyBwcm90b2NvbCBpcyBvbmx5IGludGVuZGVkIHRvIGJlIHVzZWQgZm9yIHRoZSBw cm9wYWdhdGlvbiBvZjxicj4NCiZndDsgcGFyYW1ldGVycyBuZWVkZWQgdG8gc3VwcG9ydCB0aGUg b3BlcmF0aW9uIG9mIHRoZSByb3V0aW5nIHN5c3RlbS4gSXQgTVVTVDxicj4NCiZndDsgTk9UIGJl IHVzZWQgYXMgYSBnZW5lcmFsIHB1cnBvc2UgcGFyYW1ldGVyIGV4Y2hhbmdlIHByb3RvY29sLCBh bmQgaW48YnI+DQomZ3Q7IHBhcnRpY3VsYXIgaXQgTVVTVCBOT1QgYmUgdXNlZCBhcyBhIHBhcmFt ZXRlciBuZWdvdGlhdGlvbiBwcm90b2NvbCwgc2luY2U8YnI+DQomZ3Q7IHN1Y2ggdXNlIG1heSBk ZWdyYWRlIHRoZSBhYmlsaXR5IG9mIHRoZSB1bmRlcmx5aW5nIGxpbmstc3RhdGUgcm91dGluZyBw cm90b2NvbDxicj4NCiZndDsgdG8gY2Fycnkgb3VyIGl0cyBlc3NlbnRpYWwgcHVycG9zZS48YnI+ DQomZ3Q7PGJyPg0KJmd0OyA9PT09PT09PTxicj4NCiZndDs8YnI+DQomZ3Q7IEkgaGF2ZSBjaGFu Z2VkIHRoZSBJQU5BIHRleHQgdG8gc2F5Ojxicj4NCiZndDs8YnI+DQomZ3Q7IFN5bmNocm9uaXNh dGlvbiBvZiBSb3V0aW5nIFBhcmFtZXRlcnM8YnI+DQomZ3Q7PGJyPg0KJmd0OyA9PT09PT09PTxi cj4NCiZndDs8YnI+DQomZ3Q7IEkgaGF2ZSBhZGRlZCB0byB0aGUgc2VjdXJpdHkgc2VjdGlvbjo8 YnI+DQomZ3Q7PGJyPg0KJmd0OyBJbiBzcGVjaWZ5aW5nIGEgbmV3IHBhcmFtZXRlciwgY29uc2lk ZXJhdGlvbiBtdXN0IGJlIGdpdmVuIHRvIHRoZSBpbXBhY3Qgb2Y8YnI+DQomZ3Q7IHRoZSBhZGRp dGlvbmFsIHBhcmFtZXRlciwgYW5kIGluIHBhcnRpY3VsYXIgdGhlIHJhdGUgb2YgY2hhbmdlIG9m IHRoYXQ8YnI+DQomZ3Q7IHBhcmFtZXRlciwgb24gdGhlIGR5bmFtaWNzIG9mIHRoZSBsaW5rLXN0 YXRlIHJvdXRpbmcgcHJvdG9jb2wgaW4gdXNlLiBJbiB0aGU8YnI+DQomZ3Q7IHNwZWNpZmljIGNh c2Ugb2YgdGhlIENvbnZlcmdlbmNlIFRpbWVyLCB0aGUgYW1vdW50IG9mIGRhdGEgYmVpbmcgY2Fy cmllZCBhbmQ8YnI+DQomZ3Q7IHRoZSByYXRlIG9mIGNoYW5nZSBvZiB0aGUgcGFyYW1ldGVyIHZh bHVlIHdpbGwgaGF2ZSBhIG5lZ2xpZ2libGUgaW1wYWN0IG9uIHRoZTxicj4NCiZndDsgbGluay1z dGF0ZSByb3V0aW5nIHByb3RvY29sIGluIHVzZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyA9PT09PT09 PT08YnI+DQomZ3Q7PGJyPg0KJmd0OyBJbmNvcnBvcmF0ZWQgYSBudW1iZXIgb2YgcmV2aWV3IHN1 Z2dlc3Rpb25zIGJ5IE1vaGFtZWQgQm91Y2FkYWlyIChNb2QpPGJyPg0KJmd0Ozxicj4NCiZndDsg QWRkZWQ8YnI+DQomZ3Q7PGJyPg0KJmd0OyBTdWNoIGNvbnNpc3RlbmN5IG1heSBiZSBlbnN1cmVk IGJ5IGRlcGxveWluZyBhdXRvbWF0ZWQgbWVhbnMgc3VjaCBhczxicj4NCiZndDsgZW5mb3JjaW5n IHRoZSBuZXcgdmFsdWUgYnkgaW52b2tpbmcgdGhlIG1hbmFnZW1lbnQgaW50ZXJmYWNlIG9mIGFs bDxicj4NCiZndDsgaW52b2x2ZWQgcm91dGVycy4gRm9yIGV4YW1wbGUsIGEgY2VudHJhbCBtYW5h Z2VtZW50IGVudGl0eSBtYXkgYmU8YnI+DQomZ3Q7IHJlc3BvbnNpYmxlIGZvciBjb21tdW5pY2F0 aW5nIHRoZSBuZXcgY29uZmlndXJhdGlvbiB2YWx1ZSBieSBtZWFucyBvZjxicj4NCiZndDsgdmVu ZG9yLXNwZWNpZmljIENMSSwgTkVUQ09ORiwgZXRjLiBUaGlzIGFwcHJvYWNoIG1heSBiZSBhdHRy YWN0aW5nIGlmIGFsbDxicj4NCiZndDsgaW52b2x2ZWQgbm9kZXMgZXhwb3NlIHRlY2hub2xvZ3kt YWdub3N0aWMgYW5kIHZlbmRvci1pbmRlcGVuZGVudDxicj4NCiZndDsgaW50ZXJmYWNlcyB0byB0 d2VhayBhIGdpdmVuIG5ldHdvcmstd2lkZSBjb25maWd1cmF0aW9uIHBhcmFtZXRlci48YnI+DQom Z3Q7PGJyPg0KJmd0OyA9PT09PT08YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIHdvdWxkIGxpa2UgdG8g cHJvcG9zZSB0aGF0IHdlIG1vdmUgdGhpcyBmb3J3YXJkIHRvIGJlY29tZSBhIFdHIGRyYWZ0IGFu ZDxicj4NCiZndDsgcmVmaW5lIHRoZSBkZXRhaWwgdW5kZXIgdGhlIFdHIHByb2Nlc3MuPGJyPg0K Jmd0Ozxicj4NCiZndDsgLSBTdGV3YXJ0PGJyPg0KJmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mZ3Q7IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBydGd3 ZyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpydGd3Z0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPnJ0Z3dnQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGd3ZyIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRnd2c8L2E+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_618323e0db7c4aca9a7e25410fb9153bXCHALN001ciscocom_-- From nobody Thu Mar 2 04:19:56 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95087129973; Thu, 2 Mar 2017 04:19:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 eACuJAfh1Npg; Thu, 2 Mar 2017 04:19:53 -0800 (PST) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::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 924F8129512; Thu, 2 Mar 2017 04:19:53 -0800 (PST) Received: by mail-it0-x22e.google.com with SMTP id 203so49988781ith.0; Thu, 02 Mar 2017 04:19:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uFRiyZjWBX86VASUZlS0kf5D7VoKdfn2J/t3DXvZXIU=; b=Pg2JhqGW2kafcMHw7DqmxVUvXxfvurgGsPCGy8DzmvjjeujSol0i6fiO9trDiZ7dGu zPWR4+JP9onvtIxJekAmIqrcHQwNo1Z7Hp+DAvJ0W6VPCKGX+lx+LWR6zMgpJ37GlGIH Co2Un8oPUWkWOS7AGoKWOjArpTL7bZQ78DJn3UEDsVfLlwHx/WQFFfW/WqhjY+3Wp04V D5Z3X9KNJ6V/7rBHSt3shFjH2ifAzbT+zzshRz1pdmldHV6DmgBE+OCWppQOnAH+ht36 jD/N0wlpYaffhswYI7SaQwkIEphA9F58eKLK4DOFbIjlGj/FsHk0SPKL5Af9hPIhKhPv sebg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uFRiyZjWBX86VASUZlS0kf5D7VoKdfn2J/t3DXvZXIU=; b=eZVsVYOrM5mvDd75Al/b51OZrg/4iRlAr7wP1aavpux64i4IbYC0xoe1pvFj9x7Ny6 yOFGXGlWHCZw+IiVmHuGZ9EJ4vwFYIVBv6s0pxAkJILv7xTJkWJs5EidQc6i4I+k5P8z GiIlr/YqaUhvPk7lrsjFJHn3OAOQxli4xQC+8wxDAuIKNkeVr6FLnVSkyjbM+TgIyEs9 G1AL/KCfQ2ces8RyC+hZzlX9C28NXGQ3DZqDn+sD6C2Klrrbng1lXJV5f6q4mWFnqGh0 1Grjta6xz0BfhFV4XsyKcJQHbN8eiB/BioPMcXgB7bOC1YxeZmd3T+HtiZFfT93XIEaR l60g== X-Gm-Message-State: AMke39mD4IcKgU2oin9ij1zvLkz54gVZbp02CP/JqOV/9wfpDzlYly95hBAB/pZHQZLSbPTvQ4hdET2MRs+Djg== X-Received: by 10.36.252.197 with SMTP id b188mr9264796ith.53.1488457192954; Thu, 02 Mar 2017 04:19:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.232.170 with HTTP; Thu, 2 Mar 2017 04:19:32 -0800 (PST) In-Reply-To: <75FE1936-DC60-4914-BF94-E7EC7DCF5AE9@gmail.com> References: <75FE1936-DC60-4914-BF94-E7EC7DCF5AE9@gmail.com> From: Jen Linkova Date: Thu, 2 Mar 2017 13:19:32 +0100 Message-ID: Subject: Re: WG adoption call for draft-bowbakova-rtgwg-enterprise-pa-multihoming To: Jeff Tantsura Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-bowbakova-rtgwg-enterprise-pa-multihoming@ietf.org, rtgwg-chairs , RTGWG X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 12:19:54 -0000 On Wed, Feb 22, 2017 at 12:19 AM, Jeff Tantsura wrote: > The authors have requested the RTGWG to adopt > draft-bowbakova-rtgwg-enterprise-pa-multihoming draft as the working group > document. > IPR: > > If you are listed as a document author or contributor, please respond to > this email. > > of whether or not you are aware of any relevant IPR. The response needs to > be sent to the RTGWG mailing list. > > The document will not advance to the next stage until a response has been > received from each author and each individual that has contributed to the document. I'm not aware of any IPR. -- SY, Jen Linkova aka Furry From nobody Thu Mar 2 15:27:50 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 965C2129404; Thu, 2 Mar 2017 15:27:49 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com 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 6LTh8gDFkgeq; Thu, 2 Mar 2017 15:27:47 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0107.outbound.protection.outlook.com [104.47.33.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 539531293FF; Thu, 2 Mar 2017 15:27:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=C7Bmsv4YHtxNK3I51o20DECut0R24ZgjCDlfJVjXU68=; b=LJkuFBdILeBmelLfG+/ms1KQJw3Fd/Wvly4HzT1wSie5wIbTT0s9rTQUbCMJ5JgFRuIPMhXvGXhALGtQA5nMZSpufVfnk4Dp4gHERqNd0v4IujsI6FvrLrkC0MM42jrM9dfNPv0+rsvGumauUVBhMekCwtstFlglS5w8WeRj6aE= Received: from MWHPR05MB2829.namprd05.prod.outlook.com (10.168.245.11) by MWHPR05MB2829.namprd05.prod.outlook.com (10.168.245.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.2; Thu, 2 Mar 2017 23:27:45 +0000 Received: from MWHPR05MB2829.namprd05.prod.outlook.com ([10.168.245.11]) by MWHPR05MB2829.namprd05.prod.outlook.com ([10.168.245.11]) with mapi id 15.01.0947.012; Thu, 2 Mar 2017 23:27:45 +0000 From: Chris Bowers To: Jeff Tantsura , RTGWG Subject: RE: WG adoption call for draft-bowbakova-rtgwg-enterprise-pa-multihoming Thread-Topic: WG adoption call for draft-bowbakova-rtgwg-enterprise-pa-multihoming Thread-Index: AQHSjJjsm8rXHENtkkGTcGOJ0b6YWaF9FlVQ Date: Thu, 2 Mar 2017 23:27:44 +0000 Message-ID: References: <75FE1936-DC60-4914-BF94-E7EC7DCF5AE9@gmail.com> In-Reply-To: <75FE1936-DC60-4914-BF94-E7EC7DCF5AE9@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.239.11] x-ms-office365-filtering-correlation-id: 30c041bb-144e-4985-d8ef-08d461c3bb1a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:MWHPR05MB2829; x-microsoft-exchange-diagnostics: 1; MWHPR05MB2829; 7:6oVXguXusdwXbbh9QwgwualhEqPfZol9cwqU7SAdC0B0KaGd68oYIQflTALYq+H6I3dZMcE4S9WLlhTjwkEEf7OGhtkOY+/AGpZXA1LWWuHkyZjnGAGOu7+eBYvhr9kUwDX2IbsvsdFzyp5cc67ckV1IdFrN0ba8A90II555H1IHnRBjeqbCDiUxx7gYUxEnepXnJp8bCJABXxfzM0BdcKan41bnV2SncG0UN4I2dSHsAS5i2IymdSlfsnwPgepSTaqDyJNnUP0uXAxbSDd46IkIxvUlqtN+KPSSXSAQGMzaXiyVHT1x9peU0yddzZpOjkj26momkBCJUSqcFiZE6g== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123564025)(20161123558025)(20161123562025)(20161123555025)(6072148)(6042181); SRVR:MWHPR05MB2829; BCL:0; PCL:0; RULEID:; SRVR:MWHPR05MB2829; x-forefront-prvs: 023495660C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(106116001)(790700001)(54906002)(66066001)(3846002)(6116002)(102836003)(189998001)(74316002)(2950100002)(230783001)(7736002)(54356999)(50986999)(76176999)(86362001)(33656002)(53936002)(39060400002)(8936002)(229853002)(53546006)(38730400002)(99286003)(92566002)(6246003)(55016002)(4326008)(25786008)(9686003)(81166006)(3660700001)(6506006)(2900100001)(8676002)(6436002)(122556002)(77096006)(3280700002)(5660300001)(54896002)(7696004)(6306002)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR05MB2829; H:MWHPR05MB2829.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR05MB28292B88F16AD68C8BD2F5B4A9280MWHPR05MB2829namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Mar 2017 23:27:44.9526 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB2829 Archived-At: Cc: "draft-bowbakova-rtgwg-enterprise-pa-multihoming@ietf.org" , rtgwg-chairs X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 23:27:49 -0000 --_000_MWHPR05MB28292B88F16AD68C8BD2F5B4A9280MWHPR05MB2829namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzdXBwb3J0IGFkb3B0aW9uIG9mIHRoZSBkcmFmdCBieSBSVEdXRyBhcyBhIGNvLWF1dGhvci4g IEkgYW0gbm90IGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIgZm9yIHRoaXMgZHJhZnQuDQoNCkNo cmlzDQoNCkZyb206IEplZmYgVGFudHN1cmEgW21haWx0bzpqZWZmdGFudC5pZXRmQGdtYWlsLmNv bV0NClNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDIxLCAyMDE3IDU6MTkgUE0NClRvOiBSVEdXRyA8 cnRnd2dAaWV0Zi5vcmc+DQpDYzogcnRnd2ctY2hhaXJzIDxydGd3Zy1jaGFpcnNAaWV0Zi5vcmc+ OyBkcmFmdC1ib3diYWtvdmEtcnRnd2ctZW50ZXJwcmlzZS1wYS1tdWx0aWhvbWluZ0BpZXRmLm9y Zw0KU3ViamVjdDogV0cgYWRvcHRpb24gY2FsbCBmb3IgZHJhZnQtYm93YmFrb3ZhLXJ0Z3dnLWVu dGVycHJpc2UtcGEtbXVsdGlob21pbmcNCg0KRGVhciBSVEdXRywNCg0KVGhlIGF1dGhvcnMgaGF2 ZSByZXF1ZXN0ZWQgdGhlIFJUR1dHIHRvIGFkb3B0IGRyYWZ0LWJvd2Jha292YS1ydGd3Zy1lbnRl cnByaXNlLXBhLW11bHRpaG9taW5nIGRyYWZ0IGFzIHRoZSB3b3JraW5nIGdyb3VwIGRvY3VtZW50 Lg0KUlRHV0cgY2hhaXJzIGhhdmUgZGlzY3Vzc2VkIHRoZSBwcm9ncmVzcyBvZiB0aGUgZHJhZnQg d2l0aCB2Nm9wcyBjaGFpcnMgYW5kIGdvdCB0aGVpciBibGVzc2luZy4NCg0KUGxlYXNlIGluZGlj YXRlIHN1cHBvcnQgb3Igbm8tc3VwcG9ydCBieSBNYXJjaCA4dGgsIDIwMTcuDQoNCklQUjoNCklm IHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yLCBwbGVh c2UgcmVzcG9uZCB0byB0aGlzIGVtYWlsLg0Kb2Ygd2hldGhlciBvciBub3QgeW91IGFyZSBhd2Fy ZSBvZiBhbnkgcmVsZXZhbnQgSVBSLiBUaGUgcmVzcG9uc2UgbmVlZHMgdG8gYmUgc2VudCB0byB0 aGUgUlRHV0cgbWFpbGluZyBsaXN0Lg0KVGhlIGRvY3VtZW50IHdpbGwgbm90IGFkdmFuY2UgdG8g dGhlIG5leHQgc3RhZ2UgdW50aWwgYSByZXNwb25zZSBoYXMgYmVlbiByZWNlaXZlZCBmcm9tIGVh Y2ggYXV0aG9yIGFuZCBlYWNoDQppbmRpdmlkdWFsIHRoYXQgaGFzIGNvbnRyaWJ1dGVkIHRvIHRo ZSBkb2N1bWVudC4NCg0KVGhhbmtzLA0KSmVmZiAmIENocmlzDQoNCg== --_000_MWHPR05MB28292B88F16AD68C8BD2F5B4A9280MWHPR05MB2829namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUx OA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2lu ZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdE O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5n PSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPkkgc3VwcG9ydCBhZG9wdGlvbiBvZiB0aGUgZHJhZnQgYnkg UlRHV0cgYXMgYSBjby1hdXRob3IuJm5ic3A7IEkgYW0gbm90IGF3YXJlIG9mIGFueSByZWxldmFu dCBJUFIgZm9yIHRoaXMgZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+Q2hyaXM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+IEplZmYgVGFudHN1cmEgW21haWx0bzpqZWZmdGFudC5pZXRmQGdtYWlsLmNv bV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBGZWJydWFyeSAyMSwgMjAxNyA1OjE5IFBN PGJyPg0KPGI+VG86PC9iPiBSVEdXRyAmbHQ7cnRnd2dAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6 PC9iPiBydGd3Zy1jaGFpcnMgJmx0O3J0Z3dnLWNoYWlyc0BpZXRmLm9yZyZndDs7IGRyYWZ0LWJv d2Jha292YS1ydGd3Zy1lbnRlcnByaXNlLXBhLW11bHRpaG9taW5nQGlldGYub3JnPGJyPg0KPGI+ U3ViamVjdDo8L2I+IFdHIGFkb3B0aW9uIGNhbGwgZm9yIGRyYWZ0LWJvd2Jha292YS1ydGd3Zy1l bnRlcnByaXNlLXBhLW11bHRpaG9taW5nDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+RGVhciBSVEdX Ryw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoZSBhdXRob3Jz IGhhdmUgcmVxdWVzdGVkIHRoZSBSVEdXRyB0byBhZG9wdCBkcmFmdC1ib3diYWtvdmEtcnRnd2ct ZW50ZXJwcmlzZS1wYS1tdWx0aWhvbWluZyBkcmFmdCBhcyB0aGUgd29ya2luZyBncm91cCBkb2N1 bWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+UlRHV0cgY2hhaXJzIGhhdmUgZGlzY3Vzc2VkIHRoZSBw cm9ncmVzcyBvZiB0aGUgZHJhZnQgd2l0aCB2Nm9wcyBjaGFpcnMgYW5kIGdvdCB0aGVpciBibGVz c2luZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlBsZWFzZSBp bmRpY2F0ZSBzdXBwb3J0IG9yIG5vLXN1cHBvcnQgYnkgTWFyY2ggOHRoLCAyMDE3LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SVBSOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij5JZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmlidXRvciwg cGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBlbWFpbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+b2Ygd2hldGhl ciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBSLiBUaGUgcmVzcG9uc2Ug bmVlZHMgdG8gYmUgc2VudCB0byB0aGUgUlRHV0cgbWFpbGluZyBsaXN0LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij5UaGUgZG9jdW1lbnQgd2lsbCBub3QgYWR2YW5jZSB0byB0aGUgbmV4dCBzdGFnZSB1bnRp bCBhIHJlc3BvbnNlIGhhcyBiZWVuIHJlY2VpdmVkIGZyb20gZWFjaCBhdXRob3IgYW5kIGVhY2g8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+aW5kaXZpZHVhbCB0aGF0IGhhcyBjb250cmlidXRlZCB0byB0aGUg ZG9jdW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGFu a3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkplZmYgJmFtcDsgQ2hyaXM8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_MWHPR05MB28292B88F16AD68C8BD2F5B4A9280MWHPR05MB2829namp_-- From nobody Thu Mar 2 15:48:30 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79A56126B6D; Thu, 2 Mar 2017 15:48:24 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com 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 btrekypsytDd; Thu, 2 Mar 2017 15:48:22 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0122.outbound.protection.outlook.com [104.47.36.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74E2C128BA2; Thu, 2 Mar 2017 15:48:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0jCW811oMp/e/BKKpDT8oepZrByk5vXKVofU156r8F4=; b=fMG52ROqE0qNdZigSm8eduAP2zZd2KRDBcDPbxNBF1AJzsmjjGxGvfjhwxXeZlzJGY+7cAl+jbT56MidpGkV/J/+2wspm+vwkiKjWQJQsmArB8F/iwyYjuNmHclVoTnsYQ8uCn7cruwO2c0s0J4pJ6xafYTS7nL0Ov/wi4JRhnU= Received: from MWHPR05MB2829.namprd05.prod.outlook.com (10.168.245.11) by MWHPR05MB2832.namprd05.prod.outlook.com (10.168.245.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.2; Thu, 2 Mar 2017 23:48:20 +0000 Received: from MWHPR05MB2829.namprd05.prod.outlook.com ([10.168.245.11]) by MWHPR05MB2829.namprd05.prod.outlook.com ([10.168.245.11]) with mapi id 15.01.0947.012; Thu, 2 Mar 2017 23:48:20 +0000 From: Chris Bowers To: "Acee Lindem (acee)" , Jeff Tantsura , RTGWG Subject: RE: WG adoption call for draft-bowbakova-rtgwg-enterprise-pa-multihoming Thread-Topic: WG adoption call for draft-bowbakova-rtgwg-enterprise-pa-multihoming Thread-Index: AQHSjJjsm8rXHENtkkGTcGOJ0b6YWaF0GumAgA4lf2A= Date: Thu, 2 Mar 2017 23:48:20 +0000 Message-ID: References: <75FE1936-DC60-4914-BF94-E7EC7DCF5AE9@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.239.11] x-ms-office365-filtering-correlation-id: 52a235e8-bf0d-4d30-87f4-08d461c69baa x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:MWHPR05MB2832; x-microsoft-exchange-diagnostics: 1; MWHPR05MB2832; 7:rEOfq9Ia8AimSkIi5NgxftW+lVdKQGyJAw5rUTLToWHLE8KhLJET3c090idvmqy9KEyEvmdptPQzIzXhNBiNe2BQPvWJ4cTV5rQZg8somicVc8pkZd19M782RcSDI9vbg1o2pVGGkamDo64xXvXk+HCiqnfrokCTiZP9Gp59CS/zT196Yb68MJUcToGjuy3TbfxrldxSw5xzMiapuNbsk8lyLcAuB0/FChYNcmbX3V1H8dQgfUo9CnezbuO3f63DAP7DBgyFh7CzBtKVw84/o6IiEUZb7j8SXdNplfI7hW1oq/JcenVz+QQRtWro5R2cCnQchYDv8nv3WeleoOj6cA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123555025)(20161123558025)(20161123562025)(20161123564025)(6072148); SRVR:MWHPR05MB2832; BCL:0; PCL:0; RULEID:; SRVR:MWHPR05MB2832; x-forefront-prvs: 023495660C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39840400002)(39450400003)(39850400002)(39410400002)(39860400002)(377454003)(55016002)(99286003)(230783001)(189998001)(236005)(74316002)(54896002)(54906002)(8676002)(106116001)(9686003)(39060400002)(25786008)(7736002)(6306002)(53936002)(66066001)(81166006)(229853002)(6436002)(86362001)(6506006)(76176999)(6246003)(54356999)(33656002)(50986999)(38730400002)(77096006)(3280700002)(3660700001)(53546006)(8936002)(3846002)(790700001)(122556002)(5660300001)(2906002)(6116002)(102836003)(2900100001)(2950100002)(92566002)(7696004)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR05MB2832; H:MWHPR05MB2829.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR05MB2829A08E4A08882C53F90903A9280MWHPR05MB2829namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Mar 2017 23:48:20.8255 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB2832 Archived-At: Cc: "draft-bowbakova-rtgwg-enterprise-pa-multihoming@ietf.org" , rtgwg-chairs X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 23:48:24 -0000 --_000_MWHPR05MB2829A08E4A08882C53F90903A9280MWHPR05MB2829namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Acee, The authors are OK with making this document informational. It is intended= to provide a description of the different parts of an overall solution to = this problem (with a few variants). Anything new that needs to be standard= ized will be addressed in separate documents in the appropriate working gro= up. Thanks, Chris From: Acee Lindem (acee) [mailto:acee@cisco.com] Sent: Tuesday, February 21, 2017 5:27 PM To: Jeff Tantsura ; RTGWG Cc: draft-bowbakova-rtgwg-enterprise-pa-multihoming@ietf.org; rtgwg-chairs = Subject: Re: WG adoption call for draft-bowbakova-rtgwg-enterprise-pa-multi= homing Hi Jeff, The document is standards track. Can the authors summarize what is being st= andardized as opposed to informational? I think we need to determine whethe= r this work belongs in RTGWG or 6MAN. Thanks, Acee From: rtgwg > on beha= lf of Jeff Tantsura > Date: Tuesday, February 21, 2017 at 6:19 PM To: Routing WG > Cc: "draft-bowbakova-rtgwg-enterprise-pa-multihoming@ietf.org" >, rtgwg-chairs > Subject: WG adoption call for draft-bowbakova-rtgwg-enterprise-pa-multihomi= ng Dear RTGWG, The authors have requested the RTGWG to adopt draft-bowbakova-rtgwg-enterpr= ise-pa-multihoming draft as the working group document. RTGWG chairs have discussed the progress of the draft with v6ops chairs and= got their blessing. Please indicate support or no-support by March 8th, 2017. IPR: If you are listed as a document author or contributor, please respond to th= is email. of whether or not you are aware of any relevant IPR. The response needs to = be sent to the RTGWG mailing list. The document will not advance to the next stage until a response has been r= eceived from each author and each individual that has contributed to the document. Thanks, Jeff & Chris --_000_MWHPR05MB2829A08E4A08882C53F90903A9280MWHPR05MB2829namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Acee,=

=  

The a= uthors are OK with making this document informational.  It is intended= to provide a description of the different parts of an overall solution to = this problem (with a few variants).  Anything new that needs to be standardized will be addressed in separate documents = in the appropriate working group.

=  

Thank= s,

Chris=

=  

From:= Acee Lindem (acee) [mailto:acee@cisco.com= ]
Sent: Tuesday, February 21, 2017 5:27 PM
To: Jeff Tantsura <jefftant.ietf@gmail.com>; RTGWG <rtgwg@i= etf.org>
Cc: draft-bowbakova-rtgwg-enterprise-pa-multihoming@ietf.org; rtgwg-= chairs <rtgwg-chairs@ietf.org>
Subject: Re: WG adoption call for draft-bowbakova-rtgwg-enterprise-p= a-multihoming

 

Hi Jeff= , 

&n= bsp;

The doc= ument is standards track. Can the authors summarize what is being standardi= zed as opposed to informational? I think we need to determine whether this = work belongs in RTGWG or 6MAN.  

&n= bsp;

Thanks,=

Acee&nb= sp;

&n= bsp;

From= : rtgwg <rtgwg-bounces@ietf.org> on behalf= of Jeff Tantsura <jefftant.i= etf@gmail.com>
Date: Tuesday, February 21, 2017 at 6:19 PM
To: Routing WG <rtgwg@ietf.org<= /a>>
Cc: "draft-bowbakova-rtgwg-enterprise-pa-multihoming@ietf.org<= /a>" <draft-bowbakova-rtgwg-enterprise-pa-multihoming@ietf.org= >, rtgwg-chairs <rtgwg-chairs@iet= f.org>
Subject: WG adoption call for draft-bowbakova-rtgwg-enterprise-pa-mu= ltihoming

&n= bsp;

Dear RT= GWG,

 <= /span>

The aut= hors have requested the RTGWG to adopt draft-bowbakova-rtgwg-enterprise-pa-= multihoming draft as the working group document.

RTGWG c= hairs have discussed the progress of the draft with v6ops chairs and got th= eir blessing.

Please = indicate support or no-support by March 8th, 2017.

IPR:

If you = are listed as a document author or contributor, please respond to this emai= l.

of whet= her or not you are aware of any relevant IPR. The response needs to be sent= to the RTGWG mailing list.

The doc= ument will not advance to the next stage until a response has been received= from each author and each

individ= ual that has contributed to the document.

Thanks,=

Jeff &a= mp; Chris

--_000_MWHPR05MB2829A08E4A08882C53F90903A9280MWHPR05MB2829namp_-- From nobody Fri Mar 3 04:51:39 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 778A6129850; Fri, 3 Mar 2017 04:51:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 cCkZg2prMPlU; Fri, 3 Mar 2017 04:51:35 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 773D01296DE; Fri, 3 Mar 2017 04:51:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14888; q=dns/txt; s=iport; t=1488545495; x=1489755095; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=BaD6o6q6fdxqQ68hWZcgpZs4cxQyC8vhVzsRaLmN8Q4=; b=hNv8ksO8SmUT7JxQfmiGXjuNA0Jq2PISq62c0vb14Rd9rwnRXXc2QDik rpj9sNUHLfWXr9T9RlFqZiTOGv/zMA9eYkQqvZIzTPHBV4WPIHE4mOX4o UGNdX3fRyhlSOJk2sDhdAftI1nleBlpZIN1Z3x+b1BbQPphELpfSf0Q/1 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AeAQBgZblY/4kNJK1UChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJuYmGBCQeNYZFFiA2HfoUsgg2GIgKCXT8YAQIBAQEBAQEBYii?= =?us-ascii?q?EcAEBAQQdEEEGBRACAQgOAwMBAQEoByERFAkIAgQBDQUbiUgDFbRxhzMNg0cBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEdiz2CUYFVBgsBPBaFLwWbcjoBjgmEKYF7hSK?= =?us-ascii?q?KAopTiGcBHzh7CFYVP4ZSdocvgSGBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,237,1484006400"; d="scan'208,217";a="213760585" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Mar 2017 12:51:34 +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 v23CpYO6012291 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 3 Mar 2017 12:51:34 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.1210.3; Fri, 3 Mar 2017 07:51:33 -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.1210.000; Fri, 3 Mar 2017 07:51:33 -0500 From: "Acee Lindem (acee)" To: Chris Bowers , Jeff Tantsura , RTGWG Subject: Re: WG adoption call for draft-bowbakova-rtgwg-enterprise-pa-multihoming Thread-Topic: WG adoption call for draft-bowbakova-rtgwg-enterprise-pa-multihoming Thread-Index: AQHSjJoNYxgCOk/kfUO56alwIpsPpKGCmY4AgACG/wA= Date: Fri, 3 Mar 2017 12:51:33 +0000 Message-ID: References: <75FE1936-DC60-4914-BF94-E7EC7DCF5AE9@gmail.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.197] Content-Type: multipart/alternative; boundary="_000_D4DED06AA0ACEaceeciscocom_" MIME-Version: 1.0 Archived-At: Cc: "draft-bowbakova-rtgwg-enterprise-pa-multihoming@ietf.org" , rtgwg-chairs X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 12:51:37 -0000 --_000_D4DED06AA0ACEaceeciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Chris, It is better to at least identify extensions and possible changes to existi= ng standards now rather than later in the process. Can these be explicitly = called out when the document status is changed to informational? Thanks, Acee From: Chris Bowers > Date: Thursday, March 2, 2017 at 6:48 PM To: Acee Lindem >, Jeff Tantsura >, Routing WG > Cc: "draft-bowbakova-rtgwg-enterprise-pa-multihoming@ietf.org" >, rtgwg-chairs > Subject: RE: WG adoption call for draft-bowbakova-rtgwg-enterprise-pa-multi= homing Acee, The authors are OK with making this document informational. It is intended= to provide a description of the different parts of an overall solution to = this problem (with a few variants). Anything new that needs to be standard= ized will be addressed in separate documents in the appropriate working gro= up. Thanks, Chris From: Acee Lindem (acee) [mailto:acee@cisco.com] Sent: Tuesday, February 21, 2017 5:27 PM To: Jeff Tantsura >= ; RTGWG > Cc: draft-bowbakova-rtgwg-enterprise-pa-multihoming@ietf.org; rtgwg-chairs > Subject: Re: WG adoption call for draft-bowbakova-rtgwg-enterprise-pa-multi= homing Hi Jeff, The document is standards track. Can the authors summarize what is being st= andardized as opposed to informational? I think we need to determine whethe= r this work belongs in RTGWG or 6MAN. Thanks, Acee From: rtgwg > on beha= lf of Jeff Tantsura > Date: Tuesday, February 21, 2017 at 6:19 PM To: Routing WG > Cc: "draft-bowbakova-rtgwg-enterprise-pa-multihoming@ietf.org" >, rtgwg-chairs > Subject: WG adoption call for draft-bowbakova-rtgwg-enterprise-pa-multihomi= ng Dear RTGWG, The authors have requested the RTGWG to adopt draft-bowbakova-rtgwg-enterpr= ise-pa-multihoming draft as the working group document. RTGWG chairs have discussed the progress of the draft with v6ops chairs and= got their blessing. Please indicate support or no-support by March 8th, 2017. IPR: If you are listed as a document author or contributor, please respond to th= is email. of whether or not you are aware of any relevant IPR. The response needs to = be sent to the RTGWG mailing list. The document will not advance to the next stage until a response has been r= eceived from each author and each individual that has contributed to the document. Thanks, Jeff & Chris --_000_D4DED06AA0ACEaceeciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Chris, 

It is better to at least identify extensions and possible changes to e= xisting standards now rather than later in the process. Can these be explic= itly called out when the document status is changed to informational? =

Thanks,
Acee

From: Chris Bowers <cbowers@juniper.net>
Date: Thursday, March 2, 2017 at 6:= 48 PM
To: Acee Lindem <acee@cisco.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Routing WG &l= t;rtgwg@ietf.org>
Cc: "draft-bowbakova-rtgwg-en= terprise-pa-multihoming@ietf.org" <draft-bowbakova-rtgwg-enter= prise-pa-multihoming@ietf.org>, rtgwg-chairs <rtgwg-chairs@iet= f.org>
Subject: RE: WG adoption call for d= raft-bowbakova-rtgwg-enterprise-pa-multihoming

Acee,=

=  

The a= uthors are OK with making this document informational.  It is intended= to provide a description of the different parts of an overall solution to = this problem (with a few variants).  Anything new that needs to be standardized will be addressed in separate documents = in the appropriate working group.

=  

Thank= s,

Chris=

=  

From:= Acee Lindem (acee) [mailto:acee@cisco.com]
Sent: Tuesday, February 21, 2017 5:27 PM
To: Jeff Tantsura <jef= ftant.ietf@gmail.com>; RTGWG <r= tgwg@ietf.org>
Cc: draft-bowbakova-rtgwg-enterprise-pa-multihoming@ietf.org; rtgwg-chairs = <rtgwg-chairs@ietf.org><= br> Subject: Re: WG adoption call for draft-bowbakova-rtgwg-enterprise-p= a-multihoming

 

Hi Jeff= , 

&n= bsp;

The doc= ument is standards track. Can the authors summarize what is being standardi= zed as opposed to informational? I think we need to determine whether this = work belongs in RTGWG or 6MAN.  

&n= bsp;

Thanks,=

Acee&nb= sp;

&n= bsp;

From= : rtgwg <rtgwg-bounces@ietf.org> on behalf= of Jeff Tantsura <jefftant.i= etf@gmail.com>
Date: Tuesday, February 21, 2017 at 6:19 PM
To: Routing WG <rtgwg@ietf.org<= /a>>
Cc: "draft-bowbakova-rtgwg-enterprise-pa-multihoming@ietf.org<= /a>" <draft-bowbakova-rtgwg-enterprise-pa-multihoming@ietf.org= >, rtgwg-chairs <rtgwg-chairs@iet= f.org>
Subject: WG adoption call for draft-bowbakova-rtgwg-enterprise-pa-mu= ltihoming

&n= bsp;

Dear RT= GWG,

 <= /span>

The aut= hors have requested the RTGWG to adopt draft-bowbakova-rtgwg-enterprise-pa-= multihoming draft as the working group document.

RTGWG c= hairs have discussed the progress of the draft with v6ops chairs and got th= eir blessing.

Please = indicate support or no-support by March 8th, 2017.

IPR:

If you = are listed as a document author or contributor, please respond to this emai= l.

of whet= her or not you are aware of any relevant IPR. The response needs to be sent= to the RTGWG mailing list.

The doc= ument will not advance to the next stage until a response has been received= from each author and each

individ= ual that has contributed to the document.

Thanks,=

Jeff &a= mp; Chris

 --_000_D4DED06AA0ACEaceeciscocom_-- From nobody Fri Mar 3 05:45:37 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F89129892; Fri, 3 Mar 2017 05:45:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uclouvain.be 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 NXRr7Dj-ROXY; Fri, 3 Mar 2017 05:45:34 -0800 (PST) Received: from smtp3.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A66A129542; Fri, 3 Mar 2017 05:45:34 -0800 (PST) Received: from mbpobo.dhcp.info.ucl.ac.be (mbpobo.dhcp.info.ucl.ac.be [130.104.228.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp3.sgsi.ucl.ac.be) by smtp3.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 5AB0967DB3F; Fri, 3 Mar 2017 14:45:25 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.9.2 smtp3.sgsi.ucl.ac.be 5AB0967DB3F DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1488548725; bh=Cd7az/aLfxC+5tsjhurSQLwYS6vopKc8MsyAXxKZlCI=; h=Reply-To:Subject:References:To:Cc:From:Date:In-Reply-To; b=mKHcMS9pXdeyVcU8yHUe6hVqLbRPXUcMMHvlWHICqMRq1BYNY4uz/4oSZrNSmpbp8 eePvSVG7SgGZt+GpctUqvEvdESp203AxUlUurnz9vZWWeNrnXmT1WCM+cYXGIzDIIv aQHY8Mw8UQPRuvN92ZJqBR0et6swCm7PkkW/UaeQ= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99.2 at smtp-3 Subject: Re: WG adoption call for draft-bowbakova-rtgwg-enterprise-pa-multihoming References: <75FE1936-DC60-4914-BF94-E7EC7DCF5AE9@gmail.com> To: Jeff Tantsura , RTGWG From: Olivier Bonaventure Message-ID: <062b23c5-dc58-fff8-750b-4167018b3f3c@uclouvain.be> Date: Fri, 3 Mar 2017 14:45:34 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <75FE1936-DC60-4914-BF94-E7EC7DCF5AE9@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-Information: X-SGSI-MailScanner-ID: 5AB0967DB3F.A54DA X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Cc: draft-bowbakova-rtgwg-enterprise-pa-multihoming@ietf.org, rtgwg-chairs X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 13:45:36 -0000 Hello, > > > The authors have requested the RTGWG to adopt > draft-bowbakova-rtgwg-enterprise-pa-multihoming draft as the working > group document. > > RTGWG chairs have discussed the progress of the draft with v6ops chairs > and got their blessing. > > Please indicate support or no-support by March 8th, 2017. I support this document. It would be nice if it could at least explore the role that other protocols could play in solving this enterprise multihoming problem that remains difficult to solve. For example, Multipath TCP would enable hosts to easily use different uplink providers and react to failures and congestion quickly. If there is some interest in this group, we're ready to contribute and develop prototypes based on the Linux MPTCP stack. Olivier From nobody Fri Mar 3 12:03:41 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4721295EE; Fri, 3 Mar 2017 12:03:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 rnoDmobQ5Yed; Fri, 3 Mar 2017 12:03:38 -0800 (PST) Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (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 383A01295D2; Fri, 3 Mar 2017 12:03:38 -0800 (PST) Received: by mail-pf0-x241.google.com with SMTP id e66so5071146pfe.0; Fri, 03 Mar 2017 12:03:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=+W5Kp2oTZsmL6S8bx772QLmi4eTEPt1Mp8d0+gFwzss=; b=AGdO0/NxhtJtOfr/Z1W0+PEcOsqVysXDThlVtdLazgKn2itdk7tTexFQVhHYMg91QI CdjDMW4GN9cqfzxe7oW6yENNOYOYMuqhpc5J+x07S+ZXD296pInIGgMy0uEJ+gkhHfqU RFNU/mNO8OLjTFr9n0bmvPMdCRrZla6LpWMLeZqYXGVsKu1UuvCmnfZ69x+QcCecE5pD ZEOZHcSza0OKkXwJDazHt1ihq4dDHFiPbUHKCER4Ov8fLUxqIQBvT9LqtMtsVVlXd/yE ugk/8U7v+8QPzyhuH9zY1uTRyTl9oxPd8QoOsLsaiKKKDUDd9Ubj5z3baYSv4ll7bmSP IrSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=+W5Kp2oTZsmL6S8bx772QLmi4eTEPt1Mp8d0+gFwzss=; b=HZwR1BJf2PQ+aRZyMwQKH+g9zKBsmfcbhpiUemM563H7FWxEjGPDSlOO+sA9U5vYOn nHgpcz3ur2Vr056oK0B5uKLK9teLzQ7IWGKnm2GzUVqOFYW4ovXU5D3B9LCZhWOQPf6+ rWrnTKJD1zkOPtzPxi4qsX6NJHFa6meQKCpFXIUMre5MxiqqNaqAqXxvAk9AbAWENAH1 L+k6LBAh5tzq09Krsd/32G0bywgzeSXvonah9fBBAphCzuyzSLrJ+YZOFpbLPYNcy6s3 ppnvvaqN3nTa9dZIN1DoAJhuRFhUohuTyGkR1l9lLDluzDUqvb5UMTAIC2YJ19v6OuQA 0ivQ== X-Gm-Message-State: AMke39nQIx833rgX78/1382sNfFfxurXmfbSxeSHikKPuplE9ZVCL92YJACFvSSZU9CzAA== X-Received: by 10.84.146.140 with SMTP id g12mr6618340pla.70.1488571417751; Fri, 03 Mar 2017 12:03:37 -0800 (PST) Received: from [192.168.254.57] (107-1-141-74-ip-static.hfc.comcastbusiness.net. [107.1.141.74]) by smtp.gmail.com with ESMTPSA id v9sm24952228pfl.102.2017.03.03.12.03.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Mar 2017 12:03:36 -0800 (PST) User-Agent: Microsoft-MacOutlook/f.1f.0.170216 Date: Fri, 03 Mar 2017 12:03:35 -0800 Subject: Re: WG adoption call for draft-bowbakova-rtgwg-enterprise-pa-multihoming From: Jeff Tantsura To: , RTGWG Message-ID: <28E422F6-1D1E-491A-92C6-DA54D070DDAC@gmail.com> Thread-Topic: WG adoption call for draft-bowbakova-rtgwg-enterprise-pa-multihoming References: <75FE1936-DC60-4914-BF94-E7EC7DCF5AE9@gmail.com> <062b23c5-dc58-fff8-750b-4167018b3f3c@uclouvain.be> In-Reply-To: <062b23c5-dc58-fff8-750b-4167018b3f3c@uclouvain.be> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Cc: draft-bowbakova-rtgwg-enterprise-pa-multihoming@ietf.org, rtgwg-chairs X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 20:03:39 -0000 Hi Olivier, Thanks for your comments! It would be great if you could provide more insides. Thanks! Cheers, Jeff On 3/3/17, 05:45, "Olivier Bonaventure" wrote: Hello, > > > The authors have requested the RTGWG to adopt > draft-bowbakova-rtgwg-enterprise-pa-multihoming draft as the working > group document. > > RTGWG chairs have discussed the progress of the draft with v6ops chairs > and got their blessing. > > Please indicate support or no-support by March 8th, 2017. I support this document. It would be nice if it could at least explore the role that other protocols could play in solving this enterprise multihoming problem that remains difficult to solve. For example, Multipath TCP would enable hosts to easily use different uplink providers and react to failures and congestion quickly. If there is some interest in this group, we're ready to contribute and develop prototypes based on the Linux MPTCP stack. Olivier From nobody Fri Mar 3 15:56:16 2017 Return-Path: X-Original-To: rtgwg@ietf.org Delivered-To: rtgwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 86660126D73; Fri, 3 Mar 2017 15:55:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Subject: rtgwg - Requested sessions have been scheduled for IETF 98 X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148858532054.15846.9935588286852558065.idtracker@ietfa.amsl.com> Date: Fri, 03 Mar 2017 15:55:20 -0800 Archived-At: Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 23:55:20 -0000 Dear Jeff Tantsura, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. rtgwg Session 1 (2:00:00) Thursday, Afternoon Session II 1520-1720 Room Name: Zurich E/F size: 200 --------------------------------------------- rtgwg Session 2 (2:30:00) Wednesday, Morning Session I 0900-1130 Room Name: Vevey 1/2 size: 200 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Routing Area Working Group Area Name: Routing Area Session Requester: Jeff Tantsura Number of Sessions: 2 Length of Session(s): 2 Hours, 2.5 Hours Number of Attendees: 150 Conflicts to Avoid: First Priority: isis mpls ospf pce idr spring Second Priority: bess bier teas ccamp i2rs l2sm Third Priority: bfd detnet lime nvo3 pim netmod People who must be present: Alia Atlas Jeff Tantsura Chris Bowers Resources Requested: Meetecho support in room Special Requests: --------------------------------------------------------- From nobody Sat Mar 4 08:06:31 2017 Return-Path: X-Original-To: rtgwg@ietf.org Delivered-To: rtgwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 51D4D1293E0; Sat, 4 Mar 2017 08:06:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-rtgwg-routing-types-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148864358733.23449.15917361946646832830.idtracker@ietfa.amsl.com> Date: Sat, 04 Mar 2017 08:06:27 -0800 Archived-At: Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2017 16:06:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Area Working Group of the IETF. Title : Routing Area Common YANG Data Types Authors : Xufeng Liu Yingzhen Qu Acee Lindem Christian Hopps Lou Berger Filename : draft-ietf-rtgwg-routing-types-02.txt Pages : 24 Date : 2017-03-04 Abstract: This document defines a collection of common data types using the YANG data modeling language. These derived common types are designed to be imported by other modules defined in the routing area. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-routing-types/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtgwg-routing-types-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-routing-types-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 6 18:24:28 2017 Return-Path: <7riw77@gmail.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4BCA1294BA; Mon, 6 Mar 2017 18:24:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 zanW2km9yiHv; Mon, 6 Mar 2017 18:24:21 -0800 (PST) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::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 1432E1294FD; Mon, 6 Mar 2017 18:24:21 -0800 (PST) Received: by mail-it0-x234.google.com with SMTP id m27so63304747iti.1; Mon, 06 Mar 2017 18:24:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=PamPBwZ30E60i3moGRUuA6/we9uKyfnteJSm0s6DrWg=; b=bR0uHbNcwzLmPzEJKOGXKVqvf3U5Be9BbsRCvHeXHdC+lWvrpUbBh6ATQU2spQJFI5 EQ9GZuvQMDRMhI/WjHXICKnfZ4zA5Rf/QjgHstdN0sqZggja+VFYWcMDmZWuMTRWzf9r 0HQ/Cpnj/VmCW4fTJ6DOtHEecF4uTS8IgwmrHJ24zg9vqSBqif/+O0tlRFQ2ytzW9bVK jmAifFcGsnGSKxfbW3A5I6+hYsBqZhSWCqUYxqDiS/Zhd1qrTUDS36g7xNwxC8DsJu+4 ENjrRVo96JUdCDnO2TABdnD3ZSLvwLM5oFdkayKyPzsVMKT0N+tal34t1HBTdOqmbRBG 6bGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=PamPBwZ30E60i3moGRUuA6/we9uKyfnteJSm0s6DrWg=; b=Txs6kPResD5xy2WIXdZlP4TSKChky1r/M7Oa+dbDkSbZkFCiEuon7AWRD9HDwrK8Z+ HhOpBTcbWUzPM4jpUl5fcJ2H1LW6H3OjGO0+i3dyywaG6h3j5ZpZYiWE+lmYVnBWiuL0 d9/3gRm6O+CSh5f4tCccnlJgOf4mqnUaOMzsib4n8MZMdqdyBzFhYR2ItUvDQU1UighK Pu/+wBoGlcZz36bhtOzPra2zyGrN0JZz64yYYZqzcXPD6PjplgGOoStFbsSTfg09g9P/ zKl10emR7+7rEQOUIAIF5RAbgABYgs/Js/3LiSchM4FWanbKbuplsFzCAs49Gw+r+M4V oiPQ== X-Gm-Message-State: AMke39mVSGq8iXj1ngOh+Zu1HqDQGVZqo2DIPkd9ut7WR9M+wOWYwKxZbQL9j53RgYLHBg== X-Received: by 10.36.9.209 with SMTP id 200mr18894171itm.44.1488853460200; Mon, 06 Mar 2017 18:24:20 -0800 (PST) Received: from Russ (162-229-180-77.lightspeed.rlghnc.sbcglobal.net. [162.229.180.77]) by smtp.gmail.com with ESMTPSA id j85sm9477624iod.27.2017.03.06.18.24.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Mar 2017 18:24:19 -0800 (PST) From: "Russ White" <7riw77@gmail.com> To: , References: <148856628065.15830.3525312125332246258.idtracker@ietfa.amsl.com> In-Reply-To: <148856628065.15830.3525312125332246258.idtracker@ietfa.amsl.com> Subject: FW: I-D Action: draft-white-openfabric-00.txt Date: Mon, 6 Mar 2017 21:24:17 -0500 Message-ID: <02ee01d296e9$ec570d00$c5052700$@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: AQNWQt4E90XAKMHWxi2c/u65al3g3p6BTbjw Content-Language: en-us Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 02:24:23 -0000 FYI. :-) Russ > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Friday, March 3, 2017 1:38 PM > To: i-d-announce@ietf.org > Subject: I-D Action: draft-white-openfabric-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : OpenFabric > Authors : Russ White > Shawn Zandi > Filename : draft-white-openfabric-00.txt > Pages : 13 > Date : 2017-03-03 > > Abstract: > Spine and leaf topologies are widely used in hyperscale and cloud > scale networks. In most of these networks, configuration is > automated, but difficult, and topology information is extracted > through broad based connections. Policy is often integrated into the > control plane, as well, making configuration, management, and > troubleshooting difficult. OpenFabric is an adaptation of an > existing, widely deployed link state protocol, Intermediate Sytem to > Intermediate System (IS-IS) that is designed to: > > o Provide a full view of the topology from a single point in the > network to simplify operations > > o Minimize configuration of each router (or switch) in the network > > o Optimize the operation of IS-IS within a spine and leaf fabric to > enable scaling > > This document begins with an overview of OpenFabric, including a > description of what may be removed from IS-IS to enable scaling. The > document then describes an optimized adjacency formation process; an > optimized flooding scheme; some thoughts on the operation of > OpenFabric, metrics, and aggregation; and finally a description of > the changes to the IS-IS protocol required for OpenFabric. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-white-openfabric/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-white-openfabric-00 > > > 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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Mon Mar 6 21:14:02 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1FA312940D; Mon, 6 Mar 2017 21:13:56 -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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJMQ9SobW6OR; Mon, 6 Mar 2017 21:13:55 -0800 (PST) Received: from gilfert.gredler.at (gilfert.gredler.at [87.106.222.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52F3312945E; Mon, 6 Mar 2017 21:13:55 -0800 (PST) Received: from hannes-mba.local ([::ffff:106.51.148.98]) (AUTH: PLAIN hannes, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by gilfert.gredler.at with ESMTPSA; Tue, 07 Mar 2017 06:13:50 +0100 id 00000000038C83CE.0000000058BE418E.000022F3 Subject: Re: FW: I-D Action: draft-white-openfabric-00.txt To: Russ White <7riw77@gmail.com>, rtgwg@ietf.org, isis-wg@ietf.org References: <148856628065.15830.3525312125332246258.idtracker@ietfa.amsl.com> <02ee01d296e9$ec570d00$c5052700$@gmail.com> From: Hannes Gredler Message-ID: <4e4d4333-9a0e-1e03-955a-cdf9b7072373@gredler.at> Date: Tue, 7 Mar 2017 06:13:47 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit In-Reply-To: <02ee01d296e9$ec570d00$c5052700$@gmail.com> X-Mime-Autoconverted: from 8bit to 7bit by courier 0.66 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 05:13:57 -0000 hi russ, couple of comments / questions. 1) --- OpenFabric implementations MUST NOT be mixed with standard IS-IS implementations in operational deployments. OpenFabric and standard IS-IS implementations SHOULD be treated as two separate protocols. --- any hard feelings about using MI as a way of guaranteeing that the two protocols are shielded from each other ? 2) Modified Adjacency Formation rather than doing the "only one adjacency is up" (which we did prior to the graceful-restart SA bit) - suggest to use the graceful-restart 'SA' bit, such that a node can bring up the adjacency without generating a new LSP. The LSP can then be generated if the initial-sync is done (and the new LSP arrival rate indicates that the dust is settling) such that the LSP may get released. 3) Flooding Optimization it looks to me you have re-invented the OLSR MPR set. https://tools.ietf.org/html/rfc3626#section-8.2 perhaps you may want to add a reference. /hannes On 3/7/17 3:24, Russ White wrote: > > FYI. > > :-) > > Russ > >> -----Original Message----- >> From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of >> internet-drafts@ietf.org >> Sent: Friday, March 3, 2017 1:38 PM >> To: i-d-announce@ietf.org >> Subject: I-D Action: draft-white-openfabric-00.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts > directories. >> >> >> Title : OpenFabric >> Authors : Russ White >> Shawn Zandi >> Filename : draft-white-openfabric-00.txt >> Pages : 13 >> Date : 2017-03-03 >> >> Abstract: >> Spine and leaf topologies are widely used in hyperscale and cloud >> scale networks. In most of these networks, configuration is >> automated, but difficult, and topology information is extracted >> through broad based connections. Policy is often integrated into the >> control plane, as well, making configuration, management, and >> troubleshooting difficult. OpenFabric is an adaptation of an >> existing, widely deployed link state protocol, Intermediate Sytem to >> Intermediate System (IS-IS) that is designed to: >> >> o Provide a full view of the topology from a single point in the >> network to simplify operations >> >> o Minimize configuration of each router (or switch) in the network >> >> o Optimize the operation of IS-IS within a spine and leaf fabric to >> enable scaling >> >> This document begins with an overview of OpenFabric, including a >> description of what may be removed from IS-IS to enable scaling. The >> document then describes an optimized adjacency formation process; an >> optimized flooding scheme; some thoughts on the operation of >> OpenFabric, metrics, and aggregation; and finally a description of >> the changes to the IS-IS protocol required for OpenFabric. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-white-openfabric/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-white-openfabric-00 >> >> >> 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/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html or >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > From nobody Mon Mar 6 21:37:42 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A51CF1294B7; Mon, 6 Mar 2017 21:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 NYHygRc4_GU1; Mon, 6 Mar 2017 21:37:35 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 345EA127078; Mon, 6 Mar 2017 21:37:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5089; q=dns/txt; s=iport; t=1488865055; x=1490074655; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=sfVmbH8ox5VwPOWzS2uHPBhqcZYVnz4d6JdUZ3sLT90=; b=muU3sLt31jh5YS2GeYyq1NdVpDiPNmEA9yo6LMsYooqTInCDzncLVsjc 9a6Cd355E0HIVpJL1B3RoX6gRmr7b/4xISUc/oxseMwpwFEVLyd+maISH v2JmO9c1wB+toanDP3QXuqqKEvXcIknQcq1AZKP55avtq5YO4H+ybRpcH A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQDURr5Y/5ldJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgycqYYEKB41kkUmVN4INHwuFeAKCKD8YAQIBAQEBAQEBayiFFQE?= =?us-ascii?q?BAQMBAQE4NBcEAgEIEQQBAQEeCQcnCxQJCAIEARIIAYlrCA6yAop4AQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBHYZOhG+FBoUzBZVghkwBhnWLNIIEU4RPhHCFEop2iEQ?= =?us-ascii?q?BHziBA1YVGCeEUwEdgWIBdQGIZ4ENAQEB?= X-IronPort-AV: E=Sophos;i="5.35,257,1484006400"; d="scan'208";a="215129518" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Mar 2017 05:37:25 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v275bQQO027193 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 7 Mar 2017 05:37:26 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 6 Mar 2017 23:37:25 -0600 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1210.000; Mon, 6 Mar 2017 23:37:25 -0600 From: "Les Ginsberg (ginsberg)" To: Hannes Gredler , Russ White <7riw77@gmail.com>, "rtgwg@ietf.org" , "isis-wg@ietf.org" Subject: RE: [Isis-wg] FW: I-D Action: draft-white-openfabric-00.txt Thread-Topic: [Isis-wg] FW: I-D Action: draft-white-openfabric-00.txt Thread-Index: AQNWQt4E90XAKMHWxi2c/u65al3g3p6BTbjwgACUU4D//5/HEA== Date: Tue, 7 Mar 2017 05:37:25 +0000 Message-ID: References: <148856628065.15830.3525312125332246258.idtracker@ietfa.amsl.com> <02ee01d296e9$ec570d00$c5052700$@gmail.com> <4e4d4333-9a0e-1e03-955a-cdf9b7072373@gredler.at> In-Reply-To: <4e4d4333-9a0e-1e03-955a-cdf9b7072373@gredler.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.105.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 05:37:36 -0000 Russ - Could you also clarify who sets the "DNR" bit in an LSP and when? Is it the originator or one or more of the receivers? And does it have the = same state when flooded on all links or does it vary from link to link? If the state of the bit is modified as part of the flooding I don't see how= this works since it would also require recalculation of the checksum/authe= ntication hash - and the LSP would no longer "look like" the original. Les > -----Original Message----- > From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Hannes > Gredler > Sent: Monday, March 06, 2017 9:14 PM > To: Russ White; rtgwg@ietf.org; isis-wg@ietf.org > Subject: Re: [Isis-wg] FW: I-D Action: draft-white-openfabric-00.txt >=20 > hi russ, >=20 > couple of comments / questions. >=20 > 1) > --- > OpenFabric implementations MUST NOT be mixed with standard IS-IS > implementations in operational deployments. OpenFabric and standard > IS-IS implementations SHOULD be treated as two separate protocols. > --- >=20 > any hard feelings about using MI as a way of guaranteeing that the two > protocols are shielded from each other ? >=20 > 2) Modified Adjacency Formation >=20 > rather than doing the "only one adjacency is up" (which we did prior to t= he > graceful-restart SA bit) - suggest to use the graceful-restart 'SA' > bit, such that a node can bring up the adjacency without generating a new > LSP. The LSP can then be generated if the initial-sync is done (and the n= ew > LSP arrival rate indicates that the dust is settling) such that the LSP m= ay get > released. >=20 > 3) Flooding Optimization > it looks to me you have re-invented the OLSR MPR set. > https://tools.ietf.org/html/rfc3626#section-8.2 > perhaps you may want to add a reference. >=20 > /hannes >=20 > On 3/7/17 3:24, Russ White wrote: > > > > FYI. > > > > :-) > > > > Russ > > > >> -----Original Message----- > >> From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf > >> Of internet-drafts@ietf.org > >> Sent: Friday, March 3, 2017 1:38 PM > >> To: i-d-announce@ietf.org > >> Subject: I-D Action: draft-white-openfabric-00.txt > >> > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > >> > >> > >> Title : OpenFabric > >> Authors : Russ White > >> Shawn Zandi > >> Filename : draft-white-openfabric-00.txt > >> Pages : 13 > >> Date : 2017-03-03 > >> > >> Abstract: > >> Spine and leaf topologies are widely used in hyperscale and cloud > >> scale networks. In most of these networks, configuration is > >> automated, but difficult, and topology information is extracted > >> through broad based connections. Policy is often integrated into t= he > >> control plane, as well, making configuration, management, and > >> troubleshooting difficult. OpenFabric is an adaptation of an > >> existing, widely deployed link state protocol, Intermediate Sytem t= o > >> Intermediate System (IS-IS) that is designed to: > >> > >> o Provide a full view of the topology from a single point in the > >> network to simplify operations > >> > >> o Minimize configuration of each router (or switch) in the > >> network > >> > >> o Optimize the operation of IS-IS within a spine and leaf fabric t= o > >> enable scaling > >> > >> This document begins with an overview of OpenFabric, including a > >> description of what may be removed from IS-IS to enable scaling. T= he > >> document then describes an optimized adjacency formation process; a= n > >> optimized flooding scheme; some thoughts on the operation of > >> OpenFabric, metrics, and aggregation; and finally a description of > >> the changes to the IS-IS protocol required for OpenFabric. > >> > >> > >> The IETF datatracker status page for this draft is: > >> https://datatracker.ietf.org/doc/draft-white-openfabric/ > >> > >> There's also a htmlized version available at: > >> https://tools.ietf.org/html/draft-white-openfabric-00 > >> > >> > >> 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/ > >> > >> _______________________________________________ > >> I-D-Announce mailing list > >> I-D-Announce@ietf.org > >> https://www.ietf.org/mailman/listinfo/i-d-announce > >> Internet-Draft directories: http://www.ietf.org/shadow.html or > >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > _______________________________________________ > > rtgwg mailing list > > rtgwg@ietf.org > > https://www.ietf.org/mailman/listinfo/rtgwg > > >=20 > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg From nobody Tue Mar 7 06:31:26 2017 Return-Path: <7riw77@gmail.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F48A1293E3; Tue, 7 Mar 2017 05:33: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 zhkNQylUp30p; Tue, 7 Mar 2017 05:33:51 -0800 (PST) Received: from mail-qk0-x242.google.com (mail-qk0-x242.google.com [IPv6:2607:f8b0:400d:c09::242]) (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 99827129416; Tue, 7 Mar 2017 05:33:51 -0800 (PST) Received: by mail-qk0-x242.google.com with SMTP id n141so620999qke.3; Tue, 07 Mar 2017 05:33:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=UWQRR2DemsbgY+IV6p9drAdqT1gnzLT1ExcN3XO3VhQ=; b=vOh9iefSC5JpxuGafq6r30gC+tlD+j6z7X5ZOzW/Hp7rnx+Pf5K3EzcGFqTOaHrEIR KwJnsu+Ik29em4pvrQJJYOnwN2nqLwgM8Y2vNa3NZQRli0HVTwyjZpvq+ikkaXvn9Vvt o4X8ZtYxsenhwaijW8PhNxd8iuR+I9JaPQvQde5YvmCRWM/r6OOWmqXNU6RXjPYezo5a Axm7QdYARp0HaTzHNmrnjWmhlyoj9fe1nYJqIQxEbryKb82HgnFq3Zl7yNaThD+eoLgP +p2mkTWCvFwG+kpGTtZHOFn3jIy3ApANDm6+/pBp5QyDe4EzD3hEqm9bExQvVcV/rftT cVlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=UWQRR2DemsbgY+IV6p9drAdqT1gnzLT1ExcN3XO3VhQ=; b=hgp6eo0bzoAkvcfTQ6LXcbWRUTFh1eoWjmLz7O3LTNEGd7KU5+A/wxR2ehyI+Xvmtp Lfwgd2YOQZh0+yoBQuVJ0ObQaZYxmQne0DYv3+AQMgbfXrA5gdNlVI7Nj3VvnRRo4bHO 9HRMAjOhotulXI8ijfoZWVOfeEzuv2DGzAp2RVXsKqcKwAWssIum0subMvHAUobnrDIr 39RQkd5arz8R1vWI213KZYfhSrhlOh+qYJHO9laMX1zduh+W34eCRadVaRIoTa7u4RjW 2x+T1W7LPvu/hMRXuEWpiQR4oII0vQa2SkjaN+WRBdyddYj9EYl61VrTBCM2/Gz04+Bh Ifhg== X-Gm-Message-State: AMke39mlIneK46ndAhic2N34bnQORddvczMp8/3rIEuSdVeBKvmnVXnhUYCJlJWJLFWK8A== X-Received: by 10.37.172.198 with SMTP id x6mr153197ybd.7.1488893630636; Tue, 07 Mar 2017 05:33:50 -0800 (PST) Received: from Russ (162-229-180-77.lightspeed.rlghnc.sbcglobal.net. [162.229.180.77]) by smtp.gmail.com with ESMTPSA id a11sm16765ywe.1.2017.03.07.05.33.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Mar 2017 05:33:50 -0800 (PST) From: "Russ White" <7riw77@gmail.com> To: "'Les Ginsberg \(ginsberg\)'" , "'Hannes Gredler'" , , References: <148856628065.15830.3525312125332246258.idtracker@ietfa.amsl.com> <02ee01d296e9$ec570d00$c5052700$@gmail.com> <4e4d4333-9a0e-1e03-955a-cdf9b7072373@gredler.at> In-Reply-To: Subject: RE: [Isis-wg] FW: I-D Action: draft-white-openfabric-00.txt Date: Tue, 7 Mar 2017 08:33:47 -0500 Message-ID: <013701d29747$733c2780$59b47680$@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: AQNWQt4E90XAKMHWxi2c/u65al3g3gG7LIHEAm3O8PcCVVa30p5OFk8g Content-Language: en-us Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 13:33:52 -0000 > If the state of the bit is modified as part of the flooding I don't see how this > works since it would also require recalculation of the > checksum/authentication hash - and the LSP would no longer "look like" the > original. You are correct -- I missed this. It kept naggling in the back of my mind that I wanted this to be a part of the packet, not the lsp, but I couldn't think why. The DNR bit needs to be in the packet header, but there are no bits there. Any ideas? :-) Russ From nobody Tue Mar 7 06:37:21 2017 Return-Path: <7riw77@gmail.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27C5512947A; Tue, 7 Mar 2017 05:36:33 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Fw8j4s9pA4EY; Tue, 7 Mar 2017 05:36:31 -0800 (PST) Received: from mail-ua0-x242.google.com (mail-ua0-x242.google.com [IPv6:2607:f8b0:400c:c08::242]) (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 7525A129486; Tue, 7 Mar 2017 05:36:19 -0800 (PST) Received: by mail-ua0-x242.google.com with SMTP id u30so383363uau.2; Tue, 07 Mar 2017 05:36:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=jLzAXyhS2nQXRBj8g7HxNEcDhhme7qtI5O5aGTnqZZY=; b=DekU7P2ItOkZaueKERVn7yo6z6Zg+zRR+sC9jX8nlVtqvQDu1tCWdbYRytrKyNmNu4 WVsCp9xqeX9oL0ooY1/HODqlsMFWAaoLwWC+N1mk8VcZp0u7n+K1I92rA8FnTE5qeTim BWU/OLY/4Msclw26uYSHG3egApSGQTYqqFgyiCxtLnOkc1bh0b5x9RQHzj2DmWaSBDRr /1QIBuTjvn1/aRn3+6u30kYbmYNQnwXWZ7CjRKffOHDnPJG2MDxwiNx9tQ5zSBlV6nGJ xAsL4VBB7sw1cU2uvMM3cRiq+6GiHaWlAX+NkOpKgo9JQpMQh213OH9QvCMjLMTVmriu w1/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=jLzAXyhS2nQXRBj8g7HxNEcDhhme7qtI5O5aGTnqZZY=; b=gUZ8ZL5t1d8/WSVHhV2SM7d3N1v4ChGs70AJhsXsPBhy0mIuoLy0Rb8kGXQv9rZ/fi wZ4NffzeCpvz7qgp+XMpObKAE2/8X9kniERt1Lms6q7WA56dzOMDTt79NUyXbux+VI7F w77jYADoB55XL8AKaPtOS2lD2Q1qMawgVZvs6U9jRvFQ6cQJf4V4Do5B5i2Q6VeNYlGp rfLRoL9xjhPNFFdn3M2lqDf34N3RUb8MvUBAhSQidLxM/qfASU5NBZVwBtSG5OMJvIV+ IM21U7JpVKllgasg3CK6NLnJPBkkscoy6wkiU3g/qSycVkTivMZQnhjsVmWHS7f0tidc +d+A== X-Gm-Message-State: AMke39lQ1JMV/kWZuKNlRmngXRSgn3BQZOirbM0kb7cbXi5UkqM4eAnNsOY2GvGWF5wCtQ== X-Received: by 10.37.173.85 with SMTP id l21mr180355ybe.68.1488893778499; Tue, 07 Mar 2017 05:36:18 -0800 (PST) Received: from Russ (162-229-180-77.lightspeed.rlghnc.sbcglobal.net. [162.229.180.77]) by smtp.gmail.com with ESMTPSA id x3sm16093ywd.16.2017.03.07.05.36.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Mar 2017 05:36:18 -0800 (PST) From: "Russ White" <7riw77@gmail.com> To: "'Hannes Gredler'" , , References: <148856628065.15830.3525312125332246258.idtracker@ietfa.amsl.com> <02ee01d296e9$ec570d00$c5052700$@gmail.com> <4e4d4333-9a0e-1e03-955a-cdf9b7072373@gredler.at> In-Reply-To: <4e4d4333-9a0e-1e03-955a-cdf9b7072373@gredler.at> Subject: RE: FW: I-D Action: draft-white-openfabric-00.txt Date: Tue, 7 Mar 2017 08:36:15 -0500 Message-ID: <013801d29747$cb64f8b0$622eea10$@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: AQNWQt4E90XAKMHWxi2c/u65al3g3gG7LIHEAm3O8PeeYMFX8A== Content-Language: en-us Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 13:36:33 -0000 > OpenFabric implementations MUST NOT be mixed with standard IS-IS > implementations in operational deployments. OpenFabric and standard > IS-IS implementations SHOULD be treated as two separate protocols. > --- > > any hard feelings about using MI as a way of guaranteeing that the two > protocols are shielded from each other ? Very good idea -- want to suggest text? > 2) Modified Adjacency Formation > > rather than doing the "only one adjacency is up" (which we did prior to the > graceful-restart SA bit) - suggest to use the graceful-restart 'SA' > bit, such that a node can bring up the adjacency without generating a new > LSP. The LSP can then be generated if the initial-sync is done (and the new > LSP arrival rate indicates that the dust is settling) such that the LSP may get > released. This is a really good idea, actually... Again, you want to suggest text? :-) > 3) Flooding Optimization > it looks to me you have re-invented the OLSR MPR set. > https://tools.ietf.org/html/rfc3626#section-8.2 > perhaps you may want to add a reference. Very close -- but there's a tiny bit more optimization because of the fixed topology than can be wrung out of that and/or the other MANET drafts. I should actually add ref's to all of them, thanks for pointing this out. :-) Russ From nobody Tue Mar 7 06:44:30 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B48412949E; Tue, 7 Mar 2017 05:39: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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z_9iXPtFfSgQ; Tue, 7 Mar 2017 05:39:12 -0800 (PST) Received: from gilfert.gredler.at (gilfert.gredler.at [87.106.222.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 215921293E3; Tue, 7 Mar 2017 05:39:11 -0800 (PST) Received: from hannes-mba.local ([::ffff:106.51.148.98]) (AUTH: PLAIN hannes, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by gilfert.gredler.at with ESMTPSA; Tue, 07 Mar 2017 14:39:08 +0100 id 0000000003A40C1F.0000000058BEB7FD.000030EE Subject: Re: [Isis-wg] FW: I-D Action: draft-white-openfabric-00.txt To: Russ White <7riw77@gmail.com>, "'Les Ginsberg (ginsberg)'" , rtgwg@ietf.org, isis-wg@ietf.org References: <148856628065.15830.3525312125332246258.idtracker@ietfa.amsl.com> <02ee01d296e9$ec570d00$c5052700$@gmail.com> <4e4d4333-9a0e-1e03-955a-cdf9b7072373@gredler.at> <013701d29747$733c2780$59b47680$@gmail.com> From: Hannes Gredler Message-ID: Date: Tue, 7 Mar 2017 14:38:58 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <013701d29747$733c2780$59b47680$@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 13:39:27 -0000 hi russ, On 3/7/17 14:33, Russ White wrote: > >> If the state of the bit is modified as part of the flooding I don't see > how this >> works since it would also require recalculation of the >> checksum/authentication hash - and the LSP would no longer "look like" the >> original. > > You are correct -- I missed this. It kept naggling in the back of my mind > that I wanted this to be a part of the packet, not the lsp, but I couldn't > think why. The DNR bit needs to be in the packet header, but there are no > bits there. Any ideas? functional MAC addresses ? All-L2-IS-DNR All-L1-IS-DNR /hannes From nobody Tue Mar 7 07:41:39 2017 Return-Path: <7riw77@gmail.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADC22129683; Tue, 7 Mar 2017 06:29:27 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 HPqX4Ly7vDya; Tue, 7 Mar 2017 06:29:27 -0800 (PST) Received: from mail-ot0-x242.google.com (mail-ot0-x242.google.com [IPv6:2607:f8b0:4003:c0f::242]) (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 16D4F129638; Tue, 7 Mar 2017 06:24:47 -0800 (PST) Received: by mail-ot0-x242.google.com with SMTP id x37so389140ota.1; Tue, 07 Mar 2017 06:24:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=SyD7mm+hMFwTsfmqNdFNS9leONuaXq4FtnFuJElPO+o=; b=bu48NT0SVx9iWT7ss/xDMd2H+etpH2UvRXFWQQ7MXaZYf3CN1lkuBUXtghypsZPftF RhvXTabje+KcantA5u/m8XqtNx/nLie65AsyfK/QXEDn1Sznrfh0ZdXlQHj6M/bCBuu+ 31hrMEhBDCuXcUVyY6T+c3nPHU7hy5VT/ndS3G9Azx3YFygNiibGezle8gagHMuTfuR7 S+TqbCF9depMSqq5J3IprN6HTUmwxF6Zjip2skF3Twr8h9X3AOHrD3ym/A2jLaK7V8Sd L8p9hgqOpdlX41txPTG+vmyZ1Ev9n9+t/H4aLUg4bxRQFUvnPLtqd5OXk59cMidHhsDB Nntg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=SyD7mm+hMFwTsfmqNdFNS9leONuaXq4FtnFuJElPO+o=; b=rwxow030wflt0Sfgls+w9aphtnZrNNPBFYIdd4Ak4eSHcf+y5gs3kWeI7nV8erGi4d afUr3UJJoi9C9WxCP6uwDyAXuvseR+ziC/pO4vO1PB1l8NrEnyJqPRK3I3MQa8l7s528 nA4spzLAvWodA8QsVXAuQbdsgxHEFc1LQW3lcng+2xWlreKkepiEnVx82YAT029rsUYu kbCgbMFwsECEzvk9HCgu0TOOqrbAgNjHb93cNytTQzorlw8Ec9MCEiLYPvwmd20CiPux vSZ3aAsUzKjjUaROA1EBrlOzhA9D3lYApJnal9DZfljoGUaUlIYp1FjYdzw1ugRXfMFz esqg== X-Gm-Message-State: AMke39mYe/GxbDAQrpD0juX4P2+spE84us0m0TEiBPxmRDWw2gJSob5dCdqqQHNWZZMwFA== X-Received: by 10.129.93.66 with SMTP id r63mr235472ywb.211.1488896686415; Tue, 07 Mar 2017 06:24:46 -0800 (PST) Received: from Russ (162-229-180-77.lightspeed.rlghnc.sbcglobal.net. [162.229.180.77]) by smtp.gmail.com with ESMTPSA id t3sm58742ywe.19.2017.03.07.06.24.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Mar 2017 06:24:46 -0800 (PST) From: "Russ White" <7riw77@gmail.com> To: "'Hannes Gredler'" , "'Les Ginsberg \(ginsberg\)'" , , References: <148856628065.15830.3525312125332246258.idtracker@ietfa.amsl.com> <02ee01d296e9$ec570d00$c5052700$@gmail.com> <4e4d4333-9a0e-1e03-955a-cdf9b7072373@gredler.at> <013701d29747$733c2780$59b47680$@gmail.com> In-Reply-To: Subject: RE: [Isis-wg] FW: I-D Action: draft-white-openfabric-00.txt Date: Tue, 7 Mar 2017 09:24:42 -0500 Message-ID: <01d501d2974e$90a23b00$b1e6b100$@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: AQNWQt4E90XAKMHWxi2c/u65al3g3gG7LIHEAm3O8PcCVVa30gLI9NLmAVUyB0GeLTNuMA== Content-Language: en-us Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 14:29:28 -0000 > functional MAC addresses ? > > All-L2-IS-DNR > All-L1-IS-DNR Yes -- this is a good idea... :-) Russ From nobody Tue Mar 7 17:14:48 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5E311294A4; Tue, 7 Mar 2017 17:14:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com 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 NaH5E-jO7g_k; Tue, 7 Mar 2017 17:14:43 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0117.outbound.protection.outlook.com [104.47.36.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87642129470; Tue, 7 Mar 2017 17:14:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SayEMS6rB9smnqiAnfS3UPjJLWGPgup9TJynCZfRw28=; b=OmU5zbf5SkHcEV/a5xjXYMQz7TF9ltkoeErHem70ltheDgPFxNUlxJ/FvDGcbfWgzQ5IAZWic3gAKso3EDuGJE6hAfgCDs9CPspCpGLs9JALU/5v/UgaXFcdICE3ixcaFMVr23+qRWRRJD3AJjTBbC4+D4CQ15I6dpvrt/K1ZM8= Received: from MWHPR05MB2829.namprd05.prod.outlook.com (10.168.245.11) by MWHPR05MB2830.namprd05.prod.outlook.com (10.168.245.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.8; Wed, 8 Mar 2017 01:14:41 +0000 Received: from MWHPR05MB2829.namprd05.prod.outlook.com ([10.168.245.11]) by MWHPR05MB2829.namprd05.prod.outlook.com ([10.168.245.11]) with mapi id 15.01.0961.014; Wed, 8 Mar 2017 01:14:41 +0000 From: Chris Bowers To: "Acee Lindem (acee)" , Jeff Tantsura , RTGWG Subject: RE: WG adoption call for draft-bowbakova-rtgwg-enterprise-pa-multihoming Thread-Topic: WG adoption call for draft-bowbakova-rtgwg-enterprise-pa-multihoming Thread-Index: AQHSjJjsm8rXHENtkkGTcGOJ0b6YWaF0GumAgA4lf2CAAOArgIAHGCBw Date: Wed, 8 Mar 2017 01:14:41 +0000 Message-ID: References: <75FE1936-DC60-4914-BF94-E7EC7DCF5AE9@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.239.15] x-microsoft-exchange-diagnostics: 1; MWHPR05MB2830; 7:tUhC/3FZDaBY6bZW1iZXbYHJ8AbgoY29FTLhBvN7o9MMImQLSabNPghXjgKw+WoNkCaUprOqhyQnDtqmswTX8UXaGkYPD5TIWR4jjNFaQ32/s/NTww2q1GMVTMn6gmRtqkK0LVW/yqIwDew5RsnOQ0fq3AyUDGcWAQT+LZRMEgpFbmHhzV0sZbCtUb7VCw4jdVm7RG6osIJuex1OWfNGbHljM71FYu/scHSiROoII7EIwrJnMRJsV9jhULYBTJVFdjeUOIYih0XSYLwt9YtNWtHnlJpZ1qa1QT4UGUqDPq9NHCO5agl5KFvVaslmrc26zMttYJdh8iYhRHfGz94FTw== x-ms-office365-filtering-correlation-id: f3f3822b-d40d-4978-4156-08d465c07fae x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:MWHPR05MB2830; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123562025)(20161123558025)(20161123555025)(20161123564025)(6072148); SRVR:MWHPR05MB2830; BCL:0; PCL:0; RULEID:; SRVR:MWHPR05MB2830; x-forefront-prvs: 02408926C4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39410400002)(39850400002)(39840400002)(39860400002)(377454003)(102836003)(6116002)(55016002)(86362001)(229853002)(790700001)(74316002)(54906002)(76176999)(2906002)(54356999)(4326008)(5660300001)(3846002)(53546006)(50986999)(8936002)(6306002)(77096006)(54896002)(2900100001)(53936002)(99286003)(2950100002)(6246003)(6506006)(6436002)(39060400002)(38730400002)(25786008)(122556002)(7696004)(189998001)(93886004)(236005)(7736002)(81166006)(3280700002)(9686003)(8676002)(3660700001)(230783001)(33656002)(66066001)(106116001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR05MB2830; H:MWHPR05MB2829.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR05MB282914C9B0EE26AB7CF36BA9A92E0MWHPR05MB2829namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2017 01:14:41.5084 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB2830 Archived-At: Cc: "draft-bowbakova-rtgwg-enterprise-pa-multihoming@ietf.org" , rtgwg-chairs X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 01:14:47 -0000 --_000_MWHPR05MB282914C9B0EE26AB7CF36BA9A92E0MWHPR05MB2829namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Acee, Yes. We will more explicitly identify what is already standardized vs. wha= t would need to be standardized in the next version. Chris From: Acee Lindem (acee) [mailto:acee@cisco.com] Sent: Friday, March 3, 2017 6:52 AM To: Chris Bowers ; Jeff Tantsura ; RTGWG Cc: draft-bowbakova-rtgwg-enterprise-pa-multihoming@ietf.org; rtgwg-chairs = Subject: Re: WG adoption call for draft-bowbakova-rtgwg-enterprise-pa-multi= homing Chris, It is better to at least identify extensions and possible changes to existi= ng standards now rather than later in the process. Can these be explicitly = called out when the document status is changed to informational? Thanks, Acee From: Chris Bowers > Date: Thursday, March 2, 2017 at 6:48 PM To: Acee Lindem >, Jeff Tantsura >, Routing WG > Cc: "draft-bowbakova-rtgwg-enterprise-pa-multihoming@ietf.org" >, rtgwg-chairs > Subject: RE: WG adoption call for draft-bowbakova-rtgwg-enterprise-pa-multi= homing Acee, The authors are OK with making this document informational. It is intended= to provide a description of the different parts of an overall solution to = this problem (with a few variants). Anything new that needs to be standard= ized will be addressed in separate documents in the appropriate working gro= up. Thanks, Chris From: Acee Lindem (acee) [mailto:acee@cisco.com] Sent: Tuesday, February 21, 2017 5:27 PM To: Jeff Tantsura >= ; RTGWG > Cc: draft-bowbakova-rtgwg-enterprise-pa-multihoming@ietf.org; rtgwg-chairs > Subject: Re: WG adoption call for draft-bowbakova-rtgwg-enterprise-pa-multi= homing Hi Jeff, The document is standards track. Can the authors summarize what is being st= andardized as opposed to informational? I think we need to determine whethe= r this work belongs in RTGWG or 6MAN. Thanks, Acee From: rtgwg > on beha= lf of Jeff Tantsura > Date: Tuesday, February 21, 2017 at 6:19 PM To: Routing WG > Cc: "draft-bowbakova-rtgwg-enterprise-pa-multihoming@ietf.org" >, rtgwg-chairs > Subject: WG adoption call for draft-bowbakova-rtgwg-enterprise-pa-multihomi= ng Dear RTGWG, The authors have requested the RTGWG to adopt draft-bowbakova-rtgwg-enterpr= ise-pa-multihoming draft as the working group document. RTGWG chairs have discussed the progress of the draft with v6ops chairs and= got their blessing. Please indicate support or no-support by March 8th, 2017. IPR: If you are listed as a document author or contributor, please respond to th= is email. of whether or not you are aware of any relevant IPR. The response needs to = be sent to the RTGWG mailing list. The document will not advance to the next stage until a response has been r= eceived from each author and each individual that has contributed to the document. Thanks, Jeff & Chris --_000_MWHPR05MB282914C9B0EE26AB7CF36BA9A92E0MWHPR05MB2829namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Acee,=

=  

Yes.&= nbsp; We will more explicitly identify what is already standardized vs. what would nee= d to be standardized in the next version.

 

Chris

 

From:= Acee Lindem (acee) [mailto:acee@cisco.com= ]
Sent: Friday, March 3, 2017 6:52 AM
To: Chris Bowers <cbowers@juniper.net>; Jeff Tantsura <jeff= tant.ietf@gmail.com>; RTGWG <rtgwg@ietf.org>
Cc: draft-bowbakova-rtgwg-enterprise-pa-multihoming@ietf.org; rtgwg-= chairs <rtgwg-chairs@ietf.org>
Subject: Re: WG adoption call for draft-bowbakova-rtgwg-enterprise-p= a-multihoming

 

Chris,&= nbsp;

&n= bsp;

It is b= etter to at least identify extensions and possible changes to existing stan= dards now rather than later in the process. Can these be explicitly called = out when the document status is changed to informational? 

&n= bsp;

Thanks,=

Acee

&n= bsp;

From= : Chris Bowers <= cbowers@juniper.net>
Date: Thursday, March 2, 2017 at 6:48 PM
To: Acee Lindem <acee@cisco.com= >, Jeff Tantsura <jeff= tant.ietf@gmail.com>, Routing WG <rtgwg@ietf.org>
Cc: "draft-bowbakova-rtgwg-enterprise-pa-multihoming@ietf.org<= /a>" <draft-bowbakova-rtgwg-enterprise-pa-multihoming@ietf.org= >, rtgwg-chairs <rtgwg-chairs@iet= f.org>
Subject: RE: WG adoption call for draft-bowbakova-rtgwg-enterprise-p= a-multihoming

&n= bsp;

Acee,=

 = ;

The a= uthors are OK with making this document informational.  It is intended= to provide a description of the different parts of an overall solution to = this problem (with a few variants).  Anything new that needs to be standardized will be addressed in separate documents = in the appropriate working group.

 = ;

Thank= s,

Chris=

 = ;

From= : Acee Lindem (acee= ) [mailto:acee@cisco.com]
Sent: Tuesday, February 21, 2017 5:27 PM
To: Jeff Tantsura <jef= ftant.ietf@gmail.com>; RTGWG <r= tgwg@ietf.org>
Cc: draft-bowbakova-rtgwg-enterprise-pa-multihoming@ietf.org; rtgwg-chairs = <rtgwg-chairs@ietf.org><= br> Subject: Re: WG adoption call for draft-bowbakova-rtgwg-enterprise-p= a-multihoming

 =

Hi Jeff= , 

 <= /span>

The doc= ument is standards track. Can the authors summarize what is being standardi= zed as opposed to informational? I think we need to determine whether this = work belongs in RTGWG or 6MAN.  

 <= /span>

Thanks,=

Acee&nb= sp;

 <= /span>

From= : rtgwg <rtgwg-bounces@ietf.org> on behalf= of Jeff Tantsura <jefftant.i= etf@gmail.com>
Date: Tuesday, February 21, 2017 at 6:19 PM
To: Routing WG <rtgwg@ietf.org<= /a>>
Cc: "draft-bowbakova-rtgwg-enterprise-pa-multihoming@ietf.org<= /a>" <draft-bowbakova-rtgwg-enterprise-pa-multihoming@ietf.org= >, rtgwg-chairs <rtgwg-chairs@iet= f.org>
Subject: WG adoption call for draft-bowbakova-rtgwg-enterprise-pa-mu= ltihoming

 <= /span>

Dear RT= GWG,

 <= /span>

The aut= hors have requested the RTGWG to adopt draft-bowbakova-rtgwg-enterprise-pa-= multihoming draft as the working group document.

RTGWG c= hairs have discussed the progress of the draft with v6ops chairs and got th= eir blessing.

Please = indicate support or no-support by March 8th, 2017.

IPR:

If you = are listed as a document author or contributor, please respond to this emai= l.

of whet= her or not you are aware of any relevant IPR. The response needs to be sent= to the RTGWG mailing list.

The doc= ument will not advance to the next stage until a response has been received= from each author and each

individ= ual that has contributed to the document.

Thanks,=

Jeff &a= mp; Chris

--_000_MWHPR05MB282914C9B0EE26AB7CF36BA9A92E0MWHPR05MB2829namp_-- From nobody Wed Mar 8 04:58:21 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF99129668; Wed, 8 Mar 2017 04:58:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 yT7TowlOCihF; Wed, 8 Mar 2017 04:58:16 -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 DEE46129665; Wed, 8 Mar 2017 04:58:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21669; q=dns/txt; s=iport; t=1488977895; x=1490187495; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=nUOiPDF84EFoqe4UQfCzOYSl6g8k86vUmIDTukLctHA=; b=OoVojP3ovmn7PxL1s3Qd5MQW0hI5kqMOkHrwBBNau2tT9Fc/IFNqRIfA 8ke2sVeaFWCusuTrr9Pqe4z/UAlwWmYmxnN60C9O8xiBrfarL4I4lAJsF DCnFnohC/j2x+9ohukKlR+KsABBCWStqogo638DGZ6Vz1MGaiFvVTvAAN Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ASAQD5/r9Y/5RdJa1TChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJuY2GBCgeNZZFMiA2NK4INhiICgjg/GAECAQEBAQEBAWsohRU?= =?us-ascii?q?BAQEBAx0QQQYFEAIBCA4DAwEBASEHByERFAkIAgQBDQUbiUwDFbI+hzkNgzgBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEdiz2CUYFVBgsBPBaFLwWKAoYXi2M6AY4MhCu?= =?us-ascii?q?Be4UjigKKVIhpAR84ewhWFT+GVHWHZYEhgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.36,264,1486425600"; d="scan'208,217";a="217681943" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Mar 2017 12:58:14 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v28CwEO9002468 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 8 Mar 2017 12:58:14 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.1210.3; Wed, 8 Mar 2017 07:58:13 -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.1210.000; Wed, 8 Mar 2017 07:58:13 -0500 From: "Acee Lindem (acee)" To: Chris Bowers , Jeff Tantsura , RTGWG Subject: Re: WG adoption call for draft-bowbakova-rtgwg-enterprise-pa-multihoming Thread-Topic: WG adoption call for draft-bowbakova-rtgwg-enterprise-pa-multihoming Thread-Index: AQHSjJoNYxgCOk/kfUO56alwIpsPpKGCmY4AgACG/wCAB2zKgIAAcLWA Date: Wed, 8 Mar 2017 12:58:13 +0000 Message-ID: References: <75FE1936-DC60-4914-BF94-E7EC7DCF5AE9@gmail.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.24.101.27] Content-Type: multipart/alternative; boundary="_000_D4E5699AA0FE9aceeciscocom_" MIME-Version: 1.0 Archived-At: Cc: "draft-bowbakova-rtgwg-enterprise-pa-multihoming@ietf.org" , rtgwg-chairs X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 12:58:19 -0000 --_000_D4E5699AA0FE9aceeciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks Chris - With that addition, I support RTGWG adoption. Acee From: Chris Bowers > Date: Tuesday, March 7, 2017 at 8:14 PM To: Acee Lindem >, Jeff Tantsura >, Routing WG > Cc: "draft-bowbakova-rtgwg-enterprise-pa-multihoming@ietf.org" >, rtgwg-chairs > Subject: RE: WG adoption call for draft-bowbakova-rtgwg-enterprise-pa-multi= homing Acee, Yes. We will more explicitly identify what is already standardized vs. wha= t would need to be standardized in the next version. Chris From: Acee Lindem (acee) [mailto:acee@cisco.com] Sent: Friday, March 3, 2017 6:52 AM To: Chris Bowers >; Jeff Ta= ntsura >; RTGWG > Cc: draft-bowbakova-rtgwg-enterprise-pa-multihoming@ietf.org; rtgwg-chairs > Subject: Re: WG adoption call for draft-bowbakova-rtgwg-enterprise-pa-multi= homing Chris, It is better to at least identify extensions and possible changes to existi= ng standards now rather than later in the process. Can these be explicitly = called out when the document status is changed to informational? Thanks, Acee From: Chris Bowers > Date: Thursday, March 2, 2017 at 6:48 PM To: Acee Lindem >, Jeff Tantsura >, Routing WG > Cc: "draft-bowbakova-rtgwg-enterprise-pa-multihoming@ietf.org" >, rtgwg-chairs > Subject: RE: WG adoption call for draft-bowbakova-rtgwg-enterprise-pa-multi= homing Acee, The authors are OK with making this document informational. It is intended= to provide a description of the different parts of an overall solution to = this problem (with a few variants). Anything new that needs to be standard= ized will be addressed in separate documents in the appropriate working gro= up. Thanks, Chris From: Acee Lindem (acee) [mailto:acee@cisco.com] Sent: Tuesday, February 21, 2017 5:27 PM To: Jeff Tantsura >= ; RTGWG > Cc: draft-bowbakova-rtgwg-enterprise-pa-multihoming@ietf.org; rtgwg-chairs > Subject: Re: WG adoption call for draft-bowbakova-rtgwg-enterprise-pa-multi= homing Hi Jeff, The document is standards track. Can the authors summarize what is being st= andardized as opposed to informational? I think we need to determine whethe= r this work belongs in RTGWG or 6MAN. Thanks, Acee From: rtgwg > on beha= lf of Jeff Tantsura > Date: Tuesday, February 21, 2017 at 6:19 PM To: Routing WG > Cc: "draft-bowbakova-rtgwg-enterprise-pa-multihoming@ietf.org" >, rtgwg-chairs > Subject: WG adoption call for draft-bowbakova-rtgwg-enterprise-pa-multihomi= ng Dear RTGWG, The authors have requested the RTGWG to adopt draft-bowbakova-rtgwg-enterpr= ise-pa-multihoming draft as the working group document. RTGWG chairs have discussed the progress of the draft with v6ops chairs and= got their blessing. Please indicate support or no-support by March 8th, 2017. IPR: If you are listed as a document author or contributor, please respond to th= is email. of whether or not you are aware of any relevant IPR. The response needs to = be sent to the RTGWG mailing list. The document will not advance to the next stage until a response has been r= eceived from each author and each individual that has contributed to the document. Thanks, Jeff & Chris --_000_D4E5699AA0FE9aceeciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <5DE39AEBF7A6354096BF7A4D7EA196B0@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Thanks Chris – With that addition, I support RTGWG adoption.&nbs= p;
Acee 

From: Chris Bowers <cbowers@juniper.net>
Date: Tuesday, March 7, 2017 at 8:1= 4 PM
To: Acee Lindem <acee@cisco.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Routing WG &l= t;rtgwg@ietf.org>
Cc: "draft-bowbakova-rtgwg-en= terprise-pa-multihoming@ietf.org" <draft-bowbakova-rtgwg-enter= prise-pa-multihoming@ietf.org>, rtgwg-chairs <rtgwg-chairs@iet= f.org>
Subject: RE: WG adoption call for d= raft-bowbakova-rtgwg-enterprise-pa-multihoming

Acee,=

=  

Yes.&= nbsp; We will more explicitly identify what is already standardized vs. what would nee= d to be standardized in the next version.

 

Chris

 

From:= Acee Lindem (acee) [mailto:acee@cisco.com]
Sent: Friday, March 3, 2017 6:52 AM
To: Chris Bowers <cbowers@= juniper.net>; Jeff Tantsura <jefftant.ietf@gmail.com>; RTGWG <rtgwg@ietf.org>
Cc: draft-bowbakova-rtgwg-enterprise-pa-multihoming@ietf.org; rtgwg-chairs = <rtgwg-chairs@ietf.org><= br> Subject: Re: WG adoption call for draft-bowbakova-rtgwg-enterprise-p= a-multihoming

 

Chris,&= nbsp;

&n= bsp;

It is b= etter to at least identify extensions and possible changes to existing stan= dards now rather than later in the process. Can these be explicitly called = out when the document status is changed to informational? 

&n= bsp;

Thanks,=

Acee

&n= bsp;

From= : Chris Bowers <= cbowers@juniper.net>
Date: Thursday, March 2, 2017 at 6:48 PM
To: Acee Lindem <acee@cisco.com= >, Jeff Tantsura <jeff= tant.ietf@gmail.com>, Routing WG <rtgwg@ietf.org>
Cc: "draft-bowbakova-rtgwg-enterprise-pa-multihoming@ietf.org<= /a>" <draft-bowbakova-rtgwg-enterprise-pa-multihoming@ietf.org= >, rtgwg-chairs <rtgwg-chairs@iet= f.org>
Subject: RE: WG adoption call for draft-bowbakova-rtgwg-enterprise-p= a-multihoming

&n= bsp;

Acee,=

 = ;

The a= uthors are OK with making this document informational.  It is intended= to provide a description of the different parts of an overall solution to = this problem (with a few variants).  Anything new that needs to be standardized will be addressed in separate documents = in the appropriate working group.

 = ;

Thank= s,

Chris=

 = ;

From= : Acee Lindem (acee= ) [mailto:acee@cisco.com]
Sent: Tuesday, February 21, 2017 5:27 PM
To: Jeff Tantsura <jef= ftant.ietf@gmail.com>; RTGWG <r= tgwg@ietf.org>
Cc: draft-bowbakova-rtgwg-enterprise-pa-multihoming@ietf.org; rtgwg-chairs = <rtgwg-chairs@ietf.org><= br> Subject: Re: WG adoption call for draft-bowbakova-rtgwg-enterprise-p= a-multihoming

 =

Hi Jeff= , 

 <= /span>

The doc= ument is standards track. Can the authors summarize what is being standardi= zed as opposed to informational? I think we need to determine whether this = work belongs in RTGWG or 6MAN.  

 <= /span>

Thanks,=

Acee&nb= sp;

 <= /span>

From= : rtgwg <rtgwg-bounces@ietf.org> on behalf= of Jeff Tantsura <jefftant.i= etf@gmail.com>
Date: Tuesday, February 21, 2017 at 6:19 PM
To: Routing WG <rtgwg@ietf.org<= /a>>
Cc: "draft-bowbakova-rtgwg-enterprise-pa-multihoming@ietf.org<= /a>" <draft-bowbakova-rtgwg-enterprise-pa-multihoming@ietf.org= >, rtgwg-chairs <rtgwg-chairs@iet= f.org>
Subject: WG adoption call for draft-bowbakova-rtgwg-enterprise-pa-mu= ltihoming

 <= /span>

Dear RT= GWG,

 <= /span>

The aut= hors have requested the RTGWG to adopt draft-bowbakova-rtgwg-enterprise-pa-= multihoming draft as the working group document.

RTGWG c= hairs have discussed the progress of the draft with v6ops chairs and got th= eir blessing.

Please = indicate support or no-support by March 8th, 2017.

IPR:

If you = are listed as a document author or contributor, please respond to this emai= l.

of whet= her or not you are aware of any relevant IPR. The response needs to be sent= to the RTGWG mailing list.

The doc= ument will not advance to the next stage until a response has been received= from each author and each

individ= ual that has contributed to the document.

Thanks,=

Jeff &a= mp; Chris

 --_000_D4E5699AA0FE9aceeciscocom_-- From nobody Wed Mar 8 10:47:01 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 951CB129487; Wed, 8 Mar 2017 10:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 fGGlKUQKHFe1; Wed, 8 Mar 2017 10:46:59 -0800 (PST) Received: from mail-pg0-x243.google.com (mail-pg0-x243.google.com [IPv6:2607:f8b0:400e:c05::243]) (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 149EC129442; Wed, 8 Mar 2017 10:46:59 -0800 (PST) Received: by mail-pg0-x243.google.com with SMTP id 25so4193172pgy.3; Wed, 08 Mar 2017 10:46:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=/XWPF5TJ7idcP4K78VcujCrjnMJqlIW73CpZR2wgVa8=; b=tsnNOOXl1u5pfRDudNU7jimEFcQg4z6gO/HiedDiJN9D04BIpjavnmu/7lQ2HvXfxp UN3CpVf3kZ96itFkmqVUuCDHRpT8poMzV4miw0Nq5qNmSBw9XyE5AYEtXyuXXlfqQHFP OmL8TGNNQD36VvL1BGNcCxdOxth43wuZxiaSm+6CF+cvRhA/yFGW6G+CHJUBf2ZRxbWz ZmWbkOeGLZqJ8DVLLEukkGfPA3Dum1rwhvHoeyOTwLgtQy1NnaZvexBNzK9bZZ/68g4Q Stt8SdMOmXpkaHmciOZdxksMom2FT9t99VRcZzbETduIQDulHWSYs6OhB2jWTk4jjxBl Kf4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=/XWPF5TJ7idcP4K78VcujCrjnMJqlIW73CpZR2wgVa8=; b=VxGmvN7sG4bZBi1oR3lYfumTeMYCrCA9eSOkmWkArIM2DWJh/ONR80Kocx/LejvQNp IvttMdMoqa5szx9AGvdyCgyIwJB5Up+7qIADg6UgT3WS6WQ9kiWvdwz+XBqQHqdRcBL2 tTIl3/cUQx2VVsCrHZak3yohecAVIBx3VhjabvGYzOcc+lPvzyYL/eUppL4t6/+pftX7 +HC0kI2jj+sgt7L3fy2fjTdoEZMVd7dtg8Jtpc3xpcn58cVZjuu0FflcxPKSbmbRN4Kp iv+D+UOHCtBqaa1ZaXdTWdYT8tCqtLPuaNm0gsvcIQvcephdf96knoBkD1Qao94oRD0V BjuQ== X-Gm-Message-State: AMke39mU1mua7hXf3rwWBr+1hn0f3oJhgQ9j9BNYxe0bEy9ylVjq9zpSmTRrNS5QaWWu3w== X-Received: by 10.99.230.17 with SMTP id g17mr8669373pgh.84.1488998818312; Wed, 08 Mar 2017 10:46:58 -0800 (PST) Received: from [172.16.4.90] ([66.78.254.86]) by smtp.gmail.com with ESMTPSA id a77sm7597307pfl.91.2017.03.08.10.46.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Mar 2017 10:46:57 -0800 (PST) User-Agent: Microsoft-MacOutlook/f.1f.0.170216 Date: Wed, 08 Mar 2017 10:46:59 -0800 Subject: Re: WG adoption call for draft-bowbakova-rtgwg-enterprise-pa-multihoming From: Jeff Tantsura To: RTGWG Message-ID: Thread-Topic: WG adoption call for draft-bowbakova-rtgwg-enterprise-pa-multihoming References: <75FE1936-DC60-4914-BF94-E7EC7DCF5AE9@gmail.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3571814820_275833273" Archived-At: Cc: "draft-bowbakova-rtgwg-enterprise-pa-multihoming@ietf.org" , rtgwg-chairs X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 18:47:00 -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_3571814820_275833273 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Dear RTGWG, =20 The poll has ended and there has been sufficient support to adopt the draft as the working group document. =20 Authors, please republish as the working group document. =20 Please update the draft to address Acee=E2=80=99s comment in the next revision. =20 Cheers, Jeff From: rtgwg on behalf of Jeff Tantsura Date: Tuesday, February 21, 2017 at 6:19 PM To: Routing WG Cc: "draft-bowbakova-rtgwg-enterprise-pa-multihoming@ietf.org" , rtgwg-chairs Subject: WG adoption call for draft-bowbakova-rtgwg-enterprise-pa-multihomi= ng=20 =20 Dear RTGWG, =20 The authors have requested the RTGWG to adopt draft-bowbakova-rtgwg-enterpr= ise-pa-multihoming draft as the working group document. RTGWG chairs have discussed the progress of the draft with v6ops chairs and= got their blessing. Please indicate support or no-support by March 8th, 2017. IPR: If you are listed as a document author or contributor, please respond to th= is email. of whether or not you are aware of any relevant IPR. The response needs to = be sent to the RTGWG mailing list. The document will not advance to the next stage until a response has been r= eceived from each author and each individual that has contributed to the document. Thanks, Jeff & Chris --B_3571814820_275833273 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Dear RTGWG,

 

The poll has ended and there has been sufficient support to adop= t the

draft as the working group document.

 

Authors, please republish as the working = group document.

 

Please update the draft to address Acee’s comment in the = next revision.

 

Cheers,

Jeff

=

From:= rtgwg <rtgwg-bounces@ietf.org> on behalf of Jef= f Tantsura <jefftant.ietf@gmail.= com>
Date: Tuesday, February 21, 2017 at 6:19 PM
To: = Routing WG <rtgwg@ietf.org>Cc: "draft-bowbakova-rtgwg-enterprise-pa-multihoming@ietf.org= " <draft-bowbakova-rtgwg-enterprise-pa-multihoming@ietf.org>, r= tgwg-chairs <rtgwg-chairs@ietf.org= >
Subject: WG adoption call for draft-bowbakova-rtgwg-enter= prise-pa-multihoming

 

Dear RTGWG,

 

The authors have requested the RTGWG to adopt draft-bowbakova-rtgwg-enterp= rise-pa-multihoming draft as the working group document.

RTGWG chairs= have discussed the progress of the draft with v6ops chairs and got their bl= essing.

Please indicate support or no-support by March 8th, 2017.

IPR:

If you are listed as a document author or contributor, pleas= e respond to this email.

of whether or not you are aware of any relev= ant IPR. The response needs to be sent to the RTGWG mailing list.

The= document will not advance to the next stage until a response has been recei= ved from each author and each

individual that has contributed to the = document.

Thanks,

Jeff & Chris

=
--B_3571814820_275833273-- From nobody Thu Mar 9 18:36:56 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B59041294D5; Thu, 9 Mar 2017 18:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmUA9LWGqT0e; Thu, 9 Mar 2017 18:36:37 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1E721294C4; Thu, 9 Mar 2017 18:36:32 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 08ED8B805C3; Thu, 9 Mar 2017 18:06:43 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 8102 on Remote-LFA Node Protection and Manageability X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20170310020643.08ED8B805C3@rfc-editor.org> Date: Thu, 9 Mar 2017 18:06:43 -0800 (PST) Archived-At: Cc: drafts-update-ref@iana.org, rtgwg@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 02:36:39 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8102 Title: Remote-LFA Node Protection and Manageability Author: P. Sarkar, Ed., S. Hegde, C. Bowers, H. Gredler, S. Litkowski Status: Standards Track Stream: IETF Date: March 2017 Mailbox: pushpasis.ietf@gmail.com, shraddha@juniper.net, cbowers@juniper.net, hannes@rtbrick.com, stephane.litkowski@orange.com Pages: 22 Characters: 50200 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-rtgwg-rlfa-node-protection-13.txt URL: https://www.rfc-editor.org/info/rfc8102 DOI: 10.17487/RFC8102 The loop-free alternates (LFAs) computed following the current remote-LFA specification guarantees only link protection. The resulting remote-LFA next hops (also called "PQ-nodes") may not guarantee node protection for all destinations being protected by it. This document describes an extension to the remote-loop-free-based IP fast reroute mechanisms that specifies procedures for determining whether or not a given PQ-node provides node protection for a specific destination. The document also shows how the same procedure can be utilized for the collection of complete characteristics for alternate paths. Knowledge about the characteristics of all alternate paths is a precursor to applying the operator-defined policy for eliminating paths not fitting the constraints. This document is a product of the Routing Area Working Group Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Mar 10 19:33:32 2017 Return-Path: X-Original-To: rtgwg@ietf.org Delivered-To: rtgwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BCFD4129470; Fri, 10 Mar 2017 19:33:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-rtgwg-yang-vrrp-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148920321174.3074.4858389371951810818@ietfa.amsl.com> Date: Fri, 10 Mar 2017 19:33:31 -0800 Archived-At: Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 03:33:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Area Working Group of the IETF. Title : A YANG Data Model for Virtual Router Redundancy Protocol (VRRP) Authors : Xufeng Liu Athanasios Kyparlis Ravi Parikh Acee Lindem Mingui Zhang Filename : draft-ietf-rtgwg-yang-vrrp-02.txt Pages : 40 Date : 2017-03-10 Abstract: This document describes a data model for Virtual Router Redundancy Protocol (VRRP). Both version 2 and version 3 of VRRP are covered. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-vrrp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtgwg-yang-vrrp-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-yang-vrrp-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 13 07:28:20 2017 Return-Path: X-Original-To: rtgwg@ietf.org Delivered-To: rtgwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A50C012968D; Mon, 13 Mar 2017 07:28:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-rtgwg-device-model-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148941529864.16916.11649103034706156760@ietfa.amsl.com> Date: Mon, 13 Mar 2017 07:28:18 -0700 Archived-At: Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 14:28:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Area Working Group of the IETF. Title : Network Device YANG Logical Organization Authors : Acee Lindem Lou Berger Dean Bogdanovic Christan Hopps Filename : draft-ietf-rtgwg-device-model-02.txt Pages : 22 Date : 2017-03-13 Abstract: This document presents an approach for organizing YANG models in a comprehensive logical structure that may be used to configure and operate network devices. The structure is itself represented as an example YANG model, with all of the related component models logically organized in a way that is operationally intuitive, but this model is not expected to be implemented. The identified component modules are expected to be defined and implemented on common network devices. This document is derived from work submitted to the IETF by members of the informal OpenConfig working group of network operators and is a product of the Routing Area YANG Architecture design team. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-device-model/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtgwg-device-model-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-device-model-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 13 09:02:25 2017 Return-Path: X-Original-To: rtgwg@ietf.org Delivered-To: rtgwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 67BEC1297E8; Mon, 13 Mar 2017 09:02:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-rtgwg-lne-model-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148942092940.17014.11005378021546282510@ietfa.amsl.com> Date: Mon, 13 Mar 2017 09:02:09 -0700 Archived-At: Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 16:02:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Area Working Group of the IETF. Title : YANG Logical Network Elements Authors : Lou Berger Christan Hopps Acee Lindem Dean Bogdanovic Filename : draft-ietf-rtgwg-lne-model-02.txt Pages : 13 Date : 2017-03-13 Abstract: This document defines a logical network element module. This module along with the network instance module can be used to manage the logical and virtual resource representations that may be present on a network device. Examples of common industry terms for logical resource representations are Logical Systems or Logical Routers. Examples of of common industry terms for virtual resource representations are Virtual Routing and Forwarding (VRF) instances and Virtual Switch Instances (VSIs). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-lne-model/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtgwg-lne-model-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-lne-model-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 13 09:02:44 2017 Return-Path: X-Original-To: rtgwg@ietf.org Delivered-To: rtgwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 76F37129841; Mon, 13 Mar 2017 09:02:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-rtgwg-ni-model-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148942095647.17020.8223450203168844391@ietfa.amsl.com> Date: Mon, 13 Mar 2017 09:02:36 -0700 Archived-At: Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 16:02:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Area Working Group of the IETF. Title : YANG Network Instances Authors : Lou Berger Christan Hopps Acee Lindem Dean Bogdanovic Filename : draft-ietf-rtgwg-ni-model-02.txt Pages : 17 Date : 2017-03-13 Abstract: This document defines a network instance module. This module along with the logical network element module can be used to manage the logical and virtual resource representations that may be present on a network device. Examples of common industry terms for logical resource representations are Logical Systems or Logical Routers. Examples of common industry terms for virtual resource representations are Virtual Routing and Forwarding (VRF) instances and Virtual Switch Instances (VSIs). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-ni-model/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-ni-model-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 13 11:12:57 2017 Return-Path: X-Original-To: rtgwg@ietf.org Delivered-To: rtgwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A417D1299A8; Mon, 13 Mar 2017 11:12:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-rtgwg-enterprise-pa-multihoming-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148942877264.9160.15159272705178610964@ietfa.amsl.com> Date: Mon, 13 Mar 2017 11:12:52 -0700 Archived-At: Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 18:12:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Area Working Group of the IETF. Title : Enterprise Multihoming using Provider-Assigned Addresses without Network Prefix Translation: Requirements and Solution Authors : Fred Baker Chris Bowers Jen Linkova Filename : draft-ietf-rtgwg-enterprise-pa-multihoming-00.txt Pages : 47 Date : 2017-03-13 Abstract: Connecting an enterprise site to multiple ISPs using provider- assigned addresses is difficult without the use of some form of Network Address Translation (NAT). Much has been written on this topic over the last 10 to 15 years, but it still remains a problem without a clearly defined or widely implemented solution. Any multihoming solution without NAT requires hosts at the site to have addresses from each ISP and to select the egress ISP by selecting a source address for outgoing packets. It also requires routers at the site to take into account those source addresses when forwarding packets out towards the ISPs. This document attempts to define a complete solution to this problem. It covers the behavior of routers to forward traffic taking into account source address, and it covers the behavior of host to select appropriate source addresses. It also covers any possible role that routers might play in providing information to hosts to help them select appropriate source addresses. In the process of exploring potential solutions, this documents also makes explicit requirements for how the solution would be expected to behave from the perspective of an enterprise site network administrator . The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-enterprise-pa-multihoming/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-00 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 Wed Mar 15 10:47:38 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA29F13175E; Wed, 15 Mar 2017 10:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.947 X-Spam-Level: X-Spam-Status: No, score=0.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6efkrmxk625; Wed, 15 Mar 2017 10:47:31 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54E7A131756; Wed, 15 Mar 2017 10:47:31 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.2.137; From: "Susan Hares" To: Cc: , "'Russ White'" Subject: I2RS agenda posted Date: Wed, 15 Mar 2017 13:42:48 -0400 Message-ID: <03eb01d29db3$901b49e0$b051dda0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03EC_01D29D92.090A9440" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdKdssy8vn1sqQTGSguKNAuEw3v+Ug== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 17:47:33 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03EC_01D29D92.090A9440 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I2RS agenda is posted. I2RS will be held Wednesday 3/26 at 13:00-15:00 CDT. We have time for presentations on protocol-independent modules. I2RS is charter to review protocol-independent modules whether these models Are destined for the configuration datastore or I2RS ephemeral control plane datastores, or any other control plane datastore. Please send your request to the I2RS WG chairs. If you send a request, and you do not see your request on the agendas, Please let us know. Sue Hares and Russ White (shares@ndzh.com russ@riw.us ) ------=_NextPart_000_03EC_01D29D92.090A9440 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I2RS = agenda is posted.   I2RS will be held Wednesday 3/26 at = 13:00-15:00 CDT.

 

We have time = for presentations on protocol-independent modules.

I2RS is charter to review protocol-independent modules = whether these models

Are destined = for the configuration datastore or I2RS ephemeral control plane = datastores,

or any other control = plane datastore.

 

Please send = your request to the I2RS WG chairs.

 

If you send = a request, and you do not see your request on the agendas, =

Please let us know. =

 

Sue Hares and Russ White

(shares@ndzh.com

russ@riw.us ) =

------=_NextPart_000_03EC_01D29D92.090A9440-- From nobody Wed Mar 15 13:52:03 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1C92131834; Wed, 15 Mar 2017 13:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 oFFiv5joeVhK; Wed, 15 Mar 2017 13:52:00 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002: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 E459513182C; Wed, 15 Mar 2017 13:51:59 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id v76so19163514ywg.0; Wed, 15 Mar 2017 13:51:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bmxKsz3ODcw1wgLPcYjMQ88getgrRzMp3ZLO1as9xUg=; b=ABd8B3wBHh3ovwN1wVgxRd9qoYVUARy3GTgqm2WTdC4ubaYBcFSrolARPOSi7OzbIO I7aaiKrdhAAqrCD61qZlZ6OEUp5toLDmDNxmjdUrGoWYo6gH9iYVCjNSkxQT6hPbsGHe LIC6upETFRlVdsYmbzYydPUMaYtxMwQTAQVDNhxUkE8zktO9ws/2+gbJc0YtQRY9rqYk AvBGdwk9sAMIQAEVcBjJ7Y/dvc1gNK4vPf7QeQwhnxJN41C/LUlHGXlgmTJoB8rDFOA1 UDxCObkTX2vsWV8VQbK7OjzLWVp3OB6z7Mog5gu4wKRg87GldiqWQ5VG0u3dOAr+/d9M 6lAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bmxKsz3ODcw1wgLPcYjMQ88getgrRzMp3ZLO1as9xUg=; b=IV6F5YVV9TMJVfoaqDHGC5SXog7DPCACilJSmu2D0R7sLspR7NqOvmrMLhhGZ5q037 UhzAJHGrgByWeAZ7z+iBNrd21rLI0BDxYcpmcfyfxgwX7/F1oyZW3gPXSRVYcJUUbohT zA6D8fhmCT5NZ5b4te7JxzTzjvOxzSZzNs9keXyVcmNR316sT5kikLGpLJmm4RRKURdG mTLTSW/upwBInetYOCXcWkt7QlymlsZ1RxKcuJgVWL3CyOA4VVPMuR2dOUsQspzwLKQg lYEKcfFIpVTIYPM+izErfNXhLbguxlDs+v7vaqiPMX5QIv73HxluOZ51mhUGMnbdxZBg Ny4A== X-Gm-Message-State: AFeK/H1t2LyQMGsF9UpX3VUxk0rHSsLV2IpOYpMY51n92yKNhBb1psChWdglibnYOdNxifkM553848rsBY6icg== X-Received: by 10.37.176.67 with SMTP id e3mr4032460ybj.26.1489611119103; Wed, 15 Mar 2017 13:51:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.126.69 with HTTP; Wed, 15 Mar 2017 13:51:38 -0700 (PDT) In-Reply-To: References: <75FE1936-DC60-4914-BF94-E7EC7DCF5AE9@gmail.com> From: Chris Bowers Date: Wed, 15 Mar 2017 15:51:38 -0500 Message-ID: Subject: Re: WG adoption call for draft-bowbakova-rtgwg-enterprise-pa-multihoming To: Jeff Tantsura Cc: RTGWG , "draft-bowbakova-rtgwg-enterprise-pa-multihoming@ietf.org" , rtgwg-chairs Content-Type: multipart/alternative; boundary=f403045e6f8c9bb31d054acb1d61 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 20:52:02 -0000 --f403045e6f8c9bb31d054acb1d61 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We published an updated version as a WG document. https://datatracker.ietf.org/doc/draft-ietf-rtgwg-enterprise-pa-multihoming= / We went ahead changed the status to informational and added text in sections 4.2.2 and 4.2.3 to clarify things regarding things that we think would need to be standardized elsewhere or not, as suggested by Acee. Please see the diff for the exact text: https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtgwg-enterprise-pa-multih= oming-00.txt Please tell us if this text addresses the concern or not. There were a few other clarifications that we had accumulated in the text that we went ahead and published with this version as well. I I don't think they are controversial, but please check the diff, and they are certainly open to discussion. Chris On Wed, Mar 8, 2017 at 12:46 PM, Jeff Tantsura wrote: > Dear RTGWG, > > > > The poll has ended and there has been sufficient support to adopt the > > draft as the working group document. > > > > Authors, please republish as the working group document. > > > > Please update the draft to address Acee=E2=80=99s comment in the next rev= ision. > > > > Cheers, > > Jeff > > *From: *rtgwg on behalf of Jeff Tantsura < > jefftant.ietf@gmail.com> > *Date: *Tuesday, February 21, 2017 at 6:19 PM > *To: *Routing WG > *Cc: *"draft-bowbakova-rtgwg-enterprise-pa-multihoming@ietf.org" < > draft-bowbakova-rtgwg-enterprise-pa-multihoming@ietf.org>, rtgwg-chairs < > rtgwg-chairs@ietf.org> > *Subject: *WG adoption call for draft-bowbakova-rtgwg-enterprise-pa-multi= homing > > > > > Dear RTGWG, > > > > The authors have requested the RTGWG to adopt draft-bowbakova-rtgwg-enter= prise-pa-multihoming > draft as the working group document. > > RTGWG chairs have discussed the progress of the draft with v6ops chairs > and got their blessing. > > Please indicate support or no-support by March 8th, 2017. > > IPR: > > If you are listed as a document author or contributor, please respond to > this email. > > of whether or not you are aware of any relevant IPR. The response needs t= o > be sent to the RTGWG mailing list. > > The document will not advance to the next stage until a response has been > received from each author and each > > individual that has contributed to the document. > > Thanks, > > Jeff & Chris > > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > > --f403045e6f8c9bb31d054acb1d61 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We published an updated version= as a WG document.
https://datatracker.ietf.org/doc/draft= -ietf-rtgwg-enterprise-pa-multihoming/

We went ahead changed the= status to informational and added text in sections 4.2.2 and 4.2.3 to clar= ify things regarding things that we think would need to be standardized els= ewhere or not, as suggested by Acee.=C2=A0

Please see the diff for the exact text:
https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtgwg-enterprise-pa-mult= ihoming-00.txt

Please tell us i= f this text addresses the concern or not.

There were a few other clarifications that we had accumulated in the= text that we went ahead and published with this version as well.=C2=A0 I I= don't think they are controversial, but please check the diff, and the= y are certainly open to discussion.

Chris


On Wed, Mar 8, 2017 at 12:46 PM, Jeff Tantsura <jefftant.ietf@gma= il.com> wrote:

Dear RTGWG,

=C2=A0

<= span style=3D"font-size:11pt">The poll has ended and there has been suffici= ent support to adopt the

draft as the working gro= up document.

=C2=A0

Authors, please republish as the working g= roup document.

=C2=A0

<= span style=3D"font-size:11pt">Please update the draft to address Acee=E2=80= =99s comment in the next revision.

=C2=A0

<= p class=3D"MsoNormal">Cheers,<= u>

Jeff

=

From: rtgwg = <rtgwg-bounc= es@ietf.org> on behalf of Jeff Tantsura <jefftant.ietf@gmail.com>
= Date: Tuesday, February 21, 2017 at 6:19 PM
To: Routing WG &l= t;rtgwg@ietf.org>= ;
Cc: "draft-bowbakova-rtgwg-enterpr= ise-pa-multihoming@ietf.org" <draft-bow= bakova-rtgwg-enterprise-pa-multihoming@ietf.org>, rtgwg-ch= airs <rtgwg-c= hairs@ietf.org>
Subject: WG adoption call for draft-bowbak= ova-rtgwg-enterprise-pa-multihoming

=C2= =A0

Dear RTGWG,

=C2=A0<= /span>

The authors have requested the RTGWG to adopt draft-bowbakov= a-rtgwg-enterprise-pa-multihoming draft as the working group document.=

RTGWG chairs have discussed the progress of the draft with = v6ops chairs and got their blessing.

Please indicate support= or no-support by March 8th, 2017.

IPR:=

If yo= u are listed as a document author or contributor, please respond to this em= ail.

of whether or not you are aware of any relevant IPR. Th= e response needs to be sent to the RTGWG mailing list.=

The d= ocument will not advance to the next stage until a response has been receiv= ed from each author and each

individual that has contributed= to the document.

Thanks,

Jeff & Chris<= /span>


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


--f403045e6f8c9bb31d054acb1d61-- From nobody Wed Mar 15 14:18:48 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6DF0131840 for ; Wed, 15 Mar 2017 14:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iit-edu.20150623.gappssmtp.com 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 IDSYQ8hu0M-W for ; Wed, 15 Mar 2017 14:18:44 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::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 C9803131830 for ; Wed, 15 Mar 2017 14:18:44 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id u30so15822649uau.0 for ; Wed, 15 Mar 2017 14:18:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iit-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=+PVV23mQpk4UToaLGSvjwRDjbmnUe0KpTPjxE3Y1bnI=; b=sfgzGVmLWrtp/kzecTicCmHamTSVxOYuEHY12qwsnmdsdTcF13eLgxx39jwVd5H9TD zBut64uj/KKSgSRxiRBxd/8KZ9I1h9c2TKMhq45KL9bQeGH0YSx1Kjd0ATS/JJhXD70X RBAKCKGMX6rxFTwlnLyQ+v25iHR0TDkOG0ligoesQgPUVB5A53zviS6uOvg3I+XHOksX 0eaeuVKvDmE7jSJfxYQYaMfqS0kcYDF23aKOSkRXXqemqS3ilrnxZ0pg5IpDGiiux2k+ kYnUFfub2clhDxlGbhhVSHts18g7A3o8TM4FAc7yyujUKUhqxwu/LgNx6jhcwCp1+qtP 3ECA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=+PVV23mQpk4UToaLGSvjwRDjbmnUe0KpTPjxE3Y1bnI=; b=dBCAKa2dNP4okXhzw79UqZ9MGGJ3wxNLkdVI/rGGwmtFKk2xTwIwJ1bx/dh+gf8RhJ axoUDktlV8tDSUg5zibz4O86IvQzAHZl+mL74+01uGL49/FXnxsf4sAEV9QEYyaOBPsv nTSlxEKsdPznLDigrs3n64jmm5wgxSDA3ElHs1v6yNWA968o5WjUGfpo/JOz+L6xJIC2 hSBIobtjYXuD601+lVFxx1ozrNcgASAveMLmiXtnQkc5eorYQY3ftUSmrT2YnC9SN77N KtOqYXqw9uTEfFYc7+pG/4OL4SFxFXfUSkNWsV5/E6l2mUzCHZt1XzNO1F07we51YL69 BbUA== X-Gm-Message-State: AFeK/H1Puinnhdssq5FSnmphIQu/A66FH1AAWQL8bI1aKI73l6jmDfu+WHozhBjkcZaOR3YdDKqBpMWSOposaNFe X-Received: by 10.176.83.75 with SMTP id y11mr2064426uay.94.1489612723489; Wed, 15 Mar 2017 14:18:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.90.9 with HTTP; Wed, 15 Mar 2017 14:18:12 -0700 (PDT) From: Sanjiv Kapoor Date: Wed, 15 Mar 2017 16:18:12 -0500 Message-ID: Subject: New Document To: rtgwg@ietf.org Content-Type: multipart/alternative; boundary=94eb2c191e9c3cfe3d054acb7d92 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 21:18:47 -0000 --94eb2c191e9c3cfe3d054acb7d92 Content-Type: text/plain; charset=UTF-8 A new Internet Draft https://www.ietf.org/internet-drafts/draft-kapoor-rtgwg- dynamic-multipath-routing-00.txt has been posted. Please send us comments. Thanks Sanjiv Kapoor --94eb2c191e9c3cfe3d054acb7d92 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A new =C2=A0Internet Draft


has been posted.

Please send us comments.

Thanks

Sanjiv Kapoor
<= /div> --94eb2c191e9c3cfe3d054acb7d92-- From nobody Thu Mar 16 14:56:29 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C306F129AD0; Thu, 16 Mar 2017 14:56:26 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 jaup0uY2C7l2; Thu, 16 Mar 2017 14:56:25 -0700 (PDT) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::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 E0C9C129AC6; Thu, 16 Mar 2017 14:56:22 -0700 (PDT) Received: by mail-wr0-x22b.google.com with SMTP id l37so41098430wrc.1; Thu, 16 Mar 2017 14:56:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=xKm4voVt5gT0QMgv9F1RGbQrq4FwU+2h78rzf7wtxbo=; b=Xb2dtVU2EnN0Ds7MvxqJZJF0SE/M54iuC1OgWFEfvnhn7WOIV6TXaZp7+u/opbC9mI UdFUescF19duV0R5/ScAQOH5l55dViEeUag8JZmX1id+/5ZiJ3Ndg+nmdhQGBeL5i9c+ mye4RONTum9Dae64kudFvABqgVn4itfGCqE5pTv38ZJVflsNpNPUsrHDxP6hq368weuH 6yvbS/HirH/vNyOrpUoqG8VoQ8r5b5Z41X1aNWwQ/GDJdySSzVxj36iTQ9zfKJ118doi Zg/5PRheWPCTRSQt62UOGyC/2ExOSCIUDcnKfVrDJ4mF6In5Q3QSf9azBAWNcz+yGHBa ihdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=xKm4voVt5gT0QMgv9F1RGbQrq4FwU+2h78rzf7wtxbo=; b=Mb5qZ+IpHEkdItKnzJBKSGKzVFH+AX8Ct3PNCxwGL0fupeK3Zn30twxAmttBgnrNtu URfrAYvE+YRm3x8mvDGWAjgVS4HXmANn9uVIhf1A/AAh7Nw0dLbkOjEVCWn1z57D2yzr dm1nZB5rjtu8mUGYj9Hn9Cv4P1iUbVqKn/9WYFcgTRhyq4UtbJVJZg73aHg6gcDY03X+ 1OHVgUttGk9ketK89XXw/p5CygyAqCrlPaMdDE6np7106myToGJQxVyoePw3jH/SohRx dMar99vhq2xvIp+09hnaranl5oxRc74OuT0PBQh6pOruU720aUlWyfT+HvICBrZ2zxiZ civQ== X-Gm-Message-State: AFeK/H2QvTAoudrEi4onjcN4fIY/0mu8uHMMXOo8hXO3dtYjp9rzlb9zA5r+g2efJn7CoaXzK4+WslQZgkGMtA== X-Received: by 10.223.155.193 with SMTP id e1mr10313258wrc.86.1489701381034; Thu, 16 Mar 2017 14:56:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.145.69 with HTTP; Thu, 16 Mar 2017 14:56:20 -0700 (PDT) From: Alia Atlas Date: Thu, 16 Mar 2017 17:56:20 -0400 Message-ID: Subject: AD review of draft-ietf-rtgwg-yang-key-chain-15 To: "rtgwg@ietf.org" , draft-ietf-rtgwg-yang-key-chain@ietf.org Content-Type: multipart/alternative; boundary=94eb2c1b31f2a357d7054ae021e9 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 21:56:27 -0000 --94eb2c1b31f2a357d7054ae021e9 Content-Type: text/plain; charset=UTF-8 As is customary, I have done my AD review of draft-ietf-rtgwg-yang-key-chain-15. First, I would like to thank the many authors - Acee, Yingzhen, Derek, Ing-Wher, Jeffrey, and Yi - for their work on this well-written document. Although I have requested a 3 week IETF Last Call, I have two matters that do need to be resolved before this is placed on an IESG telechat. First, there are 6 authors. Please either reduce it to the standard 5 author limit or send me, the WG chairs, and shepherd a clear explanation of the contributions and why that author limit should not be respected in this case. Second, the security considerations section should be updated to reflect the new general YANG security considerations that also mentions restconf. Thank you for your hard work on this, Alia --94eb2c1b31f2a357d7054ae021e9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As is customary, I have done my AD review of=C2=A0draft-ie= tf-rtgwg-yang-key-chain-15.
First, I would like to thank the many autho= rs -=C2=A0Acee, Yingzhen, Derek, Ing-Wher,=C2=A0
Jeffrey, and Yi = - for their work on this well-written document.

Although I have requested a 3 week IETF Last Call, I have two matters tha= t do need
to be resolved before this is placed on an IESG telecha= t.

First, there are 6 authors.=C2=A0 Please either= reduce it to the standard 5 author limit or send me, the WG chairs, and sh= epherd a clear explanation of the contributions and why that author limit s= hould not be respected in this case.

Second, the s= ecurity considerations section should be updated to reflect the new general= YANG security considerations that also mentions restconf.

Thank you for your hard work on this,
Alia
--94eb2c1b31f2a357d7054ae021e9-- From nobody Thu Mar 16 15:37:31 2017 Return-Path: X-Original-To: rtgwg@ietf.org Delivered-To: rtgwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB3A129B07; Thu, 16 Mar 2017 15:37:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" Subject: Last Call: (Routing Key Chain YANG Data Model) to Proposed Standard X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk CC: rtgwg-chairs@ietf.org, draft-ietf-rtgwg-yang-key-chain@ietf.org, akatlas@gmail.com, Jeff Tantsura , jefftant.ietf@gmail.com, rtgwg@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <148970384955.14242.9810165414164768567.idtracker@ietfa.amsl.com> Date: Thu, 16 Mar 2017 15:37:29 -0700 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 22:37:30 -0000 The IESG has received a request from the Routing Area Working Group WG (rtgwg) to consider the following document: - 'Routing Key Chain YANG Data Model' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-03-30. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes the key chain YANG data model. A key chain is a list of elements each containing a key string, send lifetime, accept lifetime, and algorithm (authentication or encryption). By properly overlapping the send and accept lifetimes of multiple key chain elements, key strings and algorithms may be gracefully updated. By representing them in a YANG data model, key distribution can be automated. Key chains are commonly used for routing protocol authentication and other applications. In some applications, the protocols do not use the key chain element key directly, but rather a key derivation function is used to derive a short-lived key from the key chain element key (e.g., the Master Keys used in the TCP Authentication Option. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-key-chain/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-key-chain/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Mar 17 09:23:15 2017 Return-Path: X-Original-To: rtgwg@ietf.org Delivered-To: rtgwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F52E1294FC; Fri, 17 Mar 2017 09:23:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" Subject: Last Call: (Routing Key Chain YANG Data Model) to Proposed Standard X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk CC: rtgwg-chairs@ietf.org, draft-ietf-rtgwg-yang-key-chain@ietf.org, akatlas@gmail.com, Jeff Tantsura , jefftant.ietf@gmail.com, rtgwg@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <148976778864.13097.8837542947858587684.idtracker@ietfa.amsl.com> Date: Fri, 17 Mar 2017 09:23:08 -0700 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 16:23:09 -0000 The IESG has received a request from the Routing Area Working Group WG (rtgwg) to consider the following document: - 'Routing Key Chain YANG Data Model' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-04-07. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes the key chain YANG data model. A key chain is a list of elements each containing a key string, send lifetime, accept lifetime, and algorithm (authentication or encryption). By properly overlapping the send and accept lifetimes of multiple key chain elements, key strings and algorithms may be gracefully updated. By representing them in a YANG data model, key distribution can be automated. Key chains are commonly used for routing protocol authentication and other applications. In some applications, the protocols do not use the key chain element key directly, but rather a key derivation function is used to derive a short-lived key from the key chain element key (e.g., the Master Keys used in the TCP Authentication Option. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-key-chain/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-key-chain/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Mar 17 09:30:30 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8E31294D2; Fri, 17 Mar 2017 09:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 9R3lMZIU6RJc; Fri, 17 Mar 2017 09:30:27 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24C371294CA; Fri, 17 Mar 2017 09:30:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5850; q=dns/txt; s=iport; t=1489768227; x=1490977827; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=99UU5b74/K/PHpLk3ygVnvYRWrW8qDEG5Hdy9J5Qb6Q=; b=X4LMiPW5LgY8uF9ET1xJ4rdpnS4KXYVGEf9jbrCR7g/ny+7sOrjvB6Z6 uH68qgwKcVeqloUWViwlghT3yCzeMOmt4ItnoJcwnbeP954fMROxSStwd pxLBGsdOpSiUvG2ZQYK2bBbcueZUql6bl4utFg+fc/v+7X7rixTALPRbP c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AvAQBvDsxY/5FdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5jgWsHjWqRWogSiAGFL4IOhiICgn8/GAECAQEBAQEBAWsohRU?= =?us-ascii?q?BAQEBA4EJAgEIDgMDAQIoByERFAkIAgQBEoloAxW0X4c0DYMJAQEBAQEBAQMBA?= =?us-ascii?q?QEBAQEBIYs9glGBYEOFRQWcDzoBjhCEMYF7hSiKCIpgiHIBHziBBFgVhxh1hxo?= =?us-ascii?q?BBh+BCoENAQEB?= X-IronPort-AV: E=Sophos;i="5.36,177,1486425600"; d="scan'208,217";a="399556400" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Mar 2017 16:30:24 +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 v2HGUO40018851 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 17 Mar 2017 16:30:24 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.1210.3; Fri, 17 Mar 2017 12:30:23 -0400 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.1210.000; Fri, 17 Mar 2017 12:30:24 -0400 From: "Acee Lindem (acee)" To: Alia Atlas , "rtgwg@ietf.org" , "draft-ietf-rtgwg-yang-key-chain@ietf.org" Subject: Re: AD review of draft-ietf-rtgwg-yang-key-chain-15 Thread-Topic: AD review of draft-ietf-rtgwg-yang-key-chain-15 Thread-Index: AQHSnqArfIBmJVuP5U2jKUk/njS/baGZOkkA Date: Fri, 17 Mar 2017 16:30:23 +0000 Message-ID: References: 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.198] Content-Type: multipart/alternative; boundary="_000_D4F18727A337Aaceeciscocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 16:30:29 -0000 --_000_D4F18727A337Aaceeciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Alia, These issues will be resolved in the next revision which I will post shortl= y after IETF 98. Thanks, Acee From: Alia Atlas > Date: Thursday, March 16, 2017 at 5:56 PM To: Routing WG >, "draft-ietf-rtgwg-y= ang-key-chain@ietf.org" > Subject: AD review of draft-ietf-rtgwg-yang-key-chain-15 Resent-From: > Resent-To: Acee Lindem >, Jeffrey Zha= ng >, Derek Yeung >, Yingzhen Qu >, >, Ing-Wher Chen > Resent-Date: Thursday, March 16, 2017 at 5:56 PM As is customary, I have done my AD review of draft-ietf-rtgwg-yang-key-chai= n-15. First, I would like to thank the many authors - Acee, Yingzhen, Derek, Ing-= Wher, Jeffrey, and Yi - for their work on this well-written document. Although I have requested a 3 week IETF Last Call, I have two matters that = do need to be resolved before this is placed on an IESG telechat. First, there are 6 authors. Please either reduce it to the standard 5 auth= or limit or send me, the WG chairs, and shepherd a clear explanation of the= contributions and why that author limit should not be respected in this ca= se. Second, the security considerations section should be updated to reflect th= e new general YANG security considerations that also mentions restconf. Thank you for your hard work on this, Alia --_000_D4F18727A337Aaceeciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Alia, 

These issues will be resolved in the next revision which I will post s= hortly after IETF 98. 

Thanks,
Acee 

From: Alia Atlas <akatlas@gmail.com>
Date: Thursday, March 16, 2017 at 5= :56 PM
To: Routing WG <rtgwg@ietf.org>, "draft-ietf-rtgwg-yang-key-chain@ietf.org" <dr= aft-ietf-rtgwg-yang-key-chain@ietf.org>
Subject: AD review of draft-ietf-rt= gwg-yang-key-chain-15
Resent-From: <alias-bounces@ietf.org>
Resent-To: Acee Lindem <acee@cisco.com>, Jeffrey Zhang <zzhang@juniper.net>, Derek Yeung <= ;derek@arrcus.com>, Yingzhen Qu <yingzhen.qu@huaw= ei.com>, <yi.yang@sockrat= e.com>, Ing-Wher Chen <Ing-Wher_Chen@jabil.com>
Resent-Date: Thursday, March 16, 20= 17 at 5:56 PM

As is customary, I have done my AD review of draft-ie= tf-rtgwg-yang-key-chain-15.
First, I would like to thank the many authors - Acee, Yingzhen, D= erek, Ing-Wher, 
Jeffrey, and Yi - for their work on this well-written document.

Although I have requested a 3 week IETF Last Call, I have two matters = that do need
to be resolved before this is placed on an IESG telechat.

First, there are 6 authors.  Please either reduce it to the stand= ard 5 author limit or send me, the WG chairs, and shepherd a clear explanat= ion of the contributions and why that author limit should not be respected = in this case.

Second, the security considerations section should be updated to refle= ct the new general YANG security considerations that also mentions restconf= .

Thank you for your hard work on this,
Alia
 --_000_D4F18727A337Aaceeciscocom_-- From nobody Sat Mar 18 05:14:31 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B554127011; Sat, 18 Mar 2017 05:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 gOqiObk6Ufsc; Sat, 18 Mar 2017 05:14:25 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::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 6B7FB1270A7; Sat, 18 Mar 2017 05:14:25 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id n11so33542708wma.0; Sat, 18 Mar 2017 05:14:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :mime-version; bh=3L+oLHuhOwKkhefynVfYYPsBvvRWbLkAHPCBSW6N3MA=; b=Xnvs7VAVHizY0CDyKcUpzIURcWNccQrqwxAPP9gBW0uGrNS/Yy5MN4I5imqKkQmpaA kpf1+G7yMjE5qMHxYImp49HbQcFIVGjj33O6O84azrMYs1/h5Yajtok9WJl6P//jj0uh Cty7/8o/vEUi/aYcVmzK4Pzj+VoUW65DPARRXLBTmokPB3vWB5C0b4ah2oAEVL7DB35l q9rhTkFLNqkvi0oi4mHx1rw/rZhpV5geu8BYG77bxUIWxqgmVSaFprBXF4LmUf7mdVSu bjWI7E8n6mYmVlTDyhTLZaCRqZLmtR8+QZEfkIkLIF47Ss2kunne0zO17UbvfslfEuHx OUtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:mime-version; bh=3L+oLHuhOwKkhefynVfYYPsBvvRWbLkAHPCBSW6N3MA=; b=AOYdbT7wQdjAfnuQDWH/5U8nrBZe8COkVzTka5aFpZtccEx0bAI59OJmckrYw702C1 fTei+k4jY5NvgRTgCSAP1QzIQbUO6UPH08v7VXf+KQ8FjT0cup64Ww9dhVF+130YzA0T 1bIZ1+wHHzkxGPS9Hga2v74L01cFiU5V6/Ft90Sk+majvKbXKgjT2mLgU+NV99D/Dusl OMDhHcQfEIuIx92yu98QACIqVtJqyXreoheiML9QV+LPK/7vf0lCSvP90VIPskCICC/e Ved85zyReEDJowpZwlMKNylQg25X4r+Ugnp6BgzKHFdSsynSaHFYLfzhOicXiL6FONK/ 9WyA== X-Gm-Message-State: AFeK/H0wvAZDxweyzg7RW+xKxK8KiCGzZ3qfbb01qPi6q9DVgscqxeiXpFWrtqGRqLu3GA== X-Received: by 10.28.71.87 with SMTP id u84mr2382306wma.101.1489839263799; Sat, 18 Mar 2017 05:14:23 -0700 (PDT) Received: from [192.168.178.18] (52D95355.cm-11-1b.dynamic.ziggo.nl. [82.217.83.85]) by smtp.gmail.com with ESMTPSA id o2sm6018150wmb.28.2017.03.18.05.14.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Mar 2017 05:14:22 -0700 (PDT) User-Agent: Microsoft-MacOutlook/f.1f.0.170216 Date: Sat, 18 Mar 2017 05:14:24 -0700 Subject: RTGWG presentation slot requests for Chicago - draft agenda published From: Jeff Tantsura To: RTGWG CC: rtgwg-chairs Message-ID: Thread-Topic: RTGWG presentation slot requests for Chicago - draft agenda published Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3572658865_616339024" Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2017 12:14:29 -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_3572658865_616339024 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Dear RTGWG, =20 The draft agenda has been posted at https://datatracker.ietf.org/doc/agenda= -98-rtgwg If you requested agenda time and don't see yourself there, or if you need t= o make a correction, please let the chairs know. =20 Please make sure you send us the slides on time! We are still looking for volunteers to take notes and jabber. =20 See you in Chicago, Jeff and Chris =20 ---------------------------------------------------------------------------= ----------------------------------------------------------------------------= ------------------------------ =20 Dear RTGWG, =20 It's that time again! The preliminary agenda for IETF 98 has been published; you can find it at h= ttps://datatracker.ietf.org/meeting/98/agenda.html. =20 RTGWG will be meeting: 09:00 - 11:30 on Wednesday, March 29 in Vevey 1/2 an= d 15:20-17:20 on Thursday, March 30 in Zurich E/F. If you'd like a slot to present a draft, please send a request to Chris and= I by Friday March 17th.=20 Please note the dates below, in particular, the deadline for draft submissi= on is UTC 23:59 March 13th. We kindly request to provide your presentations by Wednesday, March 22nd. =20 As always =E2=80=93 we would appreciate your help in taking notes and jabber, ple= ase do volunteer! =20 Looking forward to seeing you in all Chicago! =20 Cheers, Jeff and Chris =20 =20 --B_3572658865_616339024 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Dear RTGWG,

The draft agenda has been posted at https://datatracker.ietf.org/doc/= agenda-98-rtgwg

If you requested agenda time and don't see yourself there, or if = you need to make a correction, please let the chairs know.=

Please make sure you send= us the slides on time!

We are still looking for volunteers to take notes and jab= ber.

=

See= you in Chicago,

Jeff and Chris

 

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

<= p class=3DMsoNormal> 

Dear RTGWG,

 

It's that time again!

The preliminary agenda for IETF 98 ha= s been published; you can find it at https://datatracker.ietf.org/meeting/98/agenda.html.

&= nbsp;

RTGWG will be meeting: 09:00 - 11:30 on Wednesday, March 29 in Vevey 1/2 an= d 15:20-17:20 on Thursday, March 30 in Zurich E/F.

If you'd like a slot to presen= t a draft, please send a request to Chris and I by Friday March 17th.

Please not= e the dates below, in particular, the deadline for draft submission is UTC 2= 3:59 March 13th.

We kindly request to provide your presentations by Wednesday, Ma= rch 22nd.

 

As always – we would appreciate your help in taking notes and j= abber, please do volunteer!

 

Looking forward to seeing you in all Chicago!

 

Cheers,<= /span>

Jeff = and Chris

 

 

--B_3572658865_616339024-- From nobody Mon Mar 20 05:48:58 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4BF013144E; Mon, 20 Mar 2017 05:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com 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 2ejRPjIYiluA; Mon, 20 Mar 2017 05:48:46 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6731612025C; Mon, 20 Mar 2017 05:48:46 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 85C2220565; Mon, 20 Mar 2017 08:48:45 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Mon, 20 Mar 2017 08:48:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=fm1; bh=8DjMOUg84Fj2J+tkOhcFaeSYUKH76kE5aZCYf6m9N PU=; b=PtKvMwDcyBAvBO8CMINgzR46EXMQTHpUP/QZqdS8EDDZ7OF0yE1AMdHuW Nv8rvhNpRU8b+CNGv0RmHswBjmZn86pblmuQ2vrxejksgMMT/9c6bExpRr5LaHm5 YE2Hl4l56AmNraCyxftgFNImmZm3Eqi4cw+OUo2RbTo7F/oSbAy5h4YSZ6gjZIN+ 2UUKUBATpZqu9HBY6D4hm5iuPCUYn99PqeZq24xzZEO7a8hkSmkfp53y7a4+lF4y Jfy3vPwD/EfMTBjBpzWd/hCsQNO+vg87iD4ubT2pS3IdL5q4e8AFXqjFId9YLbT+ ecsyj7LuW9LquwEW5hwQTNzo1XGyQ== X-ME-Sender: X-Sasl-enc: bfRv4GT7a6Zy+I6XdrOBtQA0ETyZLG7weQwUtEPHh8Yn 1490014125 Received: from Russ (162-229-180-77.lightspeed.rlghnc.sbcglobal.net [162.229.180.77]) by mail.messagingengine.com (Postfix) with ESMTPA id 35C867E184; Mon, 20 Mar 2017 08:48:45 -0400 (EDT) From: "Russ White" To: , Subject: Updated openfabric draft Date: Mon, 20 Mar 2017 08:48:44 -0400 Message-ID: <097901d2a178$4fbf72e0$ef3e58a0$@riw.us> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_097A_01D2A156.C8AE4810" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdKheAVp7/Ix19akRCuWZd/km1GfXw== Content-Language: en-us Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 12:48:51 -0000 This is a multipart message in MIME format. ------=_NextPart_000_097A_01D2A156.C8AE4810 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Y'all -- Due to my negligence/laziness... =F0=9F=98=8A We missed the deadline for = putting the new draft up in the IETF system before Chicago next week. = Since we will be presenting the newer version of the draft in RTGWG, = I've attached it here.=20 =F0=9F=98=8A Russ ------=_NextPart_000_097A_01D2A156.C8AE4810 Content-Type: text/plain; name="draft-white-openfabric-01.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-white-openfabric-01.txt" Network Working Group R. White Internet-Draft S. Zandi Intended status: Informational N. Triantafillis Expires: September 21, 2017 LinkedIn H. Gredler RtBrick Inc. March 20, 2017 OpenFabric draft-white-openfabric-01 Abstract Spine and leaf topologies are widely used in hyperscale and cloud scale networks. In most of these networks, configuration is automated, but difficult, and topology information is extracted through broad based connections. Policy is often integrated into the control plane, as well, making configuration, management, and troubleshooting difficult. OpenFabric is an adaptation of an existing, widely deployed link state protocol, Intermediate Sytem to Intermediate System (IS-IS) that is designed to: o Provide a full view of the topology from a single point in the network to simplify operations o Minimize configuration of each router (or switch) in the network o Optimize the operation of IS-IS within a spine and leaf fabric to enable scaling This document begins with an overview of OpenFabric, including a description of what may be removed from IS-IS to enable scaling. The document then describes an optimized adjacency formation process; an optimized flooding scheme; some thoughts on the operation of OpenFabric, metrics, and aggregation; and finally a description of the changes to the IS-IS protocol required for OpenFabric. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. White, et al. Expires September 21, 2017 [Page 1] =0C Internet-Draft OpenFabric March 2017 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 21, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Modified Adjacency Formation . . . . . . . . . . . . . . . . 6 3. Determining Location on the Fabric . . . . . . . . . . . . . 6 3.1. Determining T0 . . . . . . . . . . . . . . . . . . . . . 7 3.2. Determining T1 and above . . . . . . . . . . . . . . . . 8 4. Flooding Optimization . . . . . . . . . . . . . . . . . . . . 9 5. Other Optimizations . . . . . . . . . . . . . . . . . . . . . 10 5.1. Transit Link Reachability . . . . . . . . . . . . . . . . 10 5.2. Transiting T0 Routers . . . . . . . . . . . . . . . . . . 10 6. OpenFabric and Route Aggregation . . . . . . . . . . . . . . 10 7. OpenFabric Modifications to the IS-IS protocol . . . . . . . 11 7.1. The Tier Level sub-TLV . . . . . . . . . . . . . . . . . 11 7.2. The Do Not Reflood (DNR) address . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction Spine and leaf fabrics are often used in large scale data centers; in this application, they are commonly called a fabric because of their regular structure and predicitable forwarding and convergence White, et al. Expires September 21, 2017 [Page 2] =0C Internet-Draft OpenFabric March 2017 properties. This document descibes modifications to the IS-IS protocol to enable it to run efficiently on a large scale spine and leaf fabric, OpenFabric. The goals of this control plane are: o Provide a full view of the topology from a single point in the network to simplify operations o Minimize configuration of each router (or switch) in the network o Optimize the operation of IS-IS within a spine and leaf fabric to enable scaling In building any scalable system, it is often best to begin by removing what is not needed. In this spirit, OpenFabric implementations MAY remove the following from IS-IS: o Multilevel flooding domain support. The modifications described in this document will not work across multiple flooding domains. It is assumed that multiple fabrics will be connected through an Exterior Gateway Protocol (EGP), specifically BGP [RFC4271]. o All mutliaccess link processing, including Designated Intermediate Systems (DIS). Spine and leaf fabrics are normally built using only point-to-point links, so multiaccess link processing is not required in OpenFabric. o External metrics. There is no need for external metrics in large scale spine and leaf fabrics; it is assumed that metrics will be properly configured by the operator to account for the correct order of route preference at any route redistribution point. o Tags and traffic engineering processing. OpenFabric is only designed to provide topology and reachability information. It is not designed to provide for traffic engineering, route preference through tags, or other policy mechanisms. It is assumed that all routing policy will be provided through an overlay system which communicates directly with each router in the fabric, such as PCEP [RFC5440] or I2RS [RFC7921]. Traffic engineering is assumed to be provided through Segment Routing (SR) [I-D.ietf-spring-segment-routing]. To create a scalable link state fabric, OpenFabric includes the following: o A slightly modified adjacency formation process. This is largely a matter of forming adjacencies in a specific order, rather than forming an adjacency with every discovered neighbor at the same time. White, et al. Expires September 21, 2017 [Page 3] =0C Internet-Draft OpenFabric March 2017 o A mechanism for determining which tier within a spine and leaf fabric in which the router is located. o A mechanism that reduces flooding to the minimum possible, while still ensuring complete database synchronization among the routers within the fabric. o New sub-TLVs to carry OpenFabric specific information; specifically a new IS reachability tier sub-TLV. OpenFabric implementations: o MUST support [RFC5301] and enable hostname advertisement by default if a hostname is configured on the intermediate system. o MUST support [RFC5311], simplified extension of the link state PDU space for IS-IS. o MUST support [RFC5303] and enable three-way handshakes by default. o MUST use TLV type 135 for carrying IPv4 reachability information, as defined in [RFC5305]. o MUST use TLV type 236 for carrying IPv6 reachability information, as defined in [RFC5308]. o MUST use TLV type 22 for carrying IS reachability information, as defined in [RFC5305]. o SHOULD support [RFC6232], purge originator identification for IS- IS. o SHOULD support Segment Routing (SR). [I-D.ietf-spring-segment-routing] o SHOULD support [I-D.ietf-isis-segment-routing-extensions]. o SHOULD support [RFC3719], section 4, hello padding for IS-IS. Variable hello padding SHOULD NOT be used, as data center fabrics are built using high speed links on which padded hellos will have little performance impact. OpenFabric implementations MUST NOT be mixed with standard IS-IS implementations in operational deployments. OpenFabric and standard IS-IS implementations SHOULD be treated as two separate protocols. The following spine and leaf fabric will be used to describe these modifications. White, et al. Expires September 21, 2017 [Page 4] =0C Internet-Draft OpenFabric March 2017 +----+ +----+ +----+ +----+ +----+ +----+ | 1A | | 1B | | 1C | | 1D | | 1E | | 1F | (T0) +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ | 2A | | 2B | | 2C | | 2D | | 2E | | 2F | (T1) +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ | 3A | | 3B | | 3C | | 3D | | 3E | | 3F | (T2) +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ | 4A | | 4B | | 4C | | 4D | | 4E | | 4F | (T1) +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ | 5A | | 5B | | 5C | | 5D | | 5E | | 5F | (T0) +----+ +----+ +----+ +----+ +----+ +----+ Figure 1 To reduce confusion (spine and leaf fabrics are difficult to draw in plain text art), this diagram does not contain the connections between devices. The reader should assume that each device in a given layer is connected to every device in the layer above it. For instance: o 5A is connected to 4A, 4B, 4C, 4D, 4E, and 4F o 5B is connected to 4A, 4B, 4C, 4D, 4E, and 4F o 4A is connected to 3A, 3B, 3C, 3D, 3E, 3F, 5A, 5B, 5C, 5D, 5E, and 5F o 4B is connected to 3A, 3B, 3C, 3D, 3E, 3F, 5A, 5B, 5C, 5D, 5E, and 5F o etc. The tiers or stages of the fabric are also marked for easier reference. T0 is assumed to be connected to application servers, or rather they are Top of Rack (ToR) routers. The remaining tiers, T1 and T2, are connected only to the fabric itself. Note there are no "cross links," or "east west" links in the illustrated fabric. The fabric locality detection mechanism described here will not work if there are cross links running east/west through the fabric. Locality White, et al. Expires September 21, 2017 [Page 5] =0C Internet-Draft OpenFabric March 2017 detection may be possible in such a fabric; this is an area for further study. See [RFC5449], [RFC5614], and [RFC7182] for similar solutions in the Mobile Ad Hoc Networking (MANET) solution space. The authors would like to thank Nick Russo, Rodny Molina, and Ivan Pepelnjak for their comments and review of the concepts and text of this document. 2. Modified Adjacency Formation While adjacency formation is not considered particularly burdensome in IS-IS, it is still useful to reduce the amount of state transferred across the network when connecting a new router to the fabric. Any such optimization is bound to present a tradeoff between several factors; the mechanism described here increases the amount of time required to form adjacencies slightly in order to reduce the total state carried across the network. The process is: o An IS connected to the fabric will send hellos on all links. o The IS will only complete the three-way handshake with one newly discovered neighbor; this would normally be the first neighbor which sends the newly connected intermediate system's ID back in the three-way handshake process. o The IS will complete its database exchange with this one newly adjacent neighbor. o Once this process is completed, the IS will continue processing the remaining neighbors as normal. This process allows each IS newly added to the fabric to exchange a full table once; a very minimal amount of information will be transferred with the remaining neighbors to reach full synchronization. 3. Determining Location on the Fabric The tier to which a router is connected is useful to enable autoconfiguration of routers connected to the fabric, and to reduce flooding. This section describes mechanisms for determining the tier at which a router is connected in the fabric in several steps. The first step is to find the Farthest Distance (FD) and the Total Distance (TD), which are useful in this process. To find the FD and TD: White, et al. Expires September 21, 2017 [Page 6] =0C Internet-Draft OpenFabric March 2017 o Calculate a Shortest Path Tree (SPT) for the entire network with all link metrics set to 1; this has the effect of calculating a tree based only on hop count o Find one node that is the farthest from the local node in the resulting tree; call this node F, and the distance to this node FD o Calculate an SPT for the entire network with all link metrics set to 1 from the perspective of F; call this TD 3.1. Determining T0 If FD =3D=3D TD =3D=3D 2, this is a three stage fabric; it is not = possible to determine the tier at which the local node is located based on any calculation, because the topology is perfectly symmetric. In this case: o The T0 routers MAY be manually configured to advertise 0x00 in their IS reachability tier sub-TLV, indicating they are at the edge of the fabric (a ToR router). o The T0 routers MAY detect that they are T0 through the the presence connected hosts (i.e. through a request for address assignment or some other means). This means of detection may not be reliable in all operational environments, and SHOULD be used with care. If such detection is used, and the router determines it is located at T0, it should advertise 0x00 in its IS reachability tier sub-TLV. o The router MAY examine the IS reachability tier sub-TLV of directly connected neighbors and determine one or more is advertising 0x1 in its IS reachability tier sub-TLVs. This would be the case if the spine routers in a three stage spine and leaf fabric are manually configured to advertise their tier as 0x1. o If there is no way to determine whether or not the local device is in T0 or T1, it MUST advertise 0xFF in its IS reachability tier sub-TLV. If FD =3D=3D TD, and TD >=3D 4, this is a greater than three stage = fabric; the local device SHOULD advertise 0x00 in its IS reachability tier sub-TLV. For instance, in the diagram above, 1A would: o Calculate an SPT with all link metrics set to 1; on this SPT, 5A through 5F would all have a distance of 4 White, et al. Expires September 21, 2017 [Page 7] =0C Internet-Draft OpenFabric March 2017 o Select one of these nodes as F; assume 5F is chosen as F o Set FD to 4, the distance to 5F o Run SPF from the perspective of 5F with all link metrics set to 1 o Set TD to 4, the cost from 5F to 1A o TD - FD =3D=3D 0, so 1A is at T0, and is a ToR 3.2. Determining T1 and above If FD =3D=3D TD =3D=3D 2, this is a three stage fabric; it is not = possible to determine the tier at which the local node is located based on any calculation, because the topology is perfectly symmetric. In this case: o The T1 routers MAY be manually configured to advertise 0x01 in their IS reachability tier sub-TLV. o The router MAY examine the IS reachability tier sub-TLV of directly connected neighbors and determine that one or more is advertising 0x00 in its IS reachability tier sub-TLVs. This would be the case if the ToR routers in a three stage spine and leaf fabric are manually configured to advertise their tier as 0x00. o If there is no way to determine whether or not the local device is in T0 or T1, it should advertise 0xFF in its IS reachability tier sub-TLV. If TD !=3D FD, this is a greater than three stage fabric; the local device SHOULD advertise (TD - FD) in its IS reachability tier sub- TLV. For example, in the above five stage fabric, 3B would: o Calculate an SPT with all link metrics set to 1; on this SPT, 5A through 5F and 1A through 1F would all have a cost of 2 o Select one of these nodes as F; assume 5F is chosen as F o Set FD to 2, the distance to 5F o Run SPF from the perspective of 5F with all link metrics set to 1 o Set TD to 4, the cost from 5F to 1A o TD - FD =3D=3D 2, so 1A is at T2, and is a spine switch White, et al. Expires September 21, 2017 [Page 8] =0C Internet-Draft OpenFabric March 2017 4. Flooding Optimization Flooding is perhaps the most challenging scaling issue for a link state protocol running on a dense, large scale fabric. To reduce flooding, OpenFabric takes advantage of information already available in the link state protocol, the list of the local intermediate system's neighbor's neighbors, and the fabric locality computed above. The following tables are required to compute a set of reflooders: o NL list: The set of neighbors o NN list: The set of neighbor's neighbors; this can be calculated by running SPF truncated to two hops o DNR list: The set of neighbors who should have LSPs (or fragments) marked Do Not Reflood (DNR) o RF list: The set of neighbors who should flood LSPs (or fragments) to their adjacent neighbors to ensure synchronization NL is set to contain all neighbors, and sorted deterministically (for instance, from the highest router ID to the lowest). All intermediate systems within a single fabric SHOULD use the same mechanism for sorting the NL list. NN is set to contain all neighbor's neighbors, or all intermediate systems that are two hops away, as determined by performing a truncated SPF. The DNR and RF tables are initially empty. To begin, the following steps are taken to reduce the size of NN and NL: o Move any IS in NL with its tier (or fabric location) set to T0 to DNR o Remove all intermediate systems from NL and NN that in the shortest path to the IS that originated the LSP Then, for every IS in NL: o If the current entry in NL is connected to any entries in NN: * Move the IS to RF * Remove the intermediate systems connected to the IS from NN o Else move the IS to DNR When flooding, LSPs transmitted to adjacent neighbors on the RF list will be transmitted normally. Adjacent intermediate systems on this White, et al. Expires September 21, 2017 [Page 9] =0C Internet-Draft OpenFabric March 2017 list will reflood received LSPs into the next stage of the topology, ensuring database synchronization. LSPs transmitted to adjacent neighbors on the DNR list, however, will be transmitted to the DNR address (see modifications to the IS-IS protocol, below). Any IS receiving a link state packet transmitted to the DNR address SHOULD NOT set the Send Route Message (SRM) flag on any interface for this LSP; hence the LSP will not be reflooded by this IS to any adjacent neighbor. This reduces flooding to the minimum possible while retaining full Link State Database (LSDB) synchronization. 5. Other Optimizations 5.1. Transit Link Reachability In order to reduce the amount of control plane state carried on large scale spine and leaf fabrics, openfabric implementations SHOULD NOT advertise reachability for transit links. These links MAY remain unnumbered, as IS-IS does not require layer 3 IP addresses to operate. Each router SHOULD be configured with a single loopback address, which is assigned an IPv6 address, to provide reachability to routers which make up the fabric. 5.2. Transiting T0 Routers In data center fabrics, ToR routers SHOULD NOT be used to transit between two T1 (or above) spine routers. The simplest way to prevent this is to set the overload bit [RFC3277] for all the LSPs originated from T0 routers. However, this solution would have the unfortunate side effect of causing all reachability beyond any T0 router to have the same metric, and many implementations treat a set overload bit as a metric of 0xFFFF in calculating the Shortest Path Tree (SPT). This document proposes an alternate solution which preserves the leaf node metric, while still avoiding transiting T0 routers. Specifically, all T0 routers SHOULD advertise their metric to reach any T1 adjacent neighbor with a cost of 0XFFE. T1 routers, on the other hand, will advertise T0 routers with the actual interface cost used to reach the T0 router. Hence, links connecting T0 and T1 routers will be advertised with an assymetric cost that discourages transiting T0 routers, while leaving reachability to the destinations attached to T0 devices the same. 6. OpenFabric and Route Aggregation While aggregation is not recommended in OpenFabric deployments, aggregation MAY take place when routing information is being transmitted from higher level tiers to lower level tiers. For White, et al. Expires September 21, 2017 [Page 10] =0C Internet-Draft OpenFabric March 2017 instance, in the example network, 2A through 2F could advertise a single default route to 1A through 1F. 2A through 2F would simply advertise the default as if it were an attached to each router locally using either a type 135 or 236 TLV, and then block TLVs that contain reachability information (such as types 135 and 236). Type 22 TLVs, however, MUST be flooded through this boundary, so that every router in the network shares a common view of the topology. Note that aggregation in a DC fabric can result in routing black holes in some cases, and also possibly reduce the efficiency of traffic engineering in the network. 7. OpenFabric Modifications to the IS-IS protocol 7.1. The Tier Level sub-TLV A new sub-TLV is added to the type 22 TLV to indicate tier level, as follows: o sub-TLV number (one octet): TBA o Tier identifier (one octet) The tier identifier field contains the tier number of the local router as calculated using the process above. If the tier number is unknown, the sub-TLV MUST be included with a tier ID of 0xFF, which indicates the advertising router does not have enough information to calculate its tier number, or there is some error in calculating a tier number. 7.2. The Do Not Reflood (DNR) address Link state packets flooded to the DNR layer 2 (MAC) address TBA SHOULD not be reflooded by receiving intermediate systems. 8. Security Considerations This document outlines modifications to the IS-IS protocol for operation on large scale data center fabrics. While it does add new TLVs, and some local processing changes, it does not add any new security vulnerabilities to the operation of IS-IS. However, OpenFabric implementions SHOULD implement IS-IS cryptographic authentication, as described in [RFC5304], and should enable other security measures in accordance with best common practices for the IS-IS protocol. White, et al. Expires September 21, 2017 [Page 11] =0C Internet-Draft OpenFabric March 2017 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, DOI 10.17487/RFC2629, June 1999, . [RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange Mechanism for IS-IS", RFC 5301, DOI 10.17487/RFC5301, October 2008, . [RFC5303] Katz, D., Saluja, R., and D. Eastlake 3rd, "Three-Way Handshake for IS-IS Point-to-Point Adjacencies", RFC 5303, DOI 10.17487/RFC5303, October 2008, . [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, . [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, DOI 10.17487/RFC5308, October 2008, . [RFC5311] McPherson, D., Ed., Ginsberg, L., Previdi, S., and M. Shand, "Simplified Extension of Link State PDU (LSP) Space for IS-IS", RFC 5311, DOI 10.17487/RFC5311, February 2009, . 9.2. Informative References [I-D.ietf-isis-segment-routing-extensions] Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., Litkowski, S., Decraene, B., and j. jefftant@gmail.com, "IS-IS Extensions for Segment Routing", draft-ietf-isis- segment-routing-extensions-11 (work in progress), March 2017. White, et al. Expires September 21, 2017 [Page 12] =0C Internet-Draft OpenFabric March 2017 [I-D.ietf-spring-segment-routing] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", draft-ietf- spring-segment-routing-11 (work in progress), February 2017. [RFC3277] McPherson, D., "Intermediate System to Intermediate System (IS-IS) Transient Blackhole Avoidance", RFC 3277, DOI 10.17487/RFC3277, April 2002, . [RFC3719] Parker, J., Ed., "Recommendations for Interoperable Networks using Intermediate System to Intermediate System (IS-IS)", RFC 3719, DOI 10.17487/RFC3719, February 2004, . [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2008, . [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, . [RFC5449] Baccelli, E., Jacquet, P., Nguyen, D., and T. Clausen, "OSPF Multipoint Relay (MPR) Extension for Ad Hoc Networks", RFC 5449, DOI 10.17487/RFC5449, February 2009, . [RFC5614] Ogier, R. and P. Spagnolo, "Mobile Ad Hoc Network (MANET) Extension of OSPF Using Connected Dominating Set (CDS) Flooding", RFC 5614, DOI 10.17487/RFC5614, August 2009, . [RFC6232] Wei, F., Qin, Y., Li, Z., Li, T., and J. Dong, "Purge Originator Identification TLV for IS-IS", RFC 6232, DOI 10.17487/RFC6232, May 2011, . White, et al. Expires September 21, 2017 [Page 13] =0C Internet-Draft OpenFabric March 2017 [RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)", RFC 7182, DOI 10.17487/RFC7182, April 2014, . [RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Nadeau, "An Architecture for the Interface to the Routing System", RFC 7921, DOI 10.17487/RFC7921, June 2016, . Authors' Addresses Russ White LinkedIn Email: russ@riw.us Shawn Zandi LinkedIn Email: szandi@linkedin.com Nikos Triantafillis LinkedIn Email: ntriantafillis@gmail.com Hannes Gredler RtBrick Inc. Email: hannes@rtbrick.com White, et al. Expires September 21, 2017 [Page 14] ------=_NextPart_000_097A_01D2A156.C8AE4810-- From nobody Mon Mar 20 07:51:30 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16AE4126D05 for ; Mon, 20 Mar 2017 07:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 MzTgCO8gH6I8 for ; Mon, 20 Mar 2017 07:51:28 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 897FE1271DF for ; Mon, 20 Mar 2017 07:51:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6590; q=dns/txt; s=iport; t=1490021487; x=1491231087; h=to:from:subject:message-id:date:mime-version; bh=v0TsLs7A78HeGeHokhvs2hqQVDFCz+i/UVpMCFi+1Vc=; b=YTZflyfl7dTFRvmJT/brOt2yKapWzNtkBPa9LDRk9iwf3xYvx78JoXck pfuwfdtG3DcHMslAtDboPNjo6yZeqobeOvH05m/DbY/LHZUUM1Ed2KFr3 K1AjZeSNqvBIGTppMSZTjpR5BNYz+DLE/i9WwLc0ST/Trj78miL5KYOFE k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANCwB8689Y/xbLJq1eHQEFAQsBgm45g?= =?us-ascii?q?QsqhEKLA5BKkDODIIIPgg4qiUcWAQIBAQEBAQEBayiFP4EzAl8NCAEBiXwOmDW?= =?us-ascii?q?QBoImK4ofAQEIAQEBAQEeBYZOggUIhxIBgymCXwWcTYZ5i0qBe4hbhlWIUIJ2i?= =?us-ascii?q?BIlATE+RiMWCBcVhRUggWNAh2sBJYIXAQEB?= X-IronPort-AV: E=Sophos;i="5.36,194,1486425600"; d="scan'208,217";a="650553967" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Mar 2017 14:51:25 +0000 Received: from [10.63.23.130] (dhcp-ensft1-uk-vla370-10-63-23-130.cisco.com [10.63.23.130]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v2KEpPVc002332 for ; Mon, 20 Mar 2017 14:51:25 GMT To: RTGWG From: Robert Wilton Subject: Maximum-reserved-bandwidth in YANG Message-ID: Date: Mon, 20 Mar 2017 14:51:25 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------13F6A01BCDDCD090B45D5D76" Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 14:51:30 -0000 This is a multi-part message in MIME format. --------------13F6A01BCDDCD090B45D5D76 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, I'm working on a YANG model in NETMOD to cover some of standard interface configuration that is commonly implemented by vendors but doesn't necessarily represent configuration that is covered by any published standards documents. https://datatracker.ietf.org/doc/draft-ietf-netmod-intf-ext-yang/ One of the leaves that the module defines is a "bandwidth leaf": 3.1. Bandwidth The bandwidth configuration leaf allows the specified bandwidth of an interface to be reduced from the inherent interface bandwidth. The bandwidth leaf affects the routing metric cost associated with the interface. Note that the bandwidth leaf does not actually limit the amount of traffic that can be sent/received over the interface. If required, interface traffic can be limited to the required bandwidth by configuring an explicit QoS policy. Note for reviewers: Given that the bandwidth only controls routing metrics, it may be more appropriate for this leaf, or an equivalent, to be defined as part of one of the routing YANG modules. Although conversely, it is also worth considering that the corresponding existing CLI configuration command is an interface level bandwidth command in many implementations. Acee has suggested that this leaf may be in fact represent a slightly generalized version of maximum-reservable-bandwidth defined in RFC 3630: 2.5.7. Maximum Reservable Bandwidth The Maximum Reservable Bandwidth sub-TLV specifies the maximum bandwidth that may be reserved on this link, in this direction, in IEEE floating point format. Note that this may be greater than the maximum bandwidth (in which case the link may be oversubscribed). This SHOULD be user-configurable; the default value should be the Maximum Bandwidth. The units are bytes per second. I plan to update the draft to rename "bandwidth" to "reservable-bandwidth" and align the definition more closely to the definition of Maximum Reservable Bandwidth, but generalized over any routing protocol. In particularly I'll change the definition to allow the value to be greater than the max hardware bandwidth. Does anyone have any thoughts on whether this should be standardized as part of a common routing YANG module (and if so which one) rather than the existing interfaces common YANG module? Otherwise, does anyone have any comments on the proposed definition? Thanks, Rob --------------13F6A01BCDDCD090B45D5D76 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi,

I'm working on a YANG model in NETMOD to cover some of standard interface configuration that is commonly implemented by vendors but doesn't necessarily represent configuration that is covered by any published standards documents.

https://datatracker.ietf.org/doc/draft-ietf-netmod-intf-ext-yang/

One of the leaves that the module defines is a "bandwidth leaf":

3.1.  Bandwidth

   The bandwidth configuration leaf allows the specified bandwidth of an
   interface to be reduced from the inherent interface bandwidth.  The
   bandwidth leaf affects the routing metric cost associated with the
   interface.

   Note that the bandwidth leaf does not actually limit the amount of
   traffic that can be sent/received over the interface.  If required,
   interface traffic can be limited to the required bandwidth by
   configuring an explicit QoS policy.

   Note for reviewers: Given that the bandwidth only controls routing
   metrics, it may be more appropriate for this leaf, or an equivalent,
   to be defined as part of one of the routing YANG modules.  Although
   conversely, it is also worth considering that the corresponding
   existing CLI configuration command is an interface level bandwidth
   command in many implementations.


Acee has suggested that this leaf may be in fact represent a slightly generalized version of maximum-reservable-bandwidth defined in RFC 3630:

2.5.7.  Maximum Reservable Bandwidth

   The Maximum Reservable Bandwidth sub-TLV specifies the maximum
   bandwidth that may be reserved on this link, in this direction, in
   IEEE floating point format.  Note that this may be greater than the
   maximum bandwidth (in which case the link may be oversubscribed).
   This SHOULD be user-configurable; the default value should be the
   Maximum Bandwidth.  The units are bytes per second.


I plan to update the draft to rename "bandwidth" to "reservable-bandwidth" and align the definition more closely to the definition of Maximum Reservable Bandwidth, but generalized over any routing protocol.  In particularly I'll change the definition to allow the value to be greater than the max hardware bandwidth.

Does anyone have any thoughts on whether this should be standardized as part of a common routing YANG module (and if so which one) rather than the existing interfaces common YANG module?

Otherwise, does anyone have any comments on the proposed definition?

Thanks,
Rob


--------------13F6A01BCDDCD090B45D5D76-- From nobody Mon Mar 20 10:56:25 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A67D1294A2; Mon, 20 Mar 2017 10:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 GrfMMHN54rAz; Mon, 20 Mar 2017 10:56:21 -0700 (PDT) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (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 85668131618; Mon, 20 Mar 2017 10:55:51 -0700 (PDT) Received: by mail-wm0-x241.google.com with SMTP id n11so16052410wma.0; Mon, 20 Mar 2017 10:55:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version:content-transfer-encoding; bh=sDxgp7BQMyY9EtcUy42LVqyR6Su++xmzIOSMblnhiUY=; b=W2FB5zDNARV4rTJS9eCo21OR6KIM2WTKMPZGfBweOJL/CmwtlyqHwkmReid6FHMLsm UOAKFOzLOnaf3e6h2HBfVcyJLv8nwI7hZ96q6z4blffoQO/gXQSNK5e6gqJzsEhbZmif FVmCHnF+szrNCIremyW0aVC5rl/IFi5RGe2qxnEUZCxNJPzwwYIPo3E8epr+7hKQwYJ5 NLrY8BveRNynb1LZfhzBXBDm057xuyDS1+rCSKVL35LFi3UqQ/LoKioH0yvOm7Qy1bW1 p7lNVOzE6PtV6mnOmotUANzaFnZfBu7CILfys9GohA/ClVwDYLQ+mA2HKT1ZSLK7sUMv GbAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=sDxgp7BQMyY9EtcUy42LVqyR6Su++xmzIOSMblnhiUY=; b=sb2R1oJMnplBMYoDjzKRqQqbIY41qjEmDGrIsaMimzKkEkWSNmpPYwPxOUnc+jNtVV l0La7MDxDPO7MW9Zvlnqju0NimSFYxDaRUov1AmEQZkVgWX68H9CPJ51x9TwXuXO6cOZ e9tsOOMVUaX071OZvDnuQByz3jEAa1RHgIR1jmEUd7Bc4/gUemCPuoJdkvm4Ro9U5POn 6ky+71O2wDxf/xRP5qKZe65/V7p6hSLcG7RaN/I5fddDF9wO3aRCr8GmqHbb/rPN9JRS Bj3mX69nNK6jMR5p0lEMnQZ3FxR6XA/DVYMoOc52kqTZAhiQQVsN+zuTxqGzC1Smt+38 puew== X-Gm-Message-State: AFeK/H3isOkiJtLo3Ty6ywtzYa6/B6F4AGFq42Bv/RbKpWONAw4eZHLWmzhawHU1hSNxzA== X-Received: by 10.28.37.3 with SMTP id l3mr9269529wml.100.1490032549356; Mon, 20 Mar 2017 10:55:49 -0700 (PDT) Received: from [172.20.7.250] ([46.218.58.213]) by smtp.gmail.com with ESMTPSA id g5sm21504146wrb.48.2017.03.20.10.55.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Mar 2017 10:55:48 -0700 (PDT) User-Agent: Microsoft-MacOutlook/f.1f.0.170216 Date: Mon, 20 Mar 2017 10:56:00 -0700 Subject: Re: [Isis-wg] Updated openfabric draft From: Jeff Tantsura To: Russ White , , Message-ID: Thread-Topic: [Isis-wg] Updated openfabric draft References: <097901d2a178$4fbf72e0$ef3e58a0$@riw.us> In-Reply-To: <097901d2a178$4fbf72e0$ef3e58a0$@riw.us> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 17:56:23 -0000 Russ, Thanks for sending the updated version. It would be useful if during your presentation you=E2=80=99d go over changes from= 00 to 01. Thanks! =20 Cheers, Jeff =20 On 3/20/17, 05:48, "Isis-wg on behalf of Russ White" wrote: Y'all -- =20 Due to my negligence/laziness... =F0=9F=98=8A We missed the deadline for puttin= g the new draft up in the IETF system before Chicago next week. Since we wil= l be presenting the newer version of the draft in RTGWG, I've attached it he= re.=20 =20 =F0=9F=98=8A =20 Russ _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg =20 From nobody Tue Mar 21 04:21:48 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 811B21296E5; Tue, 21 Mar 2017 04:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 GoVN5GnDFeYM; Tue, 21 Mar 2017 04:21:44 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::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 5E610129439; Tue, 21 Mar 2017 04:21:44 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id l37so109994985wrc.1; Tue, 21 Mar 2017 04:21:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=QjU99mO5747o7093u1f+b72Fu5fHcgjzQNkoTtjbgek=; b=YS+p0iBaKmjNHr2FjgjyXr8Dcc9pLqq/kqpA9/Nt/7GaZtoLarYUyf3RNY70J9VvR/ G4gTL33AmJ5zmA0Fgf/nfmncKXWELO4+QdZLzUWj0Og7vw4neYHr/lzQSn2nV2VL/NUK fUh4tyKf1WZpvz7JD1jV6pAjSpXCRwrxX4uonyp7qcv7UhxPGjoGAMIwPSZa7uUSkFGp JSqHT/pJXipp3tngmzgrzFx6jLbYHIh5tmg01NZyi+ikGUlBmFePhWqDNYXnfvQ4BJFN 4GdBz1Mkh4DM7SR0U/4VX3WeHohk8WjJYyEvDlQNbqrQu50jMggqfxalE4ri4BY9Uji4 6oEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=QjU99mO5747o7093u1f+b72Fu5fHcgjzQNkoTtjbgek=; b=NPNrrP3uda6rHlQU6bFdXIVnY2GpEW9Kpg6vwL0zfCbXZAErCRTVYj7H5NaRH4Imp7 R2qK0VkNQTf6Pr+cbKXIwJhSf8ESpCS7dohLTTwJZrWyuCvTO6k3PPcvQo1uNCfCkzYu XVKcX8cALO4Aa2o2JQSjVkgB35WGFQsmx2nhvTXa49JVTyO7pBI+KfkFAM8wZaVIMvLb ACIBpD7ge30jkaDgGAJ0mWKGWgCKmf9wZI4eAJFqNWHBXOG5tS/fMynQunD6qY4i9Bcb 9SoAC4JgUC0RH4+xdXwwKqlMjgMbpxcAuRr/CVYIJvuVMmQYfuV2I1GHkXnMNY1ngEH4 MQwg== X-Gm-Message-State: AFeK/H3Pv2TxxJ8lZ7gCu+ov0t0UXzzHRjU9JCMvwnHtel29jDSTDXGfZCyVtn4Zyce1GA== X-Received: by 10.223.171.210 with SMTP id s76mr32890313wrc.102.1490095302878; Tue, 21 Mar 2017 04:21:42 -0700 (PDT) Received: from [172.20.7.250] ([46.218.58.213]) by smtp.gmail.com with ESMTPSA id m201sm17267666wmd.19.2017.03.21.04.21.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Mar 2017 04:21:41 -0700 (PDT) User-Agent: Microsoft-MacOutlook/f.20.0.170309 Date: Tue, 21 Mar 2017 04:21:41 -0700 Subject: Re: [Netconf] Draft Charter Proposal for NETCONF WG From: Jeff Tantsura To: "t.petch" , Mehmet Ersue , 'Benoit Claise' CC: 'Netconf' , RTGWG Message-ID: <30B0C127-1FA5-4177-9718-F687029F24C9@gmail.com> Thread-Topic: [Netconf] Draft Charter Proposal for NETCONF WG References: <014101d2913a$3db72870$b9257950$@gmail.com> <070e01d291ba$9bb8f4a0$4001a8c0@gateway.2wire.net> <072D22E1-66DA-414E-BD16-C43D36BE9B6E@juniper.net> <026e01d29273$5cc0cfc0$4001a8c0@gateway.2wire.net> <5A12F60C-3BA9-41A2-B77C-9E73B9DA115D@juniper.net> <05c201d2941a$d4bd4500$4001a8c0@gateway.2wire.net> <20170303133448.GA3133@elstar.local> <00b201d2942b$32395b50$96ac11f0$@gmail.com> <014701d29753$bb651790$322f46b0$@ndzh.com> <005101d2975f$ae87ac20$0b970460$@ndzh.com> <017d01d29769$0df70b20$29e52160$@gmail.com> <010701d29771$a45f66e0$ed1e34a0$@ndzh.com> <026601d2977f$8d059600$a710c200$@gmail.com> <685B9088-7557-4C6E-9A8F-54C3208DB312@juniper.net> <7217bc23-0e1e-c250-929d-e18c3f0a800f@cisco.com> <07b601d2a197$9865d5b0$c9318110$@gmail.com> <02ee01d2a22b$295b2be0$4001a8c0@gateway.2wire.net> In-Reply-To: <02ee01d2a22b$295b2be0$4001a8c0@gateway.2wire.net> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 11:21:47 -0000 Tom, Including RTGWG, the draft-ietf-rtgwg-yang-key-chain home. In general, there=E2=80=99s no interactions, rtgwg-yang-key-chain work has been f= ocused on data model for routing protocols key-chain=E2=80=99s configuration and m= anagement. Thanks! =20 Cheers, Jeff On 3/21/17, 03:08, "Netconf on behalf of t.petch" wrote: What interaction, if any, is there between =20 draft-ietf-rtgwg-yang-key-chain-15.txt This document describes the key chain YANG data model. file "ietf-key-chain@2017-02-16.yang" =20 currently in IETF Last Call, and =20 draft-ietf-netconf-system-keychain-00 This document defines a YANG data module for a system-level keychain mechanism file "ietf-system-keychain@2016-07-08.yang" =20 ? =20 Tom Petch =20 =20 ----- Original Message ----- From: "Mehmet Ersue" To: "'Benoit Claise'" ; "'Susan Hares'" Sent: Monday, March 20, 2017 4:32 PM =20 > Dear All, > > > > based on the recent discussion and proposals please find below the updated > charter proposal for NETCONF WG. > > Please comment before March 24, 2017. > > > Following Benoit's support the I2RS-related additions have been added as a > separated item. > > Being dependent on netmod-revised-datastores point 6 and 7 have been defined > as a goal without a deadline. > > > Mehmet > > > Network Configuration (netconf) > > ------------------------------- > > > > Charter > > > > Current Status: Active > > > > Chairs: > > Mahesh Jethanandani > > Mehmet Ersue > > > > Operations and Management Area Directors: > > Benoit Claise > > Joel Jaeggli > > > > Operations and Management Area Advisor: > > Benoit Claise > > > > Mailing Lists: > > General Discussion: netconf@ietf.org > > To Subscribe: https://www.ietf.org/mailman/listinfo/netconf > > Archive: > https://mailarchive.ietf.org/arch/browse/netconf/ > > > > Description of Working Group: > > > > Configuration of networks of devices has become a critical requirement > > for operators in today's highly interconnected networks. Large and > > small operators alike have developed their own mechanisms or have used > > vendor specific mechanisms to transfer configuration data to and from > > a device and to examine device state information which may impact the > > configuration. Each of these mechanisms may be different in various > > aspects, such as session establishment, user authentication, > > configuration data exchange, and error responses. > > > > The NETCONF protocol (RFC 6241) provides mechanisms to install, > > manipulate, and delete the configuration of network devices. NETCON= F > > is based on the secure transport (SSH is mandatory to implement while > > TLS is an optional transport). The NETCONF protocol is data modelin= g > > language independent, but YANG (RFC 7950) is the recommended NETCON= F > > modeling language, which introduces advanced language features for > > configuration management. > > > > NETCONF WG recently finalized the development of RESTCONF protocol > > (RFC 8040) which provides an interface over HTTPs for accessing dat= a > > defined in YANG. RESTCONF is based on the capabilities and uses the > > datastore concept defined in the NETCONF protocol specification. In > > support of RESTCONF the YANG-Patch (RFC 8072) mechanism has been > > provided for applying patches to configuration datastores. The YANG > > Module Library (RFC 7895) provides information about all YANG modules > > used by a network management server. > > > > Last but not least NETCONF and RESTCONF Call Home (RFC 8071) have been > > developed, which enable a server to initiate a secure connection to a > > NETCONF or RESTCONF client respectively. > > > > In the current phase of NETCONF's incremental development the > > workgroup will focus on following items: > > > > 1. Finalize the YANG data module for a system-level keystore mechanism, > > that can be used to hold onto asymmetric private keys and certificates > > that are trusted by the system advertising support for this module. > > Based on the known dependencies this draft has the highest priority > > for the WG. > > > > 2. Finalize Server and Client Configuration YANG modules for both > > NETCONF and RESTCONF as well as the Client and Server Models for SS= H > > and TLS. > > > > 3. Finalize the Zero-touch provisioning for NETCONF or RESTCONF-based > > Management as a technique to establish a secure network management > > relationship between a newly delivered network device configured with > > just its factory default settings, and the Network Management System) > > > > 4. Provide a revised version of RFC 6536 (NETCONF Access Control > > Model) by adding support for RESTCONF and the YANG 1.1. constructs > > like "action" and the "notification" statements. > > > > 5. Provide a set of documents enabling advanced notification/ > > subscription capabilities, which gracefully co-exist in a deploymen= t > > of RFC 5277. The new capabilities include e.g. transport independence, > > multiple dynamic and configured subscriptions in a transport > > session. RFC 5277 will be obsoleted in parallel to the publication of > > the new document set. Following specifications will be addressed: > > - Protocol-neutral notification framework, i.e., explaining the > > concepts of subscriptions, filters, subscription state > > notifications, replay, etc. and defining the associated YANG dat= a > > model, RPCs, etc. > > - Definition of notifications sent over NETCONF and how YANG > > notifications are encoded in XML and JSON. Include consideration= s > > for parallel support / implementation compatibility with RFC-5277. > > - Definition of notifications sent over RESTCONF and HTTP2 and how > > YANG notifications are encoded in XML and JSON. Include specific= s > > of call-home and heartbeat for subscriptions. > > - The subscription and push mechanism for YANG datastores allowing > > subscriber applications to request updates from a YANG datastore= . > > > > 6. Provide a revision for the NETCONF and RESTCONF protocols and th= e > > used datastore framework building on the datastore concept in NETMO= D > > revised datastores work. Bug fixing will be done and potential > > extensions will be added. Provide guidance on how to adapt and use > > YANG with NETCONF and RESCONF protocols. NETCONF XML Encoding Rules > > from RFC 7950 will be moved to RFC6241bis. > > > > 7. Define capabilities for NETCONF and RESTCONF to support I2RS protocol > > and ephemeral state datastore requirements. > > > > Based on the implementation, deployment experience and inter- > > operability testing, the WG aims to produce a NETCONF status report > > in a later stage. The result may be clarifications for RFC6241 and > > RFC6242 and addressing any reported errata. > > > > > > Goals and Milestones: > > Done Submit NETCONF/RESTCONF Call Home to AD/IESG for consideration as > Proposed Standard > > Done Submit YANG Library to AD/IESG for consideration as Proposed > Standard > > Done Submit RESTCONF to AD/IESG for consideration as Proposed Standard > > Done Submit YANG Patch to AD/IESG for consideration as Proposed > Standard > > > > May 2017 WGLC for Zero-touch configuration mechanism > > Jun 2017 Submit Zero-touch configuration to AD/IESG for consideration as > Proposed Standard > > May 2017 WGLC for system-level keystore mechanism > > Jun 2017 Submit keystore mechanism to AD/IESG for consideration as > Proposed Standard > > May 2017 WGLC for Server and Client models for NETCONF and RESTCON= F > > Jun 2017 Submit Server and Client Configuration models to AD/IESG for > consideration as Proposed Standard > > May 2017 WGLC for Client and Server Models for SSH and TLS > > Jun 2017 Submit Client and Server Models for SSH and TLS to AD/IES= G for > consideration as Proposed Standard > > Jun 2017 WGLC for RFC 6536bis (NETCONF Access Control Model) > > Jul 2017 Submit RFC 6536bis to AD/IESG for consideration as Proposed > Standard > > Jun 2017 WGLC for advanced Notification/Subscription specification= s > > Jul 2017 Submit Notification/Subscription specifications to AD/IES= G for > consideration as Proposed Standard > > > > > > From: Benoit Claise [mailto:bclaise@cisco.com] > Sent: Friday, March 17, 2017 4:49 PM > To: Kent Watsen ; Mehmet Ersue ; > 'Susan Hares' ; 'Andy Bierman' > Cc: 'Netconf' > > > > On 3/8/2017 12:57 AM, Kent Watsen wrote: > > I agree with Mehmet, any changes to the NC/RC protocols should be don= e in > the NETCONF WG. > > +1. > > Regards, Benoit > > =20 =20 =20 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf =20 From nobody Tue Mar 21 07:13:33 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B59E712994E for ; Tue, 21 Mar 2017 07:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iit-edu.20150623.gappssmtp.com 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 EpdILHhjZYMh for ; Tue, 21 Mar 2017 07:13:30 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::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 5A6341298D3 for ; Tue, 21 Mar 2017 07:13:30 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id d188so95141421vka.0 for ; Tue, 21 Mar 2017 07:13:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iit-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=h7FBqeZx/r2N43MABTNUJT6toXjSaszdX6h49FfvzoU=; b=fAkdcA1fhPfmkgSqs8CR7vvFIFNEk1+oK8FNzOqACNXFeTq3httay5wSJ6SFFMC+H9 qflCNhttSF/ibthIIos2gzl68zCocaMrD9MnoLcoLYqYIeUXUQHL2SekMHXVfhlLSYGy Nnp7lk6Gio0mdbFIqihnG8+oxaoGbJ6YO5r0sDpzP+vwME09Te1NlUr0svK4/P+Fcz4S ekMX7vTj0mkSLVzLeiP48ilwpB3UWgerKqVEgqLPURXMaAOoHkkCgjSo4QIeUYpm+cyz 0OaBepns2gvIZVcWN2cmiFpIf8SAzhkm8CLYGCtWnsR2806uZyLWoSa5v7xsue2/5I8H oqJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=h7FBqeZx/r2N43MABTNUJT6toXjSaszdX6h49FfvzoU=; b=IYGEMhGCSXwG238NXe0/v2trpn2D9WMFZzLAOSbco77CSnDrsAHIYSuf0sFN8UyGr6 lL7hi6JjeoWG5cM8NB7Il+pHsBoeJPl9Y8m9/7mYOtJImwn6OkaBz/6sZqjKNja4oH/t MKS1xwanrDOEM49OUQJo13Zo1dDB+Wvp1k+T/nsqgjNXEShT8lT3D4n2oxRoEunFpkxQ xW6HzTsmTK842OCQd4mw6rbONfaRLW5p8j+KI4hutELQmGgUOLtQq782E7aNO6RDjWk0 uMH/dOmM8wZ9dY/24d4uf4YeWf4eqskR6PTZzDlaRxd7uvmcyHTOLh+L8KbJpEHbJDUA Hk9Q== X-Gm-Message-State: AFeK/H2Nd3J5s1/aCmKXygTbJnpdpVRkPF5KRVTSkH60xW+bf2Q1SH1EW36Vo7+Uc6QWWCqBZac8SoQ9w+brnpgJ X-Received: by 10.159.48.220 with SMTP id k28mr1203216uab.50.1490105609347; Tue, 21 Mar 2017 07:13:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.90.9 with HTTP; Tue, 21 Mar 2017 07:12:58 -0700 (PDT) In-Reply-To: References: From: Sanjiv Kapoor Date: Tue, 21 Mar 2017 09:12:58 -0500 Message-ID: Subject: Re: New Document To: rtgwg@ietf.org, Fab Devetak Content-Type: multipart/alternative; boundary=94eb2c1b45a485f58b054b3e3f46 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 14:13:33 -0000 --94eb2c1b45a485f58b054b3e3f46 Content-Type: text/plain; charset=UTF-8 As Jeff suggested, I am inviting discussion on Re: https://www.ietf.org/internet-drafts/draft-kapoor-rtgwg- dynamic-multipath-routing-00.txt This document introduces a method for simultaneous routing and congestion control across multi-path flows. The basic methods for change of flow is an additive increase and multiplicative decrease on congestion (like TCP). Extra flow requirements and congestion is dealt with by finding additional (shortest ) paths using the queue length as a measure for congestion at the links. This requires knowledge of the link state. There are two methods described, the second method achieves fair distribution of traffic flow by using a concurrency parameter, Gamma, which alters the cost of paths being used by a particular source destination traffic flow. These methods have been simulated (by Fab) using NS3 and results may be found on http://www.cs.iit.edu/~kapoor/papers/reducerate.pdf On Wed, Mar 15, 2017 at 4:18 PM, Sanjiv Kapoor wrote: > A new Internet Draft > > https://www.ietf.org/internet-drafts/draft-kapoor-rtgwg > -dynamic-multipath-routing-00.txt > > has been posted. > > Please send us comments. > > Thanks > > Sanjiv Kapoor > --94eb2c1b45a485f58b054b3e3f46 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As Jeff suggested, I am inviting =C2=A0discussion on<= /div>Re:=C2=A0https://www.ietf.org/internet-drafts/draf= t-kapoor-rtgwg-dynamic-multipath-routing-00.= txt

This document introduces a method for simul= taneous routing and congestion control across multi-path flows. The basic m= ethods for change of flow is an additive increase and multiplicative decrea= se on congestion (like TCP). Extra flow requirements and =C2=A0congestion i= s dealt with by finding additional (shortest ) paths using the queue length= as a measure for congestion at the links. This requires knowledge of the l= ink state.=C2=A0

There are two methods described, = the second method achieves fair distribution of traffic flow by using a con= currency parameter, Gamma, which alters the cost of paths being used by a p= articular source destination traffic flow.

These m= ethods =C2=A0have been simulated (by Fab) using =C2=A0NS3 and results may b= e found on=C2=A0



On Wed, Mar 15, 2017 at 4:1= 8 PM, Sanjiv Kapoor <kapoor@iit.edu> wrote:

has been posted.

Please send us comments.

Thanks

Sanjiv Kapoor=

--94eb2c1b45a485f58b054b3e3f46-- From nobody Tue Mar 21 07:22:53 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D4E1294AC; Tue, 21 Mar 2017 07:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 jc5jIkX5Q9WS; Tue, 21 Mar 2017 07:22:42 -0700 (PDT) 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 B092C12949D; Tue, 21 Mar 2017 07:22:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11946; q=dns/txt; s=iport; t=1490106162; x=1491315762; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Ph0rGFaaKoq/HRlY9mrOLKcfp4mBMGd+FyO9yJFdgms=; b=EQGZB0rWNviGPnI3j0PrieFLYNFNxPZx7b6kKW+zSBt2fGohhoQ8NsJJ JcG7cxaMJGFxRyDRRXLg4C4bASetDD3vWl0zzrQeutD9ixOhjN/WTv0Xb MVqPD54uWRs8wAlAZv6vXzQ+OcyAFXzfg/xZajt+ok3WtEe99Fhd5QRDG I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQCdNtFY/4MNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQoHjWuRXogSjTKCDh8LhS5KAoMSPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?VAQEBAQMBAWwEAgUMBAIBCBUBAgwBGgchBgsUEQIEAQkEBYlsAxUOrRyHPw2DB?= =?us-ascii?q?AEBAQEBAQEBAQEBAQEBAQEBAQEBARgFiz2CUYFLIhaFZQWJHYcBi3g6AYZ5hxq?= =?us-ascii?q?EMoF7hSiDV4YzimuET4QkAR84gQRYFUGGV3WHE4EhgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.36,198,1486425600"; d="scan'208";a="223026951" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Mar 2017 14:22:41 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v2LEMfbv008286 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 21 Mar 2017 14:22:41 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 21 Mar 2017 10:22:40 -0400 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.1210.000; Tue, 21 Mar 2017 10:22:40 -0400 From: "Acee Lindem (acee)" To: Jeff Tantsura , "t.petch" , Mehmet Ersue , "Benoit Claise (bclaise)" CC: "'Netconf'" , RTGWG Subject: Re: [Netconf] Draft Charter Proposal for NETCONF WG Thread-Topic: [Netconf] Draft Charter Proposal for NETCONF WG Thread-Index: AQHSojVbsjloti5TfEiMBOab9w67O6GfWMEA Date: Tue, 21 Mar 2017 14:22:40 +0000 Message-ID: References: <014101d2913a$3db72870$b9257950$@gmail.com> <070e01d291ba$9bb8f4a0$4001a8c0@gateway.2wire.net> <072D22E1-66DA-414E-BD16-C43D36BE9B6E@juniper.net> <026e01d29273$5cc0cfc0$4001a8c0@gateway.2wire.net> <5A12F60C-3BA9-41A2-B77C-9E73B9DA115D@juniper.net> <05c201d2941a$d4bd4500$4001a8c0@gateway.2wire.net> <20170303133448.GA3133@elstar.local> <00b201d2942b$32395b50$96ac11f0$@gmail.com> <014701d29753$bb651790$322f46b0$@ndzh.com> <005101d2975f$ae87ac20$0b970460$@ndzh.com> <017d01d29769$0df70b20$29e52160$@gmail.com> <010701d29771$a45f66e0$ed1e34a0$@ndzh.com> <026601d2977f$8d059600$a710c200$@gmail.com> <685B9088-7557-4C6E-9A8F-54C3208DB312@juniper.net> <7217bc23-0e1e-c250-929d-e18c3f0a800f@cisco.com> <07b601d2a197$9865d5b0$c9318110$@gmail.com> <02ee01d2a22b$295b2be0$4001a8c0@gateway.2wire.net> <30B0C127-1FA5-4177-9718-F687029F24C9@gmail.com> In-Reply-To: <30B0C127-1FA5-4177-9718-F687029F24C9@gmail.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.198] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 14:22:46 -0000 Tom, If you read the two drafts and look at the data nodes in the two models, you=B9ll quickly realize that they have entirely different purposes. Thanks, Acee=20 On 3/21/17, 7:21 AM, "rtgwg on behalf of Jeff Tantsura" wrote: >Tom, > >Including RTGWG, the draft-ietf-rtgwg-yang-key-chain home. >In general, there=B9s no interactions, rtgwg-yang-key-chain work has been >focused on data model for routing protocols key-chain=B9s configuration an= d >management. > >Thanks! >=20 >Cheers, >Jeff > >On 3/21/17, 03:08, "Netconf on behalf of t.petch" > wrote: > > What interaction, if any, is there between > =20 > draft-ietf-rtgwg-yang-key-chain-15.txt > This document describes the key chain YANG data model. > file "ietf-key-chain@2017-02-16.yang" > =20 > currently in IETF Last Call, and > =20 > draft-ietf-netconf-system-keychain-00 > This document defines a YANG data module for a system-level keychain > mechanism > file "ietf-system-keychain@2016-07-08.yang" > =20 > ? > =20 > Tom Petch > =20 > =20 > ----- Original Message ----- > From: "Mehmet Ersue" > To: "'Benoit Claise'" ; "'Susan Hares'" > > Sent: Monday, March 20, 2017 4:32 PM > =20 > > Dear All, > > > > > > > > based on the recent discussion and proposals please find below the > updated > > charter proposal for NETCONF WG. > > > > Please comment before March 24, 2017. > > > > > > Following Benoit's support the I2RS-related additions have been >added > as a > > separated item. > > > > Being dependent on netmod-revised-datastores point 6 and 7 have been > defined > > as a goal without a deadline. > > > > > > Mehmet > > > > > > Network Configuration (netconf) > > > > ------------------------------- > > > > > > > > Charter > > > > > > > > Current Status: Active > > > > > > > > Chairs: > > > > Mahesh Jethanandani > > > > Mehmet Ersue > > > > > > > > Operations and Management Area Directors: > > > > Benoit Claise > > > > Joel Jaeggli > > > > > > > > Operations and Management Area Advisor: > > > > Benoit Claise > > > > > > > > Mailing Lists: > > > > General Discussion: netconf@ietf.org > > > > To Subscribe: https://www.ietf.org/mailman/listinfo/netconf > > > > Archive: > > > https://mailarchive.ietf.org/arch/browse/netconf/ > > > > > > > > Description of Working Group: > > > > > > > > Configuration of networks of devices has become a critical > requirement > > > > for operators in today's highly interconnected networks. Large and > > > > small operators alike have developed their own mechanisms or have > used > > > > vendor specific mechanisms to transfer configuration data to and > from > > > > a device and to examine device state information which may impact > the > > > > configuration. Each of these mechanisms may be different in >various > > > > aspects, such as session establishment, user authentication, > > > > configuration data exchange, and error responses. > > > > > > > > The NETCONF protocol (RFC 6241) provides mechanisms to install, > > > > manipulate, and delete the configuration of network devices. >NETCONF > > > > is based on the secure transport (SSH is mandatory to implement > while > > > > TLS is an optional transport). The NETCONF protocol is data >modeling > > > > language independent, but YANG (RFC 7950) is the recommended >NETCONF > > > > modeling language, which introduces advanced language features for > > > > configuration management. > > > > > > > > NETCONF WG recently finalized the development of RESTCONF protocol > > > > (RFC 8040) which provides an interface over HTTPs for accessing >data > > > > defined in YANG. RESTCONF is based on the capabilities and uses >the > > > > datastore concept defined in the NETCONF protocol specification. >In > > > > support of RESTCONF the YANG-Patch (RFC 8072) mechanism has been > > > > provided for applying patches to configuration datastores. The >YANG > > > > Module Library (RFC 7895) provides information about all YANG > modules > > > > used by a network management server. > > > > > > > > Last but not least NETCONF and RESTCONF Call Home (RFC 8071) have > been > > > > developed, which enable a server to initiate a secure connection >to > a > > > > NETCONF or RESTCONF client respectively. > > > > > > > > In the current phase of NETCONF's incremental development the > > > > workgroup will focus on following items: > > > > > > > > 1. Finalize the YANG data module for a system-level keystore > mechanism, > > > > that can be used to hold onto asymmetric private keys and > certificates > > > > that are trusted by the system advertising support for this >module. > > > > Based on the known dependencies this draft has the highest >priority > > > > for the WG. > > > > > > > > 2. Finalize Server and Client Configuration YANG modules for both > > > > NETCONF and RESTCONF as well as the Client and Server Models for >SSH > > > > and TLS. > > > > > > > > 3. Finalize the Zero-touch provisioning for NETCONF or > RESTCONF-based > > > > Management as a technique to establish a secure network management > > > > relationship between a newly delivered network device configured > with > > > > just its factory default settings, and the Network Management > System) > > > > > > > > 4. Provide a revised version of RFC 6536 (NETCONF Access Control > > > > Model) by adding support for RESTCONF and the YANG 1.1. constructs > > > > like "action" and the "notification" statements. > > > > > > > > 5. Provide a set of documents enabling advanced notification/ > > > > subscription capabilities, which gracefully co-exist in a >deployment > > > > of RFC 5277. The new capabilities include e.g. transport > independence, > > > > multiple dynamic and configured subscriptions in a transport > > > > session. RFC 5277 will be obsoleted in parallel to the publication > of > > > > the new document set. Following specifications will be addressed: > > > > - Protocol-neutral notification framework, i.e., explaining the > > > > concepts of subscriptions, filters, subscription state > > > > notifications, replay, etc. and defining the associated YANG >data > > > > model, RPCs, etc. > > > > - Definition of notifications sent over NETCONF and how YANG > > > > notifications are encoded in XML and JSON. Include >considerations > > > > for parallel support / implementation compatibility with > RFC-5277. > > > > - Definition of notifications sent over RESTCONF and HTTP2 and >how > > > > YANG notifications are encoded in XML and JSON. Include >specifics > > > > of call-home and heartbeat for subscriptions. > > > > - The subscription and push mechanism for YANG datastores >allowing > > > > subscriber applications to request updates from a YANG >datastore. > > > > > > > > 6. Provide a revision for the NETCONF and RESTCONF protocols and >the > > > > used datastore framework building on the datastore concept in >NETMOD > > > > revised datastores work. Bug fixing will be done and potential > > > > extensions will be added. Provide guidance on how to adapt and use > > > > YANG with NETCONF and RESCONF protocols. NETCONF XML Encoding >Rules > > > > from RFC 7950 will be moved to RFC6241bis. > > > > > > > > 7. Define capabilities for NETCONF and RESTCONF to support I2RS > protocol > > > > and ephemeral state datastore requirements. > > > > > > > > Based on the implementation, deployment experience and inter- > > > > operability testing, the WG aims to produce a NETCONF status >report > > > > in a later stage. The result may be clarifications for RFC6241 and > > > > RFC6242 and addressing any reported errata. > > > > > > > > > > > > Goals and Milestones: > > > > Done Submit NETCONF/RESTCONF Call Home to AD/IESG for > consideration as > > Proposed Standard > > > > Done Submit YANG Library to AD/IESG for consideration as > Proposed > > Standard > > > > Done Submit RESTCONF to AD/IESG for consideration as Proposed > Standard > > > > Done Submit YANG Patch to AD/IESG for consideration as >Proposed > > Standard > > > > > > > > May 2017 WGLC for Zero-touch configuration mechanism > > > > Jun 2017 Submit Zero-touch configuration to AD/IESG for > consideration as > > Proposed Standard > > > > May 2017 WGLC for system-level keystore mechanism > > > > Jun 2017 Submit keystore mechanism to AD/IESG for consideration >as > > Proposed Standard > > > > May 2017 WGLC for Server and Client models for NETCONF and >RESTCONF > > > > Jun 2017 Submit Server and Client Configuration models to AD/IESG > for > > consideration as Proposed Standard > > > > May 2017 WGLC for Client and Server Models for SSH and TLS > > > > Jun 2017 Submit Client and Server Models for SSH and TLS to >AD/IESG > for > > consideration as Proposed Standard > > > > Jun 2017 WGLC for RFC 6536bis (NETCONF Access Control Model) > > > > Jul 2017 Submit RFC 6536bis to AD/IESG for consideration as > Proposed > > Standard > > > > Jun 2017 WGLC for advanced Notification/Subscription >specifications > > > > Jul 2017 Submit Notification/Subscription specifications to >AD/IESG > for > > consideration as Proposed Standard > > > > > > > > > > > > From: Benoit Claise [mailto:bclaise@cisco.com] > > Sent: Friday, March 17, 2017 4:49 PM > > To: Kent Watsen ; Mehmet Ersue > ; > > 'Susan Hares' ; 'Andy Bierman' > > Cc: 'Netconf' > > > > > > > > On 3/8/2017 12:57 AM, Kent Watsen wrote: > > > > I agree with Mehmet, any changes to the NC/RC protocols should be >done > in > > the NETCONF WG. > > > > +1. > > > > Regards, Benoit > > > > > =20 > > =20 > =20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > =20 > > >_______________________________________________ >rtgwg mailing list >rtgwg@ietf.org >https://www.ietf.org/mailman/listinfo/rtgwg From nobody Tue Mar 21 08:37:21 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A99F7129B5C for ; Tue, 21 Mar 2017 08:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 tzJUrar0X4mN for ; Tue, 21 Mar 2017 08:37:13 -0700 (PDT) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::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 52FA0129B23 for ; Tue, 21 Mar 2017 08:35:02 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id l37so114514162wrc.1 for ; Tue, 21 Mar 2017 08:35:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IdtBw3ow4/iXtRqg4lJF8UGMK+bfohSCZUwXwhX5O9E=; b=DqbXCC+sNaWJB4cMVpSBohmIrfhiIDqnUZG1PMBY45a0TGmxhGc2wl582UMx66K6lO Hq8W1PZuTc3muDabz3niguvgl2CdE8S30LKcYMmOqDgjPHeBVuqtD72yatmRaUwiKanm LOC9joURp38qc+2W1DjYTAQE5Qf8CeABnkz2Q7NMuk/+Asv1mt1Hrf1MgEvWW1ie+d+r wZ95r9be752cod0e0qH9vaGXA7zGKAwaps8+lx0asZ/HaUaaRqn5FTTCWBHrr8fgASGI 0PcjJC7kcESnIxQT8bRA+hySR9g4jvZu/zFKDvdLzvHpA6EiQmPqsfmGGlWpsf+c7AEw Y9VQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IdtBw3ow4/iXtRqg4lJF8UGMK+bfohSCZUwXwhX5O9E=; b=F24/eGy8ypCxAD0PT6CIgx6AMlTVLCfs+DQbGonm9IbXz68qMnj4DVf1fFrNxtPqpr RcRACUSdkl3vcezpMOJSBm3GcAIy3zrlHVBKp5uEZBvGtSObE14+Y6JHln/oVfY6iCmj /USmkSxc78FMteMxSkqba066yX3tStOwlOq315zbxLlqMrguO2/XweU4N68s04mL4ohv wBw1iPqGs79IG8OKW7kJ7VfyzLS56J+TjB09WQlEetuaQMy4SSS4ThJmla1LOxux/kWK 7as3OgFw3EQVvcvat11DU9dAbMWDWl90ado1bHsTh2Py2ZZxN9bLQsS4LselhYGNVSys U7jQ== X-Gm-Message-State: AFeK/H0uttDQPQM+nudevfAUDu/m9qO3n2NJcfcyzjnpA+fXmoin4XzfAdm3Hq64U4onKhYT4By3hqrJU1FZdg== X-Received: by 10.223.153.225 with SMTP id y88mr30212627wrb.81.1490110500822; Tue, 21 Mar 2017 08:35:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.169.132 with HTTP; Tue, 21 Mar 2017 08:34:20 -0700 (PDT) In-Reply-To: References: From: Tony Przygienda Date: Tue, 21 Mar 2017 08:34:20 -0700 Message-ID: Subject: Re: New Document To: Sanjiv Kapoor Cc: rtgwg@ietf.org, Fab Devetak Content-Type: multipart/alternative; boundary=f403045d616013e5c6054b3f63c9 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 15:37:16 -0000 --f403045d616013e5c6054b3f63c9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable welcome, IME this still largely holds (as Acee uses to describe those things "oldie but goodie" ;-) http://zoo.cs.yale.edu/classes/cs433/cs433-2013-fall/readings/arpanet_routi= ng.pdf On Tue, Mar 21, 2017 at 7:12 AM, Sanjiv Kapoor wrote: > As Jeff suggested, I am inviting discussion on > Re: https://www.ietf.org/internet-drafts/draft-kapoor-rtgwg- > dynamic-multipath-routing-00.txt > > This document introduces a method for simultaneous routing and congestion > control across multi-path flows. The basic methods for change of flow is = an > additive increase and multiplicative decrease on congestion (like TCP). > Extra flow requirements and congestion is dealt with by finding addition= al > (shortest ) paths using the queue length as a measure for congestion at t= he > links. This requires knowledge of the link state. > > There are two methods described, the second method achieves fair > distribution of traffic flow by using a concurrency parameter, Gamma, whi= ch > alters the cost of paths being used by a particular source destination > traffic flow. > > These methods have been simulated (by Fab) using NS3 and results may be > found on > > http://www.cs.iit.edu/~kapoor/papers/reducerate.pdf > > > On Wed, Mar 15, 2017 at 4:18 PM, Sanjiv Kapoor wrote: > >> A new Internet Draft >> >> https://www.ietf.org/internet-drafts/draft-kapoor-rtgwg- >> dynamic-multipath-routing-00.txt >> >> has been posted. >> >> Please send us comments. >> >> Thanks >> >> Sanjiv Kapoor >> > > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > > --=20 *We=E2=80=99ve heard that a million monkeys at a million keyboards could pr= oduce the complete works of Shakespeare; now, thanks to the Internet, we know that is not true.* =E2=80=94Robert Wilensky --f403045d616013e5c6054b3f63c9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
welcome, IME this still largely holds =C2=A0(as Acee uses = to describe those things "oldie but goodie" ;-)

http://zoo.cs.yale.edu/classes/cs433/cs433-2013-fall/r= eadings/arpanet_routing.pdf



On Tue, Mar 21,= 2017 at 7:12 AM, Sanjiv Kapoor <kapoor@iit.edu> wrote:
As Jeff suggested, I am in= viting =C2=A0discussion on
Re:=C2=A0https://www.ietf.or= g/internet-drafts/draft-kapoor-rtgwg-dynamic-multipath-routing-00.txt

=
This document introduces a method for simultaneous routing and congest= ion control across multi-path flows. The basic methods for change of flow i= s an additive increase and multiplicative decrease on congestion (like TCP)= . Extra flow requirements and =C2=A0congestion is dealt with by finding add= itional (shortest ) paths using the queue length as a measure for congestio= n at the links. This requires knowledge of the link state.=C2=A0
=
There are two methods described, the second method achieves = fair distribution of traffic flow by using a concurrency parameter, Gamma, = which alters the cost of paths being used by a particular source destinatio= n traffic flow.

These methods =C2=A0have been simu= lated (by Fab) using =C2=A0NS3 and results may be found on=C2=A0
=


On Wed, Mar 15= , 2017 at 4:18 PM, Sanjiv Kapoor <kapoor@iit.edu> wrote:
A new =C2=A0Internet Draft
=C2=A0=C2=A0=C2=A0<= a href=3D"https://www.ietf.org/internet-drafts/draft-kapoor-rtgwg-dynamic-m= ultipath-routing-00.txt" rel=3D"noreferrer" style=3D"font-size:12.8px" targ= et=3D"_blank">https://www.ietf.org/internet-drafts/draft-kapoor-rtgwg-<= wbr>dynamic-multipath-routing-00.txt

= has been posted.

Please send us comments.

Thanks

Sanjiv Kapoor
=


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




--
=
We=E2=80=99ve heard that a million monkeys at a million keyboards c= ould produce the complete works of Shakespeare; now, thanks to the Internet= , we know that is not true.
= =E2=80=94Robert Wilensky
--f403045d616013e5c6054b3f63c9-- From nobody Tue Mar 21 08:46:51 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 382B2129B10 for ; Tue, 21 Mar 2017 08:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iit-edu.20150623.gappssmtp.com 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 ZMNeZRYhbDSg for ; Tue, 21 Mar 2017 08:46:48 -0700 (PDT) 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 A533A129B9C for ; Tue, 21 Mar 2017 08:44:38 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id d188so98233329vka.0 for ; Tue, 21 Mar 2017 08:44:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iit-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YHUL03dW0uhrspA39cRVvR9dCvmuJARc3lJGeZ5Fr/8=; b=QFJ4BHHz/+W4leWaxSxRHZbtQXngRf3CzaJ1HOQ4F0F5WhdJGDRNeYy0DA7DKws1QM v1RIEb9T1HbDIwoO3eAeIVDWWbvzFhw1EH98LdzcVwI2qq3EOLjRm76C/0hFAtE2kcL4 8G6VOuJdhhQQ/UrxvFM3xkFOzjokZ0kQ6gdP9yKPCRheRFQwkDdm1hcLA+tuConKsZSd Y19BMl32goi3IPdgOBA6csAEk20C1tWo6JHRCrgMOedTScSAVGKP0rKDXBLjjALEeRNb uKgiOdb9kJz27bemrJAVdu9jhS5TiTDnGqgOJk7+XgzHTD7VWzp/kz8pPA19BHY8VKBV EQpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YHUL03dW0uhrspA39cRVvR9dCvmuJARc3lJGeZ5Fr/8=; b=Sn3lpOyGn7dIxTvvXvjdjugGZ6mhI1fqJ/FNt3Y0+eHB4WWwojjT8pLEJgCdn1uNkR q3dGWGviKieAuAow9ATgyV3Mx0KfSVcpwtcB6OaVZOh+7JgggQIR9l8BNARsIIx80C1e CRnMAsjka41W94d4o5RE1e1wZfwg8dsF+VUaf06P0pRMv4o4/U+/mpQXjMLxWIIav5cj Z/I/pXkQs5Bt/fD1Qj3J00jQE8EqVVAqBfeDgDJrVoRHxyci/qjVw7MBXMcsnzVx1yMl jyCpfc3vBv/YPZmwk5sxgQq+J5/OH3a5PSPDR16kRUN4AJuUDrZ4nQNJJ+3HWgFR4LvB 4ANQ== X-Gm-Message-State: AFeK/H2sHGC6Mn6Zn5JTkm7coryaieJUlMPfMRiyoxZ7qFljcOgyCZYe3ZL9JZBuUkn9zSwFMrXYA3IC18Q3zm4Y X-Received: by 10.31.3.203 with SMTP id f72mr14460821vki.108.1490111077693; Tue, 21 Mar 2017 08:44:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.90.9 with HTTP; Tue, 21 Mar 2017 08:44:07 -0700 (PDT) In-Reply-To: References: From: Sanjiv Kapoor Date: Tue, 21 Mar 2017 10:44:07 -0500 Message-ID: Subject: Re: New Document To: Tony Przygienda Cc: rtgwg@ietf.org, Fab Devetak Content-Type: multipart/alternative; boundary=001a114280b07658c8054b3f853a Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 15:46:50 -0000 --001a114280b07658c8054b3f853a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for the link. (At least) One key difference to note is that we utilize multiple paths to increase throughput. On Tue, Mar 21, 2017 at 10:34 AM, Tony Przygienda wrote: > welcome, IME this still largely holds (as Acee uses to describe those > things "oldie but goodie" ;-) > > http://zoo.cs.yale.edu/classes/cs433/cs433-2013-fall/ > readings/arpanet_routing.pdf > > > > On Tue, Mar 21, 2017 at 7:12 AM, Sanjiv Kapoor wrote: > >> As Jeff suggested, I am inviting discussion on >> Re: https://www.ietf.org/internet-drafts/draft-kapoor-rtgwg- >> dynamic-multipath-routing-00.txt >> >> This document introduces a method for simultaneous routing and congestio= n >> control across multi-path flows. The basic methods for change of flow is= an >> additive increase and multiplicative decrease on congestion (like TCP). >> Extra flow requirements and congestion is dealt with by finding additio= nal >> (shortest ) paths using the queue length as a measure for congestion at = the >> links. This requires knowledge of the link state. >> >> There are two methods described, the second method achieves fair >> distribution of traffic flow by using a concurrency parameter, Gamma, wh= ich >> alters the cost of paths being used by a particular source destination >> traffic flow. >> >> These methods have been simulated (by Fab) using NS3 and results may b= e >> found on >> >> http://www.cs.iit.edu/~kapoor/papers/reducerate.pdf >> >> >> On Wed, Mar 15, 2017 at 4:18 PM, Sanjiv Kapoor wrote: >> >>> A new Internet Draft >>> >>> https://www.ietf.org/internet-drafts/draft-kapoor-rtgwg-d >>> ynamic-multipath-routing-00.txt >>> >>> has been posted. >>> >>> Please send us comments. >>> >>> Thanks >>> >>> Sanjiv Kapoor >>> >> >> >> _______________________________________________ >> rtgwg mailing list >> rtgwg@ietf.org >> https://www.ietf.org/mailman/listinfo/rtgwg >> >> > > > -- > *We=E2=80=99ve heard that a million monkeys at a million keyboards could = produce > the complete works of Shakespeare; now, thanks to the Internet, we know > that is not true.* > =E2=80=94Robert Wilensky > --001a114280b07658c8054b3f853a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the link.

(At least) One key =C2= =A0difference to note is that we utilize multiple paths to increase through= put.=C2=A0

On Tue, Mar 21, 2017 at 10:34 AM, Tony Przygienda <tonysietf@= gmail.com> wrote:
welcome, IME this still largely holds =C2=A0(as Acee uses to descr= ibe those things "oldie but goodie" ;-)




On Tue, Mar 21, 2017 at 7:12 AM, Sanjiv Kapoor = <k= apoor@iit.edu> wrote:
As Jeff suggested, I am= inviting =C2=A0discussion on
Re:=C2=A0https://www.ie= tf.org/internet-drafts/draft-kapoor-rtgwg-dynamic-multipath-routing-00.= txt

This document introduces a method for simul= taneous routing and congestion control across multi-path flows. The basic m= ethods for change of flow is an additive increase and multiplicative decrea= se on congestion (like TCP). Extra flow requirements and =C2=A0congestion i= s dealt with by finding additional (shortest ) paths using the queue length= as a measure for congestion at the links. This requires knowledge of the l= ink state.=C2=A0

There are two methods described, = the second method achieves fair distribution of traffic flow by using a con= currency parameter, Gamma, which alters the cost of paths being used by a p= articular source destination traffic flow.

These m= ethods =C2=A0have been simulated (by Fab) using =C2=A0NS3 and results may b= e found on=C2=A0


<= div class=3D"gmail_extra">
On Wed, Mar 15, 20= 17 at 4:18 PM, Sanjiv Kapoor <kapoor@iit.edu> wrote:
A new =C2=A0Internet Draft
=

has been posted.

Please send u= s comments.

Thanks

Sanjiv Kapoor


__________________________________________= _____
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg


<= br clear=3D"all">

--
<= span style=3D"font-size:12.8000001907349px"><= i>We=E2=80=99ve heard that a million monkeys at a million keyboards could p= roduce the complete works of Shakespeare; now, thanks to the Internet, we k= now that is not true.
=E2=80=94Robert Wilensky
<= /div>

--001a114280b07658c8054b3f853a-- From nobody Wed Mar 22 01:38:55 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF27F129645; Wed, 22 Mar 2017 01:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 AfDLJTfkN72q; Wed, 22 Mar 2017 01:38:51 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::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 E248A126C3D; Wed, 22 Mar 2017 01:38:49 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id y90so8003506wrb.0; Wed, 22 Mar 2017 01:38:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :mime-version; bh=TDnFQDAGJt6tWdpQy64CAIyCQvTNC2yXk0Xx1nDPtdQ=; b=P0IM3hhjSYcepJk0KZcxM+V2+bICfJpn9rf67ZHwL2ery2bn0OZlSHfJ6RSgfAmPyZ ggI5ObxaSH21Vx/NYxZ8R7H2FEYhPW4OUS/UdAE+mBUOJZMdX7z9dXUtV2dKSxXLL4ig hfCmQIuzJ44FPYzY8CgVgyE99bVPCOFawIwJ0Sbvsz97ztrgP5VJl0piA/1ETegYGIAX AGJ5jgZzSDZ6I0Sa5s5ey53hZeUexT4yb+sgzQ2AsSzSRS7zmQrAFAKch9H5yvtpb4I4 jXdE/GgA/p783xD0eOmZ4rj96+Bts2ErkqDZ2LngtBs9NbT8/CyOG4JWFBeVrwjt2w2B FsFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:mime-version; bh=TDnFQDAGJt6tWdpQy64CAIyCQvTNC2yXk0Xx1nDPtdQ=; b=fSxpbhiJcm3z6Gvvj3nk9I96y/855GWZepfmJrBII9p2Dw/K7MPuYinKdPverFhg7s Ap5uaCyr/CI2PIgGRT3Phe3PFNdcP7l15KCFCHyUFnAvs3UISviY7GUPlVLMVa8iLOIP Jfr+7Kd6ILGIj+zgAXIUpdPGYf17tIuV++rtK0qK3nSF9fzeJPbFVrtcbigsVaIiDMx/ ByExqaNpPET355Qf+PVmtuzizNPhFuVxS9zaTviVYtv25rI65uqPCiP7DS/3FyuAX9yt 1/XnfOFxxnEgqf+HWqBv+h9/KMzn9vbKh38GUl6sxMEFPlSFYkJAJy6slfaesdAhqkJT hUdA== X-Gm-Message-State: AFeK/H0/Vny7EC2mJW7r/dQDSzMChru7xntsH5OavimP0SZAqXkDj76flQGJZ7ontSRQ6w== X-Received: by 10.223.160.115 with SMTP id l48mr37565195wrl.24.1490171928181; Wed, 22 Mar 2017 01:38:48 -0700 (PDT) Received: from [172.20.7.250] ([46.218.58.213]) by smtp.gmail.com with ESMTPSA id t63sm20656217wme.16.2017.03.22.01.38.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Mar 2017 01:38:47 -0700 (PDT) User-Agent: Microsoft-MacOutlook/f.20.0.170309 Date: Wed, 22 Mar 2017 01:38:46 -0700 Subject: Re: RTGWG presentation slot requests for Chicago - final agenda published From: Jeff Tantsura To: RTGWG CC: rtgwg-chairs Message-ID: <20550B79-04D7-42AA-8986-A6E7FB244C00@gmail.com> Thread-Topic: RTGWG presentation slot requests for Chicago - final agenda published Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3572991527_1705939273" Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 08:38:54 -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_3572991527_1705939273 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Dear RTGWG, =20 The final agenda has been posted at https://datatracker.ietf.org/doc/agenda= -98-rtgwg =20 If you requested agenda time and don't see yourself there, or if you need t= o make a correction, please let the chairs know. Please make sure you send us the slides on time! =20 We are still looking for volunteers to take notes and jabber. =20 See you in Chicago, Jeff and Chris=20 ---------------------------------------------------------------------------= ----------------------------------------------------------------------------= ------------------------------ =20 Dear RTGWG, =20 It's that time again! The preliminary agenda for IETF 98 has been published; you can find it at h= ttps://datatracker.ietf.org/meeting/98/agenda.html. =20 RTGWG will be meeting: 09:00 - 11:30 on Wednesday, March 29 in Vevey 1/2 an= d 15:20-17:20 on Thursday, March 30 in Zurich E/F. If you'd like a slot to present a draft, please send a request to Chris and= I by Friday March 17th.=20 Please note the dates below, in particular, the deadline for draft submissi= on is UTC 23:59 March 13th. We kindly request to provide your presentations by Wednesday, March 22nd. =20 As always =E2=80=93 we would appreciate your help in taking notes and jabber, ple= ase do volunteer! =20 Looking forward to seeing you in all Chicago! =20 Cheers, Jeff and Chris =20 =20 --B_3572991527_1705939273 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Dear RTGWG,

 

The final agenda has been posted at https://datatracker.ietf.org/doc/agenda-98-rt= gwg

 

If you requested agenda time and don't see yourself there, or if you ne= ed to make a correction, please let the chairs know.

Please make sure you send us= the slides on time!

 

We are still looking for volunteers to take notes and jabb= er.

<= o:p> 

See you in Chicago,

Jeff and Chris 

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

 

Dear RTGWG,

 

<= span style=3D'font-size:11.0pt'>It's that time again!

The preliminary agenda for IE= TF 98 has been published; you can find it at https://datatracker.ietf.org/meeting/98/agend= a.html.

 

RTGWG will be meeting: 09:00 - 11:30 on Wednesday, March 29 in Veve= y 1/2 and 15:20-17:20 on Thursday, March 30 in Zurich E/F.=

If you'd like a slot t= o present a draft, please send a request to Chris and I by Friday March 17th= .

Pl= ease note the dates below, in particular, the deadline for draft submission = is UTC 23:59 March 13th.

We kindly request to provide your presentations by Wedne= sday, March 22nd.

 

As always – we would appreciate your help in taking not= es and jabber, please do volunteer!

=  

Looking forward to seeing you in all Chicag= o!

&n= bsp;

= Cheers,

Jeff and Chris

 

 

--B_3572991527_1705939273-- From nobody Fri Mar 24 03:52:39 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE34E12957B; Fri, 24 Mar 2017 03:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.588 X-Spam-Level: X-Spam-Status: No, score=-4.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=btconnect.onmicrosoft.com 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 sdK4nlnb-E-l; Fri, 24 Mar 2017 03:52:35 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00097.outbound.protection.outlook.com [40.107.0.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CC1312940A; Fri, 24 Mar 2017 03:52:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fxlNeplFg/ii9brAgiOEX3B3VqleO9lbDPz7v0LetF8=; b=ZG4XafiHA83EoQQMyKFn5HEFLNFaKLLZzMrgvuRex+IUIiyowsogArhMt7UE2KKyOk/48ap32lnKdKDEbbvyoBgQdEX5rfGjiZss//2djGrdRXuwxUZPtGjhwqn1vxPca8H+7RdqwJZvTedYEYT/3F//tLZ2315f10gqfS+t3Lc= Authentication-Results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.185.203.75) by VI1PR0701MB2766.eurprd07.prod.outlook.com (10.173.81.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.2; Fri, 24 Mar 2017 10:52:31 +0000 Message-ID: <02d601d2a48c$82a82500$4001a8c0@gateway.2wire.net> From: t.petch To: "Acee Lindem (acee)" , Kent Watsen , CC: References: <005101d2975f$ae87ac20$0b970460$@ndzh.com> <017d01d29769$0df70b20$29e52160$@gmail.com> <010701d29771$a45f66e0$ed1e34a0$@ndzh.com> <026601d2977f$8d059600$a710c200$@gmail.com> <685B9088-7557-4C6E-9A8F-54C3208DB312@juniper.net> <7217bc23-0e1e-c250-929d-e18c3f0a800f@cisco.com> <07b601d2a197$9865d5b0$c9318110$@gmail.com> <02ee01d2a22b$295b2be0$4001a8c0@gateway.2wire.net> <20170321174358.GA36769@elstar.local> <65E2B5E1-A1D0-45C1-94E8-F10A35042295@juniper.net> <4A73C3C3-61F3-4988-B163-264B29EE1BA0@juniper.net> <445D4A52-0EC8-4AAD-ABC4-22CAC3B3169A@juniper.net> <03a101d2a3fd$35353ae0$4001a8c0@gateway.2wire.net> Subject: draft-ietf-rtgwg-yang-key-chain was: Re: [Netconf] Draft Charter Proposal for NETCONF WG Date: Fri, 24 Mar 2017 10:24:16 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.185.203.75] X-ClientProxiedBy: DB6P18901CA0004.EURP189.PROD.OUTLOOK.COM (10.169.208.142) To VI1PR0701MB2766.eurprd07.prod.outlook.com (10.173.81.138) X-MS-Office365-Filtering-Correlation-Id: 28b465c8-dd7d-468a-7f9c-08d472a3df95 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:VI1PR0701MB2766; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB2766; 3:Ro3pJNKhSMMnjXJWj7fBiMXK/VxAA4tSwER9g2tljxGJnwubcrl8Eul3ocnDBRHDaHn3X+eqmQH9xBsOUXGLSpUiOmkuomJsmR6dHOlXa/qOiEPnkDRT6i/g5j808IrcNTwVNKjyGLRZD4f5YCZLDtN3Q+COzlDeuruArAqVTdv0a0J45ycs43RNJXeMWiEq+vk2MKb2TPkZM9tzEGnIj4jXadxDtWTvF0Y1GXv3Cs1gJnaVBoiWQiIHovE5Cq+LF4iLTzBYT7tPCTU6T+quew==; 25:beZByTiUaMAzmcKu91bWDsUQzYBgUzRwpoeS2d/9muPD4DsKMOBShJhCa6X1h32Bk7o7Q1wRKVaO6sq68FPgPH12Rtpjd/oyS5FX2Ftwtck+JwlaXOvCWIwGG0f6PiRoy7Ti5i6WEoUt2+xSigKWfPZFGtbDBjhXTneH4vT93wWjWQ5J+Nxx7tQqYpZSBJQtnVbgOA5l3uJmgoX72bipXjmbbFrZQOav8P7fwv14/2ALkABjipMCPEtS6KEPtP271obRYScpiJCcdH7UySNNTiX/zXcBhbjTV4AMVzJn5ENFUhCS2gZjl+koJ1qPqr1R40/gq9rvsCmA4CqEUdwwFaKYehu997EtXrHh+Swm5knRPdcv1VLUfnkbemjgNV5ZQftr4Guvzg/sE+We4BHogSigHtWTR1Pxy+kdwiva3bIJ9heokutVmk0eRp3izlcFvu02H942uQFKgIsk51znHA== X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB2766; 31:YfBiocGi35u5o8omCC+VGY13A/s4JZWM2zIG4JVzJrHDqUSCMrnQQ7yAWG9z6nTHKHeGJ1S/XTmdVULhivQp+Scwp1SDj68n44R+oAur/H4beWGsSP+PccNsLN5AYdTbH0oGQdUM0FqYilbSoC7tRq8mrTfto6ACJT2pRMKzWUDm10/3XCTnK/VWZKvBvXaN0h5RPgo8eMEvGb53Udg0T+NsZCYz6lEu3cCIvNtAvwvLiFgYVdT7225phg8AAhLl2H7PsoD8Tq53svjK40waIZoxobx4r3tMNO4nJxT43/w= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278428928389397)(192374486261705)(131327999870524)(138986009662008)(95692535739014); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123564025)(20161123558025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:VI1PR0701MB2766; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2766; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB2766; 4:qKKOI74fDElb7oEeS0V1NA/DTc8YLNJTYm/8exZQp0XAlfoeHLIZiYOBwEurfxx9uP7vtdUju7WJRfnCeunjRqVTOM/Yy3PVcyeeDuJRWY+Pu3f4OYYwMJle20gJDT4u+OUHQKoKvPRd8yJn8sfJkgvXF4Dmt1ENAjM5xgRKgmqrRLCP9bk/QLcG5YCEZJJkhkUVCOHpY8TmFX8ylOoC0Nr6T/ml2W52Rs1g+2l97rxDwn9CvvsrmDdkmTzNuBvhLzlSeRSNr6pCBTztOZg8nHUG20HTHFc5gSca8H0g9a62IMdJqp589tNRq81JZPUWs+W4VYEdhIZ+6gEbMxguahaMd55U3p8dws9ukk/AzYbNtIqYTQvyXbFWhJAPA1JAz1m+bx0o8dlm1IcWqjCyq9v9GE85Nx05ehfLgXpPZnYF4r3KfY4nlwan3kUEWYziqRg9pWW+qrd9LFRrq9/lVEGV9V+UrxIq84q8jF37gkfa/F85Vpo0Pgf8Pb/JncSqTYNNSL3dEijo1dQF+1607lrVh5Sqz3cbOv911q8InNMjA5MdmpztmArTEMxQR3/IsrflmU89GcQlxHtuEBInOCP6649eDvEzPezw4rMSz20hePWbQWS9FZ0qg/g1cOjNHz303TDzZarI8H5FwGcTQ8cvh38bQJ9gPjjWSr12ccBFOeBp2dbZFa733rd2PCLvGaXpb+at34BeHLLzQqVPMCvnDs4WYaI3hz62RL5bN7bDPuu8QARVXmwfOWqBW0A6+/0TMPM5pI5oCaQ+lSpp2VUu7Ce7uwsEN7enwtACpxo= X-Forefront-PRVS: 0256C18696 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(39840400002)(39450400003)(39850400002)(39410400002)(39860400002)(377454003)(24454002)(13464003)(8676002)(1456003)(551544002)(6486002)(230783001)(53546009)(8666007)(189998001)(50226002)(4326008)(42186005)(6496005)(116806002)(62236002)(44716002)(81166006)(66066001)(5890100001)(9686003)(1556002)(33646002)(53936002)(86362001)(47776003)(6666003)(14496001)(1941001)(44736005)(93886004)(23756003)(76176999)(81816999)(38730400002)(6116002)(305945005)(81686999)(3846002)(50986999)(2906002)(50466002)(4720700003)(2870700001)(84392002)(25786009)(5660300001)(7736002)(61296003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB2766; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; VI1PR0701MB2766; 23:LJQquy1varbMjQYQm5Z4LH1mrsfTYUXdCbFoV?= =?iso-8859-1?Q?HhsjeC5oPn55JvvMvRiVTf9yb8gET9EIFdk/ftulC6W+YbUqfGMymllrPF?= =?iso-8859-1?Q?MsdUe3mPqVzX6qq4kVk/rdZb6a3UwQ9pcWER2oSXYJovL3+N5hm55uM3nk?= =?iso-8859-1?Q?PY5LcEZlyVMiR2XoYmaun0dqeD86LnVYdaJIWoj3ZrCNHFT0px3SavDYYz?= =?iso-8859-1?Q?I+JmkQA1a/IdtDUxyybiejeXGVHFaSTiZTkK9/69X3+zJ70ByMlChdIjCo?= =?iso-8859-1?Q?+UbiGPkY/43dPY67XIPdMtSIo2oZ8F7KZkQU80d6EQAsYWsFTJ5e05n2y5?= =?iso-8859-1?Q?6MDKDL8l5LDVqiggiz6aVMYPBQEbnpWm9qJhdB4i23khBNWHHF5ErhMseO?= =?iso-8859-1?Q?xsZrDlvK7Ny16j8NAYTaOpdfmba9vBXDaAK1MHtjn5jIlcKq93TKoAcN7/?= =?iso-8859-1?Q?lGEi8ROfeEuvXE8mXuzh+JOcBuXfn6SnfzzGYvEPPXmr6Y9TIfNqCJus9R?= =?iso-8859-1?Q?JVtGLmOqXddwWs8aKYQF/UlzRgpqtvrbr7BW1yfwgP1Dceh4Mb+dTry6hE?= =?iso-8859-1?Q?WxnyIvhHLTOaCO35qZ6EoUhDUsYbvoyp5OnANVWSvOwUXmdpe1+v7LjixH?= =?iso-8859-1?Q?/i8reAdEuz8tWqXmBELItT2Jf/2HzHYuYK26k3ZAN290ZrNyUvUfDpIAhY?= =?iso-8859-1?Q?bBloAOq8RQ2brcImCqLfZwaIRP8ab8DscToszMDpR9345JhCWMobjkwjX8?= =?iso-8859-1?Q?/PDzFTuSDu+MXDhz/MNkv1lI65bSacRuB8uUM3MTjO+gV46CKP6JAdpUtv?= =?iso-8859-1?Q?ioR1xCt+EiTovYPE6DmOJneOKV2n3rArVOGhi0tHKg5+Za8fMs0wb6+YRe?= =?iso-8859-1?Q?EYOzMgvVwFtM1Pf+is+KMqmLtvkowYvcd+7oS/UQMLvCUWusC+1cpzLPql?= =?iso-8859-1?Q?Np/wB2OpFAiw1aAKGePUKITGAGTot8IsoWeRMO/sy7RbDYkTKjqwsFH3mz?= =?iso-8859-1?Q?gozifnbgy8hN9SkfLdn/o9kixL5lClmJtCHwdNQGCB6Fd5FPPud3p4qjXg?= =?iso-8859-1?Q?LhAjKxWRGADuN+4qRf1T6cUzlOn7U7tDCYzrkPXEtpdYIQU5r8FndEu84D?= =?iso-8859-1?Q?ORkvsextJ10QpKmjeDhAJKnsz8ZW+67ki1IATylIio3s6vsexugrOxkghW?= =?iso-8859-1?Q?hmUI92SuElaVrrySwgQ2V8JB/QjZgUs1ihsYFW1sVK8ddXuvBYqeaD/sSB?= =?iso-8859-1?Q?ROGSw3UybT3gK+zuUaUWtlrh3qtfc4j9LtM+s0nT0jEHKQhyaz63k7S7gD?= =?iso-8859-1?Q?NvPlD0+gyDwBUhlh9mEaDPRY2I1L3Hy8DWSJ1BijdjuUte9Vl0Yfc5ysJh?= =?iso-8859-1?Q?12EGdqrTK5xZgbkdZlKoD7DAwImemm9RlZtxXr1IewxupDxJLy28m8MlUS?= =?iso-8859-1?Q?RMJTR4V8leucoSUgDLzUW0Ivd6RAfyrGwEvMWsGiIMO5Dsd3VSNxmB4fN9?= =?iso-8859-1?B?dz09?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB2766; 6:2b1AEyh2DRTmrs3b58fZwR/Cf+Jl29/xRXv//OpL6AeyyzOMebgX0JxdCFc0EHdTABPYnpKn++EFsc6fhcA+xsItxgRabXMQJq/iJxAnU6ZRQ1B7no7Ie3/8iWNup+cgFIkcTvGipL9IrmtEBlqGM8UpaceFh1WJnHubrpw1Tff0DMulN1pwnxXoKDiebxtHCpFRhRt1fSQLkQ6Je+31fm50x+5kh/J5pcf+9eJR849yqQXgSPhm1I2rJlADdInDzzl8rD74NXgDOVhuhXVrnn3+gICTd6f/gjYysPTclQz9T0vMyjRMZz2fwvOqn9rE7/09DJvQ0RhdTkIu8QCMYSJL9UpEuN3Rty7ev+ASNRhG0JTMeBlbsGZlb/IZNtW3yh52AZdGNPkSRGNfBkcrzg==; 5:iTJSialYDrNrzppB+ZgqHkWN2gIOfRp1NLsVvBKfcUQHdoiIDTi14Wsy+XCz32xvM2DI5bhV8EdOuw8xl2Jp2Zupul0XqgPkndMfrxltxHylcjlRSKomt/plgn3xZIw39+uB7wZPCZPEvF60VzG15A==; 24:Y3Syhfx7tUk1zIaqlLvuLgg55ikWWo7ExTTRau7Ch5YzjNEpMw5KAFpKvXjTTSUoc//ROWW4pkKpNt95Fv8q00odjQ5qkmNr2dODPxlN6w0= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB2766; 7:/E3KT4Q9EpOhy1NK14BuaUblBu0sVEQg4Vs/sh3YO1LCh/Uks/9Aazhtr5KWMsJeo144IHt1CX1cE1uGXKHpcTq45wn4JJXhroV1jJR8gK9lr+S9qeT7p7PiEZdqbk9XrrD4o3ctSs4MvsqXOyArJEacfs7dhnHWwqCUAJhXlYqwi50MVHcvwgzIhyeip+7pTufeD/IAIQJKEUSk+LvrDAEOESAvYrtUFR1HcM/byd0d8PGVuHm2M4pUKtsgDHeKTyAjKtWgkant495NgRXM6WFNl3FsAL6SAp3rHXbHjtkR1u2E38XCpyBI6DrPkP2ifokJQSWRyg9yuo/etiPQ4Q== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Mar 2017 10:52:31.6359 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2766 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 10:52:38 -0000 Acee Changing the title and switching to rtgwg! and inserting after Tom Petch ----- Original Message ----- From: "Acee Lindem (acee)" Sent: Thursday, March 23, 2017 9:01 PM Hi Kent, Tom, et al, On 3/23/17, 4:40 PM, "Kent Watsen" wrote: >Hi Tom, > >> Sorry about mixing up keystore and keychain - I did download the >> updated draft last week but failed to find it when I was drafting >> my post. However, while I know the English semantics of store and >> chain, I do find it more difficult to attach different semantics >> to keystore and key-chain, and I do find the Abstracts of the two >> I-Ds rather similar which leaves me uncertain about the scope of >> the work in Netconf. > >understood. > >> When the proposed charter says >> " 1. Finalize the YANG data module for a system-level keystore >> mechanism, that can be used to hold onto asymmetric private >> keys and certificates that are trusted by the system >> advertising support for this module." >> >> I am still uncertain. > >understood. > >> You are saying symmetric keys may come in future but should this >> be part of the charter now? I am divided on this. > >I'm also divided on it, but it is the case that we had passwords >(read "symmetric keys") I wouldn¹t equate a password with a symmetric key. >in the previous version of the keystore >draft and, the reason that they're not there now is because we >moved the passwords to the ietf-ssh-client module in the current >version of the draft...a decision that I consider to be "under >review" and to be discussed in Chicago. > >> You are saying you are unsure about system-level but what is it >> then, not that I have ever realised what is meant by system-level >> (unless it means not just for routers, but then the Abstract of >> key-chain, for the first five sentences, sounds like a system-wide >> model with sentence six only saying it is commonly used for routing >> protocols, it does not say it is not also for system-wide use!). >> >> I would then avoid system-level, since I do not understand it:-( > >I agree, for the reasons you mentioned, hence why I've resisted >putting "system" into the draft's or the module's name. Admittedly, >the draft's abstract/intro currently say "system", which should >probably be removed. > >> "Generic keystore mechanism" perhaps. > >Perhaps, or just "keystore" with some more words around its >common uses, kind of like how Acee's key-chain draft says that >it's commonly used in routing protocols. > >> I note that the charter does say 'asymmetric' which I think needs >> saying and also adding to the I-D; and I do think that the Netconf >> I-D should recognise the existence of other I-Ds relating to the >> storage of keys, although that detail is not a matter for the >> charter. > >The draft currently says "private keys", which a veiled reference >to asymmetric keys. It certainly can say this more overtly. > >The draft used to have some words regarding the key-chain draft, >but Acee didn't think such sections were useful and so I took it >out in the most recent version. If we add something back in now, >it would be along the lines of how the key-chain module is >specialized for a narrow purpose, while the keystore module is >useful in several contexts. That would be fine. I have added ³applications using symmetric keys² to the Abstract and Introduction of the key-chain draft. While one could conceivably use key-chains for other purposes, I fully believe there are much more straight-forward ways to model keys and/or other security objects required for these usages. I don¹t see key-chains ever evolving to more than exactly as the Abstract describes them: This document describes the key chain YANG data model. A key chain is a list of elements each containing a key string, send lifetime, accept lifetime, and algorithm (authentication or encryption). By properly overlapping the send and accept lifetimes of multiple key chain elements, key strings and algorithms may be gracefully updated. By representing them in a YANG data model, key distribution can be automated. Key chains are commonly used for routing protocol authentication and other applications requiring symmetric keys. In some applications, the protocols do not use the key chain element key directly, but rather a key derivation function is used to derive a short-lived key from the key chain element key (e.g., the Master Keys used in the TCP Authentication Option(TCP-AO)). Yes, I like all key references to say either symmetric key or asymmetric key, such as 'the private key of an asymmetric key pair' a comment which I will make on the Netconf list for the Netconf I-D. For the rtgwg I-D, I would like you to reorder the Abstract to make its applicability clearer for the casual reader, to whit, NEW This document describes the key chain YANG data model. Key chains are commonly used for routing protocol authentication and other applications requiring symmetric keys. A key chain is a list of elements each containing a key string, send lifetime, accept lifetime, and algorithm (authentication or encryption). By properly overlapping the send and accept lifetimes of multiple key chain elements, key strings and algorithms may be gracefully updated. By representing them in a YANG data model, key distribution can be automated. In some applications, the protocols do not use the key chain element key directly, but rather a key derivation function is used to derive a short-lived key from the key chain element key (e.g., the Master Keys used in the TCP Authentication Option(TCP-AO)). as I have implied on the Netconf list, the current layout has me reading the first five sentences and thinking that this is an all-embracing key related model, then I get to sentence six and think, well, I am confused now. Putting that sentence about routing protocols earlier would leave me less confused. Tom Petch The only augmentations I¹d envision would be additional algorithms and potentially other key attributes. Of course, one can never fully predict the future. Thanks, Acee > > >Kent > > From nobody Fri Mar 24 05:46:42 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E59F12968A; Fri, 24 Mar 2017 05:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 EtsqavFynQpz; Fri, 24 Mar 2017 05:46:38 -0700 (PDT) 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 AD249129685; Fri, 24 Mar 2017 05:46:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9282; q=dns/txt; s=iport; t=1490359598; x=1491569198; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=BZlzhC3/Mo/WDf1RPWE50rBBpNuHLYsSCrOQnbcNDx8=; b=Xs8dG8EUCo4DC/i0Haoxn53j0756MPgiV4D/DrcXts5fxktWM3JEiTxT Rz4uLBDoBZiRM7Ue4ch97cCLFJ4nvOe3R8ZTZrEkWBS9AT6LHHI4Vz/k0 6j9lYm1W2zMS8u2sSLmuh8jQXvx8IolZgyrjrni0qRDnSTmYnKZQESaHZ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D/AwACFNVY/4UNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1SBEloHg1uKD5FOkzqCD4IOhiICGoMKPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?VAQEBAQM0RQwEAgEIFQECBBQUAgIwJQIEAQ0FigeMEJwsD4EYBoIoikEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEdgQWKOIRAFE6CMoJlAQSJF4ZJgU2LLAGSSoF8iQG?= =?us-ascii?q?GM4hXiw0BHziBBFkVGCmEWB0ZgUp1hzKBL4ENAQEB?= X-IronPort-AV: E=Sophos;i="5.36,214,1486425600"; d="scan'208";a="224368989" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Mar 2017 12:46:37 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v2OCkbbs024376 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 24 Mar 2017 12:46:37 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.1210.3; Fri, 24 Mar 2017 08:46:36 -0400 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.1210.000; Fri, 24 Mar 2017 08:46:36 -0400 From: "Acee Lindem (acee)" To: "t.petch" , Kent Watsen , "rtgwg@ietf.org" CC: "draft-ietf-rtgwg-yang-key-chain.all@ietf.org" Subject: Re: draft-ietf-rtgwg-yang-key-chain was: Re: [Netconf] Draft Charter Proposal for NETCONF WG Thread-Topic: draft-ietf-rtgwg-yang-key-chain was: Re: [Netconf] Draft Charter Proposal for NETCONF WG Thread-Index: AdKROeE3sjloti5TfEiMBOab9w67OwAgSeNTAAMyYgAABKtfAAAmUhvuAAqrwYAAXzKn3gAB6uUAAAIQ/gAAyiJeAAAC57eAAAAVAwAAAlfsAAACJWiAAAN6WAD//+pRAIAPgnqAgATDTICAASefpIAAKg0AgABUkwD//9E3gIACAQEA///Hy4CAAALPAIABiLtBgABzYwD//8LIgAAdCxrhAAP7RIA= Date: Fri, 24 Mar 2017 12:46:36 +0000 Message-ID: References: <005101d2975f$ae87ac20$0b970460$@ndzh.com> <017d01d29769$0df70b20$29e52160$@gmail.com> <010701d29771$a45f66e0$ed1e34a0$@ndzh.com> <026601d2977f$8d059600$a710c200$@gmail.com> <685B9088-7557-4C6E-9A8F-54C3208DB312@juniper.net> <7217bc23-0e1e-c250-929d-e18c3f0a800f@cisco.com> <07b601d2a197$9865d5b0$c9318110$@gmail.com> <02ee01d2a22b$295b2be0$4001a8c0@gateway.2wire.net> <20170321174358.GA36769@elstar.local> <65E2B5E1-A1D0-45C1-94E8-F10A35042295@juniper.net> <4A73C3C3-61F3-4988-B163-264B29EE1BA0@juniper.net> <445D4A52-0EC8-4AAD-ABC4-22CAC3B3169A@juniper.net> <03a101d2a3fd$35353ae0$4001a8c0@gateway.2wire.net> <02d601d2a48c$82a82500$4001a8c0@gateway.2wire.net> In-Reply-To: <02d601d2a48c$82a82500$4001a8c0@gateway.2wire.net> 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="euc-kr" Content-ID: <948CD18346CB86499F737956008548C0@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 12:46:40 -0000 SGkgVG9tLCANCg0KT24gMy8yNC8xNywgNjoyNCBBTSwgInQucGV0Y2giIDxpZXRmYUBidGNvbm5l Y3QuY29tPiB3cm90ZToNCg0KPkFjZWUNCj4NCj5DaGFuZ2luZyB0aGUgdGl0bGUgYW5kIHN3aXRj aGluZyB0byBydGd3ZyEgYW5kIGluc2VydGluZyBhZnRlciA8dHA+DQo+DQo+VG9tIFBldGNoDQo+ DQo+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPkZyb206ICJBY2VlIExpbmRlbSAoYWNl ZSkiIDxhY2VlQGNpc2NvLmNvbT4NCj5TZW50OiBUaHVyc2RheSwgTWFyY2ggMjMsIDIwMTcgOTow MSBQTQ0KPg0KPg0KPkhpIEtlbnQsIFRvbSwgZXQgYWwsDQo+DQo+T24gMy8yMy8xNywgNDo0MCBQ TSwgIktlbnQgV2F0c2VuIiA8a3dhdHNlbkBqdW5pcGVyLm5ldD4gd3JvdGU6DQo+DQo+PkhpIFRv bSwNCj4+DQo+Pj4gU29ycnkgYWJvdXQgbWl4aW5nIHVwIGtleXN0b3JlIGFuZCBrZXljaGFpbiAt IEkgZGlkIGRvd25sb2FkIHRoZQ0KPj4+IHVwZGF0ZWQgZHJhZnQgbGFzdCB3ZWVrIGJ1dCBmYWls ZWQgdG8gZmluZCBpdCB3aGVuIEkgd2FzIGRyYWZ0aW5nDQo+Pj4gbXkgcG9zdC4gSG93ZXZlciwg d2hpbGUgSSBrbm93IHRoZSBFbmdsaXNoIHNlbWFudGljcyBvZiBzdG9yZSBhbmQNCj4+PiBjaGFp biwgSSBkbyBmaW5kIGl0IG1vcmUgZGlmZmljdWx0IHRvIGF0dGFjaCBkaWZmZXJlbnQgc2VtYW50 aWNzDQo+Pj4gdG8ga2V5c3RvcmUgYW5kIGtleS1jaGFpbiwgYW5kIEkgZG8gZmluZCB0aGUgQWJz dHJhY3RzIG9mIHRoZSB0d28NCj4+PiBJLURzIHJhdGhlciBzaW1pbGFyIHdoaWNoIGxlYXZlcyBt ZSB1bmNlcnRhaW4gYWJvdXQgdGhlIHNjb3BlIG9mDQo+Pj4gdGhlIHdvcmsgaW4gTmV0Y29uZi4N Cj4+DQo+PnVuZGVyc3Rvb2QuDQo+Pg0KPj4+IFdoZW4gdGhlIHByb3Bvc2VkIGNoYXJ0ZXIgc2F5 cw0KPj4+ICIgIDEuIEZpbmFsaXplIHRoZSBZQU5HIGRhdGEgbW9kdWxlIGZvciBhIHN5c3RlbS1s ZXZlbCBrZXlzdG9yZQ0KPj4+ICAgICAgIG1lY2hhbmlzbSwgdGhhdCBjYW4gYmUgdXNlZCB0byBo b2xkIG9udG8gYXN5bW1ldHJpYyBwcml2YXRlDQo+Pj4gICAgICAga2V5cyBhbmQgY2VydGlmaWNh dGVzIHRoYXQgYXJlIHRydXN0ZWQgYnkgdGhlIHN5c3RlbQ0KPj4+ICAgICAgIGFkdmVydGlzaW5n IHN1cHBvcnQgZm9yIHRoaXMgbW9kdWxlLiINCj4+Pg0KPj4+IEkgYW0gc3RpbGwgdW5jZXJ0YWlu Lg0KPj4NCj4+dW5kZXJzdG9vZC4NCj4+DQo+Pj4gWW91IGFyZSBzYXlpbmcgc3ltbWV0cmljIGtl eXMgbWF5IGNvbWUgaW4gZnV0dXJlIGJ1dCBzaG91bGQgdGhpcw0KPj4+IGJlIHBhcnQgb2YgdGhl IGNoYXJ0ZXIgbm93PyBJIGFtIGRpdmlkZWQgb24gdGhpcy4NCj4+DQo+PkknbSBhbHNvIGRpdmlk ZWQgb24gaXQsIGJ1dCBpdCBpcyB0aGUgY2FzZSB0aGF0IHdlIGhhZCBwYXNzd29yZHMNCj4+KHJl YWQgInN5bW1ldHJpYyBrZXlzIikNCj4NCj5JIHdvdWxkbqn2dCBlcXVhdGUgYSBwYXNzd29yZCB3 aXRoIGEgc3ltbWV0cmljIGtleS4NCj4NCj4+aW4gdGhlIHByZXZpb3VzIHZlcnNpb24gb2YgdGhl IGtleXN0b3JlDQo+PmRyYWZ0IGFuZCwgdGhlIHJlYXNvbiB0aGF0IHRoZXkncmUgbm90IHRoZXJl IG5vdyBpcyBiZWNhdXNlIHdlDQo+Pm1vdmVkIHRoZSBwYXNzd29yZHMgdG8gdGhlIGlldGYtc3No LWNsaWVudCBtb2R1bGUgaW4gdGhlIGN1cnJlbnQNCj4+dmVyc2lvbiBvZiB0aGUgZHJhZnQuLi5h IGRlY2lzaW9uIHRoYXQgSSBjb25zaWRlciB0byBiZSAidW5kZXINCj4+cmV2aWV3IiBhbmQgdG8g YmUgZGlzY3Vzc2VkIGluIENoaWNhZ28uDQo+Pg0KPj4+IFlvdSBhcmUgc2F5aW5nIHlvdSBhcmUg dW5zdXJlIGFib3V0IHN5c3RlbS1sZXZlbCBidXQgd2hhdCBpcyBpdA0KPj4+IHRoZW4sIG5vdCB0 aGF0IEkgaGF2ZSBldmVyIHJlYWxpc2VkIHdoYXQgaXMgbWVhbnQgYnkgc3lzdGVtLWxldmVsDQo+ Pj4gKHVubGVzcyBpdCBtZWFucyBub3QganVzdCBmb3Igcm91dGVycywgYnV0IHRoZW4gdGhlIEFi c3RyYWN0IG9mDQo+Pj4ga2V5LWNoYWluLCBmb3IgdGhlIGZpcnN0IGZpdmUgc2VudGVuY2VzLCBz b3VuZHMgbGlrZSBhIHN5c3RlbS13aWRlDQo+Pj4gbW9kZWwgd2l0aCBzZW50ZW5jZSBzaXggb25s eSBzYXlpbmcgaXQgaXMgY29tbW9ubHkgdXNlZCBmb3Igcm91dGluZw0KPj4+IHByb3RvY29scywg aXQgZG9lcyBub3Qgc2F5IGl0IGlzIG5vdCBhbHNvIGZvciBzeXN0ZW0td2lkZSB1c2UhKS4NCj4+ Pg0KPj4+IEkgd291bGQgdGhlbiBhdm9pZCBzeXN0ZW0tbGV2ZWwsIHNpbmNlIEkgZG8gbm90IHVu ZGVyc3RhbmQgaXQ6LSgNCj4+DQo+PkkgYWdyZWUsIGZvciB0aGUgcmVhc29ucyB5b3UgbWVudGlv bmVkLCBoZW5jZSB3aHkgSSd2ZSByZXNpc3RlZA0KPj5wdXR0aW5nICJzeXN0ZW0iIGludG8gdGhl IGRyYWZ0J3Mgb3IgdGhlIG1vZHVsZSdzIG5hbWUuICBBZG1pdHRlZGx5LA0KPj50aGUgZHJhZnQn cyBhYnN0cmFjdC9pbnRybyBjdXJyZW50bHkgc2F5ICJzeXN0ZW0iLCB3aGljaCBzaG91bGQNCj4+ cHJvYmFibHkgYmUgcmVtb3ZlZC4NCj4+DQo+Pj4gIkdlbmVyaWMga2V5c3RvcmUgbWVjaGFuaXNt IiBwZXJoYXBzLg0KPj4NCj4+UGVyaGFwcywgb3IganVzdCAia2V5c3RvcmUiIHdpdGggc29tZSBt b3JlIHdvcmRzIGFyb3VuZCBpdHMNCj4+Y29tbW9uIHVzZXMsIGtpbmQgb2YgbGlrZSBob3cgQWNl ZSdzIGtleS1jaGFpbiBkcmFmdCBzYXlzIHRoYXQNCj4+aXQncyBjb21tb25seSB1c2VkIGluIHJv dXRpbmcgcHJvdG9jb2xzLg0KPj4NCj4+PiBJIG5vdGUgdGhhdCB0aGUgY2hhcnRlciBkb2VzIHNh eSAnYXN5bW1ldHJpYycgd2hpY2ggSSB0aGluayBuZWVkcw0KPj4+IHNheWluZyBhbmQgYWxzbyBh ZGRpbmcgdG8gdGhlIEktRDsgYW5kIEkgZG8gdGhpbmsgdGhhdCB0aGUgTmV0Y29uZg0KPj4+IEkt RCBzaG91bGQgcmVjb2duaXNlIHRoZSBleGlzdGVuY2Ugb2Ygb3RoZXIgSS1EcyByZWxhdGluZyB0 byB0aGUNCj4+PiBzdG9yYWdlIG9mICBrZXlzLCBhbHRob3VnaCB0aGF0IGRldGFpbCBpcyBub3Qg YSBtYXR0ZXIgZm9yIHRoZQ0KPj4+IGNoYXJ0ZXIuDQo+Pg0KPj5UaGUgZHJhZnQgY3VycmVudGx5 IHNheXMgInByaXZhdGUga2V5cyIsIHdoaWNoIGEgdmVpbGVkIHJlZmVyZW5jZQ0KPj50byBhc3lt bWV0cmljIGtleXMuICBJdCBjZXJ0YWlubHkgY2FuIHNheSB0aGlzIG1vcmUgb3ZlcnRseS4NCj4+ DQo+PlRoZSBkcmFmdCB1c2VkIHRvIGhhdmUgc29tZSB3b3JkcyByZWdhcmRpbmcgdGhlIGtleS1j aGFpbiBkcmFmdCwNCj4+YnV0IEFjZWUgZGlkbid0IHRoaW5rIHN1Y2ggc2VjdGlvbnMgd2VyZSB1 c2VmdWwgYW5kIHNvIEkgdG9vayBpdA0KPj5vdXQgaW4gdGhlIG1vc3QgcmVjZW50IHZlcnNpb24u ICBJZiB3ZSBhZGQgc29tZXRoaW5nIGJhY2sgaW4gbm93LA0KPj5pdCB3b3VsZCBiZSBhbG9uZyB0 aGUgbGluZXMgb2YgaG93IHRoZSBrZXktY2hhaW4gbW9kdWxlIGlzDQo+PnNwZWNpYWxpemVkIGZv ciBhIG5hcnJvdyBwdXJwb3NlLCB3aGlsZSB0aGUga2V5c3RvcmUgbW9kdWxlIGlzDQo+PnVzZWZ1 bCBpbiBzZXZlcmFsIGNvbnRleHRzLg0KPg0KPlRoYXQgd291bGQgYmUgZmluZS4gSSBoYXZlIGFk ZGVkIKn4YXBwbGljYXRpb25zIHVzaW5nIHN5bW1ldHJpYyBrZXlzqfcgdG8NCj50aGUgQWJzdHJh Y3QgYW5kIEludHJvZHVjdGlvbiBvZiB0aGUga2V5LWNoYWluIGRyYWZ0LiBXaGlsZSBvbmUgY291 bGQNCj5jb25jZWl2YWJseSB1c2Uga2V5LWNoYWlucyBmb3Igb3RoZXIgcHVycG9zZXMsIEkgZnVs bHkgYmVsaWV2ZSB0aGVyZSBhcmUNCj5tdWNoIG1vcmUgc3RyYWlnaHQtZm9yd2FyZCB3YXlzIHRv IG1vZGVsIGtleXMgYW5kL29yIG90aGVyIHNlY3VyaXR5DQo+b2JqZWN0cyByZXF1aXJlZCBmb3Ig dGhlc2UgdXNhZ2VzLiBJIGRvbqn2dCBzZWUga2V5LWNoYWlucyBldmVyIGV2b2x2aW5nDQo+dG8N Cj5tb3JlIHRoYW4gZXhhY3RseSBhcyB0aGUgQWJzdHJhY3QgZGVzY3JpYmVzIHRoZW06DQo+DQo+ ICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIGtleSBjaGFpbiBZQU5HIGRhdGEgbW9kZWwu ICBBIGtleSBjaGFpbg0KPiAgIGlzIGEgbGlzdCBvZiBlbGVtZW50cyBlYWNoIGNvbnRhaW5pbmcg YSBrZXkgc3RyaW5nLCBzZW5kIGxpZmV0aW1lLA0KPiAgIGFjY2VwdCBsaWZldGltZSwgYW5kIGFs Z29yaXRobSAoYXV0aGVudGljYXRpb24gb3IgZW5jcnlwdGlvbikuICBCeQ0KPiAgIHByb3Blcmx5 IG92ZXJsYXBwaW5nIHRoZSBzZW5kIGFuZCBhY2NlcHQgbGlmZXRpbWVzIG9mIG11bHRpcGxlIGtl eQ0KPiAgIGNoYWluIGVsZW1lbnRzLCBrZXkgc3RyaW5ncyBhbmQgYWxnb3JpdGhtcyBtYXkgYmUg Z3JhY2VmdWxseSB1cGRhdGVkLg0KPiAgIEJ5IHJlcHJlc2VudGluZyB0aGVtIGluIGEgWUFORyBk YXRhIG1vZGVsLCBrZXkgZGlzdHJpYnV0aW9uIGNhbiBiZQ0KPiAgIGF1dG9tYXRlZC4gIEtleSBj aGFpbnMgYXJlIGNvbW1vbmx5IHVzZWQgZm9yIHJvdXRpbmcgcHJvdG9jb2wNCj4gICBhdXRoZW50 aWNhdGlvbiBhbmQgb3RoZXIgYXBwbGljYXRpb25zIHJlcXVpcmluZyBzeW1tZXRyaWMga2V5cy4g IEluDQo+ICAgc29tZSBhcHBsaWNhdGlvbnMsIHRoZSBwcm90b2NvbHMgZG8gbm90IHVzZSB0aGUg a2V5IGNoYWluIGVsZW1lbnQga2V5DQo+ICAgZGlyZWN0bHksIGJ1dCByYXRoZXIgYSBrZXkgZGVy aXZhdGlvbiBmdW5jdGlvbiBpcyB1c2VkIHRvIGRlcml2ZSBhDQo+ICAgc2hvcnQtbGl2ZWQga2V5 IGZyb20gdGhlIGtleSBjaGFpbiBlbGVtZW50IGtleSAoZS5nLiwgdGhlIE1hc3RlciBLZXlzDQo+ ICAgdXNlZCBpbiB0aGUgVENQIEF1dGhlbnRpY2F0aW9uIE9wdGlvbihUQ1AtQU8pKS4NCj4NCj48 dHA+DQo+DQo+WWVzLCBJIGxpa2UgYWxsIGtleSByZWZlcmVuY2VzIHRvIHNheSBlaXRoZXIgc3lt bWV0cmljIGtleSBvciBhc3ltbWV0cmljDQo+a2V5LCBzdWNoIGFzICd0aGUgcHJpdmF0ZSBrZXkg b2YgYW4gYXN5bW1ldHJpYyBrZXkgcGFpcicgYSBjb21tZW50IHdoaWNoDQo+SSB3aWxsIG1ha2Ug b24gdGhlIE5ldGNvbmYgbGlzdCBmb3IgdGhlIE5ldGNvbmYgSS1ELg0KPg0KPkZvciB0aGUgcnRn d2cgSS1ELCBJIHdvdWxkIGxpa2UgeW91IHRvIHJlb3JkZXIgdGhlIEFic3RyYWN0IHRvIG1ha2Ug aXRzDQo+YXBwbGljYWJpbGl0eSBjbGVhcmVyIGZvciB0aGUgY2FzdWFsIHJlYWRlciwgdG8gd2hp dCwNCj4NCj5ORVcNCj4gVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIGtleSBjaGFpbiBZQU5H IGRhdGEgbW9kZWwuDQo+IEtleSBjaGFpbnMgYXJlIGNvbW1vbmx5IHVzZWQgZm9yIHJvdXRpbmcg cHJvdG9jb2wNCj4gICBhdXRoZW50aWNhdGlvbiBhbmQgb3RoZXIgYXBwbGljYXRpb25zIHJlcXVp cmluZyBzeW1tZXRyaWMga2V5cy4NCj5BIGtleSBjaGFpbg0KPiAgIGlzIGEgbGlzdCBvZiBlbGVt ZW50cyBlYWNoIGNvbnRhaW5pbmcgYSBrZXkgc3RyaW5nLCBzZW5kIGxpZmV0aW1lLA0KPiAgIGFj Y2VwdCBsaWZldGltZSwgYW5kIGFsZ29yaXRobSAoYXV0aGVudGljYXRpb24gb3IgZW5jcnlwdGlv bikuICBCeQ0KPiAgIHByb3Blcmx5IG92ZXJsYXBwaW5nIHRoZSBzZW5kIGFuZCBhY2NlcHQgbGlm ZXRpbWVzIG9mIG11bHRpcGxlIGtleQ0KPiAgIGNoYWluIGVsZW1lbnRzLCBrZXkgc3RyaW5ncyBh bmQgYWxnb3JpdGhtcyBtYXkgYmUgZ3JhY2VmdWxseSB1cGRhdGVkLg0KPiAgIEJ5IHJlcHJlc2Vu dGluZyB0aGVtIGluIGEgWUFORyBkYXRhIG1vZGVsLCBrZXkgZGlzdHJpYnV0aW9uIGNhbiBiZQ0K PiAgIGF1dG9tYXRlZC4NCj5Jbg0KPiAgIHNvbWUgYXBwbGljYXRpb25zLCB0aGUgcHJvdG9jb2xz IGRvIG5vdCB1c2UgdGhlIGtleSBjaGFpbiBlbGVtZW50IGtleQ0KPiAgIGRpcmVjdGx5LCBidXQg cmF0aGVyIGEga2V5IGRlcml2YXRpb24gZnVuY3Rpb24gaXMgdXNlZCB0byBkZXJpdmUgYQ0KPiAg IHNob3J0LWxpdmVkIGtleSBmcm9tIHRoZSBrZXkgY2hhaW4gZWxlbWVudCBrZXkgKGUuZy4sIHRo ZSBNYXN0ZXIgS2V5cw0KPiAgIHVzZWQgaW4gdGhlIFRDUCBBdXRoZW50aWNhdGlvbiBPcHRpb24o VENQLUFPKSkuDQoNClRoYW5rcyBUb20gLSBJIGFncmVlIHRoYXQgdGhpcyBpcyBhIGJldHRlciBj bGVhcmVyIG9yZ2FuaXphdGlvbiBvZiB0aGUNCkFic3RyYWN0IGFuZCBJbnRyb2R1Y3Rpb24uIFRo aXMgd2lsbCBiZSBpbiB0aGUgdXBkYXRlIEkgcG9zdCBuZXh0IHdlZWsuDQoNClRoYW5rcywNCkFj ZWUgDQoNCg0KDQo+DQo+YXMgSSBoYXZlIGltcGxpZWQgb24gdGhlIE5ldGNvbmYgbGlzdCwgdGhl IGN1cnJlbnQgbGF5b3V0IGhhcyBtZSByZWFkaW5nDQo+dGhlIGZpcnN0IGZpdmUgc2VudGVuY2Vz IGFuZCB0aGlua2luZyB0aGF0IHRoaXMgaXMgYW4gYWxsLWVtYnJhY2luZyBrZXkNCj5yZWxhdGVk IG1vZGVsLCB0aGVuIEkgZ2V0IHRvIHNlbnRlbmNlIHNpeCBhbmQgdGhpbmssIHdlbGwsIEkgYW0g Y29uZnVzZWQNCj5ub3cuICBQdXR0aW5nIHRoYXQgc2VudGVuY2UgYWJvdXQgcm91dGluZyBwcm90 b2NvbHMgZWFybGllciB3b3VsZCBsZWF2ZQ0KPm1lIGxlc3MgY29uZnVzZWQuDQo+DQo+VG9tIFBl dGNoDQo+VGhlIG9ubHkgYXVnbWVudGF0aW9ucyBJqfZkIGVudmlzaW9uIHdvdWxkIGJlIGFkZGl0 aW9uYWwgYWxnb3JpdGhtcyBhbmQNCj5wb3RlbnRpYWxseSBvdGhlciBrZXkgYXR0cmlidXRlcy4g T2YgY291cnNlLCBvbmUgY2FuIG5ldmVyIGZ1bGx5IHByZWRpY3QNCj50aGUgZnV0dXJlLg0KPg0K PlRoYW5rcywNCj5BY2VlDQo+DQo+DQo+DQo+Pg0KPj4NCj4+S2VudA0KPj4NCj4+DQo+DQoNCg== From nobody Mon Mar 27 02:36:45 2017 Return-Path: X-Original-To: rtgwg@ietf.org Delivered-To: rtgwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 517C41294B5; Mon, 27 Mar 2017 02:36:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtgwg@ietf.org Subject: I-D Action: draft-ietf-rtgwg-spf-uloop-pb-statement-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.48.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149060739728.7991.7538908475369601805@ietfa.amsl.com> Date: Mon, 27 Mar 2017 02:36:37 -0700 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 09:36:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Area Working Group of the IETF. Title : Link State protocols SPF trigger and delay algorithm impact on IGP micro-loops Authors : Stephane Litkowski Bruno Decraene Martin Horneffer Filename : draft-ietf-rtgwg-spf-uloop-pb-statement-03.txt Pages : 14 Date : 2017-03-27 Abstract: A micro-loop is a packet forwarding loop that may occur transiently among two or more routers in a hop-by-hop packet forwarding paradigm. In this document, we are trying to analyze the impact of using different Link State IGP implementations in a single network in regards of micro-loops. The analysis is focused on the SPF triggers and SPF delay algorithm. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-spf-uloop-pb-statement/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtgwg-spf-uloop-pb-statement-03 https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-spf-uloop-pb-statement-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-spf-uloop-pb-statement-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 Mar 27 08:44:35 2017 Return-Path: X-Original-To: rtgwg@ietf.org Delivered-To: rtgwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F276129781; Mon, 27 Mar 2017 08:44:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtgwg@ietf.org Subject: I-D Action: draft-ietf-rtgwg-yang-key-chain-16.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.48.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149062946834.30583.12244265522603320289@ietfa.amsl.com> Date: Mon, 27 Mar 2017 08:44:28 -0700 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 15:44:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Area Working Group of the IETF. Title : Routing Key Chain YANG Data Model Authors : Acee Lindem Yingzhen Qu Derek Yeung Ing-Wher Chen Jeffrey Zhang Filename : draft-ietf-rtgwg-yang-key-chain-16.txt Pages : 25 Date : 2017-03-27 Abstract: This document describes the key chain YANG data model. Key chains are commonly used for routing protocol authentication and other applications requiring symmetric keys. A key chain is a list of elements each containing a key string, send lifetime, accept lifetime, and algorithm (authentication or encryption). By properly overlapping the send and accept lifetimes of multiple key chain elements, key strings and algorithms may be gracefully updated. By representing them in a YANG data model, key distribution can be automated. In some applications, the protocols do not use the key chain element key directly, but rather a key derivation function is used to derive a short-lived key from the key chain element key (e.g., the Master Keys used in the TCP Authentication Option(TCP-AO)). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-key-chain/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtgwg-yang-key-chain-16 https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-yang-key-chain-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-yang-key-chain-16 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 Mar 27 10:05:16 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 175E512945D; Mon, 27 Mar 2017 10:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.496 X-Spam-Level: X-Spam-Status: No, score=-5.496 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_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=eJz6zgvt; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=CADTreoQ 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 D_NUr2GHbY4T; Mon, 27 Mar 2017 10:05:12 -0700 (PDT) Received: from esa5.dell-outbound.iphmx.com (esa5.dell-outbound.iphmx.com [68.232.153.95]) (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 95CBC129479; Mon, 27 Mar 2017 10:05:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1490633737; x=1522169737; h=from:cc:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=Lz7VclSW8bYkHlFxUm0rrSUR/2V1edpIDAAQwjeCRf4=; b=eJz6zgvtJFQghrhxRcuqPKADgvdf7AqMsMFXL0mnnRRO9vrsA67N/rST Jh9L3OrT7BUIgktzPGL9F8vkPBMOaPLbWi2Lo/ZCUhbeDAKdhKMPVoHXy PuQuMdYNdBCxt02OTghpoAJNVqODT2LNOuBIcPFGvDOFKznyzDto6Ty1V c=; Received: from esa5.dell-outbound2.iphmx.com ([68.232.153.203]) by esa5.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Mar 2017 11:55:36 -0500 From: "Black, David" Cc: "Black, David" , "White, Joseph L" , "John Leung (john.leung@intel.com)" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa5.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Mar 2017 23:05:06 +0600 Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v2RH54lM028001 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 27 Mar 2017 13:05:05 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com v2RH54lM028001 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1490634306; bh=0IcNB3jAYwS8VpiAdJ9oZSmt7LE=; h=From:To:CC:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=CADTreoQ2yCw8+t7GH1XcH7g+4Dhswnhvlo8ywQZtSwRQSxTZiQUTEPV7V+xzG6Zk 6gd6UVa8ia8tI/EpNVcrJRUEZ2nFTdLY7Jf7++4Fu+m63zw14GHLOGdRG7020FEJEW Sf2FuHTbow3fngEvaVjy1AeuRtTsK7Y0UouPIa+c= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com v2RH54lM028001 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd03.lss.emc.com (RSA Interceptor); Mon, 27 Mar 2017 13:04:34 -0400 Received: from MXHUB310.corp.emc.com (MXHUB310.corp.emc.com [10.146.3.36]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v2RH4kLf001288 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Mon, 27 Mar 2017 13:04:46 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB310.corp.emc.com ([10.146.3.36]) with mapi id 14.03.0266.001; Mon, 27 Mar 2017 13:04:45 -0400 To: "rtgwg@ietf.org" , "ops-area@ietf.org" Subject: YANG Device Profile for Data Center switches - in RTGWG and OPS-AREA Thread-Topic: YANG Device Profile for Data Center switches - in RTGWG and OPS-AREA Thread-Index: AdKnHEHhHrAiDD35RQisC3nm4Ia8CQ== Date: Mon, 27 Mar 2017 17:04:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.105.8.135] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: public, GIS Solicitation Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 17:05:16 -0000 Gentle rtgwg and ops-area participants, I wanted to call attention to a couple of drafts about early activity on a = YANG profile for data center switches that will be discussed in RTGWG (firs= t session, Wed , 9a start) and OPS-AREA (Thursday, 1p start): https://datatracker.ietf.org/doc/html/draft-wbl-rtgwg-yang-ci-profile-bkgd https://datatracker.ietf.org/doc/html/draft-wbl-rtgwg-baseline-switch-mode= l For those who don't want to wade through the drafts, the RTGWG chairs have = already posted the slides: https://www.ietf.org/proceedings/98/slides/slides-98-rtgwg-yang-device-prof= ile-for-redfish-network-management-draft-wbl-rtgwg-baseline-switch-model-dr= aft-wbl-rtgwg-yang-ci-profile-bkgd-00.pdf [watch out for URL split across lines ...] The short summary is that for data center converged infrastructure [CI], ne= tworking should be managed as part of the overall infrastructure - e.g., si= ngle "pane of glass" for an 84U rack of which 4U may be networking equipmen= t. Another standards body (DMTF - Distributed Management Task Force) is w= orking on a standard for CI management, Redfish, and is reusing YANG models= for network management via a translation approach (hallelujah - not-invent= ed-here doesn't win every time!) - among the benefits of reuse this should = be common views of underling state via YANG-based CI management and network= management tools.=20 This reuse is working "running code" today, as described in the slides and = the ci-profile-background draft. The next step is to define the minimum im= plementation requirements for what data center switches to be managed as pa= rt of CI - i.e., when a YANG-based management tool looks at such a switch, = what does it expect to see as the minimum set of supported YANG modules, i.= e., a device profile. This avoids "defensive programming" in management to= ols to deal with different switch implementations supporting different YANG= modules - that inevitably leads to switch-specific code in management tool= s. The baseline-switch-model draft is a rather drafty first start on the m= inimum set of supported YANG modules for data center switches (NB: the set = will differ for other classes of equipment/devices) - we're looking to do t= his work in the IETF so that the resulting device profile is broadly useful= well beyond Redfish, and we (draft co-authors) are looking for all the hel= p, advice, etc. that people care to offer. In particular, we're not attac= hed to the format of that draft - it was our first attempt to capture mater= ial. The longer, more detailed discussion of this activity will be in RTGWG - th= e shorter OPS-AREA session is intended to be more of an overview of the act= ivity and why it's useful in the hope of engendering interest. We'll be ha= ppy to take questions on the lists, in the meetings or directly. Thanks, --David (on behalf of Joe White, David Black and John Leung, the wb= l draft co-authors) -------------------------------------------------------- David L. Black, Distinguished Engineer Dell EMC, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0 Cell: +1 (978) 394-7754 David.Black@dell.com <=3D=3D=3D NEW =3D=3D=3D -------------------------------------------------------- From nobody Mon Mar 27 15:49:35 2017 Return-Path: X-Original-To: rtgwg@ietf.org Delivered-To: rtgwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0DC127B52; Mon, 27 Mar 2017 15:49:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtgwg@ietf.org Subject: I-D Action: draft-ietf-rtgwg-yang-key-chain-17.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.48.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149065496926.30501.12153996757288343407@ietfa.amsl.com> Date: Mon, 27 Mar 2017 15:49:29 -0700 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 22:49:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Area Working Group of the IETF. Title : Routing Key Chain YANG Data Model Authors : Acee Lindem Yingzhen Qu Derek Yeung Ing-Wher Chen Jeffrey Zhang Filename : draft-ietf-rtgwg-yang-key-chain-17.txt Pages : 25 Date : 2017-03-27 Abstract: This document describes the key chain YANG data model. Key chains are commonly used for routing protocol authentication and other applications requiring symmetric keys. A key chain is a list of elements each containing a key string, send lifetime, accept lifetime, and algorithm (authentication or encryption). By properly overlapping the send and accept lifetimes of multiple key chain elements, key strings and algorithms may be gracefully updated. By representing them in a YANG data model, key distribution can be automated. In some applications, the protocols do not use the key chain element key directly, but rather a key derivation function is used to derive a short-lived key from the key chain element key (e.g., the Master Keys used in the TCP Authentication Option(TCP-AO)). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-key-chain/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtgwg-yang-key-chain-17 https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-yang-key-chain-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-yang-key-chain-17 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 Mar 27 15:52:51 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B94471204DA for ; Mon, 27 Mar 2017 15:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.501 X-Spam-Level: X-Spam-Status: No, score=-13.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 xTV7GtkgLZ8t for ; Mon, 27 Mar 2017 15:52:47 -0700 (PDT) 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 95AC612965E for ; Mon, 27 Mar 2017 15:52:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2683; q=dns/txt; s=iport; t=1490655165; x=1491864765; h=from:cc:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=YgXlelYVmySmnnACSX4J+qpSHKGpyLYpM5DFjUQhRmw=; b=egXPwdbYB1GTCGuo8LaNvYRF9r8y/eTS8xGUlyjapsQ6uj7bx5knVt3c rBOb9sOLN+4Vl8+xvtHBWFLqhXr2kM2h813VBTDVbDzSV5oK2FjVImQeq 0FEdggamvpUwcF07et34WtPdbm+whb+zEEeaEKC3TqHecWpu7rJntjt9M g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BrAQB4ltlY/5JdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1RhfQ4HjWqRIZV4gg4fDYV2AiaCeD8YAQIBAQEBAQEBayiFDQkCAQM?= =?us-ascii?q?BAWwLEAIBCEYnCyUCEgWFcoQVDq43ik8BAQEBAQEEAQEBAQEBASGLPYMXhFWCT?= =?us-ascii?q?QWQIYw6AYZ6i1GBfFSEVooLk2QBHziBBFkVGClnDIVldYhggQ0BAQU?= X-IronPort-AV: E=Sophos;i="5.36,234,1486425600"; d="scan'208";a="225525567" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Mar 2017 22:52:44 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v2RMqiuU011064 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 27 Mar 2017 22:52:44 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.1210.3; Mon, 27 Mar 2017 18:52:43 -0400 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.1210.000; Mon, 27 Mar 2017 18:52:43 -0400 From: "Acee Lindem (acee)" CC: "rtgwg@ietf.org" Subject: Re: I-D Action: draft-ietf-rtgwg-yang-key-chain-17.txt Thread-Topic: I-D Action: draft-ietf-rtgwg-yang-key-chain-17.txt Thread-Index: AQHSp0x3DiOjkxqZM02eErN9bsLP8KGpOk0A Date: Mon, 27 Mar 2017 22:52:43 +0000 Message-ID: References: <149065496926.30501.12153996757288343407@ietfa.amsl.com> In-Reply-To: <149065496926.30501.12153996757288343407@ietfa.amsl.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.24.118.200] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 22:52:50 -0000 This version includes Alia=B9s AD comments and Tom Petch=B9s WG last call comments. I used the YANG model =B3Security Considerations=B2 template from Benoit=B9s last E-mail on the subject since it apparently doesn=B9t have a permanent location as of yet. Thanks, Acee=20 On 3/27/17, 5:49 PM, "rtgwg on behalf of 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 Routing Area Working Group of the IETF. > > Title : Routing Key Chain YANG Data Model > Authors : Acee Lindem > Yingzhen Qu > Derek Yeung > Ing-Wher Chen > Jeffrey Zhang > Filename : draft-ietf-rtgwg-yang-key-chain-17.txt > Pages : 25 > Date : 2017-03-27 > >Abstract: > This document describes the key chain YANG data model. Key chains > are commonly used for routing protocol authentication and other > applications requiring symmetric keys. A key chain is a list of > elements each containing a key string, send lifetime, accept > lifetime, and algorithm (authentication or encryption). By properly > overlapping the send and accept lifetimes of multiple key chain > elements, key strings and algorithms may be gracefully updated. By > representing them in a YANG data model, key distribution can be > automated. > > In some applications, the protocols do not use the key chain element > key directly, but rather a key derivation function is used to derive > a short-lived key from the key chain element key (e.g., the Master > Keys used in the TCP Authentication Option(TCP-AO)). > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-key-chain/ > >There are also htmlized versions available at: >https://tools.ietf.org/html/draft-ietf-rtgwg-yang-key-chain-17 >https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-yang-key-chain-17 > >A diff from the previous version is available at: >https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtgwg-yang-key-chain-17 > > >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/ > >_______________________________________________ >rtgwg mailing list >rtgwg@ietf.org >https://www.ietf.org/mailman/listinfo/rtgwg From nobody Wed Mar 29 08:40:58 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0AE1296FD for ; Wed, 29 Mar 2017 08:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.845 X-Spam-Level: ** X-Spam-Status: No, score=2.845 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vu_bw7u0Z5Z4 for ; Wed, 29 Mar 2017 08:40:55 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60F11126DC2 for ; Wed, 29 Mar 2017 08:40:55 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=31.133.128.130; From: "Susan Hares" To: Subject: Question on draft-ietf-rtgwg-routing-types Date: Wed, 29 Mar 2017 11:35:59 -0400 Message-ID: <009201d2a8a2$2a9ac4c0$7fd04e40$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0093_01D2A880.A3894BD0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdKonyE6FQw1FFh9RqeyVcySd3MfCA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 15:40:57 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0093_01D2A880.A3894BD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit RTGWG DT: Just curious, did the DT consider BGP routing types? If so, where did you decide BGP routing types were not common routing types? Sue ------=_NextPart_000_0093_01D2A880.A3894BD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

RTGWG DT: =

 

Just curious, did the DT consider BGP routing = types?  If so, where did you decide BGP routing types were not = common routing types?  

 

Sue =

 

 

------=_NextPart_000_0093_01D2A880.A3894BD0-- From nobody Wed Mar 29 08:46:44 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27CB212942F for ; Wed, 29 Mar 2017 08:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 AXnVhJxYUThw for ; Wed, 29 Mar 2017 08:46:40 -0700 (PDT) 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 30083129801 for ; Wed, 29 Mar 2017 08:46:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4799; q=dns/txt; s=iport; t=1490802394; x=1492011994; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=r/yYrAYp9igOLugc4bediKkh8WjMA+VxUJ3pvteF404=; b=V3JHTT9JDu74h7oLA6s2PN0pjVgp2M7Wg4H88CsB16z7MWB/M64ElORq NHBlbsjMniFnRxhEXKDE6pLZu9KryzKZ1JdK6UgHq+Z+lL1vcm6NOXm1e pIJy1q2Ek7HSkLIqJy+SjauJvbuIU86absh4rRXMdD6VP4lnnihyuVifM s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAQDg1dtY/4kNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5nYYELB41skVGQHYUxgg6GIgKDQT8YAQIBAQEBAQEBayiFFQE?= =?us-ascii?q?BAQEDLVwCAQgOAwMBAigHMhQJCAEBBAESigqwFopEAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBHYs9hHSFRQWcYAGST5Ezk2kBHziBBFkVhRkFGIFjdYgpgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.36,241,1486425600"; d="scan'208,217";a="8316565" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Mar 2017 15:46:33 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v2TFkX21030811 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 29 Mar 2017 15:46:33 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 29 Mar 2017 11:46:32 -0400 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.1210.000; Wed, 29 Mar 2017 11:46:32 -0400 From: "Acee Lindem (acee)" To: Susan Hares , "rtgwg@ietf.org" Subject: Re: Question on draft-ietf-rtgwg-routing-types Thread-Topic: Question on draft-ietf-rtgwg-routing-types Thread-Index: AdKonyE6FQw1FFh9RqeyVcySd3MfCP//+DkA Date: Wed, 29 Mar 2017 15:46:32 +0000 Message-ID: References: <009201d2a8a2$2a9ac4c0$7fd04e40$@ndzh.com> In-Reply-To: <009201d2a8a2$2a9ac4c0$7fd04e40$@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.24.96.129] Content-Type: multipart/alternative; boundary="_000_D501400DA5382aceeciscocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 15:46:42 -0000 --_000_D501400DA5382aceeciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sue, We incorporated the types that were required for L3VPN/L2VPN models. Specif= ically, route-distinguisher, route-target, route-target-type, and the vpn-r= oute-target. There was an extensive discussion with the authors of these mo= dels. Thanks, Acee From: rtgwg > on beha= lf of Susan Hares > Date: Wednesday, March 29, 2017 at 10:35 AM To: Routing WG > Subject: Question on draft-ietf-rtgwg-routing-types RTGWG DT: Just curious, did the DT consider BGP routing types? If so, where did you = decide BGP routing types were not common routing types? Sue --_000_D501400DA5382aceeciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <49B8513F94AF614B8EFB95D5BD0A9606@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Sue, 
We incorporated the types that were required for L3VPN/L2VPN models. S= pecifically, route-distinguisher, route-target, route-target-type, and the = vpn-route-target. There was an extensive discussion with the authors of the= se models. 
Thanks,
Acee

From: rtgwg <rtgwg-bounces@ietf.org> on behalf of Susan Ha= res <shares@ndzh.com>
Date: Wednesday, March 29, 2017 at = 10:35 AM
To: Routing WG <rtgwg@ietf.org>
Subject: Question on draft-ietf-rtg= wg-routing-types

RTGWG DT:

 

Just curious, did the DT consider BGP routing types?=   If so, where did you decide BGP routing types were not common routin= g types?  

 

Sue

 

 

 --_000_D501400DA5382aceeciscocom_-- From nobody Wed Mar 29 09:02:10 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC3A1294CD for ; Wed, 29 Mar 2017 09:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.947 X-Spam-Level: X-Spam-Status: No, score=0.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDsbb1ReaK8W for ; Wed, 29 Mar 2017 09:02:08 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F061E1296F3 for ; Wed, 29 Mar 2017 09:02:07 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=31.133.128.130; From: "Susan Hares" To: "'Acee Lindem \(acee\)'" , References: <009201d2a8a2$2a9ac4c0$7fd04e40$@ndzh.com> In-Reply-To: Subject: RE: Question on draft-ietf-rtgwg-routing-types Date: Wed, 29 Mar 2017 11:57:21 -0400 Message-ID: <00c501d2a8a5$265dfe10$7319fa30$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C6_01D2A883.9F4EA800" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDXwzi4B96BBr1TfUCFM48H2sYUSwEVR9oTo5kWroA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 16:02:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00C6_01D2A883.9F4EA800 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Acee: Thank you. Just to clarify your answer, does mean you had a discussion with the operators (e.g. openconfig) who implement the basic BGP model as well? Sue From: Acee Lindem (acee) [mailto:acee@cisco.com] Sent: Wednesday, March 29, 2017 11:47 AM To: Susan Hares; rtgwg@ietf.org Subject: Re: Question on draft-ietf-rtgwg-routing-types Hi Sue, We incorporated the types that were required for L3VPN/L2VPN models. Specifically, route-distinguisher, route-target, route-target-type, and the vpn-route-target. There was an extensive discussion with the authors of these models. Thanks, Acee From: rtgwg on behalf of Susan Hares Date: Wednesday, March 29, 2017 at 10:35 AM To: Routing WG Subject: Question on draft-ietf-rtgwg-routing-types RTGWG DT: Just curious, did the DT consider BGP routing types? If so, where did you decide BGP routing types were not common routing types? Sue ------=_NextPart_000_00C6_01D2A883.9F4EA800 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Acee:

 

Thank you.  =  Just to clarify your answer, does mean you had a discussion with = the operators (e.g. openconfig) who implement the basic BGP model as = well?

 

Sue =  

 

From:= = Acee Lindem (acee) [mailto:acee@cisco.com]
Sent: Wednesday, = March 29, 2017 11:47 AM
To: Susan Hares; = rtgwg@ietf.org
Subject: Re: Question on = draft-ietf-rtgwg-routing-types

 

Hi = Sue, 

We incorporated the types that = were required for L3VPN/L2VPN models. Specifically, route-distinguisher, = route-target, route-target-type, and the vpn-route-target. There was an = extensive discussion with the authors of these = models. 

Thanks,

Acee

 

=

From: = rtgwg <rtgwg-bounces@ietf.org> on = behalf of Susan Hares <shares@ndzh.com>
Date: = Wednesday, March 29, 2017 at 10:35 AM
To: Routing WG = <rtgwg@ietf.org>
Subject: = Question on = draft-ietf-rtgwg-routing-types

 

=

RTGWG DT: =

 

Just curious, did the DT = consider BGP routing types?  If so, where did you decide BGP = routing types were not common routing types? =  

 

Sue =

 

 

------=_NextPart_000_00C6_01D2A883.9F4EA800-- From nobody Wed Mar 29 09:12:04 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F491129864 for ; Wed, 29 Mar 2017 09:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 QfvLbUlOdi_j for ; Wed, 29 Mar 2017 09:11:58 -0700 (PDT) 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 502CA1297AA for ; Wed, 29 Mar 2017 09:11:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10169; q=dns/txt; s=iport; t=1490803918; x=1492013518; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=KmRP34X+dDeTH060PzCJjyK0fE1TFuoLI81XzSwU3nA=; b=elFugU32Cr2vw02lsS4RtJeZh4we9KKE4elQ2li4WcCMLBhnjwRN29Rp gtJUeH1BYKcILnDGXca6OFDtZX1AYJgAHoGTyCfEWWGqCUHqWPq0KltLL zSPB35OiVNSJf+JK8hjXi8yIAhCMehdz/Ibugot7ylgxOXlX7rsSMI8Dd I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAQD229tY/4QNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5nYYELB41skVGQHYUxgg6GIgKDQz8YAQIBAQEBAQEBayiFFQE?= =?us-ascii?q?BAQEDLVwCAQgOAwMBAQEoBzIUCQgBAQQBEooKsB6KRAEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAR2LPYR0FoUvBZxgAZJPkTOTaQEfOIEEWRWFGQUYgWN1iCmBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,241,1486425600"; d="scan'208,217";a="229918708" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Mar 2017 16:11:57 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v2TGBv6j015449 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 29 Mar 2017 16:11:57 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 29 Mar 2017 12:11:56 -0400 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.1210.000; Wed, 29 Mar 2017 12:11:56 -0400 From: "Acee Lindem (acee)" To: Susan Hares , "rtgwg@ietf.org" Subject: Re: Question on draft-ietf-rtgwg-routing-types Thread-Topic: Question on draft-ietf-rtgwg-routing-types Thread-Index: AdKonyE6FQw1FFh9RqeyVcySd3MfCP//+DkAgABW3oD//7A2AA== Date: Wed, 29 Mar 2017 16:11:56 +0000 Message-ID: References: <009201d2a8a2$2a9ac4c0$7fd04e40$@ndzh.com> <00c501d2a8a5$265dfe10$7319fa30$@ndzh.com> In-Reply-To: <00c501d2a8a5$265dfe10$7319fa30$@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.24.96.129] Content-Type: multipart/alternative; boundary="_000_D5014649A539Faceeciscocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 16:12:01 -0000 --_000_D5014649A539Faceeciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Susan Hares > Date: Wednesday, March 29, 2017 at 10:57 AM To: Acee Lindem >, Routing WG > Subject: RE: Question on draft-ietf-rtgwg-routing-types Acee: Thank you. Just to clarify your answer, does mean you had a discussion wi= th the operators (e.g. openconfig) who implement the basic BGP model as wel= l? If you have looked OpenConfig models in Github, they have their own factori= ng of types. The bigger question of OpenConfig and IETF models is certainly= not addressed by this model. Acee Sue From: Acee Lindem (acee) [mailto:acee@cisco.com] Sent: Wednesday, March 29, 2017 11:47 AM To: Susan Hares; rtgwg@ietf.org Subject: Re: Question on draft-ietf-rtgwg-routing-types Hi Sue, We incorporated the types that were required for L3VPN/L2VPN models. Specif= ically, route-distinguisher, route-target, route-target-type, and the vpn-r= oute-target. There was an extensive discussion with the authors of these mo= dels. Thanks, Acee From: rtgwg > on beha= lf of Susan Hares > Date: Wednesday, March 29, 2017 at 10:35 AM To: Routing WG > Subject: Question on draft-ietf-rtgwg-routing-types RTGWG DT: Just curious, did the DT consider BGP routing types? If so, where did you = decide BGP routing types were not common routing types? Sue --_000_D5014649A539Faceeciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <5B639E20363AF74D94FC86FFB8196B3F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable


From: Susan Hares <shares@ndzh.com>
Date: Wednesday, March 29, 2017 at = 10:57 AM
To: Acee Lindem <acee@cisco.com>, Routing WG <rtgwg@ietf.org>
Subject: RE: Question on draft-ietf= -rtgwg-routing-types

Acee:

 

Thank you.   = ;Just to clarify your answer, does mean you had a discussion with the opera= tors (e.g. openconfig) who implement the basic BGP model as well?


If you have looked OpenConfig models in Github, they have their own fa= ctoring of types. The bigger question of OpenConfig and IETF models is cert= ainly not addressed by this model. 

Acee 


 

Sue  <= /span>

 

From: Acee Lindem (acee) [mailto:acee@cisco.com]
Sent: Wednesday, March 29, 2017 11:47 AM
To: Susan Hares; rtgwg@ietf.org
Subject: Re: Question on draft-ietf-rtgwg-routing-types

 

Hi Sue,=  

We inco= rporated the types that were required for L3VPN/L2VPN models. Specifically,= route-distinguisher, route-target, route-target-type, and the vpn-route-ta= rget. There was an extensive discussion with the authors of these models. 

Thanks,=

Acee

&n= bsp;

From: rtgwg <rtgwg-bounces@ietf.org> on behalf of Susan Hares <shares@ndzh.com>
Date: Wednesday, March 29, 2017 at 10:35 AM
To: Routing WG <rtgwg@ietf.org<= /a>>
Subject: Question on draft-ietf-rtgwg-routing-types

&n= bsp;

RTGWG DT:

 =

Just curious, did the DT= consider BGP routing types?  If so, where did you decide BGP routing = types were not common routing types?  

 =

Sue

 =

 =

--_000_D5014649A539Faceeciscocom_-- From nobody Wed Mar 29 09:23:58 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8FC12943A for ; Wed, 29 Mar 2017 09:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.947 X-Spam-Level: X-Spam-Status: No, score=0.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1M6gur_MAQYB for ; Wed, 29 Mar 2017 09:23:55 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28663129665 for ; Wed, 29 Mar 2017 09:23:51 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=31.133.128.130; From: "Susan Hares" To: "'Acee Lindem \(acee\)'" , References: <009201d2a8a2$2a9ac4c0$7fd04e40$@ndzh.com> <00c501d2a8a5$265dfe10$7319fa30$@ndzh.com> In-Reply-To: Subject: RE: Question on draft-ietf-rtgwg-routing-types Date: Wed, 29 Mar 2017 12:19:04 -0400 Message-ID: <002001d2a8a8$2f2dd2b0$8d897810$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01D2A886.A81D6B30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDXwzi4B96BBr1TfUCFM48H2sYUSwEVR9oTAlJPj/UCsDzEmaNxCVNg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 16:23:56 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0021_01D2A886.A81D6B30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Acee: I was querying about operational experience with draft-ietf-rtgwg-routing-types as input for IDR. IDR has adopted BGP model that predates this work. Sue From: Acee Lindem (acee) [mailto:acee@cisco.com] Sent: Wednesday, March 29, 2017 12:12 PM To: Susan Hares; rtgwg@ietf.org Subject: Re: Question on draft-ietf-rtgwg-routing-types From: Susan Hares Date: Wednesday, March 29, 2017 at 10:57 AM To: Acee Lindem , Routing WG Subject: RE: Question on draft-ietf-rtgwg-routing-types Acee: Thank you. Just to clarify your answer, does mean you had a discussion with the operators (e.g. openconfig) who implement the basic BGP model as well? If you have looked OpenConfig models in Github, they have their own factoring of types. The bigger question of OpenConfig and IETF models is certainly not addressed by this model. Acee Sue From: Acee Lindem (acee) [mailto:acee@cisco.com] Sent: Wednesday, March 29, 2017 11:47 AM To: Susan Hares; rtgwg@ietf.org Subject: Re: Question on draft-ietf-rtgwg-routing-types Hi Sue, We incorporated the types that were required for L3VPN/L2VPN models. Specifically, route-distinguisher, route-target, route-target-type, and the vpn-route-target. There was an extensive discussion with the authors of these models. Thanks, Acee From: rtgwg on behalf of Susan Hares Date: Wednesday, March 29, 2017 at 10:35 AM To: Routing WG Subject: Question on draft-ietf-rtgwg-routing-types RTGWG DT: Just curious, did the DT consider BGP routing types? If so, where did you decide BGP routing types were not common routing types? Sue ------=_NextPart_000_0021_01D2A886.A81D6B30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Acee:

 

I was querying about = operational experience with draft-ietf-rtgwg-routing-types as input for = IDR.  IDR has adopted BGP model that predates this work. =

 

Sue =

 

From:= = Acee Lindem (acee) [mailto:acee@cisco.com]
Sent: Wednesday, = March 29, 2017 12:12 PM
To: Susan Hares; = rtgwg@ietf.org
Subject: Re: Question on = draft-ietf-rtgwg-routing-types

 

 

=

 

=

From: = Susan Hares <shares@ndzh.com>
Date: = Wednesday, March 29, 2017 at 10:57 AM
To: Acee Lindem = <acee@cisco.com>, Routing WG = <rtgwg@ietf.org>
Subject: = RE: Question on = draft-ietf-rtgwg-routing-types

 

=

Acee:

 

Thank you.   Just to clarify your = answer, does mean you had a discussion with the operators (e.g. = openconfig) who implement the basic BGP model as well?

 

=

If you have looked OpenConfig = models in Github, they have their own factoring of types. The bigger = question of OpenConfig and IETF models is certainly not addressed by = this model. 

 

=

Acee 

 

=

 

=

 

Sue  

 

= From:= Acee Lindem (acee) [mailto:acee@cisco.com] =
Sent: Wednesday, March 29, 2017 11:47 AM
To: Susan = Hares; rtgwg@ietf.org
Subject: Re: = Question on draft-ietf-rtgwg-routing-types

 

Hi = Sue, 

We = incorporated the types that were required for L3VPN/L2VPN models. = Specifically, route-distinguisher, route-target, route-target-type, and = the vpn-route-target. There was an extensive discussion with the authors = of these models. 

Thanks,

Acee

 

From: = rtgwg <rtgwg-bounces@ietf.org> on = behalf of Susan Hares <shares@ndzh.com>
Date: = Wednesday, March 29, 2017 at 10:35 AM
To: Routing WG = <rtgwg@ietf.org>
Subject: = Question on = draft-ietf-rtgwg-routing-types

 

RTGWG DT: =

 

Just curious, did the DT = consider BGP routing types?  If so, where did you decide BGP = routing types were not common routing types? =  

 

Sue =

 

 

------=_NextPart_000_0021_01D2A886.A81D6B30-- From nobody Fri Mar 31 07:10:30 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 075E51296AA; Fri, 31 Mar 2017 07:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPUI-LBwyhYL; Fri, 31 Mar 2017 07:10:13 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (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 C05991294C4; Fri, 31 Mar 2017 07:10:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v2VEAD2w021705; Fri, 31 Mar 2017 07:10:13 -0700 Received: from XCH15-06-07.nw.nos.boeing.com (xch15-06-07.nw.nos.boeing.com [137.136.238.213]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v2VEA2dI021190 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 31 Mar 2017 07:10:02 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-07.nw.nos.boeing.com (2002:8988:eed5::8988:eed5) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 31 Mar 2017 07:10:01 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Fri, 31 Mar 2017 07:10:01 -0700 From: "Templin, Fred L" To: "rtgwg@ietf.org" , "idr@ietf.org" , "dmm@ietf.org" Subject: A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network Thread-Topic: A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network Thread-Index: AdKqJ23SLpD8In76QZ6KmFhm2+NWUg== Date: Fri, 31 Mar 2017 14:10:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 14:10:16 -0000 Hello, Yesterday (03/30/2017) I presented "A Simple BGP-based Mobile Routing Syste= m for the Aeronautical Telecommunications Network" at the IETF98 rtgwg sessio= n. I also presented the document at the Distributed Mobility Management (DMM) session earlier in the week. Both presentations resulted in interesting que= stions and comments. I would therefore like to invite community review input on th= e document - see below for the announcement with abstract and URLs: Thanks - Fred fred.l.templin@boeing.com --- A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : A Simple BGP-based Mobile Routing System for the = Aeronautical Telecommunications Network Author : Fred L. Templin Filename : draft-templin-atn-bgp-01.txt Pages : 14 Date : 2017-03-29 Abstract: The International Civil Aviation Organization (ICAO) is investigating mobile routing solutions for a worldwide Aeronautical Telecommunications Network with Internet Protocol Services (ATN/IPS). The ATN/IPS will eventually replace existing communication services with an IPv6-based service supporting pervasive Air Traffic Management (ATM) for Air Traffic Controllers (ATC), Airline Operations Controllers (AOC), and all commercial aircraft worldwide. This informational document describes a simple mobile routing service based on mature industry standards to address the ATN/IPS requirements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-templin-atn-bgp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-templin-atn-bgp-01 https://datatracker.ietf.org/doc/html/draft-templin-atn-bgp-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-templin-atn-bgp-01 Please note that it may take a couple of minutes from the time of submissio= n 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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt