From nobody Sat Jul 1 13:05:26 2017 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 33EAF126CC7; Sat, 1 Jul 2017 13:05:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149893951918.426.5472006844083223635@ietfa.amsl.com> Date: Sat, 01 Jul 2017 13:05:19 -0700 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-te-lsp-distribution-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jul 2017 20:05:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing of the IETF. Title : Distribution of Traffic Engineering (TE) Policies and State using BGP-LS Authors : Stefano Previdi Jie Dong Mach(Guoyi) Chen Hannes Gredler Jeff Tantsura Filename : draft-ietf-idr-te-lsp-distribution-07.txt Pages : 27 Date : 2017-07-01 Abstract: This document describes a mechanism to collect the Traffic Engineering and Policy information that is locally available in a router and advertise it into BGP-LS updates. Such information can be used by external components for path computation, re-optimization, service placement, network visualization, etc. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-te-lsp-distribution/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-te-lsp-distribution-07 https://datatracker.ietf.org/doc/html/draft-ietf-idr-te-lsp-distribution-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-te-lsp-distribution-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jul 2 19:43:25 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A77A2129B10 for ; Sun, 2 Jul 2017 19:43:24 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=nistgov.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 MoqRqBTfemC4 for ; Sun, 2 Jul 2017 19:43:21 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0124.outbound.protection.outlook.com [23.103.201.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6AE1120726 for ; Sun, 2 Jul 2017 19:43:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bEflYP5FW8XfJWATJ57dsW8ewoe/XehQlfMVgYBPA/g=; b=o07h9h0dd85Yq6dgdm1slWL8NLoAg5VgcYwbWKtjf7FNv34vTwqV/eX+HNx7nQAVfUgSgBCcxfX43rLVav6ywWReKuN1uiv4nyKRMoIamGagGABK5LqLpZanm+y3ubb6gytbhT6RDcaDpnkVJvWjOl0Q74w+9WZmoLdv95kOsjc= Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM2PR09MB0448.namprd09.prod.outlook.com (10.161.252.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.11; Mon, 3 Jul 2017 02:43:19 +0000 Received: from DM2PR09MB0446.namprd09.prod.outlook.com ([fe80::1c34:a069:468b:fa58]) by DM2PR09MB0446.namprd09.prod.outlook.com ([fe80::1c34:a069:468b:fa58%13]) with mapi id 15.01.1220.015; Mon, 3 Jul 2017 02:43:18 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Alexander Azimov CC: IDR Thread-Topic: Idr Digest, Vol 158, Issue 55 Thread-Index: AQHS8JhbierNvITKTE+0Rt3Sr7SyM6JBZegl Date: Mon, 3 Jul 2017 02:43:18 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [173.73.254.121] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR09MB0448; 7:M2lv1HW5+2VHMpIEeavJyeZq1phDMKaIUTesoSPicM6t/Y++mIYnPWOSWIN/+QVcF8UbTM99J2wcraTH9n22zLDCxrvsjeJ7/8+kjIYC/oBgvVvjxjwP/fAE7xr6OrGcn1J8rHe8PQK6Apl/rVGPk91aSCO2lvL108ahEhRZLU5+uLlYG3hrMIXhDwMloqdnlAHAz6KD210fEBL2HTGvP7nsRfTdpEknB//00WLVtMYWCfBpO5V41WwM1qUIivyTSGiSqMo03NxFJk7FnCBWM8tir65l1p4SQLRgTGDL+cvCmZHy8u1uezw9r0kgMIR9goKGAb2M7oqF5s4Rw2dp7dpp6KtySN5qsdKrU/2mDibIbZVYYWXngXdDsQIHA8n3aaWI1Ji9FBXGp4nR8YX/GnZuUaH9nZ+SXxPnah8FJYBc9oZH5p70jNyjGb8Qc3hhQw1qN/2GNdJkep8zDTnEVrbXL5FSEUin377s0g/dnd3X4jult1KrcFJkAjdeZIWf1fVY7J6oPE/GvhfJRGEVQNgSk/55XzsJPM3aQ5D6BsasiyTxYZ/sbxlEUgLi0mpYxAzoB5cOPtk5ODlSuBV1XGz74laJrNi+Q+GuASFq482TcVrqkoizqVEd8nD2MktqeT5WcxuASsoAkLnwBVvkE81oNj5x4T1XruI4fCC9fQN7xQBRZ4nZhqOEW/1Kk49zqXQJddUUQIb4ug0Z2w+5BQiNI+QgneBUFFuRq+kjNtLD+UdeZ7sJO29wrVVld1hlA9GO8j7oqw3zzT0Zj9nYSCgBjX8/vuim0PGfOHTn/9M= x-ms-office365-filtering-correlation-id: fdf9bdfd-3324-4635-d281-08d4c1bd434e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR09MB0448; x-ms-traffictypediagnostic: DM2PR09MB0448: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(236129657087228)(48057245064654)(92977632026198)(167848164394848)(247924648384137); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(6055026)(6041248)(20161123555025)(20161123558100)(20161123564025)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR09MB0448; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR09MB0448; x-forefront-prvs: 035748864E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39860400002)(39850400002)(39450400003)(39400400002)(39410400002)(5403001)(18543002)(10533003)(81166006)(189998001)(7736002)(8936002)(8676002)(305945005)(102836003)(6246003)(6116002)(33656002)(512874002)(38730400002)(110136004)(3846002)(74316002)(2906002)(2950100002)(66066001)(229853002)(6916009)(3280700002)(25786009)(3660700001)(55016002)(6306002)(99286003)(6506006)(53546010)(14454004)(4326008)(6436002)(86362001)(966005)(9686003)(478600001)(5660300001)(2900100001)(5250100002)(7696004)(50986999)(54356999)(76176999)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0448; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jul 2017 02:43:18.5957 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0448 Archived-At: Subject: Re: [Idr] Idr Digest, Vol 158, Issue 55 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 02:43:25 -0000 > >We would like to try to start a discussion before committing actual change= s >to the draft. I've tried to aggregate questions that were raised during WG >adoption call, hope this will be helpful. > > >It was mentioned that while mandatory status of roles is effective way to >speed up deployment process, it may also bring problems with backward >compatibility. Imagine that after software update you will get errors for >your configuration file, that was working fine. For me it seems like a >design problem that should be solved. Our current plan is to make next >changes in the draft: David and Job have raised some important design discussion points that are not captured (IMO) in your summary: https://www.ietf.org/mail-archive/web/idr/current/msg18223.html=20 https://www.ietf.org/mail-archive/web/idr/current/msg18222.html=20 I feel it would be good to reply directly to their posts and address each o= f their questions/concerns. Sriram Date: Thu, 29 Jun 2017 00:48:50 +0300 From: Alexander Azimov To: idr wg Subject: [Idr] draft-ietf-idr-bgp-open-policy -- discussion Message-ID: Content-Type: text/plain; charset=3D"utf-8" Dear IDR members! We would like to try to start a discussion before committing actual changes to the draft. I've tried to aggregate questions that were raised during WG adoption call, hope this will be helpful. It was mentioned that while mandatory status of roles is effective way to speed up deployment process, it may also bring problems with backward compatibility. Imagine that after software update you will get errors for your configuration file, that was working fine. For me it seems like a design problem that should be solved. Our current plan is to make next changes in the draft: 1. Remove mandatory status of roles: so, roles SHOULD be set on each BGP session instead of MUST. We are also going to make reference to bgp-reje= ct draft, so that there will be no route exchange if there is no import/exp= ort policy or roles; 2. Remove complex roles. For those who is still looking for more flexibility, absence of roles will provide a walk around; 3. Clarify that iOTC MUST NOT be transmitted through *Customer/Provider/Pee*r sessions or unmarked eBGP sessions. There are also few minor questions such as: 1. We have two situations when Notification is sent: when there is conflict pair of roles and when strict mode is set by one side and other side has no roles. Should we use two different subcodes or one is enough= ? 2. Proper naming of attribute: iOTC vs iOtC. We are looking forward your comments and feedback. I'm planning to push these changes during weekend. PS: We would like to ask IDR chairs to give us a slot during meeting at Prague. ------------------------------ From nobody Mon Jul 3 00:32:16 2017 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 694BF127735; Mon, 3 Jul 2017 00:32:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149906713541.4998.17993840168020054664@ietfa.amsl.com> Date: Mon, 03 Jul 2017 00:32:15 -0700 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-rfc5575bis-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 07:32:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing of the IETF. Title : Dissemination of Flow Specification Rules Authors : Susan Hares Christoph Loibl Robert Raszuk Danny McPherson Martin Bacher Filename : draft-ietf-idr-rfc5575bis-04.txt Pages : 32 Date : 2017-07-03 Abstract: This document updates RFC5575 which defines a Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute traffic flow specifications. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix. This draft specifies IPv4 traffic flow specifications via a BGP NLRI which carries traffic flow specification filter, and an Extended community value which encodes actions a routing system can take if the packet matches the traffic flow filters. The flow filters and the actions are processed in a fixed order. Other drafts specify IPv6, MPLS addresses, L2VPN addresses, and NV03 encapsulation of IP addresses. This document updates RFC5575 to correct unclear specifications in the flow filters and to provide rules for actions which interfere (e.g. redirection of traffic and flow filtering). Applications which use the bgp flow specification are: 1) application which automate of inter-domain coordination of traffic filtering, such as what is required in order to mitigate (distributed) denial- of-service attacks; 2) application which control traffic filtering in the context of a BGP/MPLS VPN service, and 3) applications with centralized control of traffic in a SDN or NFV context. Some of deployments of these three applications can be handled by the strict ordering of the BGP NLRI traffic flow filters, and the strict actions encoded in the Extended Community Flow Specification actions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-04 https://datatracker.ietf.org/doc/html/draft-ietf-idr-rfc5575bis-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-rfc5575bis-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 3 02:21:02 2017 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4304C12EBF9; Mon, 3 Jul 2017 02:21:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149907366125.4902.17815425041816330940@ietfa.amsl.com> Date: Mon, 03 Jul 2017 02:21:01 -0700 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-rtc-hierarchical-rr-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 09:21:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing of the IETF. Title : Extensions to RT-Constrain in Hierarchical Route Reflection Scenarios Authors : Jie Dong Mach(Guoyi) Chen Robert Raszuk Filename : draft-ietf-idr-rtc-hierarchical-rr-03.txt Pages : 6 Date : 2017-07-03 Abstract: The Route Target (RT) Constrain mechanism specified in RFC 4684 is used to build a route distribution graph in order to restrict the propagation of Virtual Private Network (VPN) routes. In network scenarios where hierarchical route reflection (RR) is used, the existing RT-Constrain mechanism cannot guarantee a correct route distribution graph. This document describes the problem scenario and proposes a solution to address the RT-Constrain issue in hierarchical RR scenarios. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-rtc-hierarchical-rr/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-rtc-hierarchical-rr-03 https://datatracker.ietf.org/doc/html/draft-ietf-idr-rtc-hierarchical-rr-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-rtc-hierarchical-rr-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 Jul 3 05:14:27 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3FE2126557 for ; Mon, 3 Jul 2017 05:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 (1024-bit key) header.d=arista.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 c3vH-Dr3Qziw for ; Mon, 3 Jul 2017 05:14:22 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::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 EB143126BF6 for ; Mon, 3 Jul 2017 05:14:21 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id z22so108256453uah.1 for ; Mon, 03 Jul 2017 05:14:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arista.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=hw7De9DLosNZHRTRdyVOL8MvIebc8zblLyylM/0Yr3c=; b=ZlfgpJrmpK8dSKdrjqv3tpV45vmJ6mcaSAPIhGjM6g9A8C4T/vwx8HpzhLZ2lMO5mn CcIgh32GVTOHL2ACKBe4Kl217HhHvJbiuCSvjsRdz1iKMNMLkxf9IB4kNnCsehPl+leV TPlnYVaC1y/aCviU0hRL4W1LxoUGA/enIhJxo= 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=hw7De9DLosNZHRTRdyVOL8MvIebc8zblLyylM/0Yr3c=; b=LhK6IIQUO5TZEoTuTPVKE8h3/afZZ6f0kv9C3h2TkYfPNELGjdvYOgClDL/9c/A/Ri tlb5XQDdh+1fIxJ6ucYzyZAHQjC+cGnLK4wxRSwzlHZCBCG00rLbaKGiYxOPZ2dRMA6T I4x06aSX8TMUMObb7KOEa+dBtR9HiP9zPQ5hHoUdLijiZTgTBTqebmgS8g1l0tnTLmXu Ahg6upNMTJYOsi3/sT+9b2CcBnZBWi0NiXd6fIbaupHT6gojIEaHEyFpIZhQE7V1pvDn f9Emx8wCpJayVnfuN3IYr5bwj9qp5Vg7p2KsiY8697m1pcnTVw5rPSQrpGMzvr9V7gy6 CryA== X-Gm-Message-State: AKS2vOy0giOpQA+p/2a4shN02eyGlCH4G9yhzhM+9I3gN9d1Vfpgwfcs io7458WAxbskFYxAV5tUviX8xH2cANnyrOdn7Q== X-Received: by 10.159.59.175 with SMTP id r47mr14435445uah.91.1499084060791; Mon, 03 Jul 2017 05:14:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.4.46 with HTTP; Mon, 3 Jul 2017 05:14:20 -0700 (PDT) In-Reply-To: <149824800169.17379.9099679082498238196@ietfa.amsl.com> References: <149824800169.17379.9099679082498238196@ietfa.amsl.com> From: Nandan Saha Date: Mon, 3 Jul 2017 17:44:20 +0530 Message-ID: To: idr@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Idr] I-D Action: draft-previdi-idr-segment-routing-te-policy-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 12:14:26 -0000 Hello! I have some questions on the NLRI encoding. 1. Can the value of NLRI length be less than 96 for IPv4 AFI and less than 192 for IPv6 AFI? IOW, can it be less than full mask length for the end point address? 2. If the answer to (1) is "yes", then what is the rationale for keeping the end point address field of the NLRI fixed length? (4 or 16 bytes depending on AFI). Should the end point become variable length like the NLRI encoding defined in RFC4760? 3. If the answer to (1) is "no", how are summary addresses to be represented? Another question which is unrelated to the changes in version 7 of the draft. Section "4.2.1. Acceptance of an SR Policy NLRI" says " If the NLRI is not one of the legal lengths, a router supporting this document and that imports the route MUST consider it to be malformed and MUST apply the "treat-as-withdraw" strategy of [RFC7606] " It's not clear to me how a receiver can extract a valid route from a malformed NLRI. The "treat-as-withdraw" can be applied if the NLRI is well formed but some other attributes are malformed, which seems to be implied by the following line at the end of the subsection "A unacceptable SR Policy update that has an invalid NLRI portion MUST trigger a reset of the BGP session." Thank you! Best regards, Nandan On Sat, Jun 24, 2017 at 1:30 AM, wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Inter-Domain Routing of the IETF. > > Title : Advertising Segment Routing Policies in BGP > Authors : Stefano Previdi > Clarence Filsfils > Paul Mattes > Eric Rosen > Steven Lin > Filename : draft-previdi-idr-segment-routing-te-policy-07.txt > Pages : 30 > Date : 2017-06-23 > > Abstract: > This document defines a new BGP SAFI with a new NLRI in order to > advertise a candidate path of a Segment Routing Policy (SR Policy). > An SR Policy is a set of candidate paths consisting of one or more > segment lists. The headend of an SR Policy may learn multiple > candidate paths for an SR Policy. Candidate paths may be learned via > a number of different mechanisms, e.g., CLI, NetConf, PCEP, or BGP. > This document specifies the way in which BGP may be used to > distribute candidate paths. New sub-TLVs for the Tunnel > Encapsulation Attribute are defined. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-previdi-idr-segment-routing-te-policy/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-previdi-idr-segment-routing-te-policy-07 > https://datatracker.ietf.org/doc/html/draft-previdi-idr-segment-routing-te-policy-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-previdi-idr-segment-routing-te-policy-07 > > > 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/ > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Mon Jul 3 05:52:46 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C5813160E for ; Mon, 3 Jul 2017 05:52:39 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=nistgov.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 HxRhU_nhQ7fj for ; Mon, 3 Jul 2017 05:52:36 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0126.outbound.protection.outlook.com [23.103.200.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CD7813160B for ; Mon, 3 Jul 2017 05:52:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Z9MD8KNiQdRRF17IdXcR4RicET13D0hFlaoiyfnc/XE=; b=dc+FkA4yrP2x9etDhyBhKMhq5sAW6nTqnk5NhNdsmCclMcNW7djXdI2iFESiknlzPzZBb9eR0IdW8ylpCDRMZr8PiNsFZZBMCc9DElunccWBzdhDliaiHCtbnsoeX1TTqnBA+QpcTOf4cZdewuAjb4fJ4nxn8smfraqeXQCHRec= Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM2PR09MB0445.namprd09.prod.outlook.com (10.161.252.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.11; Mon, 3 Jul 2017 12:52:35 +0000 Received: from DM2PR09MB0446.namprd09.prod.outlook.com ([fe80::1c34:a069:468b:fa58]) by DM2PR09MB0446.namprd09.prod.outlook.com ([fe80::1c34:a069:468b:fa58%13]) with mapi id 15.01.1220.018; Mon, 3 Jul 2017 12:52:35 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Alexander Azimov CC: IDR Thread-Topic: [Idr] draft-ietf-idr-bgp-open-policy -- discussion Thread-Index: AQHS8/s+dY4QuDYni0GPdTpPunfOcg== Date: Mon, 3 Jul 2017 12:52:35 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [173.73.254.121] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR09MB0445; 7:qTI+AFR7UgsaLH4Lq9pCD4/4tHH8Xg+dTchsBhjYt9rQRs4LFORmpr8TjaHjh/Pkp12SniBDet1q1HWihi4UYrQWB09ICV6i75gdA08BqJx4Q3zz7xo5G3MPr4556OdtGI/LQRUu8is4kXwckC6zCw5XyZB42EVCCLRrl9TySmj6HVZAHrMK09hBaA0G/Fxeuppj6T1fRvUwCSFWumNGb8KDcsdQ8uuO9eI/fb3ws2bQK4KWQnW1PBzog43lauGRxT6YSIT/IiXMsIpLpmKDdPE9ZJgTdx0RleVrWD/bReNASk7fL1o/ZkmnP2RyoZmh3S1/q3IMeqle8sv85aNH56Xy36EN2VaIZOgDOPfBhCs6oqraeZnUY/psio2r8W6kyY78IqLPnxpSkCd4NiE4V3PXWwWVzQF43MEQSc5NCZYYyHVzLor7qwz1AxoYPseX5YmntjkLCBnXoJjGr4d92eOtjzvvNaL77ZF03ISSDB9mbe6Y68gfk1vSWHW3sexNjHxO0po4o2lajJWYo2C66UpYSXcRjYxzqa3fahgBNzryKj3oEoaIS+YXcg5JBGYaxzJpLl1oog8bfrR4d4qeWHiVdQdhc2YnTFsOLTK36dYhdq+YG6TakMrmde4aCWHQBF/yTZk+JyGWR814eGzjphj+ZTmj+eSIiudnhj/mu3nEAmeMcmhtxJhTzloDZXZcM4i4fZr/FuM93PIueBqgbhyuL1geheEnUHCqbfw7intMnuC8Wp2PF8Y8eYEIbCjLrYf00v+TB+WnNrTgSQuemMtpCe56uW1iLPHWCcWfaig= x-ms-office365-filtering-correlation-id: 52620937-ffc9-401f-586a-08d4c21260c1 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR09MB0445; x-ms-traffictypediagnostic: DM2PR09MB0445: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(236129657087228)(48057245064654)(167848164394848); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(100000703101)(100105400095)(10201501046)(6055026)(6041248)(20161123558100)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR09MB0445; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR09MB0445; x-forefront-prvs: 035748864E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39400400002)(39840400002)(39850400002)(39450400003)(2900100001)(189998001)(8936002)(230783001)(3280700002)(229853002)(33656002)(478600001)(2906002)(6916009)(38730400002)(110136004)(6246003)(2950100002)(14454004)(8676002)(966005)(66066001)(81166006)(7696004)(86362001)(74316002)(6506006)(50986999)(54356999)(76176999)(305945005)(7736002)(6436002)(53936002)(3660700001)(99286003)(9686003)(4326008)(55016002)(25786009)(5250100002)(5660300001)(3846002)(6306002)(6116002)(102836003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0445; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jul 2017 12:52:35.3485 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0445 Archived-At: Subject: Re: [Idr] draft-ietf-idr-bgp-open-policy -- discussion X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 12:52:39 -0000 Resending with the correct subject line... sorry about the earlier oversigh= t. Sriram > >We would like to try to start a discussion before committing actual change= s >to the draft. I've tried to aggregate questions that were raised during WG >adoption call, hope this will be helpful. > > >It was mentioned that while mandatory status of roles is effective way to >speed up deployment process, it may also bring problems with backward >compatibility. Imagine that after software update you will get errors for >your configuration file, that was working fine. For me it seems like a >design problem that should be solved. Our current plan is to make next >changes in the draft: David and Job have raised some important design discussion points that are not captured (IMO) in your summary: https://www.ietf.org/mail-archive/web/idr/current/msg18223.html https://www.ietf.org/mail-archive/web/idr/current/msg18222.html I feel it would be good to reply directly to their posts and address each o= f their questions/concerns. Sriram From nobody Mon Jul 3 07:52:12 2017 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF25712EBF7; Mon, 3 Jul 2017 07:52:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149909352493.22848.565380168898713698@ietfa.amsl.com> Date: Mon, 03 Jul 2017 07:52:04 -0700 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-flowspec-l2vpn-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 14:52:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing of the IETF. Title : Dissemination of Flow Specification Rules for L2 VPN Authors : Weiguo Hao Qiandeng Liang James Uttaro James Uttaro Shunwan Zhuang Filename : draft-ietf-idr-flowspec-l2vpn-06.txt Pages : 13 Date : 2017-07-03 Abstract: This document defines BGP flow-spec extension for Ethernet traffic filtering in L2 VPN network. SAFI=134 in [RFC5575] is redefined for dissemination traffic filtering information in an L2VPN environment. A new subset of component types and extended community also are defined. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-l2vpn/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-flowspec-l2vpn-06 https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-l2vpn-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-flowspec-l2vpn-06 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 Jul 3 08:57:11 2017 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 31DEA129B25; Mon, 3 Jul 2017 08:56:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149909741417.22786.4679459342587499122@ietfa.amsl.com> Date: Mon, 03 Jul 2017 08:56:54 -0700 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 15:56:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing of the IETF. Title : Making Route Servers Aware of Data Link Failures at IXPs Authors : Randy Bush Jeffrey Haas John G. Scudder Arnold Nipper Thomas King Filename : draft-ietf-idr-rs-bfd-03.txt Pages : 12 Date : 2017-07-03 Abstract: When BGP route servers are used, the data plane is not congruent with the control plane. Therefore, peers at an Internet exchange can lose data connectivity without the control plane being aware of it, and packets are lost. This document proposes the use of a newly defined BGP Subsequent Address Family Identifier (SAFI) both to allow the route server to request its clients use BFD to track data plane connectivity to their peers' addresses, and for the clients to signal that connectivity state back to the route server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-rs-bfd/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-rs-bfd-03 https://datatracker.ietf.org/doc/html/draft-ietf-idr-rs-bfd-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-rs-bfd-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 Jul 3 08:58:51 2017 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F41213169D; Mon, 3 Jul 2017 08:58:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149909752320.22817.1743005946537953583@ietfa.amsl.com> Date: Mon, 03 Jul 2017 08:58:43 -0700 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-flowspec-l2vpn-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 15:58:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing of the IETF. Title : Dissemination of Flow Specification Rules for L2 VPN Authors : Weiguo Hao Qiandeng Liang James Uttaro Stephane Litkowski Shunwan Zhuang Filename : draft-ietf-idr-flowspec-l2vpn-07.txt Pages : 13 Date : 2017-07-03 Abstract: This document defines BGP flow-spec extension for Ethernet traffic filtering in L2 VPN network. SAFI=134 in [RFC5575] is redefined for dissemination traffic filtering information in an L2VPN environment. A new subset of component types and extended community also are defined. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-l2vpn/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-flowspec-l2vpn-07 https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-l2vpn-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-flowspec-l2vpn-07 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 Jul 3 09:04:32 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6915712785F for ; Mon, 3 Jul 2017 09:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-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=juniper.net 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 sI2jgPSVN1ZM for ; Mon, 3 Jul 2017 09:04:28 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0124.outbound.protection.outlook.com [104.47.36.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE5C6129482 for ; Mon, 3 Jul 2017 09:04:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=j4PMWqUWjR7gPgGaq3XgIchmazc+rJDR8WUjX/pug8g=; b=U9dfErwCDqYEa5jThpOttDwBEdStVHQVGDnpb7pnYS6VYskU/RtOfJOpBTCRC8Dbq2NtzuPIjcoTyZDRjOpIoCPt8BOxzyENbXYe1ozokEcNzuCCssoaJriXaAsrl5zX3lq711FLnWDjDD2T2YcE5negx2dRXIphDle4BTcU27w= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; Received: from [172.29.34.54] (66.129.241.14) by BN3PR05MB2498.namprd05.prod.outlook.com (10.167.3.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.6; Mon, 3 Jul 2017 16:04:27 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: <149909741417.22786.4679459342587499122@ietfa.amsl.com> Date: Mon, 3 Jul 2017 12:04:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2EE46AAC-7206-4F83-A85D-C697193A8F79@juniper.net> References: <149909741417.22786.4679459342587499122@ietfa.amsl.com> To: idr wg X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: BN6PR13CA0043.namprd13.prod.outlook.com (10.171.172.29) To BN3PR05MB2498.namprd05.prod.outlook.com (10.167.3.27) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: daec06ca-9ead-44dc-384a-08d4c22d2e7d X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(48565401081)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR05MB2498; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 3:nJnJxIG4r5BgXKAft+X3Uv99vW2jSDHbfB4lrNJpBE17e605mZpmnvXEpbiOlEyYvCuOjKQnrvoVVUy+Rdx5uodi+YCSMDk4RLD1taB/Zwz5NS0NpWWqO55tqJzbDT5ZlLrEqjtipDeLz2kBnKxDR1Z8Mqbte7yhDekIR+Ste1TYmqZ7GKFbIOFwaCd+kTY53Gp9qEyJlqHvsBdt8ed19zlAl7S3pOWNCCHAMESs/dRyJ7ITVyJOB0nS0pMt9boPHv1DiAgByNBIPjvUKcoqluA0nM40JwiGrGficxP5NC1ZdZIEhtMUAEfEpg/pKiyyAy19kZnn4fQunb4FZpyvFxD0j6MwfBP//uBUVD7m3KS9QS+kThxgKBsCXUJdwjW0t+EE9wcDot+SqGV4gkZ4qUXNwXIvWtFnECPMs7HqwxeOzh7QmmppMIkea2ftltihyetMAGc1uUZZS5Yc6wVBhERogLwQkewEa5hnB0jKsFG69ubQSHW3Q8BY6PkbI6uEUNzH/wVct2SvJb1Ec/dIZkMbyioDADeQKuJ+eDirJppMoqeHC86RfNfwz5rEWASdPSe2N4Qfbxx+9dRT5fVc1si+a5Ebmk9NX8yhdZYQgZ9SIiLKbRGzfRTyzZ95AuTQ80T4g1KxhGGBHHDtd18jknZ8mOuy9Gwx2TwDVMOHSCnjlhciKxvr5QNfICPQG85aNqXns4yHb09VW92PKU7/PAHNvhyPCsD6adqI9JkCKZoLMnBL10X3QG5GBILmWfXJBqMY3r+qXTjjdIE3QJgIUQ== X-MS-TrafficTypeDiagnostic: BN3PR05MB2498: X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 25:qzlUVDAIVIWw2OF5pdvRW3HrKlTj8JaYoeCH/SD0hH0h7ZxsQxkmK24yRHQmgRjWtrVoX2SWSfxPJG8z+Kt+lkZczATWTsOZiuAKNV68yHv3hS9mZLAEVjPDawG9yFyJldbveiHwZNgDjrfyvA13WZkDKduOD52vW1kr/oAZvY6v/nwk4+q8vKUyZfyfiQdg2ojueCE6tCLLJAtehG0t4EtbKtSHXxUQc1ReKLfXwblraaHsaom8T5E4md0o70bwfxTQmphANqYtmgQIMs2CGKt36nB4FUI8DpBbidMg05pfPJYDdPxFChfpLtczVhmeIg8MK0kqgx4W+jojE9YzssJPR+KvA+gOcUI+1/DJnREaBI5Es4ndjMfFs9wDWxVe2yAKx+yCJLPqEs59/aaRNJox+CakWQLIpY2oNBCVffbOrlb7QQVK4NVayYGFHwrJh7rCHhjQG0DHybX1EUJaHFToqkXC+wey9U7tWotP+FS2KmBZTnC/xOkfHOds8R63cKb60zbh93W53xjh6nKSJWsnVjF9v3OXziqjy+nWi+5otbhbNOqvwjcDKDfE8VlNeVuZ1Lh1kFF1RUpUJdG/ytFU1uqZh4zUM/U56eJj1XVYoQcz1gT24dWbRGpvXWEp3ZagC7EWh5z+sT9cR/dZ/VNK982LUEmZuNb8fwFqNM4ta45hgLk1lPUczRqXjf2VQUCBKdOXQ7Y5y7eTl6kLeUOmtXhnMfxwMoPerkM3Wj3/nuKGT0uD0FduQjJ4fa8KSTkqyQsvTqJRKg0Ja3gnugU1bP8AVc08E7KqTvFGjFqpig/kr7jItf0TvbCZnv/kYAvDLQRKTuDZSTJHJk/WQh0MSvkPm3aJ7J7H1JU+DNZSDWQkgrKe3d+rx3xeXAAPaxt8xLUXB+BrrPhsn/jN/1y6CwjT9McmNihz6+Dmb+Q= X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 31:SVZl6Hki8h6P+U9kCKF6ZNj/FEgaAUohE1xlvjXmD7J8UZ0FSul+Z+u1K6TOoAKY5bQay2z7XMkoUizESpis4hCTICtR58mw/7pAfruxQwmDJZAnP6lxPyKYJVucIhYyQX4di6jYbSN3kw0detKbo1SffRRK2+p3S0ZStN6LdFG8t8Az0Omu0C8Qy9x3w5Y6JV05sn16Bdx+Zy12dRJFnvzmR+Gq+T7ACn/n7tNCeoEkUxwALl9TrrAd4JQTQ4FYW7go5MxRGfNWU88U29EFVhWgdpPBr6eNub17m8MmqUysJmuQcHU+xXsl+JV3R9XRjS0fP8jRubYO/U34Z9yZ/JwUImydqC5TlzhYkeI0DCsCPUYr7Pl4EvFRUyRY+OPxzcCC7ogveObHwqYGtShEsaX4VDsHl8I5qf1HjK839Dvs+BYgn+MuI+TpeEW42pXogtzhllU7tH+c47OFZ7lI2AQM9SbOLsnQR6EElP6CVL35JWkhhtQuexyqLxRZNKskdM0CS5snj3LVZ4BdkJHZNWmbeBC1G4+nqA5/s8Rsoi1wnbaOGO6ChHY/ezkIi5xWjiVOWViVLO9ZKv0Tmr65WOaKHSUbowG9prTifNfxh6N/Cu7Ij4+leMhRPI8GUk3NGgHDkQsRx3+hhvuDy7EiaxwV1hwJaEx/OQmc25B04whTB0NJCnvTYJdZHgoPUDsZay1wfFpMV0j9jyNUds2akQ== X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 20:zVGIAroiNmSjN9qNdOcF8yxZX6tGq8eJu7LwqCWf7ZAsg8442gc3XYya8LGAF5YUrRApxDurKxl2LxcmX7p0zptCcquZOjzL9NI4GNo0kKOT5F5SjyyyjhEtTk8qgZQcPBKrT3RD6H6c4o0V1Ny0iV1VQAmGkfxIjzJPR5LHY0s45fQfq94zHs4GTIpdan7L2Deb59jLVpj/7MFU99uAdAMFXtv8gvWqcOVmUtKDmlu+TtVrbMheOctFlUJVSWfS0VrW5JXSfE/YSp8trwC1kWSGsCFNfqokz00HOY7YcRc3h0ksLj240GsZUHdr70rOe/THV06qFsDHJeVbuigCKX89xqujlx98ThhX9NyOR2AS3KLA2peXBvCXhi1b6IQ/ssO47CKKS7fSd5Umf9rvuxs7XPCWADmJ5rsoaGuNGS8RpbzXC51Vsn9U8Yl6pLZwSI85rcJe/bzBbbHKzoBGEjdPP9v0Y9nxY6GsHO3Kboet4qzzhmJOWIU6FbdWJBU+pqjSt4AQuK1rtxuTMnQsElBmGPpFnUjGPUQph88L4rqihzV+QzelDLbXepDIr6AIhjWpmr6zyn+6I1eNQoJ8buPeeEmlqbp0E3gxby+CMAQ= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278178393323532)(158342451672863)(120809045254105)(236129657087228)(148574349560750)(247924648384137); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(6055026)(6041248)(20161123564025)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR05MB2498; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR05MB2498; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR05MB2498; 4:df47dPY0hL1VTLpyrNvgxG+LqTV0S3YYRzRjBLdROm?= =?us-ascii?Q?UaYiSm1PcW4I5EC1wd6/xJnsjhCz7DVMuP1LR0s3Fs5bwPNhk+5fW7FRp4BP?= =?us-ascii?Q?KLNKmXbS1fdS1cK2luJ70iK/j9T5ZJ3a7kaEBGrPUE3enf+QRQyiFsaVGTLf?= =?us-ascii?Q?2mMQKFQYEbohV34KbJl+VoY/TnrD5FWcnfo6vAfumS66fBL31ZR1w4CYyevV?= =?us-ascii?Q?6NaalQdQ4NRmIxpTeebEhaXIyGYYfdNDgbYw+8Lou1c3rfNSj4gVSucCLGuz?= =?us-ascii?Q?DWJrz+DVyhyXYgIuqa08dt25vu70H7quC4nSv4zsOlpSZL0n6qqXCNq7ddlY?= =?us-ascii?Q?uoutN0hbWmKekj3Yvh720XjJ7i7uPpKqujMFvzqwz2EO+pNE1xkB6hjF2JLo?= =?us-ascii?Q?hAxos0RRHQgGQCUvjYQjoGTsuqA9HL+nfy1VYpqyUhGvBl68k4Xjdg9E2oMs?= =?us-ascii?Q?CnDIJIy3u9V6UsDVHt9vUnTDe1bscxXsqzdy9CzJbskSzFIInriVUKrHHDPK?= =?us-ascii?Q?SC7PGleVYhfF3JN2loT3Tkjx9lHG/Euwxl+JqZYaX0NzrZaPVrCMZC/DIovH?= =?us-ascii?Q?as4q67f2bokihdgoW7WaBtvyMyBQtEZ5S0XrjSVWqkJ31jSDxIt9ay9g3C2C?= =?us-ascii?Q?a8J7EigRNMrVv6DhH38qCdnnpzQXbAn9HxszYhE/OTI4S1vH6LNlbDxmIeZv?= =?us-ascii?Q?Kbs3LkeL42Q82IZNUZbVHH66gGqyQek1kUOU3F/0kS2RRPNbBlZYu8OjqUP1?= =?us-ascii?Q?u6IUXCcLb8nMU2baI2/JvLds60bD5jAmul+x2xj5ZPrgfykpetHyORUh6WKH?= =?us-ascii?Q?Ol0ulLJBSzuT8Sx4O28lgiec+A32YuAdTFlTVNhXa8R4hg1Olrx8ltHwd16y?= =?us-ascii?Q?5qxt59bOG2w/9Xsm9+PUaUVIZzTZ/WY3MN1lTGJO0gKZDslFmlKCUpokthia?= =?us-ascii?Q?b6+uqxvZsIfjeOMss/5SpKnbjgF27s3e0f2Vj2pc0fTJtHtMd9gRAQQRMXvQ?= =?us-ascii?Q?jt8ndjrojqFGhqlS8M1/Gd9Q4EaCYIPGr3YGb4JMEAVPed4krf/+5kcPgxcI?= =?us-ascii?Q?3gYHDwYheHr/MVQKF6/BHQAqtZG2v0bhVUkNHhxuR3h/h8EEn6g4f2z7MV7n?= =?us-ascii?Q?kxwywydLl1j3/2+1PPHpXyn32WTCJwDlZcpqmgO95rXMB8u2KnzPK4AWwRrC?= =?us-ascii?Q?GNpy+jEV2Ne+/YOr2wcfo/PBo9xQm53VK/EiqwcDop2ZkOZBHOPZM+hB4dVP?= =?us-ascii?Q?E56Bgcdx4+OJwJN3g206mp88zHuomKMyc8lM+yJ9/AiZ/dB5LQz3BIS97hKl?= =?us-ascii?Q?HWm8hiUwTaCHAIr/QAvdK5zkM3Q6eyisCjGHvhHahKw+Cip8DKBpkzTuHiQm?= =?us-ascii?Q?glQy4DHPcpMO+uNoXohH+mF9E=3D?= X-Forefront-PRVS: 035748864E X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(39450400003)(39410400002)(39860400002)(39840400002)(39850400002)(39400400002)(377424004)(24454002)(53754006)(377454003)(57306001)(8676002)(53546010)(82746002)(50466002)(50226002)(6916009)(2950100002)(83716003)(3846002)(86362001)(189998001)(6116002)(7736002)(230783001)(6666003)(33656002)(81166006)(90366009)(66066001)(305945005)(36756003)(966005)(42186005)(47776003)(229853002)(25786009)(6306002)(478600001)(76176999)(6486002)(5660300001)(50986999)(2906002)(8746002)(53936002)(77096006)(38730400002)(110136004)(6246003)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR05MB2498; H:[172.29.34.54]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR05MB2498; 23:YiSrH8XfHYDsRdhWoycYiwye41drQDl7jkfKQlsYn?= =?us-ascii?Q?KciXiJu4GNlmmYPA90vG/FWSGncznsiojBgF1VDrnlaQCdktR38/dcHE6t9T?= =?us-ascii?Q?5haZMznGQ6ZNSc5lQ2kwW/NXMg8Ya28gtHfRoPVNUSKHf+KgqM2FgQzOnPCS?= =?us-ascii?Q?RvCRG8Si4WI1cjm8sfevXvVEuxRL2Vj2EchCmR1gAoF5TXzaw+Yrd9oQZEL8?= =?us-ascii?Q?OAMMwdJPAXgFZEID2TEWGLxDdIcAGSSLBlZjcDxH9jrWWejT45/OfYuJcdYr?= =?us-ascii?Q?xC3eBmJvISA/uiRypQ/GBVUeUGx5L4BkpNcHzfPKh019mbCuhkX8xsPgO6St?= =?us-ascii?Q?/lzgRI2dB/U1pT6TPDSzzLt4FIuobU7YMXkBg9v2UWXOCES0DQ9lGSCgw/PL?= =?us-ascii?Q?Tuothx336cQLSOte06F5bB+H2Lw5q9wiMD3v/0KYQin9bh2VNuEgY4QbvhT/?= =?us-ascii?Q?O9g2Cn82g+qHKUjOd2NVGZSq+Y3NkKA+CZmKztjMLphI6hKrCoVwmrivaVRZ?= =?us-ascii?Q?i5c28ue3MAvvqscBCU7abNryR79fmTVYTUm+99RZTQppxiwpWkj8lViBNQa0?= =?us-ascii?Q?aMRyb0lD+uwX2E9j6ywnL5qBu4knuhPO5d2COvl92JW8nw4wvu/s/IJe8o6J?= =?us-ascii?Q?8+IxmEjlvfhMBYIB+8n1szdOQgCIEsjZS/7iB8B3fPXf2xamDMrCgPQ/WPJi?= =?us-ascii?Q?9FMfuyqJgfgkYOsFbZZOHC1qkZXX0mCUhlBSek7LJu4Ml+1gDn+SsOFgJw4x?= =?us-ascii?Q?rF0ftebL2djh4AovLYl9WoHn4wwyGQ53ipJ/9oSwQe+d2GUaQQqSaXTyQyzO?= =?us-ascii?Q?fMRZ5iTsGoGaZlRNdTioorWpLDCW6yEQjPxgEoEcpTdAXl9KCbvjziR8tU9J?= =?us-ascii?Q?a0QoP6QBoDci7AtiUT74XQ8r1L04nALtFwN6PmVAsQsDCrAAIy7W8W6wx5Ua?= =?us-ascii?Q?jsHEC3kkPQcTkG24vieinG3OXaPZGBaoMTjq2sDri9C5R/Z5+Mu2PeFleOJ/?= =?us-ascii?Q?Z02YtnKLH3z3fk2u3Q6+FIvGJKr1jkdHVFjWPY3MrzUfB+2fNUZ9qWS7Egt3?= =?us-ascii?Q?+qbZiV/HdJHGTLOJmgeoFF0+QkrXoPyqXNC2Tvm3X41vBaxOr3auxkhudkdl?= =?us-ascii?Q?X1m0V7DDy1ldiePCzP5gX97IjhYS2SoGrnceIQzj1m7Hs56W2XRGbp1JGgXv?= =?us-ascii?Q?yTBGKq6ZnCeiSj+OvxdQUVlLbRwgcr45LVwRInWq9ZBXOMYAak57aMe5Uz7j?= =?us-ascii?Q?sCQX2zUwPP5TGSVEEITaeqICkJRJYEKXZpWzDKeXgyu2oJF2Bj73iDxhY+z1?= =?us-ascii?Q?xDs2nepZGL29c3cTxm2rxE=3D?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR05MB2498; 6:mfPxtkbzqH7qgjzfKkMvBt/NS3ZnH/vZu1uL2LjnjQ?= =?us-ascii?Q?E8+di9zuLR43B//R8KGxwQdk2gf5Vqt5aPkFUsEBqj7yMgmijTNjf83SwNzx?= =?us-ascii?Q?UU5RTEk0v/BVJqpw0cIW4+YyHF23M7TKv3x6CD0sWId5Cm4U8S/UlO/u1rZq?= =?us-ascii?Q?wMD5gqxtdw/h93kMZx21uFs/0ORqrl5i5UwZ0THs30GEO8wdtRWOtvPmTT2I?= =?us-ascii?Q?oqPNwXhA/PLvvYgctEzL5+RgH28s4MYmLXgxKXq1ADhUYKDxwrUhaqTxZryz?= =?us-ascii?Q?J+prwhIy1vRREsPGscMsFpmmhWJ99I9XLI1S+82v3Qa9bTFPrVzOJ8YZzUyz?= =?us-ascii?Q?uQFtIjaWeYtRFxsiqzEnW9LSHWBN4WisUFXrdOyQDjG2DS76gRAq7fQXcDYy?= =?us-ascii?Q?TGF582FkTRFMq4r0OIe+4ENCFBbm9ptONA6nBai4SpliKgdCNgU0BffjUSsy?= =?us-ascii?Q?wDUY6njz1nVkb9+C138hJxKWCT8pLgbXCbbSHq2ecajr0JtqeTJsLQCObT0i?= =?us-ascii?Q?Li1hlmh8wUUxkWl9MpfrQYeXREJedL6Qjzi0sjpPMLPBiR3BCRG84EhQ1RwY?= =?us-ascii?Q?MkoQFvLqLZafOhGFwejaWg3mNijcEjmKQ+E6H9l0JuLWR3PMx7Bc5u2HzO9w?= =?us-ascii?Q?odbODvsKNvTQUdz2jg0NkGHMBGtGb5+4ZQ0fd4PpEyZS5aawnaEefK28o0Hn?= =?us-ascii?Q?M9bPokJ9MdnA5ujMjclcDpCR7pt/0N6JMx0Ij+ZQtfF1WmUJga2HcQ9WZP3g?= =?us-ascii?Q?UOAPdweDlmspbKO3swIKY/gVeukI+51hoJKz/ADYduEMxvSG4iWFyC/qi13p?= =?us-ascii?Q?vjsmycvxvHEMFZmHQC3jpGH/HZWXKuJZttnhVpLtNOli5J8lNunpaney/vf8?= =?us-ascii?Q?16oRCGd808JCJI8LwPkC1lf78gIMWCbmwghIYCTSjbXKIxbKTj4iOeDBW8/E?= =?us-ascii?Q?lZgqnXJl9pRWP0q5cq18J3OCpoSE5cqzzuqQMOpks22I0yqRed34kvmHSKD7?= =?us-ascii?Q?4iH3BsVMQn22xSs8y/98zQ?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 5:OTIPB1+rNEULZvWn7q/iIR7bb1sdNMM2SAvB45vSvXGLFkKKkdcLX4Vi74J9sH8oga4kFLPoAGBCgqWTbSZ3dDM1BrnJhdyUFE026OLC0XOYoeXUP9Q24cV5vxG5yllme1UDkP70f1cLU/x4ryjlxPanqNklP7l/KJT1lf2Lcscthv5XdUgkMbT/99tf4rxUikaElvDCLY09zJHf7B20kWBmGQGNM7laekxm8kCENYmQmsXwXNLqtd6wtk0IWVDiph8qAnsRQrQul/xrs+qNziRADxVIPt3MQUglPpE2ItN+0/VCyjLfrEQ/ZR42Wb2joQBVoOVobWj3CcJdcbHpPvwlfhg7L5e/MjbRQQOcB/1FVxKqFXMq6acyG3nangM843Bj5iyZg7mryTzwl38pni9mEHGjDS72HaruKpM62qiiQtbEEtJ+Un4UuzddPkaRJn6WE6tKP4NFh+lIn1as7sbusiMMgiv3DsYBE4NcaLjLWVkdhWRb4tSZQK7bq+mK; 24:enEwUgBWQhAKWsnYDV52ER625UL0RWBiJDh2+ZRxe6vw8J79F/DzNkABF61FcKaUG5PMNaEolOT3Z2WqCPflmVuhvz1qC8wFm3QgZnSbPrw= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 7:MFbURy5T30c+XsZiAONQD02BuU6rsdf89seCJaowYJje1Q4InmLb2/LapWnq7T8xrGhvDluT2zyUDcqYpUhPekpVIYq7ueTfJtonXeOdJln9htDbG/3KecH4UdKh3LzPJuH4btxGAtuUTQAvw/+DuaS7v1upHNW1FtMDignQoyOCPAAX6MAqhRwlcu8earj92UOuAwC0NZQJwDi+saHSDco3IO4Fk9J4EXj3sVEiwwaJ2qVPu68o7HXY9YL2UKsCIMhw5gGnna3pP9/um7elQB14nI7uA+DMZetwCXS69UYjuzYvY5yq+Do+Xp4inhU+cfMDhg3kmA7UG/gU75MhXLpQ1IPL2r+0VxLpRysVfHoJxtGltAp9GZh0PU4b9sEfy1JSDynueWR1Z+V6Dc0c6TZIkbhFvvu/XRQEOxD5FhKDxvnr/lOThsRSFd4PvdPJ550V1N4yZrKtCuyWPAocLUH4BmkGUilpVbwpJrpuLLgRAH2h5MoQl/uO1PuAN/Xj5teBrjdDHGR+zqdbTP9kbxiFKBvRTA3TAhFjwXi3l/Zuoj2kv/xYSCZNdnj4h5C4z6pd/g/0/OD/LLY6eUDzpgYUHp/Ydb80BWAxWhn330c4AbcjQfVBzmahtvxFa25m6DYKP036FCP+waXJKh26BxJYOizO60y70lzG9qqhjlox7SeSybRg/gQi6mMSRDnohlZF9dq+35WLQpiPy9auXiyNagL8GMvPzQoo4qPiBXCILejFfIO1tHE0PEHiBSXE3WMy1aaMu67HU8Sy2t0lP912SF0Wyrjz9lGSgmzf6Mo= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jul 2017 16:04:27.3482 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR05MB2498 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 16:04:31 -0000 Hi All, This is a significant rewrite from the previous version. Most of the = changes are refactoring for clarity and readability, but their extent = and volume means rfcdiff isn't so helpful; sorry about that. There is one substantive change worth calling out: the previous version = used a plain IPv4/IPv6 NLRI format, and communicated the reachability = state of tracked next hops using an extended community. The new version = uses its own NLRI format, and embeds reachability state in the NLRI. In = other respects, the intent is that the specified behavior is the same as = the previous version. Thanks and (to those in the U.S. and elsewhere who celebrate it) have a = good holiday. Regards, --John > On Jul 3, 2017, at 11:56 AM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Inter-Domain Routing of the IETF. >=20 > Title : Making Route Servers Aware of Data Link = Failures at IXPs > Authors : Randy Bush > Jeffrey Haas > John G. Scudder > Arnold Nipper > Thomas King > Filename : draft-ietf-idr-rs-bfd-03.txt > Pages : 12 > Date : 2017-07-03 >=20 > Abstract: > When BGP route servers are used, the data plane is not congruent = with > the control plane. Therefore, peers at an Internet exchange can = lose > data connectivity without the control plane being aware of it, and > packets are lost. This document proposes the use of a newly defined > BGP Subsequent Address Family Identifier (SAFI) both to allow the > route server to request its clients use BFD to track data plane > connectivity to their peers' addresses, and for the clients to = signal > that connectivity state back to the route server. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-rs-bfd/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-idr-rs-bfd-03 > https://datatracker.ietf.org/doc/html/draft-ietf-idr-rs-bfd-03 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-rs-bfd-03 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Mon Jul 3 09:08:08 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18902128A32 for ; Mon, 3 Jul 2017 09:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 5Qh5MBoJ6rvw for ; Mon, 3 Jul 2017 09:08:04 -0700 (PDT) Received: from mail-wm0-f49.google.com (mail-wm0-f49.google.com [74.125.82.49]) (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 7C322126579 for ; Mon, 3 Jul 2017 09:08:04 -0700 (PDT) Received: by mail-wm0-f49.google.com with SMTP id 62so173385147wmw.1 for ; Mon, 03 Jul 2017 09:08:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=26PHiKm1xWO8NvWylwt8ZXrUkZxqPFAk0BeJZwWmO4A=; b=hig+5zLT0G7n75XgP+BlUc2uN1IxzgPWpiMwfcJHMUC1pTQ4zc16HLsB/KOGws6fKp ERlNLBJ4G+RXL4wy87FpENWtIoAO1J3B3vkEAC0/UI9/OL6iCrL6+GZ7choUud5IvzaN /Y/zT99phx/WMGg0C3FJeLCtEq7SjSNkTM+I9HXFpGdMWOqY5R7I/KXZgVzaqZLqMIdz 3XfuCaYyPQo5de10CNaayvH7Y0RKWfUdyv2Nu/wkhb+kGxhbBBv4FI1Gt2HmjtgLhPSA Kjyx5AAhFYE/QpB9/eNNQzxamZ2kJG+Er1/iXDSZC4FUJH6NJRf1kAXMI+8kKdSIx03b 5duA== X-Gm-Message-State: AKS2vOwWGPnafPGkUVcS0YdDipY7n+AJtLwNrhJZVgUKWQW0n4qibCqa TcKaiTS/evV8/s6SKpRscg== X-Received: by 10.80.176.198 with SMTP id j64mr15126482edd.168.1499098082769; Mon, 03 Jul 2017 09:08:02 -0700 (PDT) Received: from localhost ([89.200.47.198]) by smtp.gmail.com with ESMTPSA id e54sm6959233eda.27.2017.07.03.09.08.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Jul 2017 09:08:02 -0700 (PDT) Date: Mon, 3 Jul 2017 18:08:00 +0200 From: Job Snijders To: idr@ietf.org Message-ID: <20170703160800.x6wcym2ma6jceqv7@Vurt.local> References: <149909741417.22786.4679459342587499122@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <149909741417.22786.4679459342587499122@ietfa.amsl.com> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: NeoMutt/20170609 (1.8.3) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 16:08:07 -0000 Hi, Does this version include anything related to my remarks in this message? https://mailarchive.ietf.org/arch/msg/idr/2LgFxEqjmWSVuAC5PM103pR7buU Kind regards, Job On Mon, Jul 03, 2017 at 08:56:54AM -0700, 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 Inter-Domain Routing of the IETF. > > Title : Making Route Servers Aware of Data Link Failures at IXPs > Authors : Randy Bush > Jeffrey Haas > John G. Scudder > Arnold Nipper > Thomas King > Filename : draft-ietf-idr-rs-bfd-03.txt > Pages : 12 > Date : 2017-07-03 > > Abstract: > When BGP route servers are used, the data plane is not congruent with > the control plane. Therefore, peers at an Internet exchange can lose > data connectivity without the control plane being aware of it, and > packets are lost. This document proposes the use of a newly defined > BGP Subsequent Address Family Identifier (SAFI) both to allow the > route server to request its clients use BFD to track data plane > connectivity to their peers' addresses, and for the clients to signal > that connectivity state back to the route server. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-rs-bfd/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-idr-rs-bfd-03 > https://datatracker.ietf.org/doc/html/draft-ietf-idr-rs-bfd-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-rs-bfd-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/ > > _______________________________________________ > 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 Jul 3 09:19:23 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6536712F3D5 for ; Mon, 3 Jul 2017 09:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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=juniper.net 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 oCYZkAEYZKE3 for ; Mon, 3 Jul 2017 09:19:14 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0135.outbound.protection.outlook.com [104.47.34.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8791129B06 for ; Mon, 3 Jul 2017 09:19:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Uc1rMgzgRu7HvYu9v23sdu7BT+Z9XJyY5oDYGEOfSss=; b=aYl5nSLeuZ3u7/0juMcE6xdX/95tOTE8/VThYKKPe2z7fyzGFjIL6/UId+XXnrT9nSjB/uN7oST+Qz+CDvOpSra3FFhgZeH/tgx4NaxYxa6e9+ENeGgWfI0rXt/8qw5iJDXRRDUHFDXf1o2iEP+7VyQzJfsJAaqBduZmhhHcxic= Authentication-Results: ntt.net; dkim=none (message not signed) header.d=none;ntt.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.34.54] (66.129.241.14) by CO2PR05MB2503.namprd05.prod.outlook.com (10.166.95.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.6; Mon, 3 Jul 2017 16:19:13 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: <20170703160800.x6wcym2ma6jceqv7@Vurt.local> Date: Mon, 3 Jul 2017 12:19:08 -0400 Cc: idr@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <149909741417.22786.4679459342587499122@ietfa.amsl.com> <20170703160800.x6wcym2ma6jceqv7@Vurt.local> To: Job Snijders X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: BN6PR20CA0018.namprd20.prod.outlook.com (10.173.158.156) To CO2PR05MB2503.namprd05.prod.outlook.com (10.166.95.149) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 27b15c3d-64b8-46da-81d0-08d4c22f3eca X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(48565401081)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CO2PR05MB2503; X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2503; 3:XQYbftf0VqGIuwHG02AcW8BJu14sLe/IE7jMI1I8IOMXZAQD/vj1uTs4dGHbKD03s3S33bjgmM32twxVnGG03OaW7I8e35vzKjslfIm/qEuOxZNZdlFXRYYFdYGwHX1IbNnTv/xLNE0Dull2MyjykjHNjFy++MadOqigAbCi3HDj9asfEMA0Cjqt/1k/7oTGzm1wMS02zgUx+fZQbZvjCDkgSQETtb5GQlsID2HEN080eU6Hpm1fJFWX5h6mhtDutX1HiEefHQzKBNvn0KTvJc3ob7ONDUH9gF+9R4JD+ae/yEM3UDvGZU1uCfzfVnIuhsfD/5yiJweSHHEjc+HyIMe9rG3vB1IpJ88saIteyayyNmO0GsNo9eYMUDEsUPu+0MgZMIjitAyzEYQPjgkaL6fBqvZUr50qZ+ILqNY7NA1ghc0S8JGwfJyhys5od+o0LcGiXxwjzaNSFipbHstDqMQ7gUk5TkFtLe7zgSLt64ZXybMVLCy6ifEvFChKpfscWUjutPt5zdZGkHcETB6hlArVk+NoLND1uqpjxf4eErkBHCLoL27QhajujK7BL/BLY+VZhZwZ6M6Y+p8HbasJen/B5LG52xVZTLOzfA+ZgsXQ/hBTPTT5uu3pwVd3xPk+qa99Cs0+cPygGWU+Q7/KKE1QJQxg9uLt44nXNPwVHG8Dbp4bGiXrpRwJeuhs79h7j8lmMe5l5zS5a6ehKjX5sqDmJoC0VtRtNRaL/rGVrZ49hu8nstCLz8abzBd5VIEy7wBRFhW35usfrKZ0c7gClw== X-MS-TrafficTypeDiagnostic: CO2PR05MB2503: X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2503; 25:IGUuLK4Z/5FGW07wNsUKUqXKWgWAjjWRex9/M2PXAe6vI+svRb17lzikr+1/PCis17azxmE+kk4yX+AufpNM+kZxbOD4EX1Pafn2B1H6Au5mvj/pnyoX66yD/93WTJMal2g0b45WKxPqai/CuGRYlDy+kOvqP5Ty/+6v5uZszJ67GGyw5sBVTE4oatw6aN3G9k288bEzdvMWmmAP6HXvqcZduYTAqfSgA+2m0Q8H8+mbBVBK0Kkf64YQKf5D40apdQoyMmfIHFyoJUKaTZvxJEeNzUWxHPzRiwaybatnnFRy4DotIk0r5+Svf7fLca3lQmcXtBrmsa9vZdO+V/u4okIZARjOkZHd3akbCRtO47Jz2PrWxdYaIW9xv41U9/NidNhS6qoyhKUTxe4PwRueXS997VA70Gben+M+tC9GBszZZ67UYlDY9CUba/9SzDQui+8biIHekHVXpMRbQSJAWim05XAaPYGe6wPcZBqGll7J+sYbeICOyX9FwhgBw2VdvcyfdQ+nbIghBkKP/nhEmXgRQm1pF9R4DeVtYoemZKTtvSTBN+v2ldnXbaIkdZh2fI8965Wjo+3+37fs89WZh3UjulRbFtNb+SZNo81nFu4MGzgJu/xIqotDSUaP16DhfqzuHWcfyhV6l42i1NpkH88dicRZBB/4SAgJ6KieNB3nh1qQ9vVKVh0HkvD+UalFsTi69IIqklEogT7Yai1kjkTA7sZypZy9lJEhixegWbGfiM+UrSIbcAWm45jj7Gl5aCjzgUcBb2Kydt5vkdXNPx2huTb6gIoDpkU5WPcLWB9FUFk4wFTCg79ZisjYB0Wh5F6kJBuOuLWAMcAHE8uIWtTBa/7ose+q9MTKG5hxaR8JIZI1HWEN1geZtQtV3nxAdsNIz68CEdW8GyG0sJ+gFZOCuW4BJAzABXXvT8V05Gk= X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2503; 31:8WeGwXqTwLQ6wU/ebv3J2FZtXuYHyqfBiZuZ+3dqi0qIm77BB4hd1gADuuh7NJou19xqjImPkmyy25EympWYYq8vSjz495f9t9tDKTx+J7h/X5HRjzjEFudzngbfh+fuqpumSXEketarxW05J6OLcQyP3n4DDv/lzyvxoOGWYLuTNKt/oJLnD5BgWc3nq7QU0Gdfjg5ThwQs7zktnU02dNrzJGNZ2OFPHqIu646UylVHqi+FPemxYFY1zA7fFX0gXIVeuSnH0s0HWjCIq3Vw6ldjZ6huqE8XcyFFpdzd5VfUTE8hqrFhKbBBDlPIE3KS9CeQ2nCm4sx4Ta4tbNNR888QcXrT87DVk3OmQfepuM4WwG8d71JztK5OSoUiBuZJLk0TDKo2HTC/g2vudmS7MoSGYH0GVCZLI3Ad6acynVeNELsB+yze2the47dK2Yx40VJx/46VI7GQOouVFCgEVrMj/HZxmpKbIRdB71SNriJI3iUleIwcsdLwBvcICl/71CgD0WUozcl6gkZ5koD5QzBNVzV76q3+7RmMLRZ11uWPEoJT4tqnAhDqw+g4ZCQ/RDAFeizB3uWY38Ba5S6XDnkuyNTNxwhLxCnMvtRpgBi9vXl1AHRREdVV3YcWutsEbyTAwZdfJ/chKoIlNB3s2JgEkh6jiIMmaz79QpCpBntU79MvXIwLwQnKItUGiyufD1F73x2e/jR687RMAtfzmQ== X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2503; 20:6nMwJHiITEdFSyHperIUWO8EP1K1blMscVahhCYrlJWCX1zz2lykUUEaeaQ8EAd0YZSIobRP/9mdm/s0cjdCUjx8tTDU2wP/evSSPR9y+609Kgc0q87fe2UbjWwdZpnQwXOR1hRrKGf4ffin65O5fx0TX5/kGyCn8meZcxoFu7iLHpb5XlucBLfzW9ryVmFIylsDIIEdwKwK4EucSf2xiVhLbDS3rQNxfONQreJGxZeoadQaDBNj+0dXjGNEngnlgzef1gEX5UT+vNwKXa+fQvb1rHrgV8q46HHBbTHq9rTUYZC2+4EyVex7WQe2pnTxF+oYbiwsHOM/Jz0CsCXLm8ky2Shxxm3wRDF2Uckd+Vt1hMjUrHkjaytiJe1k1QMHj4vbUzUF/N8mCEs9L8O3BIRkE3wjSniTDJbft+sdoYiVp+pLW/BzZzQZUN5epvh9ghLqVwdztod1wC6HAQrIFsPP65B/X6evfFvVnOXOezRZ/AOfy/695xb5apjiJgMrIMMKughPZdpJEgn12r3T9loYZeOsl+3TOHCGq4HViUXDOWL0Skf6i2bNI6wTCjsjH56qZQQyRRV7NJjEqTgGZhierCnDvfdMsYyVED1eZ6c= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278178393323532)(158342451672863)(236129657087228)(131327999870524)(48057245064654)(100405760836317); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CO2PR05MB2503; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CO2PR05MB2503; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDTzJQUjA1TUIyNTAzOzQ6NDliWUk1ZHBaTE1VUUtXOWFHcUhncFh0NWRj?= =?utf-8?B?enlWTnhsQVNleDZ1OGtrdTdSV3l1ZGEzK09PK1JPM3RLanY5RGJsOEdaNy9M?= =?utf-8?B?eC9HMHdpZjQxZDY3TDZEQnlvem1iQUtSbEpYNmt3Z0JFWUh6bFVCTmVJdUpj?= =?utf-8?B?cFVnUGg1L0owTHl0MEhqRHYvWFpId1FCVlAzVTlsUUM2ZEZEMytGS3A4ME1k?= =?utf-8?B?SHZCZndtYS9mb2wxaytOTHQwZWVDb0UvMzlXa2htQzAvWGdFOFlmaWFTZkpV?= =?utf-8?B?VDFmRmt6VjJnYmVFQU8wMktVNnMzd1lCN0d2bE12Qk5uUS9LMlJyYjIzZ3Mx?= =?utf-8?B?ZE9Lb21ZbC9zT21JRmMxNVlsOGpSRThZaVl3ZkhIT3RwczRiUGluWmplMFhP?= =?utf-8?B?djdKRWppNUFkOGpIaTF5aGcvbWdBeHRYeitMOHZCS01yRnB0K0VZZlBLQ0xI?= =?utf-8?B?cWNtd0pyK2V4VDl5M2tCd1d1WXh1bWpnMXNPL0FMRCtHbEk3UUZ2SWQ4eWpJ?= =?utf-8?B?aFpIVGFxdUZaTXFQRjE4MjRVU0pGbnp5NUdnYXRiUHAyM1lhUWVUSDA1ZHM0?= =?utf-8?B?TmFPYStGMDlyZTZJaVc3VDJaLysrYmhyamdNYmdNM1dveGluUWVOekJTMW1x?= =?utf-8?B?bytKN1c2dUVvZkVLY1hweW1wS1JpQS8rUzdjS05QTis0YTd2SXJ3cDlSRG9s?= =?utf-8?B?Qk5EUHJNNzRvYVptUzJaWFlyM1VFZzI0MXFXTGhRc01YUU80UlpEdlZ2ekJq?= =?utf-8?B?Q2RHd2x3UG8zMU5uN1VtVkcxcXhVaUlKTkJpZ3lNZkpFeDZRZmhlbHRuTXBH?= =?utf-8?B?RldyMUJIWXlMS2hIVllpN1grRXQvcUFpU0djNkRLU2NuTGpvQVRQcUlicThw?= =?utf-8?B?bDVqTlJLcHlGYXBTK0QxSm9ZWmlvZ2JxR1JpU2VxWWtxckJTMk9nQmdjTFQv?= =?utf-8?B?YWlGWDU5NzRyTWZTdVpaVFMzYjJrU2gxSlJEYllidXQwUHUwNVVUYklKWmR5?= =?utf-8?B?V2pmd1dFdjZlamlGR3dPRWFOSzZKRCsvUWhyUUZXZWJ5dnRnL1lFUDRaejV3?= =?utf-8?B?NXJFdmN6MHZlQVRhcTNEVkFLTWJrbUVhTVRCRlpwSjZ5dUp6YitwSjlSSW8x?= =?utf-8?B?emJrTDYyMHFWK1dJNWo5dzhsRWtDampmY1d0WTJzOXBINUNJb29wd3hPNW9R?= =?utf-8?B?ZWpwYkxsbHA1MnRQZE5qT1NuaStHRnR3Tm55VTd1NVlvUjJDZVNWMFFVdzl6?= =?utf-8?B?RVNSb3F2OVk0RThIVGRscEdqVlBtRXdNMGE5UEwzVCtNZHBWSERiYWpJeS9H?= =?utf-8?B?SFpoTEVJNHhmdHk0V1IxZmd1R0Z6UWsvaEZNUk9WUk53WE5QRkVWc3ZNNDBs?= =?utf-8?B?Y28wRGpDeXRjSGpxTUZ3Ni9GWlZrWUQ4NEpuS2FuOU9XalpNN0R0UWo1MjJo?= =?utf-8?B?dXlwNXVWMzFXUDY4S2NQb1B6R1JsRUVQRW9YbnlEdHJac1BVckxMWkt0ZjRl?= =?utf-8?B?cFFCRVpTTEVNQmFUSDl4R1piZTNwMFJwYVJoT1JEQmZQbjZPc1hROU1Hd0t3?= =?utf-8?B?N0JHdkVPSUJSYzEyNVZTeitCeER0OGJ2Sm1oWmlxcjhrTnYzNFZNOGVvYk9S?= =?utf-8?B?eWNaclF5b3RhM3ZIMkYreHZpMEkweTI2QmowdDRsWkVlb3pyNEdGaldvK2ZW?= =?utf-8?B?MzJNYkI4YkxZQ05wOVF0WmM0RE0rTU91SlJKQUxBdVZ6VjJHenJEQWFNdTFt?= =?utf-8?B?MVhqVzNxcnNSVmtQK3lJdERmZnVRZi9zUXRaTWUyNXM3WmdWRURKVUJITm1s?= =?utf-8?B?RlljaTJXcUh6SzltMmxwbGE4cUlIOHp6emJxOE1HOE1MOTlFQitUYWVIRmRJ?= =?utf-8?Q?efVTC/ZREo=3D?= X-Forefront-PRVS: 035748864E X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(39410400002)(39400400002)(39450400003)(39840400002)(39850400002)(39860400002)(377454003)(24454002)(23676002)(5660300001)(83716003)(966005)(305945005)(2906002)(25786009)(189998001)(53546010)(82746002)(36756003)(478600001)(50466002)(3846002)(42186005)(229853002)(38730400002)(6666003)(86362001)(8676002)(2950100002)(47776003)(6916009)(110136004)(33656002)(50226002)(6246003)(50986999)(76176999)(6116002)(8746002)(81166006)(4326008)(6306002)(6486002)(77096006)(57306001)(7736002)(53936002)(90366009)(66066001)(230783001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2503; H:[172.29.34.54]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDTzJQUjA1TUIyNTAzOzIzOm5YQzA2Y3NQekQvdGQ5VVRJNnY4YVlzbEs4?= =?utf-8?B?dUgrS0FTUHdRbEpYK095a0tVd0Vya1VVT2RJZ3lqUEl0TmhzSGJLWWlveVpO?= =?utf-8?B?SndaK2IvcDVGRW9YdUQxckEzY1FPS3Y1Mm1lamd2T09INDFDWktEZHhML0FQ?= =?utf-8?B?c0ZRVG8weTYzdmNHaHUybjNHSTMwZVdRUGorQnpmSEdpL3A5RGtlZlVUbndU?= =?utf-8?B?QXl5YXMvVkR6OWFuUWhrV0N3Qjl5Sld3dXpGcGlvVC8ySVFnQzJYaTNYSDFm?= =?utf-8?B?ME0xVUl3d1RhS2VsT051dldRREw4dGo4azZvSFZVVU8wckVNQzRvOTM3ZGJZ?= =?utf-8?B?dFNlc0xPS0xvWXRPTzQ0dXRQb3BqUExmT25tOVNkTHYwZmFQSjhpSkFKZjBa?= =?utf-8?B?NFVnOUdZMTFwMlh1S2luWVBDRldNclFWWGgybVNmYjBidGwxVk1STnBzNXk3?= =?utf-8?B?cGFWa1dkODRtZGZIT2FrT3RsbE5wN1FjblhLbVVMR0dVcDFScXJ5cGt0ZWdF?= =?utf-8?B?WVdDWVo3WlBXYnk3MzZURGVCMWlCZjJBeW16ZlNuVy9MYVh6VU1QVW14Q0NY?= =?utf-8?B?empkNlM2VTVjemExcnN5dXFWSXZBUk5HVnVqZWlWMUZhR1F0R25YQkNERFl2?= =?utf-8?B?L0RYWW44dTFoRTAwdlNMYVJOQVJIMVJoV1haNkJlcjVUNDZvS3lzZnFPd3lR?= =?utf-8?B?NGc2QWNvRkh6VldNKzhOSGt6MjFqVTJ4S1JNUWNwSldnN1JGbmlydWhUTnYx?= =?utf-8?B?enlwZVdYbW92SiszUWR3WnYraDEvL29yODJnbENvN09EZW1VLzVrdXQzTDFi?= =?utf-8?B?U1pTOVk0NVdSWUhXSE8rbzNUSkJzbHVrejVhUWd1ei9DbmdpVU5JMTJ2aGk0?= =?utf-8?B?UTMzaVhONDh1RnBLckM3M0ZmVDNtVzd2bG9lbjJUcXVyeGM0UnZGaUloRlBv?= =?utf-8?B?N0sxcVRGbTJPTVRtc0VBcFprWlF3K014dE1WWllsR1NYdXExUktVZTh0NlJl?= =?utf-8?B?NjR1N1o4bHZFT3hZa25CalBPbURlWm1zSzN2ZzQ3dkcvb2ZDQWJubi9NQVZn?= =?utf-8?B?b0Y1UzBqY0JvOGtpRGdUYTNMVDQrdktWcDFrT3hQRjU5eUdZVkpNZ3JYWU4y?= =?utf-8?B?MDlDSjM1UjJCUllsVTVGQWxnV3JvQ3NxMFhBRWhnUzVPejhOM2dERG55MVA5?= =?utf-8?B?Rml6N1dPaVl2ZHNabGh0b2wwdEJScG9aU2JhKzQ5ZHpuTW1YR1d1MUc5N2py?= =?utf-8?B?bGVZYjloeUJSSWxobm5BUm1CSGZuUkhBNTJ3SXdUbm5WTmpNcDRBRk1yU1dT?= =?utf-8?B?QjFBb2ZrNjBjYlYyT01SYnNLM1l4L2hVbW4zeHk1REZRRjBkVlVoaWN2dWYw?= =?utf-8?B?NHg0cit5aEk4V1M5b2lJdTFTMi93OW1jeCtJeGwvVVM5SGVOU0pibS90Sng2?= =?utf-8?B?eElFWll0UFJtT04zOWxMRDRaYnBwdDRjTk14cGd0TG1sbHlTcllzN1F1RTNl?= =?utf-8?B?VXRIcktsU1BGc29XUDdYb2hNdnRRcytiTklvVVdGOFlXZmZFeTg2VzQrK3dj?= =?utf-8?B?bWxUNmpRc0NOdXhOdjhNZ1FPQ2RuU3FFQVcrMEdDZTNvVTYrN1J0QS9XOFhq?= =?utf-8?B?SzB6bmhXdnV2Q1pmdWFrOGRKT2FSUG5vTFRtWjhRbE1VQkRLUGZZVjJoVUlk?= =?utf-8?B?NUs1dGRFODlhNzh1akxnREJFYnF6NDQ4WmxuLzBpZzF6YVJCdGh0WTRKZGZw?= =?utf-8?Q?w7YnpMIxQFfxwySN0716/ZkzqrBgqLyhabSQY=3D?= X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDTzJQUjA1TUIyNTAzOzY6QzJvcDBHdWhNN243eWZid0dHMGtxRjBwN1oz?= =?utf-8?B?S0NXYlByZWg0UnM1N24vZXdITG8xTEhjRzJYdW52Z3JDam5WSzFhbVlhOFFt?= =?utf-8?B?dzh0SE9ocVJ4K01OSzdaM2haVEpGMWg2bUFEWEpqS25RRzR6VDV4bXJuN3NP?= =?utf-8?B?VDhEKytRcTRjMGJkcWQwRnAwQXVaR1JlcjZVaVRBcTcvSUs0N0NCTDdCaWh3?= =?utf-8?B?STVQNmhjMHIxamo2dVoybU9uUDFkMFA2QkM0VmZ3RG5nWEVmc3J6c0FuUTYr?= =?utf-8?B?eWIvbm83ckNWaG5hWEkvK3RGRHFpWlU4OVN1eWtINnRBUzZGUnQ2eW1QMmlK?= =?utf-8?B?WU9LUVNaK0hmWHl6bTZNNTVTQVBnMFNqb1NqekFPTVVQSDZLeEVab2xmVHhx?= =?utf-8?B?MHkrREsranlydHFNamxwTkdkVWt4MURvdGpvQ2NNWnVyUDR0MTZJMzNUOWJh?= =?utf-8?B?VGhTSFZIOVpON2lzU3ZyWElVcjhsdi9jbFRjQmlNV3VaVDVGWEVhREd6KzY0?= =?utf-8?B?eU90OW1pd25Va2l2NEpMMjhvMkNVbHFnQXMrZ0RkY1lxdHBhK25qK1hxNHBy?= =?utf-8?B?VUcyQzBIM1Qrdit0cmpPNzI1WUI5VXpGZjBuV2Q3dmkvb3JwcGtHK3RnZ3pS?= =?utf-8?B?MGtzOTUzWUV4Rzh0eVNEeHdkMERSWThvWGFOZ1hkNjZVcFVuREFtT0trWmUv?= =?utf-8?B?OTd2VVJGRjh3STVESnBPRDVPS21XZ3RVNVBZNVI5OUJwYjVHOUxoT0hBdWU4?= =?utf-8?B?WDJzRkFRWjVFejhSOG03b1d3Zjk2UDdUaGZNNEVYaVl6a3hNQ1Jvc2lLMVA0?= =?utf-8?B?dDQ1WjZaNnRPL242RHdPZFVTOThtaTY2RXQyTmsxRTNJUk9TMWVqVDJUWGNh?= =?utf-8?B?SVZlZk1VY2tLVVlQb3c2QzV5b3IxaW5wTzdCcXNrem5MZGxDWXpFTFgrVzdz?= =?utf-8?B?SzVxcW5oN2ZEck9xRU5WQ0J6L0R6OE1BUHMvRlpKVTlRZzhvcFJVejBrUmdx?= =?utf-8?B?cDdQSWE5MVhuNU93WkpKZmExMGNJYWhJeklLWUowczZKaVBweGFNMDY1b3h6?= =?utf-8?B?RzZDSzhxMjBjTHBHZWgwR00zOXdVZjNtd2J5Rzc1ODRTUFl6MXJwWnVCQXRz?= =?utf-8?B?YkVuVUtjU0IzS2xYajBKeDlZaFF2WHFaVEVXeE5DNXRMeDNESm1PYVY0RTdR?= =?utf-8?B?eG9QaVFKT1dDRnQ4eXNjY0tHcVhCY2xlVlkzVUJXRWwyNithOUZZS2tiaE0v?= =?utf-8?B?dm1xQzd5OFJoWldmQWxJeW1ITHZWQU43U0NSMEFLSStuM0M5Z1RwVzFLWW5X?= =?utf-8?B?eXdTaktkM2JwTWxnK08zanVvT2kwNU41U2tQVjI4dnJ3d2Z0bXFGeHN1UGQy?= =?utf-8?Q?qAjTG4x?= X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2503; 5:w3cQtDdMcuC6Phlfqi3+BcgKVRDSn7JSA2Txer0hL7Bgyad/gp/jO5L4IQAuCmxC6ZQdVEpx/Yzh92yyi30J88gV0gYLRkEzFPWTxGlX1tlpXCVoQVvaCg1kR9FFLqvNcasBoFqalUxv8LTTIQR3fhOuKjaI84E8xtPzx5uyFVdMYsAMZU8M4wDEDemJTjm7vnjLevZDhpSgKyQclSatHt8HIKejiR9Di+eEqZ91GqUfiUQ5yLFqVdWY0D0/kpGCfh3o6Og/IaKjAnTcqNSSUGkBzfNUEkGYoqoPDClhaHmzMtzelykOQ4+o2StOTPS/+Z6lW5uYmWvoPN5acdmUEMOVgeDobqbCUNI/5GDtmi5EnsvhHQSsRfW1jQFVkGI/GXxEiSdtNeM+Fxk5MayM+BjsHh1xYkS9daNuX+RLyr6xH2R8fz/5TMAolcYSZrvPxVgeQNPhe1MxF05FHRku/L0tG1XPZ4TUEI6xT8lVdwY1+7M/rh9M0v49J4IORAOj; 24:gphUeyaL5oxIloip8Nm5x3+mmUPWbhG0gCDqCLgXVr9mnfpJ3cNOAWj8kkbS0GdbNvc8WBVfXtRcHzi0v4DGLRwU7cv2OH+aj70TqUWcmDw= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2503; 7:ltd2vcZPqR47/pOeTUrp+8YiNMAeZQvYHudazx2muWzAsmxS5mszy6b+I6Jp0FOuYL/zgDwDapa3Cq7C7tA+6uaDmql+3P6wmvmdhizOAXROmKk5lRGzFAtAHqbRRmzvD/o6QHdLS3M3FR46qqvJobH8Uiu5BrQAayskBkxZ3loqgCMB1yeQBEQueVFfulR+2MTScs3QRvZ5jcQVoE1Om4P/YFH1n7gb94UmE36HQqxDk1hU7OBmcy9bMaa+p42lc8sgC4nadV2sz6l+hbTmRE2nGC8Z/XM2Gii//X/5fTkz+cjPFcRZ+Rkg66CyWQN3zCHuc1VbXdZbCYTNVy8BeSIq3Ju2007th+0Jw169F9j5r4etzSolgTCfaaRNbP5TRbVk6DH16TungM72UztstqkpTLFrMQR017yNc8tGpJFuV5ip4m6BaXbX0U1a+PGLR+cCyyzXc6Tn/QjZrrFG/lzL5be4+m1J3Q89X1cSbsNFMD9+I0TLjINawlimqKXNR47N9qr1Tcjw4uqmyL7vb/kkarU/lwH/XC8A214USP/dzQcS6MHJJlAyVEnMiqze+b9tefXREEEDM8Bm5KEky5WIs55UJOhBluifTQBoRlz6J2AaOWIDMVxp+hk812e+LjqSZvarPHXdmQm1t7YZlV3tHMOkLjeULbOAEl3sj/q9ZB/M4B/wb+/Hj/UAuxIrQa45F2x3WEFAf32xSaegS7htS+o4Bo5A5GqV0thgaO3y10YgVPnMBwM+AfG8eoeaf26BMvoTm3RIzw4LfZEB0wX+SYxNH635FNqjgxpQTPk= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jul 2017 16:19:13.3308 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2503 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 16:19:17 -0000 On Jul 3, 2017, at 12:08 PM, Job Snijders wrote: >=20 > Does this version include anything related to my remarks in this > message? >=20 > = https://mailarchive.ietf.org/arch/msg/idr/2LgFxEqjmWSVuAC5PM103pR7buU Yes, at least in some small way: Throughout this document, we generally assume that the route server being discussed is able to represent different RIBs towards different clients, as discussed in section 2.3.2.1 of [RFC7947]. If this is not the case, the procedures described here to allow BFD to be automatically provisioned between clients still have value; however, the procedures for signaling reachability back to the route server may not. My summary of the major points in your your wall-of-text :-) is a. There is value in the provisioning BFD part, b. There is not value in the communicating reachability state back to = the server part. The paragraph above hopefully captures (a). As for (b), I (as an author) = didn't see WG consensus to get rid of that element of the draft. Since = that was exactly the raison d'=C3=AAtre of the draft, it would have been = pretty cheeky to cut it out without WG consensus to make that kind of = major course change (more than just an "optimalisation" as you described = it). A possible middle ground would be to more clearly divide the procedural = elements of (a) and (b) in the draft, so that an implementation could = clearly say it does (a) but not (b). If the WG wants to do this, I think = it may be easier with the refactored version. HTH, --John= From nobody Mon Jul 3 09:38:53 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5394F1204DA for ; Mon, 3 Jul 2017 09:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 YvThAncKECJ3 for ; Mon, 3 Jul 2017 09:38:49 -0700 (PDT) Received: from mail-wm0-f54.google.com (mail-wm0-f54.google.com [74.125.82.54]) (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 921D2129B15 for ; Mon, 3 Jul 2017 09:38:49 -0700 (PDT) Received: by mail-wm0-f54.google.com with SMTP id i127so114293616wma.0 for ; Mon, 03 Jul 2017 09:38:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=T0+DLVUbtyXSB7O6+IfHEoVuSyMtseurUpWJPiixXzY=; b=nCeGAFA3ls4Gb/c0eQhgLZ/ySNHguQ1ss7XtHDViO6Yjca7O337PRGTFHIN2Wk0mbA hjYR0Xyd9d2TkFiDlx3MqB3vx0GfBaQcpqPNiOu2VyErN8XplzIqJkpgdKTZsDB8FeDh M7ZTBLQdtygikMZE/fW+BdVVxAfOKYYLD5xMKeY1KkBTDB+iUjGT/NN4CDb/pSc4dH7s vUdNdMsF76dOOlPrryTlRcPCIwMfmsl3vqDWC3Tx2+SWCcDoqXa/XQ3nWW2wT68gih6H wfbslMs/kg1nOUGX5ZzX2/Pkj15h8ZqKA31UxgFOJpL1jOnRmaBNm0I8xlApI33M+0oD h3rg== X-Gm-Message-State: AKS2vOwpEQnjPoyc6EGOHWoaqojGBvmgUSBM+slrIPfrVLxnDTxYlHcU reAq6G/1wItxBeGBsyt3fA== X-Received: by 10.80.194.66 with SMTP id t2mr15729559edf.86.1499099928035; Mon, 03 Jul 2017 09:38:48 -0700 (PDT) Received: from localhost ([89.200.47.198]) by smtp.gmail.com with ESMTPSA id 2sm20241841edt.36.2017.07.03.09.38.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Jul 2017 09:38:47 -0700 (PDT) Date: Mon, 3 Jul 2017 18:38:46 +0200 From: Job Snijders To: "John G. Scudder" Cc: idr@ietf.org Message-ID: <20170703163846.224w6lxvbt4txqub@Vurt.local> References: <149909741417.22786.4679459342587499122@ietfa.amsl.com> <20170703160800.x6wcym2ma6jceqv7@Vurt.local> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: NeoMutt/20170609 (1.8.3) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 16:38:52 -0000 On Mon, Jul 03, 2017 at 12:19:08PM -0400, John G. Scudder wrote: > On Jul 3, 2017, at 12:08 PM, Job Snijders wrote: > > Does this version include anything related to my remarks in this > > message? > > > > https://mailarchive.ietf.org/arch/msg/idr/2LgFxEqjmWSVuAC5PM103pR7buU > > Yes, at least in some small way: > > Throughout this document, we generally assume that the route server > being discussed is able to represent different RIBs towards different > clients, as discussed in section 2.3.2.1 of [RFC7947]. If this is > not the case, the procedures described here to allow BFD to be > automatically provisioned between clients still have value; however, > the procedures for signaling reachability back to the route server > may not. > > My summary of the major points in your your wall-of-text :-) is > > a. There is value in the provisioning BFD part, > b. There is not value in the communicating reachability state back to the server part. > > The paragraph above hopefully captures (a). As for (b), I (as an > author) didn't see WG consensus to get rid of that element of the > draft. Since that was exactly the raison d'être of the draft, it would > have been pretty cheeky to cut it out without WG consensus to make > that kind of major course change (more than just an "optimalisation" > as you described it). Ah, yes of course WG consensus is important. I had assumed that the authors were expressing their 100% agreement with all my points through silence. ;-) I look forward to hearing counterpoints as to why it is useful to communicate reachability state back to the route server, and how the authors (or other working group participants) envision the scalability cost aspect. Kind regard, Job From nobody Mon Jul 3 10:32:25 2017 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A64C1316DB; Mon, 3 Jul 2017 10:32:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149910313008.22848.15997091431527017276@ietfa.amsl.com> Date: Mon, 03 Jul 2017 10:32:10 -0700 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-bgp-open-policy-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 17:32:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing of the IETF. Title : Route Leak Prevention using Roles in Update and Open messages Authors : Alexander Azimov Eugene Bogomazov Randy Bush Keyur Patel Kotikalapudi Sriram Filename : draft-ietf-idr-bgp-open-policy-01.txt Pages : 10 Date : 2017-07-03 Abstract: Route Leaks are the propagation of BGP prefixes which violate assumptions of BGP topology relationships; e.g. passing a route learned from one peer to another peer or to a transit provider, passing a route learned from one transit provider to another transit provider or to a peer. Today, approaches to leak prevention rely on marking routes according to operator configuration options without any check that the configuration corresponds to that of the BGP neighbor, or enforcement that the two BGP speakers agree on the relationship. This document enhances BGP Open to establish agreement of the (peer, customer, provider, internal) relationship of two neighboring BGP speakers to enforce appropriate configuration on both sides. Propagated routes are then marked with an iOTC attribute according to agreed relationship allowing prevention of route leaks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-open-policy/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-open-policy-01 https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-open-policy-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-open-policy-01 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 Jul 3 10:38:25 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9F181316DB for ; Mon, 3 Jul 2017 10:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 5pcpFs7nEegj for ; Mon, 3 Jul 2017 10:38:21 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 039731316AB for ; Mon, 3 Jul 2017 10:38:13 -0700 (PDT) X-Original-To: idr@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id E9BC441B94 for ; Mon, 3 Jul 2017 19:38:10 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id C27E041B73; Mon, 3 Jul 2017 19:38:10 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id BF5BB1718F; Mon, 3 Jul 2017 19:38:10 +0200 (CEST) Date: Mon, 3 Jul 2017 19:38:10 +0200 From: Gert Doering To: Job Snijders Cc: "John G. Scudder" , idr@ietf.org Message-ID: <20170703173810.GA45648@Space.Net> References: <149909741417.22786.4679459342587499122@ietfa.amsl.com> <20170703160800.x6wcym2ma6jceqv7@Vurt.local> <20170703163846.224w6lxvbt4txqub@Vurt.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170703163846.224w6lxvbt4txqub@Vurt.local> X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 17:38:24 -0000 Hi, On Mon, Jul 03, 2017 at 06:38:46PM +0200, Job Snijders wrote: > I look forward to hearing counterpoints as to why it is useful to > communicate reachability state back to the route server, and how the > authors (or other working group participants) envision the scalability > cost aspect. I find this a useful point for telemetry so the IXP operator can know "there is loss of connectivity between participant". Also, it enables best-path selection on the route-server to pick other paths if available. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Mon Jul 3 10:53:17 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D36CD1316E1 for ; Mon, 3 Jul 2017 10:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 yE5-jJENSDLQ for ; Mon, 3 Jul 2017 10:53:12 -0700 (PDT) Received: from mail-wm0-f46.google.com (mail-wm0-f46.google.com [74.125.82.46]) (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 8558E1296C6 for ; Mon, 3 Jul 2017 10:53:12 -0700 (PDT) Received: by mail-wm0-f46.google.com with SMTP id f67so62318586wmh.1 for ; Mon, 03 Jul 2017 10:53:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=0T3+RrI2HK11XqoJ3FX8vZ9OhvlYMlVVf09rK8Ns1Bo=; b=MxqtEmYZL9bhg+uH7uUkSULJ5/rcRgbqgAMHwxnb1B0BROncUjnZEjOF7OYDCfwKMC U2dJe0ZgY645aq4s5RwbTWb+gM3w0LHy//O3Fwig/gAFBM3bTE/EOkuA5+nmBUkTrzn9 QAdpdgkTsSp7iNc0zuTZrvpsZp2AevaQoKBB72K8T1bfXCgCBKh0WeKrFEj/gHyqgXBs MbgtjVi5t8wJumeKf8XUFHrsPgvCGvvJXIpD1i2CLgdt9xeZCqvnd7Dn2HpWrJwMfTC5 K4xXHR1EH7PgeMDGjIBVwfNGn2d7IhNzhak9PYqPHnwhz5VeCUOWdDC8oFOnUbLfwJ14 7J5Q== X-Gm-Message-State: AKS2vOyKPWFHuekcprAW6b2cJbgR+fd3YGDe3lAjN5ElOtBdp3fLqUDm S/jmZNlEJSKL069K X-Received: by 10.80.192.154 with SMTP id k26mr12280953edf.136.1499104390849; Mon, 03 Jul 2017 10:53:10 -0700 (PDT) Received: from localhost ([89.200.47.198]) by smtp.gmail.com with ESMTPSA id 4sm7717890eds.48.2017.07.03.10.53.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Jul 2017 10:53:10 -0700 (PDT) Date: Mon, 3 Jul 2017 19:53:08 +0200 From: Job Snijders To: Gert Doering Cc: "John G. Scudder" , idr@ietf.org Message-ID: <20170703175308.hembxkplaniz66wb@Vurt.local> References: <149909741417.22786.4679459342587499122@ietfa.amsl.com> <20170703160800.x6wcym2ma6jceqv7@Vurt.local> <20170703163846.224w6lxvbt4txqub@Vurt.local> <20170703173810.GA45648@Space.Net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170703173810.GA45648@Space.Net> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: NeoMutt/20170609 (1.8.3) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 17:53:15 -0000 On Mon, Jul 03, 2017 at 07:38:10PM +0200, Gert Doering wrote: > On Mon, Jul 03, 2017 at 06:38:46PM +0200, Job Snijders wrote: > > I look forward to hearing counterpoints as to why it is useful to > > communicate reachability state back to the route server, and how the > > authors (or other working group participants) envision the scalability > > cost aspect. > > I find this a useful point for telemetry so the IXP operator can know > "there is loss of connectivity between participant". Sure, but there is a cost associated with the distribution of this information. Additionally, IXP operators seem to be able to also retrieve this information in other ways: real time analysis of {net,s}flow data, deploying their own site-to-site monitoring (example: https://ams-ix.net/technical/statistics/real-time-stats) I'd argue that "it is may be interesting to know this" is a weaker argument then "without this knowledge the technology doesnt work". As it currently stands, all route server implementations are struggling with high volume, so adding additional load doesn't seem attractive. "Just because we can" doesn't go well with a resource constrained construct like a route server. > Also, it enables best-path selection on the route-server to pick other > paths if available. This is addressed through ADD-PATH / RFC 7911. By the time draft-ietf-idr-rs-bfd gets anywhere I expect that ADD-PATH is implemented on all common platforms. It would seem unlikely to me that we'll have BGP implementations that implement draft-ietf-idr-rs-bfd but not RFC 7911. Kind regards, Job From nobody Mon Jul 3 13:01:08 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6452C131795 for ; Mon, 3 Jul 2017 13:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 uIM7vnGnY1ZQ for ; Mon, 3 Jul 2017 13:01:05 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 1863A1286CA for ; Mon, 3 Jul 2017 13:01:05 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1dS7Wn-00020z-QY; Mon, 03 Jul 2017 20:01:02 +0000 Date: Mon, 03 Jul 2017 22:01:01 +0200 Message-ID: From: Randy Bush To: "Sriram, Kotikalapudi (Fed)" Cc: Alexander Azimov , IDR In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Idr] draft-ietf-idr-bgp-open-policy -- discussion X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 20:01:06 -0000 > I feel it would be good to reply directly to their posts and address > each of their questions/concerns. thanks for voluntgeering From nobody Mon Jul 3 13:07:48 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6A4B126D46 for ; Mon, 3 Jul 2017 13:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 aMNYln-FqJkw for ; Mon, 3 Jul 2017 13:07:45 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 D2CD3126DED for ; Mon, 3 Jul 2017 13:07:45 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1dS7dG-00022q-Qz; Mon, 03 Jul 2017 20:07:43 +0000 Date: Mon, 03 Jul 2017 22:07:42 +0200 Message-ID: From: Randy Bush To: Job Snijders Cc: "John G. Scudder" , idr@ietf.org In-Reply-To: <20170703163846.224w6lxvbt4txqub@Vurt.local> References: <149909741417.22786.4679459342587499122@ietfa.amsl.com> <20170703160800.x6wcym2ma6jceqv7@Vurt.local> <20170703163846.224w6lxvbt4txqub@Vurt.local> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 20:07:47 -0000 > Ah, yes of course WG consensus is important. I had assumed that the > authors were expressing their 100% agreement with all my points through > silence. ;-) actually, you atacked the style and tone of my response, so i gave up. we have long experience (can you say DataKit?) with bad failures and hard debugging of partial data plane connectivity interacting with lack of knowledge of the control plane. when my router's packets can not reach you, or vice versa, i *really* want to learn a better place to send them. remember, this arose from arnold asking me what it would take for me to be willing to consider using route servers. btw, doed ntt base its forwarding on route server supplied control plane at many exchanges? randy From nobody Mon Jul 3 13:08:51 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6201E1270B4 for ; Mon, 3 Jul 2017 13:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 grQzIiY5YPax for ; Mon, 3 Jul 2017 13:08:47 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 71AA21270A7 for ; Mon, 3 Jul 2017 13:08:47 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1dS7eF-00023X-3f; Mon, 03 Jul 2017 20:08:43 +0000 Date: Mon, 03 Jul 2017 22:08:42 +0200 Message-ID: From: Randy Bush To: Job Snijders Cc: Gert Doering , idr@ietf.org In-Reply-To: <20170703175308.hembxkplaniz66wb@Vurt.local> References: <149909741417.22786.4679459342587499122@ietfa.amsl.com> <20170703160800.x6wcym2ma6jceqv7@Vurt.local> <20170703163846.224w6lxvbt4txqub@Vurt.local> <20170703173810.GA45648@Space.Net> <20170703175308.hembxkplaniz66wb@Vurt.local> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 20:08:49 -0000 > I'd argue that "it is may be interesting to know this" is a weaker > argument then "without this knowledge the technology doesnt work". without this knowledge, betting my ass on route serves doesn't work. randy From nobody Mon Jul 3 13:17:07 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76EDF124234 for ; Mon, 3 Jul 2017 13:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 ZyCydcJ1lrB2 for ; Mon, 3 Jul 2017 13:16:59 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5504F124E15 for ; Mon, 3 Jul 2017 13:16:59 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id z62so61922628ioi.3 for ; Mon, 03 Jul 2017 13:16:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=orWo3YrGtf7wMJoYMUmLPdJoiOVT6wor6zeqYSj2xZo=; b=NbDP/lbSXBOtEQ25dt1KOAm7IxQxJfXZSoCotYF/UHIdphznsATtaSbyKaYvxq57EI +EbpcLfUanGkOppMyl7lHaxS1Dqkrf9c5lLYnvE72K/CAzcBTwHhKhcVxN/MF8fTiZ1j ChC4e5X3QSy7fzc7dhvRGG2n+Al4pGJzcIkeUXrftg1y2UCErXcmfFjKK7mus8ai1WY1 29FsrogwDtfpfTEZsqrpnni2uaV3MvVsR5L7B0X/IwZaGgK/umN401WomTrY4XjYS2H5 XMHn0HrCv7fPkHlMQ7G+uuvlR7dXoi4lm2sOZPv5TdAdUo26u378/P/Hke6i3rUh35ca 8zZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=orWo3YrGtf7wMJoYMUmLPdJoiOVT6wor6zeqYSj2xZo=; b=pTD6TIL97WjduBtgOemK1w49x7yb85avZj4O7lOO7qM3xpTgWhGOPlFbcsxvhCDDeM KSVqb5SSuyQGWAkiqFQC51+cUZf6BXtzeA5So6+KkrMdii7hf/mOf142PwQZdM3hwOqQ ZfTnx6CnC7Odjo10GOIYvNMYo8Wr6lV+5YHpdtJ/J2J1xJVDhEZaENAPLz95TA7+/wur bNb5mG98cR5mWk1ysIAvMvoW+dYVsJUyc/tBta7yw5tcLvM1ArRcX/bOi55VWWNxtkUq iLsfVDouiJivTCtr6O47J63hpARZ8cF88TjR/P8zjEfYFX0DbwbCvc56hK7q2zsWiTsy p77A== X-Gm-Message-State: AIVw1104OQBb1FS3aRDiYBLUm2LZsdFBSHeRXpEBSKEHVQKYC5dVOBJm kx6pVmnvpla5r3F906hkaEW/y6W7TBr8 X-Received: by 10.107.28.84 with SMTP id c81mr8335505ioc.186.1499113018640; Mon, 03 Jul 2017 13:16:58 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.32.15 with HTTP; Mon, 3 Jul 2017 13:16:57 -0700 (PDT) Received: by 10.79.32.15 with HTTP; Mon, 3 Jul 2017 13:16:57 -0700 (PDT) In-Reply-To: <20170703173810.GA45648@Space.Net> References: <149909741417.22786.4679459342587499122@ietfa.amsl.com> <20170703160800.x6wcym2ma6jceqv7@Vurt.local> <20170703163846.224w6lxvbt4txqub@Vurt.local> <20170703173810.GA45648@Space.Net> From: Robert Raszuk Date: Mon, 3 Jul 2017 22:16:57 +0200 X-Google-Sender-Auth: Jlo-8PhSgvkLDD8697C_Z66ZNNQ Message-ID: To: Gert Doering Cc: idr wg , Job Snijders Content-Type: multipart/alternative; boundary="001a1140986ef4545205536f72f5" Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 20:17:04 -0000 --001a1140986ef4545205536f72f5 Content-Type: text/plain; charset="UTF-8" The intention here has nothing to do with telemetry ... //RR On Jul 3, 2017 19:38, "Gert Doering" wrote: > Hi, > > On Mon, Jul 03, 2017 at 06:38:46PM +0200, Job Snijders wrote: > > I look forward to hearing counterpoints as to why it is useful to > > communicate reachability state back to the route server, and how the > > authors (or other working group participants) envision the scalability > > cost aspect. > > I find this a useful point for telemetry so the IXP operator can know > "there is loss of connectivity between participant". > > Also, it enables best-path selection on the route-server to pick other > paths if available. > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --001a1140986ef4545205536f72f5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The intention here has nothing to do with telemetry ...
//RR

On Jul 3, 2017 19:38, "Gert= Doering" <gert@space.net>= wrote:
Hi,

On Mon, Jul 03, 2017 at 06:38:46PM +0200, Job Snijders wrote:
> I look forward to hearing counterpoints as to why it is useful to
> communicate reachability state back to the route server, and how the > authors (or other working group participants) envision the scalability=
> cost aspect.

I find this a useful point for telemetry so the IXP operator can know
"there is loss of connectivity between participant".

Also, it enables best-path selection on the route-server to pick other
paths if available.

Gert Doering
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Aufsichtsratsvo= rs.: A. Grundner-Culemann
D-80807 Muenchen=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0USt-IdNr.:= DE813185279

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr
--001a1140986ef4545205536f72f5-- From nobody Mon Jul 3 13:20:19 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E220D1317AE for ; Mon, 3 Jul 2017 13:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 g3J7lv7Dp3DR for ; Mon, 3 Jul 2017 13:20:15 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE834124234 for ; Mon, 3 Jul 2017 13:20:05 -0700 (PDT) X-Original-To: idr@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id EF8E441B95 for ; Mon, 3 Jul 2017 22:20:02 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id C44C941B72; Mon, 3 Jul 2017 22:20:02 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id B63DD17561; Mon, 3 Jul 2017 22:20:02 +0200 (CEST) Date: Mon, 3 Jul 2017 22:20:02 +0200 From: Gert Doering To: Robert Raszuk Cc: Gert Doering , idr wg , Job Snijders Message-ID: <20170703202002.GD45648@Space.Net> References: <149909741417.22786.4679459342587499122@ietfa.amsl.com> <20170703160800.x6wcym2ma6jceqv7@Vurt.local> <20170703163846.224w6lxvbt4txqub@Vurt.local> <20170703173810.GA45648@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="+H3Lb6cBlAOEba9I" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 20:20:18 -0000 --+H3Lb6cBlAOEba9I Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Jul 03, 2017 at 10:16:57PM +0200, Robert Raszuk wrote: > The intention here has nothing to do with telemetry ... But it *is* telemetry. "Hey, Route-Server, I can see something that you do not see" - so the RS can do better educated guesses, and the IXP operator can go fix the L2 issue. If that's not an intentional aspect, it's useful nonetheless. (So what would you say what the *intention* of this is?) Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --+H3Lb6cBlAOEba9I Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAllapu8ACgkQ31bAZeTO f8WcwhAAqG4ZayLyJ1cssIgw2hC3k5K3kWtw1wENQMlVmK9zTkDyBb528r24qT+O q3KW6jUuerJe6S5KMHyU2iecI3OPKH7cdr/wUevwH+Qz5Ieb1Zsf7empNv1soiIG 3Ac4TjZ9waW0I1eV9T8pix38AB/nTpEZEQs20JDSQu2dhpOum9MNLAWl7vmvDZfL jlrBM6qez/4brtOSvU7sj3UdfZzAN4+wm1xtaZ3zwWu5QXlieNGglr4FDK/FrFGu 9ykhqFYbiYl8d6FcGKTpapxc53yRsi7Z4ADWwXgbOnVfVXXTeNA3VYkFmuUwIIuO 75Ahra352LoJQuT+5biGfMf3mqWkTNHPlV5HwY0HCigisC093pPueJPBjdv/KeM4 x7uXGm3O2rXhBMGtQgoXk3WuvWBjigpx+GB+MuVbU/ONHdGviYJ8URwfMrY4buf3 0L8znKqgXJRVX8opsjchkCxHk74TvWLfEDhwJRlTAySs/xbsQHpELe7OwYgSgrs9 FJ5dy8XlVVnyjYHiwhxwzssuRTyE8xCqVAmxXMK47IK28dtSaQbc9skx4IEBC1uM 8WRAqLCCdHCnTeHR/spM9isPAKl1Z0Gz695eVGsreEcNGFa94iauXVC8WyK+pLUj +KN2hki8039ZUamjDeAlGiVIqB272BmbkT2Qw0nfWTa+KoMJ16M= =TycD -----END PGP SIGNATURE----- --+H3Lb6cBlAOEba9I-- From nobody Mon Jul 3 13:21:26 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC511270B4 for ; Mon, 3 Jul 2017 13:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 AxGNi0bDSV3R for ; Mon, 3 Jul 2017 13:21:22 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CEED126BF0 for ; Mon, 3 Jul 2017 13:21:22 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id m84so61913235ita.0 for ; Mon, 03 Jul 2017 13:21:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=R6opqcLSijtziRiWqPu+9SA2TqdqZaI5WPGVhiTAp/I=; b=rM+o2rxF5I+ixiF0aRkWaN0oPOYFV3c4MESl/iTGHZGXDdCzc7KMHimMAn9vJ0Yz1f 7J5IJMrL+84ENC4oKecLLhb0XGAypMFeYa2JKIIKZMG7fBY1tjjZiHdiHXjxmzKAYGmH G7bLvXcZvESdjrQulaAYHSFvvamhRwozp245FkjG3vJKtJYvhRcGeOttMDoR48yQ8oqs KlGF5kLYB+9wrpe0qFOiLoa+KE6dcM8r3QqWfRxlGl9FUHsmwWh5SQFRmlwlXLHSVe9S VeV3hb1No/m4QuEOIvREy10fWVDdhNjFQx5sGl8LjKiwcR+WjaVQE+5GF896wf4z1Kii 6NQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=R6opqcLSijtziRiWqPu+9SA2TqdqZaI5WPGVhiTAp/I=; b=d2kChSYL8H/zBF5ETAytcX2ySWC8kFbkjZf3+9+ux79ttZU4QDMEOncdGD00WyteTP jM65OEKho3IqJ78XJSbR6QxXiNgMsmUp+2miS6kW4VXIqNwhWbBWKypUc+o9v9PnLl2H IpnqadXS0LmgXC/GiymkVdl6HZbjScIoEU3KqNuyLVkhohc/KTihPfmTt7b9BRVm9e9L S7H2zE2g4x5Zn0Ej5Pe1nVSAaPTKlZwgiA4ClBHRLVzLubMH10P6VU1HjvGyWf0yX0Ud XpHjZuJlL+TbCN4p2NB6QIxbUa0zPqrpL5izwmz1V3qOObGlTGtlcK6XhErVOD+RC2Dx LnHw== X-Gm-Message-State: AKS2vOxxwZwRi2axSabT32Fz3dVe4jMneGmwOCJUqTtn6OoR4S+j922g 0G31tDZUgdIihoWFcdFUibbOQer42l3f X-Received: by 10.36.150.133 with SMTP id z127mr35786705itd.104.1499113281740; Mon, 03 Jul 2017 13:21:21 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.32.15 with HTTP; Mon, 3 Jul 2017 13:21:20 -0700 (PDT) Received: by 10.79.32.15 with HTTP; Mon, 3 Jul 2017 13:21:20 -0700 (PDT) In-Reply-To: References: <149909741417.22786.4679459342587499122@ietfa.amsl.com> <20170703160800.x6wcym2ma6jceqv7@Vurt.local> <20170703163846.224w6lxvbt4txqub@Vurt.local> <20170703173810.GA45648@Space.Net> <20170703175308.hembxkplaniz66wb@Vurt.local> From: Robert Raszuk Date: Mon, 3 Jul 2017 22:21:21 +0200 X-Google-Sender-Auth: weT3vIEbu3Q0opxdQSAddsrKEsk Message-ID: To: Randy Bush Cc: idr wg , Job Snijders Content-Type: multipart/alternative; boundary="94eb2c08c4e2a2f01905536f82a6" Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 20:21:24 -0000 --94eb2c08c4e2a2f01905536f82a6 Content-Type: text/plain; charset="UTF-8" Randy, Route server should not be bothered with any of his 100s clients suffering from broken mpls base data plane bugs. It can send all client two (or more) diffetent paths and remain stateless. At this point I oppose to proceed with this document any further. Thx //RR. On Jul 3, 2017 22:08, "Randy Bush" wrote: > > I'd argue that "it is may be interesting to know this" is a weaker > > argument then "without this knowledge the technology doesnt work". > > without this knowledge, betting my ass on route serves doesn't work. > > randy > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --94eb2c08c4e2a2f01905536f82a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Randy,

Route= server should not be bothered with any of his 100s clients suffering from = broken mpls base data plane bugs.

It can send all client two (or more) diffetent paths and remain s= tateless.

At this point = I oppose to proceed with this document any further.
=
Thx
//RR.


On Jul 3, 2017 22:08, "Randy Bush" <randy@psg.com> wrote:
> I'd argue that "it is may be interes= ting to know this" is a weaker
> argument then "without this knowledge the technology doesnt work&= quot;.

without this knowledge, betting my ass on route serves doesn't work.
randy

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr
--94eb2c08c4e2a2f01905536f82a6-- From nobody Mon Jul 3 13:24:45 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56A1B1317A9 for ; Mon, 3 Jul 2017 13:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 14n6QpYjNwJb for ; Mon, 3 Jul 2017 13:24:41 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 717751270B4 for ; Mon, 3 Jul 2017 13:24:41 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id v202so17584066itb.1 for ; Mon, 03 Jul 2017 13:24:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=8x1pPjWgxXjYeqaYIImtd33dj0MPieW5DS/renylaJk=; b=rPU46bY+oUJ0Q/F9t1b4hdk6uqsC81qu5RTbp5H177Cd6PkPZpTh6lM8CnF9LR2SuR XJTMfqKX6L84PU1KIwmwv9L861psT+FY7uW9JK75rY6aacpm8aY6m1/oyMLp6Z/CT9iq e28W6tnoBovIJJwXRmNABt/TIEgx1g3nL2nQKMTbazHJz45GSyWqOs96uFmhOgNRVans htnCGS9Wse3bDUrfM0JZEnsKXYlrbhwRstD+HUgz5DylpWjD25dAF+ddVq7JJ99Q2jnH ne5jCOL9K72hfBkT6R4bVZJlyHc9FOFmWcTvXud2LexuFpby+fGD0h+Dm6lb85yJXhb4 X6Eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=8x1pPjWgxXjYeqaYIImtd33dj0MPieW5DS/renylaJk=; b=aJEhT0ZARvHn9NuUKv/H6fSq3EtbeCOOXtL8S4ea2M8ggWSrBh/0fjG1ohInp13ecu 511vaAAdIL35Nb18IiXLQ/jq4dEEAlAV3XMqPOX2VSv2Y5cNva8k3qG45x3fBKoly8X3 YY7kw0JCCedAzAwkLCtdUVy1GyBb1s6vIMjGlZlZ/Z+vpC2XYzac2n8H1Ks9IrBl+asY 2gSyzlq285ctZUmO9x9rSDVU/r4W69MIMeggvR+jtc0QTSNghMTwgKHk9hPXBT23SoSA Wh+4VqFWTOFCFsohr0awozm7mI1JsP73Z6/uI+cIcCwWLzvrV3q4uSSe0rrGqYMrDjRA arCg== X-Gm-Message-State: AIVw113p9Jh5qiUQ1r59OANblFnGZZzSHc6/mFyjumLq+h5BLqzgHMkY 6WHgfgfV4krS7Sc4mFsJyZGmewAICw== X-Received: by 10.36.207.212 with SMTP id y203mr10096316itf.18.1499113480665; Mon, 03 Jul 2017 13:24:40 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.32.15 with HTTP; Mon, 3 Jul 2017 13:24:39 -0700 (PDT) Received: by 10.79.32.15 with HTTP; Mon, 3 Jul 2017 13:24:39 -0700 (PDT) In-Reply-To: <20170703202002.GD45648@Space.Net> References: <149909741417.22786.4679459342587499122@ietfa.amsl.com> <20170703160800.x6wcym2ma6jceqv7@Vurt.local> <20170703163846.224w6lxvbt4txqub@Vurt.local> <20170703173810.GA45648@Space.Net> <20170703202002.GD45648@Space.Net> From: Robert Raszuk Date: Mon, 3 Jul 2017 22:24:39 +0200 X-Google-Sender-Auth: MnD8OqK9XkdMuJl-zzEyv0p6P4U Message-ID: To: Gert Doering Cc: Job Snijders , idr wg Content-Type: multipart/alternative; boundary="94eb2c05b7907eb6a705536f8e11" Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 20:24:44 -0000 --94eb2c05b7907eb6a705536f8e11 Content-Type: text/plain; charset="UTF-8" Is result of bfd a telemetry ? Interesting .. On Jul 3, 2017 22:20, "Gert Doering" wrote: > Hi, > > On Mon, Jul 03, 2017 at 10:16:57PM +0200, Robert Raszuk wrote: > > The intention here has nothing to do with telemetry ... > > But it *is* telemetry. "Hey, Route-Server, I can see something that > you do not see" - so the RS can do better educated guesses, and the > IXP operator can go fix the L2 issue. > > If that's not an intentional aspect, it's useful nonetheless. > > (So what would you say what the *intention* of this is?) > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > --94eb2c05b7907eb6a705536f8e11 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Is result of bfd a telemetry ? Interesting ..

On Jul 3, 2017 22:20, &= quot;Gert Doering" <gert@space.ne= t> wrote:
Hi,=

On Mon, Jul 03, 2017 at 10:16:57PM +0200, Robert Raszuk wrote:
> The intention here has nothing to do with telemetry ...

But it *is* telemetry.=C2=A0 "Hey, Route-Server, I can see something t= hat
you do not see" - so the RS can do better educated guesses, and the IXP operator can go fix the L2 issue.

If that's not an intentional aspect, it's useful nonetheless.

(So what would you say what the *intention* of this is?)

Gert Doering
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Aufsichtsratsvo= rs.: A. Grundner-Culemann
D-80807 Muenchen=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0USt-IdNr.:= DE813185279
--94eb2c05b7907eb6a705536f8e11-- From nobody Mon Jul 3 13:27:36 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B957E120724 for ; Mon, 3 Jul 2017 13:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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 B6IXYBNU9cET for ; Mon, 3 Jul 2017 13:27:33 -0700 (PDT) Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::22]) (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 B480D1200B9 for ; Mon, 3 Jul 2017 13:27:32 -0700 (PDT) Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dS7wS-0005wb-HF (job@us.ntt.net) for idr@ietf.org; Mon, 03 Jul 2017 20:27:32 +0000 Received: by mail-wr0-f180.google.com with SMTP id c11so239626179wrc.3 for ; Mon, 03 Jul 2017 13:27:32 -0700 (PDT) X-Gm-Message-State: AKS2vOx/D3l7KHYNx4EHJC7it3tRWJ76yfR4Ai2bp4H97Qr1Ixdu3hLu x3nt4AUm73a0Yb3foNeqv25XRWKJlSpO X-Received: by 10.223.175.37 with SMTP id z34mr34069324wrc.11.1499113651129; Mon, 03 Jul 2017 13:27:31 -0700 (PDT) MIME-Version: 1.0 References: <149909741417.22786.4679459342587499122@ietfa.amsl.com> <20170703160800.x6wcym2ma6jceqv7@Vurt.local> <20170703163846.224w6lxvbt4txqub@Vurt.local> In-Reply-To: From: Job Snijders Date: Mon, 03 Jul 2017 20:27:20 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Job Snijders , Randy Bush Cc: idr@ietf.org Content-Type: multipart/alternative; boundary="f403045f5644a7613805536f9842" Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 20:27:35 -0000 --f403045f5644a7613805536f9842 Content-Type: text/plain; charset="UTF-8" On Mon, 3 Jul 2017 at 22:07, Randy Bush wrote: > > Ah, yes of course WG consensus is important. I had assumed that the > > authors were expressing their 100% agreement with all my points through > > silence. ;-) > > actually, you atacked the style and tone of my response, so i gave up. I'm not sure I know what you are referring to. I sent feedback on the draft to the list (in a fresh thread) and only received a response from Robert Raszuk. If I discouraged dialogue on this topic in some way, please point me to it and allow me an opportunity to apologize for doing so. we have long experience (can you say DataKit?) with bad failures and hard > debugging of partial data plane connectivity interacting with lack of > knowledge of the control plane. Yes. But a route server will never be a full replacement for regular bilateral sessions, so that will always remain. If the implication is that the technology (full state available to the RS) is critical in the maintenance and operation of the IXP itself, it should clearly state so. This would be new information to me though. As a generalized mechanism, IXPs could snoop BFD traffic to disseminate the current state of reachability on the fabric, such BFD snooping would work for both RS peers as well as bilateral peers. A question would be "why impose additional reporting duties (load) on the RS peers when the IXP can glean similar information through snooping"? when my router's packets can not reach you, or vice versa, i *really* want > to learn a better place to send them. Yes. But how does statement show that the route server itself must be kept appraised on who can reach who? Kind regards, Job > --f403045f5644a7613805536f9842 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, 3 Jul 2017 at 22:0= 7, Randy Bush <randy@psg.com> wr= ote:
> Ah, yes of course WG cons= ensus is important. I had assumed that the
> authors were expressing their 100% agreement with all my points throug= h
> silence. ;-)

actually, you atacked the style and tone of my response, so i gave up.


I'm not sure I know what you are referring to. I sent feedback o= n the draft to the list (in a fresh thread) and only received a response fr= om Robert Raszuk. If I discouraged dialogue on this topic in some way, plea= se point me to it and allow me an opportunity to apologize for doing so.=C2= =A0


we have long experience (can you say DataKit?) with ba= d failures and=C2=A0hard debugging of partial data plane connectivity inter= acting with=C2=A0lack of knowledge of the control plane.


Yes. Bu= t a route server will never be a full replacement for regular bilateral ses= sions, so that will always remain. If the implication is that the technolog= y (full state available to the RS) is critical in the maintenance and opera= tion of the IXP itself, it should clearly state so. This would be new infor= mation to me though.=C2=A0

As a generalized mechanism, IXPs could snoop BFD traffic to disseminate = the current state of reachability on the fabric, such BFD snooping would wo= rk for both RS peers as well as bilateral peers. A question would be "= why impose additional reporting duties (load) on the RS peers when the IXP = can glean similar information through snooping"?


when my router's packets can not reach you, or vice versa, i *really*= =C2=A0want to learn a better place to send them.


Yes. But how do= es statement show that the route server itself must be kept appraised on wh= o can reach who?

Kind re= gards,

Job
--f403045f5644a7613805536f9842-- From nobody Mon Jul 3 13:29:53 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 569A1131455 for ; Mon, 3 Jul 2017 13:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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 kQMtGRPwvckb for ; Mon, 3 Jul 2017 13:29:51 -0700 (PDT) Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 F32BF1270B4 for ; Mon, 3 Jul 2017 13:29:50 -0700 (PDT) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dS7yg-000Ey9-G1 (job@us.ntt.net) for idr@ietf.org; Mon, 03 Jul 2017 20:29:50 +0000 Received: by mail-wm0-f42.google.com with SMTP id w126so178074937wme.0 for ; Mon, 03 Jul 2017 13:29:50 -0700 (PDT) X-Gm-Message-State: AKS2vOxRFMC8hyOjGB7M1BI6zjcpPZHiQDqp6ViWhp5/pKiTHZt6+RXo qbLsRmNrutnAmhUK3GzEpZyEWbXgFJQS X-Received: by 10.28.22.6 with SMTP id 6mr26576298wmw.124.1499113789096; Mon, 03 Jul 2017 13:29:49 -0700 (PDT) MIME-Version: 1.0 References: <149909741417.22786.4679459342587499122@ietfa.amsl.com> <20170703160800.x6wcym2ma6jceqv7@Vurt.local> <20170703163846.224w6lxvbt4txqub@Vurt.local> <20170703173810.GA45648@Space.Net> <20170703175308.hembxkplaniz66wb@Vurt.local> In-Reply-To: From: Job Snijders Date: Mon, 03 Jul 2017 20:29:37 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Job Snijders , Randy Bush Cc: Gert Doering , idr@ietf.org Content-Type: multipart/alternative; boundary="001a114702a4e09d0305536fa0ee" Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 20:29:52 -0000 --001a114702a4e09d0305536fa0ee Content-Type: text/plain; charset="UTF-8" On Mon, 3 Jul 2017 at 22:08, Randy Bush wrote: > > I'd argue that "it is may be interesting to know this" is a weaker > > argument then "without this knowledge the technology doesnt work". > > without this knowledge, betting my ass on route serves doesn't work. I don't follow. If the route server facilitates you in setting up BFD to all "nexthops of interest", the route server's job is done, right? Any RS peer has the ability to locally verify reacahbility across the fabric and route accordingly. Kind regards, Job > --001a114702a4e09d0305536fa0ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, 3 Jul 2017 at 22:0= 8, Randy Bush <randy@psg.com> wr= ote:
> I'd argue that "= it is may be interesting to know this" is a weaker
> argument then "without this knowledge the technology doesnt work&= quot;.

without this knowledge, betting my ass on route serves doesn't work.


I don't follow. If the route server facilitates you in settin= g up BFD to all "nexthops of interest", the route server's jo= b is done, right? Any RS peer has the ability to locally verify reacahbilit= y across the fabric and route accordingly.=C2=A0
Kind regards,

Job
--001a114702a4e09d0305536fa0ee-- From nobody Mon Jul 3 13:38:06 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85AED1270A7 for ; Mon, 3 Jul 2017 13:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 GXjIT26xCNmO for ; Mon, 3 Jul 2017 13:38:02 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 465B31200B9 for ; Mon, 3 Jul 2017 13:38:02 -0700 (PDT) X-Original-To: idr@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id E5D5541B94 for ; Mon, 3 Jul 2017 22:38:00 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id C166441B72; Mon, 3 Jul 2017 22:38:00 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id BE0D8175D5; Mon, 3 Jul 2017 22:38:00 +0200 (CEST) Date: Mon, 3 Jul 2017 22:38:00 +0200 From: Gert Doering To: Robert Raszuk Cc: Gert Doering , Job Snijders , idr wg Message-ID: <20170703203800.GE45648@Space.Net> References: <149909741417.22786.4679459342587499122@ietfa.amsl.com> <20170703160800.x6wcym2ma6jceqv7@Vurt.local> <20170703163846.224w6lxvbt4txqub@Vurt.local> <20170703173810.GA45648@Space.Net> <20170703202002.GD45648@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UhHRPELKZss2VAk+" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 20:38:04 -0000 --UhHRPELKZss2VAk+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Jul 03, 2017 at 10:24:39PM +0200, Robert Raszuk wrote: > Is result of bfd a telemetry ? Interesting .. Of course it is, if you tell the results of measurements A->B to C. Whatever measurement this is. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --UhHRPELKZss2VAk+ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAllaqyUACgkQ31bAZeTO f8U5qxAAqk1T9avjQQtRgJnSllUYE9nJR71dI69vwWRfThlhVyRd1L6EthvJdaZl VICEKNsocsbk8/mVupwFKAGwS13ApDIHG2GcqmKWHk6iIXZ8EWWGTXVg3SJQnAgu VU4O/sOZEvr4Dx2w1O9zpiFW5qvx0alWYUwIB66Tbi7EaztbhBW1cTuauBfqccij 2UZCLuZ4zjLDOUHtbrI0ZsouD6bg5xbq1osXOaZfYl0Jazk2grOh8V/pTZhlFbkt Cu6B9EiLYLD4maC7/Ze3M+wybEp/mPp813a6IALBEde16nZVUeI6Y5vTzktpkXYb FrNHZt8yAX728Car/ro1pQsU1JeQZVubv/GM+Ixo8fsCr6F9DVetUWqSsTpyPG10 33tXphCHR0hSF3cbfAFOyIbBHqf+66vMavVkg9Cdz0cfKhhzpuO43N4EpH6NV2ba cXZQ8TeqPUhrFgtD7O4UedIE0Iwb6H8/f3v6dPw92FSKu4uZCR6cwBzj1XcoIMXk Y/lrlmiZabIGztHRGHOydEnM/5TRGj49C4w6FeJ7cK4tDW5WpvJiz9XGygvPNTHH dJZZz9ibgwe4oTiLBJ5JFkb75rPgGxF2/t5Rj2BIanjrGwIETdw8O9X9QAnc2otm EaYCakN+HwnyeaqxdVqrlII7s00qX5FmvnqRQ74mij6ZAdAbVJg= =QqNL -----END PGP SIGNATURE----- --UhHRPELKZss2VAk+-- From nobody Mon Jul 3 13:42:34 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4F31200B9 for ; Mon, 3 Jul 2017 13:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.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 1GoOh-vRlMIY for ; Mon, 3 Jul 2017 13:42:29 -0700 (PDT) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFE4D128BC8 for ; Mon, 3 Jul 2017 13:42:26 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id r103so239799716wrb.0 for ; Mon, 03 Jul 2017 13:42:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pQWk48Df4j0m6QrsCgN5lNCEvQVhClK1MVwyzhbuxf8=; b=ii5Uwxce3IaHW98NvLucwnXfKDuihf572rOBzZjvAt3ADaFeUbfRCkCizE0BbH5Gs3 zHglHbDR8/wXardRK2GW8LjkiUIojxVfybs3nzNYJwG7UHSwqib5R1hD7i99TDY0k77z Aqz+iuVoj2QkVTIPNffVj4Z8XPd16sFwHynC7g9/9UpqghKeNIU0bUxRCn31XxpH+f4X gTxQzdTAqHGHMlqzmA+SSsZrnNd/dzLWu95qsyajElllzWM8p3mdMB8SD8CXLH+61E8h 5cCDGtwVwBZIhn/VLYGEcNcFYhbjWhtfF/hbWnjuu5JLON4JIFpvohjJq6kE/gBy28iG 0y1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pQWk48Df4j0m6QrsCgN5lNCEvQVhClK1MVwyzhbuxf8=; b=jz3a8gad3Mq1YUc79+muecBvodF9KbqS8/u11SevUm1w3Dx7iSZb/jacA90UGIVv94 /zkyBoa7yfPZfzyRUNd3v6cwNYs9tNAJf/zpH3RXIEpl36gElC78rcZnF0o85HoGTn3a fUheS5t1bMxihTvb7UFJQAuT0Resn8RmlkQJiA8sJyFXkufM+mN9Gh8hRSvpWHxDUXiY Axb2/acgmnA6mNV1uRGA+woiAF65BIq3FLM7h1+752au/oTiG/k9O4v4FYvytRVsb2v4 eT+W7MGsEDQbZLmAvpenpw1wR76958qVfnzCKgKonRKCpEutVjmK+YHqtRwCbCbBEjF/ nkhQ== X-Gm-Message-State: AKS2vOztrTwoNg3dMWvH0shwMttYaX38oV0YC4e5aOfAhVfE+LSEurHM N1YFc6oUZwaQ+aAgFSrCoiIn56RDgPDe X-Received: by 10.223.175.37 with SMTP id z34mr34091163wrc.11.1499114545286; Mon, 03 Jul 2017 13:42:25 -0700 (PDT) MIME-Version: 1.0 References: <149909741417.22786.4679459342587499122@ietfa.amsl.com> <20170703160800.x6wcym2ma6jceqv7@Vurt.local> <20170703163846.224w6lxvbt4txqub@Vurt.local> <20170703173810.GA45648@Space.Net> <20170703202002.GD45648@Space.Net> <20170703203800.GE45648@Space.Net> In-Reply-To: <20170703203800.GE45648@Space.Net> From: Job Snijders Date: Mon, 03 Jul 2017 20:42:14 +0000 Message-ID: To: Gert Doering , Robert Raszuk Cc: idr wg Content-Type: multipart/alternative; boundary="f403045f5644f31ee305536fcdbd" Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 20:42:32 -0000 --f403045f5644f31ee305536fcdbd Content-Type: text/plain; charset="UTF-8" On Mon, 3 Jul 2017 at 22:38, Gert Doering wrote: > On Mon, Jul 03, 2017 at 10:24:39PM +0200, Robert Raszuk wrote: > > Is result of bfd a telemetry ? Interesting .. > > Of course it is, if you tell the results of measurements A->B to C. > > Whatever measurement this is. You are right, any observation of a state can be distributed as a telemetry. What I question is whether it is useful (performance or scalability wise) to have route servers take that particular state into consideration when doing best path (or multiple best paths) selection on behalf of their peers. Kind regards, Job > --f403045f5644f31ee305536fcdbd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 3 Jul 2017 at 22:38, Gert Doering <gert@space.net> wrote:
On Mon, Jul 03, 2017 at 10:24:39PM +0200,= Robert Raszuk wrote:
> Is result of bfd a telemetry ? Interesting ..

Of course it is, if you tell the results of measurements A->B to C.

Whatever measurement this is.

You are right, any observation of a state can be distributed a= s a telemetry.=C2=A0

Wha= t I question is whether it is useful (performance or scalability wise) to h= ave route servers take that particular state into consideration when doing = best path (or multiple best paths) selection on behalf of their peers.

Kind regards,

Job
--f403045f5644f31ee305536fcdbd-- From nobody Mon Jul 3 13:53:21 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5129A1296B3 for ; Mon, 3 Jul 2017 13:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 gyGxfYfawp9s for ; Mon, 3 Jul 2017 13:53:18 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 19864129AC5 for ; Mon, 3 Jul 2017 13:53:18 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1dS8LJ-0002DJ-MO; Mon, 03 Jul 2017 20:53:13 +0000 Date: Mon, 03 Jul 2017 22:53:12 +0200 Message-ID: From: Randy Bush To: Job Snijders Cc: Gert Doering , idr@ietf.org In-Reply-To: References: <149909741417.22786.4679459342587499122@ietfa.amsl.com> <20170703160800.x6wcym2ma6jceqv7@Vurt.local> <20170703163846.224w6lxvbt4txqub@Vurt.local> <20170703173810.GA45648@Space.Net> <20170703175308.hembxkplaniz66wb@Vurt.local> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 20:53:19 -0000 > I don't follow. If the route server facilitates you in setting up BFD to > all "nexthops of interest", the route server's job is done, right? Any RS > peer has the ability to locally verify reacahbility across the fabric and > route accordingly. route servers are for the small folk who can not do full mesh, let alone add path and other fancy things. the rs IS their control plane, period. From nobody Mon Jul 3 14:10:31 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3A312F3D5 for ; Mon, 3 Jul 2017 14:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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 b2chU3vMH90Z for ; Mon, 3 Jul 2017 14:10:29 -0700 (PDT) Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 31D84130889 for ; Mon, 3 Jul 2017 14:10:24 -0700 (PDT) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dS8bv-0002Il-MU (job@us.ntt.net) for idr@ietf.org; Mon, 03 Jul 2017 21:10:23 +0000 Received: by mail-wr0-f176.google.com with SMTP id k67so239293398wrc.2 for ; Mon, 03 Jul 2017 14:10:23 -0700 (PDT) X-Gm-Message-State: AKS2vOy8OQSqgYSREQzMRzptZ7yHQmzFWaYZRHN0ZEn/JEYmLVHTpllr bOSAG39GapA8xzgwUwTWaf3ct09aHZIy X-Received: by 10.223.177.129 with SMTP id q1mr34191432wra.82.1499116222378; Mon, 03 Jul 2017 14:10:22 -0700 (PDT) MIME-Version: 1.0 References: <149909741417.22786.4679459342587499122@ietfa.amsl.com> <20170703160800.x6wcym2ma6jceqv7@Vurt.local> <20170703163846.224w6lxvbt4txqub@Vurt.local> <20170703173810.GA45648@Space.Net> <20170703175308.hembxkplaniz66wb@Vurt.local> In-Reply-To: From: Job Snijders Date: Mon, 03 Jul 2017 21:10:11 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Job Snijders , Randy Bush Cc: Gert Doering , idr@ietf.org Content-Type: multipart/alternative; boundary="f403045e7c7ae997a50553703163" Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 21:10:30 -0000 --f403045e7c7ae997a50553703163 Content-Type: text/plain; charset="UTF-8" On Mon, 3 Jul 2017 at 22:53, Randy Bush wrote: > > I don't follow. If the route server facilitates you in setting up BFD to > > all "nexthops of interest", the route server's job is done, right? Any RS > > peer has the ability to locally verify reacahbility across the fabric and > > route accordingly. > > route servers are for the small folk who can not do full mesh, let alone > add path and other fancy things. the rs IS their control plane, period. > If a device can't do add-path, can we really expect these devices to do fancy things like opportunistic "route server assisted" BFD to all next-hops of interest? If we operate under the assumption that these clients can't support receiving multiple paths through add-path, I envision a somewhat ugly cadence: 1) Hey RS, can't reach A 2) Ok, here try reaching A via B 3) hey RS, I can't reach B either Etc, etc The above scenario might look small, but often problems at IXPs don't affect (isolate) a single participant, but rather clusters of participants. A challenging aspect of IXPs are the "ISLs" between sites. If the RS is to receive and keep track of the state of who can reach who, it should somehow create a clear benefit that visibly reduces the load on the participant's devices. If the only benefit is "if the RS keeps track of this state, the participant doesn't need to support ADD-PATH (but only draft-ietf-idr-rs-bfd)", I'm skeptical whether I can get behind that reasoning. Kind regards, Job --f403045e7c7ae997a50553703163 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Mon, 3 Jul 2017 at 22:53, Randy= Bush <randy@psg.com> wrote:
=
> I don't follow. If the route = server facilitates you in setting up BFD to
> all "nexthops of interest", the route server's job is do= ne, right? Any RS
> peer has the ability to locally verify reacahbility across the fabric = and
> route accordingly.

route servers are for the small folk who can not do full mesh, let alone add path and other fancy things.=C2=A0 the rs IS their control plane, perio= d.

If a= device can't do add-path, can we really expect these devices to do fan= cy things like opportunistic "route server assisted" BFD to all n= ext-hops of interest?

If= we operate under the assumption that these clients can't support recei= ving multiple paths through add-path, I envision a somewhat ugly cadence:

1) Hey RS, can't reac= h A
2) Ok, here try reaching A via B
3) hey RS, I can't reach B either
Etc,= etc

The above scenario = might look small, but often problems at IXPs don't affect (isolate) a s= ingle participant, but rather clusters of participants. A challenging aspec= t of IXPs are the "ISLs" between sites.=C2=A0

If the RS is to receive and keep track of t= he state of who can reach who, it should somehow create a clear benefit tha= t visibly reduces the load on the participant's devices. If the only be= nefit is "if the RS keeps track of this state, the participant doesn&#= 39;t need to support ADD-PATH (but only draft-ietf-idr-rs-bfd)", I'= ;m skeptical whether I can get behind that reasoning.=C2=A0

Kind regards,
=
Job
--f403045e7c7ae997a50553703163-- From nobody Mon Jul 3 14:18:57 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3F612F3D5 for ; Mon, 3 Jul 2017 14:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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_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=juniper.net 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 T7ROAAsrr1t6 for ; Mon, 3 Jul 2017 14:18:47 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0122.outbound.protection.outlook.com [104.47.41.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 383DE12F290 for ; Mon, 3 Jul 2017 14:18:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4uwIKnEhXq727boINqeKMr9N7y8NUQzXOy6UaaiH5A4=; b=b4hVvdx4K667W4wZe6WI4pbhtfMk9vKDfwSBBz1BaXKNfU/CdhExdZRSNoru/xyza+FmYCxDhNhrzIffFzD8YMwQwRXJwIdiz2T1h8/UUxfW4t2V5/aTkSjbmOkfXHPcrex3FAcyE1HnRmwTETupLxwqhBksIbvDgh7eHpudMqk= Authentication-Results: ntt.net; dkim=none (message not signed) header.d=none;ntt.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.34.54] (66.129.241.14) by CO2PR05MB2503.namprd05.prod.outlook.com (10.166.95.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.6; Mon, 3 Jul 2017 21:18:43 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_0F7E64C7-D0C5-40FE-8CB3-E0EE52C9229E" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: Date: Mon, 3 Jul 2017 17:18:37 -0400 Cc: Randy Bush , idr@ietf.org Message-Id: References: <149909741417.22786.4679459342587499122@ietfa.amsl.com> <20170703160800.x6wcym2ma6jceqv7@Vurt.local> <20170703163846.224w6lxvbt4txqub@Vurt.local> <20170703173810.GA45648@Space.Net> <20170703175308.hembxkplaniz66wb@Vurt.local> To: Job Snijders X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: BN6PR20CA0050.namprd20.prod.outlook.com (10.171.181.140) To CO2PR05MB2503.namprd05.prod.outlook.com (10.166.95.149) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: e71b3606-f648-493e-1748-08d4c259161b X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(48565401081)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CO2PR05MB2503; X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2503; 3:4R1eg7026wP+qmwQep6GfFELhMm5NFc7pe+ZA5SseC+VJMmELAfMFwQKFkWS+avR/rHWOQJJolFE3ejCgN1mAGfTkaGwLWi8sckOCawTl8qZhdHyiYwhRSo8HbYyyWXu5ijJXoOpCMCzAtNdEvL23Pglh3X/PRkujDwAZFzmQcaX+5cnUYBMl1RV6lKrmRG2Hd1Zn8wyTgFFnUpSIlL7mP8rN7Zc1vcSBVogd35VaBok7Oxu35VmS8TqnCpvy26dwCkE/uPk8qL4zRHQsjKWFzngOe5f+EO3VdXFbBrxfcFZqVT7QdAgfJ8WonspQKVFgOyv/1/jbhZTFhdykBlSIRM5ZMgaDN5RNRn3ftCuDOtCR4EWE1MtzjPR9VShpbQscmwcSaf+jfvsfnqVBZ4iBPLhvqZaD8QWiDr2g2tx2qjqjzQMI9pGqgDXCLZgY8W1QWGSg2E6WrcsPoCIJ7b6fLRKn5EuwfssaARw5vABcvZXnwwhuYwUFQeKtMlth3qgMbTWS9JqDvhnoElZCUHdpZyY9V4XWgfKMVHgWO+q/AYXAA7n+jqPUvkJrpqakWAo61cN1NBr/PN7MhrThwEHLf+fQnwNY6w9cjgGml1qGQM5U57Jl7oWd3rZc5gl6gU4X1CMOFqGcJjxYXg9uSbWNX97HDObiC9WMaA+C1zmxifReMTCiGjnvxItwNpAB2ScExoN2ZRrbvth1tXbh5ML1zb50192J6BrWV/j6YoJfno9xReREpjn9qSKGGXHzYiHfXOsk4BkNo4Q2Tm4oYbvgA== X-MS-TrafficTypeDiagnostic: CO2PR05MB2503: X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2503; 25:5Cbgwp6VWOmOVql2J6v+nrlvN+dlycDP45Th6+JN2aZAJKFQRAydbBGQheROQ3QcHKHT5C7zKbyzinXjcJTEo7ybYAyasC/xguuM3M63wbXB9agIxdeXGqbRkCXttZgKZ2bqjFBt8/s4ytWUgI1Ah5shAed+ZPQhBcoMf23OBMgzosBkJanb1F6YXxUqtGcfZscuiuU3UoS4alywjG38DMWBNQw034rSxiE5HKzzKR6l4TBPaAdtm0UKFFOKIZ91WmbtVJl+MAZTknvNuHqSvAW04JI0Zi3auFS6gtIE2poQQeFR3AEAF/A+L20Tqumj1SbBfTcVVJcnfxCOzmQNkOyexbj6oddE1jssUVdR33FFqJ4CuzQbHZfSoF5GcULpI8Id8Hi0A4Cf40D/eZokGTDkftRP1AjCSQANqvF60us3VKcB6g+ZVxk+MX3yd5GD9YKAsa89EyDA7xBWeowOXFxVFgMvF3CuG+W5iGfRekBLShvbTDNNeqQuR7xOkyYfiIAcxFWKYF5iPUClCDwLDv+NWsxowPlAOhwN5OpDQfiDWwzgJxDddiQesqxobHfFn2/v1KEcCdEJagrVnAz+Zga5NlIahAmf53oA4r2Jl9zmvedPvhwY+7/eH+gOkLCBI09V6dG9VUZ2AvzfB48cod0iyJ4ZuSaSDLHzAnQ5e+3fslMv71MMbZaL0pw9OPBrI+f2z31GYYwQoCGcOg0vxjH5Ko7aKXkWSr0YFlt3AXz4Pp2s2052Yjk3b4CBxiFe9iBC7dh7tkoe1J5pQZ2T82LtPsEnpTiMsKSqRBxf6S+XtEtqXmUZjo5D8vrEZmOsRzn935ouOhbOdIPkgO0+MyHM717afR+sWOhZpqyor9gYwMSBg60HW4DC2prg5USHg67nbQdu0Uyo/R3CKQUXFJ5zLVDyHKFovhi+Whu0Aog= X-LD-Processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2503; 31:y2U/5zsND7yJDsyLWkfWcWK+qqWWnFNbsD/41I1efWGwCZm/9W8iQZWLfQGKFh7p/+sEaTsD2FHSCwtLx2mpecPsoK1Obud/fgr3djgG9oQRy8rJm0+BCcuQxbmcJsQ1CglJyPHtTn5ncxSXqc36MqiQKWcpr8yuP++FpLyBhGk6tetIJXm9iuCYkSu/3WDXNsqxf6Ro9inE3Rw/FZoorP3W90/y6iWjjC9XAKxT3V2CtF5kHjG0svtHFagkl+cWDNOSeRABqapfa5pubTt3ZjlopBbVQxzh4KbNplGFAyMZMGtj1oLsN8FQlyMLGov2vx45c8QME38F2VD4QP1tTcv1CIBy5ciNuHvibobbz2cjALfpFFlu5ZkUhBD9snnPn082aPYvbrtLSe9L60+4uecjsqOQC4f5HCoFXIveE5qSkzgJHxPc/zSSIHg+JbqjuKw2BpzbwjTV4h1VKIU6cGVLr9IIm67OgeOva10I9TNjsGCl5WMYBL1yEZzB8M/10OSUqETcMn14zoxiyZBGcrYJiPzlscd/qP1g2xjcDpbTpmeCoy62o3e1XTBFgAZ2pA6QzZm2uL+2qHlZb5phUptiZyF45VsYzYI52Zip0/6OxKfrzvyRrfw0DTyg+3QxwVFAR9gyD3aO71xbEzMQRIxh32nNphex47iutgpEet6PU8inyupzb586/6qhomnkZH7SJjq5NT2Z20U1CfSKoQ== X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2503; 20:U09khn3uN6MprM1I0qT4pqWW8yVCjTcY6D8CkKoEX+Cbg2CzG1U5YHC0HXC/xpUbLZgQ0o+L7y62Wv/zuPqqC3fa/C8sRAL3ED1Bfp6z7TP+U9ynj4AOLmHk3jnsrKu3ZffP5pbUA8dYLooVe55VJzzp7CorT2Hg9lrFQgZlKK+4/Wp1KMkl8eQ8Gpn+WVzxJOjyR59eXDj3EyeoApOhRFR+7pYHSjF7RE1+CQD4CmoPcw1kL3++CbkCxsigBUqG4wjJKQOoCR1Rho3UaRWTmJ0viY2ic1tLtCHnIVOWsVj84azMvf1bPNjLET5cJwEiuYVR6tF5d/XFWs2XgumpTO2Bycd5/PthX1xK1AX7s5zHXaLDLRPrr2OH29mgjeg5iDdL7+qAzBPnFbyiMpYzYt0M0Jnf8G+OHEsjE5fsxbHJk0mar+7d2pk39zVnnl2Zq9Ay1VFZr3h58hhFL6bs/O6ulnG0yVup3S0MaiBhdKh4jkfyhvR3t89SbuFAGQfXLEOQrsT4T+umwFi17eaWWKgWt20R2Gp5fhtitN9GqK2411gY3DmMSPPgbCTFQmSNtnAl96W6vyfLOwIu4N/nlLsuQL4rbVZc2O5dtWzRQYA= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(133145235818549)(236129657087228)(50300203121483); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123560025)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CO2PR05MB2503; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CO2PR05MB2503; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO2PR05MB2503; 4:iBDMVLEehrxqYTE1ytitemo4V+6dUz3u2XEleNyc2O?= =?us-ascii?Q?MdN+bTO6YdYS8wv1b2LYff0scH2V7bjn1FckNwmpBiRI7jmGOGEF7KUKZe5i?= =?us-ascii?Q?/yytV3V3GHjB1sdIqaVwHNhsNmbqLWNWTbMjEFGEr+o0aqb5UyWMU2g31+Gs?= =?us-ascii?Q?REZXnDJLxWpUYoUc5SuuZK733MsS6Qd376zBLpZHBwBJaL5a9TOt10Qzx46w?= =?us-ascii?Q?ioSuAgHQT98MapnJKaMH81i0wMo41PnrHFoWkdYPUCXpKVSuwGy/ZHlWn+hO?= =?us-ascii?Q?O2/xAuX4lguzYQUsAKDAPNZcrpC8oN0RqONH5cUup0UnB/UjXafuFSKAKNBE?= =?us-ascii?Q?pv06GT+PsnZ9BwPsb9Ds4rgGIo/Dto+mIxvLChpwjvGVURhGBeP1rIGnVIih?= =?us-ascii?Q?9GmwK5J3kZ7rDT2IF1+l3u8+KqHtfapvlTStU2Zfi9serwwQs+PvN0vsilBL?= =?us-ascii?Q?ah7z7RlT7qXbOU6Q8OI3SMnslh15vHlZDdv7fZ/HUtY67taNxVLu88fz1EiF?= =?us-ascii?Q?gcffbt8I3/BUDONSEQRD5dY6rsFBK4k5a26riXh/UXcgCLk99P83GyumrcrX?= =?us-ascii?Q?e2Ql90TFSgbVVsdC9+7nZTFRMioCuVWOT/vurk6ZvOuSfDtuwyt1RIPApqfm?= =?us-ascii?Q?kR/pO5owU8IOat+/FBwM9qDj8bkQ2WvqtpL08KIMryspwhaLB4fO+NLZVtgY?= =?us-ascii?Q?BlHh+racN6E5KEFKm6VVfId2aECpUvvIoJmXT8waK5Qf5HdMnu4nzD/tCjtd?= =?us-ascii?Q?U3xfsrc54T91q1Ise2hhkc5SMX3ZsUXlhwhGwGAH7wSldW0xA7+PGpJUG4Ky?= =?us-ascii?Q?rj8e2RAeCLbTblERzMVT39q7cdbVlCb6yYtiX4hYbIROZ1J4lWDXcZ5RSMhq?= =?us-ascii?Q?54Fib3cbSeU3UYhCHwA8OyLhww+kvW9KHCzns78C82yf6wO8JitqNf7pGdCC?= =?us-ascii?Q?owa85FdMROdr/MGZfcIaZW+FAKtKM3+C5RIhhp+EWp6ewDfrJloDs3tLLVhC?= =?us-ascii?Q?EapiE773QdNnnawJsggZwfJjECz5I7Ie8DwyMHbdp5ksATGAMCoSbRR0OsDw?= =?us-ascii?Q?QWBhjeMStO8GDrrjqwEZe6hxwua2r5jvPRikVrN35A8eiBpn+nzUPCoPxIt4?= =?us-ascii?Q?M9+y05FJgOaSA5eRWI0jp2kmb96oyUKC8rn02joQ9yasDhmVyMIKKGwXkbh8?= =?us-ascii?Q?ymQd0jZuhFzxUWc+YLgRGG7awPtCm7q4geqLL8w1B8CoOFdKbekzkRJaCsmD?= =?us-ascii?Q?6fcRMwPnJL13qqgzz0hDvG1t5O4aKPM8ivGQxBfx36ZjMwzIFfW4FqWnwCKv?= =?us-ascii?Q?+twQY3fMS7D6Ogd1hjyBc=3D?= X-Forefront-PRVS: 035748864E X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(39410400002)(39400400002)(39850400002)(39840400002)(39860400002)(39450400003)(377454003)(24454002)(5660300001)(93886004)(83716003)(2906002)(25786009)(53546010)(82746002)(36756003)(84326002)(478600001)(189998001)(42186005)(229853002)(38730400002)(86362001)(6666003)(2950100002)(110136004)(6916009)(33656002)(3846002)(50986999)(76176999)(6116002)(81166006)(6246003)(8676002)(236005)(4326008)(6486002)(77096006)(7736002)(66066001)(53936002)(90366009)(69556001)(270700001)(230783001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2503; H:[172.29.34.54]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO2PR05MB2503; 23:8UaL67wxAkxjNKlRMLdx0bptt2NG0V9Quudn41lL4?= =?us-ascii?Q?8mMezeaQPJg6abarUgXfJKFEKE0ab2v7dR5eibn35tb1VgTVM44gzapvO4WX?= =?us-ascii?Q?NIx3Xq2i+ajjbPJ1aIPeFSGsdwm0brOuK0k7O+z7sJtN21rh2LLuvlElT65T?= =?us-ascii?Q?bAJpmJ26sJ90/Tbes9vkf4+jd3QNuMzE0WIMyDNV0DemwadZUJc5McpFOZu+?= =?us-ascii?Q?M/wFc9Z1Bk9ek6bTkJl6VZNmlFsa50fv9/rOO2jcTNXFcdn8kRa+3yevqS7R?= =?us-ascii?Q?Mx+FsxsJ/FfHwlg1BGDF3hlHyXLJkg4t/mM7xlJTeeyPceZT7BE+vBbfpC1s?= =?us-ascii?Q?lqpLp3pjNWQ0L/OlTtuCYFXM1PInYB2GfVDm6A2Lm/eXrUa3DlA2a3/Xylmx?= =?us-ascii?Q?VIhxVVQddMqGaCTaiquJD6dW7GSswsToM+aoQ6oijfq5XJmafki1UwapM0pC?= =?us-ascii?Q?ZjM4ROViJKAB9HbtU/wBVYdEqzNYuaKDB7NnRwe7cTnKHoRBEw25j+wrD81z?= =?us-ascii?Q?GV7stAFDNPLtQUDNJAsBRrZXoRWZUR+sw2LjDqE/3Yk7a0NBSc7/mNK9MrPm?= =?us-ascii?Q?a7fugWeyh1jpcZQjM2mr7OsjIIgnU8g5BzNlr+vCj3xg+MiBAyM6ig46gDdn?= =?us-ascii?Q?tn85RjC2NF2GkUlz0KUleu07HoP/aLImUAUfZ77sFSu48RPB6BC/UQ7MZBLh?= =?us-ascii?Q?5NJLId2jlChukPhJItsYLRmyuF/Ncy85nHLG44ZY2Cvj6p1bXnxfVXN64v4D?= =?us-ascii?Q?Drek4C3cWDK3ZpujZuhdi7zX8MjT2g7tHCpi2yfk0XABtt5ARYpTCMMM5b6F?= =?us-ascii?Q?1C4e7eb4964kAd3JrxvJlBDXhDnwtONVwUwWSNksoUMih6TzLQ79euECFNSG?= =?us-ascii?Q?7PVKvirp04YQOLgLwCoLzEd59Xd8xj9qTEv3vU6cYFnxFbxbMfgIfxU+tSru?= =?us-ascii?Q?rS/FELwm2kEwqb1agZKvWLuZlztk//e/v6b+nKs5UlGLtSaju/Z5GxIXy4SN?= =?us-ascii?Q?jhbHiQ7eFNcTeX5k/0/hd9BNrWzxGSFn1fCiCoTbY3Pyddldtmq+AMN2LRMf?= =?us-ascii?Q?FXrlD3p+Ce8vO4Ld2SCcGYaLoVl/ZOwmqgcszNPYbrINbpzEhJODJP2n/nkP?= =?us-ascii?Q?sBmJh9Op2sYTa8MCHMdsGgxEHflGt/O5IQ8idd/95aZfTZ/qddJOzCP3fZ3H?= =?us-ascii?Q?YtHWFnOiu4wVMmSJwUymCX73lZUaflilMi/?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO2PR05MB2503; 6:AgISFX63+yFT5KK51HWwZIKi2i6h7I326eT5BaywHo?= =?us-ascii?Q?vo3A0CG/0IrUAR/0q57da/lMInuY4/cIj3KcihNkVEo2jahYrVXfa2c7xX+G?= =?us-ascii?Q?9AW+rn6BqIsalYyOFs6eHivy9X/CJ8opeFMTwVEnCIE6/dstREt7UZ2Q870Q?= =?us-ascii?Q?Wy1vSzAkrPGqMHtQp17dzeMpJK46P2bNNpN+LM1tQkga+cxv9QabAyQRkrRj?= =?us-ascii?Q?zTVN5wq8zxG+WFJyoe0RUSVJKNaotYap3OVHTgQRnoX158ZGUwOiblT5RDZ+?= =?us-ascii?Q?oCQNt9wBFS4z6K3lf09Gunn9phoM+gi59b9Io8kfNt1fRPFuply6xFaZO959?= =?us-ascii?Q?Y4ENUkJ8y8PzmE3PtIhnyQwQ3F2PJUEeDZ0tgmkk+1jREjiiwmbmazP0PxKA?= =?us-ascii?Q?i//Nr5U2N+6+5U5IQAkR76jfcGSGUwO9iX38miPX69kjMTk/BQSgo3ux9hxf?= =?us-ascii?Q?KhvBQp+oXIbhd7NLKbbnMaJrm/ysTJBWgfJzpDPjVBweg93rgB+Ark++m/wK?= =?us-ascii?Q?NnF5o1f+prxv0NldBLf4IX2JijZlIeQHjVUhBcQ+IURM1ylF5nWTjv71pwoF?= =?us-ascii?Q?hPjZ27jOxqxD614W2aFjMi29eFSYrxIX0rBQOz/Tvf2zq6xF6m4IFEYpzbhX?= =?us-ascii?Q?r2vRaVFoUWg5c1anAn1ECV/ljsf1V8fcxfwGXCAWc3LR4GE6En8xZ+iDh1xD?= =?us-ascii?Q?3VjZFptQPRG/0hoWnn8+ZtLAD1qYKSPyEDPSBKbKgIGGyunVkvBpaWp6Ov8Z?= =?us-ascii?Q?+lg+WMYruKJ7BVJ7KYdafrb1NPVkzoEPxFdRwvo4oAq18KomRcmL12q2k8SK?= =?us-ascii?Q?KBaCUDsvRGiBHq0MkIanBlDOEfOcNH7tUFtyN21RmiLQeLiE4Sdg+I66urvD?= =?us-ascii?Q?XTQgr7iI0pJOYUr4l+aWKT+mwE02aZw2Ilssj+gavjFwsCA29cKCFOVasKgu?= =?us-ascii?Q?k7rCd49jICak2k9GRfC3yvVPy3L5LO3l5L82xG3QJ+ZwXatk1gx2rb67HnyP?= =?us-ascii?Q?ZSmeqY0FBq596uPw7eUMvo?= X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2503; 5:JHxOyKJq8yuWOlyjlHMgEArSAtH+8v/xd87Kn0/pZnbG5FBUcU+Wyi0Jjkqtdev3gH3OLIzSvOtOqtpeAmLlfG6RT9WWXi3kaCe+9voMLdxyOXiAI1Ak6zaGBDARYFFQmxTDGkaACKu96mot3ZbTaZ7S0/v1jUFBMFLq4piuOFi5Mz6z2HzQUYtE4rIwD6izbxMn8T0P1J0BitoRgbrTVshMdDYhNAerMSLtkbhRx6Dz5jcUBNDucdLd9/spdP2QFedTPSwN0Pi4C+wHQScvylOC0LGBZh1u/Q1piGL6QHT9Qg4fQOLtMqh2SBw0nUaXeMKI77jQMpwFldrxOkq/V7DF4eDvxxw69TMA9Jj1iMOwUrua64ad5wvgfnxM9LXNdPgIUNjYaDBp7TLxmcpjlUQllWtjHVntvu4SrEastsXUd9NM4ZjLtobmid+gqCvulp5Er6YifWuHv5u+9qpQtN+hIO0vRDEJRaz3cZl3TGGe/oTHW6q9AIEprPmf8Blh; 24:48RS4sJO/RxEA9LuV73PU2A/stsrxsbI7UwqU9WvNkz1mcnxZKF4Sm8MkJfm6XfzvTY0Rw/SFUbNJHdlrc6uii0BbgsQj3YvmHB38nQUUD4= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2503; 7:MBeHhXnVsspMDd0/K6B49vddAd0s1GIdtk2n2u/hLmGLCgVHPq4emxp7hfB47ilwZpsA4M3/vQXsNlnyH6VbziKBfdxDr89LFV+YlTfseaXTOWYm/vMSu6SCOS4g9n2xryh1wGAKLhN9STn4vkbhCxymH9+kADqqy7PQp+sYow+JiMTeoJ04+1Kd/o+C82P4iQFF4oMyD5dHfLabbc0qJigJJWeN9t2ZnlC8kjzhCdIT/alhyLMBYeOIItPKo1RWhyOEfLATwJ2BVGg6V/enahfoq0G5twoCkSd7pXbcxSrUvkBzhsxuqtJ9/S55K6C9rw5NzAixL8CVpM4eMnfgFAGcIUFx3i6yZDy5Qjjkca6jxE6xHlx7EIwfKIOqRJdJS1z4PWUQnnzgSWl300XypLmR2vqZfYMu/W9WGy1ePRAS7bb9gRPTdcVADMsIB0yliuvL6qo2YPFbo2aybcwJdEbZafSES8ZyrIVjw/p6rquo+aB+hvwvo5bAzCbSoMgW5cj4Q2CEkOwwk9KU1ycMiQppjdJuSosu7oAELkZ5h1OCMWqFa3surCsjsY/VASgpBFt4JZWCscc2WLxPM8KX4d8IrnxA+kK9oFSX9+Js0tZbex6PFaT9+AgRG63B13jh4xGjrnb2basQHkHZRsoiD3NhHl1oKb12sBuIIcAmyK0CPma5XuT2z6WG4RYOre6GGgpftle4l4uVijUr0VBQNuoQKahMGPFqrwrHD1ooSdKBlQwM0fk1KmuM54vacf50VstPAtm6ax/AUmj8xgh4u0x91I38ULk30+quYOago9M= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jul 2017 21:18:43.7418 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2503 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 21:18:55 -0000 --Apple-Mail=_0F7E64C7-D0C5-40FE-8CB3-E0EE52C9229E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jul 3, 2017, at 5:10 PM, Job Snijders wrote: >=20 >=20 > On Mon, 3 Jul 2017 at 22:53, Randy Bush > wrote: > > I don't follow. If the route server facilitates you in setting up = BFD to > > all "nexthops of interest", the route server's job is done, right? = Any RS > > peer has the ability to locally verify reacahbility across the = fabric and > > route accordingly. >=20 > route servers are for the small folk who can not do full mesh, let = alone > add path and other fancy things. the rs IS their control plane, = period. >=20 > If a device can't do add-path, can we really expect these devices to = do fancy things like opportunistic "route server assisted" BFD to all = next-hops of interest? >=20 > If we operate under the assumption that these clients can't support = receiving multiple paths through add-path, I envision a somewhat ugly = cadence: >=20 > 1) Hey RS, can't reach A > 2) Ok, here try reaching A via B > 3) hey RS, I can't reach B either > Etc, etc If that cadence happens, they haven't implemented what's in rs-bfd, = right? So why would even #1 happen? --John= --Apple-Mail=_0F7E64C7-D0C5-40FE-8CB3-E0EE52C9229E Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Jul 3, 2017, at 5:10 PM, Job Snijders <job@ntt.net> wrote:


On Mon, 3 Jul 2017 at 22:53, Randy Bush <randy@psg.com> wrote:
> I don't follow. If the route server facilitates you in setting up BFD to
> all "nexthops of interest", the route server's job is done, right? Any RS
> peer has the ability to locally verify reacahbility across the fabric and
> route accordingly.

route servers are for the small folk who can not do full mesh, let alone
add path and other fancy things.  the rs IS their control plane, period.

If a device can't do add-path, can we really expect these devices to do fancy things like opportunistic "route server assisted" BFD to all next-hops of interest?

If we operate under the assumption that these clients can't support receiving multiple paths through add-path, I envision a somewhat ugly cadence:

1) Hey RS, can't reach A
2) Ok, here try reaching A via B
3) hey RS, I can't reach B either
Etc, etc

If that cadence happens, they haven't implemented what's in rs-bfd, right? So why would even #1 happen?

--John
--Apple-Mail=_0F7E64C7-D0C5-40FE-8CB3-E0EE52C9229E-- From nobody Mon Jul 3 14:32:18 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14DBA131460 for ; Mon, 3 Jul 2017 14:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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 skBHakyrTl_s for ; Mon, 3 Jul 2017 14:32:15 -0700 (PDT) Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 5EBCC12EBFA for ; Mon, 3 Jul 2017 14:32:02 -0700 (PDT) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dS8wr-0004PO-Sg (job@us.ntt.net) for idr@ietf.org; Mon, 03 Jul 2017 21:32:01 +0000 Received: by mail-wm0-f52.google.com with SMTP id w126so179088943wme.0 for ; Mon, 03 Jul 2017 14:32:01 -0700 (PDT) X-Gm-Message-State: AIVw111RKKP8Ns13L/BQbCklEkqeWPNVraZ51GfUhFbsWBE5VP2YT/PB 5KvQ56rkRM216BgYe+vcF5Mm7B54s868 X-Received: by 10.28.54.13 with SMTP id d13mr16990245wma.124.1499117520549; Mon, 03 Jul 2017 14:32:00 -0700 (PDT) MIME-Version: 1.0 References: <149909741417.22786.4679459342587499122@ietfa.amsl.com> <20170703160800.x6wcym2ma6jceqv7@Vurt.local> <20170703163846.224w6lxvbt4txqub@Vurt.local> <20170703173810.GA45648@Space.Net> <20170703175308.hembxkplaniz66wb@Vurt.local> In-Reply-To: From: Job Snijders Date: Mon, 03 Jul 2017 21:31:49 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Job Snijders , "John G. Scudder" Cc: Randy Bush , idr@ietf.org Content-Type: multipart/alternative; boundary="001a1143678e4a14c30553707feb" Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 21:32:17 -0000 --001a1143678e4a14c30553707feb Content-Type: text/plain; charset="UTF-8" On Mon, 3 Jul 2017 at 23:18, John G. Scudder wrote: On Jul 3, 2017, at 5:10 PM, Job Snijders wrote: > On Mon, 3 Jul 2017 at 22:53, Randy Bush wrote: > >> > I don't follow. If the route server facilitates you in setting up BFD to >> > all "nexthops of interest", the route server's job is done, right? Any >> RS >> > peer has the ability to locally verify reacahbility across the fabric >> and >> > route accordingly. >> >> route servers are for the small folk who can not do full mesh, let alone >> add path and other fancy things. the rs IS their control plane, period. >> > > If a device can't do add-path, can we really expect these devices to do > fancy things like opportunistic "route server assisted" BFD to all > next-hops of interest? > > If we operate under the assumption that these clients can't support > receiving multiple paths through add-path, I envision a somewhat ugly > cadence: > > 1) Hey RS, can't reach A > 2) Ok, here try reaching A via B > 3) hey RS, I can't reach B either > Etc, etc > > > If that cadence happens, they haven't implemented what's in rs-bfd, right? > So why would even #1 happen? > Perhaps my understanding of the draft is flawed, but rs-bfd (currently) specifies the concept of relaying information from RS participant back to the RS about who the participant can reach or not. So #1 can only happen if rs-bfd is implemented, and the cadence would be a logical consequence if add-path is not supported. Kind regards, Job > --001a1143678e4a14c30553707feb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, 3 Jul 2017 at 23:18, John G. Scudder <jgs@juniper.net> wrote:

O= n Jul 3, 2017, at 5:10 PM, Job Snijders <job@ntt.net> wrote:
On Mon, 3 Jul 2017 at 22:53, Randy Bush <randy@psg.com> wrote:
=
> I don't follow. If the route server= facilitates you in setting up BFD to
> all "nexthops of interest", the route server's job is do= ne, right? Any RS
> peer has the ability to locally verify reacahbility across the fabric = and
> route accordingly.

route servers are for the small folk who can not do full mesh, let alone add path and other fancy things.=C2=A0 the rs IS their control plane, perio= d.

If a= device can't do add-path, can we really expect these devices to do fan= cy things like opportunistic "route server assisted" BFD to all n= ext-hops of interest?

If= we operate under the assumption that these clients can't support recei= ving multiple paths through add-path, I envision a somewhat ugly cadence:

1) Hey RS, can't reac= h A
2) Ok, here try reaching A via B
3) hey RS, I can't reach B either
Etc,= etc

If that cadence happens, they haven'= t implemented what's in rs-bfd, right? So why would even #1 happen?


Perhaps my understanding of the draft is flawed, =C2=A0= but rs-bfd (currently) specifies the concept of relaying information from R= S participant back to the RS about who the participant can reach or not. So= #1 can only happen if rs-bfd is implemented, and the cadence would be a lo= gical consequence if add-path is not supported.=C2=A0

Kind regards,

Job
--001a1143678e4a14c30553707feb-- From nobody Mon Jul 3 14:40:22 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3ECF12F3D5 for ; Mon, 3 Jul 2017 14:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-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=juniper.net 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 tCCcf3ryAmiQ for ; Mon, 3 Jul 2017 14:40:17 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0102.outbound.protection.outlook.com [104.47.37.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DA97131562 for ; Mon, 3 Jul 2017 14:40:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5r/mlmhAQ4wAUQDlLD2m7DGjFlnH4a1J832zKbKmldE=; b=Mw4h2gjs1QeN+ptv1fJhHyA/ry2ybZToYO1KSMhX6zJ+SKQrqt+JLOOGP9snJBMsk++X+lNWcPx0bd7EMkqrNuIAthjNf0Y3uMV9kxru/uMwdqpvvdKf7CDOIIDGI79xuwE+d+GTi5pzqYYAMpV5L8DogDyHqjt0ZdM78VzOEvk= Authentication-Results: ntt.net; dkim=none (message not signed) header.d=none;ntt.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.34.54] (66.129.241.14) by CY1PR05MB2506.namprd05.prod.outlook.com (10.167.10.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.6; Mon, 3 Jul 2017 21:40:00 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_EE2F5E1F-288D-4750-9E2C-7B474F3D302D" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Scudder In-Reply-To: Date: Mon, 3 Jul 2017 17:39:49 -0400 Cc: Randy Bush , idr@ietf.org Message-Id: <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> References: <149909741417.22786.4679459342587499122@ietfa.amsl.com> <20170703160800.x6wcym2ma6jceqv7@Vurt.local> <20170703163846.224w6lxvbt4txqub@Vurt.local> <20170703173810.GA45648@Space.Net> <20170703175308.hembxkplaniz66wb@Vurt.local> To: Job Snijders X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: BN6PR10CA0045.namprd10.prod.outlook.com (10.175.102.159) To CY1PR05MB2506.namprd05.prod.outlook.com (10.167.10.27) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: cf4801a6-015f-4fd2-66bf-08d4c25c1051 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(48565401081)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY1PR05MB2506; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 3:+OmPeHG/m22Kcy3lQuRtarNIzCoKGFwR8HluLDc54xhWcJWqb4igVNaegm0mcN2NMTgHrhfR75v0YH2l573q0rlm56lM0s8RSpP7kSxUEZWX6K5q53YoCSWW30rCoLc9/sh13aW/Sz2IZA0UzbwZtVRe4WCkKfRjoKFPqG5mp+4WfIFffbwp8FyvOP9SvYIBkFD1yMAU+RqhA4UlhWyDmLChnSB16yxaWplHIAIHFFkuUyt9pLDQjl8oeMcrssVCv+alB6ik4+dP6uTwbchJL7wSiprmSkxxxB1kYI1mb/YPaVxjtQu4Kk3ch6U6egaaGE0N7zsF/wf70NBEKCVz1//cndd/AAtRLTJSYKesjdUbGYaV0FMQjJfx21a88ea9KVvHnqpOL5RByDtYYx0IY+ep+/C6JDzCkeP/NTnTZGrDnHJd4n/YeCYPAY7/i5H3gX9JyyZ0WRtOuh9xtIJDm33Tpi2A4i2prGK7D75prRsCevFkEqJhWweZGIOzxjJGMknCqN43sySVMhQQiby9sGRIArGlMV2ZIB82ZAu3ZuBJ7m1yVMelEj9wJtOSvtws8BxGjteeEIWJqEgupwWmr5ggxgFuCEOXVR9LZKQRZDlzYnFJPfG+vGvhjjnkocu46ALEty/SUbnN12cZi9WgQHsJ4z2DEgqlp9F/Rgpo/w2Ske33PZJwqDhnhT+87dn91HhkcDD03BOTBCDYsWnSN9Si+9fdddaE/8u6EWpNIo4xFkfvreYAv7bGOCq3APJCDMKhnOVLebowaPF9WObjTw== X-MS-TrafficTypeDiagnostic: CY1PR05MB2506: X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 25:8zWhp87rByGaZNOdfB8N/TQA3JuzSqNqzfwgA9wWLUI5UJtWdi5sMgR6ouECObdysNg5LfJYLTb+IDat0K2PcguYTOHkUn284BFj1Sd0md/hXyEYlOlu8G9o5E3tFoiNBJLwPWfXAWqXcsb6GE8zjlHGJ3YyNF4r7ZKIpSUocf8A7M7HAcqUlDurxXR2YkGTeCYSl3k9yWTE3gLVhTB1Ev5ElkzJw2N9bucxiCrWV5hKMA9LctN1xrOCa2t6aIXFukvKPfOH51T9hVinl9Ari8ozyd8HHYieihq0LPnSLhbR1rA+9tuuM4ODjANBBVkTTPKJlcE4tJi9KIcEejijpdrN19ix+m5beiLRt0En297y+EZ4c8smWS8jDew/kFnqkFm6Ukfb1JPcuEWxlzjsw7ilMFRKfw3KooOVIlbzDACirgYESH3B/gTqNKErfRCdtQqFrSccwVew8jLYSjfsyyxsLcodW3GbSNpxJ2r+5X4+RzM3FV2L1XYiB35/7Ekejcfe0bouxzms1NFDktAWyu7j1/kMUtO8MdyHthkG5dxoWopvAAv4HEvBE6c6FQcm219BBVyabX67/53inURJUB3RIYXZukyBWUHFzhQNLvc5x9DaD5Nx1FRY2LQgOaVoaLuRf5RXsP8WJhbb9ny1LHiSEHAKp+kLYoBP92SNYu5cPG3B8ACg0ajwaFwwBPAmtXZZRHqo+2TEk1nheZFIA7/voR6nTE3S+Pa8sDn84FmZlC4fabJOw8lMDC4fu/tieZG1RApdZQDSYWblH1+CECueyZqlPJzDsyE7BNtIi8i3NHn3G3hIIIHC2I7d34gt/uus243r8nyLXTNHyCp2lya1oH4EhnhJVi8cnYh4cmgnrcqDD33MW4EKZpo2BLD1ALrCBw+JO/FIDwusRKWCZI6PC55zvRlSUI/kVlLEZzY= X-LD-Processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 31:FTVuf7tZWIbpsIiZY5QKd8o/kXe2FzUbMzUGBhAGSw5FRNNDQAEPWTihZUaJgbZSBSY9D4AMblnq7kFsUBkUyGXa2z9x3Gx61MlzgQfxH/cGY+NQRW9go64Diiu8tMVXOEmoU3wEQkhlWt/fXpTGr//NOLQJJBrX1wIK2lfHQlqdmtultd7Dp4cZLtF9djHxbyZ79c6SXJbH0qSAZvfk3qYYEWYxvWN5h4k1DO6O7YhMRwf04w99ta/dkvXgqyt4APbgPhqS5El179zzZeD9I0Sxy2FfDUNKgx/AtTio8owZQ8TJ/IDT9Hj4c4hRHJDW8J9DKFdaPbSgE+7zJrcr8ywiOVTmwy1M4aWFzQpzFc/7loGDp2tsvS3NLl2E1gt5wdoVtGPZceqN9JHhXvODY+7GwafwM2DOpF5h9oX4IsFFCFdiULWy7VgDhgcq06wBD2B1uX2qfWkdYDnTCesPqiWGRjINCPWH7SMtV2YJlI/CBu1sl4kVwMD50GGfac21qRiE39ySYBahmh1gpAPK2FmTPbNtBdPE9tMxOfWibG+zr/hBgWNhdjeVeBFOqdPat6xDADs1VsMiCGN4zSNAIR/dIrp87wVa2tz9ZY0/KAI8Vnv00KTllp0P26LHhbqlLgwt8KESJUCOV91/R/3FA/p4N2UTMPQbJS/A1kXbciI7rc3iqPuYS07Giip+TVv0WLV286LWws4pWqQcx6E7RQ== X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 20:XKCl9dPpUp0BV1eB9wdAkeoclbY1Ax33Wk97T0nNUzxZhhwDkBwBnJE+6h5AHpm1zDloKtj39pXblOR20TwF4QOVYEDgg5gx04mIa4ddxTEg8bs2ihUyBFgh4w50tMg8eKPvJfo071wsR+pxsaLsOeX68mkwHn7IQYQCEHGV/SbszR5iFD4rXLHkcxU2bKSGYgXARLIT3z1JuHURfxjralMet5bt6kNZ9gF4bikXHbiWwm/ATJCdw7uWiy0icb5fUcpLQXxijetBPVMB1T7rLVveCsFq8Z/kVjtaF/23UzAxRitGXc2iy5pWjs4xvbybCnesbT9QMCLD22ZlSfeAPOuHoxq66h0iPoKg/VbWbeOXLSX/v6zwiOaNxArCfzHYfFrFyQCh1sSV9x9CWfl49EbOCpLmL4qh4ZhAC6T48vvVy8QzX8BHoQ2JyDRmYJBgRfPGu3QnDcWvp7dFO2QmuXc7xBm82AUJI99DrFM2aW3u6M5S2QPePbiDqgIh4likuQcsNQYqKQ7r/D61Ds18c7tDBca4pvkhNNkgbG8dP+pqsvpee5re/A/9aUyRT2VJGdRHzsnflVKeI/UaCwveAplPzqJF8upMkbdX5kHSc5M= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(133145235818549)(236129657087228)(138986009662008)(50300203121483); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(2017060910025)(5005006)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6055026)(6041248)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR05MB2506; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR05MB2506; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB2506; 4:nJNBKHclpf4WKvzU8Jy9rQNG5hIpuECiAyR2qf8tVD?= =?us-ascii?Q?8BHam9l5pADSQz58q6Ly/EnNudtZYhYrx7q80nLWu+MEI4/eAdCyuWDhiiku?= =?us-ascii?Q?FQfgVXt5KYfluvEiZDiNvWOaRRq/uz35oyQG05QVOf2a4FE3CPdG5GEAJK1K?= =?us-ascii?Q?oEMwE8xCbfCxxDmTBFZNBZLLFllk2PM7To2Rmr7YHDGQFXsj78BOfKpMFA4q?= =?us-ascii?Q?nLYBtRNzewmGHvvs8V1lDV45d/1UZaehavZldiMxfsNAGc8nfuWXIZmxlpMf?= =?us-ascii?Q?j+598ZQmz8G89urItuKavQR9b+T3tO/OsAuXr/0JI6AAxk9vj3XkfTKlAxWo?= =?us-ascii?Q?EG3EkRT2RhAIipwpdPmxTN+PPWwQrwmgkPj1NB/L5EKNBMOqZE2hdmWIFPZZ?= =?us-ascii?Q?/j52vzry+qlcVd5pB+wQAcQZwJg8nuCxAMWHbDATzXXbuNkmSjjVYgPVmCkC?= =?us-ascii?Q?FnswBW/9Ih277o9w8b/uyQPUA7bLYd2G0RhKVsAlOZzyPXgaQNgcg3EkP7kL?= =?us-ascii?Q?Gbh9DMUx5sBlAHmneCo1bimp+boLHiXXeK+ArBmkDDlJEa/dxewPmjhPEq3F?= =?us-ascii?Q?EGu5bm9RyXV6gCVHfXIbvoa6jShEde2guuRDjjDvclXpDzRhajj+yXHk+6g1?= =?us-ascii?Q?4ImC0M9PLGnY6FSJuOhMssLdCrONtnbzDsVex3dulF9XZyAgFFdsnOzoFs6Y?= =?us-ascii?Q?V8jWSdPYyWaF0BLA+s9bpK4eu4Il1mCZkZECkRDXgszksNFMKtsp38dmbzwl?= =?us-ascii?Q?7vitan0Ru/2WcIm+zEnGDqrFonqhdov+oqB4Y296J4KweoEoEqSw0OvL0H8C?= =?us-ascii?Q?mq2zEYpigeSt0Jzb60rX18QmAwCxA19BgLplHro6U7b58oLVUy8WgO3mMcDe?= =?us-ascii?Q?z+X+Bu3VzorpanUBTMO6bNJTkJN/FHPZ8o6kkJ16YiiIWIrb7xP2HAHTympc?= =?us-ascii?Q?NlcmgjRaaLYPXwAOYbv/XeagUJ6OuRQZBcUMXRDtRxUozLq3uyMlMhf68GKw?= =?us-ascii?Q?QDuj/YCuhwpFxcZejmD7gML4c4NMEZ5pXVnO7iBFyxvBHhSc5GeU8mpeaMi7?= =?us-ascii?Q?Mp9c6J0yyQRBzpgNiIa3iNcBOOHU9+UJ5jedjWrxafN2u5OFNNfJ8knM6fsF?= =?us-ascii?Q?I8r6j+4DDEyD4i/6IO5Yy9rFz2G2MbYp03nhl3zQ4tS9WzaFdwgf+E8DaSIN?= =?us-ascii?Q?gcnIafjNvJ6Yw2C4qAWajs/CNHbH0kGcqRnEG1ibM6R1Yo8kYVOwsOsvbocP?= =?us-ascii?Q?RdVgmHam5G7U0FdRCd7dQcCApfB/H6lR5ljtdVp/6DraBb+AYqkf6HURuXKM?= =?us-ascii?Q?YwDu7Ba8uFgEhYH53e7XYiQn8KR123xz7ZoCKF7r8XZyiNbzmxGEYobeoVCG?= =?us-ascii?Q?asrsVcygh46fc+mK4To5Rpzsw=3D?= X-Forefront-PRVS: 035748864E X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(39400400002)(39450400003)(39860400002)(39410400002)(39840400002)(39850400002)(24454002)(377454003)(53936002)(36756003)(25786009)(6246003)(478600001)(38730400002)(86362001)(110136004)(76176999)(50986999)(4326008)(236005)(2906002)(33656002)(189998001)(93886004)(42186005)(230783001)(90366009)(66066001)(69556001)(6116002)(3846002)(229853002)(6666003)(83716003)(53546010)(84326002)(5660300001)(6916009)(7736002)(82746002)(8676002)(77096006)(6486002)(2950100002)(81166006)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2506; H:[172.29.34.54]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB2506; 23:SqLS8AcMP0pjkfZuUn3+7SHopwa8di1QGvwX0vl09?= =?us-ascii?Q?oMc5GinF6rFFcksGSm0B7MBmJqyiAaYQMvnTXj6vstJXFORBydMK7pf7Fre7?= =?us-ascii?Q?HqA3gCL+739DXDnpCyu8AQejwkuXC/7fHYHyUmPqpzDgPRhkH7yysklOEGFM?= =?us-ascii?Q?hqVZ+K5jzxcwcq/jJrW3YCY284Y1na0i2kIrs1nybztuXb8BJs1adCCqTWIp?= =?us-ascii?Q?S5gf5LRFXFuHQNLAYVA8fCOsByobWQW1hEpQ9eh2nDz/l7EhpXVcUjpGubOZ?= =?us-ascii?Q?620zaGGNJ36dv6zscFdBMeKPTS5g2jVnxPDJwzpnjmFCqdyEN7b0XdZKpFG9?= =?us-ascii?Q?JCYI15XBFJ8b5nMWT4rTNz3rg6cx3COXcLVVCN/GXGFXeNxkbzLMPl7eg/am?= =?us-ascii?Q?Ln8kAB+vA+V219v2QpuukctFN2ai5ww0rpJgt16agDrYj6xSPTbnLhHn2n6n?= =?us-ascii?Q?JMqd4r1Th54a+LBxb+cIap6t5hkmpKRrFS9t2QfzIdyuyQVzqUHVAffb2p74?= =?us-ascii?Q?DG/ScfJLmBU/upi2Rlg8Vq4Ez0JDSxPteCWNT6kBz9GSALQ33MHWAHQb11Oj?= =?us-ascii?Q?3heuEU3vsxdcVzr+aVuFlQ4gieDgH67kkTntli9jRk6A3/OE7rpbjc3dwoN3?= =?us-ascii?Q?qey9uoykn/4cs+XbA4Lj4j5GlReCu65jvqElXQ8H6H5KWbTw6b9PzO6mCyNF?= =?us-ascii?Q?qXY9rILw3soMScPIaOdMw/8EevkzazGwEf7eTyijaBLZE0GhRE3E/Dtx0foY?= =?us-ascii?Q?Xjd1efvRM8dyejxYheAMV5kBpfgnAx4HUrqPb0rqLwBXRwSgBaWFlzPtIdh1?= =?us-ascii?Q?kB4vZ6hfa0j5EUKFNvemfns4Sd49rupvCzQhwXrHfRisOjKnRgcXCzqbwCup?= =?us-ascii?Q?+HwlX+u5zxyQW9kmjG7iMjkq3Rn8c3aQQSD0nkb89FU88+z8sSTL5MXlvUsE?= =?us-ascii?Q?Q9eSb/7rrk+4VisYTmVeVmuppHckO4/St2YSJbzHHNK4KOmZvTimX9K6sfXr?= =?us-ascii?Q?NNbWbkmR0Rq0hY87U0CzUPanXEx/bfHckp1TJwVolCzURyZJ5TjQeCzEq29W?= =?us-ascii?Q?m2lZTHWN/vvoZJ3XL9LLBeUPWMzJuPBD0c2zDr+U+jVtf1BZU1XQNpS6uxHD?= =?us-ascii?Q?kGLUbqTb4xieE2lGisimXMKvHcYuZF7xeuap/LemSlrkS1H2sB8gxUiT1L3B?= =?us-ascii?Q?k1ZxQV0MgLEWp4=3D?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB2506; 6:imnlHRmQvE3f1C++xDy3Sxa0bJw2zhhGZU7CgtBVcM?= =?us-ascii?Q?KKdnu4Q5DrO0SsWxHjiYWqgoCZcIGva4TUKvU/ZVR7AH55I620EbThl/+rQU?= =?us-ascii?Q?4sKQmeq9AiRpsQc6S64H9mvseel17KaqekjCNY755E7FCfRxkqai9TG8x02g?= =?us-ascii?Q?IsGFz+feson8ucmsZDG/OlZY1xejI97hEO/LfjI4eUh4Ozpik8cC1Po09i9u?= =?us-ascii?Q?qJPtZyu/wq7b04+JBL2BOlv8ME9vmCR/BoBTEk8ILjZG0iGgIR8pHn9fiEZY?= =?us-ascii?Q?QGCKr3M5AC23s5myqGPEbh4+aQYg98MfdY+kORvMsSnVQeAbX6XKg6ZeQxZC?= =?us-ascii?Q?J/2h+iCVZEbtARaDdlJCPGOq7sf+JdCEJJQO1pYDHJhiaWsfZ+DA23ZL7+/I?= =?us-ascii?Q?uLsUzY5O58UBPzS+5bnOgH+wV6Zjyd+X+LONe1NegSoPJ4f0vSQp15dIU2ob?= =?us-ascii?Q?wX2NYnxv1zE10tn/I7S78wI0rJxF7mU10J7eE8Tesw+vuRaJa8O+XOLKXmxi?= =?us-ascii?Q?HGd3VuDMd4Ny5bkqGOQBExpxVW9R4R+zlw61pQz0zMQdZZ998uCryPIvRjsm?= =?us-ascii?Q?GSCPZi5CJQJR6VvTrarlkRZ4BTDD4Ow+eKDbVYFotcE6qOsM92YBFOGNh1xl?= =?us-ascii?Q?sHXnJUKRWp3chOI+ZwlVpWvlT+Un4tMBUSNfL8aGbfLIkszCXpVfzP8esPMA?= =?us-ascii?Q?/LHUay8agL0T2XVtn7hmr73Q8cwhCRrcX6l/pMZ1/q9j6XNYsMefRs07V2za?= =?us-ascii?Q?FZEllwbSFjtWqfKepvdif/lmaD4t42rcgwdSeZw88lx7sIaWsLXSiJxP5QaG?= =?us-ascii?Q?iQZR6ErtLubis4dU+/4BdG7jqKrKYEKmLTt6ENQbbsZ51oLOnA+LgBXDHwa5?= =?us-ascii?Q?bfdp1BzhK5a3i9t3uXv6y7tj/548Z4lYsAzf5UfUnhse8lzRfMWC/VL6u0nd?= =?us-ascii?Q?Y2Eji4USUptE/QDVul8DjOlQ48kkpFnTlmeu4yyrgu/2EjSFIZeEswuhn0bh?= =?us-ascii?Q?hbvGbmFxD/YbifNRhxnUiD?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 5:MSmnLx78GiboPRXDGN6fX13UIDzOIYay48V6ev19IIJM4LBxWI9jY9wPX5B+XlTeJgZbuUJLN/WT722DR7G08wo6HMSbMLKClwV1Kwp+sExjGk91l76KTsOKic+Kmp6qJzcf5aMWPH/Dt+zuYOZa6/ZD3F7SYhk1mViLB6Z2HDMM+JG8ub2eKkBO5lO6Fofly/uo6QU++rYNb9zsT6XaY/hg4deL4ESFiU1s7p/8or9vctAdCewwSS69pbz63deHWgY3TmxaXtrbqm7rxeBKPnE0Y9G+a37gDY1ZwJ3MHEVDEoQ8KyVrbHZL7u4+GgfRU5voxd17ROzlZjE3/3ifjUbsx9RG/3NWkmA8qSEnnnbo7jacVYx2SwL7unEYSDr8kJ/VcZygJ6ZunlNYOOV3WmbMHPr96iZ/GGxSxmwFYSIr5i+8RBXirwr9ZLBVT/TJIy1H4LHNMRho9kIXK84ZsvIhSNCxvi0WlOK9vvD9GO1xPL/bxrLobY4OAABjhOG3; 24:M2YWzaqktdq78V6h5VCc41xkgL9AsrvdH9IdqQ2Y+Gd6z2IhHTpYq3vObvYCdIOiLF5QwcB+9taX4T2YjarNUJWvyYZiMQtMcLfiJLanKxY= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 7:ZO1MxnUNoskcCckPqysaeRBMjNV9BvBp+XQEhQZIAUnI/vQfp/Rk700Qxv62mwDpbvSd1FG7dIB4xZZ+fKkN0kYa3gEgKuKmCkiys6n72y9fiPEC1jJQlWNIvxhMs3YiXu0ZGDiUHPUJPoBKSVs8H9Lmn7AV/y4T6JoVKhT4X8xJAD1lcTadiTLHwcYqAOEEadsEN7n9tHkm84gJyQ+AX76MlLR2a/jDkoqnwmenuKmj158YZT0vfPo7t46AVjgb5QzLbj1xF0PB6l4D8zt7M+iFc38qR/Fhito1wketRc0z236YlmVMEuf7FZjOuaV3inD5HMCE8bCNQt+UHtSGW5OaRLyJfmHKC/GCjdlrRQc478t8zYm2MBCorwmsrgFcVj3RITGXa11KNYma1j5oYiU16LDJ5IsRapzkLcjdBFbufsbr575byCYWlnyJ6TABjzGxnloE2hOwCdmclA6gNP0QlTgNvdoS/EfmxjCp2STCNRVdhd9gXJNnsE7klYiloL0JsmwJuWImmbHtagd08Y+VU4cDQYRrcT4XRRWAgdC9FLkmHddeCp2P4/7ccIOk7VihcYtAdSw08SyxZwKqRSJOa0M1SuSwQNvLW6oPrOM/E0+mvMktYCAcF9eujMDD5UrCoPf585BwxquqOc7gmnmhrfnoESwN03n/Q0dLp0/7TBCHtiwcmyi5c4JNJW10DdK+zxX11Ez5pQUeBFzcNN3BEsQgzB1TeB9om8iRkgYAHawC1PtWi5YWsr7AKjaTeOmjGsa4APXODPBvH7/Qu30PNbFjYR5g/ijR4B1LxMw= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jul 2017 21:40:00.0913 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2506 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 21:40:20 -0000 --Apple-Mail=_EE2F5E1F-288D-4750-9E2C-7B474F3D302D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 3, 2017, at 5:31 PM, Job Snijders wrote: >=20 > On Mon, 3 Jul 2017 at 23:18, John G. Scudder > wrote: >=20 >> On Jul 3, 2017, at 5:10 PM, Job Snijders > wrote: >> On Mon, 3 Jul 2017 at 22:53, Randy Bush > wrote: >> > I don't follow. If the route server facilitates you in setting up = BFD to >> > all "nexthops of interest", the route server's job is done, right? = Any RS >> > peer has the ability to locally verify reacahbility across the = fabric and >> > route accordingly. >>=20 >> route servers are for the small folk who can not do full mesh, let = alone >> add path and other fancy things. the rs IS their control plane, = period. >>=20 >> If a device can't do add-path, can we really expect these devices to = do fancy things like opportunistic "route server assisted" BFD to all = next-hops of interest? >>=20 >> If we operate under the assumption that these clients can't support = receiving multiple paths through add-path, I envision a somewhat ugly = cadence: >>=20 >> 1) Hey RS, can't reach A >> 2) Ok, here try reaching A via B >> 3) hey RS, I can't reach B either >> Etc, etc >=20 > If that cadence happens, they haven't implemented what's in rs-bfd, = right? So why would even #1 happen? >=20 >=20 > Perhaps my understanding of the draft is flawed, but rs-bfd = (currently) specifies the concept of relaying information from RS = participant back to the RS about who the participant can reach or not. Yes, but I think the part you are overlooking is that the RS asks the = client to track connectivity to all candidate next-hops, whether or not = the RS is currently sending the client a route with that next hop.=20 > So #1 can only happen if rs-bfd is implemented, Yes, but. > and the cadence would be a logical consequence if add-path is not = supported.=20 That's the error. Numbers 2 and 3 wouldn't happen if rs-bfd were = implemented as written, because in step zero the RS would have said "hey = client, please use BFD towards A and B" and in step 1, the client would = say "hey RS, can't reach A, also can't reach B". --John --Apple-Mail=_EE2F5E1F-288D-4750-9E2C-7B474F3D302D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Jul 3, 2017, at 5:31 PM, Job Snijders <job@ntt.net> wrote:

On Mon, 3 Jul 2017 at 23:18, = John G. Scudder <jgs@juniper.net> wrote:

On Jul 3, 2017, at = 5:10 PM, Job Snijders <job@ntt.net> wrote:
On Mon, 3 Jul 2017 = at 22:53, Randy Bush <randy@psg.com> wrote:
> I don't follow. = If the route server facilitates you in setting up BFD to
> all "nexthops of interest", the route server's job is = done, right? Any RS
> peer has the ability to locally = verify reacahbility across the fabric and
> route = accordingly.

route servers are for the = small folk who can not do full mesh, let alone
add path = and other fancy things.  the rs IS their control plane, period.

If a device can't do = add-path, can we really expect these devices to do fancy things like = opportunistic "route server assisted" BFD to all next-hops of = interest?

If we operate under the assumption that these = clients can't support receiving multiple paths through add-path, I = envision a somewhat ugly cadence:

1) Hey RS, can't reach = A
2) Ok, here try reaching A via = B
3) hey RS, I can't reach B = either
Etc, = etc

If that cadence happens, they haven't = implemented what's in rs-bfd, right? So why would even #1 = happen?


Perhaps my understanding of the draft is flawed, =  but rs-bfd (currently) specifies the concept of relaying = information from RS participant back to the RS about who the participant = can reach or not.

Yes, but I think the part you are overlooking is = that the RS asks the client to track connectivity to all candidate = next-hops, whether or not the RS is currently sending the client a route = with that next hop. 

So #1 can only happen if rs-bfd is implemented, =

Yes, = but.

and the = cadence would be a logical consequence if add-path is not = supported. 

That's the error. Numbers 2 and 3 wouldn't happen if = rs-bfd were implemented as written, because in step zero the RS would = have said "hey client, please use BFD towards A and B" and in step 1, = the client would say "hey RS, can't reach A, also can't reach = B".

--John

= --Apple-Mail=_EE2F5E1F-288D-4750-9E2C-7B474F3D302D-- From nobody Mon Jul 3 14:56:23 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7524F130134 for ; Mon, 3 Jul 2017 14:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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 drkfUr5XAnGx for ; Mon, 3 Jul 2017 14:56:12 -0700 (PDT) Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::22]) (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 1915D129AAD for ; Mon, 3 Jul 2017 14:56:12 -0700 (PDT) Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dS9KF-000Eza-U2 (job@us.ntt.net) for idr@ietf.org; Mon, 03 Jul 2017 21:56:11 +0000 Received: by mail-wm0-f49.google.com with SMTP id f67so66932084wmh.1 for ; Mon, 03 Jul 2017 14:56:11 -0700 (PDT) X-Gm-Message-State: AKS2vOzkE8UibR3lqN452lluGfCPr+kFIzCsaFzF9zlUUzXFmbbnQ9Ud 4RtxGTR13uDGGz+1j+c7wDCmrDAduRIH X-Received: by 10.28.209.70 with SMTP id i67mr26689830wmg.3.1499118970048; Mon, 03 Jul 2017 14:56:10 -0700 (PDT) MIME-Version: 1.0 References: <149909741417.22786.4679459342587499122@ietfa.amsl.com> <20170703160800.x6wcym2ma6jceqv7@Vurt.local> <20170703163846.224w6lxvbt4txqub@Vurt.local> <20170703173810.GA45648@Space.Net> <20170703175308.hembxkplaniz66wb@Vurt.local> <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> In-Reply-To: <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> From: Job Snijders Date: Mon, 03 Jul 2017 21:55:58 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Job Snijders , John Scudder Cc: Randy Bush , idr@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1313f6afaafb055370d571" Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 21:56:17 -0000 --94eb2c1313f6afaafb055370d571 Content-Type: text/plain; charset="UTF-8" On Mon, 3 Jul 2017 at 23:40, John Scudder wrote: > On Jul 3, 2017, at 5:31 PM, Job Snijders wrote: > > > On Mon, 3 Jul 2017 at 23:18, John G. Scudder wrote: > > On Jul 3, 2017, at 5:10 PM, Job Snijders wrote: >> On Mon, 3 Jul 2017 at 22:53, Randy Bush wrote: >> >>> > I don't follow. If the route server facilitates you in setting up BFD >>> to >>> > all "nexthops of interest", the route server's job is done, right? Any >>> RS >>> > peer has the ability to locally verify reacahbility across the fabric >>> and >>> > route accordingly. >>> >>> route servers are for the small folk who can not do full mesh, let alone >>> add path and other fancy things. the rs IS their control plane, period. >>> >> >> If a device can't do add-path, can we really expect these devices to do >> fancy things like opportunistic "route server assisted" BFD to all >> next-hops of interest? >> >> If we operate under the assumption that these clients can't support >> receiving multiple paths through add-path, I envision a somewhat ugly >> cadence: >> >> 1) Hey RS, can't reach A >> 2) Ok, here try reaching A via B >> 3) hey RS, I can't reach B either >> Etc, etc >> >> >> If that cadence happens, they haven't implemented what's in rs-bfd, >> right? So why would even #1 happen? >> > > > Perhaps my understanding of the draft is flawed, but rs-bfd (currently) > specifies the concept of relaying information from RS participant back to > the RS about who the participant can reach or not. > > > Yes, but I think the part you are overlooking is that the RS asks the > client to track connectivity to all candidate next-hops, whether or not the > RS is currently sending the client a route with that next hop. > Conceptually there isn't a big difference between exchanging this information in bulk or as deltas. But thank you for pointing this out, I now also wonder whether it is efficient for a RS participant to track next-hops it migh not have any business with. That seems like a waste of resources. So #1 can only happen if rs-bfd is implemented, > > > Yes, but. > > and the cadence would be a logical consequence if add-path is not > supported. > > > That's the error. Numbers 2 and 3 wouldn't happen if rs-bfd were > implemented as written, because in step zero the RS would have said "hey > client, please use BFD towards A and B" and in step 1, the client would say > "hey RS, can't reach A, also can't reach B". > I'm not sure whether events will be packed together this neatly. Questions that remain: - is it absolutely necessary for the RS to be aware of the entire bfd session topology state? - is it reasonable to assume there will be BGP speakers that support draft-ietf-idr-rs-bfd, but not RFC 7911? - if the RS is not stateless (in this regard), can we reasonable expect things to scale? (As it currently stands the industry has trouble scaling RS services) If it was not clear from previous messages: I am supportive of the idea of "assisted BFD" to take away some obvious downsides of route servers. Just not sure the proposed approach will work out good enough. Kind regards, Job > --94eb2c1313f6afaafb055370d571 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, 3 Jul 2017 at 23:4= 0, John Scudder <jgs@juniper.net&= gt; wrote:
On Jul 3, 2017, at 5:31 PM, Job Snijders <job@ntt.net> wrote:

On Mon, 3 = Jul 2017 at 23:18, John G. Scudder <jgs@juniper.net> wrote:

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">
On Jul 3, 2017, at 5:10 PM, Job Snij= ders <job@ntt.net&g= t; wrote:
On Mon, 3 Jul 2017= at 22:53, Randy Bush <randy@psg.com> wrote:
> I don't f= ollow. If the route server facilitates you in setting up BFD to
> all= "nexthops of interest", the route server's job is done, righ= t? Any RS
> peer has the ability to locally verify reacahbility acros= s the fabric and
> route accordingly.

route servers are for th= e small folk who can not do full mesh, let alone
add path and other fanc= y things.=C2=A0 the rs IS their control plane, period.

If a device can't= do add-path, can we really expect these devices to do fancy things like op= portunistic "route server assisted" BFD to all next-hops of inter= est?

If we operate under= the assumption that these clients can't support receiving multiple pat= hs through add-path, I envision a somewhat ugly cadence:

1) Hey RS, can't reach A
2) Ok, here try reaching A via B
3) hey RS= , I can't reach B either
Etc, etc

If that cadence happens, they haven't implemented what&= #39;s in rs-bfd, right? So why would even #1 happen?


Perhaps my understanding of the draft is flawed, =C2=A0but rs-bfd (current= ly) specifies the concept of relaying information from RS participant back = to the RS about who the participant can reach or not.

Yes, but I think the part you are overlooking is that the RS asks t= he client to track connectivity to all candidate next-hops, whether or not = the RS is currently sending the client a route with that next hop.

Concept= ually there isn't a big difference between exchanging this information = in bulk or as deltas. But thank you for pointing this out, I now also wonde= r whether it is efficient for a RS participant to track next-hops it migh n= ot have any business with. That seems like a waste of resources.=C2=A0


So #1 can only happen if rs-bfd is implemented,

Yes, but.

and the cadence would be a logical consequence if add-path = is not supported.=C2=A0

=
That's the error. Number= s 2 and 3 wouldn't happen if rs-bfd were implemented as written, becaus= e in step zero the RS would have said "hey client, please use BFD towa= rds A and B" and in step 1, the client would say "hey RS, can'= ;t reach A, also can't reach B".


I'm n= ot sure whether events will be packed together this neatly.=C2=A0

Questions that remain:=C2=A0

- is it absolutely necessary= for the RS to be aware of the entire bfd session topology state?

- is it reasonable to assume ther= e will be BGP speakers that support draft-ietf-idr-rs-bfd, but not RFC 7911= ?

- if the RS is not sta= teless (in this regard), can we reasonable expect things to scale? (As it c= urrently stands the industry has trouble scaling RS services)

If it was not clear from previous mes= sages: I am supportive of the idea of "assisted BFD" to take away= some obvious downsides of route servers. Just not sure the proposed approa= ch will work out good enough.=C2=A0

Kind regards,

Job
--94eb2c1313f6afaafb055370d571-- From nobody Mon Jul 3 15:20:36 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8007129ACD for ; Mon, 3 Jul 2017 15:20:33 -0700 (PDT) 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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 WlKGOTc-eBJe for ; Mon, 3 Jul 2017 15:20:31 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 7AFFA12EC15 for ; Mon, 3 Jul 2017 15:20:30 -0700 (PDT) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 6ABED1E333; Mon, 3 Jul 2017 18:29:42 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jeffrey Haas In-Reply-To: Date: Mon, 3 Jul 2017 18:20:28 -0400 Cc: John Scudder , idr@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <09BFF794-6899-4DA5-8EF5-DDF86513BFBA@pfrc.org> References: <149909741417.22786.4679459342587499122@ietfa.amsl.com> <20170703160800.x6wcym2ma6jceqv7@Vurt.local> <20170703163846.224w6lxvbt4txqub@Vurt.local> <20170703173810.GA45648@Space.Net> <20170703175308.hembxkplaniz66wb@Vurt.local> <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> To: Job Snijders X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 22:20:34 -0000 > On Jul 3, 2017, at 5:55 PM, Job Snijders wrote: >=20 >=20 > I'm not sure whether events will be packed together this neatly.=20 >=20 > Questions that remain:=20 >=20 > - is it absolutely necessary for the RS to be aware of the entire bfd = session topology state? The draft is written with the idea that some/many devices *won't* be = aware. If the state is Unknown, things still work. >=20 > - is it reasonable to assume there will be BGP speakers that support = draft-ietf-idr-rs-bfd, but not RFC 7911? >=20 > - if the RS is not stateless (in this regard), can we reasonable = expect things to scale? (As it currently stands the industry has trouble = scaling RS services) >=20 > If it was not clear from previous messages: I am supportive of the = idea of "assisted BFD" to take away some obvious downsides of route = servers. Just not sure the proposed approach will work out good enough.=20= The way I suggest reading this: 1. BFD to the BGP nexthops is really desirable. It lets you avoid = blackholing in several well known scenarios, including the RS based = distribution of routes. 2. Regular BFD needs both sides of the session to be prepared. In the = absence of full mesh BFD configuration, there needs to be a feature that = permits the RS to notify the clients what nexthops are of interest on = both sides. 3. The feedback mechanism permits a RS to send alternate paths - when it = is capable of doing so - when a given nexthop is unreachable by a given = client. The third mechanism is very optional. Many RSes need not implement any = sort of new path selection if they don't want to; points 1 and 2 are = still helpful.=20 To the points about add-paths, and statefulness, even if the RS clients = spoke add-paths, you have to choose what level of path scaling you want = to do. If you're to the point of sending everything, a RS isn't even = necessary. And clearly, people use RSes partially for "remote policy" - = effectively path pruning. Looked at a somewhat different way, choosing the backup paths is no = different than add-paths or diverse paths feature choosing the next best = path. But since the RS and the client could have already conveyed the = possible set of nexthops for the view, there's no need for stepwise = discovery. Perhaps this point needs to be made clearer in the draft. -- Jeff From nobody Mon Jul 3 15:23:00 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE0C1120454 for ; Mon, 3 Jul 2017 15:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 G0e6ZrGXc2OL for ; Mon, 3 Jul 2017 15:22:57 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0759F12EB27 for ; Mon, 3 Jul 2017 15:22:57 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id h64so63092902iod.0 for ; Mon, 03 Jul 2017 15:22:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=2xvELZ4c4hOOAGsv6BtgHSbUsHFg9kt+0xdOBO845I0=; b=jeb2wUNrRMUdKL6llXFtKkVp+O8CXBv5SzTm1ueb7Juq3aIutrJXQy4K+9tvqpVzbB GFiW1S7N9Zs5sVbYO1iCdhg42x4ein/B7fVsZcY6/loBuyoTzUI2ebZZnafE7RKziSCe r1my9/yRaGMLApeiovlTub2t0HBnKn+Qi1vIZM+0IvCF1WUoxKM+5DTztMgNm62ZVHzl Kb6V3WAwnMLUFFjvAZnxInPXoTQU9T4M4q7apcuMRQn5sWr9DeMCGMO69TZTN+gXzn9W XUkDTe14cWqpGIx1GNo2FERp+PfFeG+CzAa5iTDGOq1pi9I9Ugp8DLtulHAAF2K7pE6C Wm5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=2xvELZ4c4hOOAGsv6BtgHSbUsHFg9kt+0xdOBO845I0=; b=SC44DUpPfvMNcuRgXIWIHsEl3n1QyrP3z8Mx7qZEwRAbnUx+tCEiH6sE2BNfvh5t78 L1LLmJBR5/xfVAyp2wKF5T93V4KLtFPAcjdWnXZvHljtnqoD52z0L9bnDWY0u7YUgW66 jhRQec2kW+sPVangNgQDmpi6emvVaG2nkt+gvRHgY9NG1DhkAv1EWF/eLR/SRbDVBabB Z6KlY0eA+eJMyPHQ/KYveaCTuCPOB/is97ShQ4/Y1HQiPbLdkASbIITVCou1axbjm5cy 9Bj856pqOiMsD+8E7QTYKVSCtAlFe935odh3hCr2RMOWigIYsTexUUDVHFaDCGqDN2NJ hmVQ== X-Gm-Message-State: AIVw11040EnCZ6nlwn33U7+vswfATka70SVfmtFNXeGJ4xCbF0Puh0Qb QGapP7QJuLaUlU1nHzrlE0Xou1dHPH4U X-Received: by 10.107.140.145 with SMTP id o139mr18611545iod.155.1499120576226; Mon, 03 Jul 2017 15:22:56 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.32.15 with HTTP; Mon, 3 Jul 2017 15:22:55 -0700 (PDT) Received: by 10.79.32.15 with HTTP; Mon, 3 Jul 2017 15:22:55 -0700 (PDT) In-Reply-To: <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> References: <149909741417.22786.4679459342587499122@ietfa.amsl.com> <20170703160800.x6wcym2ma6jceqv7@Vurt.local> <20170703163846.224w6lxvbt4txqub@Vurt.local> <20170703173810.GA45648@Space.Net> <20170703175308.hembxkplaniz66wb@Vurt.local> <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> From: Robert Raszuk Date: Tue, 4 Jul 2017 00:22:55 +0200 X-Google-Sender-Auth: tg5IaocwZVD24sMJwa6KWxU2NiU Message-ID: To: "John G. Scudder" Cc: idr wg , Job Snijders Content-Type: multipart/alternative; boundary="94eb2c05a5446bedf305537135c8" Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 22:22:59 -0000 --94eb2c05a5446bedf305537135c8 Content-Type: text/plain; charset="UTF-8" On Jul 3, 2017 23:40, "John Scudder" Yes, but I think the part you are overlooking is that the RS asks the client to track connectivity to all candidate next-hops, whether or not the RS is currently sending the client a route with that next hop. And that is precisly the fundamental flow of this proposal. Clients are to track next hops for bgp paths they do not even have ... What happens when RS gets 100 paths for policy eligible net for a given client ? Client will enable waist of 100 bfd sessions and what is much worse will report state of those 100 next hops to RS ? This is so bad .... Cheers R. So #1 can only happen if rs-bfd is implemented, Yes, but. and the cadence would be a logical consequence if add-path is not supported. That's the error. Numbers 2 and 3 wouldn't happen if rs-bfd were implemented as written, because in step zero the RS would have said "hey client, please use BFD towards A and B" and in step 1, the client would say "hey RS, can't reach A, also can't reach B". --John _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --94eb2c05a5446bedf305537135c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Jul 3, 2017 23:40, "John Scudder"

Yes, but I think the part you are overl= ooking is that the RS asks the client to track connectivity to all candidat= e next-hops, whether or not the RS is currently sending the client a route = with that next hop.


And that is pr= ecisly the fundamental flow of this proposal.

Clients are to track next hops for bgp paths they do = not even have ...

What h= appens when RS gets 100 paths for policy eligible net for a given client ?= =C2=A0

Client will enabl= e waist of 100 bfd sessions and what is much worse will report state of tho= se 100 next hops to RS ?

This is so bad ....=C2=A0

Cheers
R.









S= o #1 can only happen if rs-bfd is implemented,

Yes, but.

and the cadence would be a logical consequence if add-path is not= supported.=C2=A0

That&#= 39;s the error. Numbers 2 and 3 wouldn't happen if rs-bfd were implemen= ted as written, because in step zero the RS would have said "hey clien= t, please use BFD towards A and B" and in step 1, the client would say= "hey RS, can't reach A, also can't reach B".

--John


____= ___________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr


--94eb2c05a5446bedf305537135c8-- From nobody Mon Jul 3 15:31:24 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D83513154E for ; Mon, 3 Jul 2017 15:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 AmNDxzooL-xG for ; Mon, 3 Jul 2017 15:31:19 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::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 D34EB13161E for ; Mon, 3 Jul 2017 15:31:18 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id h64so63155554iod.0 for ; Mon, 03 Jul 2017 15:31:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=PWNicuuIArAO37H+YsLO71ObnYOdfG+a+GV9lHP+o0M=; b=jNSABfjOMEd3CA5QeE9xrr5+GDM8ay8Mo8wEheQVqjZAVvWgIJ9bkO2WcehZb26bu5 Nq/vDVjUPOh781Klq7ueEBZDjnq23ZvoLa+gTnRdblU7lei5raxBDS8PiK0c06plINAc wvPMX7vM8enbyuTR5zdRZWFDQfpDChXwIhQof1Y9xDkEsHiuMRchR0qMUr2zclCibcrn msVn1+6pRle5qlpLq90PTBcoxwj8MnJAXkhPBfx35HAfPyvX3IZ5KpVXr+s8D/RffTYW RTKxLCbHJe/SVnoumX0FOj8OCh/4uWWirKQZ1RuPdzPGbYBBj7JeU2pu9PjmDHbixX7A Bbxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=PWNicuuIArAO37H+YsLO71ObnYOdfG+a+GV9lHP+o0M=; b=SrWZXcevDzjCpVAcGECyfl6gM6mZ99WjIUDUozm9TbJI1VwPQ1CAuFFPyXG3De2K2r U9eCmMn+bopJzMQfKSioA+bvOg+8pXpNwuRB1Y+/GoKajM2QiWfcKLMHKY6sQAamqEX5 adyqODcduv5Hg8qG0cBE4Hf0AiNyjpB7it57jiydo4KAPQ9661O6Bg4AhJZX94b5AAMu 4caZGPq32k3wT/v4BhYq6A2RnNRmOdJzaHhJSkOMrWqD6UbAcP2Kl5Bh5JDQa0N5UwMo 14u/CQcsvk2svfU4WY6PxOf8HByAXr6wozsox/lCHQSeTlK9gPq4pC+0kaYbRHwMYqgM /BOQ== X-Gm-Message-State: AIVw1123ggbPqJqSKY4WhleSnt6R5e6Nhr0CSNxeY4kycAXFaFdUwphn 1Hu2Z4nDHztvFmwvbJkd9Fgp8V2YPw== X-Received: by 10.107.28.84 with SMTP id c81mr8747136ioc.186.1499121078147; Mon, 03 Jul 2017 15:31:18 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.32.15 with HTTP; Mon, 3 Jul 2017 15:31:17 -0700 (PDT) Received: by 10.79.32.15 with HTTP; Mon, 3 Jul 2017 15:31:17 -0700 (PDT) In-Reply-To: <09BFF794-6899-4DA5-8EF5-DDF86513BFBA@pfrc.org> References: <149909741417.22786.4679459342587499122@ietfa.amsl.com> <20170703160800.x6wcym2ma6jceqv7@Vurt.local> <20170703163846.224w6lxvbt4txqub@Vurt.local> <20170703173810.GA45648@Space.Net> <20170703175308.hembxkplaniz66wb@Vurt.local> <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> <09BFF794-6899-4DA5-8EF5-DDF86513BFBA@pfrc.org> From: Robert Raszuk Date: Tue, 4 Jul 2017 00:31:17 +0200 X-Google-Sender-Auth: lVWfhsf_5I8dwwQdAkWtSepqwZk Message-ID: To: PFRC - jhaas Cc: idr wg , Job Snijders Content-Type: multipart/alternative; boundary="001a1140986e56a40605537153de" Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 22:31:22 -0000 --001a1140986e56a40605537153de Content-Type: text/plain; charset="UTF-8" If client talks add-paths you send them two paths. You may send them more if they wish so. It is just broken desing to signal failure between nodes to get new paths. PIC has proven this long time back. What this is about is really a new idea of sdn controller with bgp and distributed bfd for weak clients. Now maybe we could understand what are those weak clients who can not handle two paths for a given net ? Thx R. On Jul 4, 2017 00:20, "Jeffrey Haas" wrote: > > > On Jul 3, 2017, at 5:55 PM, Job Snijders wrote: > > > > > > I'm not sure whether events will be packed together this neatly. > > > > Questions that remain: > > > > - is it absolutely necessary for the RS to be aware of the entire bfd > session topology state? > > The draft is written with the idea that some/many devices *won't* be > aware. If the state is Unknown, things still work. > > > > > - is it reasonable to assume there will be BGP speakers that support > draft-ietf-idr-rs-bfd, but not RFC 7911? > > > > - if the RS is not stateless (in this regard), can we reasonable expect > things to scale? (As it currently stands the industry has trouble scaling > RS services) > > > > If it was not clear from previous messages: I am supportive of the idea > of "assisted BFD" to take away some obvious downsides of route servers. > Just not sure the proposed approach will work out good enough. > > The way I suggest reading this: > 1. BFD to the BGP nexthops is really desirable. It lets you avoid > blackholing in several well known scenarios, including the RS based > distribution of routes. > 2. Regular BFD needs both sides of the session to be prepared. In the > absence of full mesh BFD configuration, there needs to be a feature that > permits the RS to notify the clients what nexthops are of interest on both > sides. > 3. The feedback mechanism permits a RS to send alternate paths - when it > is capable of doing so - when a given nexthop is unreachable by a given > client. > > The third mechanism is very optional. Many RSes need not implement any > sort of new path selection if they don't want to; points 1 and 2 are still > helpful. > > To the points about add-paths, and statefulness, even if the RS clients > spoke add-paths, you have to choose what level of path scaling you want to > do. If you're to the point of sending everything, a RS isn't even > necessary. And clearly, people use RSes partially for "remote policy" - > effectively path pruning. > > Looked at a somewhat different way, choosing the backup paths is no > different than add-paths or diverse paths feature choosing the next best > path. But since the RS and the client could have already conveyed the > possible set of nexthops for the view, there's no need for stepwise > discovery. Perhaps this point needs to be made clearer in the draft. > > -- Jeff > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --001a1140986e56a40605537153de Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If client talks add-paths you send them two paths. You ma= y send them more if they wish so.

It is just broken desing to signal failure between nodes to get new pat= hs. PIC has proven this long time back.

What this is about is really a new idea of sdn controller w= ith bgp and distributed bfd for weak clients.=C2=A0
=
Now maybe we could understand what are those we= ak clients who can not handle two paths for a given net ?

Thx
R.
=

On Jul 4, 2017 00= :20, "Jeffrey Haas" <jhaas@p= frc.org> wrote:

> On Jul 3, 2017, at 5:55 PM, Job Snijders <job@ntt.net> wrote:
>
>
> I'm not sure whether events will be packed together this neatly. >
> Questions that remain:
>
> - is it absolutely necessary for the RS to be aware of the entire bfd = session topology state?

The draft is written with the idea that some/many devices *won't* be aw= are.=C2=A0 If the state is Unknown, things still work.

>
> - is it reasonable to assume there will be BGP speakers that support d= raft-ietf-idr-rs-bfd, but not RFC 7911?
>
> - if the RS is not stateless (in this regard), can we reasonable expec= t things to scale? (As it currently stands the industry has trouble scaling= RS services)
>
> If it was not clear from previous messages: I am supportive of the ide= a of "assisted BFD" to take away some obvious downsides of route = servers. Just not sure the proposed approach will work out good enough.

The way I suggest reading this:
1. BFD to the BGP nexthops is really desirable.=C2=A0 It lets you avoid bla= ckholing in several well known scenarios, including the RS based distributi= on of routes.
2. Regular BFD needs both sides of the session to be prepared.=C2=A0 In the= absence of full mesh BFD configuration, there needs to be a feature that p= ermits the RS to notify the clients what nexthops are of interest on both s= ides.
3. The feedback mechanism permits a RS to send alternate paths - when it is= capable of doing so - when a given nexthop is unreachable by a given clien= t.

The third mechanism is very optional.=C2=A0 Many RSes need not implement an= y sort of new path selection if they don't want to; points 1 and 2 are = still helpful.

To the points about add-paths, and statefulness, even if the RS clients spo= ke add-paths, you have to choose what level of path scaling you want to do.= =C2=A0 If you're to the point of sending everything, a RS isn't eve= n necessary.=C2=A0 And clearly, people use RSes partially for "remote = policy" - effectively path pruning.

Looked at a somewhat different way, choosing the backup paths is no differe= nt than add-paths or diverse paths feature choosing the next best path.=C2= =A0 But since the RS and the client could have already conveyed the possibl= e set of nexthops for the view, there's no need for stepwise discovery.= =C2=A0 Perhaps this point needs to be made clearer in the draft.

-- Jeff

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr
--001a1140986e56a40605537153de-- From nobody Mon Jul 3 15:33:14 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA23131640 for ; Mon, 3 Jul 2017 15:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 E5floutvxmAl for ; Mon, 3 Jul 2017 15:33:11 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3534E12EB27 for ; Mon, 3 Jul 2017 15:33:11 -0700 (PDT) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 51EA81E333; Mon, 3 Jul 2017 18:42:23 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_C3A62944-E5A8-4611-A709-505C616CD884" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jeffrey Haas In-Reply-To: Date: Mon, 3 Jul 2017 18:33:09 -0400 Cc: idr wg , Job Snijders Message-Id: <2F52A154-3F75-4DC9-9DBF-7C8047F65288@pfrc.org> References: <149909741417.22786.4679459342587499122@ietfa.amsl.com> <20170703160800.x6wcym2ma6jceqv7@Vurt.local> <20170703163846.224w6lxvbt4txqub@Vurt.local> <20170703173810.GA45648@Space.Net> <20170703175308.hembxkplaniz66wb@Vurt.local> <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> <09BFF794-6899-4DA5-8EF5-DDF86513BFBA@pfrc.org> To: Robert Raszuk X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 22:33:12 -0000 --Apple-Mail=_C3A62944-E5A8-4611-A709-505C616CD884 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jul 3, 2017, at 6:31 PM, Robert Raszuk wrote: >=20 > What this is about is really a new idea of sdn controller with bgp and = distributed bfd for weak clients.=20 >=20 Regardless of what you might think of the idea of signaling back to the = RS to permit the RS to bias its own route selection, if you think the = connectivity test to the nexthop is of little value, you haven't done = nearly enough work with IXPs. -- Jeff --Apple-Mail=_C3A62944-E5A8-4611-A709-505C616CD884 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Jul 3, 2017, at 6:31 PM, Robert Raszuk <robert@raszuk.net> = wrote:

What this is about is really = a new idea of sdn controller with bgp and distributed bfd for weak = clients. 


Regardless of what you might think of the = idea of signaling back to the RS to permit the RS to bias its own route = selection, if you think the connectivity test to the nexthop is of = little value, you haven't done nearly enough work with IXPs.

-- Jeff

= --Apple-Mail=_C3A62944-E5A8-4611-A709-505C616CD884-- From nobody Mon Jul 3 15:39:20 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE762131693 for ; Mon, 3 Jul 2017 15:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, 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 L-9Lw12IbTv6 for ; Mon, 3 Jul 2017 15:39:15 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2057B129562 for ; Mon, 3 Jul 2017 15:39:14 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id h134so63345454iof.2 for ; Mon, 03 Jul 2017 15:39:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Hmm/s3o47VtzQ8DWi3jpVWeTnWdqyODIjakFdsFwKPA=; b=OHQDhUXs6kLL0nwDb5SFO34qD/mRuphpsp+cXdKKMxGJZ3BRQoQ/6YnrWusTAW/Pzj 9YpNiFmTyEvcyc9phjUaKOWc6oSnmRw3xAx0MOa4ecy5tGvQeQ33Fd2rQsq1VYWDtRvK Hx5i7wBAiFm0aJnet218FWWZxQLpVOlVzDNAj7hAx6l7PEEk4JAnq7Q/bcEwhQI5lG5J eJ8SYfx9T8ESC2ex44GO20hJLRvj7aBIxpnlbMGbJMbZ43W7jV1qiWKDPfzwDApFCqs3 a3IC/9nOglKifhq3+Drz+LSLNW7Be9uptnChOL5nshiYk2uNIn/OEYu5mSuK7p3IGnTJ BkRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Hmm/s3o47VtzQ8DWi3jpVWeTnWdqyODIjakFdsFwKPA=; b=rlWXrq4NR97inFziYWmNgb3D0l2rUEElkrw9ubISHLWlT83hlzfn4rhcRV1Q7BdvIm AufvB1F/ioQ9alNZwr0uLGj68B0n2+XZFkPVydM04fQ4CD+g31ZG/uUmU51rHVdd27oe K1RhrZWd5RYg3/Sx02cTepHdMsfaNBw3U/y3Rs6OryNhu8CFecgEovJg3340gXjIxrxR wuQgJYGWiK+FqwZ560OzfRgpxSTmdj31nO2c6jJTaYI3i8o6AXiGE6l+YXC3fN0LGyAu v6v8znyTAQ6diotMgkCiO/PO1Aq4dSxRXPeANW2ocVb/WNlAKixYV5RDyOyGtyuQpXWz 1n/g== X-Gm-Message-State: AKS2vOx7M6lUDuYBvKVK5t0mAIBRyTuX9eeNRgwsLZnutJtOp5bMcBW6 eK30MlZlVGefKPlsv76C+AMrn8pNYA== X-Received: by 10.107.128.30 with SMTP id b30mr24266944iod.179.1499121553492; Mon, 03 Jul 2017 15:39:13 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.32.15 with HTTP; Mon, 3 Jul 2017 15:39:12 -0700 (PDT) Received: by 10.79.32.15 with HTTP; Mon, 3 Jul 2017 15:39:12 -0700 (PDT) In-Reply-To: <2F52A154-3F75-4DC9-9DBF-7C8047F65288@pfrc.org> References: <149909741417.22786.4679459342587499122@ietfa.amsl.com> <20170703160800.x6wcym2ma6jceqv7@Vurt.local> <20170703163846.224w6lxvbt4txqub@Vurt.local> <20170703173810.GA45648@Space.Net> <20170703175308.hembxkplaniz66wb@Vurt.local> <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> <09BFF794-6899-4DA5-8EF5-DDF86513BFBA@pfrc.org> <2F52A154-3F75-4DC9-9DBF-7C8047F65288@pfrc.org> From: Robert Raszuk Date: Tue, 4 Jul 2017 00:39:12 +0200 X-Google-Sender-Auth: KywYmAQRMqlR2aRdVx8t031gLSE Message-ID: To: PFRC - jhaas Cc: Job Snijders , idr wg Content-Type: multipart/alternative; boundary="001a113f8b12abd51f0553716f1a" Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 22:39:17 -0000 --001a113f8b12abd51f0553716f1a Content-Type: text/plain; charset="UTF-8" I never questioned connectivity check between clients. I question (similar to Job's observation) to put RS in the middle of the repair chain of events. Thx, R. PS. I do recommend we focus on the problem rather then going personal on who understands IX env better. On Jul 4, 2017 00:33, "Jeffrey Haas" wrote: > > On Jul 3, 2017, at 6:31 PM, Robert Raszuk wrote: > > What this is about is really a new idea of sdn controller with bgp and > distributed bfd for weak clients. > > > Regardless of what you might think of the idea of signaling back to the RS > to permit the RS to bias its own route selection, if you think the > connectivity test to the nexthop is of little value, you haven't done > nearly enough work with IXPs. > > -- Jeff > > --001a113f8b12abd51f0553716f1a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I never questioned connectivity check between clients.
I question =C2=A0(similar to Job= 's observation) to put RS in the middle of the repair chain of events.<= /div>

Thx,
R.

PS. I do recommen= d we focus on the problem rather then going personal on who understands IX = env better.

On Jul 4, 2017 00:33, "Jeffrey Haas" <jhaas@pfrc.org> wrote:

On Jul 3, 2017, at 6:31 PM, Robert Raszuk <robert@raszuk.net&= gt; wrote:

What this is about is really a new idea of sdn controll= er with bgp and distributed bfd for weak clients.=C2=A0

Regardless of what you might think of the idea of signaling back to t= he RS to permit the RS to bias its own route selection, if you think the co= nnectivity test to the nexthop is of little value, you haven't done nea= rly enough work with IXPs.

-- Jeff

<= /div>
--001a113f8b12abd51f0553716f1a-- From nobody Mon Jul 3 15:50:21 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97EBA1316DE for ; Mon, 3 Jul 2017 15:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 HbcWoEHnYJKD for ; Mon, 3 Jul 2017 15:50:19 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06C721316A9 for ; Mon, 3 Jul 2017 15:50:19 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id m68so93883721ith.1 for ; Mon, 03 Jul 2017 15:50:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=EE1qlNzGGuhZjy04tbIwFmtgQuF+qq5IaBFWInjpzcw=; b=A3ncgKs5NZZ7BW2OSTUiQVevq7ehTzZefQm/9pFCEOklUQBkfLZHAXFYWRpM7tJNZ9 eom/gquwt/QIiQhs8GsW5WJHb23S8YGehNazTGzx3JBQJfX8y/N1x8NlFd4A2D+CvKfL AvQ0zVMXrx4ME/Lmas3InsOkLKiz/4qnJe+oc6Cpk1C3ACi6Eu33/koF1D/4OoS6TUjl bZxEDf3orkqDll1Tlk7SLTwzHiQ5XlVqJi3eh1fS83GosTlgGiXKNXOJF0AWW+8mEdT7 7I7H469B+/sIcxzDP+nu4FZYlGqRanJUzJhKWNYQabqsAPy9cGrpqnfE09/JaYLdTbMp UPdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=EE1qlNzGGuhZjy04tbIwFmtgQuF+qq5IaBFWInjpzcw=; b=HpwHe1XsZ5EjrptegNS66DYndG3hKzGIac6bRgAL/UKHgbmHt0UbNIWR5iqqU0xUpg cwErNR1D2Hxqsc/2f3Qf5v/fkTZntl4cWGOm6lT3vP/WBjMRXQtw9RS4Fg9oUt2AYDpb G+Oa4y0lwvbgW9vPY1Tea5OSp30NWCdPRA7boxkNq4UM+k+/jFy316F9UvXlj3JC1LMF +YblXjYXrX0TuqFREKJIHdTcQ7oKLKB7cKhqioDVCLnhRuZNskv1mN5SjZeRiPlQtktG Kr/ZY3f8XXtMe/hqWVBiHfWJDYJlwuu4+LdAlXCP4a0cqG0gqyvtoSZArP4IJsyMzcM0 fbRA== X-Gm-Message-State: AKS2vOxyTB7OP5Bv+WZKHeAkbESVy6KiSyGdlUCTF5Y6kBm4FIA5RThJ qXEry8wD1Ko1QuwnfaI/AkzeipV9ZQ== X-Received: by 10.36.150.133 with SMTP id z127mr36315547itd.104.1499122218373; Mon, 03 Jul 2017 15:50:18 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.32.15 with HTTP; Mon, 3 Jul 2017 15:50:17 -0700 (PDT) Received: by 10.79.32.15 with HTTP; Mon, 3 Jul 2017 15:50:17 -0700 (PDT) In-Reply-To: <2F52A154-3F75-4DC9-9DBF-7C8047F65288@pfrc.org> References: <149909741417.22786.4679459342587499122@ietfa.amsl.com> <20170703160800.x6wcym2ma6jceqv7@Vurt.local> <20170703163846.224w6lxvbt4txqub@Vurt.local> <20170703173810.GA45648@Space.Net> <20170703175308.hembxkplaniz66wb@Vurt.local> <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> <09BFF794-6899-4DA5-8EF5-DDF86513BFBA@pfrc.org> <2F52A154-3F75-4DC9-9DBF-7C8047F65288@pfrc.org> From: Robert Raszuk Date: Tue, 4 Jul 2017 00:50:17 +0200 X-Google-Sender-Auth: mlD31S6o5aGUIF9Bn9t6KnWHauM Message-ID: To: PFRC - jhaas Cc: Job Snijders , idr wg Content-Type: multipart/alternative; boundary="94eb2c08c4e24d3f480553719751" Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 22:50:20 -0000 --94eb2c08c4e24d3f480553719751 Content-Type: text/plain; charset="UTF-8" Also Jeff what makes you assume that IX operators and IX env are so bad as compared with other enterprise or sp igp networks ? After all I do know a lot of enterprise PEs with such old code which is never going to support add-paths. Is next draft going to extend new SAFI to make regular RRs selecting paths based on client's feedback ? Is this really the direction we should be all endorsing here ? Thx R. On Jul 4, 2017 00:33, "Jeffrey Haas" wrote: > > On Jul 3, 2017, at 6:31 PM, Robert Raszuk wrote: > > What this is about is really a new idea of sdn controller with bgp and > distributed bfd for weak clients. > > > Regardless of what you might think of the idea of signaling back to the RS > to permit the RS to bias its own route selection, if you think the > connectivity test to the nexthop is of little value, you haven't done > nearly enough work with IXPs. > > -- Jeff > > --94eb2c08c4e24d3f480553719751 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Also Jeff what makes you assume that IX operators and IX = env are so bad as compared with other enterprise or sp igp networks ?

After all I do know a lot of enterp= rise PEs with such old code which is never going to support add-paths.
<= div dir=3D"auto">
Is next draft going to extend = new SAFI to make regular RRs selecting paths based on client's feedback= ?

Is this really the di= rection we should be all endorsing here ?

=
Thx
R.

On Jul 4, 2017 00:33, "= ;Jeffrey Haas" <jhaas@pfrc.org> wrote:


What this = is about is really a new idea of sdn controller with bgp and distributed bf= d for weak clients.=C2=A0


Regardless of what you = might think of the idea of signaling back to the RS to permit the RS to bia= s its own route selection, if you think the connectivity test to the nextho= p is of little value, you haven't done nearly enough work with IXPs.

-- Jeff

--94eb2c08c4e24d3f480553719751-- From nobody Mon Jul 3 16:56:43 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8FF91317AE for ; Mon, 3 Jul 2017 16:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.657 X-Spam-Level: X-Spam-Status: No, score=-2.657 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 YGS9c3y5ILAD for ; Mon, 3 Jul 2017 16:56:40 -0700 (PDT) Received: from mail-io0-f198.google.com (mail-io0-f198.google.com [209.85.223.198]) (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 50A0312F24E for ; Mon, 3 Jul 2017 16:56:40 -0700 (PDT) Received: by mail-io0-f198.google.com with SMTP id 100so103882092ioh.0 for ; Mon, 03 Jul 2017 16:56:40 -0700 (PDT) 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:date :message-id:subject:from:to; bh=hw7De9DLosNZHRTRdyVOL8MvIebc8zblLyylM/0Yr3c=; b=H8yN16HQS0hivJ3+j8TpNBbwiL9+0wPMitmNo0ZKNKA0ufArSMcHSivIFz49QfywZn uOXYnRePddWtXymQNUWPWRf26AD+9lIpbYE3So12zqbCWuYxhAvBD1uTCTGaZ6skQqT7 rwp4YxGjVpW0IsCalnrhtumhf08rFp+pt1+6WcVjKJ58K1LUatFdqtu+KlyMCAVncei0 Og16hMK1/yP84wessNLVKexV5V1tepGSmklsR2fM+eQaB2uoRggCXfaVaZXKkSYHVieS 0R695QT9CET3NFMpwQZ7+vUcFpmBzMDtWsET9q6yMSLjUa4dCoQUvUrZ1ezZUDKUw6C2 g1Ug== X-Gm-Message-State: AKS2vOyJcrmfjYP78ylmwt493aEm6ejfuYPy22USzZaH+Wnef/kqrouz klXeWJyNS3KwUnJ2bmlYHeZ6bwW98VeDRwYU9KlTcxQ= X-Received: by 10.107.168.35 with SMTP id r35mr16911172ioe.25.1499126199512; Mon, 03 Jul 2017 16:56:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.4.46 with HTTP; Mon, 3 Jul 2017 05:14:20 -0700 (PDT) In-Reply-To: <149824800169.17379.9099679082498238196@ietfa.amsl.com> References: <149824800169.17379.9099679082498238196@ietfa.amsl.com> Date: Mon, 3 Jul 2017 17:44:20 +0530 Message-ID: From: Nandan Saha To: idr@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Idr] I-D Action: draft-previdi-idr-segment-routing-te-policy-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 23:56:42 -0000 Hello! I have some questions on the NLRI encoding. 1. Can the value of NLRI length be less than 96 for IPv4 AFI and less than 192 for IPv6 AFI? IOW, can it be less than full mask length for the end point address? 2. If the answer to (1) is "yes", then what is the rationale for keeping the end point address field of the NLRI fixed length? (4 or 16 bytes depending on AFI). Should the end point become variable length like the NLRI encoding defined in RFC4760? 3. If the answer to (1) is "no", how are summary addresses to be represented? Another question which is unrelated to the changes in version 7 of the draft. Section "4.2.1. Acceptance of an SR Policy NLRI" says " If the NLRI is not one of the legal lengths, a router supporting this document and that imports the route MUST consider it to be malformed and MUST apply the "treat-as-withdraw" strategy of [RFC7606] " It's not clear to me how a receiver can extract a valid route from a malformed NLRI. The "treat-as-withdraw" can be applied if the NLRI is well formed but some other attributes are malformed, which seems to be implied by the following line at the end of the subsection "A unacceptable SR Policy update that has an invalid NLRI portion MUST trigger a reset of the BGP session." Thank you! Best regards, Nandan On Sat, Jun 24, 2017 at 1:30 AM, wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Inter-Domain Routing of the IETF. > > Title : Advertising Segment Routing Policies in BGP > Authors : Stefano Previdi > Clarence Filsfils > Paul Mattes > Eric Rosen > Steven Lin > Filename : draft-previdi-idr-segment-routing-te-policy-07.txt > Pages : 30 > Date : 2017-06-23 > > Abstract: > This document defines a new BGP SAFI with a new NLRI in order to > advertise a candidate path of a Segment Routing Policy (SR Policy). > An SR Policy is a set of candidate paths consisting of one or more > segment lists. The headend of an SR Policy may learn multiple > candidate paths for an SR Policy. Candidate paths may be learned via > a number of different mechanisms, e.g., CLI, NetConf, PCEP, or BGP. > This document specifies the way in which BGP may be used to > distribute candidate paths. New sub-TLVs for the Tunnel > Encapsulation Attribute are defined. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-previdi-idr-segment-routing-te-policy/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-previdi-idr-segment-routing-te-policy-07 > https://datatracker.ietf.org/doc/html/draft-previdi-idr-segment-routing-te-policy-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-previdi-idr-segment-routing-te-policy-07 > > > 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/ > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Mon Jul 3 18:07:47 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBDD129AD0 for ; Mon, 3 Jul 2017 18:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_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=juniper.net 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 KQKv3NbJ7FMQ for ; Mon, 3 Jul 2017 18:07:44 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0116.outbound.protection.outlook.com [104.47.36.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 261DE129AA3 for ; Mon, 3 Jul 2017 18:07:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5/CkoNRHJ/vgCkbX+pD7ZoZMrMZspqV+NUpcfoyMEd8=; b=INBwYl5P1+CB4uXf+v2kwX6ecHX0LECMGlBhOIHqlXFCteguVZVoUOzysqWiTN10hxcjk3lv88DmHCTvIgOWeTEIDnUUEugCZa6Cd9rogs7ld8ggqI7J51QruRxtavr3BgURS1sIFIEoHNyQXYeS0Nvf9iRv2l6L9+8l6Fzv5CE= Received: from CY1PR05MB2507.namprd05.prod.outlook.com (10.167.10.134) by CY1PR05MB2714.namprd05.prod.outlook.com (10.167.18.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.6; Tue, 4 Jul 2017 01:07:42 +0000 Received: from CY1PR05MB2507.namprd05.prod.outlook.com ([10.167.10.134]) by CY1PR05MB2507.namprd05.prod.outlook.com ([10.167.10.134]) with mapi id 15.01.1240.013; Tue, 4 Jul 2017 01:07:41 +0000 From: John Scudder To: Robert Raszuk CC: John Scudder , idr wg , Job Snijders Thread-Topic: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt Thread-Index: AQHS9D5iAfPwC43N0E6gQjXGHlpN/w== Date: Tue, 4 Jul 2017 01:07:41 +0000 Message-ID: References: <149909741417.22786.4679459342587499122@ietfa.amsl.com> <20170703160800.x6wcym2ma6jceqv7@Vurt.local> <20170703163846.224w6lxvbt4txqub@Vurt.local> <20170703173810.GA45648@Space.Net> <20170703175308.hembxkplaniz66wb@Vurt.local> <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [107.77.195.125] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR05MB2714; 7:qk0adgDDCdL9HIZbGWaIUyx1kF95wNClnXvsFic8yRdq2ufjL+qZDvQmTVka8bhi1M81selZghKhTxsYbzVC3iY66bmVlSFGFb049Wmq0LQGwpxuto7Gse9I6YKc6k7FuYy9PGY0yeiOglS4/q4rF/cCKACbpep4D8a2li/cFOr1kFC+RINkFfQX7w0TFWUTBoAT47ZUP7qNE2uIlAvqspbkvT54QKlo1g8vUpLW4HcWzZDCHntHzFdx+1zLNIf/U1YAsoNMHQLHIop+kMq7CXWFMomGszd2u1VD+B+dZHTj3aoU0iN/jTH6uRjKV6w60uSkLTBOR3dbvkq86jFZpc37rS1iPcgcuhQ1hZYwNoVH/+fOZPV7q304Xzq6nhsc5cAsiqObKxFebnsi7QiYIHHbtEmqu2zi+ByROiEKCL0XykGr2spxvtX6MCoLcz+4bjHoLpgE3AiOaE6W3CU1A09Hr4jI2zXz3ZJCQv3h2c0vtAe6ZejSR32fq1bPaNuJ/cXFMRtc0VB+OcI30GpHTPN/w7/xa16XFnQ2yNrEWzprwgYni3NI6HBXDIGTzk5JmMbbOowJbq2pr3+HRTJ3mKCV6PDSDNO+NtYSG5DO3ogxdl+3iZTM4MunT3JaoCguFG/Ge+K+zryVrL+HzVB4DRHIvexG29p5kRFZ1QgdgqyvPjAkRWC30AP8017E9zTzlIQicI2xXaxvQL6x9DBEDLBlaDusjdkwb6M8bH3QqSfq0HVk0AhsMl20a3AzjR8HoVQaVjYuGteTrm3XaqqeRi5i7WrdGGdy2zMEkg7hrXs= x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39450400003)(39860400002)(39410400002)(39850400002)(39400400002)(377454003)(24454002)(14454004)(76176999)(4326008)(6916009)(83716003)(6512007)(2950100002)(99286003)(54906002)(6246003)(189998001)(6116002)(110136004)(36756003)(38730400002)(53936002)(102836003)(478600001)(77096006)(6486002)(86362001)(305945005)(3846002)(66066001)(82746002)(3280700002)(8676002)(81166006)(7736002)(2906002)(54356999)(230783001)(25786009)(33656002)(229853002)(2900100001)(8936002)(50986999)(6436002)(6506006)(5660300001)(53546010)(93886004)(3660700001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2714; H:CY1PR05MB2507.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: 01b25e26-c650-42ad-8a7c-08d4c2791230 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY1PR05MB2714; x-ms-traffictypediagnostic: CY1PR05MB2714: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211171220733660); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR05MB2714; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR05MB2714; x-forefront-prvs: 0358535363 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <351A62A96ED206499A8A316C08F907E3@junipernetworks.onmicrosoft.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jul 2017 01:07:41.7147 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2714 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 01:07:46 -0000 On Jul 3, 2017, at 6:22 PM, Robert Raszuk wrote: >=20 > What happens when RS gets 100 paths for policy eligible net for a given c= lient ?=20 >=20 > Client will enable waist Waist? > of 100 bfd sessions and what is much worse will report state of those 100= next hops to RS ? Unclear to me why reporting 100 next hops is so bad? > This is so bad ....=20 Perhaps you can elaborate on why you think so.=20 --John= From nobody Tue Jul 4 01:39:01 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63E73131B26 for ; Tue, 4 Jul 2017 01:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 zIUWnr58OOxa for ; Tue, 4 Jul 2017 01:38:57 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90E2E131B2B for ; Tue, 4 Jul 2017 01:38:54 -0700 (PDT) X-Original-To: idr@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 4873D41BD6 for ; Tue, 4 Jul 2017 10:38:53 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 21E9A41B94; Tue, 4 Jul 2017 10:38:53 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 1EE6E35A1B; Tue, 4 Jul 2017 10:38:53 +0200 (CEST) Date: Tue, 4 Jul 2017 10:38:53 +0200 From: Gert Doering To: Robert Raszuk Cc: PFRC - jhaas , idr wg Message-ID: <20170704083853.GJ45648@Space.Net> References: <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> <09BFF794-6899-4DA5-8EF5-DDF86513BFBA@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 08:38:59 -0000 Hi, On Tue, Jul 04, 2017 at 12:31:17AM +0200, Robert Raszuk wrote: > If client talks add-paths you send them two paths. You may send them more > if they wish so. > > It is just broken desing to signal failure between nodes to get new paths. > PIC has proven this long time back. > > What this is about is really a new idea of sdn controller with bgp and > distributed bfd for weak clients. > > Now maybe we could understand what are those weak clients who can not > handle two paths for a given net ? What makes you assume that these two paths will *work*? IXPs are big (like, 600 nodes), and there might be a partial outage that kills off everything behind one 100G link in a 4x 100G bundle -> 100+ remotes are gone. Two paths won't do much good then, if both next-hops are in that set. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Tue Jul 4 01:41:40 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF157131B34 for ; Tue, 4 Jul 2017 01:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 KbzDbyF7BqpY for ; Tue, 4 Jul 2017 01:41:37 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 925571316A4 for ; Tue, 4 Jul 2017 01:41:37 -0700 (PDT) X-Original-To: idr@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 4086B41BD8 for ; Tue, 4 Jul 2017 10:41:36 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 1AD9C41BD6; Tue, 4 Jul 2017 10:41:36 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 0C80935A36; Tue, 4 Jul 2017 10:41:36 +0200 (CEST) Date: Tue, 4 Jul 2017 10:41:35 +0200 From: Gert Doering To: Robert Raszuk Cc: PFRC - jhaas , idr wg Message-ID: <20170704084135.GK45648@Space.Net> References: <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> <09BFF794-6899-4DA5-8EF5-DDF86513BFBA@pfrc.org> <2F52A154-3F75-4DC9-9DBF-7C8047F65288@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 08:41:39 -0000 Hi, On Tue, Jul 04, 2017 at 12:50:17AM +0200, Robert Raszuk wrote: > Also Jeff what makes you assume that IX operators and IX env are so bad as > compared with other enterprise or sp igp networks ? Nobody said "IX operators are bad". But IXP fabrics are tricky things - too large, too many paths, not enough visibility into the end nodes (= participant routers), critical path for many users. > After all I do know a lot of enterprise PEs with such old code which is > never going to support add-paths. Last time I looked, IDR wasn't really targetting "enterprise internal" Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Tue Jul 4 02:02:59 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65276131C19 for ; Tue, 4 Jul 2017 02:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, 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 yIT5T_8ZrXUt for ; Tue, 4 Jul 2017 02:02:57 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 E1352131C17 for ; Tue, 4 Jul 2017 02:02:56 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id m84so68502695ita.0 for ; Tue, 04 Jul 2017 02:02:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=NZhVlwaVwdpAcjWbTw0CdjdstVOQzx0f7GQRnty96/w=; b=BmSH8Zku4O0jwNqvBg7LAXBeuFM270Fv2yWEKRbCVPbXQ8khEn2Xfz6Et5ArTveFUR 7EoZDfIMEZeX9t2OHLj8O7vbEqdGjT1yQIofeUa9YQCzDxfHB7vHz0RhtRiv69e9k8Dn hiH1Wdu8IM0jUCRX0L52BZcrJO/XsrCXhF0HNDNPj00m8Ov7wRNuuC4oxohzs6vG/uUE /1tZQk89tvobokjHJDI3jbc5GjQQlMy7uLVh1YVycbQmQtONaH9ybTSCSUKji5x4qq3O CYb5KeCBrFJ72WT5tNWFNrOhX+rGxEJhVzf9R7lpN6aYI2zg5smkYImpsD9UphFpSmsG smFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=NZhVlwaVwdpAcjWbTw0CdjdstVOQzx0f7GQRnty96/w=; b=OFMz2/8gtFvxdw7IxEVLWtoJJyZk6j8nwk+KeXnuZwSzBdypLxpaEnksg5/Q8RFsKU Jy3SOjlIVPa95fBtedTxHLy4XavKRBUISUM4zxxDNZG1Uajgfi2aEqnr7QYYHiD4uRXf giC/XYFPNtPcvONrxueTPdZt8MOD1+jtkzsTyyUJFALW0qAlXLdvxFsbBx8NG8OxeLDx RJ6ULNCMESG7uODcE3SNg3vw1GEVVCmwzw8e0VnguPeGx8tOV+xiN6WiulXwzD5rcRGu LVAYVOgPbg3wxIGiKXQp3IhxLEIgk+XKPZo1toaFUax7RmrXJ/vpT5q6LBsxu1tVg+hA BMag== X-Gm-Message-State: AKS2vOyXQcMSW4uHr84ihkuBW1OGmZ0b54zaYcHt65jYvlWOFgCumorz ZiUnQI62+xBIEBvJ1DMOyuoLtxTEOg== X-Received: by 10.36.139.1 with SMTP id g1mr34350345ite.18.1499158976228; Tue, 04 Jul 2017 02:02:56 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.32.15 with HTTP; Tue, 4 Jul 2017 02:02:55 -0700 (PDT) Received: by 10.79.32.15 with HTTP; Tue, 4 Jul 2017 02:02:55 -0700 (PDT) In-Reply-To: References: <149909741417.22786.4679459342587499122@ietfa.amsl.com> <20170703160800.x6wcym2ma6jceqv7@Vurt.local> <20170703163846.224w6lxvbt4txqub@Vurt.local> <20170703173810.GA45648@Space.Net> <20170703175308.hembxkplaniz66wb@Vurt.local> <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> From: Robert Raszuk Date: Tue, 4 Jul 2017 11:02:55 +0200 X-Google-Sender-Auth: TUCzAJI8HvR1Ntra0_0M4ttyqY0 Message-ID: To: "John G. Scudder" Cc: Job Snijders , idr wg Content-Type: multipart/alternative; boundary="94eb2c049bc43d750d05537a263c" Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 09:02:58 -0000 --94eb2c049bc43d750d05537a263c Content-Type: text/plain; charset="UTF-8" John, Today vast majority of OPEN policy clients share single RS view/table so you do best path and update generation once for all of them. The moment you introduce per client state you are braking those apart into individual views. Even those with policy today have subset of nets in their own tables not all. So this optimization also goes away. So if you send clients real paths they locally can repair failures without any additional state per client on RS. That is why I called it "a waist". And this is not 100 it is 100 x number of clients say 1000 of dynamic state which triggers 1000 best paths and update generations on propagated failures of best path. Thx R. On Jul 4, 2017 03:07, "John Scudder" wrote: > On Jul 3, 2017, at 6:22 PM, Robert Raszuk wrote: > > > > What happens when RS gets 100 paths for policy eligible net for a given > client ? > > > > Client will enable waist > > Waist? > > > of 100 bfd sessions and what is much worse will report state of those > 100 next hops to RS ? > > Unclear to me why reporting 100 next hops is so bad? > > > This is so bad .... > > Perhaps you can elaborate on why you think so. > > --John --94eb2c049bc43d750d05537a263c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
John,

Today = vast majority of OPEN policy clients share single RS view/table so you do b= est path and update generation once for all of them.

The moment you introduce per client state you = are braking those apart into individual views.

<= /div>
Even those with policy today have subset of nets in = their own tables not all. So this optimization also goes away.

So if you send clients real paths th= ey locally can repair failures without any additional state per client on R= S. That is why I called it "a waist".

=
And this is not 100 it is 100 x number of clients s= ay 1000 of dynamic state which triggers 1000 best paths and update generati= ons on propagated failures of best path.=C2=A0

<= /div>
Thx
R.

On Jul 4, 2017 03:07, "= ;John Scudder" <jgs@juniper.net<= /a>> wrote:
On Ju= l 3, 2017, at 6:22 PM, Robert Raszuk <robert@raszuk.net> wrote:
>
> What happens when RS gets 100 paths for policy eligible net for a give= n client ?
>
> Client will enable waist

Waist?

> of 100 bfd sessions and what is much worse will report state of those = 100 next hops to RS ?

Unclear to me why reporting 100 next hops is so bad?

> This is so bad ....

Perhaps you can elaborate on why you think so.

--John
--94eb2c049bc43d750d05537a263c-- From nobody Tue Jul 4 02:26:54 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4311B131543 for ; Tue, 4 Jul 2017 02:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 DVWXZP1oVVqH for ; Tue, 4 Jul 2017 02:26:51 -0700 (PDT) Received: from mail-wm0-f46.google.com (mail-wm0-f46.google.com [74.125.82.46]) (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 1B57F12EB31 for ; Tue, 4 Jul 2017 02:26:50 -0700 (PDT) Received: by mail-wm0-f46.google.com with SMTP id w126so189943256wme.0 for ; Tue, 04 Jul 2017 02:26:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=hpfsOW84eIbHGzpttNIxPZRde4oxr/E/Ds3L3Al8JHU=; b=A6xmkT1Qo1Ew3XfpsOGwaDA05lmmsHldFw+P8iTezhk9o+HHXT+auOnLEMnMABpAJL L1tBBGhbHWRfL7abIQAy54hv5eemPvOMLe3rkNtkvVjyNqCQ50MendB2YKeQ/UNv3CGV uxh/vWRwqNrcAiIZp/X4f9+ehaJ/+gCMArWFgwbqNkfQ0IB6bbE+rv94LenUTr9pMrN2 NpBNOVn2152FUW68XliHcr2VmKlhUkWktOtuip/+C2BpiEEKs1fGTGoM6vSnQOM1sAd2 9TkdYIMNT8LHbpsnm4HFheaBZ5vCDGA0Abr0cnEKuyFL0ArxJKWz9VwFKuhw0EFLKJ2n QbRg== X-Gm-Message-State: AKS2vOzWe0XfW6MCF/47IuRyIjqjuzNTQqSeWJ0cOz/IZHg2ctMV6qi6 FEeuCAaaXkd5ShiZ X-Received: by 10.80.173.198 with SMTP id b6mr15177239edd.81.1499160409340; Tue, 04 Jul 2017 02:26:49 -0700 (PDT) Received: from localhost ([89.200.47.198]) by smtp.gmail.com with ESMTPSA id b30sm8853881edd.6.2017.07.04.02.26.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Jul 2017 02:26:48 -0700 (PDT) Date: Tue, 4 Jul 2017 11:26:46 +0200 From: Job Snijders To: Gert Doering Cc: Robert Raszuk , idr wg Message-ID: <20170704092646.yzahxshfjc5o66pg@Vurt.local> References: <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> <09BFF794-6899-4DA5-8EF5-DDF86513BFBA@pfrc.org> <20170704083853.GJ45648@Space.Net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170704083853.GJ45648@Space.Net> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: NeoMutt/20170609 (1.8.3) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 09:26:53 -0000 On Tue, Jul 04, 2017 at 10:38:53AM +0200, Gert Doering wrote: > On Tue, Jul 04, 2017 at 12:31:17AM +0200, Robert Raszuk wrote: > > If client talks add-paths you send them two paths. You may send them > > more if they wish so. > > > > It is just broken desing to signal failure between nodes to get new > > paths. PIC has proven this long time back. > > > > What this is about is really a new idea of sdn controller with bgp > > and distributed bfd for weak clients. > > > > Now maybe we could understand what are those weak clients who can > > not handle two paths for a given net ? > > What makes you assume that these two paths will *work*? > > IXPs are big (like, 600 nodes), and there might be a partial outage > that kills off everything behind one 100G link in a 4x 100G bundle -> > 100+ remotes are gone. > > Two paths won't do much good then, if both next-hops are in that set. Yes, two paths won't help when faced with catastrophic events (where large clusters of participants of the IXP go offline). But should it? In that case the IXP participant will have to use other means (IP transit, private peering) until the IXP has been repaired (usually done within a few hours?) We already observed that path _diversity_ isn't that great at IXPs in the sense that often there is only a single path towards a prefix: https://mailarchive.ietf.org/arch/msg/idr/qhgG2cCs0UuDHdPRdfDIMs7jeHs I posit that it is safe to assume that other (non-RS) paths will always exist (via transit, other peering), and as such in the trade-off between keeping more state at the RS vs trying to keep the RS lean and mean, the design parameters should be as following: - the main purpose of this draft is to ensure that each RS participant sets up BFD sessions to the other participants of interest, the main purpose is _not_ to ensure there are always paths even if half the IX is on fire. The priority should be quick fault detection, not to "make the best use of the IX under any and all circumstances". - we should work from the assumption that if a client supports draft-ietf-idr-rs-bfd, it will also have support for ADD-PATH. If we cannot assume this, I'd like to understand why. - explicitly consider scalability issues. The bigger internet exchanges are struggling with their current route server load, so if IDR adds any computational cost to their list of tasks, it'll need to properly justify that. - The technology facilitate setting up the minimum required set of BFD sessions, not the maximum. Kind regards, Job From nobody Tue Jul 4 03:48:49 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0601A131E29 for ; Tue, 4 Jul 2017 03:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 NkCcKDmUFw8W for ; Tue, 4 Jul 2017 03:48:46 -0700 (PDT) Received: from mail-wm0-f53.google.com (mail-wm0-f53.google.com [74.125.82.53]) (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 C8BA5131E2A for ; Tue, 4 Jul 2017 03:48:45 -0700 (PDT) Received: by mail-wm0-f53.google.com with SMTP id w126so192013189wme.0 for ; Tue, 04 Jul 2017 03:48:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=YOWKYcHhLyD9+a2VMIcLo1g60vyQR0YQAwYjfx1njQM=; b=Z3En2zD5+gbVw1tSNwZK+/GK9FHI2oAdBLK3KW413UtkGngd3n9a5xQb06XyNY5p/D 9VZnqm8tEYiB7IBv/6k5swMKAUN0+4sdvE9d8IfhMRwKilt68Fho0Fm1AQ5u/JFPuuZg EkasD56deFxBZmnKhs/nx1Zt7Q/BY1vJUz8wHpi6+QP/NtL/xxCLvE81RZbKtY315rZR FolTSc8UgdQpNfsc/PlsWbW3PD2QoD2aK3XY6UUzROmquDRStX0DRvww0/OnvHv4h/fd udtr+4PWAR1OK366xOeNoKAj3syMYBSx0C5kBhE41/1Z3PgtGpmpQdWuR+aBZQ+a3kFP 681g== X-Gm-Message-State: AKS2vOy9dhTGFCXFQxBcpX8Dc24tA1lWO7kdP/+bdD7kQej4n4DISsJf nqyVXQI96U+YprMK X-Received: by 10.80.182.180 with SMTP id d49mr18064288ede.56.1499165324096; Tue, 04 Jul 2017 03:48:44 -0700 (PDT) Received: from localhost ([89.200.47.198]) by smtp.gmail.com with ESMTPSA id f26sm8565832edd.10.2017.07.04.03.48.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Jul 2017 03:48:42 -0700 (PDT) Date: Tue, 4 Jul 2017 12:48:40 +0200 From: Job Snijders To: Jeffrey Haas Cc: idr@ietf.org Message-ID: <20170704104840.mg5bflnmmjlv4jbi@Vurt.local> References: <20170703175308.hembxkplaniz66wb@Vurt.local> <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> <09BFF794-6899-4DA5-8EF5-DDF86513BFBA@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <09BFF794-6899-4DA5-8EF5-DDF86513BFBA@pfrc.org> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: NeoMutt/20170609 (1.8.3) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 10:48:48 -0000 On Mon, Jul 03, 2017 at 06:20:28PM -0400, Jeffrey Haas wrote: > > On Jul 3, 2017, at 5:55 PM, Job Snijders wrote: > > > > I'm not sure whether events will be packed together this neatly. > > > > Questions that remain: > > > > - is it absolutely necessary for the RS to be aware of the entire > > bfd session topology state? > > The draft is written with the idea that some/many devices *won't* be > aware. If the state is Unknown, things still work. Like with today's RS? "This draft doesn't make it worse" is hardly an impressive statement ;-) > > - is it reasonable to assume there will be BGP speakers that support > > draft-ietf-idr-rs-bfd, but not RFC 7911? > > > > - if the RS is not stateless (in this regard), can we reasonable > > expect things to scale? (As it currently stands the industry has > > trouble scaling RS services) > > > > If it was not clear from previous messages: I am supportive of the > > idea of "assisted BFD" to take away some obvious downsides of route > > servers. Just not sure the proposed approach will work out good > > enough. > > The way I suggest reading this: > 1. BFD to the BGP nexthops is really desirable. It lets you avoid > blackholing in several well known scenarios, including the RS based > distribution of routes. yes. > 2. Regular BFD needs both sides of the session to be prepared. In the > absence of full mesh BFD configuration, there needs to be a feature > that permits the RS to notify the clients what nexthops are of > interest on both sides. yes > 3. The feedback mechanism permits a RS to send alternate paths - when > it is capable of doing so - when a given nexthop is unreachable by a > given client. > > The third mechanism is very optional. Many RSes need not implement > any sort of new path selection if they don't want to; points 1 and 2 > are still helpful. agreed. > To the points about add-paths, and statefulness, even if the RS > clients spoke add-paths, you have to choose what level of path scaling > you want to do. If you're to the point of sending everything, a RS > isn't even necessary. And clearly, people use RSes partially for > "remote policy" - effectively path pruning. > > Looked at a somewhat different way, choosing the backup paths is no > different than add-paths or diverse paths feature choosing the next > best path. But since the RS and the client could have already > conveyed the possible set of nexthops for the view, there's no need > for stepwise discovery. Perhaps this point needs to be made clearer > in the draft. But any churn in the possible set of nexthops, directly results in BGP churn, where as when the route server is not kept in the loop about who can reach who, there will not be any churn at the route server level when 2 RS participants cannot reach each other (temporarily). Kind regards, Job From nobody Tue Jul 4 07:27:52 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADA1D13192D for ; Tue, 4 Jul 2017 07:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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 40Xu25eTIRHj for ; Tue, 4 Jul 2017 07:27:49 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::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 D65FA13161A for ; Tue, 4 Jul 2017 07:27:48 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id r36so72411159ioi.1 for ; Tue, 04 Jul 2017 07:27:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=nPUjz8ffe4zccnZyMsWL2JCyNh+WTl4O911LxfBPaCs=; b=HZQpAqX2xnI1r5yPZVfinY2mwJMPPT+RcN4kkRhMyfcF8g6bYbGgzQp44JZgFt2A0O +/2nisT4/5SgbCS6oLCBzq0eD1edmYxyP5AYG93tBoxREePdUiNOLS1nOwn6caNQjy03 GL0ESPd5KX9a4cBfyEOLmrNu+1KrbINVlsGDWPfWeWr4uE7bPxH+Gz6TZXFyPgZA95Qe /EeX0Z08XrqGg215wZ7gBsnpbWVE8gRJX5jIFA1uKQvNB7YluKje7orvj7/1Sagz8wr9 d1yPgw6HJVISNzCQRS7rNz1JaTK7fjZOVVpCP0G52+xC37ShXXSNlQUo9vchq7moJbod DAew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=nPUjz8ffe4zccnZyMsWL2JCyNh+WTl4O911LxfBPaCs=; b=Gr9ts/BWG8x358+gJoJdjGzrqXGnkM5v/x7lAX5sg9GUBOV5C2LPv7lBuX287MVBD9 CVu/S2rg0ln6eE1hBiUx2BCdg43vGg2L65z5usT48rO9rYqQROsHjOzrEyXdatyvTxnB oDdrnlISJ0b3N77Kdfw0Tmnrvc/BnNmEGVRzWDg/BgXvxcOQPOjr3bzVeBXCtfFdJdkM lF/M3GGT3d4V60ISwZrYCzcA+LnBeKFoBPp5crcBDSryG9SUN8ULLkMR+k304ShZAk1A vh0Q9qsytGM3L/o/ToLVZn3m3R5Fq8pWxk4/65YZh5YuP50EPHSH4Lpk7U+dxDXfuGm5 ec3Q== X-Gm-Message-State: AIVw113R6UCF2um0GgwVDm8Pjl49AmhWSW4IiiK7z84yUCbGoWn7tGj2 5jca61bJ3jQ4GLu8aYRRryLf4fP0ea6Z X-Received: by 10.107.28.84 with SMTP id c81mr11397954ioc.186.1499178468026; Tue, 04 Jul 2017 07:27:48 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.32.15 with HTTP; Tue, 4 Jul 2017 07:27:47 -0700 (PDT) Received: by 10.79.32.15 with HTTP; Tue, 4 Jul 2017 07:27:47 -0700 (PDT) In-Reply-To: <20170704084135.GK45648@Space.Net> References: <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> <09BFF794-6899-4DA5-8EF5-DDF86513BFBA@pfrc.org> <2F52A154-3F75-4DC9-9DBF-7C8047F65288@pfrc.org> <20170704084135.GK45648@Space.Net> From: Robert Raszuk Date: Tue, 4 Jul 2017 16:27:47 +0200 X-Google-Sender-Auth: ce6ieLePg8Qe_LreMnIu0nW9x0I Message-ID: To: Gert Doering Cc: idr wg , PFRC - jhaas Content-Type: multipart/alternative; boundary="001a1140986e0ab4b105537eb067" Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 14:27:51 -0000 --001a1140986e0ab4b105537eb067 Content-Type: text/plain; charset="UTF-8" Gert, The argument that we need controller rather then route server because " IXP fabrics are tricky things" just does not convince me. Let's compare your arguments vs MSDCs: > too large DCs today have fabrics which are orders of magnitude bigger then any IX on the planet. > too many paths Please explain where for a given net so many paths are coming from. If IX client is connected to 2 or 3 ports in a given IX it is max. As clients share their own nets it is hardly that they will share someone elses nets and volunteer to become free transit. > not enough visibility into the end nodes (= participant routers) Please observe then when in MSDCs compute nodes attach to a fabric such fabric has zero visibility into their state. > critical path for many users. Well since going via RS in IX is a local optimization there is always path around it. Here pls let's not mix direct peerings via IXes as their control plane is also direct and never goes via any route server. Cheers, R. --001a1140986e0ab4b105537eb067 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Gert,

The ar= gument that we need controller rather then route server because "=C2=A0IXP fabrics are tricky things"= just does not convince me.

Let's compare = your arguments vs MSDCs:

> too large

DCs today have fabrics whi= ch are orders of magnitude bigger then any IX on the planet.

> too many paths

Please explain where for a given net so many paths are coming from.= If IX client is connected to 2 or 3 ports in a given IX it is max. As clie= nts share their own nets it is hardly that they will share someone elses ne= ts and volunteer to become free transit.

> not enough visibility into the end n= odes
(=3D participant routers)

Please observe then when in MSDCs compute nodes attac= h to a fabric such fabric has zero visibility into their state.

> critical path for many users.

Well since going via RS in IX is= a local optimization there is always path around it. Here pls let's no= t mix direct peerings via IXes as their control plane is also direct and ne= ver goes via any route server.

Cheers,
R.=C2=A0

--001a1140986e0ab4b105537eb067-- From nobody Tue Jul 4 08:55:32 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B240A132137 for ; Tue, 4 Jul 2017 08:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.012 X-Spam-Level: X-Spam-Status: No, score=-3.012 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_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, 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=juniper.net 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 OxwDOwLnaJvZ for ; Tue, 4 Jul 2017 08:55:29 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0111.outbound.protection.outlook.com [104.47.32.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21D79132131 for ; Tue, 4 Jul 2017 08:55:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9yy5BOqXglhzBXHD/W8LEA1ydybsLs4BKbbKIxo5zbY=; b=jspw06x5u4G4tp29t5RFoJl/hhAu7z9zsJlSo3xACSHm5c5sgWtCTDFW46Ef+Szx4BDYO12LwZ78Bd022uh3HC54XEZezs6rnNxKpwTZ+ZAcSUGxSd4vagLmrKBcYPfJ/GMh383ma0ZxI49oWmW3zuMRtG7e+orcc4EjsOSfeyc= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; Received: from askhan-sslvpn-nc.jnpr.net (66.129.241.13) by SN2PR05MB2510.namprd05.prod.outlook.com (10.166.213.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.6; Tue, 4 Jul 2017 15:55:27 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: <20170704104840.mg5bflnmmjlv4jbi@Vurt.local> Date: Tue, 4 Jul 2017 11:55:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <20C02BA3-5C13-46FB-AFE8-85D61E469EA1@juniper.net> References: <20170703175308.hembxkplaniz66wb@Vurt.local> <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> <09BFF794-6899-4DA5-8EF5-DDF86513BFBA@pfrc.org> <20170704104840.mg5bflnmmjlv4jbi@Vurt.local> To: idr wg X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: BN6PR16CA0017.namprd16.prod.outlook.com (10.172.212.155) To SN2PR05MB2510.namprd05.prod.outlook.com (10.166.213.19) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 51c44ae4-8756-41b6-7d19-08d4c2f5175d X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(48565401081)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:SN2PR05MB2510; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2510; 3:Ed5HFvAffwnZVDzxkotVNtX4wxibpq5yEHAzVH4dKBdWU4mG8dUykLMG6F/RP/YF3URvjVO7in0R5CFCWOtCwIBMgMihmlZ56gDU4iODI4CXDNbeBOE/SXtSpFk0j+S/awnu9K0fAG/n7vM9A+1XXO5/xjGx0oj29IgUB6BqePOXp4WGz2JwyJdxeCKsIJpuZmPZE1O0SSB5vGb/Ojah2cHTn5fAnJ7eTmMm09CdfBu+V8e+0PSJ4sC2BAh6//hpi8jd2OoGDMWKc7jQeu+IExqy04iZqpu/2uqIOsC3+rglR8Y9OltWdEGa03kKkXcm8ToWt3cu+tcSw61BMVRFu+9DBL6bU1blqyVkY7g8OdmADYBocoQPfBBpg5NawcX0+3ve0K+1zjFVBgVn8jPQksSeC7fzAkgL8xIdf+OTGH5+sVw6lqGmeNJ2sjlCa5gIcrylBBTwajUq1fcFCfFqnkSoddHHBG4PA+1MoNj6EEibUuEeTSg6mbhRQB6fBa4n4bE3AzfaBIo2RMrGDMTvjHJv2Gx70/NZCWrVUINo/KJizgxFzjxppxw5wDZ1kxkH0NylY3yrz+Vrm/PErkxVzXMqC9oX9XRP3mwxQuB9pTPOOmqi8Zw3teiA7q5yZvuPZSlta6AEb7DbB7KRsSIGm/7/AP29o9ouFxSIY48JjutUWMKE3pDwDSGr4iCACjnRQc/Nv3AeWQdO6LNNQVO/nfT+ER9uN10ABPCKzlsjfBsPeDeBUqJNAs3pXCO1TyNPuGo46Sz3WyZKQfZh0jKjGw== X-MS-TrafficTypeDiagnostic: SN2PR05MB2510: X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2510; 25:h7JyhBhhm4VRJqsvt663Rgfjaj3tB7R3FjKDYMfv4obG3WP/tvk4a9MI8ESB2/J0WdpSCa3Cqb2sDTLNi+CECFx4tpO+fi4Opblm/IPMEK8HfUbJkmTM9rdAEV3ibgElqbf5vzDO7gYDmg2V5eFZqVEZ2wr7rOnrJUwgrcUQ3EK4v5z2pcomLz8b7MM1RKssM1V7kpLjYrmxIZMZ26UAuhBa4qnqoWOczT1agHmOKmyson4veSimCO8825w9SelBRf8zxwAStp3Fx4nWbpGbugKGJyTbfTkDK7Wlrmiq84UZX/6NrKb36lVW8iuGAglUGq76DrRZTvXIFGTJ1grWFSqGCxqFm8Jtze1kuY9KIEt1gsLcHKZx7T0g2SpRsgLDewux4PPyUxBDvUt3zILswdsX75VEf5UzWbUO+1aVGOC4cVS8UfHIxHaLKhyW7wbiSFZ/mOKu1xP+JfqeREijHxJjT4gEVZaUSJASOtowN+Qdtz0JxD1Rf2z+eeN8aho7P7NNqOISoHZa0bZ3nyjLlX0UbfUN1vou6BMr64e5e3PFPYd3i5IdV0/7VpOeOtrWkUTQsdZChx5CzoMiiGUgJbyd8maGK8We6+3jvzidlC2XM6mLQNElAk+YGkslSLp7X2224EYNn6pE0+1UYWupJnABQKceIEaUxOOYihOt+5vQA5JrlfjkMsFLxPNcY6FtXJhS/riYK9YwbW9jw6WT+pPBIxb8nwBTh4SH5qSqdhoGWCvAcsSr/iVBE3bME/NBQ5f7VMFNrvua3BWWyNHI4h9dsdHjjYGClRM5CO7HHRvhuamw+VNqLYpjn1205omNIN1JdEXHzy1tkvwO1WgnObhgKccU20tDt0OE11mgaMYi7E0ibMGssjSBV78/PLtJTScPpaWoydhEy2nQBlt42e/hXMojrCyy4ZU789E40Hc= X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2510; 31:4sbWETAkB2dsQ5UH6t2Ct8juDDSBM5NgF7ayGZHrcgYd6UMHnxRKcUF/E6fQBwuzUc3NmeWlpojZns24TdWcirNM3Kyp1IXQ54ehuNWHr8FgdL76VEzJmKXdOjJf18Pgzj6ITv8sNqMAl0xNDcca36AQCbjrc5vLK09m5zuc9Y6H9XVpjDVCxfG2G2W03QSZQSjUwv9B0cskBJLVVJnSM+/HBQN96XB5oLyi3psV2JqTFN7JT8VjQRRDRrhEAuiU9U5fRe9YuuZt7nq+YxbbzaI3MHk5VIwmy6/URNMKcPB0yRT76EAF9iGML0OSYhlHEsp3wyofWZ6uydqE1ZQ5xuFN487OHGbyimoSVRV5rKeNqJqW9Untfk2rxthqfFzd2tNTSU2RXpWYeVeRxS3E39Rx+y+q30eni7htEx6dCmHWGtcegwXC5ud/RvLVa1EB8qw07ppc7ltqSOJdyE9PuKUM0r6TDLXKG7biKjI/tRY5olsnwP0zhSCi5VansMDxm2YYxJjLo7B7zKp6QJut7Y6OJqtOgr88sJ6WT+P+gWgC0tDXpRLYLZujie9aH2pkLDHT46Fn5R3Kk8mEgEReqqF3l+tDAZJGM2QzA0MZvnRSwjnNosQLSroy8cSzSpsNethTHJ0U+8s+wAPKNEW4TJ1JxxZaIXl8Ub+whFggk48JYarsqiUcp2QxNaVvk5kvEwtAMyV7ASXkv1I1HXBbTTiNAMNdNAi45CHjrkuHNOw= X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2510; 20:kzZgpHYpnL0tilVnDoKN/Hjd2/ricF8DJwh/qlricuA/4FHdcz8MPu4dnrF/NWy2c2FarhthpcqkFAY2HqEO/OI/kBrSCCcBVA11crhX9J6G4Le8ohaOsnP63dgOD1sho8ZA6FC0p1G43VFabbEJlxrnZ3wW07Q5aS+joeBFDhnHJXcOW7O+XJhIgF3QSLOJfN07SjOEPCFZPQwEn4uv10EiHFgYMVMVmZaJmXvw2fOaMY29lbB26y9frF6AVOphcbwXCQphl/4tL4v5YmaG1jLie+lAHza3Ds2PSa4Ar4ut1QPzftKn6H43jEE6yT8kX0MMdzRKYckCFL4JnDVNzcZGzucuLctGGvLz93gK09smpjMavW2NaB0AYVaKqANvDz50YwtFRxoOY5UBXM/9h4qx3W9ScSrNxjqHVNcO2McJsVEkmt1dNvmy8I2FIqsiPnSaS+oQ6scSK97jDSMQtWv7pQNH+livC/Wc2ADxICSFaoS9z6IPijSy0ad0Occaf0VfyIsC73E0Aczflml9VPi42Qo6vPmiK7WsKl/Ck02bASyMPDnIXGaIUh+UaXe28cIdZ1CLiUegfN6FPha40C6cEMcJc9jR+Rzme3KotY4= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(236129657087228)(247924648384137); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(2017060910033)(5005006)(3002001)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(6055026)(6041248)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN2PR05MB2510; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN2PR05MB2510; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR05MB2510; 4:wTbR0f80Qljh0Z02BGjen1BfWoBdpdHh3V/pIUlUAc?= =?us-ascii?Q?o8CWdwv8vO6GukLFxOzfU8nkzmxwCeppVxyncCyS7Vxvx4y+/jOIlaxp3s/z?= =?us-ascii?Q?vD+i8XIg001ZJvXPBqd/dIHyinQBbisXFBu0uaFeOeuftIZVKyaKMxZq4K1/?= =?us-ascii?Q?T3gahHf6VxlG4TUUFrzkheIXt7cODIiBFPnlQifh0a0lfa6IRUPs1zTtKNTY?= =?us-ascii?Q?FpUysb4kKBo89P93//RqGCRKJyBwDmsHGl8pw1TR3YLkLEorVzGkZL16Q4aq?= =?us-ascii?Q?h5uJLub2zIHr1r885suD3sFayTW526mQwwngtoh2dwj213ILAt0KJd5mbN8F?= =?us-ascii?Q?aCmbwFgKgS2aNAElJze7Cv6ww73Yy3GNdWNhNNQpDJzhymZHXUJImI/sjSem?= =?us-ascii?Q?29TiV++vZntPZBpFVh1RY6tYsfZru6ugfkgsHd++cLjDtBEYHT6C3X0O29V0?= =?us-ascii?Q?maqUcM/ycwQQKKojQRNr5rX4/yZXOODc8/ilplMLBqNNQUu0mqDRskFe9lIr?= =?us-ascii?Q?+uZhk8cNMpsX5biGsBPNhFdIICQ9N/Ftr+xSptT/hS0O4/QlybwsuSLmz6Yg?= =?us-ascii?Q?n7VAK8Rt8JsGHmVyHNx+ZiJOYAZmbb785XZMWvO8IyFs2ersnr0uLaX2EeUN?= =?us-ascii?Q?Y4nPD2JYsejTBG7aeyCg1LQlSbtNSbzuYBUR69jlgCfWCZ9OOCU3auAvt0Hn?= =?us-ascii?Q?BM6H2yfFjreGmd1C7x4BIAEVnIfVAf6+7jw3NGR/thKm9ougK9LWQSGzCXSX?= =?us-ascii?Q?EbbSrxQy1y+rWri0VT1ZyGGLKi4vcRZZcbX6H3c29TIDqwZXhxUWmEKXXB6n?= =?us-ascii?Q?JuJouTtON0flSMw+fuUKWLnnE8WBUq6XQMqUbhvD+JKqAvR3EoSQI5ahQOAY?= =?us-ascii?Q?UAMivpEKb8Bt4VBJzElLPAyUjahvJVglUMvBsHJErtfWbcp1/C43DctRV5wv?= =?us-ascii?Q?q0ktcQp4kGetRSdHZotea3PdDR4TCz7+vsf1J/JxAbm/bQDyNcwVrmWeWspa?= =?us-ascii?Q?+LP3EhILLUIHczakVb8LMlVtKzBFIWSIh36G51WibcbmUdO1orLABjgHxSN3?= =?us-ascii?Q?tP/a0VX1ShoUkkLVFGMfZO4M5qr2LhKFKm6wkh0spdD1bO8VGcUTlrEak5gk?= =?us-ascii?Q?dFBmmqCF+9315XW28vQSfTDtUI0ZDe8O7qrCxra9cTiicwedjip1C/JcYNry?= =?us-ascii?Q?uqM6pH7gGZujM0VutTYDvSbCjF7hGnXJti2yf9qPu1bhMsMo8aMyljZgMO1J?= =?us-ascii?Q?RiKeKnEQAe1vIcZu74OCEwmQe2PsgA5GlWOdKS?= X-Forefront-PRVS: 0358535363 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(39860400002)(39840400002)(39410400002)(39850400002)(39400400002)(39450400003)(5660300001)(23726003)(6916009)(230783001)(2950100002)(6666003)(6506006)(93886004)(478600001)(561944003)(6116002)(82746002)(7736002)(3846002)(305945005)(83716003)(2906002)(50466002)(189998001)(50986999)(76176999)(57306001)(8676002)(8746002)(81166006)(50226002)(33656002)(25786009)(66066001)(53416004)(47776003)(42186005)(6486002)(229853002)(86362001)(36756003)(53936002)(6246003)(38730400002)(6512007)(110136004)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR05MB2510; H:askhan-sslvpn-nc.jnpr.net; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR05MB2510; 23:XB18vQunudiXsXHwgoho6pIXtluEFQ1TuG1Ot0lNt?= =?us-ascii?Q?9eQz2qhashcO9DJEMGqOSiXIMcxBcvQJdv8cDiKgvojrrMVTZVCtWv82DY/A?= =?us-ascii?Q?oesC7hlVvBs8Bt+s5G9Fncd8hIqC3lG1fBbkxrQSYh4SEiN6N/S0Dva75AUI?= =?us-ascii?Q?dnw+bVn0n1PTiBtk9og2mSjFac1Rh3zxHVqD6WOyYPfX6AD0VurJwJyJ1tnv?= =?us-ascii?Q?GekzFCp+sfkiAzxKpATwRmrmUD7jBWHYlL1Sqooo6tEBBUlvZTewmthWCjTV?= =?us-ascii?Q?8A0fcSNFyrHZcEwIYo8jc0C/SJpHsFIE0uTWyWllV6I1Xvl+UZ/NB3aCrqvz?= =?us-ascii?Q?jpVt/A9uLNpZpAhAp61fPL8lUDQ7579EIkHHfqMh3KSPcaf1h/FmbHv4OqVl?= =?us-ascii?Q?WJCrMMADSLrVuk5QZg6O6pG5U/NhruOEmMXrJpQvgzB1Ff2Jbaarc900vwB6?= =?us-ascii?Q?yvWGXk5w2Eofal+W1EaVe0diKvz7NEAaLuvrHyXXzkLeGBxb5xVl7THV3rMs?= =?us-ascii?Q?GWRf+uMT6XtefA+inWwEG34fH7ytXe5Had77KtKKtPDDXC63wiRoy8f9s4PI?= =?us-ascii?Q?rOg21blIbiZhopW6muXf3KRaT0NssQrmmuSReVjGxjDE8Re8vXS4XiuXYdgv?= =?us-ascii?Q?ebyXaw/W3jK1wmO7XTHmo/sAAitmZR8vhd/vDQKmtSkb0UVKJ6aZ4NURliA1?= =?us-ascii?Q?yoHw01gOqvPKz1cEKY0Td7j9A8pc6EA8LWxDbozfokGmgpiF48syVdHCtPd+?= =?us-ascii?Q?i2SLJ0Ji4S8WKqv6vOnPCb//L+SxliHcXtPzvx0SM0KVvqHdmo6WhuXBaP4F?= =?us-ascii?Q?ddOiPm6nB2DbvQbLkxdsLV2ZUP0L2lTiyvitHDnVn9aNjdzeDx20fgZ1ucjv?= =?us-ascii?Q?kWjIg9cMN4e6+uEyyO0IarVOTIst2H6ur+L/ZgiX39Bd3zoKQoYkFsjdm438?= =?us-ascii?Q?0OhJUx91w5gC2oJ2XgeT5+9Hki9LBbRrCBFbBDkynwLpZKuO8Pr0ZV2yl+QA?= =?us-ascii?Q?Lr2rYkcxc+0d3Fn7lguBLHGNmZll1V46N1TDeC7Y/+UtpRyBe+49LAkXbmJT?= =?us-ascii?Q?vFTV7r5KpXGndQPS482SSEiY/V1tiVobg9DnaESxcS1IhngJinMlmKweSfRH?= =?us-ascii?Q?fXQKcl+W7gatgBE4QJjc7w4UKtHPh0r9y7M8CIiLb7CukkbW9jzuCnTj/qAF?= =?us-ascii?Q?a2gA3uvEgZGZqG8bD9r7NVFkt3+Em3dUD4F+HeFbpl0kINdbafaHgHLyA=3D?= =?us-ascii?Q?=3D?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR05MB2510; 6:j+i8uHX4EWFhhnGasuBd1h3MJ/HyoGzXkhk57tmzGd?= =?us-ascii?Q?gj5yLkwFySOpSjKhm+bHXBQa8DQQUsI9je41gVXUIljDL5J5yWagUU1hkeaM?= =?us-ascii?Q?NSGErSPf4lIFtxBMEKmz59diKXhglzjisDASIRaNunpipbtujwSuNw4Fgu7y?= =?us-ascii?Q?Y0Qxz86wYbUa9Cv9uPuzoyKyagYu72ZyK9OMYx0QaoQ5fU8Bal6SKIDMB9rE?= =?us-ascii?Q?4TsU5ltxhFR4cjsaxfY3QQQ2q9lgnq2I9n/We8r1ovSzRUcAZ2WTKH5p9zNr?= =?us-ascii?Q?Mx3eFWqT18XzDkOVpMMSMsx0J8lrVSwZw0pH9CTNd3Nr2b20JLLDRn7XBrJj?= =?us-ascii?Q?Tucu2bSq+nkcJrhPnBfsCOsAEkVCjJI3YJYPyxv1W/SvNglkCYmA/VQPOvGj?= =?us-ascii?Q?hdopP83jXHrU3PWlrv63tj/526pSHLGGofhxuYYavKkwCGn5OqRMRZKau3Tz?= =?us-ascii?Q?yEpChpK9GRIXGI8cl4LERD/pZlRj17CmRHrdrsTtLoAMLomDFArjNV2eE/eb?= =?us-ascii?Q?a5KDdhZG6mti+a3LRzlDYmTRzqwN5LD+ZAS1HlbSS0Hq4b/PAXfokVJeP6gC?= =?us-ascii?Q?mcgQQJMVtiMI5UeIH0rSv0Jr4h5BdWHLP/DjblcxAn3fzigz0fB/+yG5ozoE?= =?us-ascii?Q?3uB6PA4m7zRG+ge1pKzmIJ6Tyd+kS9HSbghaYGm7hTyKo0s4TLd0OWxBPzYW?= =?us-ascii?Q?s+9bCWU8cMuKDR/BiWYlsRIo9VhcqDQyySjQaWK1gd4XP49uFAF77L7S8Ux5?= =?us-ascii?Q?MQZ2I6Z5htGh2H0vqmMmBDTdOeBtf8rgVTJ24Dawa2Uxv3Mj53E4UgoDrQCY?= =?us-ascii?Q?48BugZuJe++g4CXCHc8tigQAm9SkJ9sUlM+Hhid0N/HExAjV1T5gAYHUHfjA?= =?us-ascii?Q?MJqczXxHuG32D4L4ALLNvRxqthDG1gKEHYKVdQYbsEqE7BGY4mrMyoHRzXMe?= =?us-ascii?Q?mVohN8XDAgUmqgdklPEOGzJgB6n9SB3c7MAURMj9PjoD6+EuApYGfxv4BUtF?= =?us-ascii?Q?wuXD37UoYfmR/CuJUMCrVE?= X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2510; 5:xEJyQkiWNBzex9Bfzx/9QM1M4CwS7kbZatDMmTPIdw+vbql3tOSrJa5JDecC7B61nuiVTgl7sEWWeCakV33wcOoHwlPqQe6hzyNUtmDsL1FtEWyHOHIpbrDSadIIVKL8eH7EYX58As7QWTNlsq2qft89Vizqe6q8k+bGf+4Z/DkkWZpU9mZGjDsJEc8sA00cUzLSg7KxhUyYsZTDRRBZpBDlnc+MceX4yJGJb5M0uquvMS+w2DFql4H06RUlkM5XdOMyBbPDhpaWfXM22Gq5e8rOcgeNDk4e9OtRrwHQHygZr9zeJj0xq+0JMv/Oq3FVCrANGjs2eNhZ7RIHPfy4Y/3MST+vbcshFnUWr1CufHNiwe74mJJZebTd/Y5fHM1/eaBjNcpso1oTjPj8LgAkVlbD6Y6r0n8LpLd+vZ5wFOTY1C3dAs4YkQnDAI5rBVau0/cNiCX4kekU6yc9WNt3SAt4OHbk0EvysWFfAF7T5MjpadMa00Ruzh/WyWugfImS; 24:4Opk9r6OkQwnGlMYtzb2ooRiYEqYY1wJjePAfIphNoaYxhCg2jEkKhZxP+OdSsHscfmAfFVejE3LOKcxHIBpBtgmsK60liX8tRzy8+9oO2E= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2510; 7:jq+UFGzu+855voaCpV8KvZQIVDseUThjPZoWqq/k7cRTwZ84TdQUSteMpRxK+r41rCDrUppTRLMUjAXaazga3JE2NX+c/rkH5WHXLsZ/jPpe9ZohIayqanHhhV94UR3KyltbHNT+ptuUlA2TA0fIl4Gyrn8AeM1lxuLQaQKME2lN+3mLaBXGFST3LRDC+LLV6plWmJOXaCyxmkbpwCpoOszOtBkRHPFnr6f3gizSaQiaFDTk/MVQlRy3wsQt+7sjB8wYSFTW+NTdd3MxidZQwrf5RcI5FSo9gHkx1rYj8hhz2d96mZhJAGraT/tb79yliASrty7ev2HZTNMiAfEOONWZdvfMMbfWBPXst+v+/ADT8HyZTaubAVGoyjio0qTH7jOA00pI30tKAK4rSL6SYRo+qXJqxNvxBORNwp1doZoRGwPcomMcPvqciGBXlz74+URduQbe4z8Lwqb55kh3l/xgGPalvgHzgfkLq++U5O/JNLl3ma1NvL7g1P03M8zScEJCYo9CC4+h1CEtHJOuMuzXDAf87M2RJ7HkPXYNcQgnz+h50BPk/Lbkrj1J55uxTOk5jM+1YW/17NPJo9Z1CsNfu+9Q36vUngT3FPkKkCFcBP76xuVwdvzemtIceK8KkmX3gmABDEfMLbRM2u7t91BkWL1iPuPPptf3Cz2mVs0/Yo0QO+W3lFhteWkGhgi/vdcEbxu30WGR9Bw17WWEogQWaSi8WTQzMIYMxPfaaj0FAoVTTywpFeHIuQ/C1bbsJ5Sq1PD+P6D7UYPwRzvq4OlvD3XGqHnjkw0/3b4CBRg= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Jul 2017 15:55:27.8205 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR05MB2510 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 15:55:31 -0000 One observation regarding the "RR won't scale if it has to do per-client = route selection" concern -- it seems to me it would be entirely feasible = for an implementation to associate some figure-of-merit with each next = hop, a function of its reported reachability by each of its indirect = peers. That figure-of-merit could be used during traditional (not = per-client) route selection. The general idea would be "if one other = client can't reach you, that's their problem, if dozens of other clients = can't reach you, maybe we should choose a different next hop if we've = got one" [*]. Think of it as making the binary resolvability condition = of RFC 4271 9.1.2.1 fuzzy. I think specifying the function would be beyond the scope of this (or = really, any) draft since it's "just policy". But it demonstrates there's = some potential benefit from the proposal without going all the way down = to per-client route selection. --John= From nobody Tue Jul 4 08:57:25 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A965E12EC30 for ; Tue, 4 Jul 2017 08:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_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=juniper.net 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 ho3OfpwziULN for ; Tue, 4 Jul 2017 08:57:21 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0111.outbound.protection.outlook.com [104.47.41.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B291313168D for ; Tue, 4 Jul 2017 08:57:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lIrDKWkSIzK4QXuuTXu90Y9h76kCoRUxzGdXWFHv4/s=; b=GGXv6Ue4mdX1BS2KRH11ZCHh2JMIwSZ10qJiJr0cVh4CT+TfEa3eAIQ5cdZmTYtLgF5xhophJ3he8eziX/OqjAAZuX2sZtmpOAOKzha1YOLns+ydo+wtdE8Hrb/oUprm/pmcz3UO54Ei3mUadpgmVf+ZuyjymPAYkWPbbVgI3ls= Authentication-Results: ntt.net; dkim=none (message not signed) header.d=none;ntt.net; dmarc=none action=none header.from=juniper.net; Received: from askhan-sslvpn-nc.jnpr.net (66.129.241.13) by CY1PR05MB2507.namprd05.prod.outlook.com (10.167.10.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.6; Tue, 4 Jul 2017 15:57:18 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: <20170704092646.yzahxshfjc5o66pg@Vurt.local> Date: Tue, 4 Jul 2017 11:57:15 -0400 Cc: idr wg Content-Transfer-Encoding: quoted-printable Message-Id: References: <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> <09BFF794-6899-4DA5-8EF5-DDF86513BFBA@pfrc.org> <20170704083853.GJ45648@Space.Net> <20170704092646.yzahxshfjc5o66pg@Vurt.local> To: Job Snijders X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: BN6PR20CA0067.namprd20.prod.outlook.com (10.171.181.157) To CY1PR05MB2507.namprd05.prod.outlook.com (10.167.10.134) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: a07acdd1-9b79-4f4c-b46d-08d4c2f559b0 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(48565401081)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY1PR05MB2507; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 3:2hZcjWMBWOyCeCE2d1TI2D2ZvICn7TRmtGnZ49T/G8gPECzofiQpx6Jk4bRmcSUDCipImP4trx1PPC+KwOb/q8qk2kAC+qAw5wK20cRnT9WLIEOKb71Dk2hUody542rrdUQSWWd5IlweR8tsQRjtGO9GPYG98Ti5tJCGYeC/xp/n2jCK01fFNdYyeVZxSWEJddVy1xWZ/lEi7WNfVLx8JB8u2MioAzFEztNYcqrtTeWUU154zgAR2extA6TQbXoOAK2nSLZH1msUjfrisNK0q5VaKgsAGX6CE4m3GF3ZgZNeRdcwKnprKidAgvziyfv+RuX4pAD5Kv9wdpfqKh422TuebHNISPaaXgLltal2KJcz/DClsA2ouepTjiC0sYpD4SKyLc01SdQpIoky07FYcHlTdOXORZ35gu3zBzJD18zw9piN5wKO8DU7ncAP9Qvl3KpVmoF4DHH2AqajWnh5augcP4+kCcUYvp9vUwK36CadvTFKKrwaOLfSNkCDEMTdmyZNbwwJzrXA3v2DXuWhgnTugGJUdAN7W3IzJe0Csa53+RjFsxzjqqQ27zKbpAmW4jIBn4YX9IHSziWycrIqL0IxiWWhSxszwaRVJwj6Ma5g+w/yHSWHPadpvIDoDnyydeADM3VTJp5JjWd4IwteuJz+IMTHlsup13H0sjnHyXdGIUPT914anWvohavMrOBnzOU2VA1zdTzYRSbfBgzA8nFPnCsgkCCTUXhtVsGI0jJAgLyoZ+xKBsxO3QaEbX0xKDoNNhCx7DGoaGLtYFabSA== X-MS-TrafficTypeDiagnostic: CY1PR05MB2507: X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 25:VYi4XoMMmn96VLWRzURTsbX0pCK+259CP7jELBOFTISArevTWPZo6JX+sOEDutT2L2+NB9S2isyunoX1yuOWhiliM/sf4eamonwhSlEJTkI7GFCU2ETrlxnsQhuAkJoCgJldneToQP2o20eorqDmxGkbfDESZtcCpS4yCmZQxZFBcf9WCGA4yImXqw+btLAEg+4aLIaw/+KFkaaxFw9W5dyHCFhxZx9ulc6KcIDH9ndYIGu1o2fLY5Fn3Sz+DIeBbByrgw1dUjQNdPRaMignotbgF3SHXMendtrnTMUAOUXicGvpl3oMkixJxAyglONFzSaKyRP66Dl/JqzDjN1SteqPTAwDfxsIcEmK0/7X7Gnz942EsMUzhysCYNOhbISDxAGkWLj8nfvHIKrt1w5J/iLaAoebyNbfcLOa1dbryfm4tNWKu2adieUJp8s0GpGfPueYsnybLBB97nEEwTsFEz6q3W+1Hz+iUjh0ZzxZmjW87XxF0LpO51DKw6ZmMb2ULuP7B2h5FEEHjPLW/B9DO7JCXmmJV7MCz4BLcKdlh2PhTY9Dnhh5TPlCqNGcmPzPP5N2PANHmj7JsyVT5Pt2wH0XWQqwIwEwjrRQtwqtMxtjxGGuElpQ8XIp6xZA0pVmArZJHP6ZUcspCWDCtanYL2gUsy58Mnd6G2/ycVP9yWrTbRPbm5ap6ZglOg+9JG4iuOhaHiO5DnGuiMzWPS5wttOpOsmNJycgMIUvTsZQvyeYTqRr5kASFCAGfq05uZSzyK4eu5idjwsEOxoItnJf05LppRoEc5QPmc2OMeF/f0+Zi4Ce9AfaMR0O+lFv0CTknRBkFoRMn/C87TACG5sGjJV537l75qKSCguXKuTi0aDv0HefxFjDaTw5MpbXdzeBjLrMFY5OFg6zhksPwOB5FzLdQKE8UosGCN4XwwSalBQ= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 31:oLxjODdFIWLOgp/m6Wo1a7kce9/IZeJdEhqqGKryUmd5NMtI3p37HbspwbqIqD41TdeRqAC2BmbSnMpZB3CGE1Q05aQ0Hg/WTqB775IoVzKoWsv7Z1KUW32q7zn4yik4LeBfXWsmpzw9v2l9KnmsNgdZvv/IttEU6BUT1TxVFKUoWZjmAJjlQnP4YfYS7v5pAk93Lc9zh9qeUkj0JvYVFATCXJVJ19U9Av+97mC0AgnAbzW9M43h3oKTn00Vqik43cYta+KOV2G/zI6rJ/qXbOdlzoKvFoOeIz6moH/W4aS/fTeqZjiN4BAW9h7XWM0tMnoQPTLcsvaYjDye9CIA2r7eoCx5Pn/ZkN7wdD59NgrH7dIOlxyopOAACoPmK5YFACbFxFWUJreEcPgK+an8ygc6q0uXqGfjVQObDXC6F89mV3VPQh16Wb6Z1GekNkhiem+eP1IBcvhyYR1zzO6Y1ouVtsnTTuFtxGkRHu68GPPOXw9ZHKkYan5PteBKS30b0C0OjCAhMnm210Pz0M+tGCNFDMXp6CgEASswSj5z3sXncOwOx/snL9PyB+DeJk785d9F19OiUiqjh3jaL9DukemH7bGVpqHCMDwsxh72trSJ55NbZDBchZWg0k5+B0ADfA6AW38PomLJ2P7mqk1Cwg8V/ffPGu9gxSVDwOl5fORRc7/uwz+2Zsf6vdZLXFNJxEO+OdYERX0XMnxKqfqVgw== X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 20:c26M/5ifLOgpxtL50cSULxgFpMJZy2oDRWs4yMCX8khypvQhBnRYiOxFRW+5D1IfNwdJtGrv0DXjfc7mreInjjunyqNuD1N8WEf+CFKMx994tbHzoOCtDbgRLITKjZ6YTxmL0azUPoMagIWuPuvLma+447O8+3aV8CQHiHGFOKwTVK8lhP5VTqOE97w1dFpZhaBHrr3W3mpT6uGEuJtsGiy2VeAnhn+pEf8HqPFLNICoRv//Vk9V50/nBB42OVOsFney8CiI7cWwftLpFNzbMp4gCbRz+e9WXz6Se4Hg8dtI0Z2ghR5FhgvxPzqWXO9gjmmXrkFDyFznNlcgoabe58Am7ScA2ead18DbAqIk6WIkpTCHOfJwYh7eJeKZliNj86aU6xCmO69zIWZV7vMDIIWyImnKx4lhd6vUjxy+HkmwKj87eXySAQGq6HiSEAarzPl2pMjlRpEFvIM8oj/vGDrkRwE6+Si1uoEOJI7RZVH2X2JQ/Yyr457yZuKeUIbihBSSdefNLODbvqh5rYomqCMY5QEkahfnwJ0OLxPryg3H0tbJDoJ1koCKnoCK6o4L7KSTGP5ctrIaOrdqcmqoaeaF9Pi6Hd3cXPGQGs0QaEM= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(236129657087228)(48057245064654)(247924648384137); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910033)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123564025)(20161123555025)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR05MB2507; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR05MB2507; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB2507; 4:qprr5L5tRegKf5qoSH0UHEuFhm+6noeU3OQovOqosl?= =?us-ascii?Q?UwdCQxYdpf7Rw5g/wE5+OJbthbi9kP8QzJTEA7STkplJyCFlYqBzPjClRDnE?= =?us-ascii?Q?eUMASA8ILLoZLnLl1u4ASLc+sLvC88lEwa0Vqn9VUKBfNScbLdC39YQxgQ+Q?= =?us-ascii?Q?mq2wrAo17J4kHvU/P/vm8+7j/BMdRocJY0zFpP0UdYHn5sFZ6bezVHe35on0?= =?us-ascii?Q?KOKofvxBiKisPwUG+58+E9Szrpb4yizEvgDlWoNc4/QNsSY1GGbl4KCpUvhG?= =?us-ascii?Q?+xOMi7wkKFcQzkzoKvNrkLcZRN8Kn7Ruiq4P60TC4tN58kc5XI0jKZ3Fop9t?= =?us-ascii?Q?o/WvxtDiCT7QT5myxpXEj/qEDRU4fw9Dak313qI3908Un24hnoc4ts6axqSJ?= =?us-ascii?Q?eA7gapPJYvEFhDI0ihRTiY7HFqmbaO5Qfb8rUFwMKtqGEqsTzQ4g4IKQVFNE?= =?us-ascii?Q?KgEuc4q9b6/n2Dwb7ep/wJF93wveoliQOC7fZnPnccaWoEB75E8QH4vi1Jpd?= =?us-ascii?Q?/FkE4wKs1Hch8dQVmUKq1HqqDascsq3IygNKoo00vyClJ+IYwF+POYnMnFFY?= =?us-ascii?Q?YfvPQMrtt+1jHVod/Xo/wKTzEjWWWrPoy0G9bNZh2d5pUclzc8hfCwHYqggq?= =?us-ascii?Q?7R7OVKnUvVj6KxksU6XHZM+clrdmmkQgikbNZyKdYJE5QEwHabvTxOWwjRxX?= =?us-ascii?Q?NjHl3/sBsxYgR04jITPy/I/Y88bhGBwvdarh1lHPoTB85QAlLjH2hjUScTxv?= =?us-ascii?Q?cyfJdWspWElI9qo8Cg5Y4QwsaBATj1pI3bsvoOmV7YE4G7DQUGq9qgJCyLWf?= =?us-ascii?Q?p7bGorq+fei9dpn4Uns77dr0YcF4MutYn7DaJNv3zZx2V3lSp84z1sXsdkF1?= =?us-ascii?Q?rXH8kxheOoKRUjKLVwmTT//MzlJGvpEO/quSaq9McN40nQ8GXmE47C3pWtm6?= =?us-ascii?Q?6soPlpVHVM3BNFKWQumhgeOZXaTjwkZghrbT133Xwlf1vSKZBC837j4tCD2j?= =?us-ascii?Q?LeWH282AKTOeodt8VpM9PYyEqsDGOITG5EmbVSORL3F6wQVc1P2sVHoChhiI?= =?us-ascii?Q?AjhCuy6CwE6jDCE59o2LOHPIzYV61SjY9Q43nEuKIjlgeE70Giksg/eis47Z?= =?us-ascii?Q?uQcBoFN97uSDvJSNqbLcm/Yx/sBFrj37pgyE0S36MO76kgms//IdCX+yJ0Iv?= =?us-ascii?Q?QMwOiMChL7zqkBxnm90OSiSH63tq7Q7VT2ngmiolVF5J6UMV113GZ7GfIt3z?= =?us-ascii?Q?NfO/xRJBVaJP32A+RhATFemwv9FcDIoFokHcrHnpkaHdTzD4i9TrfBo0rmEb?= =?us-ascii?Q?utnv8CvpTAqSlgtbT/6OA=3D?= X-Forefront-PRVS: 0358535363 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(39410400002)(39850400002)(39450400003)(39860400002)(39840400002)(39400400002)(24454002)(377454003)(2906002)(50986999)(230783001)(478600001)(8746002)(6486002)(229853002)(81166006)(966005)(6916009)(93886004)(6666003)(2950100002)(305945005)(8676002)(4326008)(76176999)(5660300001)(25786009)(7736002)(575784001)(53416004)(50466002)(42186005)(47776003)(6246003)(38730400002)(57306001)(6116002)(86362001)(53546010)(53936002)(83716003)(189998001)(6512007)(6306002)(23726003)(82746002)(33656002)(50226002)(6506006)(36756003)(110136004)(3846002)(66066001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2507; H:askhan-sslvpn-nc.jnpr.net; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB2507; 23:iSs350gCyIPkljUglU8acdYHuK+g0FoQkr/RK76Z3?= =?us-ascii?Q?bLJQ7dXMI14nPFjltOz0FFRyqQW20k+Pj86nJfT+H8jVe+Si9KfY2roy1Qz8?= =?us-ascii?Q?CAHRtR/kkvITvfGMNisSjhD/G4RXOoG9BLSdBFF1yuv9V/yQK+yu4W3QFONG?= =?us-ascii?Q?VxEi2RJBQWhDiovLWNeACXcPs1gYaDJ+76CvBh8IpoU6QWbV0t8ekPZr2l82?= =?us-ascii?Q?yiTbbq8lxfCh4V2Q33+Vs9PBpeFRpwWqyd3w7XJAUFtS38MvLl1BrIiXx5+o?= =?us-ascii?Q?mHGYkTrEoOr9Ob0v6qlZQxBomwXM+Ye69s09hYLV885bUyQ6LrffrZBHZ4X8?= =?us-ascii?Q?XydnCXXhSsozJZn59UKjseAzauY8Oep0AEY5Ss2DH+44qbX1q56hT6AZf2lI?= =?us-ascii?Q?/BwFrx2c94qv5j4HYQ7dQR3OwoSCXNJG75IKimEH9mpYNsetNxbYqlNKqN2N?= =?us-ascii?Q?AA0p7KNzoPHg1y2Ijqm3cFTWDrTNtMz4KbkYkotqb4Npcq77JADZJRNW5xV8?= =?us-ascii?Q?xvDe1XlYSmi3KBWjKvm1d/d4WR6C1/MDCHcaKSH0g7F729whUI7UZa42c+LU?= =?us-ascii?Q?Z1MV49pBZjLtRuil3aU3LFJagKucli49mY341fqn4nl1FqqCkSzH9Vnwk3FR?= =?us-ascii?Q?rFYiHHcNobIJ9IWfIwBIuYc42/G+/neJfxfegvcUmKR0Jy/tKkp6nyKgicCd?= =?us-ascii?Q?Cxavr3wIb77ylfKWi5bzWBZoJiygnrqz4g53AE8AXeSxVnY7vw2L6mU7Vr2C?= =?us-ascii?Q?vdHRZcLN9qh+pqy3HRbrHn63xMrulLwj2V0YcYhXzZA2yWnIkKCgSZTfN89t?= =?us-ascii?Q?Ct5zJDd9RayHWiWce+ziEaQkgQMnoc9HuX3y/3vdIsE408o1diKIPa3gWaOt?= =?us-ascii?Q?LY681sufa8mNzzjF17doQ1CconbKRfISTMrEd1RjgIm/PYNyuEx7w0rD/6nW?= =?us-ascii?Q?sA74Gnk+huJkkbF1rjzI8mOgbm3y0CJXqP969e+u875+8JY4xy9bqCT2LWXb?= =?us-ascii?Q?d5aydljog+TMa0dlcsgq5vGkAWzJUAOg8PquW3MzH8PtZFr1lyfffbMxDqV3?= =?us-ascii?Q?MZI09/TQ6nSZHn39NrEY5uh4+qywPGHeBczEzebPDHq9SNFVEmgjVmWLYgZw?= =?us-ascii?Q?P3CtgFMX6leUbxgvnpOoJcO5pmnMtYegJGRZOnGgBJsrPJRmlwPrnmYZHRYe?= =?us-ascii?Q?vLPMqSnfhvOi9h0MfE9OFA1CsKdgh5cleJU6/FTuindtlfQqcZsukL6stXip?= =?us-ascii?Q?S+HllwI9fqg2hVJ17y4zKIDUmhTStL4mFtxZ0LCtMgu4g3F9Oc2RF0+qqoE0?= =?us-ascii?Q?A5bMzv9iXy4JyfLrw3S9h+y9Uwiuw+2TQ7jr9BnSqvgsOOKM0538RX+hmd7z?= =?us-ascii?Q?E88Rg=3D=3D?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB2507; 6:Z4rbaQ6Dc/V9olYCE94mypFST2OJ/Jq3lhqbpPQzGX?= =?us-ascii?Q?dEXtZaeHKL6LhBl4A9aE6gbYCdYrxaZ/Px3B9cN86Vdw2dVf3NUfacMHM/XW?= =?us-ascii?Q?9WGWeL7ZETj9FiSa3joyWROsFOUJPLoCzIsoMURU5vN/zMyI2BtDrFwmXvrT?= =?us-ascii?Q?eAfKwjO8QZvbbdvmoOg7aY3rXK05ZECbw6rzxCm1mNTc1qNtKSVCRgsZTlba?= =?us-ascii?Q?AmCs9mLQdfrljZUzNjv8yWOhfM5zCbRSaN/x9vfA92Y8KCgqYRLQXqbOhaYy?= =?us-ascii?Q?xpFwnArb8r4uxvWShoeKv/RVILoyPRhzptwqEDgIfguACKCsOuQKoUGODI0o?= =?us-ascii?Q?OEr2c9CH2rN1OxJwDO7pH5M0AVotcPRZlPwLH1CP9HVFtLrm14HdluQskNhY?= =?us-ascii?Q?fbG0ube5QQbhc/R5D7DCU5XAYSgMqKH2cN5rpEa0f6ipbq4rtLe6u3p6tXT3?= =?us-ascii?Q?23r7pf9nKzKa+GXcUlxksgMI8Vz6x5l8zGkw9ZEhMYbKyb5tSwC4lH8Ppzf5?= =?us-ascii?Q?XM0yWGp/Ml8TK5tNqYPf1jcCumgzKIjlWqWEbR0mLevCLniQz/PKi762kEAx?= =?us-ascii?Q?/Z884oWbApFtWsq2ZKyQzoHQzq2GRZTYJ35bppPsrfafiuzs+U8MCOpdgQ7i?= =?us-ascii?Q?mB9A3CUEBWxBBrcbiqGBi+WausrOaKQ9Cy715vMo+YINQBlL22Yx5Q2HIOm0?= =?us-ascii?Q?2lhrqZjkonMtDWD9dOfAAS2rfigOTpERA+tn6isnlk4rSFpZpcrmps2Os02T?= =?us-ascii?Q?KL83od6Dwa5ZqcIzyNrpf+3XfT23dPH5RnK2jCCh8+6k/WN+h14F1q9rRIlw?= =?us-ascii?Q?45ibzA7xBe80jcMEHZ+8WDHaA1GlteYiIazlKlHfqzEf2SdgThVNoP4le/k6?= =?us-ascii?Q?Jtf3IszV3jEZZXytsNO/Zk1ich3ONpGIIMR0aEe01JuzuNZCztFrwrQ3hPO2?= =?us-ascii?Q?soxvm6ZeKw2Fl1suw2hCSyt5Saob+tvFfxlVWKOVlLA27cT9ZIT/ThVGFCdc?= =?us-ascii?Q?kayXWt8ci9hLyOhDsacug6?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 5:wmnc4/pgtZRyWDbA2EfQlbZZOaAIag7bbYAtUreStz1vWTC4W5vi/aCB8jvCYhSqw6EMFJbsPX2NhuxEvVHemmLOq3rt/gk20bUS8qYmU/hdeEoSOXZGWxG3iQEcnUU0Hi9GeYaS0mekCc9cQnYmmP+i3wD0vcK15LaWPvF8HjrFJDwI4QZGWaum4VLS1YrnsVL/ldG5xmAj46XcEJo9OyMq7M8BJJkJVwvkdhkorGBY/VCkmmR0BnaRli9SXk1B3jPh8iDbRtGhMAItaz7M8Yd1XUClm4bbSnsZnxmZZ2LYJzM4pfYIrgsYtALQhZRoGdaD83U0SKuvInn00PkupW0H/uU9pzMmMWc/yAaZuIGXO7EIfDwiKWlbvzIAhKeZADnZZkqRjyNNsuwsZZ4rSKcx5yTMTun0+XWbfXZV2FoaoY2i8qRi/8eSCZPpycfjmADZAQ7+W+MMIrF3JMUh3WE88mxEVWQ9Wyxaw3pZxTMgX4pcQtqnUQvFKcgiz2Rc; 24:JexQlcHmOHa0GWbkttVYDWDmWGOpNgNOf1MqTyitf46//JlafW9xjPNuWiLh3174LUwv7zEhMYtBEM8Dpzi8P0BpjqfvPD2S+w7671HFkUg= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 7:6L/xextnimQ10/KZDbWmiDvY78cX+ZFZaw4CBPaqU/o6x30omEr4Vxu2nX9l8FP+61O6HDGyFaG8egB5vMczXST9oSXnmGPACIVUK7RPF2ZALIFH33P8lMhaM1WZRA5RBV1oBJC7eo4zVNUB/P1EN7Me3hi1hFUOm5RTS1cXXwpe5ejZu0e6fDnYa9ekvWhHjwsaBrgaOkYQiGvBPgGDFcYSBGZfCfOb3gDHMmwBZsv1a9HE1Gwqys+80iDeZrPwWXPoVCQTnOQRakX69W4+M1eDxdX0Gg/EX1bYzvz6RRs3Jgg/QWUpMPUN6d33yUaEDgmqvDJmErbXFWCTjexRHAcl+wtTu3X923YxzA4GSE7FGIIfHX9qOtPkvM5WFUcQjOS90aSUXnF/Gvi2ghGmCgSEPzYhTFEc1t1INzBCf916wH4RS2jHu15Hl3vhL31HfFEHde2+zmeAqY+0bASsCFKgeqxVtzhNWUvcgLp149sCPLST2vcVP/Otr0iFyLofiKNsIUnzcsRqU55cTH+yXQa5bKcHpK1oqnaCozubVQRBUZ2plnIaGbmqDHYr9gEC/c1Xq/lZ3aairkF4Qe8e7L638cdYdMsfy++W1bXv7KyJobHMWYwTL98e7iBLS008sZGCZIygdzOxMSJIUDJEuuulpG3osn9Ct/upCxsCdFyrc3YIwHphJSWJ6VkEhTvQxnBOUim7gKhCzut0ZRKtxZNUf5tuGXdCHlxYMXQWgUXU3oE/glCzSfaXIFIYaDGEqzEzooPeYF3B2KYvT5RkfNaK8xqCz2KMyt3jAG6WVJo= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Jul 2017 15:57:18.8142 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2507 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 15:57:24 -0000 On Jul 4, 2017, at 5:26 AM, Job Snijders wrote: > We already observed that path _diversity_ isn't that great at IXPs in > the sense that often there is only a single path towards a prefix: > https://mailarchive.ietf.org/arch/msg/idr/qhgG2cCs0UuDHdPRdfDIMs7jeHs which earlier message says in part: > AMS-IX RS indicated that one out of three routes have an alternative = path > DE-CIX RS 1 out of 2 routes have an alternative path > INEX RS seemed to have virtually no alternative paths for the routes The first two seem to me like non-trivial cases of diversity, although = of course well short of full coverage. One thing not taken in by your = quick survey is whether there's any correlation between traffic and = diversity (e.g., it could be that the 1 out of 2 DE-CIX routes that have = alternative paths account for well over 50% of the traffic). I don't = necessarily advocate trying to go down the path of generating these = statistics, because the "one out of two routes would benefit" point = already seems like reasonable motivation to me. I'm merely cautioning = against reading the numbers as being more conclusive than they are. --John= From nobody Tue Jul 4 10:36:13 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9351325DE for ; Tue, 4 Jul 2017 10:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 NvdgztUJ5yCt for ; Tue, 4 Jul 2017 10:36:10 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id EBDEC1319A8 for ; Tue, 4 Jul 2017 10:36:09 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 9B8BA1E34A; Tue, 4 Jul 2017 13:45:23 -0400 (EDT) Date: Tue, 4 Jul 2017 13:45:23 -0400 From: Jeffrey Haas To: Gert Doering Cc: Robert Raszuk , idr wg Message-ID: <20170704174523.GM2289@pfrc.org> References: <149909741417.22786.4679459342587499122@ietfa.amsl.com> <20170703160800.x6wcym2ma6jceqv7@Vurt.local> <20170703163846.224w6lxvbt4txqub@Vurt.local> <20170703173810.GA45648@Space.Net> <20170703202002.GD45648@Space.Net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170703202002.GD45648@Space.Net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 17:36:11 -0000 On Mon, Jul 03, 2017 at 10:20:02PM +0200, Gert Doering wrote: > On Mon, Jul 03, 2017 at 10:16:57PM +0200, Robert Raszuk wrote: > > The intention here has nothing to do with telemetry ... > > But it *is* telemetry. "Hey, Route-Server, I can see something that > you do not see" - so the RS can do better educated guesses, and the > IXP operator can go fix the L2 issue. > > If that's not an intentional aspect, it's useful nonetheless. Such a side effect was noted in other offline discussions. But it didn't make sense to bloat the document with this information. Similarly, in the IPsec "VPN" scenario, it also permits a box to collect telemetry about the health of the tunnel mesh. -- Jeff From nobody Tue Jul 4 10:39:10 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5061325EC for ; Tue, 4 Jul 2017 10:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 RcLCi4X3RxBp for ; Tue, 4 Jul 2017 10:39:06 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id B8D061325E9 for ; Tue, 4 Jul 2017 10:39:06 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 60D9B1E34A; Tue, 4 Jul 2017 13:48:20 -0400 (EDT) Date: Tue, 4 Jul 2017 13:48:20 -0400 From: Jeffrey Haas To: Job Snijders Cc: Gert Doering , idr wg , Robert Raszuk Message-ID: <20170704174820.GN2289@pfrc.org> References: <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> <09BFF794-6899-4DA5-8EF5-DDF86513BFBA@pfrc.org> <20170704083853.GJ45648@Space.Net> <20170704092646.yzahxshfjc5o66pg@Vurt.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170704092646.yzahxshfjc5o66pg@Vurt.local> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 17:39:08 -0000 On Tue, Jul 04, 2017 at 11:26:46AM +0200, Job Snijders wrote: > I posit that it is safe to assume that other (non-RS) paths will always > exist (via transit, other peering), and as such in the trade-off between > keeping more state at the RS vs trying to keep the RS lean and mean, the > design parameters should be as following: > > - the main purpose of this draft is to ensure that each RS > participant sets up BFD sessions to the other participants of > interest, the main purpose is _not_ to ensure there are always > paths even if half the IX is on fire. The priority should be quick > fault detection, not to "make the best use of the IX under any and > all circumstances". > [intentional re-ordering of your text...] > > - The technology facilitate setting up the minimum required set of > BFD sessions, not the maximum. The draft already accomplishes these. > - we should work from the assumption that if a client supports > draft-ietf-idr-rs-bfd, it will also have support for ADD-PATH. If > we cannot assume this, I'd like to understand why. > > - explicitly consider scalability issues. The bigger internet > exchanges are struggling with their current route server load, so > if IDR adds any computational cost to their list of tasks, it'll > need to properly justify that. The draft does not require the RS to support additional path selection. It does, however, enable it if the RS is capable of such things. -- Jeff From nobody Tue Jul 4 10:44:25 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3381C132603 for ; Tue, 4 Jul 2017 10:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 idLcm9lCdn79 for ; Tue, 4 Jul 2017 10:44:21 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 88AEE129AEB for ; Tue, 4 Jul 2017 10:44:21 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 1FB831E34A; Tue, 4 Jul 2017 13:53:35 -0400 (EDT) Date: Tue, 4 Jul 2017 13:53:34 -0400 From: Jeffrey Haas To: Job Snijders Cc: idr@ietf.org Message-ID: <20170704175334.GO2289@pfrc.org> References: <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> <09BFF794-6899-4DA5-8EF5-DDF86513BFBA@pfrc.org> <20170704104840.mg5bflnmmjlv4jbi@Vurt.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170704104840.mg5bflnmmjlv4jbi@Vurt.local> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 17:44:23 -0000 On Tue, Jul 04, 2017 at 12:48:40PM +0200, Job Snijders wrote: > On Mon, Jul 03, 2017 at 06:20:28PM -0400, Jeffrey Haas wrote: > > > On Jul 3, 2017, at 5:55 PM, Job Snijders wrote: > > > > > > I'm not sure whether events will be packed together this neatly. > > > > > > Questions that remain: > > > > > > - is it absolutely necessary for the RS to be aware of the entire > > > bfd session topology state? > > > > The draft is written with the idea that some/many devices *won't* be > > aware. If the state is Unknown, things still work. > > Like with today's RS? "This draft doesn't make it worse" is hardly an > impressive statement ;-) It's BGP. You have to deal with what incremental deployment looks like. [...] > > Looked at a somewhat different way, choosing the backup paths is no > > different than add-paths or diverse paths feature choosing the next > > best path. But since the RS and the client could have already > > conveyed the possible set of nexthops for the view, there's no need > > for stepwise discovery. Perhaps this point needs to be made clearer > > in the draft. > > But any churn in the possible set of nexthops, directly results in BGP > churn, where as when the route server is not kept in the loop about who > can reach who, there will not be any churn at the route server level > when 2 RS participants cannot reach each other (temporarily). I believe you are confused about the CPU work associated with providing add-paths actually is. Add-paths implementations already run N-best calculations. They must already include the work of running policy and BGP loop checks. Adding an additional exclusion list based on nexthop viability for the view isn't significantly more work for a given round of route selection. If you'd like to argue "send them 2, and if they both don't work, let god and their backup paths sort it out", fine. You're welcome to run your RS that way - if you run a RS. What I don't understand is why you object to someone else doing something different. -- Jeff From nobody Tue Jul 4 10:49:17 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28FED1319C2 for ; Tue, 4 Jul 2017 10:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 cnhmcZzuBpYh for ; Tue, 4 Jul 2017 10:49:14 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id EB010132613 for ; Tue, 4 Jul 2017 10:49:13 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id B4BE61E34A; Tue, 4 Jul 2017 13:58:27 -0400 (EDT) Date: Tue, 4 Jul 2017 13:58:27 -0400 From: Jeffrey Haas To: Job Snijders Cc: Randy Bush , idr@ietf.org Message-ID: <20170704175827.GP2289@pfrc.org> References: <149909741417.22786.4679459342587499122@ietfa.amsl.com> <20170703160800.x6wcym2ma6jceqv7@Vurt.local> <20170703163846.224w6lxvbt4txqub@Vurt.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 17:49:16 -0000 On Mon, Jul 03, 2017 at 08:27:20PM +0000, Job Snijders wrote: > As a generalized mechanism, IXPs could snoop BFD traffic to disseminate the > current state of reachability on the fabric, such BFD snooping would work > for both RS peers as well as bilateral peers. I must admit to being boggled at expecting IXP switch fabric endpoints being expected to sniff on a chatty protocol to derive state. Why do you think this makes sense? > A question would be "why > impose additional reporting duties (load) on the RS peers when the IXP can > glean similar information through snooping"? There's also the matter that the fabric isn't necessarily aware of the semantics of a session. It would have to report up to some central box anyway. -- Jeff From nobody Tue Jul 4 11:09:12 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF521326DF for ; Tue, 4 Jul 2017 11:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 g6_n3GX-cJWc for ; Tue, 4 Jul 2017 11:09:09 -0700 (PDT) Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com [74.125.82.50]) (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 195D21326DC for ; Tue, 4 Jul 2017 11:09:08 -0700 (PDT) Received: by mail-wm0-f50.google.com with SMTP id 62so202906598wmw.1 for ; Tue, 04 Jul 2017 11:09:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=5b8altpgp9ydhY9IGcObyW7dxTR+OdAsbNxfp9nPTMg=; b=Kw07wpxickSz3T7Mr6vNoo0eRyCvDYySzoA2RKpk2G0Lx3NHw6Xb6zBBQ1gE1OQcRH JxMCEoiNinuuBaSlnBILdsh2I8DRsbxJvf5QLYEuDMH/vgsOJrI+MGX8dM/T7Q4YoV23 ar3UIiZ0HFxTYTM9GUfYPhTSzC519IkPz/p3gM/qLcGt55xUCmV9nwvp4hk5Uj2a4c/a hHMxjXCrI4klrl1OXb9ZgyKCweBXIl4UrMcGoSKRkJ0zhC5jBLsLlxOQ7KEF7GEIw4jS cyh/wG1HQx3GQttw6F4UW+NqSIrko2K5u0/Cw6S4cesArNm6fKsRrUV+nyaW+nsv1k7z cSjA== X-Gm-Message-State: AKS2vOwlB+sgSu2eWZdmhaB5M9GvAZ0vqlZ4rwDpYxCykKQbP0QzsDGD MxoJxMzCVIHfOOPF X-Received: by 10.80.152.112 with SMTP id h45mr19531723edb.51.1499191747235; Tue, 04 Jul 2017 11:09:07 -0700 (PDT) Received: from localhost ([89.200.47.198]) by smtp.gmail.com with ESMTPSA id w41sm7519530edd.43.2017.07.04.11.09.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Jul 2017 11:09:06 -0700 (PDT) Date: Tue, 4 Jul 2017 20:09:04 +0200 From: Job Snijders To: Jeffrey Haas Cc: idr@ietf.org Message-ID: <20170704180904.imv4rk7zzkckfxbo@Vurt.local> References: <149909741417.22786.4679459342587499122@ietfa.amsl.com> <20170703160800.x6wcym2ma6jceqv7@Vurt.local> <20170703163846.224w6lxvbt4txqub@Vurt.local> <20170704175827.GP2289@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170704175827.GP2289@pfrc.org> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: NeoMutt/20170609 (1.8.3) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 18:09:11 -0000 On Tue, Jul 04, 2017 at 01:58:27PM -0400, Jeffrey Haas wrote: > On Mon, Jul 03, 2017 at 08:27:20PM +0000, Job Snijders wrote: > > As a generalized mechanism, IXPs could snoop BFD traffic to > > disseminate the current state of reachability on the fabric, such > > BFD snooping would work for both RS peers as well as bilateral > > peers. > > I must admit to being boggled at expecting IXP switch fabric endpoints > being expected to sniff on a chatty protocol to derive state. Why do > you think this makes sense? Because some IXPs already use 'snooping' style methods, this is not my own idea. For instance VIX offers insight into who peers with who at https://www.vix.at/vix_peeringmatrix_detail_ipv6.html (page may take up to 60 seconds to load) based on a form of snooping, some other IXPs snoop ('intercept') ARP traffic to prevent unnecessary chatter. This isn't new. > > A question would be "why impose additional reporting duties (load) > > on the RS peers when the IXP can glean similar information through > > snooping"? > > There's also the matter that the fabric isn't necessarily aware of the > semantics of a session. It would have to report up to some central box > anyway. Yes, but that box wouldn't be the same box as the route server. Kind regards, Job From nobody Tue Jul 4 11:15:00 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3244C13272C for ; Tue, 4 Jul 2017 11:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5] 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 fwbXj3wSWvny for ; Tue, 4 Jul 2017 11:14:58 -0700 (PDT) Received: from mail-wm0-f49.google.com (mail-wm0-f49.google.com [74.125.82.49]) (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 2B01C13272B for ; Tue, 4 Jul 2017 11:14:58 -0700 (PDT) Received: by mail-wm0-f49.google.com with SMTP id 62so203005105wmw.1 for ; Tue, 04 Jul 2017 11:14:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=g/64P6OEI0RYK+fYDt+UF/VzPQhO+L6FnRKSulyG5ys=; b=pWluuAcrhj1VkK14RLbVobcJ3SaIo0gDELKDALqpCxuQJmIRSMDyY67DZisjC2GsgZ krCNKgXl4peZKn2E2YwttUTYSqjV0a6oJR3zTskgGXuGQY/tF4UW4J6j3u8hLkK/8La/ NvJICu3ATlMZjB3F9stblPiB2AojqVAKl4p1D9UzkGs3gjBZEv3mVrx1osnZXy/zaRcg I8iKGQcFQ+VuI2jPo6N+ot/rM7xdZ3WEA1wsXxSz2ayuvHd7TwWl/oke5gFCOSMR/B7k 7bawlIsCbQYATORBCbb83rC8PFbWIDYb3BiwFP1KDAsQDB2FyfkHUoRoldIGenriIJN4 TLzA== X-Gm-Message-State: AKS2vOzbh6cLcmVdU9x7glOHTxgX1YyECShESmIMz9zdCUeycF+A57sN MjDgTQZz37gn6dvuCyhZGA== X-Received: by 10.80.153.52 with SMTP id k49mr19385582edb.63.1499192096551; Tue, 04 Jul 2017 11:14:56 -0700 (PDT) Received: from localhost ([89.200.47.198]) by smtp.gmail.com with ESMTPSA id h18sm10382821eda.46.2017.07.04.11.14.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Jul 2017 11:14:55 -0700 (PDT) Date: Tue, 4 Jul 2017 20:14:54 +0200 From: Job Snijders To: Jeffrey Haas Cc: idr@ietf.org Message-ID: <20170704181454.la5hw3nyisneefff@Vurt.local> References: <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> <09BFF794-6899-4DA5-8EF5-DDF86513BFBA@pfrc.org> <20170704104840.mg5bflnmmjlv4jbi@Vurt.local> <20170704175334.GO2289@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170704175334.GO2289@pfrc.org> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: NeoMutt/20170609 (1.8.3) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 18:14:59 -0000 On Tue, Jul 04, 2017 at 01:53:34PM -0400, Jeffrey Haas wrote: > If you'd like to argue "send them 2, and if they both don't work, let > god and their backup paths sort it out", fine. You're welcome to run > your RS that way - if you run a RS. What I don't understand is why > you object to someone else doing something different. I'm not sure what to make of this paragraph? From nobody Tue Jul 4 11:21:32 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF62B12896F for ; Tue, 4 Jul 2017 11:21:30 -0700 (PDT) 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 lDk_WzoH77rj for ; Tue, 4 Jul 2017 11:21:29 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by ietfa.amsl.com (Postfix) with ESMTP id EEADA1316AC for ; Tue, 4 Jul 2017 11:21:28 -0700 (PDT) Received: by puck.nether.net (Postfix, from userid 162) id AC9FD5407BA; Tue, 4 Jul 2017 14:21:28 -0400 (EDT) Date: Tue, 4 Jul 2017 14:21:28 -0400 From: Jared Mauch To: randy@psg.com Cc: "John G. Scudder" , idr wg Message-ID: <20170704182128.GA2081@puck.nether.net> References: <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 18:21:31 -0000 On Tue, Jul 04, 2017 at 11:02:55AM +0200, Robert Raszuk wrote: > John, > > Today vast majority of OPEN policy clients share single RS view/table so > you do best path and update generation once for all of them. > > The moment you introduce per client state you are braking those apart into > individual views. > > Even those with policy today have subset of nets in their own tables not > all. So this optimization also goes away. > > So if you send clients real paths they locally can repair failures without > any additional state per client on RS. That is why I called it "a waist". I suspect you mean the homophone waste. > And this is not 100 it is 100 x number of clients say 1000 of dynamic state > which triggers 1000 best paths and update generations on propagated > failures of best path. Something I've observed in the past ~20 years is the relative compute power has gone up significantly for a BGP speaker, as many platforms may even do hardware offload of BFD, this part isn't what worries me. Tracking the N to N-1 BFD state worries me more, I've seen significant operational issues on multiple vendors with BFD. These of course are bugs and should be fixed. While I'm not a big fan of route servers personally, many people do use them in high cost areas to reduce their operational load. I'm also concerned about 3rd parties tasking me with unexpected work without constraints. Section 4 comment: Any thoughts on rate-limiting for the messages? Some IX fabrics are large and I cound envison a lot of results. I'd suggest limiting ReachAsk to once every 1,3 or possibly even 6 seconds. Was any thought given to the min/max rate of ReachAsk? (I could also see non-rs peers wanting me to send them ReachTell in the event of someone selling transit over an IX as well). Section 5 text comment: "Again, since the contents of ReachAsk are simply a set of host routes to be tested, route selection over a combined ReachAsk MAY be omitted." Suggest dropping Again. Section 6 comment: Prohibition of fe80:: next-hops may make sense here. One may not know what outbound interface is in-use. I'm always wary when I see fe80 addresses being used. - jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From nobody Tue Jul 4 11:36:14 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D441913275D for ; Tue, 4 Jul 2017 11:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 stFhM6cvkBXA for ; Tue, 4 Jul 2017 11:36:11 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 766D91319E5 for ; Tue, 4 Jul 2017 11:36:11 -0700 (PDT) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 2B6A91E333; Tue, 4 Jul 2017 14:45:25 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jeffrey Haas In-Reply-To: <20170704181454.la5hw3nyisneefff@Vurt.local> Date: Tue, 4 Jul 2017 14:36:10 -0400 Cc: idr@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <79BF9BD8-5589-48E4-A2ED-478E9BD9E989@pfrc.org> References: <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> <09BFF794-6899-4DA5-8EF5-DDF86513BFBA@pfrc.org> <20170704104840.mg5bflnmmjlv4jbi@Vurt.local> <20170704175334.GO2289@pfrc.org> <20170704181454.la5hw3nyisneefff@Vurt.local> To: Job Snijders X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 18:36:13 -0000 > On Jul 4, 2017, at 2:14 PM, Job Snijders wrote: >=20 > On Tue, Jul 04, 2017 at 01:53:34PM -0400, Jeffrey Haas wrote: >> If you'd like to argue "send them 2, and if they both don't work, let >> god and their backup paths sort it out", fine. You're welcome to run >> your RS that way - if you run a RS. What I don't understand is why >> you object to someone else doing something different. >=20 > I'm not sure what to make of this paragraph? As unicast to Job, my phrasing was inappropriate and I apologize to any = who might be offended. My point here is that at no point does this document mandate the RS = implement path selection mechanisms in response to the reported state = from the clients. However, this shouldn't preclude implementations that = desire to make use of such state. Thus, I don't understand the proscriptive desires. -- Jeff= From nobody Tue Jul 4 11:44:35 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7947B132789 for ; Tue, 4 Jul 2017 11:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Uie99hi2eY_f for ; Tue, 4 Jul 2017 11:44:31 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADC7132788 for ; Tue, 4 Jul 2017 11:44:30 -0700 (PDT) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 89F961E333; Tue, 4 Jul 2017 14:53:44 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jeffrey Haas In-Reply-To: <20170704182128.GA2081@puck.nether.net> Date: Tue, 4 Jul 2017 14:44:29 -0400 Cc: randy@psg.com, idr wg Content-Transfer-Encoding: quoted-printable Message-Id: References: <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> <20170704182128.GA2081@puck.nether.net> To: Jared Mauch X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 18:44:33 -0000 > On Jul 4, 2017, at 2:21 PM, Jared Mauch wrote: >=20 > Tracking the N to N-1 BFD state worries me more, I've seen = significant > operational issues on multiple vendors with BFD. These of course are = bugs and > should be fixed. Most of the issues I've seen here tend to be in a modest number of = categories: - Session scaling with regard to high speed timers. This proposal = suggests very sedate timers, really in the same lines as the ones of BFD = in its Down/Init state. - Session scaling for number of sessions. This might be an issue for = lower end hardware implementations with fixed session tables. For such = issues, it's reasonable for an implementation of this proposal to = provide filtering (policy) to select which sessions it desires to form = BFD adjacencies with. - Async vs. Echo mode. Not every implementation supports Echo. - Inappropriate BGP behaviors with regard to AdminDown transitions. = I'll even own to the fact we've had this class of bug in our = implementation. >=20 > While I'm not a big fan of route servers personally, many people = do use > them in high cost areas to reduce their operational load. I'm also = concerned > about 3rd parties tasking me with unexpected work without constraints. As noted above, policy/configuration to limit work is quite reasonable. = "If it hurts, don't do that." >=20 > Section 4 comment: >=20 > Any thoughts on rate-limiting for the messages? Some IX fabrics = are > large and I cound envison a lot of results. I'd suggest limiting = ReachAsk to > once every 1,3 or possibly even 6 seconds. Was any thought given to = the min/max > rate of ReachAsk? (I could also see non-rs peers wanting me to send = them ReachTell > in the event of someone selling transit over an IX as well). I had considered this a consequence of the hysteresis comment later in = the document. Perhaps this could be spelled out in further detail if = necessary. >=20 > Section 6 comment: >=20 > Prohibition of fe80:: next-hops may make sense here. One may > not know what outbound interface is in-use. I'm always wary when I = see fe80 > addresses being used. I'm supportive of this. Link scoping is tricky at the best of times. -- Jeff From nobody Tue Jul 4 11:46:39 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E48FE1327AB for ; Tue, 4 Jul 2017 11:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 UEg0fBohohP0 for ; Tue, 4 Jul 2017 11:46:36 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC931316DD for ; Tue, 4 Jul 2017 11:46:36 -0700 (PDT) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 0F5E11E333; Tue, 4 Jul 2017 14:55:50 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jeffrey Haas In-Reply-To: <20170704180904.imv4rk7zzkckfxbo@Vurt.local> Date: Tue, 4 Jul 2017 14:46:35 -0400 Cc: idr@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0138E6D2-9C5C-4C89-A2CE-C951616EE97F@pfrc.org> References: <149909741417.22786.4679459342587499122@ietfa.amsl.com> <20170703160800.x6wcym2ma6jceqv7@Vurt.local> <20170703163846.224w6lxvbt4txqub@Vurt.local> <20170704175827.GP2289@pfrc.org> <20170704180904.imv4rk7zzkckfxbo@Vurt.local> To: Job Snijders X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 18:46:38 -0000 > On Jul 4, 2017, at 2:09 PM, Job Snijders wrote: >=20 > On Tue, Jul 04, 2017 at 01:58:27PM -0400, Jeffrey Haas wrote: >>=20 >> I must admit to being boggled at expecting IXP switch fabric = endpoints >> being expected to sniff on a chatty protocol to derive state. Why do >> you think this makes sense? >=20 > Because some IXPs already use 'snooping' style methods, this is not my > own idea. For instance VIX offers insight into who peers with who at > https://www.vix.at/vix_peeringmatrix_detail_ipv6.html (page may take = up > to 60 seconds to load) based on a form of snooping, some other IXPs > snoop ('intercept') ARP traffic to prevent unnecessary chatter. This > isn't new. Traffic matrixing is pretty standard. ARP filtering with consequent static ARP is pretty common. IGMP snooping usually relies on first hop upstream device to implement = and it's a very quiet and boring protocol. BFD is chatty. I don't think it's the same problem space at all. -- Jeff= From nobody Tue Jul 4 12:13:18 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09D2712ECC6 for ; Tue, 4 Jul 2017 12:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5] 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 r9MOBGCOTbBj for ; Tue, 4 Jul 2017 12:13:15 -0700 (PDT) Received: from mail-wm0-f49.google.com (mail-wm0-f49.google.com [74.125.82.49]) (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 8B2751319F1 for ; Tue, 4 Jul 2017 12:13:15 -0700 (PDT) Received: by mail-wm0-f49.google.com with SMTP id f67so92809062wmh.1 for ; Tue, 04 Jul 2017 12:13:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=cfFszB+YC3Gf+5LTyi24aL0N7UB+MQPQqSdV6h14tz0=; b=I2Ne3ahwFASy22FVm+ZIK38BqVMHmVqhKoQjoZF4kRmWrasAJu4oROc2AKjNyYumnY 8UbMMK6sRZRL2ucFgM3uiD5nt5uSAenvZRgmmYWuWeIAS3hs5SDjQSgvjC9Sx2pxuHgz dSX09pMLKxZahJ/1dus4ldpzeiT/sFkYEOq0KNrBt4gGmJ+UMq3SY/3Qe0Dy/1QG4poS ghZLf5/7HsiJK2t5DMWdS/mMT0TQXUAD7d20szWhkbOF+rxdQ3u9VMxHGs/dyOriC94x xDYRa5TUucG23ukfFDnh209a7973h820dLISLuBgKUTdXLkYeJhilo3gioZ3jqYMcxsd TOXQ== X-Gm-Message-State: AKS2vOwhO0CTRgHuGm4Q3ebkqV3SjBrg4ykgzFnDoY+2HwI/iYC4QUp9 6kVCiV1sb1NJs19j X-Received: by 10.80.187.105 with SMTP id y96mr18933020ede.122.1499195593913; Tue, 04 Jul 2017 12:13:13 -0700 (PDT) Received: from localhost ([89.200.47.198]) by smtp.gmail.com with ESMTPSA id y53sm8332187edd.4.2017.07.04.12.13.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Jul 2017 12:13:13 -0700 (PDT) Date: Tue, 4 Jul 2017 21:13:12 +0200 From: Job Snijders To: Jeffrey Haas Cc: idr@ietf.org Message-ID: <20170704191312.nkkjeylhrpx5qcgz@Vurt.local> References: <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> <09BFF794-6899-4DA5-8EF5-DDF86513BFBA@pfrc.org> <20170704104840.mg5bflnmmjlv4jbi@Vurt.local> <20170704175334.GO2289@pfrc.org> <20170704181454.la5hw3nyisneefff@Vurt.local> <79BF9BD8-5589-48E4-A2ED-478E9BD9E989@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <79BF9BD8-5589-48E4-A2ED-478E9BD9E989@pfrc.org> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: NeoMutt/20170609 (1.8.3) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 19:13:17 -0000 On Tue, Jul 04, 2017 at 02:36:10PM -0400, Jeffrey Haas wrote: > My point here is that at no point does this document mandate the RS > implement path selection mechanisms in response to the reported state > from the clients. However, this shouldn't preclude implementations > that desire to make use of such state. > > Thus, I don't understand the proscriptive desires. Interesting, my perception of the document was different. From section 4 it is not clear to me that this behaviour is optional: "The RS uses the received ReachTell routes as input to the NHIB and hence the route selection process it performs on behalf of the client." and in section 4.4: "In computing its per-client Loc-RIB, the RS uses the content of the related per-client NHIB as input to the route resolvability condition (section 9.1.2.1 of [RFC4271]). The next hop being resolved is looked up in the NHIB and its state determined:" and specifically: "Down next hops MUST NOT be considered resolvable." Kind regards, Job From nobody Tue Jul 4 12:18:33 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721E6131702 for ; Tue, 4 Jul 2017 12:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 4l4lhIfd_kFY for ; Tue, 4 Jul 2017 12:18:31 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9621319FD for ; Tue, 4 Jul 2017 12:18:30 -0700 (PDT) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id A979B1E333; Tue, 4 Jul 2017 15:27:43 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jeffrey Haas In-Reply-To: <20170704191312.nkkjeylhrpx5qcgz@Vurt.local> Date: Tue, 4 Jul 2017 15:18:28 -0400 Cc: idr@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> <09BFF794-6899-4DA5-8EF5-DDF86513BFBA@pfrc.org> <20170704104840.mg5bflnmmjlv4jbi@Vurt.local> <20170704175334.GO2289@pfrc.org> <20170704181454.la5hw3nyisneefff@Vurt.local> <79BF9BD8-5589-48E4-A2ED-478E9BD9E989@pfrc.org> <20170704191312.nkkjeylhrpx5qcgz@Vurt.local> To: Job Snijders X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 19:18:32 -0000 > On Jul 4, 2017, at 3:13 PM, Job Snijders wrote: >=20 > On Tue, Jul 04, 2017 at 02:36:10PM -0400, Jeffrey Haas wrote: >> My point here is that at no point does this document mandate the RS >> implement path selection mechanisms in response to the reported state >> from the clients. However, this shouldn't preclude implementations >> that desire to make use of such state. >>=20 >> Thus, I don't understand the proscriptive desires. >=20 > Interesting, my perception of the document was different. =46rom = section 4 > it is not clear to me that this behaviour is optional: I see the issue now. Some of the language got simplified out of -03 = from -02. My fault as one of the contributors in not catching this in = John's rewrite. =20 In -02: 3. Advertising Client Router Connectivity to the Route Server As discussed above, a client router will advertise its Adj-NHIB-Out to the route server. The route server SHOULD update the reachability information of next hops in the client's NHIB table accordingly. Furthermore, the route server SHOULD use reachability information from the NHIB as input to its own decision process when computing the Adj-RIB-Out for this client.=20 The lack of the SHOULD appears to be the point of contention. -- Jeff= From nobody Tue Jul 4 17:19:12 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA64F12F280 for ; Tue, 4 Jul 2017 17:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 XnXWqmuGCr8O for ; Tue, 4 Jul 2017 17:19:08 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::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 36BB012F265 for ; Tue, 4 Jul 2017 17:19:08 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id r36so77834216ioi.1 for ; Tue, 04 Jul 2017 17:19:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ekXFZHbMC6iG3B2JxiJL11xkHeBpmQmlWODwfFfouWQ=; b=BMwKcujYIMSaVdKuzknk7tqrVlTED30RHbh7q1BsgotyS7dQcXtoGrfhRdzUZPI81q 46+l5o3M9zpayarOgufza0NDlnE/PXPkwfSABxNPb4geFFgVudiBvgA5AK5rIXpPtwhQ kwQB1VUsJ2iE+/fGoSn3jcjo4ftF4B9EuAqD7q0kUl9nDp8erfTrWaOq3o8yE4I1TT6e kFWYtOx+jGWsudbvXwYN6nJImYazOxkdDfgxYUEHkMdcoQnFoUMIR3HbF4QNKJiWdX+U BHBmDxiInnmRO7m/jC3M51BgcVNASJiJzaU1j/KXJR4Xga2D6XyopQZoDAtlGgOCHvam Gczw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ekXFZHbMC6iG3B2JxiJL11xkHeBpmQmlWODwfFfouWQ=; b=M30uL4MqP8/u7l0z3Zdgo1GPPFpEt1YkdsAsYU054ei3nzj14CSdxpjrIEFg7csBd4 UQUTdGHGMx7hk+kex10vGopFvhn2hnx0E7YFQP2tL3+HU/fhzRkiPSGx8EPCk9w/DThn 15oJRL3v/aGnzA2zdX3SlseSoBcGYOPCzRvPVIM84c4ovIdeOhFO5VYkTzWoqhODNfRB wz0yr1C69OQ6ia0qRQkeDDgGe0IrkIsOLg31s03JsZbY3g4MQ12V0/cntaQS8RGb1+mU OLuPaE+4So0Xib9GHslSd0rSDLehmMM1Ks3LItxe9gtbsBD5GDncxy0diJxAoz0QBdAQ wP0Q== X-Gm-Message-State: AIVw111F+CP0ISUNtHBVXqv+9hyIeyYtFLBc5C7HDz0vRHzgrOIBru3K 2gBggY7gTASe32RzmFxLVwDYlpqz1Q== X-Received: by 10.107.140.145 with SMTP id o139mr23367887iod.155.1499213947452; Tue, 04 Jul 2017 17:19:07 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.32.15 with HTTP; Tue, 4 Jul 2017 17:19:06 -0700 (PDT) Received: by 10.79.32.15 with HTTP; Tue, 4 Jul 2017 17:19:06 -0700 (PDT) In-Reply-To: References: <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> <09BFF794-6899-4DA5-8EF5-DDF86513BFBA@pfrc.org> <20170704104840.mg5bflnmmjlv4jbi@Vurt.local> <20170704175334.GO2289@pfrc.org> <20170704181454.la5hw3nyisneefff@Vurt.local> <79BF9BD8-5589-48E4-A2ED-478E9BD9E989@pfrc.org> <20170704191312.nkkjeylhrpx5qcgz@Vurt.local> From: Robert Raszuk Date: Wed, 5 Jul 2017 02:19:06 +0200 X-Google-Sender-Auth: bgbNfshhXBVPv729zL0XPXH57vY Message-ID: To: PFRC - jhaas Cc: idr wg , Job Snijders Content-Type: multipart/alternative; boundary="94eb2c05a544c7c680055386f22a" Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 00:19:10 -0000 --94eb2c05a544c7c680055386f22a Content-Type: text/plain; charset="UTF-8" Jeff, This has nothing to do with the major point of contention, but nice try ;). Bringing in some cosmetics is in no way helpfull to address fundamental flows of the proposal. But I must ask ... this appears in spite of major comments against to be a wg doc. Well so be it. But do we have multiple implementations of both RS and clients supporting this proposal ? Cheers R. On Jul 4, 2017 21:19, "Jeffrey Haas" wrote: > > > On Jul 4, 2017, at 3:13 PM, Job Snijders wrote: > > > > On Tue, Jul 04, 2017 at 02:36:10PM -0400, Jeffrey Haas wrote: > >> My point here is that at no point does this document mandate the RS > >> implement path selection mechanisms in response to the reported state > >> from the clients. However, this shouldn't preclude implementations > >> that desire to make use of such state. > >> > >> Thus, I don't understand the proscriptive desires. > > > > Interesting, my perception of the document was different. From section 4 > > it is not clear to me that this behaviour is optional: > > I see the issue now. Some of the language got simplified out of -03 from > -02. My fault as one of the contributors in not catching this in John's > rewrite. > > In -02: > > 3. Advertising Client Router Connectivity to the Route Server > > As discussed above, a client router will advertise its Adj-NHIB-Out > to the route server. The route server SHOULD update the reachability > information of next hops in the client's NHIB table accordingly. > Furthermore, the route server SHOULD use reachability information > from the NHIB as input to its own decision process when computing the > Adj-RIB-Out for this client. > > The lack of the SHOULD appears to be the point of contention. > > -- Jeff > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --94eb2c05a544c7c680055386f22a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Jeff,

= This has nothing to do with the major point of contention, but nice try ;).=

Bringing in some cosmetics is= in no way helpfull to address fundamental flows of the proposal.

But I must ask ... this appears i= n spite of major comments against to be a wg doc. Well so be it. But =C2=A0= do we have multiple implementations of both RS and clients supporting this = proposal ?=C2=A0

Cheers<= /div>
R.

On Jul 4, 2017 21:19, "Jeffrey Haas" <jhaas@pfrc.org> wrote:

> On Jul 4, 2017, at 3:13 PM, Job Snijders <job@ntt.net> wrote:
>
> On Tue, Jul 04, 2017 at 02:36:10PM -0400, Jeffrey Haas wrote:
>> My point here is that at no point does this document mandate the R= S
>> implement path selection mechanisms in response to the reported st= ate
>> from the clients.=C2=A0 However, this shouldn't preclude imple= mentations
>> that desire to make use of such state.
>>
>> Thus, I don't understand the proscriptive desires.
>
> Interesting, my perception of the document was different. From section= 4
> it is not clear to me that this behaviour is optional:

I see the issue now.=C2=A0 Some of the language got simplified out of -03 f= rom -02.=C2=A0 My fault as one of the contributors in not catching this in = John's rewrite.

In -02:

3.=C2=A0 Advertising Client Router Connectivity to the Route Server

=C2=A0 =C2=A0As discussed above, a client router will advertise its Adj-NHI= B-Out
=C2=A0 =C2=A0to the route server.=C2=A0 The route server SHOULD update the = reachability
=C2=A0 =C2=A0information of next hops in the client's NHIB table accord= ingly.
=C2=A0 =C2=A0Furthermore, the route server SHOULD use reachability informat= ion
=C2=A0 =C2=A0from the NHIB as input to its own decision process when comput= ing the
=C2=A0 =C2=A0Adj-RIB-Out for this client.

The lack of the SHOULD appears to be the point of contention.

-- Jeff
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr
--94eb2c05a544c7c680055386f22a-- From nobody Tue Jul 4 17:28:01 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFA6D12F26C for ; Tue, 4 Jul 2017 17:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 WsiSYV60kiRw for ; Tue, 4 Jul 2017 17:27:56 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 7FD1012F251 for ; Tue, 4 Jul 2017 17:27:56 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id m84so78179627ita.0 for ; Tue, 04 Jul 2017 17:27:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=1XW4LBII4KdOTmTMxDjRxQIVynn9FE75fCUmaB3NsYM=; b=ivl1k628DcUMIdJlc4+FqPpfDE+MNXUkl1zmHByYEUd1NNQ6ft634FXmbsivl1+o+5 9DsjQSR31nh1X9gAnaLmdzR9VntM6Jf5xQMUAkHmebqa1RabLzX/Rz2Yc+dn6DfsTh9z mPrUhi9P7jZuB6rp8AiF4JPICIq8xEOjK6vGagYTIDoYd/gdmwDnEgVAEGatQq35oS3t SOb582A+zomkMn9H07u7XrV3yxdtgT+WG9xcswldsPQW6wVA7mjxYu+zNvUv5AWRijvw AqV9rQSvzO1PTJK7HNrmFCIpka/Rg0mRLNBQwItOP9ikC7KrHynTYHEzzCDmYy4w9+RD Jm9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=1XW4LBII4KdOTmTMxDjRxQIVynn9FE75fCUmaB3NsYM=; b=MYtaASY3oZPgJKerRvNGUhLe24q/or1wOudPQJsNNmQyHyij+mjaJAyrziazmMLanz BkxFlRJre4BbMERj6pQ5cOXtsKWzx4O/uQckE3dyJCcKSbAmS7lHKSYWETGiWuxZuekY tnE3oebDSDcp+kBVU5oCVdOh1nj25TYK2Lk0usb7LUMUsrSpdGDDiyhan6qlJtEBdaCA spaOHlww/Y50vdTSu1sGkR7+bAzq4PoZbdRzPC6uvYqWVjlU74NY3okHU5w/EtBRTvTb fN2AI0uKzuRxSLf2laCrLJ024H6Ihgpx6qUvpj4WNG+sitEX7EbnrpzX/etcKAaJUXUc iboQ== X-Gm-Message-State: AIVw112sRzJFM7ugmh7pHpYEicALzgAb+++QB7p4eah+z6BwP4zWA5GC k1XT8wEHag9tigEnKEfQDSDsqX0nXg== X-Received: by 10.36.20.137 with SMTP id 131mr17084980itg.104.1499214475352; Tue, 04 Jul 2017 17:27:55 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.32.15 with HTTP; Tue, 4 Jul 2017 17:27:54 -0700 (PDT) Received: by 10.79.32.15 with HTTP; Tue, 4 Jul 2017 17:27:54 -0700 (PDT) In-Reply-To: <20170704175334.GO2289@pfrc.org> References: <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> <09BFF794-6899-4DA5-8EF5-DDF86513BFBA@pfrc.org> <20170704104840.mg5bflnmmjlv4jbi@Vurt.local> <20170704175334.GO2289@pfrc.org> From: Robert Raszuk Date: Wed, 5 Jul 2017 02:27:54 +0200 X-Google-Sender-Auth: _b9rT9KlLEnKlJAXfI1HNW0lqXo Message-ID: To: PFRC - jhaas Cc: idr wg , Job Snijders Content-Type: multipart/alternative; boundary="001a1143e1963ee3a605538712a4" Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 00:27:59 -0000 --001a1143e1963ee3a605538712a4 Content-Type: text/plain; charset="UTF-8" Jeff, Running add paths for common policy paths vs per client best path are orders of magnitude more work. I can not believe why you would think otherwise ... Thx RR On Jul 4, 2017 19:44, "Jeffrey Haas" wrote: > On Tue, Jul 04, 2017 at 12:48:40PM +0200, Job Snijders wrote: > > On Mon, Jul 03, 2017 at 06:20:28PM -0400, Jeffrey Haas wrote: > > > > On Jul 3, 2017, at 5:55 PM, Job Snijders wrote: > > > > > > > > I'm not sure whether events will be packed together this neatly. > > > > > > > > Questions that remain: > > > > > > > > - is it absolutely necessary for the RS to be aware of the entire > > > > bfd session topology state? > > > > > > The draft is written with the idea that some/many devices *won't* be > > > aware. If the state is Unknown, things still work. > > > > Like with today's RS? "This draft doesn't make it worse" is hardly an > > impressive statement ;-) > > It's BGP. You have to deal with what incremental deployment looks like. > > [...] > > > Looked at a somewhat different way, choosing the backup paths is no > > > different than add-paths or diverse paths feature choosing the next > > > best path. But since the RS and the client could have already > > > conveyed the possible set of nexthops for the view, there's no need > > > for stepwise discovery. Perhaps this point needs to be made clearer > > > in the draft. > > > > But any churn in the possible set of nexthops, directly results in BGP > > churn, where as when the route server is not kept in the loop about who > > can reach who, there will not be any churn at the route server level > > when 2 RS participants cannot reach each other (temporarily). > > I believe you are confused about the CPU work associated with providing > add-paths actually is. > > Add-paths implementations already run N-best calculations. They must > already include the work of running policy and BGP loop checks. Adding an > additional exclusion list based on nexthop viability for the view isn't > significantly more work for a given round of route selection. > > If you'd like to argue "send them 2, and if they both don't work, let god > and their backup paths sort it out", fine. You're welcome to run your RS > that way - if you run a RS. What I don't understand is why you object to > someone else doing something different. > > -- Jeff > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --001a1143e1963ee3a605538712a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Jeff,

Runnin= g add paths for common policy paths vs per client best path are orders of m= agnitude more work.

I ca= n not believe why you would think otherwise ...

=
Thx
RR

On Jul 4, 2017 19:44, "= ;Jeffrey Haas" <jhaas@pfrc.org> wrote:
On Tue,= Jul 04, 2017 at 12:48:40PM +0200, Job Snijders wrote:
> On Mon, Jul 03, 2017 at 06:20:28PM -0400, Jeffrey Haas wrote:
> > > On Jul 3, 2017, at 5:55 PM, Job Snijders <job@ntt.net> wrote:
> > >
> > > I'm not sure whether events will be packed together this= neatly.
> > >
> > > Questions that remain:
> > >
> > > - is it absolutely necessary for the RS to be aware of the e= ntire
> > > bfd session topology state?
> >
> > The draft is written with the idea that some/many devices *won= 9;t* be
> > aware.=C2=A0 If the state is Unknown, things still work.
>
> Like with today's RS? "This draft doesn't make it worse&q= uot; is hardly an
> impressive statement ;-)

It's BGP.=C2=A0 You have to deal with what incremental deployment looks= like.

[...]
> > Looked at a somewhat different way, choosing the backup paths is = no
> > different than add-paths or diverse paths feature choosing the ne= xt
> > best path.=C2=A0 But since the RS and the client could have alrea= dy
> > conveyed the possible set of nexthops for the view, there's n= o need
> > for stepwise discovery. Perhaps this point needs to be made clear= er
> > in the draft.
>
> But any churn in the possible set of nexthops, directly results in BGP=
> churn, where as when the route server is not kept in the loop about wh= o
> can reach who, there will not be any churn at the route server level > when 2 RS participants cannot reach each other (temporarily).

I believe you are confused about the CPU work associated with providing
add-paths actually is.

Add-paths implementations already run N-best calculations.=C2=A0 They must<= br> already include the work of running policy and BGP loop checks.=C2=A0 Addin= g an
additional exclusion list based on nexthop viability for the view isn't=
significantly more work for a given round of route selection.

If you'd like to argue "send them 2, and if they both don't wo= rk, let god
and their backup paths sort it out", fine.=C2=A0 You're welcome to= run your RS
that way - if you run a RS.=C2=A0 What I don't understand is why you ob= ject to
someone else doing something different.

-- Jeff

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr
--001a1143e1963ee3a605538712a4-- From nobody Tue Jul 4 19:47:28 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE2512EAFF for ; Tue, 4 Jul 2017 19:47:26 -0700 (PDT) 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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 Em0G-UNnUCZ8 for ; Tue, 4 Jul 2017 19:47:25 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 34DCC1243FE for ; Tue, 4 Jul 2017 19:47:25 -0700 (PDT) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 529021E333; Tue, 4 Jul 2017 22:56:39 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jeffrey Haas In-Reply-To: Date: Tue, 4 Jul 2017 22:47:23 -0400 Cc: idr wg , Job Snijders Content-Transfer-Encoding: quoted-printable Message-Id: References: <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> <09BFF794-6899-4DA5-8EF5-DDF86513BFBA@pfrc.org> <20170704104840.mg5bflnmmjlv4jbi@Vurt.local> <20170704175334.GO2289@pfrc.org> To: Robert Raszuk X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 02:47:26 -0000 > On Jul 4, 2017, at 8:27 PM, Robert Raszuk wrote: >=20 > Jeff, >=20 > Running add paths for common policy paths vs per client best path are = orders of magnitude more work. >=20 > I can not believe why you would think otherwise ... At no point did I state add-paths would be per client.= From nobody Tue Jul 4 20:58:00 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63D1312EA7C; Tue, 4 Jul 2017 20:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=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 JnqUgjIx2J7d; Tue, 4 Jul 2017 20:57:49 -0700 (PDT) Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::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 A06B71288B8; Tue, 4 Jul 2017 20:57:49 -0700 (PDT) Received: by mail-yb0-x233.google.com with SMTP id e201so68420778ybb.1; Tue, 04 Jul 2017 20:57:49 -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=2akMd/1xOCKG5mUlADgdU3l0ELLpZYLa/fhuaM9jgTM=; b=f+NLgtJv6+yb+Cu1FBjMi/AMa+Ue8DBXzeGJuogJmRPxN0u21RRoj3EJqZKbNlatFY yKb9i+VzBKz1RRGLgTyTlw+CULl2TAM/AkcPV8JfzMvrDTamKt3yF2cDW9otmHcrpCdj kM9OAEWF1aSZi2K2Xr4E4ReJXtTsz+VVOFrm0q6GOXePmlA3yOhheMdZQHOjcQ1ZVJv2 9c2iPfFgcNGuKxypVBuiNVh5HNDRZaHAdMYzVEAP8il3waDUK15+PIRMR1CIFnFLqKly RWNdEqdtqK/P8E+xwRvqv9VKbfdeVvKlqhe/silRe30qVCfKbIGzbcB40g7Mw55+3XA2 TWhQ== 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=2akMd/1xOCKG5mUlADgdU3l0ELLpZYLa/fhuaM9jgTM=; b=WKMCBR+Es5HkFSwYp+2lTXHf22N/cwDll7StaKXd+DfECcnZCQSDr+FQiId3BsvDQU JAiQNGIBUPn52oeRvCVONr+lPx8T82haa/iShkBy6z7bpf/NYzn0EOsxLlYCWDvz722X voK/UXxQv7Y/TzflqCRhyieARKXvtopr1DclNNHTFLj/BUo6D/jQQvJKHTMNsVxedkfU rZ8Huso7/fvTgZrLscsaTxkyJ073HZyQ1JUj029vKmqFfR5nrMB3yipjgvx5pvBOEnzB 1mhthRHoTy+Jnzu3ZcwwqSGAvuSYW8ct1sXAqgOAFF05v7cZlhVzEZ4ICAzEUC2xNt0s uqew== X-Gm-Message-State: AIVw112kdYxZxM246+vMvgeaNLXhoOZco1zAkgjEp5j3ELVmRLMin506 fnEsSGdsH6s9Zb3mqo20K0xCPK9JrQ== X-Received: by 10.37.173.71 with SMTP id l7mr3536266ybe.144.1499227068755; Tue, 04 Jul 2017 20:57:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.16.5 with HTTP; Tue, 4 Jul 2017 20:57:48 -0700 (PDT) In-Reply-To: References: From: Pushpasis Sarkar Date: Tue, 4 Jul 2017 20:57:48 -0700 Message-ID: To: "Les Ginsberg (ginsberg)" Cc: "idr-ads@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-idr-bgp-ls-node-admin-tag-extension.all@ietf.org" , "idr@ietf. org" Content-Type: multipart/mixed; boundary="f403045eb0d0df222d05538a0043" Archived-At: Subject: Re: [Idr] RtgDir review: draft-ietf-idr-bgp-ls-node-admin-tag-extension-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 03:57:52 -0000 --f403045eb0d0df222d05538a0043 Content-Type: multipart/alternative; boundary="f403045eb0d0df222705538a0041" --f403045eb0d0df222705538a0041 Content-Type: text/plain; charset="UTF-8" Hi Les, Thank you once more for the review comments. And sorry for the late reply. I have addressed all your comments in the attached draft. Please review the same let me know if you have any more comments. If not I will upload the draft soon. Thanks and regards, -Pushpasis On Wed, Jun 28, 2017 at 10:26 PM, Pushpasis Sarkar wrote: > Hi Les, > > Thanks a lot for the review comments. I will reply back addressing your > comments soon. > > Thanks and regards > -Pushpasis > > On Tue, Jun 27, 2017 at 11:37 PM, Les Ginsberg (ginsberg) < > ginsberg@cisco.com> wrote: > >> Hello, >> >> I have been selected as the Routing Directorate reviewer for this draft. >> The Routing Directorate seeks to review all routing or routing-related >> drafts as they pass through IETF last call and IESG review, and sometimes >> on special request. The purpose of the review is to provide assistance to >> the Routing ADs. For more information about the Routing Directorate, please >> see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir . >> >> Although these comments are primarily for the use of the Routing ADs, it >> would be helpful if you could consider them along with any other IETF >> comments that you receive, and strive to resolve them through discussion or >> by updating the draft. >> >> >> Document: draft-ietf-idr-bgp-ls-node-admin-tag-extension-01 >> Reviewer: Les Ginsberg >> Review Date: June 27, 2017 >> Intended Status: Standards >> >> Summary: The document is of modest scope - covering definition of BGP-LS >> codepoints for a relatively new IGP attribute (Node Admin Tags). >> While I found nothing which I would consider a major issue, there are a >> number >> of places where the text lacks clarity. I think addressing these areas >> would >> greatly improve the quality of the draft. >> >> >> Major Issues: None >> >> Minor Issues: >> >> Section 1 Introduction >> >> The acronym LSDB is not defined. >> >> Figure 1 >> >> I have a personal dislike for duplicating text/pictures from another >> spec when that spec could simply be referenced. There are only two >> possible outcomes: >> >> 1)The duplicated text is redundant (best case) >> 2)The text differs somewhat from the original leading to possible >> unintentional misinterpretations. >> >> Suit yourself on this comment - but I would prefer the duplication be >> omitted. >> >> Section 2 First paragraph >> >> You refer to "sub-TLV" but that reference is unclear and ambiguous. >> IS-IS uses a sub-TLV of Router Capability to advertise tags, but OSPF >> uses a TLV of Router Info LSA. >> What seems most relevant here is that you are defining a new Attribute >> TLV for Node NLRI. >> >> Section 3 Second paragraph >> >> I do not know what the paragraph is trying to say, nor do >> I know what the "TBD" in columns 4 and 5 in the following Table 1 is >> meant to reference. If you are simply trying to describe the source >> of the info advertised by the new BGP-LS Node attribute then you should >> rewrite the above paragraph and in the figure below show: >> >> IS-IS 242/21 >> OSPF RI-LSA/10 >> >> Section 3.1 >> >> A description of where in the Node NLRI the area/level information can be >> found >> (from RFC 7752) would be helpful. >> >> >> Section 3.1 Penultimate Paragraph >> >> As TAGs with "global" scope will be advertised by the IGP multiple >> times (once per area/level) I assume you are asking BGP-LS advertisements >> to reduce these multiple occurrences to a single occurrence? More >> explicit language on that point would be helpful. >> >> Section 3.1 Last paragraph >> >> I recognize this statement regarding policy being used to filter what is >> advertised is consistent with RFC 7752. But it would also be good to >> include >> a statement like: >> >> "Definition of such a policy is outside the scope of this document." >> >> Nits: Please see attached diff file with some editorial corrections. >> > > --f403045eb0d0df222705538a0041 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Les,

Thank you once more for the rev= iew comments. And sorry for the late reply. I have addressed all your comme= nts in the attached draft. Please review the same let me know if you have a= ny more comments. If not I will upload the draft soon.

=
Thanks and regards,
-Pushpasis

On Wed, Jun 28, 2017 at 10:26 PM, P= ushpasis Sarkar <pushpasis.ietf@gmail.com> wrote:
=
Hi Les,

= Thanks a lot for the review comments. I will reply back addressing your com= ments soon.

Thanks and regards
-Pushpasis
<= div class=3D"HOEnZb">

On Tue, Jun 27, 2017 at 11:37 PM, Les Ginsberg (ginsb= erg) <ginsberg@cisco.com> wrote:
Hello,

=C2=A0I have been selected as the Routing Directorate reviewer for this dra= ft. The Routing Directorate seeks to review all routing or routing-related = drafts as they pass through IETF last call and IESG review, and sometimes o= n special request. The purpose of the review is to provide assistance to th= e Routing ADs. For more information about the Routing Directorate, please s= ee=C2=A0 http://trac.tools.ietf.org/area/rt= g/trac/wiki/RtgDir .

Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF comment= s that you receive, and strive to resolve them through discussion or by upd= ating the draft.


Document: draft-ietf-idr-bgp-ls-node-admin-tag-extension-01
Reviewer: Les Ginsberg
Review Date: June 27, 2017
Intended Status: Standards

Summary:=C2=A0 The document is of modest scope - covering definition of BGP= -LS
codepoints for a relatively new IGP attribute (Node Admin Tags).
While I found nothing which I would consider a major issue, there are a num= ber
of places where the text lacks clarity. I think addressing these areas woul= d
greatly improve the quality of the draft.


Major Issues: None

Minor Issues:

Section 1 Introduction

The acronym LSDB is not defined.

Figure 1

I have a personal dislike for duplicating text/pictures from another
spec when that spec could simply be referenced. There are only two
possible outcomes:

1)The duplicated text is redundant (best case)
2)The text differs somewhat from the original leading to possible
unintentional misinterpretations.

Suit yourself on this comment - but I would prefer the duplication be omitt= ed.

Section 2 First paragraph

You refer to "sub-TLV" but that reference is unclear and ambiguou= s.
IS-IS uses a sub-TLV of Router Capability to advertise tags, but OSPF
uses a TLV of Router Info LSA.
What seems most relevant here is that you are defining a new Attribute
TLV for Node NLRI.

Section 3 Second paragraph

I do not know what the paragraph is trying to say, nor do
I know what the "TBD" in columns 4 and 5 in the following Table 1= is
meant to reference. If you are simply trying to describe the source
of the info advertised by the new BGP-LS Node attribute then you should
rewrite the above paragraph and in the figure below show:

IS-IS 242/21
OSPF RI-LSA/10

Section 3.1

A description of where in the Node NLRI the area/level information can be f= ound
(from RFC 7752) would be helpful.


Section 3.1 Penultimate Paragraph

As TAGs with "global" scope will be advertised by the IGP multipl= e
times (once per area/level) I assume you are asking BGP-LS advertisements to reduce these multiple occurrences to a single occurrence? More
explicit language on that point would be helpful.

Section 3.1 Last paragraph

I recognize this statement regarding policy being used to filter what is advertised is consistent with RFC 7752. But it would also be good to includ= e
a statement like:

"Definition of such a policy is outside the scope of this document.&qu= ot;

Nits: Please see attached diff file with some editorial corrections.


--f403045eb0d0df222705538a0041-- --f403045eb0d0df222d05538a0043 Content-Type: text/plain; charset="US-ASCII"; name="draft-ietf-idr-bgp-ls-node-admin-tag-extension-02.txt" Content-Disposition: attachment; filename="draft-ietf-idr-bgp-ls-node-admin-tag-extension-02.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_j4qh30u10 CgoKCkludGVyLURvbWFpbiBSb3V0aW5nICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBQLiBTYXJrYXIsIEVkLgpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBBcnJjdXMsIEluYy4KSW50ZW5kZWQgc3RhdHVzOiBTdGFu ZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBILiBHcmVkbGVyCkV4cGly ZXM6IEphbnVhcnkgNSwgMjAxOCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUnRC cmljaywgSW5jLgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBTLiBMaXRrb3dza2kKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgT3JhbmdlCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSnVseSAwNCwgMjAx NwoKCiAgICAgIEFkdmVydGlzaW5nIE5vZGUgQWRtaW4gVGFncyBpbiBCR1AgTGluay1TdGF0ZSBB ZHZlcnRpc2VtZW50cwogICAgICAgICAgIGRyYWZ0LWlldGYtaWRyLWJncC1scy1ub2RlLWFkbWlu LXRhZy1leHRlbnNpb24tMDIKCkFic3RyYWN0CgogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0 aGUgcHJvdG9jb2wgZXh0ZW5zaW9ucyB0byBjb2xsZWN0IG5vZGUKICAgYWRtaW5pc3RyYXRpdmUg dGFncyBhZGV2ZXJ0aXNlZCBpbiBJR1AgTGluayBTdGF0ZSBhZHZlcnRpc2VtZW50cyBhbmQKICAg ZGlzc2VtaW5hdGUgdGhlIHNhbWUgaW4gQkdQIExpbmstU3RhdGUgYWR2ZXJ0aXNlbWVudCBwcm90 b2NvbCwgdG8KICAgZmFjaWxpdGF0ZSBpbnRlci1BUyBURSBhcHBsaWNhdGlvbnMgdGhhdCBtYXkg bmVlZCB0aGUgc2FtZSBub2RlCiAgIGFkbWluaXN0cmF0aXZlIHRhZ3MgdG8gYXNzb2NpYXRlIGEg c3Vic2V0IG9mIG5ldHdvcmsgZGV2aWNlcyBzcGFubmluZwogICBhY3Jvc3MgbW9yZSB0aGFuIG9u ZSBBUyB3aXRoIGEgc3BlY2lmaWMgZnVuY3Rpb25hbGl0eS4KClJlcXVpcmVtZW50cyBMYW5ndWFn ZQoKICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFM TCIsICJTSEFMTCBOT1QiLAogICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQi LCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcwogICBkb2N1bWVudCBhcmUgdG8gYmUgaW50 ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFJGQyAyMTE5IFtSRkMyMTE5XS4KClN0YXR1cyBvZiBU aGlzIE1lbW8KCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgaXMgc3VibWl0dGVkIGluIGZ1bGwgY29u Zm9ybWFuY2Ugd2l0aCB0aGUKICAgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4KCiAg IEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVu Z2luZWVyaW5nCiAgIFRhc2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBt YXkgYWxzbyBkaXN0cmlidXRlCiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0 cy4gIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtCiAgIERyYWZ0cyBpcyBhdCBodHRwOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZHJhZnRzL2N1cnJlbnQvLgoKICAgSW50ZXJuZXQtRHJhZnRz IGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzCiAg IGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1 bWVudHMgYXQgYW55CiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5l dC1EcmFmdHMgYXMgcmVmZXJlbmNlCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0 aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiIKCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBl eHBpcmUgb24gSmFudWFyeSA1LCAyMDE4LgoKCgoKCgoKClNhcmthciwgZXQgYWwuICAgICAgICAg ICBFeHBpcmVzIEphbnVhcnkgNSwgMjAxOCAgICAgICAgICAgICAgICBbUGFnZSAxXQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgIE5vZGUgQWRtaW4gVGFncyBpbiBCR1AtTFMgICAgICAgICAgICAg IEp1bHkgMjAxNwoKCkNvcHlyaWdodCBOb3RpY2UKCiAgIENvcHlyaWdodCAoYykgMjAxNyBJRVRG IFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZQogICBkb2N1bWVudCBhdXRo b3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4KCiAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0 byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWwKICAgUHJvdmlzaW9ucyBSZWxhdGlu ZyB0byBJRVRGIERvY3VtZW50cwogICAoaHR0cDovL3RydXN0ZWUuaWV0Zi5vcmcvbGljZW5zZS1p bmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2YKICAgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1 bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzCiAgIGNhcmVmdWxseSwgYXMgdGhl eSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJpY3Rpb25zIHdpdGggcmVzcGVjdAogICB0 byB0aGlzIGRvY3VtZW50LiAgQ29kZSBDb21wb25lbnRzIGV4dHJhY3RlZCBmcm9tIHRoaXMgZG9j dW1lbnQgbXVzdAogICBpbmNsdWRlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UgdGV4dCBhcyBkZXNj cmliZWQgaW4gU2VjdGlvbiA0LmUgb2YKICAgdGhlIFRydXN0IExlZ2FsIFByb3Zpc2lvbnMgYW5k IGFyZSBwcm92aWRlZCB3aXRob3V0IHdhcnJhbnR5IGFzCiAgIGRlc2NyaWJlZCBpbiB0aGUgU2lt cGxpZmllZCBCU0QgTGljZW5zZS4KClRhYmxlIG9mIENvbnRlbnRzCgogICAxLiAgSW50cm9kdWN0 aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDIK ICAgMi4gIFBlci1Ob2RlIEFkbWluaXN0cmF0aXZlIFRhZyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gICAzCiAgIDMuICBCR1AtTFMgRXh0ZW5zaW9ucyBmb3IgUGVyLU5vZGUgQWRt aW5pc3RyYXRpdmUgVGFncyAgLiAuIC4gLiAuICAgNAogICAgIDMuMS4gIE5vZGUgQWRtaW4gVGFn IFRMViAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDUKICAgNC4gIEVs ZW1lbnRzIG9mIFByb2NlZHVyZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gICA3CiAgIDUuICBBcHBsaWNhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAgOAogICA2LiAgSUFOQSBDb25zaWRlcmF0aW9ucyAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDgKICAgNy4gIE1hbmFnZWFiaWxp dHkgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA5CiAg ICAgNy4xLiAgT3BlcmF0aW9uYWwgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAgOQogICAgICAgNy4xLjEuICBPcGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDkKICAgOC4gIFRMVi9TdWItVExWIENvZGUgUG9p bnRzIFN1bW1hcnkgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA5CiAgIDkuICBTZWN1 cml0eSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICAgOQogICAxMC4gQWNrbm93bGVkZ2VtZW50cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgIDkKICAgMTEuIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA5CiAgICAgMTEuMS4gIE5vcm1hdGl2 ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgOQogICAg IDExLjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgMTAKICAgICAxMS4zLiAgVVJJcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEwCiAgIEF1dGhvcnMnIEFkZHJlc3NlcyAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMQoKMS4gIEludHJvZHVj dGlvbgoKICAgQWR2ZXJ0aXNpbmcgTm9kZSBBZG1pbmlzdHJhdGl2ZSBUYWdzIGluIExpbmsgU3Rh dGUgcHJvdG9jb2xzIGxpa2UgSVMtCiAgIElTIFtSRkM3OTE3XSBhbmQgT1NQRiBbUkZDNzc3N10g ZGVmaW5lcyBhbiBvcHRpb25hbCBvcGVyYXRpb25hbAogICBjYXBhYmlsaXR5LCB0aGF0IGFsbG93 cyB0YWdnaW5nIGFuZCBncm91cGluZyBvZiB0aGUgbm9kZXMgaW4gYSBJR1AKICAgZG9tYWluLiAg VGhpcywgYW1vbmcgb3RoZXIgYXBwbGljYXRpb25zLCBhbGxvd3Mgc2ltcGxlIG1hbmFnZW1lbnQg YW5kCiAgIGVhc3kgY29udHJvbCBvdmVyIHJvdXRlIGFuZCBwYXRoIHNlbGVjdGlvbiwgYmFzZWQg b24gbG9jYWwgY29uZmlndXJlZAogICBwb2xpY2llcy4gIEhvd2V2ZXIgbm9kZSBhZG1pbmlzdHJh dGl2ZSB0YWdzIGFkdmVydGlzZWQgaW4gSUdQCiAgIGFkdmVydGlzZW1lbnRzIGxldCBuZXR3b3Jr IG9wZXJhdG9ycyBhc3NvY2lhdGUgbm9kZXMgd2l0aGluIGEgc2luZ2xlCiAgIEFTIChpZiBub3Qg YSBzaW5nbGUgYXJlYSkuICBUaGlzIGxpbWl0cyB0aGUgdXNlIG9mIHN1Y2ggbm9kZQogICBhZG1p bmlzdHJhdGl2ZSB0YWdzIGFuZCBhcHBsaWNhdGlvbnMgdGhhdCBuZWVkIHRvIGFzc29jaWF0ZSBh IHN1YnNldAoKCgoKU2Fya2FyLCBldCBhbC4gICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSA1LCAy MDE4ICAgICAgICAgICAgICAgIFtQYWdlIDJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgTm9k ZSBBZG1pbiBUYWdzIGluIEJHUC1MUyAgICAgICAgICAgICAgSnVseSAyMDE3CgoKICAgb2YgbmV0 d29yayBkZXZpY2VzIHNwYW5uaW5nIGFjcm9zcyBtdWx0aXBsZSBBUyB3aXRoIGEgc3BlY2lmaWMK ICAgZnVuY3Rpb25hbGl0eSBjYW5ub3QgdXNlIHRoZW0uCgogICBUbyBhZGRyZXNzIHRoZSBuZWVk IGZvciBhcHBsaWNhdGlvbnMgdGhhdCByZXF1aXJlIHZpc2liaWxpdHkgaW50bwogICBMaW5rIFN0 YXRlIERhdGFiYXNlcyAoTFNEQnMpIGFjcm9zcyBJR1AgYXJlYXMsIG9yIGV2ZW4gYWNyb3NzIEFT ZXMsCiAgIHRoZSBCR1AtTFMgYWRkcmVzcy1mYW1pbHkvc3ViLWFkZHJlc3MtZmFtaWx5IGhhdmUg YmVlbiBkZWZpbmVkIHRoYXQKICAgYWxsb3dzIEJHUCB0byBjYXJyeSBMU0RCIGluZm9ybWF0aW9u LiAgVGhlIEJHUCBOZXR3b3JrIExheWVyCiAgIFJlYWNoYWJpbGl0eSBJbmZvcm1hdGlvbiAoTkxS SSkgZW5jb2RpbmcgZm9ybWF0IGZvciBCR1AtTFMgYW5kIGEgbmV3CiAgIEJHUCBQYXRoIEF0dHJp YnV0ZSBjYWxsZWQgQkdQLUxTIGF0dHJpYnV0ZSBhcmUgZGVmaW5lZCBpbiBbUkZDNzc1Ml0uCiAg IFBsZWFzZSByZWZlciB0byBbUkZDNzc1Ml0gZm9yIG1vcmUgZGV0YWlscy4KCiAgIEZvciB0aGUg cHVycG9zZSBvZiBhZHZlcnRpc2luZyBub2RlIGFkbWluaXN0cmF0aXZlIHRhZ3Mgd2l0aGluIEJH UAogICBMaW5rLVN0YXRlIGFkdmVydGlzZW1lbnRzLCBhIG5ldyBOb2RlIEF0dHJpYnV0ZSBUTFYg dG8gYmUgY2FycmllZCBpbgogICB0aGUgY29ycmVzcG9uZGluZyBCR1AtTFMgTm9kZSBOTFJJIGlz IHByb3Bvc2VkLiAgRm9yIG1vcmUgZGV0YWlscyBvbgogICB0aGUgTm9kZSBBdHRyaWJ1dGUgVExW cyBwbGVhc2UgcmVmZXIgdG8gc2VjdGlvbiAzLjMuMSBpbiBbUkZDNzc1Ml0KCjIuICBQZXItTm9k ZSBBZG1pbmlzdHJhdGl2ZSBUYWcKCiAgIEFuIGFkbWluaXN0cmF0aXZlIFRhZyBpcyBhIDMyLWJp dCBpbnRlZ2VyIHZhbHVlIHRoYXQgY2FuIGJlIHVzZWQgdG8KICAgaWRlbnRpZnkgYSBncm91cCBv ZiBub2RlcyBpbiB0aGUgZW50aXJlIHJvdXRpbmcgZG9tYWluLiAgVGhlIG5ldyBUTFYKICAgYW5k IHN1Yi1UTFYgcHJvcG9zZWQgaW4gSVMtSVMgW1JGQzc5MTddIGFuZCBPU1BGIFtSRkM3Nzc3XQog ICByZXNwZWN0aXZlbHksIHNwZWNpZmllcyBvbmUgb3IgbW9yZSBhZG1pbmlzdHJhdGl2ZSB0YWcg dmFsdWVzLiAgQSBCR1AKICAgTGluay1TdGF0ZSBzcGVha2VyIHRoYXQgYWxzbyBwYXJ0aWNpcGF0 ZXMgaW4gdGhlIElHUCBsaW5rIHN0YXRlCiAgIGFkdmVydGlzZW1lbnRzIGV4Y2hhbmdlIG1heSBs ZWFybiBvbmUgb3IgbW9yZSBub2RlIGFkbWluaXN0cmF0aXZlCiAgIHRhZ3MgYWR2ZXJ0aXNlZCBi eSBhbm90aGVyIHJvdXRlciBpbiB0aGUgc2FtZSBJR1AgZG9tYWluLiAgU3VjaCBCR1AtCiAgIExT IHNwZWFrZXIgc2hhbGwgZW5jb2RlIHRoZSBzYW1lIHNldCBvZiBub2RlIGFkbWluaXN0cmF0aXZl IHRhZ3MgaW4KICAgdGhlIGNvcnJlc3BvbmRpbmcgTm9kZSBBdHRyaWJ1dGUgVExWIHJlcHJlc2Vu dGluZyB0aGUgbmV0d29yayBkZXZpY2UKICAgdGhhdCBvcmlnaW5hdGVkIHRoZSBub2RlIGFkbWlu aXN0cmF0aXZlIHRhZ3MuCgogICBUaGUgbm9kZSBhZG1pbmlzdHJhdGl2ZSB0YWdzIGFkdmVydGlz ZWQgaW4gSUdQIGxpbmsgc3RhdGUKICAgYWR2ZXJ0aXNlbWVudHMgd2lsbCBoYXZlIGVpdGhlciBw ZXItYXJlYShvciBwZXItbGV2ZWwgaW4gSVMtSVMpc2NvcGUKICAgb3IgJ2dsb2JhbCcgc2NvcGUu ICBPcGVyYXRvciBtYXkgY2hvb3NlIHRvIGEgc2V0IG9mIG5vZGUKICAgYWRtaW5pc3RyYXRpdmUg dGFncyBhY3Jvc3MgYXJlYXMgKG9yIGxldmVscyBpbiBJUy1JUykgYW5kIGFub3RoZXIKICAgYWR2 ZXJ0aXNlIHNldCBvZiBub2RlIGFkbWluaXN0cmF0aXZlIHRhZ3Mgd2l0aGluIGEgc3BlY2lmaWMg YXJlYSAob3IKICAgbGV2ZWwpLiAgQnV0IGV2aWRlbnRseSB0d28gYXJlYXMgd2l0aGluIHRoZSBz YW1lIEFTIG9yIHR3byBkaWZmZXJlbnQKICAgQVNlcyBtYXkgdXNlIHRoZSBzYW1lIG5vZGUgYWRt aW5pc3RyYXRpdmUgdGFnIGZvciBkaWZmZXJlbnQgcHVycG9zZXMuCiAgIEluIHN1Y2ggY2FzZSBh cHBsaWNhdGlvbnMgd2lsbCBuZWVkIHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4gdGhlIHBlci0KICAg YXJlYShvciBwZXItbGV2ZWwpIHNjb3BlZCBhZG1pbmlzdHJhdGl2ZSB0YWdzIG9yaWdpbmF0ZWQg ZnJvbSBhCiAgIHNwZWNpZmljIG5vZGUgYWdhaW5zdCB0aG9zZSBvcmlnaW5hdGVkIGZyb20gdGhl IHNhbWUgbm9kZSB3aXRoCiAgICdnbG9iYWwnIHNjb3BlLgoKICAgQSBCR1AtTFMgcm91dGVyIGlu IGEgZ2l2ZW4gQVMgd2hpbGUgY29weWluZyB0aGUgbm9kZSBhZG1pbmlzdHJhdGl2ZQogICB0YWdz IGxlYXJudCBmcm9tIElHUCBsaW5rLXN0YXRlIGFkdmVydGlzZW1lbnRzLCBNVVNUIGFsc28gY29w eSB0aGUKICAgc2NvcGUgYXNzb2NpYXRlZCB3aXRoIHRoZSBub2RlIGFkbWluaXN0cmF0aXZlIHRh Z3MuICBSZWZlciB0bwogICBTZWN0aW9uIDMuMSBmb3IgaG93IHRvIGVuY29kZSB0aGUgYXNzb2Np YXRlZCBzY29wZSBvZiBhIG5vZGUKICAgYWRtaW5pc3RyYXRpdmUgdGFncyBhcyB3ZWxsLgoKCgoK ClNhcmthciwgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgNSwgMjAxOCAgICAgICAg ICAgICAgICBbUGFnZSAzXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgIE5vZGUgQWRtaW4gVGFn cyBpbiBCR1AtTFMgICAgICAgICAgICAgIEp1bHkgMjAxNwoKCiAgIFRvIGJlIGFibGUgdG8gZGlz dGluZ3Vpc2ggYmV0d2VlbiB0aGUgc2lnbmlmaWNhbmNlIG9mIGEgcGVyLWFyZWEob3IKICAgcGVy LWxldmVsKSBhZG1pbmlzdHJhdGl2ZSB0YWcgbGVhcm50IGluIG9uZSBhcmVhLCBmcm9tIHRoYXQK ICAgYWR2ZXJ0aXNlZCBpbiBhbm90aGVyIGFyZWEsIG9yIGFub3RoZXIgQVMsIGFueSBhcHBsaWNh dGlvbnMgcmVjZWl2aW5nCiAgIHN1Y2ggYSBCR1AtTFMgYWR2ZXJ0aXNlbWVudHMgTVVTVCBjb25z aWRlciB0aGUgc2NvcGUgYXNzb2NpYXRlZCB3aXRoCiAgIGVhY2ggbm9kZSBhZG1pbmlzdHJhdGl2 ZSB0YWcgYWxvbmcgd2l0aCB0aGUgYXJlYShvciBsZXZlbCBpbiBJUy1JUykKICAgYXNzb2NpYXRl ZCB3aXRoIGNvcnJlc3BvbmRpbmcgSUdQIGxpbmsgc3RhdGUgYWR2ZXJ0aXNlbWVudCBhbmQgdGhl IEFTCiAgIG51bWJlciBhc3NvY2lhdGVkIHdpdGggdGhlIG9yaWdpbmF0aW5nIG5vZGUuICBUaGUg YXJlYShvciBsZXZlbCkKICAgYXNzb2NpYXRlZCB3aXRoIGNvcnJlc3BvbmRpbmcgSUdQIGxpbmsg c3RhdGUgYWR2ZXJ0aXNlbWVudCBhbmQgdGhlIEFTCiAgIG51bWJlciBhc3NvY2lhdGVkIHdpdGgg dGhlIG9yaWdpbmF0aW5nIG5vZGUgY2FuIGJlIGRlcml2ZWQgZnJvbQogICBhcHByb3ByaWF0ZSBu b2RlIGF0dHJpYnV0ZXMgKGFscmVhZHkgZGVmaW5lZCBpbiBCR1AtTFMgW1JGQzc3NTJdKQogICBh dHRhY2hlZCB3aXRoIHRoZSBjb3JyZXNwb25kaW5nIE5vZGUgTkxSSS4gIFtSRkM3NzUyXSBzcGVj aWZpZXMgdGhhdAogICBJU0lTIGxldmVsIGluZm9ybWF0aW9uIGJlIGVuY29kZWQgaW4gTm9kZSBO TFJJIFsxXSBhbmQgT1NQRiBBcmVhCiAgIElkZW50aWZpZXJzIGJlIGVuY29kZWQgaW4gTm9kZSBE ZXNjcmlwdG9yIFN1Yi1UTFZzIFsyXS4KCjMuICBCR1AtTFMgRXh0ZW5zaW9ucyBmb3IgUGVyLU5v ZGUgQWRtaW5pc3RyYXRpdmUgVGFncwoKICAgVGhlIEJHUC1MUyBOTFJJIGNhbiBiZSBhIG5vZGUg TkxSSSwgYSBsaW5rIE5MUkkgb3IgYSBwcmVmaXggTkxSSS4KICAgVGhlIGNvcnJlc3BvbmRpbmcg QkdQLUxTIGF0dHJpYnV0ZSBpcyBhIG5vZGUgYXR0cmlidXRlLCBhIGxpbmsKICAgYXR0cmlidXRl IG9yIGEgcHJlZml4IGF0dHJpYnV0ZS4gIEJHUC1MUyBbUkZDNzc1Ml0gZGVmaW5lcyB0aGUgVExW cwogICB0aGF0IG1hcCBsaW5rLXN0YXRlIGluZm9ybWF0aW9uIHRvIEJHUC1MUyBOTFJJIGFuZCBC R1AtTFMgYXR0cmlidXRlLgogICBUaGlzIGRvY3VtZW50IGFkZHMgYW4gbmV3IE5vZGUgQXR0cmli dXRlIFRMViBjYWxsZWQgJ05vZGUgQWRtaW4gVGFnCiAgIFRMVicgdG8gZW5jb2RlIG5vZGUgYWRt aW5pc3RyYXRpdmUgdGFncyBpbmZvcm1hdGlvbi4KCiAgIFtSRkM3OTE3XSBkZWZpbmVzIHRoZSAn Tm9kZSBBZG1pbiBUYWcnIHN1Yi1UTFYgaW4gdGhlIFJvdXRlcgogICBDYXBhYmlsaXR5IFRMViAo dHlwZSAyNDIpIGluIElTLUlTIExpbmsgU3RhdGUgUERVcyB0byBlbmNvZGUgbm9kZQogICBhZG1p bmlzdHJhdGl2ZSB0YWdzLiAgU2ltaWxhcmx5IFtSRkM3OTE3XSBkZWZpbmVzIHRoZSAnTm9kZQog ICBBZG1pbmlzdHJhdGl2ZSBUYWcnIFRMViBpbiBPU1BGIFJvdXRlciBJbmZvcm1hdGlvbiBMU0Fz IHRvIGVuY29kZQogICBub2RlIGFkbWluaXN0cmF0aXZlIHRhZ3MgaW4gT1NQRiBMaW5rIFN0YXRl IHVwZGF0ZSBwYWNrZXRzLiAgVGhlIG5vZGUKICAgYWRtaW5pc3RyYXRpdmUgdGFncyBUTFZzIGxl YXJudCBmcm9tIHRoZSBJR1AgbGluayBzdGF0ZQogICBhZHZlcnRpc2VtZW50cyBvZiBhIHNwZWNp ZmljIG5vZGUgd2lsbCBhbGwgYmUgaW5zZXJ0ZWQgaW4gYSBuZXcgTm9kZQogICBBZG1pbiBUYWcg VExWIGFuZCBhZGRlZCB0byB0aGUgY29ycmVzcG9uZGluZyBOb2RlIGFyZSBtYXBwZWQgdG8gdGhl CiAgIGNvcnJlc3BvbmRpbmcgQkdQLUxTIE5vZGUgTkxSSS4gIE5vZGUgYWRtaW5pc3RyYXRpdmUg dGFncyBmcm9tIElHUAogICBhZHZlcnRpc2VtZW50cyBhcmUgbWFwcGVkIHRvIHRoZSBjb3JyZXNw b25kaW5nIE5vZGUgQWRtaW4gVGFnIFRMViBpbgogICB0aGUgZm9sbG93aW5nIHdheS4KCiAgICst LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tKwogICB8IFRMViBDb2RlIHwgRGVzY3JpcHRpb24gICAgfCBMZW5ndGggICB8ICAg ICBJUy1JUyBUTFYgfCAgICAgICBPU1BGIHwKICAgfCAgUG9pbnQgICB8ICAgICAgICAgICAgICAg IHwgICAgICAgICAgfCAgICAgIC9zdWItVExWIHwgICAgTFNBL1RMViB8CiAgICstLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t KwogICB8ICAgVEJEICAgIHwgTm9kZSBBZG1pbiBUYWcgfCBWYXJpYWJsZSB8ICAgIDI0Mi8yMSBb M10gfCAgUkktTFNBLzEwIHwKICAgfCAgICAgICAgICB8IFRMViAgICAgICAgICAgIHwgICAgICAg ICAgfCAgICAgICAgICAgICAgIHwgICAgICAgIFs0XSB8CiAgICstLS0tLS0tLS0tKy0tLS0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKwoKICAgICAg ICAgICAgICAgVGFibGUgMTogTm9kZSBBZG1pbiBUYWcgVExWIE1hcHBpbmcgZnJvbSBJR1AKCgoK CgoKClNhcmthciwgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgNSwgMjAxOCAgICAg ICAgICAgICAgICBbUGFnZSA0XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgIE5vZGUgQWRtaW4g VGFncyBpbiBCR1AtTFMgICAgICAgICAgICAgIEp1bHkgMjAxNwoKCjMuMS4gIE5vZGUgQWRtaW4g VGFnIFRMVgoKICAgVGhlIG5ldyBOb2RlIEFkbWluaXN0cmF0aXZlIFRhZyBUTFYsIGxpa2Ugb3Ro ZXIgQkdQLUxTIE5vZGUgQXR0cmlidXRlCiAgIFRMVnMsIGlzIGZvcm1hdHRlZCBhcyBUeXBlL0xl bmd0aC9WYWx1ZSAoVExWKXRyaXBsZXRzLiAgRmlndXJlIDEKICAgYmVsb3cgc2hvd3MgdGhlIGZv cm1hdCBvZiB0aGUgbmV3IFRMVi4KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKClNhcmthciwgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgNSwgMjAx OCAgICAgICAgICAgICAgICBbUGFnZSA1XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgIE5vZGUg QWRtaW4gVGFncyBpbiBCR1AtTFMgICAgICAgICAgICAgIEp1bHkgMjAxNwoKCiAgICAwICAgICAg ICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzCiAg ICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3 IDggOSAwIDEKICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rCiAgICB8ICAgICAgICAgICAgICBUeXBlICAgICAgICAgICAg IHwgICAgICAgICAgICAgTGVuZ3RoICAgICAgICAgICAgfAogICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgIHwgICAg ICAgICAgICBGbGFncyAgICAgICAgICAgICAgfAogICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgIHwgICAgICAgICAg ICAgICAgICAgQWRtaW5pc3RyYXRpdmUgVGFnICMxICAgICAgICAgICAgICAgICAgICAgICB8CiAg ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKwogICAgfCAgICAgICAgICAgICAgICAgICBBZG1pbmlzdHJhdGl2ZSBUYWcgIzIg ICAgICAgICAgICAgICAgICAgICAgIHwKICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICAvLyAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAvLwogICAgKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSsKICAgIHwgICAgICAgICAgICAgICAgICAgQWRtaW5pc3RyYXRpdmUgVGFnICNOICAgICAg ICAgICAgICAgICAgICAgICB8CiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwoKICAgICBUeXBlIDogIEEgMi1vY3RldCBm aWVsZCBzcGVjaWZpeWluZyBjb2RlLXBvaW50IG9mIHRoZSBuZXcKICAgICAgICAgICAgIFRMViB0 eXBlLiBDb2RlLXBvaW50OiBUQkEgKHN1Z2dlc3RlZCAxMDQwKQoKICAgICBMZW5ndGg6IEEgMi1v Y3RldCBmaWVsZCB0aGF0IGluZGljYXRlcyB0aGUgbGVuZ3RoIG9mIHRoZSB2YWx1ZQogICAgICAg ICAgICAgcG9ydGlvbiBpbiBvY3RldHMgYW5kIHdpbGwgYmUgYSBtdWx0aXBsZSBvZiA0IG9jdGV0 cwogICAgICAgICAgICAgZGVwZW5kZW50IG9uIHRoZSBudW1iZXIgb2YgdGFncyBhZHZlcnRpc2Vk LgoKICAgICBWYWx1ZTogIEEgMi1vY3RldCAnRmxhZ3MnIGZpZWxkLCBmb2xsb3dlZCBieSBhIHNl cXVlbmNlIG9mIG11bHRpcGxlCiAgICAgICAgICAgICA0IG9jdGV0cyBkZWZpbmluZyB0aGUgYWRt aW5pc3RyYXRpdmUgdGFncy4KCiAgICAgICBGbGFnczogQSAyLW9jdGV0IGZpZWxkIHRoYXQgY2Fy cmllcyBmbGFncyBhc3NvY2lhdGVkIHdpdGgKICAgICAgICAgICAgICBhbGwgdGhlIGFkbWluaXN0 cmF0aXZlIGZsYWdzIGVuY29kZWQgaW4gdGhpcyBUTFYuCiAgICAgICAgICAgICAgRm9sbG93aW5n IGlzIHRoZSBmb3JtYXQgb2YgdGhpcyBmaWVsZC4KCiAgICAgICAgICAgICAgIDAgMSAyIDMgNCA1 IDYgNyA4IDkgMCAxIDIgMyA0IDUKICAgICAgICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSsKICAgICAgICAgICAgICB8THwgICAgICAgICAgICBSZXNlcnZlZCAgICAgICAg IHwKICAgICAgICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKCiAgICAg ICAgICAgICAgVGhlIGZvbGxvd2luZyBiaXQgZmxhZ3MgYXJlIGRlZmluZWQ6CgogICAgICAgICAg ICAgIEwgYml0IDogSWYgdGhlIEwgYml0IGlzIHNldCAoMSksIGl0IHNpZ25pZmllcyB0aGF0CiAg ICAgICAgICAgICAgICAgICAgICBhbGwgYWRtaW5pc3RyYXRpdmUgZmxhZ3MgZW5jb2RlZCBpbiB0 aGlzCiAgICAgICAgICAgICAgICAgICAgICBUTFYgaGFzIHBlci1hcmVhKG9yIGxldmVsIGluIElT LUlTKSBzY29wZSwKICAgICAgICAgICAgICAgICAgICAgIGFuZCBzaG91bGQgbm90IGJlIG1peGVk IHdpdGggb25lcyB3aXRoIHNhbWUKICAgICAgICAgICAgICAgICAgICAgIHZhbHVlIGJ1dCB3aXRo ICdnbG9iYWwnIHNjb3BlIChMIGJpdCByZXNldAogICAgICAgICAgICAgICAgICAgICAgdG8gMCku CgoKICAgICAgICAgICBGaWd1cmUgMTogQkdQIExpbmstU3RhdGUgTm9kZSBBZG1pbmlzdHJhdGl2 ZSBUYWcgVExWCgoKCgoKU2Fya2FyLCBldCBhbC4gICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSA1 LCAyMDE4ICAgICAgICAgICAgICAgIFtQYWdlIDZdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAg Tm9kZSBBZG1pbiBUYWdzIGluIEJHUC1MUyAgICAgICAgICAgICAgSnVseSAyMDE3CgoKICAgVGhp cyBuZXcgdHlwZSBvZiAnTm9kZSBBZG1pbiBUYWcnIFRMVnMgY2FuIE9OTFkgYmUgYWRkZWQgdG8g dGhlIE5vZGUKICAgQXR0cmlidXRlIGFzc29jaWF0ZWQgd2l0aCB0aGUgTm9kZSBOTFJJIHRoYXQg b3JpZ2luYXRlcyB0aGUKICAgY29ycmVzcG9uZGluZyBub2RlIGFkbWluaXN0cmF0aXZlIHRhZ3Mg aW4gSUdQIGRvbWFpbi4KCiAgIEFsbCB0aGUgbm9kZSBhZG1pbmlzdHJhdGl2ZSB0YWdzIHdpdGgg J3Blci1hcmVhJyAob3IgcGVyLWxldmVsKQogICBzY29wZSwgb3JpZ2luYXRlZCBieSBhIHNpbmds ZSBub2RlIGluIGFuIElHUCBkb21haW4gU0hBTEwgYmUgcmUtCiAgIG9yaWdpbmF0ZWQgaW4gYSBz aW5nbGUgJ05vZGUgQWRtaW4gVGFnJyBUTFYgYW5kIGluc2VydGVkIGluIHRoZSBOb2RlCiAgIE5M UkkgZ2VuZXJhdGVkIGZvciB0aGUgc2FtZSBub2RlLiAgU2ltaWxhcmx5LCBhbGwgdGhlIG5vZGUK ICAgYWRtaW5pc3RyYXRpdmUgdGFncyB3aXRoICdnbG9iYWwnIHNjb3BlIG9yaWdpbmF0ZWQgYnkg dGhlIHNhbWUgbm9kZQogICBpbiBJR1AgZG9tYWluIFNIQUxMIGJlIHJlLW9yaWdpbmF0ZWQgaW4g YW5vdGhlciAnTm9kZSBBZG1pbiBUYWcnIFRMVgogICBhbmQgaW5zZXJ0ZWQgaW4gdGhlIHNhbWUg Tm9kZSBOTFJJIGdlbmVyYXRlZCBmb3IgdGhlIG9yaWdpbmF0aW5nCiAgIG5vZGUuICBNdWx0aXBs ZSBpbnN0YW5jZXMgb2YgYSBUTFYgbWF5IGJlIGdlbmVyYXRlZCBieSB0aGUgQkdQLUxTCiAgIHJv dXRlciBmb3IgYSBnaXZlbiBub2RlIGluIHRoZSBJR1AgZG9tYWluLiAgVGhpcyBNQVkgaGFwcGVu IGlmIHRoZQogICBvcmlnaW5hbCBub2RlJ3MgbGluayBzdGF0ZSBhZHZlcnRpc2VtZW50IGNhcnJp ZXMgbW9yZSB0aGFuIDE2MzgzIG5vZGUKICAgYWRtaW5pc3RyYXRpdmUgZ3JvdXBzIGFuZCBhIHNp bmdsZSBUTFYgZG9lcyBub3QgcHJvdmlkZSBzdWZmaWNpZW50CiAgIHNwYWNlLiAgQXMgc3VjaCBt dWx0aXBsZSBvY2N1cmVuY2Ugb2YgdGhlICdOb2RlIEFkbWluIFRhZycgVExWcyB1bmRlcgogICBh IHNpbmdsZSBCR1AgTFMgTkxSSSBpcyBjdW11bGF0aXZlLgoKICAgV2hpbGUgY29weWluZyBub2Rl IGFkbWluaXN0cmF0aXZlIHRhZ3MgZnJvbSBJR1AgbGluay1zdGF0ZQogICBhZHZlcnRpc2VtZW50 cyB0byBjb3JyZXNwb25kaW5nIEJHUC1MUyBhZHZlcnRpc2VtZW50cywgdGhlIHNhaWQgQkdQLQog ICBMUyBzcGVha2VyIE1BWSBydW4gYWxsIHRoZSBub2RlIGFkbWluaXN0cmF0aXZlIGZsYWdzIHRo cm91Z2ggYQogICBsb2NhbGx5IGNvbmZpZ3VyZWQgcG9saWN5IHRoYXQgc2VsZWN0cyB3aGljaCBv bmVzIHNob3VsZCBiZSBleHBvcnRlZAogICBhbmQgd2hpY2ggb25lcyBub3QuICBBbmQgdGhlbiB0 aGUgbm9kZSBhZG1pbmlzdHJhdGl2ZSB0YWcgaXMgY29waWVkCiAgIHRvIHRoZSBCR1AtTFMgYWR2 ZXJ0aXNlbWVudCBpZiBpdCBpcyBwZXJtaXR0ZWQgdG8gZG8gc28gYnkgdGhlIHNhaWQKICAgcG9s aWN5LgoKNC4gIEVsZW1lbnRzIG9mIFByb2NlZHVyZQoKICAgTWVhbmluZyBvZiB0aGUgTm9kZSBh ZG1pbmlzdHJhdGl2ZSB0YWdzIGlzIGdlbmVyYWxseSBvcGFxdWUgdG8gQkdQCiAgIExpbmstU3Rh dGUgcHJvdG9jb2wuICBBIHJvdXRlciBhZHZlcnRpc2luZyB0aGUgbm9kZSBhZG1pbmlzdHJhdGl2 ZQogICB0YWcgKG9yIHRhZ3MpIG1heSBiZSBjb25maWd1cmVkIHRvIGRvIHNvIHdpdGhvdXQga25v d2luZyAob3IgZXZlbgogICBleHBsaWNpdGx5IHN1cHBvcnRpbmcpIGZ1bmN0aW9uYWxpdHkgaW1w bGllZCBieSB0aGUgdGFnLgoKICAgSW50ZXJwcmV0YXRpb24gb2YgdGFnIHZhbHVlcyBpcyBzcGVj aWZpYyB0byB0aGUgYWRtaW5pc3RyYXRpdmUgZG9tYWluCiAgIG9mIGEgcGFydGljdWxhciBuZXR3 b3JrIG9wZXJhdG9yLiAgVGhlIG1lYW5pbmcgb2YgYSBub2RlCiAgIGFkbWluaXN0cmF0aXZlIHRh ZyBpcyBkZWZpbmVkIGJ5IHRoZSBuZXR3b3JrIGxvY2FsIHBvbGljeSBhbmQgaXMKICAgY29udHJv bGxlZCB2aWEgdGhlIGNvbmZpZ3VyYXRpb24uICBIb3dldmVyIG11bHRpcGxlIGFkbWluaXN0cmF0 aXZlCiAgIGRvbWFpbiBvd25lcnMgbWF5IGFncmVlIG9uIGEgY29tbW9uIG1lYW5pbmcgaW1wbGll ZCBieSBhCiAgIGFkbWluaXN0cmF0aXZlIHRhZyBmb3IgbXV0dWFsIGJlbmVmaXQuCgogICBUaGUg c2VtYW50aWNzIG9mIHRoZSB0YWcgb3JkZXIgaGFzIG5vIG1lYW5pbmcuICBUaGVyZSBpcyBubyBp bXBsaWVkCiAgIG1lYW5pbmcgdG8gdGhlIG9yZGVyaW5nIG9mIHRoZSB0YWdzIHRoYXQgaW5kaWNh dGVzIGEgY2VydGFpbgogICBvcGVyYXRpb24gb3Igc2V0IG9mIG9wZXJhdGlvbnMgdGhhdCBuZWVk IHRvIGJlIHBlcmZvcm1lZCBiYXNlZCBvbiB0aGUKICAgb3JkZXJpbmcuCgogICBFYWNoIHRhZyBT SE9VTEQgYmUgdHJlYXRlZCBhcyBhbiBpbmRlcGVuZGVudCBpZGVudGlmaWVyIHRoYXQgTUFZIGJl CiAgIHVzZWQgaW4gcG9saWN5IHRvIHBlcmZvcm0gYSBwb2xpY3kgYWN0aW9uLiAgTm9kZSBhZG1p bmlzdHJhdGl2ZSB0YWdzCiAgIGNhcnJpZWQgYnkgdGhlIE5vZGUgQWRtaW4gVGFnIFRMViBTSE9V TEQgYmUgdXNlZCB0byBpbmRpY2F0ZQoKCgpTYXJrYXIsIGV0IGFsLiAgICAgICAgICAgRXhwaXJl cyBKYW51YXJ5IDUsIDIwMTggICAgICAgICAgICAgICAgW1BhZ2UgN10KDApJbnRlcm5ldC1EcmFm dCAgICAgICAgICBOb2RlIEFkbWluIFRhZ3MgaW4gQkdQLUxTICAgICAgICAgICAgICBKdWx5IDIw MTcKCgogICBpbmRlcGVuZGVudCBjaGFyYWN0ZXJpc3RpY3Mgb2YgdGhlIG5vZGUgaW4gSUdQIGRv bWFpbiB0aGF0IG9yaWdpbmF0ZWQKICAgaXQuICBUaGUgVExWIFNIT1VMRCBiZSBjb25zaWRlcmVk IGFzIGFuIHVub3JkZXJlZCBsaXN0LiAgV2hpbHN0CiAgIHBvbGljaWVzIG1heSBiZSBpbXBsZW1l bnRlZCBiYXNlZCBvbiB0aGUgcHJlc2VuY2Ugb2YgbXVsdGlwbGUgdGFncwogICAoZS5nLiwgaWYg dGFnIEEgQU5EIHRhZyBCIGFyZSBwcmVzZW50KSwgdGhleSBNVVNUIE5PVCBiZSByZWxpYW50IHVw b24KICAgdGhlIG9yZGVyIG9mIHRoZSB0YWdzIChpLmUuLCBhbGwgcG9saWNpZXMgc2hvdWxkIGJl IGNvbnNpZGVyZWQKICAgY29tbXV0YXRpdmUgb3BlcmF0aW9ucywgc3VjaCB0aGF0IHRhZyBBIHBy ZWNlZGluZyBvciBmb2xsb3dpbmcgdGFnIEIKICAgZG9lcyBub3QgY2hhbmdlIHRoZWlyIG91dGNv bWUpLgoKICAgRm9yIG1vcmUgZGV0YWlscyBvbiBndWlkYW5jZSBvbiB1c2FnZSBvZiBub2RlIGFk bWluaXN0cmF0aXZlIHRhZ3MKICAgcGxlYXNlIHJlZmVyIHRvIHNlY3Rpb24gNCBbNV0gaW4gW1JG Qzc5MTddLgoKNS4gIEFwcGxpY2F0aW9ucwoKICAgW1JGQzc5MTddIGFuZCBbUkZDNzc3N10gcHJl c2VudCBzb21lIGFwcGxpY2F0aW9ucyBvZiBub2RlCiAgIGFkbWluaXN0cmF0aXZlIHRhZ3MuCgog ICBUaGUgUG9saWN5LWJhc2VkIEV4cGxpY2l0IHJvdXRpbmcgdXNlIGNhc2UgY2FuIGJlIGV4dGVu ZGVkIHRvIGludGVyLQogICBhcmVhIG9yIGludGVyLUFTIHNjZW5hcmlvcyB3aGVyZSBhbiBlbmQg dG8gZW5kIHBhdGggbmVlZHMgdG8gYXZvaWQgb3IKICAgaW5jbHVkZSBub2RlcyB0aGF0IGhhdmUg cGFydGljdWxhciBwcm9wZXJ0aWVzLiAgRm9sbG93aW5nIGFyZSBzb21lCiAgIGV4YW1wbGVzLgoK ICAgMS4gIEdlb3BvbGl0aWNhbCByb3V0aW5nIDogcHJldmVudGluZyB0cmFmZmljIGZyb20gY291 bnRyeSBBIHRvCiAgICAgICBjb3VudHJ5IEIgdG8gY3Jvc3MgY291bnRyeSBDLiAgSW4gdGhpcyBj YXNlLCB3ZSBtYXkgdXNlIG5vZGUKICAgICAgIGFkbWluaXN0cmF0aXZlIHRhZ3MgdG8gZW5jb2Rl IGdlb2dyYXBoaWNhbCBpbmZvcm1hdGlvbiAoY291bnRyeSkuCiAgICAgICBQYXRoIGNvbXB1dGF0 aW9uIHdpbGwgYmUgcmVxdWlyZWQgdG8gdGFrZSBpbnRvIGFjY291bnQgbm9kZQogICAgICAgYWRt aW5pc3RyYXRpdmUgdGFnIHRvIHBlcm1pdCBhdm9pZGFuY2Ugb2Ygbm9kZXMgYmVsb25naW5nIHRv CiAgICAgICBjb3VudHJ5IEMuCgogICAyLiAgTGVnYWN5IG5vZGUgYXZvaWRhbmNlIDogaW4gc29t ZSBzcGVjaWZpYyBjYXNlcywgaXQgaXMgaW50ZXJlc3RpbmcKICAgICAgIGZvciBzZXJ2aWNlLXBy b3ZpZGVyIHRvIGZvcmNlIHNvbWUgdHJhZmZpYyB0byBhdm9pZCBsZWdhY3kgbm9kZXMKICAgICAg IGluIHRoZSBuZXR3b3JrLiAgRm9yIGV4YW1wbGUsIGxlZ2FjeSBub2RlcyBtYXkgbm90IGJlIGNh cnJpZXIKICAgICAgIGNsYXNzIChubyBoaWdoIGF2YWlsYWJpbGl0eSksIGFuZCBzZXJ2aWNlIHBy b3ZpZGVyIG1heSB3YW50IHRvCiAgICAgICBlbnN1cmUgdGhhdCBjcml0aWNhbCB0cmFmZmljIG9u bHkgdXNlcyBub2RlcyB0aGF0IGFyZSBwcm92aWRpbmcKICAgICAgIGhpZ2ggYXZhaWxhYmlsaXR5 LgoKICAgSW4gY2FzZSBvZiBpbnRlci1BUyBUcmFmZmljLUVuZ2luZWVyaW5nIGFwcGxpY2F0aW9u cywgZGlmZmVyZW50IEFTZXMKICAgU0hPVUxEIHNoYXJlIHRoZWlyIGFkbWluaXN0cmF0aXZlIHRh ZyBwb2xpY2llcy4gIFRoZXkgTUFZIGFsc28gbmVlZAogICB0byBhZ3JlZSB1cG9uIHNvbWUgY29t bW9uIHRhZ2dpbmcgcG9saWN5IGZvciBzcGVjaWZpYyBhcHBsaWNhdGlvbnMuCgogICBGb3IgbW9y ZSBkZXRhaWxzIG9uIHNvbWUgcG9zc2libGUgYXBwbGljYXRpb25zIHdpdGggbm9kZQogICBhZG1p bmlzdHJhdGl2ZSB0YWdzIHBsZWFzZSByZWZlciB0byBzZWN0aW9uIDMgWzZdIGluIFtSRkM3Nzc3 XS4KCjYuICBJQU5BIENvbnNpZGVyYXRpb25zCgogICBUaGlzIGRvY3VtZW50IHJlcXVlc3RzIGFz c2lnbmluZyBjb2RlLXBvaW50cyBmcm9tIHRoZSByZWdpc3RyeSBmb3IKICAgQkdQLUxTIGF0dHJp YnV0ZSBUTFZzIGJhc2VkIG9uIHRhYmxlIFRhYmxlIDIuCgoKCgoKU2Fya2FyLCBldCBhbC4gICAg ICAgICAgIEV4cGlyZXMgSmFudWFyeSA1LCAyMDE4ICAgICAgICAgICAgICAgIFtQYWdlIDhdCgwK SW50ZXJuZXQtRHJhZnQgICAgICAgICAgTm9kZSBBZG1pbiBUYWdzIGluIEJHUC1MUyAgICAgICAg ICAgICAgSnVseSAyMDE3CgoKNy4gIE1hbmFnZWFiaWxpdHkgQ29uc2lkZXJhdGlvbnMKCiAgIFRo aXMgc2VjdGlvbiBpcyBzdHJ1Y3R1cmVkIGFzIHJlY29tbWVuZGVkIGluIFtSRkM1NzA2XS4KCjcu MS4gIE9wZXJhdGlvbmFsIENvbnNpZGVyYXRpb25zCgo3LjEuMS4gIE9wZXJhdGlvbnMKCiAgIEV4 aXN0aW5nIEJHUCBhbmQgQkdQLUxTIG9wZXJhdGlvbmFsIHByb2NlZHVyZXMgYXBwbHkuICBObyBu ZXcKICAgb3BlcmF0aW9uYWwgcHJvY2VkdXJlcyBhcmUgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50 LgoKOC4gIFRMVi9TdWItVExWIENvZGUgUG9pbnRzIFN1bW1hcnkKCiAgIFRoaXMgc2VjdGlvbiBj b250YWlucyB0aGUgZ2xvYmFsIHRhYmxlIG9mIGFsbCBUTFZzL1N1Yi1UTFZzIGRlZmluZWQKICAg aW4gdGhpcyBkb2N1bWVudC4KCiAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0rLS0tLS0t LS0tLS0tLS0tLSstLS0tLS0tLS0tKwogICAgICAgICAgICAgIHwgVExWIENvZGUgUG9pbnQgfCBE ZXNjcmlwdGlvbiAgICB8ICBMZW5ndGggIHwKICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0t LSstLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0rCiAgICAgICAgICAgICAgfCAgICAgIDEwNDAg ICAgICB8IE5vZGUgQWRtaW4gVGFnIHwgdmFyaWFibGUgfAogICAgICAgICAgICAgICstLS0tLS0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLSsKCiAgICAgICAgICAgICBUYWJs ZSAyOiBTdW1tYXJ5IFRhYmxlIG9mIFRMVi9TdWItVExWIENvZGVwb2ludHMKCjkuICBTZWN1cml0 eSBDb25zaWRlcmF0aW9ucwoKICAgUHJvY2VkdXJlcyBhbmQgcHJvdG9jb2wgZXh0ZW5zaW9ucyBk ZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQgZG8gbm90CiAgIGFmZmVjdCB0aGUgQkdQIHNlY3VyaXR5 IG1vZGVsLiAgU2VlIHRoZSAnU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMnCiAgIHNlY3Rpb24gb2Yg W1JGQzQyNzFdIGZvciBhIGRpc2N1c3Npb24gb2YgQkdQIHNlY3VyaXR5LiAgQWxzbyByZWZlciB0 bwogICBbUkZDNDI3Ml0gYW5kIFtSRkM2OTUyXSBmb3IgYW5hbHlzaXMgb2Ygc2VjdXJpdHkgaXNz dWVzIGZvciBCR1AuCgoxMC4gIEFja25vd2xlZGdlbWVudHMKCiAgIFRCQS4KCjExLiAgUmVmZXJl bmNlcwoKMTEuMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzCgogICBbUkZDMjExOV0gIEJyYWRuZXIs IFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQogICAgICAgICAgICAg IFJlcXVpcmVtZW50IExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTksCiAgICAgICAgICAgICAgRE9J IDEwLjE3NDg3L1JGQzIxMTksIE1hcmNoIDE5OTcsCiAgICAgICAgICAgICAgPGh0dHA6Ly93d3cu cmZjLWVkaXRvci5vcmcvaW5mby9yZmMyMTE5Pi4KCiAgIFtSRkM0MjcxXSAgUmVraHRlciwgWS4s IEVkLiwgTGksIFQuLCBFZC4sIGFuZCBTLiBIYXJlcywgRWQuLCAiQQogICAgICAgICAgICAgIEJv cmRlciBHYXRld2F5IFByb3RvY29sIDQgKEJHUC00KSIsIFJGQyA0MjcxLAogICAgICAgICAgICAg IERPSSAxMC4xNzQ4Ny9SRkM0MjcxLCBKYW51YXJ5IDIwMDYsCiAgICAgICAgICAgICAgPGh0dHA6 Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM0MjcxPi4KCgoKU2Fya2FyLCBldCBhbC4gICAg ICAgICAgIEV4cGlyZXMgSmFudWFyeSA1LCAyMDE4ICAgICAgICAgICAgICAgIFtQYWdlIDldCgwK SW50ZXJuZXQtRHJhZnQgICAgICAgICAgTm9kZSBBZG1pbiBUYWdzIGluIEJHUC1MUyAgICAgICAg ICAgICAgSnVseSAyMDE3CgoKICAgW1JGQzc3NTJdICBHcmVkbGVyLCBILiwgRWQuLCBNZWR2ZWQs IEouLCBQcmV2aWRpLCBTLiwgRmFycmVsLCBBLiwgYW5kCiAgICAgICAgICAgICAgUy4gUmF5LCAi Tm9ydGgtQm91bmQgRGlzdHJpYnV0aW9uIG9mIExpbmstU3RhdGUgYW5kCiAgICAgICAgICAgICAg VHJhZmZpYyBFbmdpbmVlcmluZyAoVEUpIEluZm9ybWF0aW9uIFVzaW5nIEJHUCIsIFJGQyA3NzUy LAogICAgICAgICAgICAgIERPSSAxMC4xNzQ4Ny9SRkM3NzUyLCBNYXJjaCAyMDE2LAogICAgICAg ICAgICAgIDxodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNzc1Mj4uCgoxMS4yLiAg SW5mb3JtYXRpdmUgUmVmZXJlbmNlcwoKICAgW1JGQzQyNzJdICBNdXJwaHksIFMuLCAiQkdQIFNl Y3VyaXR5IFZ1bG5lcmFiaWxpdGllcyBBbmFseXNpcyIsCiAgICAgICAgICAgICAgUkZDIDQyNzIs IERPSSAxMC4xNzQ4Ny9SRkM0MjcyLCBKYW51YXJ5IDIwMDYsCiAgICAgICAgICAgICAgPGh0dHA6 Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM0MjcyPi4KCiAgIFtSRkM1NzA2XSAgSGFycmlu Z3RvbiwgRC4sICJHdWlkZWxpbmVzIGZvciBDb25zaWRlcmluZyBPcGVyYXRpb25zIGFuZAogICAg ICAgICAgICAgIE1hbmFnZW1lbnQgb2YgTmV3IFByb3RvY29scyBhbmQgUHJvdG9jb2wgRXh0ZW5z aW9ucyIsCiAgICAgICAgICAgICAgUkZDIDU3MDYsIERPSSAxMC4xNzQ4Ny9SRkM1NzA2LCBOb3Zl bWJlciAyMDA5LAogICAgICAgICAgICAgIDxodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8v cmZjNTcwNj4uCgogICBbUkZDNjk1Ml0gIEpldGhhbmFuZGFuaSwgTS4sIFBhdGVsLCBLLiwgYW5k IEwuIFpoZW5nLCAiQW5hbHlzaXMgb2YKICAgICAgICAgICAgICBCR1AsIExEUCwgUENFUCwgYW5k IE1TRFAgSXNzdWVzIEFjY29yZGluZyB0byB0aGUgS2V5aW5nCiAgICAgICAgICAgICAgYW5kIEF1 dGhlbnRpY2F0aW9uIGZvciBSb3V0aW5nIFByb3RvY29scyAoS0FSUCkgRGVzaWduCiAgICAgICAg ICAgICAgR3VpZGUiLCBSRkMgNjk1MiwgRE9JIDEwLjE3NDg3L1JGQzY5NTIsIE1heSAyMDEzLAog ICAgICAgICAgICAgIDxodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNjk1Mj4uCgog ICBbUkZDNzc3N10gIEhlZ2RlLCBTLiwgU2hha2lyLCBSLiwgU21pcm5vdiwgQS4sIExpLCBaLiwg YW5kIEIuCiAgICAgICAgICAgICAgRGVjcmFlbmUsICJBZHZlcnRpc2luZyBOb2RlIEFkbWluaXN0 cmF0aXZlIFRhZ3MgaW4gT1NQRiIsCiAgICAgICAgICAgICAgUkZDIDc3NzcsIERPSSAxMC4xNzQ4 Ny9SRkM3Nzc3LCBNYXJjaCAyMDE2LAogICAgICAgICAgICAgIDxodHRwOi8vd3d3LnJmYy1lZGl0 b3Iub3JnL2luZm8vcmZjNzc3Nz4uCgogICBbUkZDNzkxN10gIFNhcmthciwgUC4sIEVkLiwgR3Jl ZGxlciwgSC4sIEhlZ2RlLCBTLiwgTGl0a293c2tpLCBTLiwKICAgICAgICAgICAgICBhbmQgQi4g RGVjcmFlbmUsICJBZHZlcnRpc2luZyBOb2RlIEFkbWluaXN0cmF0aXZlIFRhZ3MgaW4KICAgICAg ICAgICAgICBJUy1JUyIsIFJGQyA3OTE3LCBET0kgMTAuMTc0ODcvUkZDNzkxNywgSnVseSAyMDE2 LAogICAgICAgICAgICAgIDxodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNzkxNz4u CgoxMS4zLiAgVVJJcwoKICAgWzFdIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc3NTIj c2VjdGlvbi0zLjIKCiAgIFsyXSBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NzUyI3Nl Y3Rpb24tMy4yLjEuNAoKICAgWzNdIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc5MTcj c2VjdGlvbi0zLjEKCiAgIFs0XSBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3Nzc3I3Nl Y3Rpb24tMi4xCgogICBbNV0gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzkxNyNzZWN0 aW9uLTQKCiAgIFs2XSBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3Nzc3I3NlY3Rpb24t MwoKCgoKClNhcmthciwgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgNSwgMjAxOCAg ICAgICAgICAgICAgIFtQYWdlIDEwXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgIE5vZGUgQWRt aW4gVGFncyBpbiBCR1AtTFMgICAgICAgICAgICAgIEp1bHkgMjAxNwoKCkF1dGhvcnMnIEFkZHJl c3NlcwoKICAgUHVzaHBhc2lzIFNhcmthciAoZWRpdG9yKQogICBBcnJjdXMsIEluYy4KCiAgIEVt YWlsOiBwdXNocGFzaXMuaWV0ZkBnbWFpbC5jb20KCgogICBIYW5uZXMgR3JlZGxlcgogICBSdEJy aWNrLCBJbmMuCgogICBFbWFpbDogaGFubmVzQHJ0YnJpY2suY29tCgoKICAgU3RlcGhhbmUgTGl0 a293c2tpCiAgIE9yYW5nZQoKICAgRW1haWw6IHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29t CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKClNhcmthciwgZXQgYWwuICAgICAgICAg ICBFeHBpcmVzIEphbnVhcnkgNSwgMjAxOCAgICAgICAgICAgICAgIFtQYWdlIDExXQo= --f403045eb0d0df222d05538a0043-- From nobody Wed Jul 5 01:29:48 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 828BF131B30 for ; Wed, 5 Jul 2017 01:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 AwusUI8Zs3cE for ; Wed, 5 Jul 2017 01:29:44 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FAC7131B34 for ; Wed, 5 Jul 2017 01:29:44 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id z62so81838907ioi.3 for ; Wed, 05 Jul 2017 01:29:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=oiUb83mebApxyor7W0Q1MOZUJ8GVGDkHWJ3zsFGBPvA=; b=sGBtlZh+wdSMc3vmO3Z1nUwEDYVI7QYzoQaQFaVV1Z6KcuwlDPbz+wScTUUvqXbd8l DgKfcfjM3mMjuZrweRmTCExWgvIYrcHuo2HOPH2aa3w497spJDkNXlCQ47PaLrZPy2ZE sXYFEqtRjTYPTSJv3MdplS6BDq2YpWjEPmQkSAVtsUmHJGGxbwi3i8tkRcrr8OjJgxxD aPoisiReuaXrXsG3YztUvVq9/ztbO5zM7xGIclK46lPYCzRoLJg4w68juTCf4u6LA6/w 8kqha0dXXQ88gqy1J6Q2c6wOCVr0JKl3bM/XD2kLC5woXMAZoqFfqsTMRiAqdtdnphgU GXwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=oiUb83mebApxyor7W0Q1MOZUJ8GVGDkHWJ3zsFGBPvA=; b=hSeuMD45Ysryb/HfU1TLJ+g8bXRsnPINJ6ve6NgvpOK6rSd6+LRoykGagjMzIVBRig Cco1M0IVW0pR5yWGiQ1evUd9/heffwDCyTXArI23KaksRQX9nzi2Q31rwHaseg/t/I+/ 31E/cz6FCLcebuqjZ8KoAK2qfjEptEDWPlcJ37zpo41V5P2JzW4bSS2kQw269Ma8kC1j lJNijhwOmioqNenmPPIZ8p3fZBrhZgYVo4okyY3kteyKLcBk+3YksRCuzPt5bRF1Um1i C58luqKQtTt7smXYttwxIRB6ge0uA9wOXoO7NBZyPpPscgqEq6W0O0R+mbgSEm70hV46 K5Dw== X-Gm-Message-State: AIVw111p0kExSJDYlxQPoyACsYCIB9w9DAFa9AqLUtHt7PaWEUUojsa4 7s2OQEbgxVD8j6+Ryu5t2C5QAAU6Xg== X-Received: by 10.107.140.145 with SMTP id o139mr24472974iod.155.1499243383552; Wed, 05 Jul 2017 01:29:43 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.32.15 with HTTP; Wed, 5 Jul 2017 01:29:41 -0700 (PDT) Received: by 10.79.32.15 with HTTP; Wed, 5 Jul 2017 01:29:41 -0700 (PDT) In-Reply-To: References: <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> <09BFF794-6899-4DA5-8EF5-DDF86513BFBA@pfrc.org> <20170704104840.mg5bflnmmjlv4jbi@Vurt.local> <20170704175334.GO2289@pfrc.org> From: Robert Raszuk Date: Wed, 5 Jul 2017 10:29:41 +0200 X-Google-Sender-Auth: CHL8k_kQ0baCzjiSXTa8FsjcY3Q Message-ID: To: PFRC - jhaas Cc: idr wg Content-Type: multipart/alternative; boundary="94eb2c05a5444f001d05538dcdd4" Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 08:29:46 -0000 --94eb2c05a5444f001d05538dcdd4 Content-Type: text/plain; charset="UTF-8" Neither did I. Add-paths is for all clients while signalled bfd state of remote nhs is per client. And this is the issue. Thx R. On Jul 5, 2017 04:47, "Jeffrey Haas" wrote: > On Jul 4, 2017, at 8:27 PM, Robert Raszuk wrote: > > Jeff, > > Running add paths for common policy paths vs per client best path are orders of magnitude more work. > > I can not believe why you would think otherwise ... At no point did I state add-paths would be per client. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --94eb2c05a5444f001d05538dcdd4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Neither did I.=C2=A0

Add-paths is for all clients while signalled bfd state of remote = nhs is per client.

And this is= the issue.

Thx
R.

On Jul 5, 2017 04:47, "Jeffrey Haas" <jhaas@pfrc.org> wrote:

> On Jul 4, 2017, at 8:27 PM, Robert Raszuk <robert@raszuk.net> wrote:
>
> Jeff,
>
> Running add paths for common policy paths vs per client best path are = orders of magnitude more work.
>
> I can not believe why you would think otherwise ...

At no point did I state add-paths would be per client.
___________________________________________= ____
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

--94eb2c05a5444f001d05538dcdd4-- From nobody Wed Jul 5 08:05:12 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8800B132A49 for ; Wed, 5 Jul 2017 08:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 J4w0nPmJvmar for ; Wed, 5 Jul 2017 08:05:08 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06854131D51 for ; Wed, 5 Jul 2017 08:05:08 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id z62so87324767ioi.3 for ; Wed, 05 Jul 2017 08:05:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=AFIHDDbw9bUiWL64H6Db20jxLjJYWjB4hjN3pkd2FVI=; b=o5KIl8AyOKg+cMx/2DYc/wh3VDRiHJF1HQZbZXzv6n4p4kjf3QZcLsQFtAQSNA71c6 TmGwy7F+sZi/V69SigpwbsvSMCklXjjHrY1WJwUEO7sDg9xubuQFdnbP1bVAq6UOr1Cg l3iugqWfLGfytCObvhbsvn7C9IOKpZ1kqsHlPIIPQO3sTs1ZLEKnmsegIhxplLMWe+Vx 9mgRjm1+UWW5WZP49QUn/WOO6h+rzyc4yyhcZQuUwg9o8+lLIxCnkQG9gEdxxRBPU56W zljUsKhAMA6mU7e+rgHdcD5sAw9w0GQZILlrnVAQwKjdS9cHkFiCnDMQJ3OOj3V35MIy eKuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=AFIHDDbw9bUiWL64H6Db20jxLjJYWjB4hjN3pkd2FVI=; b=XOsHpnZgZKg95Nj2/hmwIxsb+WCJ1QsU3jdpK+iD+nKAHO3jkG8ZTzAD1gcpaZGDXI 8jFucEoli0gbFOm3/l4eRX0RgKbUqObrD+TYcegIeHdk6pSTidWTj0KFPATrbsN+IHmJ vsbu0zjN30NKCBiTms4Qo2wd5olntnTbnyg7fuioy+gttwByig8G5ced8kXC1G84XP1B 8R861RcdbXs2D4loVI8NOe5hhQeSV0yG/7tMpMvZsbgzF1kMa64HUu30RWaTOTpjLvoR inUvDkCEECetrEQYuqbW5Yqe0exWj1bRxLnjNP5ZmvOS2QcEaDQqBYU2Uk0tf1d3QpO2 fyQA== X-Gm-Message-State: AKS2vOxlmotTON5O2hQ6MozfchZjYFL5m7fJcI7pfJ3IldxRsmtq3LJK DIkFAnSLm/X+nD53nAlObJvKlzBD7rNy X-Received: by 10.107.128.30 with SMTP id b30mr31675979iod.179.1499267107198; Wed, 05 Jul 2017 08:05:07 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.32.15 with HTTP; Wed, 5 Jul 2017 08:05:05 -0700 (PDT) Received: by 10.79.32.15 with HTTP; Wed, 5 Jul 2017 08:05:05 -0700 (PDT) In-Reply-To: <20C02BA3-5C13-46FB-AFE8-85D61E469EA1@juniper.net> References: <20170703175308.hembxkplaniz66wb@Vurt.local> <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> <09BFF794-6899-4DA5-8EF5-DDF86513BFBA@pfrc.org> <20170704104840.mg5bflnmmjlv4jbi@Vurt.local> <20C02BA3-5C13-46FB-AFE8-85D61E469EA1@juniper.net> From: Robert Raszuk Date: Wed, 5 Jul 2017 17:05:05 +0200 X-Google-Sender-Auth: EA3sVkRDF2N_pjToeXqE6UWZQLI Message-ID: To: "John G. Scudder" Cc: idr wg Content-Type: multipart/alternative; boundary="001a113f8b12591f7d055393539f" Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 15:05:10 -0000 --001a113f8b12591f7d055393539f Content-Type: text/plain; charset="UTF-8" Hi John, You are describing the situation where client notices next hop down, notifies RS but does not get new path till other clients also report the same next hop as down. Is this really a good idea ? Note that due to selective policy only very few clients may get given path so your heuristic would now also need to account for static or dynamic (signalled with communities) policies. Well I have nothing against machine learning or AI, but do we really need it here on RSes ? Thx R. On Jul 4, 2017 17:55, "John G. Scudder" wrote: > One observation regarding the "RR won't scale if it has to do per-client > route selection" concern -- it seems to me it would be entirely feasible > for an implementation to associate some figure-of-merit with each next hop, > a function of its reported reachability by each of its indirect peers. That > figure-of-merit could be used during traditional (not per-client) route > selection. The general idea would be "if one other client can't reach you, > that's their problem, if dozens of other clients can't reach you, maybe we > should choose a different next hop if we've got one" [*]. Think of it as > making the binary resolvability condition of RFC 4271 9.1.2.1 fuzzy. > > I think specifying the function would be beyond the scope of this (or > really, any) draft since it's "just policy". But it demonstrates there's > some potential benefit from the proposal without going all the way down to > per-client route selection. > > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --001a113f8b12591f7d055393539f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi John,

You= are describing the situation where client notices next hop down, notifies = RS but does not get new path till other clients also report the same next h= op as down.

Is this real= ly a good idea ?

Note th= at due to selective policy only very few clients may get given path so your= heuristic would now also need to account for static or dynamic (signalled = with communities) policies.

Well I have nothing against machine learning or AI, but do we really ne= ed it here on RSes ?

Thx=
R.

On Jul 4, 2017 17:55, "John G. Scudder" <= jgs@juniper.net> wrote:
One observation regarding t= he "RR won't scale if it has to do per-client route selection"= ; concern -- it seems to me it would be entirely feasible for an implementa= tion to associate some figure-of-merit with each next hop, a function of it= s reported reachability by each of its indirect peers. That figure-of-merit= could be used during traditional (not per-client) route selection. The gen= eral idea would be "if one other client can't reach you, that'= s their problem, if dozens of other clients can't reach you, maybe we s= hould choose a different next hop if we've got one" [*]. Think of = it as making the binary resolvability condition of RFC 4271 9.1.2.1 fuzzy.<= br>
I think specifying the function would be beyond the scope of this (or reall= y, any) draft since it's "just policy". But it demonstrates t= here's some potential benefit from the proposal without going all the w= ay down to per-client route selection.

--John
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr
--001a113f8b12591f7d055393539f-- From nobody Wed Jul 5 08:21:34 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7558B131635 for ; Wed, 5 Jul 2017 08:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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 nta2btdvNzmp for ; Wed, 5 Jul 2017 08:21:30 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 B4B46131453 for ; Wed, 5 Jul 2017 08:21:30 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id m84so88123534ita.0 for ; Wed, 05 Jul 2017 08:21:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=+fBJ/cUjXDGxvu3/RxNrJvm40CXTrIvMYR08CmQMKaU=; b=K1wbgUVSuIqlOFBnghauxDFvrtfeNYFTah536fW0s8OwBt0PZpzD4kqw5B4jR9GLt2 DxNu8Oi0T7GjEJdTGbEgEYnG+ywlE6TCcdr5P0wusInBm/qE0gWJW8ZYpjKbv38zrLrx HClo2YCAWGangWk05j84AoiaRuZXhGjVbgDa2HQEmtJ/sRPYlNz9gGgVi8Z8FyiWsBaG HkS5Mz2l3suIwlIem52Zh6IujWDjZnipaD/lE0oLqMl3g7NE/g+R2x9848KfZMWITzyB Baevh2ouc/YH4MZ2isRdz4WxKzWRu4o2Y02MidZ7OB5VRlWljpgHE6aDH9tzMfJmTZJu QNXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=+fBJ/cUjXDGxvu3/RxNrJvm40CXTrIvMYR08CmQMKaU=; b=mUh1YumzLzc+u81OnEiPL+cF/9fGX9Qa7OW0Ndgp7fANJQ48slfxXOJCEErVH8nwAQ wWdNBd+MH8e2xlPwf4r6IBbueaeYr22qfRmFE+5Gi/QBLic+lZ3ScErU++cFQhbwF0fE uTNYQR19OpgsrzhOs+ruD4ecv7liAzDX49sI044Y3RZPeLB+XoB6gbWHVoAfo5Vvewyb yziZEXwSRTJKZAfM1R1OQCYE0Lpv+S1u1dmrLA7O7tf4aXlVvRpXDntw5od3F/j7lGTN dSZb1vJmhB8B6rta6+DKUAA/U0VBQzF36iWUrax+hadI17QrW7LXH3ELQF5QHQnux0od cNng== X-Gm-Message-State: AIVw1112pVYo8miycy8VjONFxPr7B0HwqjbgO91SEG3wpSbFrTV2au9l 5HCq66sRql9N6uDy4JnibkAI0oCd2rqS X-Received: by 10.36.20.137 with SMTP id 131mr20139437itg.104.1499268090016; Wed, 05 Jul 2017 08:21:30 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.32.15 with HTTP; Wed, 5 Jul 2017 08:21:28 -0700 (PDT) Received: by 10.79.32.15 with HTTP; Wed, 5 Jul 2017 08:21:28 -0700 (PDT) In-Reply-To: References: <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> <09BFF794-6899-4DA5-8EF5-DDF86513BFBA@pfrc.org> <20170704104840.mg5bflnmmjlv4jbi@Vurt.local> <20170704175334.GO2289@pfrc.org> From: Robert Raszuk Date: Wed, 5 Jul 2017 17:21:28 +0200 X-Google-Sender-Auth: 7O9HnEMXMhZoeVsusrcUjxfdtZ8 Message-ID: To: PFRC - jhaas Cc: idr wg , Job Snijders Content-Type: multipart/alternative; boundary="001a1143e196edbb4c0553938dd4" Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 15:21:32 -0000 --001a1143e196edbb4c0553938dd4 Content-Type: text/plain; charset="UTF-8" Jeff, > What I don't understand is why you > object to someone else doing > something different. The draft proposes a solution which does not allow to locally repair paths. That is my biggest issue with this draft. Solutions which do allow for local repairs are available so why don't we encorage their use instead of inventing alternatives ? As to doing something different by someone else is there a pointer to existing implementations of this wg proposal ? Are those implementations able to support add-paths ? Thx, R. --001a1143e196edbb4c0553938dd4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Jeff,
<= br>
> What I don't understand is why= you
> object to=C2=A0someo= ne else doing=C2=A0
> somet= hing different.

The draft proposes a solution which doe= s not allow to locally repair paths. That is my biggest issue with this dra= ft.

Solutions which do allow for local repairs are avai= lable so why don't we encorage their use instead of inventing alternati= ves ?

As to doing something different by someone else i= s there a pointer to existing implementations of this wg proposal ?

Are those implementations able to support add-paths ?

Thx,
R.

<= /div>
--001a1143e196edbb4c0553938dd4-- From nobody Wed Jul 5 09:43:59 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E04D131848 for ; Wed, 5 Jul 2017 09:43:57 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, T_SPF_HELO_TEMPERROR=0.01, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net 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 KorHKsoHefb7 for ; Wed, 5 Jul 2017 09:43:55 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0102.outbound.protection.outlook.com [104.47.36.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D12CB13154B for ; Wed, 5 Jul 2017 09:43:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=I2rK8xs5RD5LW5wvweTRsKcg9AjwCqpjAIH1VXVpDPc=; b=MVg+7Alj62BIsJXIjsM0fPlPDNGOZp/mMpohsraQmcPrV3raanEUkc7R7Av5a//3BmyxSLXH58UnKtUtbZ4RMriHscBy83jlBDd7I5l2Z5os0Ye9Msmiovl0nXqVZF8GI4T6s1GrDcrSVZYh+4loLgU5fHzM4hozweRE3g2ArcE= Authentication-Results: raszuk.net; dkim=none (message not signed) header.d=none;raszuk.net; dmarc=none action=none header.from=juniper.net; Received: from askhan-sslvpn-nc.jnpr.net (66.129.241.13) by SN2PR05MB2509.namprd05.prod.outlook.com (10.166.213.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.6; Wed, 5 Jul 2017 16:43:53 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_04D74F30-F904-4AD5-BFD6-BCB08611E1F9" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Scudder In-Reply-To: Date: Wed, 5 Jul 2017 12:43:49 -0400 Cc: idr wg Message-Id: <1FD8FAE9-E6BF-4C48-BCD6-12C1012827E2@juniper.net> References: <20170703175308.hembxkplaniz66wb@Vurt.local> <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> <09BFF794-6899-4DA5-8EF5-DDF86513BFBA@pfrc.org> <20170704104840.mg5bflnmmjlv4jbi@Vurt.local> <20C02BA3-5C13-46FB-AFE8-85D61E469EA1@juniper.net> To: Robert Raszuk X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: BN6PR08CA0068.namprd08.prod.outlook.com (10.172.144.30) To SN2PR05MB2509.namprd05.prod.outlook.com (10.166.213.18) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 20d453ae-38d3-41cc-823e-08d4c3c505d0 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(48565401081)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:SN2PR05MB2509; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 3:27rRut1JYPN3Q/ZO9CvrzS94doIpuTzv9rc/rvvObvWlG/Lr0Xn0Y2L2/BkeF1egmD5n+SLdXEPC7iTBhp7zBtocYHAEnrfVPMA8lBXSijs0vS+99tcDbyBKu6i54v/twrbdS70yk+dT2q5WBTKr0q7fmEJjNytd8FggNKt9C7soJOzjTAMaM99fpB6M3qXt/dKprq6fNqzFvNadahvxvYHCUCDqOkRzVhCbhQLlquu+AnjjXgW9pGM9cc+TK7pG5Fg3d0d5e45AgbnW80FurqZOF6L37l8FKgE39YQm8W0FVdFZ1rScSuFMA1xwAeoOL+6WkrX5fQDsr8ZMi7oPGj7yIASOWzG2+Vl/HApB7mfb32AEo007+6k4Za9vA/XT5lMkxsCnHgyOZPv0vDQupcCDJP9x7zYTt85Z7tWjelhKUh911g7yL1yP5yIgJ+e+S7HO19KbNVO/Y+EcNhXHJnNpD4fjWMfumKuxOX3XTDXh0gg4Bd3SNqFxImL50I8jZhPqlMA9pROHJR6RiwlikMEFunM+umguMN4Yy32KtyGlrZ+7jNS8eirYIoCQpTn1l3CHEkxcc6r2PYQ3G7+9SUro+02MUaCP4TfYgoJl7FRD3dfDI/dWG34RmAu/c1JRSCIXZtjXRxkq7qQzAKq6mYJc/4IPRDjGc0idm0cXdRshe6u/tkT0pFd2DRwb26OzmM5FlFcBGwYhQCYjIQwqQMHhuTOuZPm7ogrPY9XXL7HLvVHRL/0iFb2TeTAgr1GTW8I01rK6oBJ5Mal9fqE7AQ== X-MS-TrafficTypeDiagnostic: SN2PR05MB2509: X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 25:RUA5ul5Jq2/x9yruNp1u8VEQ015gzPF25okFEg0xZD+i7VOs+eJelQ4j3NW9pPqCWTbl6T2GxY8Y9UpujXYn4ybV4jKWcZOZZOOtu+4iYuv7CG8ZB/JFBI/np1nuCKkQI2gqdYG1AnYqtPo/XB66OXTsn4aYHXK4Q8VoTfd7LvbqZSAu/QEvh0tIBnCi8DPzIZ+8KVsrzgrmRrek/5mDR8yu+DwACWxGrvxsEpDR8GVynldl8joTaA12Ccx+cbgcuFBBlXHGh6VeSuRPM+spE01+jXqc3Poh2pcFAcw+WcMMmjTnZesRmsAfMbAwDn3R8EBUKOjJpQHqgO9pqImfxDdNfOMUZ+NhW3FpeC4G+7hF9pIqyFO30EPsh5MF7rX0xHX21e+BnLHvrkoAiHCpsH7VXbvJaAF/kk3YohQX07ClYjm2Kgc6CXm+KGYzHbGwGuKzvTAMeQwzUACuJ0Sp4UvZ/rPHKejIevpxbAbyAgP/cDo9+2h4OpBctpURI1Vp2yOqxX+5YxyZQzd8xapiNyLlzLY/GIC7P0YadtXqSxK5M+cDGPZIIcFgD+CzWrMZQuwhTT1xe1PR4BS/fLi5c2hc6gMCefk+ayGvrgAyu3dN3O6j2xVCStKhTrmWpP3ImPKJnOogNAZFCC7ctsQbQwCndAbI6eWIspsxDHU9std2nFnURsH/JJ6mV/2loTTQMKYhPfT674P/qfjw14Ubv5xZrN0e0T9xk3ug+bN13sAzxslGCBIoaH8HvP61dejCUkAr1kJ7U8/jAGmevUM2IgoscWSr5wjclyn47l1EVxS1Kapz1UHy/tHHNreKQfbX6pnMSC7vv4fnLrbtCT9yYe0UYAVu0b/dR12YwgjSoNQqs5TZgqosAl+krf8t/EqbDnwp4nZ0CMp3tL1dPaYuowOY4Dp+7/ffppKeh8pMC40= X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 31:L4l1Nmo1BeCpkPXnhI8dDv+ECcXRMGUjahwWuXX7ntBkHdApWU9DfkmUoL44mU3jtPRgSA6zdFQq3XwqZLFR6Ljh1dOJth9YqnpnAng4uPe2Ozk8Qbqi4GnpCs30XHGKnT182ZZTJg8m+xlqGgh2mdxdzi2oA7S9ja5BPvnaGPG90TjhynKrXf9gPCgDVMIHY8rOcizqoj93xI0ntp90cAuJbd4DTwA2AHT10p5erCm0qmcbgWdFa8KiZXI4QC08k3/OngFy17+2rXn5Ghx+ZYP0KLyHoBTVGRC1DiN9WyTzdi8j/6riW+59SwKkoCwY6eJV6fnFePUALQ72c4OeFqoNdyYbsxiAW+alxRTLe3Nv8QtEom+7I4deUKQXiWhoHq172dlcdKM2uEcOFnoILXCnEoz+YqdGGaHEwx0M2q4SDuqiO0GAsXrX5ulhtk0JLAAa4OrfxKjBqE1A428jytB9FvPtvIZLE/4wQ39bBObfY/zKvuJ2f35jsPzpThY+vmN3vqSlkItL5h/bAUAk1FcbQLvGUUdnHkTKf/bu85oxQNtvEBFrXjjGSxMou20dqEeTFxGON7HsL0SK6hCT0qzFd1wXolsZB2gOVkccMP9ipxp1z3YgjJNmPs8K/RISiQcwCTFggI6zOlNzMU3O8zGrKn+q28mXgE7JLL4caJyxkB928H8tHV+msNJxbXEsQELzNUb5oOKdb7oPI1u7Eg== X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 20:vNF0euV2k4fFKf3kjtNe6BxZhTQI7QZyXQYo1jyNzDiG3eBAPrDGnFrmL+r0c/ddK9WtvBK3i2Je47ZZCNzwz3sGMqXGIBQGvrNZ63Izk0dJZSpF4NEH3LzOf4UxRObQNCV1PJydWOAWfMLs81K/pK+do5fjs4Ia1AocIegK1IuWs/0w6lF1YIhTzm97VGQkqRu/dlnSb3WpwneWLpyApNaUXDrL0n8hxp9pjIuf9R4VWZJAjq7EJ7S7EWF+5vCaRg1j0UL/NZG1NsKGkOJ1koyN+1NsHcpdQ+yNJ3xu43ts97boYx+5rWcaennbNcRYtkzuU1iMyiZ/M0zM5+6BmLfGj9Nh2LhWm7S72dgclTyjH93HyBp7kWMebHgOz+LfgMNTApHCJqfbKwWrDDoxlrjUpZbtIwN1L4Gtc1ac8wHlTOfFHY/ghsRFR93FghsKJpKOIzfFMt3AFV6+Se3LnHYVmciJMxGeLoEuvsjtnt7Iwb8k31+fbJfwlZEzG9tKyTPOc7jBjsxlm43tD0w3rxisB4F80nrhqrRlBMmPqDAbp8vQ91EMhkQQEwkVMZ4f1qDMO0+4FSJ3QeG26CzR0aQbwdmkGmkt8FDxaajAt+k= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(236129657087228)(138986009662008)(48057245064654)(148574349560750)(50300203121483)(247924648384137); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(2017060910033)(5005006)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123555025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN2PR05MB2509; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN2PR05MB2509; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR05MB2509; 4:iwRzVHtybAsIZmMdZpyO+M0rm3qHOReyV2/+OtV9Cc?= =?us-ascii?Q?68yuuz/oEMptH52FfswWyl2dYfNwJJ17aph3nPZn6V5H+ej0bWsc/OiofgIM?= =?us-ascii?Q?pNIF+C12Tp3cz0SHeWI+5hBF06lLPBsMgJZ/DjXKF9v+gZQcC6xkSvx2yJfn?= =?us-ascii?Q?y+FKDZ7woHVHR1Mo8t92ISqU7kQPtpV778id4pO+pPj59Jdk1t4IQuC+XrRM?= =?us-ascii?Q?MhJAYOyuVC0RDPLEtfboty8qvvgGsQ5G9Dg6bwdBt2xug4XwdicjznSafoSL?= =?us-ascii?Q?srFFovL+t8Nj6ExfCoevxzxv6l0X+7QiNiBGNSOTFHkxUimItxyaeC0qSKul?= =?us-ascii?Q?cd5RFna1+TmBn/szDRNBmT4LKV+fqF6prIarPENH428i/Gz44YAqT6fqFHsX?= =?us-ascii?Q?aSNNQ+Ab5rtHoedrGKY1RkDHXtcbR/cKvf3Sf5zRrncerGn+Z+R++EWI5f9i?= =?us-ascii?Q?ENLD+RvwjMzGkxkm1yb3QF1m+SVcZ1yGdV6rSZIlgia4D0t3TMGETX+MjhKc?= =?us-ascii?Q?7/qMfahNidtRWWQH6NAndYXOkNG0PBIrV6f5wztAbbFzKtA9cGmDPil1Nou7?= =?us-ascii?Q?JFYah4OueHtVNb21yQVFJ+iOHGxZzLA0e7qaU1L/S4j0YdmfBeMGlvYMJEEr?= =?us-ascii?Q?QwsFYPSx2pUAN7o3dhLNf5MWOKyOfqAaGEcJDCe3OedrJcudBKOXKbKdV+KX?= =?us-ascii?Q?Txge57oG+U1YewJt1CNQ8og5sDTnjLPxwBIACaZSHQj4+w0I+ztR1jZ/t4UH?= =?us-ascii?Q?DR6ys+2ZOKtNk/bHB25qm0rv6/oYfwiBFDlSbdegNNutuIBIRV8npaXAuB5T?= =?us-ascii?Q?qZKoSAcjWBbOH/32muibY1PL5LS2JLqavAMf63Fm5xtUSfDbNUdAiJxzT7Ie?= =?us-ascii?Q?D9c94a2uXyfwMDnlA8qzjlOqo1nKA5PM4QhtZpCzJKum+EJxXYdy7O9JJasU?= =?us-ascii?Q?peDgZwmGdoqX0DNMZtGEkOXP7cLgW+Zo/3RlvkcCW2lSqpKDlwpfhbMoCEtp?= =?us-ascii?Q?rG5V1Xakaf6hjVbQDX03HYGDrptVMRTTlK2pWe4gWgwqvED4jCB56f3ed4mP?= =?us-ascii?Q?RiNyatg+a22EgJGKwqUJJjaoz0a5AfeYndwfiwRRa7g9M+ao+07cME/BCACs?= =?us-ascii?Q?6bh47TAHRASpU4OmixVu3TZIqPBiroxPpGoVyIDgg5FG/uU24wh8c8KX8kXQ?= =?us-ascii?Q?YyQstNPHMSm/kC+137Zgmi3OFbMivKpFAOGpThepdqrPAW09p1WoF1Wcl8zV?= =?us-ascii?Q?KqojD6eAERKGNHWI0m0aefi+x8zL2T2XfGEB0fTrWtcTuDgecAhJv89HoaLg?= =?us-ascii?Q?sD/VPjXFosk4acnLdYX/Ab0CfJPUnIYnRUzsZyDy3t8La2rhjUMBnINKRoOP?= =?us-ascii?Q?2k3cTt9PW4qhS1o1IIZB0Fgaus7iNbe25EW+CWIYkWcXYDTHaf6DoZKLOxTB?= =?us-ascii?Q?2v6puKYg=3D=3D?= X-Forefront-PRVS: 0359162B6D X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(39860400002)(39840400002)(39400400002)(39850400002)(39410400002)(39450400003)(51444003)(377454003)(24454002)(83716003)(478600001)(2906002)(69556001)(3846002)(6116002)(110136004)(84326002)(50986999)(561944003)(4326008)(33656002)(25786009)(6306002)(966005)(6486002)(86362001)(57306001)(66066001)(189998001)(6246003)(76176999)(38730400002)(7736002)(236005)(81166006)(6506006)(36756003)(42186005)(50226002)(82746002)(53416004)(53936002)(8676002)(6512007)(6666003)(93886004)(229853002)(53546010)(230783001)(5660300001)(2950100002)(6916009)(606006)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR05MB2509; H:askhan-sslvpn-nc.jnpr.net; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR05MB2509; 23:ZCmafffO5OSfsPNth3ydv4pGB5LxmU++HNlQ+lUsP?= =?us-ascii?Q?fYtCTjH0BY8fz1CgsGVaxIT6GyjqaE07gbPK5T6inrQtxnB1TB8qkKJzU/Kn?= =?us-ascii?Q?SwdODgARwa3ONd5tu3vGhlxV7FQOVyB9bgURsehG3VP4arNLqf8AYrwwYCSK?= =?us-ascii?Q?Sa8xcJ6jxdS0Z7yXrZXpQn9kx4R1VGzif4V3ywWxyZIU4CUDL2o76A0J0m5e?= =?us-ascii?Q?+XpFJelXUEv8b9x81fmxXUx4Pcil4cKJFOblUdwUs4+yv04QA8aZhZZFUNla?= =?us-ascii?Q?4X2KkJv3IWswsAiszp2fojzNOOjzwvbpxZh75hK1XUVWrH41jYxo0L4s4mK7?= =?us-ascii?Q?XS85GheeK63E/Xp3l6oJ4FquOuqz0P901bp7ZaGglpEkJP6Yk/CwlQZXS/cY?= =?us-ascii?Q?oMQxzsWbqHXTcfUehBNORNUPsPMuk0BkuDIaeauE3S9u2cZBsIKCfLz31qrX?= =?us-ascii?Q?OSMnZ9YKleeOM02c1GIlMAIXC6QHeEPsYjmwAm9Z6bdKCEdkYzvyJS1UY5IT?= =?us-ascii?Q?qmgMQ7pzqiwPCfGIkht+2WiDFDjPhuZF691ep8MjjVEshNLwH0Ez7l8EaRnc?= =?us-ascii?Q?i7YXF6WghTDTWPpMBFRY2Jh3q3KVsezEXQA0h4JqpEtYnScyAWnMmp+1663/?= =?us-ascii?Q?pYAYzXTyOZn45jBn6/w38ljlUsYbq+1j8jM5L767tX5frcmwB8XW3Rw9SqSy?= =?us-ascii?Q?qWahFTU4gu6Duer4lQimtdWnYpplJ2t95YjnFu8LqTVNG65/CNhHxd3I8GwS?= =?us-ascii?Q?BBsO2zKZmR88u/CB/4ifHS2EeYOACRgLkQp0LvotbkZyZuPk78lkDCh3Xtqt?= =?us-ascii?Q?om0BVqvJ60MYaayNWzU3DQoP2yZVtqpyUqX0sEFhAzFh5ieyBzQIwxZp/xRM?= =?us-ascii?Q?n4f6e9WJLwqswWoyp21EMZYZM0xFZV+ZCYRh/e2U2VmWdailfQyR8vzXsiXW?= =?us-ascii?Q?M4u++NKuSWKXDjlWAwXxxjQIgDslcEYVIYrzCK4Zy1uQSPZ2dM0/rjbZQh2C?= =?us-ascii?Q?b187l4JZkBvP6/OMAbklybN1yaoUAan4Ud0UZz4OR4dQJJd7wnr4nKGkTEwM?= =?us-ascii?Q?fSfdzVAgf7IBfxLj5+6nsOCHKrR/CLq75YbNlAznFBHpILFJfS9PNefzjRRz?= =?us-ascii?Q?2+yFji5e7EkpR8iTi+sLPVcitzxfRkSri0pskSjHMZnYpXSv3lx86Gq5tvb5?= =?us-ascii?Q?mFXlMK6QJN5uD++7pEE4Arc/9fhhqduWI4ygS9/kF4Upqj2CEIJnRJlvzTSb?= =?us-ascii?Q?Kmo0+AQwkm1ei7f9gfmt0dZvVY5aVt8FtSPXHuA7WvroC89uSTcrf6bJcNIY?= =?us-ascii?Q?Jp0c+VaZJbmCid+d7hpJS+Gqume5Q9m4/5A/xDHhynB?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR05MB2509; 6:+ez8K5thtUt31HW5BR9WSkyBj/c4/clz/PTDHhV96h?= =?us-ascii?Q?wPWxj0U7vV69IZxNMj1wWZNIrPK/DWvaFxQ9VN1JQvHm+ztUHbwXgyYc6F6w?= =?us-ascii?Q?qRBLDBV8aBlD/hSiNlDbup8KxohIEVr0DGjAM+5yjQo9Vc2sgwSG6FvQX8PJ?= =?us-ascii?Q?eQ/O7+WSy5/US0Lh3eiQPmooBQtC4KrDjltDWl9dX8bEzJmmEqWoLfuh2Eg2?= =?us-ascii?Q?6PcnNZumHW87pSoxEdvfDuDAtxhYdz3n9P4wodg7RVUeRPa2JSEuZGncwTNo?= =?us-ascii?Q?OjiXz+2LE+WNvGgRP7xYHwV9GHtg9pWLpn5U3Kt+GjQwEwTf1R2OtOGKPK5O?= =?us-ascii?Q?fDwXzCr10bRTOAd7NXYbSQblWWNqWBBIKqR0CaonC/ok+iGKTbZWFn5tBn6l?= =?us-ascii?Q?U6YDwvaWxh8lAP0vpRiC1VARKZaaFrw9w+LsiB83ba/9xsMXfAiOZOTwiLKn?= =?us-ascii?Q?Q5081Z2gSdcIuPTqnq3mIbOBzPxhZZNEoWiMfQlodhB74D3g4o2YurTRvfOT?= =?us-ascii?Q?rT2xjFlPf0RtO7f1JZ3z3Wuhb3zBySN3vtQIWR4EFsHbpV382TqOwXKrVZzb?= =?us-ascii?Q?rWn3JeOg4l7zgCqXwE+Gr0jjlSLzr4miph2dEQ9Faku2kutx8EkKv0AK0gZ0?= =?us-ascii?Q?T+jd43rhLy3kCPwQdCiXR+eAPp9pLAF2yjQC2gCym1pBSwemY+fD7GqBdwp9?= =?us-ascii?Q?zhY5bCsjHWLLYG3VL7sjw92THo+CEGBfNELwyrDXLsoqWi9S+mDZchPLAXMB?= =?us-ascii?Q?Y4Y0p2eCVmZPwxLDQT91aFBUijIhvt13bftTCYd3KOSHZP88gIcDUv6G+SY1?= =?us-ascii?Q?emxRB3MZ7yDXFovLJgx+eUabh8MhXkf8kuy0XXzNakGQJFCAr9QFbOJUU3do?= =?us-ascii?Q?JdsQl7dRhyRtYsZdvfqXsT76qqlZqbs+S17iZJfjXyoqehpmNZEcG20SaL4n?= =?us-ascii?Q?6joN2jdjIAUsULcYbW/9FN0tRjqCq8Za2UltM0SQawZphBWS3wyAxeZYoKLm?= =?us-ascii?Q?mcYba7OHWALQWCvHWBFNK2?= X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 5:d3wPo7Kc63OwFdU7Xvc8WP2sK19X3FOCdFcI/4a/zfZe5apDRQm2rkq7PHg8NTmiX8BXZulRbkGPiSPvt11q04RnIXZYQ6eKi1Reph/BTVwvAb3v9PaL0m5rdZxUjBHYKaKrXXMcRxYNXmSSUJ3wLBY0oD+qghWwp7os3NO0whCZkvYnLrRhnHSZZxXIBOv9BpZrsbIm37Y9I+ap6EZVaGRphQAUK+KF3xc2eP/ytds1QCHIrZpCAUFBRrq3B/mXAeIKe3q3LP6z2YZTcv8CZYNUZeywfaAV6D6Lkk92i43Xl8tiZdO5zRwNS1EDpM+px0lTS94K8guH0LAxSoHDcH+8Zl6VURJWQKye6aFkJM5PTnhmUOLJ64J8OaU2pefNufOaAO6ZkTAt173VLKpE9Czv3jaTq85UvucK+/rTOrSQIYBIx9kuK4PplchoG0Uk4PjQNmwHREPrNsWnCTx+MVdFprPFzSfhx/SUJvKfMG+ShbNU4ucsoJcbbIAJiP2g; 24:POV4qifqAs/dQugHjpfsuEDxp85GJoA9bPiZP8RBZO1UTiEVpN43fN/sgayDEI+f5sbIgD7HFkwxpHocTgcPKKU9/McZ7UtATiC4P86JoTc= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 7:QGHuQZwZ9JQpwD9bRYU/tqq1bUSKbsBRDWJ+9gd7oF0+6XaxPz47DDtYIyK5SMdmz9cVXSrMagXB89frsw4XJFGQorAdnNqCN0zKp2YHKHaGmYb5n4dmY307X/5km64R/qtAnhKY1mlh20T+4F/xNHLQ/xZ3BvnU/jEKJtIFmSFtF/4w7JJ2MnXz6KMIackMbVwnVw6TbkMeDCSOjnMSnvEyBCztDhpf33cxGOioyPXmPyfS75frxIT1kOPHQ8qzif5v5l/b4myQmurrsozhcBup22o9bXaksb34iLBLM5ct5NYfTty9m3pBuUi1KDWziSZ5Qe01YiWzzd677ITp+c6CpppWRSIaPZg5xGOIzM0UFVha+KwXq422NKx8ICii5+BXI5yf3Bnm1iMxwz+NBJCcAyz9BibrGpP/sfM54oD34zvthkdjS2wYlqQoMywgnKN1YoJugXB8leU39rqoRd9WmcQb6ZOnYIUiqxCbAVHMcxFngyG27MU1ciL2fOON8KMTZs2MNwUqQgMVZgDTb7lcyep6DURIBetdvI1OY2Ii8aB67+YPtIJn0j+Jb3UvwDBh3KrBGz8KwoH6nsGlwYuLk5OMzNHlTZpjDJdQlI7HMvorLNyNBF7HSfkRBvaPbu3XZjHqAzO1D/BuGZLsnAW0rMttOhHKk2nDdQ7mRGzY8/7P9O4pGOpnEt8aE2VL5JA4YoESbkoMO+fbvycr53W22mKuF4Olb+jPSSNPXo3Tr9UqpgL5bRzGOa2zQuJelK4q9x1ExnJGTHIxqDQrVTGaghdMsVwagPfLRbJkvUQ= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jul 2017 16:43:53.4919 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR05MB2509 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 16:43:57 -0000 --Apple-Mail=_04D74F30-F904-4AD5-BFD6-BCB08611E1F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 5, 2017, at 11:05 AM, Robert Raszuk wrote: >=20 > Hi John, >=20 > You are describing the situation where client notices next hop down, = notifies RS but does not get new path till other clients also report the = same next hop as down. >=20 > Is this really a good idea ? If the RS does implement per-client selection, then it gets a new path = right away, but concerns have been raised about the computational and = storage costs of per-client. The baseline RS as currently deployed will = obviously not provide a new path to the client nor will it even know = about the client's connectivity issue. I have merely pointed out that = there is a middle ground available. Whether it's "really a good idea" or = not is for the implementor and operator of the RS to say (and the WG = too, I suppose, if we wanted to bake the idea into the draft, though I = think that is not necessary). > Note that due to selective policy only very few clients may get given = path so your heuristic would now also need to account for static or = dynamic (signalled with communities) policies. What I described was per next hop, not per route, so I don't think your = critique applies.=20 > Well I have nothing against machine learning or AI, but do we really = need it here on RSes ? This is a straw man of course. --John >=20 > Thx > R. >=20 > On Jul 4, 2017 17:55, "John G. Scudder" > wrote: > One observation regarding the "RR won't scale if it has to do = per-client route selection" concern -- it seems to me it would be = entirely feasible for an implementation to associate some = figure-of-merit with each next hop, a function of its reported = reachability by each of its indirect peers. That figure-of-merit could = be used during traditional (not per-client) route selection. The general = idea would be "if one other client can't reach you, that's their = problem, if dozens of other clients can't reach you, maybe we should = choose a different next hop if we've got one" [*]. Think of it as making = the binary resolvability condition of RFC 4271 9.1.2.1 fuzzy. >=20 > I think specifying the function would be beyond the scope of this (or = really, any) draft since it's "just policy". But it demonstrates there's = some potential benefit from the proposal without going all the way down = to per-client route selection. >=20 > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr = --Apple-Mail=_04D74F30-F904-4AD5-BFD6-BCB08611E1F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Jul 5, 2017, at 11:05 AM, Robert Raszuk <robert@raszuk.net> = wrote:

Hi John,

You are = describing the situation where client notices next hop down, notifies RS = but does not get new path till other clients also report the same next = hop as down.

Is this really a good idea = ?

If the RS = does implement per-client selection, then it gets a new path right away, = but concerns have been raised about the computational and storage costs = of per-client. The baseline RS as currently deployed will obviously not = provide a new path to the client nor will it even know about the = client's connectivity issue. I have merely pointed out that there is a = middle ground available. Whether it's "really a good idea" or not is for = the implementor and operator of the RS to say (and the WG too, I = suppose, if we wanted to bake the idea into the draft, though I think = that is not necessary).

Note that due to selective policy only very few clients may = get given path so your heuristic would now also need to account for = static or dynamic (signalled with communities) = policies.

What I described was per next hop, not per route, = so I don't think your critique applies. 

Well I have nothing = against machine learning or AI, but do we really need it here on RSes = ?

This is a = straw man of course.

--John


Thx
R.

On Jul = 4, 2017 17:55, "John G. Scudder" <jgs@juniper.net> wrote:
One observation = regarding the "RR won't scale if it has to do per-client route = selection" concern -- it seems to me it would be entirely feasible for = an implementation to associate some figure-of-merit with each next hop, = a function of its reported reachability by each of its indirect peers. = That figure-of-merit could be used during traditional (not per-client) = route selection. The general idea would be "if one other client can't = reach you, that's their problem, if dozens of other clients can't reach = you, maybe we should choose a different next hop if we've got one" [*]. = Think of it as making the binary resolvability condition of RFC 4271 = 9.1.2.1 fuzzy.

I think specifying the function would be beyond the scope of this (or = really, any) draft since it's "just policy". But it demonstrates there's = some potential benefit from the proposal without going all the way down = to per-client route selection.

--John
_______________________________________________
Idr mailing list
Idr@ietf.org
= https://www.ietf.org/mailman/listinfo/idr

= --Apple-Mail=_04D74F30-F904-4AD5-BFD6-BCB08611E1F9-- From nobody Wed Jul 5 09:47:35 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0AE112EC06 for ; Wed, 5 Jul 2017 09:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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=juniper.net 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 rhWOdazd0vzU for ; Wed, 5 Jul 2017 09:47:31 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0139.outbound.protection.outlook.com [104.47.36.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A78A12EB8C for ; Wed, 5 Jul 2017 09:47:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=TJ0wdS0KV3UaF28Td93CmEi8jiry9HHEPMBn9TCEZSI=; b=NGTwydOTBnGZKOSNsxe+mcCHZaI8l9ulaGG+SjxX8uT3d/rioaHiEqsyMf5XXLaR3sR5RYcZQELj3HimjOO7t2j5vJrnTtgboG6+/TxDJOB+3VRG+Bt8wnculTiEYskJkQcslrCuA+JTqiBPSTvPFlN6eT4iJpxYskCRjBO1Dk0= Authentication-Results: ntt.net; dkim=none (message not signed) header.d=none;ntt.net; dmarc=none action=none header.from=juniper.net; Received: from askhan-sslvpn-nc.jnpr.net (66.129.241.13) by CO2PR05MB2503.namprd05.prod.outlook.com (10.166.95.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.6; Wed, 5 Jul 2017 16:47:29 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: <20170704191312.nkkjeylhrpx5qcgz@Vurt.local> Date: Wed, 5 Jul 2017 12:47:28 -0400 Cc: Jeffrey Haas , idr@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> <09BFF794-6899-4DA5-8EF5-DDF86513BFBA@pfrc.org> <20170704104840.mg5bflnmmjlv4jbi@Vurt.local> <20170704175334.GO2289@pfrc.org> <20170704181454.la5hw3nyisneefff@Vurt.local> <79BF9BD8-5589-48E4-A2ED-478E9BD9E989@pfrc.org> <20170704191312.nkkjeylhrpx5qcgz@Vurt.local> To: Job Snijders X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: BN6PR10CA0039.namprd10.prod.outlook.com (10.175.102.153) To CO2PR05MB2503.namprd05.prod.outlook.com (10.166.95.149) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 56cceb00-5cdd-4322-b6b4-08d4c3c5867b X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(48565401081)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CO2PR05MB2503; X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2503; 3:oD8aY/XCfFavU2x9U8r5JJi3NbptT+ec72AXvybMMNpePT3voKrNrYpNxfyaxO+3DG+nUHdiEYn466F9iT21gMP7LcoE34tWDYQpl1afDve4tJu4rLZRWtkZPbnULqL5ygDmahknlBr4e3QNWntXR2eEju64MXTNIp9nkqotetF7k/Ft1xnPq68nmD0PmO7GTvHmGsDFjY4yWnDoJvctCOln3XKHRA8CsEtWVKwD6I208TAfb1cQhI24Y+44ujWpeFv9WnGV9hYFIh85s4ECcYss2jZukK/mWGNQ9MNJQbVUr7aFhR03bksjF8aoYOgdfVuDFyR7eWIwVMbZNWitAGlHiYhcolOp9P+ct9v9B1PoyKro8ks8JJl7F5VZ7faCio01kogTLDWHApdbMxrh5KdvaNgX+YLbTgvuFyyaKWOsLc2uzlFyfxLKze6z+hRaIPKoGpvRlDbvvZUzROPa8V8TnT88t+pgd3rrIz7MUraZmVpZxf6oACNtC/0rTREmCSY7bemflJITVtI+Ozy2ph0JQS7gyGMvSzUg0uU+SE2X0Q0zg4XyDSzpyxbak9fzYbzEhgaUbE4y5T8C8mia0nyqDKIS+U1jP+Vlsi95eUz9imIeT+hsXI3IFqZ9mlIFXaTpsXxbg1cfa/BKQrIKDEXVrgOz7XIzlGTWlDNjMyS6ozDaOW2KFVsAC26qeNLqDyKv/LgXDMfPp7ZuDVLH3pGNa0SJLIQcvGJhOdhS4z5QvVnroVvOXaW5lSnhLs/jLn7yQPag4CBUX3X5VseRtQ== X-MS-TrafficTypeDiagnostic: CO2PR05MB2503: X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2503; 25:17R++1MLyarH0xbIB58CbL2GQ8O06WwNfRLMUkCez+UIZMi+IbTgE8JIzNegHuK6TYv7nuLXiQRh5GZqaDvnmfjd0kQIYGi7RIQM3fOdd26ekkMLlsjVrP2TeoxskEOPbnErPNtDMM/9KjUlbXrUPJCpatxhLn/iQaZUY701y64Aro3s3g9sOpyTehYHkfa8iFIGbHTGB7CyiHALJShU+hX2SmjkqTGNKnBSaAMpYKBdGsmIZOscXhQ/hFNKOgF0Xp6PH5E4K4rDSgW86xmtkQhdphNFi8Q/pdBtPsEbkHj7w7+eoM476rrncW6m0KL+KpFNn2VAygFno2yZsPbMAOEl9ThTe2h5rPdio7rT36CqwW81ncCs+HUZ6O+PQSLsX5wozdehx4KuqGbdGL/Gp/hJrEuKxhq41Yn6PsS3Q/GrG4Fhl7XQukZPyzb4E4gZjjQa5mbybu9nAx3xNcAxlW6v1baQcj5uoyIXktf+mNvu7nbpqUG4mlz4V/UriGWrNGUarRp7x90wFaAMmx1cIbt9SPHh8vbs12YT9qhmvA5ey3u1e027A4lUeIW4tfFMKb6mLURXDeJtl5jSHB+ZTm9KWFnOfWMaew0UMeReg1484KJ8knxvuOadxT/bcucByZxPdbst2h+C9hOrsTItEhRDgbYDlXkldElMJKJAn31vuVppjTaYYgziTjOBN/edo0VtbXUDRJNvA+m323q11JherYwcOTT5XMW/td533N8HZMzd/IFxbbwtgOcC9hAg7aiFRIPEyp0tCHp0mGeDMAuV4l3VhrTFWHPz7cUjVf4y0SQbEhGWL+5gHmE15cDYuAtxpKY514F3avzEewRL1AxbEm0zrSQA85lXBN210SqVVppgNP9YGYF+rNiEuf6uRbREfjZboS8RPnEMwcaOtFqnrms5MyuWAfJb94B7A0A= X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2503; 31:qwiQD9xtuBMbxxUYu05HtGohiOkv5kGfVtYWFrVwPE+hG/1bDP2kJ+Wg+kKiOzPgjMi6h1rVCTvt8jmqTMWR9zmpANV6SEz+SY+iCVEyFCc8eeSMhZraWWOQHxmIyN//tiL8huyYuWx9Xws4elPlYnbowfRrb8JjRUQ/tWs1OhJJFlgy2MXwPgejiIfs24RuStiMF2XDsW3FklQXYwRR04v9325CrVqONPYbAC0Kg4VjHKObvsb1hQGgHZvtTn/mPQWa6ZAKwuZ+MASazItjBcoOndFw5da2/15UYJ/WcShPuo9cQj83qa6s5kc0fiA8yYdi/01N9KEFXaMJv51xJJUy6gS9egOC3voSvAOJPSK8XD2xQGcGIcg/2s7/v6KWBr9Uf4tZvXlIngvBphb1jWihBhgmreyAJw7Lz9351zNz7Ahm/6anUIFxjADucHkgjUXZzv3Kfh0op8M6Kq/M8C6WQTj3AJwfZ5RyxdlGxYUTKPlBahjPjPAMTFva514w2dWp3wT/1q9/QT/H04r2ljEQGgIUNqff0nSZJgr78AGazIVPbhfH4vBEBoIE/oGjvBlcZO5sgZ3Z5TTD21dLthjq9Di36/zjtHzOi2v7tVRqCBRe1QvFwOsM7EI7hvtdVbbUQYNKHfmMX8UkNK4S2aeGJwjtC8m308f36t1p0yfL0g+dKHWDCmdQxQIPajmAvItLgnSQ7WXun7pr6ggY/g== X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2503; 20:+8AYNUk45a+2EFZHa2sZeLmEPTClEL31IIt7o4w3dBst/yV8bP5ZR5X73ZoL7Rc0VRybxPvCwArOQgPlbfBO30iOnV3RjJ78gZUjQsLc3A8Ot6PvPBo0ubVLdBTWhTn2kC9ANOiu3WUoHjJXzwRtUpGGGeN2kyEOz7bGSAclryzKgceGKYOzf5u3dQWvK/VKz+GGDyES+/22JDoaDGRrcbr42TBKqxmIJWEgQrz2oZjqVQewmIwJlZaCRtjOgebabv+jahJzU8FAvbPA88k9Zf/IVDODU1qPHGJ1WCb7VBcLvIWX4/EIwxJ2Mh8Z1WByaobS9p4NKBn4B2ns2/ljxDL7JnYlmxpeJ7oyLEGZDFdNKDIMMc0y9E5a84L/bqX5oi40xT+Ud+m/U3JcmCBYVoZdmmRq5bhsH9YIzZ5OwrEiD1Jfs3vVq52pg+3HCzjQ+y9tI4Xr2TpefAQC3Cb6kBoers8na0MKx1iJGGrVguN8GlBkSlypZNaXdpBiHiQ7mXpMZZ8BcRpgpAqQ05N4SGfRfYDiOeYECsajxzk7omwv/CCpPJkLSTskXyOtdiHor2SDCq02KGI5lAQG4RFso8eXJCoK3xGpCdu3HJQEGkE= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278178393323532)(236129657087228); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CO2PR05MB2503; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CO2PR05MB2503; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO2PR05MB2503; 4:EiFSjIP/+PRbawLgtkfVEg7RHZsSTwKFbVljjymEEw?= =?us-ascii?Q?qSaTH8YwwMEVA/4m/gKRHOYZA8+0NkXOzWBDU4PfBbgDOB1063LjeMU0H5Jj?= =?us-ascii?Q?cgznA9UF6NPaDOfMRNYTosQSzMU9kXYvTJENq5RQhSR/LbIof8rzZkfu4Y6Y?= =?us-ascii?Q?bJxOc4BmXXUxVEbwcjOCvv8fwj9nfRP3f/skMiWTIFvgeNWhFWTeucESJLuC?= =?us-ascii?Q?CHZjEkLWpI7IG8qjn52h+IWjUZnvkPMr3iTBlM9/UCaHhxb0t3sUKci7WWeX?= =?us-ascii?Q?65p/5pCIXqEuAXcE9VjLT4Pp2k/yKLcyoEykI+BRgYc6WLfoi34bNa8mNrYM?= =?us-ascii?Q?VWYdEA24bFWyORQvyHWAJT+lXpCIB/1WKrWcx5rLjOBro/UNxF6nQLnCke6t?= =?us-ascii?Q?g2YYzKLlxDg6fPCMAzz3nM5XYquxDabZF+wepL9gJMtgOUvMjTjNJvpVgAc+?= =?us-ascii?Q?MXDIgDFFi+cNShXPWexboc8VvTywo6q9GFxDsSurirCRsoTdt8ChPc1svO/+?= =?us-ascii?Q?q8Hm1ep504mNDgWD00EJ6TnzRkWUp+dAty/ahR2GsR0wJMqhQyOwI/0mLcDj?= =?us-ascii?Q?Lssa47SffkdViEaWDhVK/x0p7vgVDucTU2eFihKjkDs4EhcWugX/7i/wf/dA?= =?us-ascii?Q?ydpcdAjz21y0xMAOI+jnrgg+v5S5j0GikiPfUZDCS/IHoren1rvn1aAkONH/?= =?us-ascii?Q?zuPAmyC2H7ZFmN3h0Sqz7cILhbJ1/8pB8qhcQX1qbAJKBDkBj4mqIjFHsHn2?= =?us-ascii?Q?gX8vnu7NWxt8HJgiGjCuKKuFToarfSapX2JsCH+4v0DjJ+/t5/wuA/nd9CsP?= =?us-ascii?Q?ZYxMUn+xZfbOtADtB/LJ4zE6kKofskMNX67fyDaNMk0/1G5KGr5Oez5biQcb?= =?us-ascii?Q?xvbKwbrucNvAYWBCUa0QlZlAwUV6Md37m0Kr/Q5GSXmdYMUcLgb07D+3HY70?= =?us-ascii?Q?YJmULK8SctU7m1eD7IjgzwZ6zMpMVhw6D+aFYpIgHoZHG2b34v1knOMLqGfG?= =?us-ascii?Q?+7xj+oLSUAp6NTiM3VAkAq5HuRVAFyLPe5dey+kZR93bs7TK0BnZlxOWhte3?= =?us-ascii?Q?KCpoy2lqQvvz8rKr9qnrKL7gq4l8NsgWarK42YuHj36JXnbLcUlO/mgomQgl?= =?us-ascii?Q?X59n87Lzd8ST6sndpWaye/nXpRkE3vSmAuwg014TZd1R9CT/ID5ymRtNOqvL?= =?us-ascii?Q?MzZdnlj4hGjwwVTyk63nCVr9LYP2thnV0oYN3sV2o2V19mY/+LoU7NTzqEtn?= =?us-ascii?Q?oxiEHOnrPOY58QxBA=3D?= X-Forefront-PRVS: 0359162B6D X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(39840400002)(39450400003)(39400400002)(39860400002)(39850400002)(39410400002)(377454003)(24454002)(3846002)(23726003)(478600001)(6116002)(50466002)(53936002)(83716003)(47776003)(6916009)(2906002)(25786009)(82746002)(2950100002)(5660300001)(53546010)(36756003)(66066001)(33656002)(8676002)(8746002)(38730400002)(53416004)(6506006)(81166006)(6246003)(42186005)(110136004)(6486002)(229853002)(189998001)(76176999)(50986999)(93886004)(57306001)(86362001)(50226002)(7736002)(305945005)(4326008)(6512007)(230783001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2503; H:askhan-sslvpn-nc.jnpr.net; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO2PR05MB2503; 23:zmVOj3KFLWKo3Hile89MbICM5NF7Rd7imEDDHNBe6?= =?us-ascii?Q?1hyW2so7sImjEKdKM6oLRaPwtYJnVFuuXBNDQLYBsdVW+Vk/uktdsDNASB4f?= =?us-ascii?Q?MwLfPk5hSw7YqLUX5w6OTLhEgUQI7B4trBt8HiQ0pZ2r4UQNjFrZPMQLlOVP?= =?us-ascii?Q?I8C9jMR8R3v2n3C6StJs7AVHYhn+bTNWw069l6mNoGjhmBIOhgXaGInelVk2?= =?us-ascii?Q?GwaB+JUQfeKbUPmXRkpMALuxrGgG4llbruhbIwIEX9CvU3zlwVtOrYzhQg02?= =?us-ascii?Q?02lRz52MzSwdRnQJaUuumGpmYQURMnzQ4FBM3LrdlMy11mueDMgMwAHNxzcd?= =?us-ascii?Q?QD9+kOjSn+OQINwCBDBhvBWrb1X4btU+/SFm50ZV/MKpu/7X/4VZ6Re7Tbc1?= =?us-ascii?Q?sb0gSEAFLdmO/2RyBKRKyKb11xLPAhuAfxmijPy+093GjP/zKWzIdwFhHI3E?= =?us-ascii?Q?AnfbY83qvz+jz3115m9tmAMAOiAeHDnqt/V32RTe+7Msny4X+2p6H1r37gD4?= =?us-ascii?Q?GOQ4o06099XgXQIreFpwy3FG3B6V8LSixchhykhTsFqK2/hJLawzjsf17IZ8?= =?us-ascii?Q?c4spPdE2/nXrPFRaF4gOGXdwmd6F0jTsbau+rrRiFQeLu4+xE5sivubyqX6S?= =?us-ascii?Q?s/6eJv3QVae45jszKNRh+muG4PkR4Edlq+eZ2FaxbV07ov1P4VCGAYTEfpbP?= =?us-ascii?Q?77Ny4boLqHKo1pmv3X/7pBoVXsuD0s5oMVxotnihcAg939xHj4dYtncJH/gm?= =?us-ascii?Q?JbJcbNLfs6JMZLZurLOmSWVOES7MWrHMv9qPY3k3RJXA1UbPsU0OwwNT9T7c?= =?us-ascii?Q?FAS2v0BqoIhHAHwuLE0nciCV2B+DgRqGTrG4ZfMPfahDz/SG4rE69KIWlla6?= =?us-ascii?Q?J10IjkFcYF0qaatDIrofwpyzv4asl8Rp3JBx5BKxCPd9Vv5pKgxGV8EtNnLQ?= =?us-ascii?Q?P5PTzqq2n8xuuAcSe3sY8ty5bwSYrxM6Xq7av8/0pFDGMSIfGXynvbCFAby0?= =?us-ascii?Q?RAC1aluztOpGVGRJtN/w7tiiSfkUYQBnoZqQiiuq5OdNMbcVtouBLEh0tBqh?= =?us-ascii?Q?IM6jy8FJFZT29T2mwl4NYEpulzHhOwVx/FTYASiPg6tPxqOoK2Dm4Rz+iIHy?= =?us-ascii?Q?skcng/nUhaPMoCoSRPwTf1wUrfYNuQPCtaZi4zI61srSmFiMnmZURnRXe2+z?= =?us-ascii?Q?sP5/AJn1vwu149W6gOumzKW6yEdXVhb01HyFBka3Gbvnqe5iV54Y3Q/r5qL+?= =?us-ascii?Q?yMqEvQ3Xm1mS6bqvGa6LvORmUzG667fbLNrS+iW?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO2PR05MB2503; 6:oMDPPJ3DDbQo0zBECN151xBr960Ddn5z3iqcGnkNb/?= =?us-ascii?Q?clkRUSKml9jdlaU/63fAVGif8UqXzrUYyifr05M8IH4Pup+lCW4b6ls0SwsR?= =?us-ascii?Q?MKd/5L1wv1KEn6UlfHglj9Y9z2D+eYycqzMS2Kjuhr8lXSlg9soYAWa4TjYg?= =?us-ascii?Q?NosqA9IhYftd2FpZ/tqNQC/Wp/HNW4EpZKZUNBQVebTURtAn5s/kB5suTXDK?= =?us-ascii?Q?1I5kCgXzbgNVAbIMVFfWycu0uvLVPn3sBaUK3G3SK8uYdfUNPn3Ic/UaFGVG?= =?us-ascii?Q?+1oG5A6mqR1tl1IwjedJW7xCgoPxXFd+cgleSxaJpZzfbJkQ1jt39I+IliMl?= =?us-ascii?Q?qHRVpeln8nuYgmgkPbLGU9mAILbp3OQzmV1mhThEF/wAQMDF/QeXRsqqz9ns?= =?us-ascii?Q?saknixXrzF3vP3l4tUWAMVdeyISgr1a2/5HhkXKLrgP8ijnM4dT0dzlNYYQc?= =?us-ascii?Q?2DZsiNsi/LHHlkv4uNP0Q465+D8FXR4XBJazD28W8vTip1O6AYwWqXJUqNtP?= =?us-ascii?Q?omYlU1Efmcy7It4IHHqJDswJRWstf9ZRYgyR6kRA4InAIZRYGh0c0Q+RwZMt?= =?us-ascii?Q?MTGEtHYh+NWDQecu6MOJ0TRqpd7qKYr1Kbh8EuaBp+gV1VM2EJVYJUWA9jmc?= =?us-ascii?Q?y0yt1esZX9rtjXt3YVd5jsDxtsq2OX59qOnIATmaggrDK76lO35OqEwCcuOm?= =?us-ascii?Q?YTyUJFpbgJqJtEz4SDqbm8NuscVsuRwrQWYjuyg+JY1xB6rVe8ZzCWYweRz5?= =?us-ascii?Q?gYgpdBag5arcfLs9ShiZgEBtl43kKb6iaI1bJWeUVkxkqqwnvgZ4axZpS8J3?= =?us-ascii?Q?ZaXTiMLgBtiMBa3xf7olQOPciY5Sdty3KfcVWr6z2ey7x+8YM3/Dka2Tk9ti?= =?us-ascii?Q?zKmslvp1kPD1HXqwMNZFXMxK8t8Nxmm6pW5drMN7FyyOZJhGWohQjoy1uMwA?= =?us-ascii?Q?es+k37u03IHfpk9GrokIbQqgqdRpw0KNdYJUQnqcF+Dla26ksW+zVQSe5kxX?= =?us-ascii?Q?zpbRccNOCtnz2p939scFU+?= X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2503; 5:aNvxQQLthvGBVtiyUQkYDzZFV1gOCbE3pv6p3UbbV6yX9TmGIADuEXXiXKdI6TsmdygQ1zNjG8wCTqxL+/TcmOS3Ot4dg9p8hUCg+J8XIzx0jt9Hzyoja7a5fRRxtMpjbupvBPBNWB73iKMdBWyYsDytaQjeOsxFfVRsQwzTi05qJ6lilN2qIf+84jg3Bh1gag+/wgCrHuomORzSsXdxhpzVOocWFtTULVmRYI+TgssHqOm726K3D4qbOu67h9UeOzA6R7LF+0N/o+043bOSE4Nnvg2BRV2JfYHQpBSUqCtDjphRx1bCfiq8iJt36PgmEE8+wrEufh/JGQN0RB0fLBW3aetV+NVtlmOY1UiL3U3Y6JbdL/Onoz6iOCP2QsRmRenB4j45YvniDIv1r7HS5zih4TaZtyT2V4c4WNMjqG6qcLIdtxgvp1jB+23OjfhFgUcwbVL0I90oxOph/sEqmfEXgILDs09JR1aQ3kaHAQ1gZDa6eqmBHEUeZa1aPOpe; 24:wkxcxsNMGohChtV8PvALIgAWDVJqHMuy1sv7MOePLpK69KniYrt3n42hkZXB0dou5vRFM/z6ahuN7LzunLAw9B4Fp686JhFoNtGxt7OM7DQ= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2503; 7:bMUtP/jY/Oj3bckqyTIV3Jsmj1yAWwGTSlo2pI5vZ5f+1zgQqVw14/t+kRAFJPlq9zX/aN73YdRNHFJ+FJNxS+CGEgkuBZ1ItkkvTrsOtgR3PQ2T77wU4QziOKIbxcRU3ALRspiErmpZ+e19Q4GMrCtlt4cfZwpYs3P61LcHlUngovIguRhSswHmph1VWM6/gcdpnBBo26L2DOdHGFqgp1hvAhwpPAzEf0i4dt0Brk4Z0joolrGc0YCyqXnrD7VwxDeTLy8JGv0yOe9ES2zOhfx6GlDFB5xo+uCmvilokaPVfLVIMt56zeYDtp4t36rvc6KWV1g2dkFfpJhRfEGjT73Z1OQ0RTkFjK3m6xFzwzMKzBRhze+dPhB5nUKXkOHVkSa4E1ReG3ArihA6xRnOngkDOCEKn5TFJyBk/7J39BzT/wLFUSwNvoOe3wTfxQHvI1J0JW2xNj01hBT0sQmn00b7jimppJL1Arz6fgbSkXl+hCOBDOjGQsV3pebabt+/XjHsgRNYb/XsM4MZ6QW3e8CKWOL/0Lnyfr3teT3EzRB91ov3LQlf2Npj4EaT7iuw9Z81uLjbxTyD8BXpGau/WrXcOKnydvrW6azwVxNJPb/lIteD0CdM5UpJKlWPKHh4k1fFRGBP7pCEMifPEhM4t2YLlAKkWh4z9mcnFkVyyg/9dcAA2KKc4wsJK3MKFO7xsDJ4bMqnmQpDcFXssiAIwUF9nfm+KRzpzlyAPwx4nH1kUSLxvWEJojSgxD+HeXLQrNJObOGmbhclFOuESJN2BTSU7sv6cVp5/3foFILuq7M= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jul 2017 16:47:29.1485 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2503 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 16:47:33 -0000 On Jul 4, 2017, at 3:13 PM, Job Snijders wrote: > On Tue, Jul 04, 2017 at 02:36:10PM -0400, Jeffrey Haas wrote: >> My point here is that at no point does this document mandate the RS >> implement path selection mechanisms in response to the reported state >> from the clients. However, this shouldn't preclude implementations >> that desire to make use of such state. >>=20 >> Thus, I don't understand the proscriptive desires. >=20 > Interesting, my perception of the document was different. =46rom = section 4 > it is not clear to me that this behaviour is optional: I think it would be reasonable to fix that in -04. As Jeff pointed out, = I was pretty aggressive in cutting between -02 and -03. --John= From nobody Wed Jul 5 10:18:06 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79133131D55 for ; Wed, 5 Jul 2017 10:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 LisiAIyEtXjF for ; Wed, 5 Jul 2017 10:18:03 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38FCD129B3A for ; Wed, 5 Jul 2017 10:18:03 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id v202so117804266itb.0 for ; Wed, 05 Jul 2017 10:18:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=wCz7B/4Z+3IjIIpr69wX6NW1PZNzer+9IfTWHigw/sk=; b=OZ8j65+WUPfaQybPpNuRm+MFXzYbmFik8fsF8NHABmJB3sB1s2mHx63T1tcq1tOHK8 4oqmvNMKXfG7CGtBGGqyajltnlarP1Uf9MALmSNA1ENGRPj6bGfHSDXqcA1895P4rVIA Q7A0/5ufKGoa+gPLfe0O8gRqJfrOkMa2zj86scsP87uRGfHDIG7elO5tjVHV2FB1Rksy 1oKxRomRkzru8VwUIW3dVbIBnUBQib0RHMHfvwlGeRske9qYNx9Vnjm5zHp1NUWmi0QV JItFjFBXM4jUaKUb4xHmOfGpQOC1E5feBQ9h2GyMW05TdDxZcyG0jHzEQoDZln5CWc/B KJ8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=wCz7B/4Z+3IjIIpr69wX6NW1PZNzer+9IfTWHigw/sk=; b=tKfnBZ4K3a2LjC/P4b1obaVrNO3TfrljaJ+m29wSpdY4Vzmlr7LunHcwGXMxeQNzYt 1/+0sfJjS3Iri90IXCzX6wP+tXQthcQ6+vdwiHPTyL2AysPgHHsNEaPRqjsSbSk565/4 4ft3ycDliQjElkaOJbIq+7a+V5rjReOdHe5GAq8j/jGoWCK9BSFXdjhBEGEPeXJ3Wy5w RvAOiEOMiU1fllM9xJZwQIvFIbbYznMcq4eVnSIfbWBJcoRAkpy395t5s6fbqj1vV7XK dn2ZSyIxGCYER7ju7USpapnfxlnVjNpypUBHRvkxI4w9cNDwAGykGxoZyXINnrGtTSHD 91NA== X-Gm-Message-State: AKS2vOzWXVhMlkjrz6Af2UxuRC01TRyRYsYb/1LZJ9e6/PcblIUDYiwq kukGdbff9D9S5DOOFJxhjycLiTAcUw== X-Received: by 10.107.128.30 with SMTP id b30mr32352309iod.179.1499275082456; Wed, 05 Jul 2017 10:18:02 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.32.15 with HTTP; Wed, 5 Jul 2017 10:18:01 -0700 (PDT) Received: by 10.79.32.15 with HTTP; Wed, 5 Jul 2017 10:18:01 -0700 (PDT) In-Reply-To: <1FD8FAE9-E6BF-4C48-BCD6-12C1012827E2@juniper.net> References: <20170703175308.hembxkplaniz66wb@Vurt.local> <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> <09BFF794-6899-4DA5-8EF5-DDF86513BFBA@pfrc.org> <20170704104840.mg5bflnmmjlv4jbi@Vurt.local> <20C02BA3-5C13-46FB-AFE8-85D61E469EA1@juniper.net> <1FD8FAE9-E6BF-4C48-BCD6-12C1012827E2@juniper.net> From: Robert Raszuk Date: Wed, 5 Jul 2017 19:18:01 +0200 X-Google-Sender-Auth: OcVBzNzLw6OaldMnQR6BHMly2SA Message-ID: To: "John G. Scudder" Cc: idr wg Content-Type: multipart/alternative; boundary="001a113f8b12b5f1220553952eee" Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 17:18:05 -0000 --001a113f8b12b5f1220553952eee Content-Type: text/plain; charset="UTF-8" Hi, I think it does apply. Reason is that you can't (well shouldn't) delay to send a client a path with different next hop when previous next hop is down and you know (by learning per prefix policies) that no other client got such next hop. Of course implementation wise there can be per nh global counter incremented when you advertise given path to the client. Good luck troubleshooting those cases on RS ;). Cheers, R. Note that due to selective policy only very few clients may get given path so your heuristic would now also need to account for static or dynamic (signalled with communities) policies. What I described was per next hop, not per route, so I don't think your critique applies. Well I have nothing against machine learning or AI, but do we really need it here on RSes ? This is a straw man of course. --John Thx R. On Jul 4, 2017 17:55, "John G. Scudder" wrote: > One observation regarding the "RR won't scale if it has to do per-client > route selection" concern -- it seems to me it would be entirely feasible > for an implementation to associate some figure-of-merit with each next hop, > a function of its reported reachability by each of its indirect peers. That > figure-of-merit could be used during traditional (not per-client) route > selection. The general idea would be "if one other client can't reach you, > that's their problem, if dozens of other clients can't reach you, maybe we > should choose a different next hop if we've got one" [*]. Think of it as > making the binary resolvability condition of RFC 4271 9.1.2.1 fuzzy. > > I think specifying the function would be beyond the scope of this (or > really, any) draft since it's "just policy". But it demonstrates there's > some potential benefit from the proposal without going all the way down to > per-client route selection. > > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --001a113f8b12b5f1220553952eee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I think it does apply.

Reason is that you can't (well shouldn't) delay to send a client = a path with different next hop when previous next hop is down and you know = (by learning per prefix policies) that no other client got such next hop.

Of course implementation wise there can be per nh global= counter incremented when you advertise given path to the client.

Good luck troubleshooting those cases on RS ;).

Cheers,
R.




Note that due to selective pol= icy only very few clients may get given path so your heuristic would now al= so need to account for static or dynamic (signalled with communities) polic= ies.

What I describ= ed was per next hop, not per route, so I don't think your critique appl= ies.=C2=A0
<= /div>




Well I have nothing against machine learning or= AI, but do we really need it here on RSes ?
=

This is a straw man of course.

--John


Thx
R.
<= /div>

On Jul 4, 20= 17 17:55, "John G. Scudder" <jgs@juniper.net> wrote:
=
One observation regarding the "RR won&#= 39;t scale if it has to do per-client route selection" concern -- it s= eems to me it would be entirely feasible for an implementation to associate= some figure-of-merit with each next hop, a function of its reported reacha= bility by each of its indirect peers. That figure-of-merit could be used du= ring traditional (not per-client) route selection. The general idea would b= e "if one other client can't reach you, that's their problem, = if dozens of other clients can't reach you, maybe we should choose a di= fferent next hop if we've got one" [*]. Think of it as making the = binary resolvability condition of RFC 4271 9.1.2.1 fuzzy.

I think specifying the function would be beyond the scope of this (or reall= y, any) draft since it's "just policy". But it demonstrates t= here's some potential benefit from the proposal without going all the w= ay down to per-client route selection.

--John
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr


--001a113f8b12b5f1220553952eee-- From nobody Wed Jul 5 10:53:05 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40271131552 for ; Wed, 5 Jul 2017 10:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 NfVtpTIP41Md for ; Wed, 5 Jul 2017 10:53:02 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 16841131555 for ; Wed, 5 Jul 2017 10:53:02 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 592CC1E34A; Wed, 5 Jul 2017 14:02:12 -0400 (EDT) Date: Wed, 5 Jul 2017 14:02:12 -0400 From: Jeffrey Haas To: idr@ietf.org Message-ID: <20170705180212.GA15632@pfrc.org> References: <001e01d2d14c$32ed2e10$98c78a30$@ndzh.com> <19180.1496426777@x59.NIC.DTAG.DE> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Idr] WG adoption call for draft-ymbk-idr-bgp-open-policy (5/20 to 6/3/2017). X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 17:53:03 -0000 Job, On Sun, Jun 04, 2017 at 11:59:47AM +0000, Job Snijders wrote: > Unfortunately, as it's currently specified, I still cannot see my > affiliation deploying this technology in a meaningful way. > > The word "peer" is extremely overloaded: it is a homonym which conflates > all kinds of concepts. The term appears in too many training courses to be > redefined to one specific meaning. On top of that, I all too often see that > provisioning- or customer engineers don't have clear insight as to who is > customer and who the supplier is. Even worse: a customer may assume the > supplier role as part of a larger deal. While in the hallways we easily > talk about simplified models on how the internet works, actually enforcing > that simplification in the context of EBGP to me is undesirable. I have some opinions here that probably overlap your own. While I haven't paid good attention to operator forums like NANOG for a while, I remember that definitions of 'peer' tended to make for a heated topic. I also don't remember any particular convergence on a formal definition that would hold up in a BGP AS-graph sort of way. It might be helpful if you or other operators rally for what the current definition of that term is perceived to be. (And yes, I realize that simply asking the question may be tantamount to starting a flame war...) [...] > > Perhaps if the draft would focus on merely two classifications: "stub" and > "transit" networks, where the former would be an affirmation that neither > party expects the "stub" network to transit prefixes for any other ASN, and > transit networks would enjoy the same behavior as any ASN today, that would > give a different twist to this idea. Downside is that one needs to bounce > the session to become a transit provider. The real issue here is the simple matter of AS-graph definition. A stub network is always clear. Traditional papers for valley free routing tend to focus on the remaining up/down/lateral relationships. I believe these are the properties we're looking for, and that stub/transit is probably not a sufficient relationship. -- Jeff From nobody Wed Jul 5 11:44:31 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 457C3131DB9 for ; Wed, 5 Jul 2017 11:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 FoXQ7l31-414 for ; Wed, 5 Jul 2017 11:44:28 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1DAD131DBF for ; Wed, 5 Jul 2017 11:44:27 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v65IiOHT071647 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Jul 2017 19:44:24 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local Message-ID: <595D3387.7080101@foobar.org> Date: Wed, 05 Jul 2017 19:44:23 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.15 (Macintosh/20170609) MIME-Version: 1.0 To: Jeffrey Haas CC: idr@ietf.org References: <001e01d2d14c$32ed2e10$98c78a30$@ndzh.com> <19180.1496426777@x59.NIC.DTAG.DE> <20170705180212.GA15632@pfrc.org> In-Reply-To: <20170705180212.GA15632@pfrc.org> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Idr] WG adoption call for draft-ymbk-idr-bgp-open-policy (5/20 to 6/3/2017). X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 18:44:30 -0000 Jeffrey Haas wrote: > It might be helpful if you or other operators rally for what the current > definition of that term is perceived to be. It means just what people choose it to mean - neither more nor less. Words mean so many different things. Nick From nobody Wed Jul 5 11:54:19 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F01DE131550 for ; Wed, 5 Jul 2017 11:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 hVWypVX7YCHe for ; Wed, 5 Jul 2017 11:54:16 -0700 (PDT) Received: from mail-wm0-f45.google.com (mail-wm0-f45.google.com [74.125.82.45]) (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 DE51A12EC21 for ; Wed, 5 Jul 2017 11:54:15 -0700 (PDT) Received: by mail-wm0-f45.google.com with SMTP id 62so231432271wmw.1 for ; Wed, 05 Jul 2017 11:54:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=xBpJLV+5AfY+6I4YfSoCkVScON1ZssdiNiEKEJW4be0=; b=NgvrIxfJSXUK3nFKBm79C9QVo0nvEmdX5Kg5iNCu9g47tsz1qjJsoxwWU5cqHkeS7/ FMndFfOd1FB9I3Qr55kA+5zB2RBrSTsz1lydWf67IAqgiQm+rV+gR6kQdjyClvHBPSdB s1F4aX4JmKgWFb8vNKQ4xb0PeA2RMwDzmviRkOk+FAgQmL2zcsjM2K2yNddOfYf22rMx aMInjdh31KsUsidUbZw+Ky8lbajOP0ASjgqvBOn660EAZZnTA9DEs+IuaN+nfYNVDu6G /jLzxYXI97eN6sjSNIhNhlbhs/yxHIdhFQu82zS+iDB/WPkrX27pwIC6Z/UOSCNkrokE SmWQ== X-Gm-Message-State: AKS2vOy/Vbldrz42QJ6DKynoSlm0Abm4bsqXLRhiif0e8YApJEw4POQ1 7+ChB+K5QENhFRXn X-Received: by 10.80.145.118 with SMTP id f51mr23514686eda.170.1499280854149; Wed, 05 Jul 2017 11:54:14 -0700 (PDT) Received: from localhost ([89.200.47.198]) by smtp.gmail.com with ESMTPSA id x51sm13813141edd.49.2017.07.05.11.54.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Jul 2017 11:54:13 -0700 (PDT) Date: Wed, 5 Jul 2017 20:54:12 +0200 From: Job Snijders To: Jeffrey Haas Cc: idr@ietf.org Message-ID: <20170705185412.dr3pcvxtjayn6xw4@Vurt.local> References: <001e01d2d14c$32ed2e10$98c78a30$@ndzh.com> <19180.1496426777@x59.NIC.DTAG.DE> <20170705180212.GA15632@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170705180212.GA15632@pfrc.org> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: NeoMutt/20170609 (1.8.3) Archived-At: Subject: Re: [Idr] WG adoption call for draft-ymbk-idr-bgp-open-policy (5/20 to 6/3/2017). X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 18:54:18 -0000 On Wed, Jul 05, 2017 at 02:02:12PM -0400, Jeffrey Haas wrote: > On Sun, Jun 04, 2017 at 11:59:47AM +0000, Job Snijders wrote: > > Unfortunately, as it's currently specified, I still cannot see my > > affiliation deploying this technology in a meaningful way. > > > > The word "peer" is extremely overloaded: it is a homonym which > > conflates all kinds of concepts. The term appears in too many > > training courses to be redefined to one specific meaning. On top of > > that, I all too often see that provisioning- or customer engineers > > don't have clear insight as to who is customer and who the supplier > > is. Even worse: a customer may assume the supplier role as part of a > > larger deal. While in the hallways we easily talk about simplified > > models on how the internet works, actually enforcing that > > simplification in the context of EBGP to me is undesirable. > > I have some opinions here that probably overlap your own. While I > haven't paid good attention to operator forums like NANOG for a while, > I remember that definitions of 'peer' tended to make for a heated > topic. I also don't remember any particular convergence on a formal > definition that would hold up in a BGP AS-graph sort of way. > > It might be helpful if you or other operators rally for what the > current definition of that term is perceived to be. I don't think that is possible. > > Perhaps if the draft would focus on merely two classifications: > > "stub" and "transit" networks, where the former would be an > > affirmation that neither party expects the "stub" network to transit > > prefixes for any other ASN, and transit networks would enjoy the > > same behavior as any ASN today, that would give a different twist to > > this idea. Downside is that one needs to bounce the session to > > become a transit provider. > > The real issue here is the simple matter of AS-graph definition. A > stub network is always clear. Traditional papers for valley free > routing tend to focus on the remaining up/down/lateral relationships. > I believe these are the properties we're looking for, and that > stub/transit is probably not a sufficient relationship. Shouldn't the draft perhaps focus on what _is_ clear? Kind regards, Job From nobody Wed Jul 5 13:15:27 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71A1C131DC5 for ; Wed, 5 Jul 2017 13:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_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=juniper.net 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 SxvUsamzRcju for ; Wed, 5 Jul 2017 13:15:23 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0132.outbound.protection.outlook.com [104.47.37.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A786131DC4 for ; Wed, 5 Jul 2017 13:15:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nk0ZfOTUWZcOiyuNYewiglLy/DT3MJ2kvYuYicWoGo8=; b=KOK4HEva2oPJa2KSR1x/PZTUyZF21F7xhjUMiO82FiyBwa7hX37v/PBVHako56sAeQnF8ABdx+DlW8svb/Q0CSFyVVGSK+lxYEeDhgXil1VxTJcUb5t8h5/6ytmt5uApOp5z/fFe3Nfw9LwO7NzIq67yTnUMsrX/ayubcMK+YMw= Authentication-Results: ntt.net; dkim=none (message not signed) header.d=none;ntt.net; dmarc=none action=none header.from=juniper.net; Received: from askhan-sslvpn-nc.jnpr.net (66.129.241.13) by BN3PR05MB2498.namprd05.prod.outlook.com (10.167.3.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.6; Wed, 5 Jul 2017 20:15:21 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: <20170704191312.nkkjeylhrpx5qcgz@Vurt.local> Date: Wed, 5 Jul 2017 16:15:18 -0400 Cc: Jeffrey Haas , idr@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <38186E07-5635-44F1-8933-BCC21514F284@juniper.net> References: <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> <09BFF794-6899-4DA5-8EF5-DDF86513BFBA@pfrc.org> <20170704104840.mg5bflnmmjlv4jbi@Vurt.local> <20170704175334.GO2289@pfrc.org> <20170704181454.la5hw3nyisneefff@Vurt.local> <79BF9BD8-5589-48E4-A2ED-478E9BD9E989@pfrc.org> <20170704191312.nkkjeylhrpx5qcgz@Vurt.local> To: Job Snijders X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: BN6PR13CA0031.namprd13.prod.outlook.com (10.171.172.17) To BN3PR05MB2498.namprd05.prod.outlook.com (10.167.3.27) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b8e7696a-8a97-4082-00e9-08d4c3e2906d X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(48565401081)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR05MB2498; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 3:0fx5nV6wVR2XsBZFCWBTzQE775JkPmkpcjh2x8eo5yXLbflwf2py/3M/PRnLHuzMNTeVjy4TToRcLuPZCGqy1PQvEcWwhr0u3Ll70QO322cLSNSQ3A0Eci4viYMfwNjXfE6Yxlullns5c8haAvtRT7A+j5c4Hue+m8C6TVnwmtiqmnZFtU8foh20e8o49YfyrMqmAPS1AYSqtOqNCiaER2Tx4f3lGRGYvGzQ9J47GcwK9V8z2VDDJHomksMlvpmWhcm/ai3uIWxjz8o/tFsccKc6PJjMHODLmyXzoBiGphHLltYw2CdaqIDylFRIUdRcZgQOWXRV4OEreiUfOtweiMkOY0t8NtaLepUFPfvFWt6s/op7SfuxgE/1fIhf5bnxoOvoFN4LkehheflR9xv1k65YypeWUMB14MiWrEAME2RDO4kUZQD7a82tHIcFWy8ETeE2/LyU100pC6s/sy+UoQX6MihHaJlMXWIkhQqI8jL7GjJFnR5RHcDK+0IAxBeimMkvYeM3vXMurv/r5coK09ygBVEzRXhUduRGgjNuoeMk9qSTz3ocv3xKvZbbTEybkbm66XuynUuXTJoYyrfAIMKCuR7cnxTEouiKRAqdSz8YQtW03XbvYzynrvR7OxBSP7bkWhXaqJMTCS7xoWkaUtjStnMky8hOV1mGPXjiaogXhN3VnypXryYeErWPZDYZcVWIVsQMLhR6MxNIHT71DDAQ6PsRHSyvn2nhjm9tyQvsb56m6rU1/UCXGQ5GW3XyMv4KIETiYYa0Mm1gFp8EiQ== X-MS-TrafficTypeDiagnostic: BN3PR05MB2498: X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 25:oDlLkZanjs3nV8/US4IXJ1HTtTkILdMi6veqXDYBGwqOJ3RB/zn6BpC8ZnO/+0HfwWeCgs5aVS5ZaIXkgnsiz7VDSzve2Y5Kpc7r04kcSR9P3iycNK3+j255/+ujfy9p++NJPU/Htbuw4LTVm4twxjIyimmGAyJcli4hkhl2uOL6TKARmnFTFbWNhDT3W59o/NvdrINbylHJ6RAMPI7qqFVah8ulZQCM/LmHFicQIJC2dcQCn9uNS0/vwDqFPVPm6n8am96LbqL2Bo7ykrzSeAGL6fB64DglaFFgcp07cwv2drs3MGiKk9BY/cga9TEzzo65WZUFv6B7+RmSGKk4VAl+QVMlEU5yweHHDmh3/4izQLDkBA8uJLMtNHqYxow9lIBpE/OlcTUIvFIDMgYCeza5SDJvr+ykeFJBoGB1qpiBDc2XBsd+YvchCpS61/IFa95rtRKszwwYMo/2RaMlY4Y3iINPcKSSsCsRgqJFcL4idHieHIisTYzMRUGflYoBQn4BAnS+LALw+WxlwTFKKn4xIRoLzLuwlQ39E6AIw58VVj9Ur0h+imHvWtup4m7CpWEEIGtiUTmFYixDmgq0vz70gziiwLCGdcpoE7YMzUAtA/0il0tXieOcPFrQQlCUqLzwupBXIFayGRL+v2lRQxICMyCSDI2nndRal6rI0SfjZTfNS2m/RXWAt+FD1qy2RZy8eDsU4tKwEQjigN/8eFFLetEGaKBllqokqSviEq2V51NNB+tC4EzYiTghWRGv9EMm/gFsmLDNTREKMB9da13N6FbZsqx8xfQ8rLf6qmvIUzDBJReFmaBGhFm6VC2g0mswbLfA5KnwtgD7Mq0MbGNm4NqGxGq1pIa9MIMurUjT2tCuk7mmOhpe8ReHtEqHW8Z+YzHgplR2+cx9MkD5RWzxtG99lKItlhAQuqgUYqw= X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 31:14PAgtSbJl6nkatF6ZXXfGyHuanCr6S+9h+o+hohsQzhCikInJ1YRcIEhpD4Sc+mRfv08EfLjjxnnKXz+EWyrgaVT/S3vdUEo7TLKG1kj/LFGek+25htYsxZBJGwHN9L6PBf0rCmAWKNxqvcMJXmuyPc/1AkgBXkSLjeNC2b6Duk5AF+AJdu50ulSd66l3+rdFJwcbdTTwhQxJzn3v+OsKr9Eewa9QwoNUyXQvU3rY65JAVT1vZOmw9geqscPnKZRrpdSgw0ELZbEzh3UXf1QYlQCd0O/RxwSz14VEImJi4n610rFWCfWn6oHU5/hYrnjTJ5t0A9ClIGomvLOl7D8fG1PKd8hk4CXZD6y2KG35ZdxyjFAaeEWNHOcKguZ10B+UgSNhPF1A19wD/b5+GTdPeL9WDRCYi5sY9D7ZGr1oE5ikWCHnKgCC+y184rHd7t8oj+VSgX9txOYDOvuwli5TH9xWlGPE3ZU92bdaQwxU+yVS+dtcXfNutVIH6v3lHTge0OTSaFPuisTxrqUwChWYLyoAoqmDc1ShtWWBkc0I/QVO8F7SCRkV8rIu0uky8iaoxg+hjSFKluSf8p0XjGzQHMiR2WBDNrNHbFTUQ5FjGKTZEtnAswjVnoJqpMdsI68VBl5p2nPYXg6HzFhJ+lIoe0D6ELsgc2iZNDHX1ZBMku9ghXHtDq+8vuZqsesghhq4ySA0pf+d7ZL5ZBOSOzXA== X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 20:U2x7NDS3M5ayNCTYZ56z3kv5JVhHIcvDhqn375aPVYXeiuMM9xvmeuAhX2xyoHwBTteziGDcouR1UkN2+kCDsZyoCac72Y6yH45xiKR/CT3y1lprX5K6742RClCTy8Y4LbcFe1DZ3RUPSSmSRV3SgSQZvCrieLQvKLV2kZVzNN11guzfVXkGMZkZ3jrDSG+sYlzg1/53n/xeYPCpT/Nj2y593HRgXq4bugYGxeP/hWg++jmzBncyj/9SF+2SQM8UKFrGZe+wSumt78o8Ex3ZWed/A0osIKSRlql1HBu/klBnu2v7o75UPGRdejks3ZcpgvdnoS9O3eEekWBKiYHPTM76suV4HIvwp9C3qH8/CvmKSmeb8ppX6gL9GZPGhIKfn67vlrUHQX1aHYcBpTq8bkYW0I1RNRXrzqOgTc30nSIYX3fYj70mMnHwXzPA/qND3UaO6mjxBEXaVLutCDTcIp1Pv12fTph+4fH7spRgBnQjPju5z3lsotZT01sCuJl7iPvSDJz2CiIoG/u+nahsw3cPaovPxwYLw+LQv2i+0UiGQeSAurqSMdwXF42C9t+dP4/ejO/9j9IgPfJ5FVdmUyxldH5bh4MNWNPRxTb18d8= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278178393323532)(158342451672863)(236129657087228)(148574349560750)(247924648384137); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123555025)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR05MB2498; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR05MB2498; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR05MB2498; 4:nbJosabRNAaKkBioqnuFs7Rjumbs82lLzhDbE59RQG?= =?us-ascii?Q?kmzg+GOiPLScGPj+L7KSkw6r1iA4/SsfWDj+NnNIRruz+lsDEjyXryON96/+?= =?us-ascii?Q?9ZYW8e5upTEXf+zUdGgOTfD3CbCdwfB7VVe8m6uZaQLSzLaObCIgYV9HHLoO?= =?us-ascii?Q?lkycRM0l4Sa8PU41FY3AoAnm9Aa4gL2VCHxluYXuDOkND7UAtU+uhpI9hP72?= =?us-ascii?Q?lwf56o88qriVAMlsKf4e0VQ7ghrXO6N1FUmoBf6ri4Pda3e4Tgxgknn1ol1e?= =?us-ascii?Q?oOwSodiV3OEF9IHxFN+T0gcqzZnJNRLhfs99ZQXtugAoB8A0e9Gob11sk7Yo?= =?us-ascii?Q?rt881sdUdxH6J1DNRB1VgH1ZSZEuPR19dwNbpRlSVbeXt2an22xG20ylwAXP?= =?us-ascii?Q?1m6VsG75cmJVad7bTbcUlENkjAZLtsRSaUtY898Y2VEk26/wg8cU7HYtrSAo?= =?us-ascii?Q?DK8Z2SMsjQj/pGlofQAkZm2CK7T7e3GUWV2DAOlvtqB1Wisjg0gVVqzw/Rxv?= =?us-ascii?Q?NzPDXuWmNBckT7tq4q+iZgBunKhloKr566D/fgesygTe1Vev+M/1TlcjLUad?= =?us-ascii?Q?XzxQOiyeeZVNCFIBLJ5W1h66SjSYqTvoZSNsDZn9yvQAH/86hMtW+Grg4Siw?= =?us-ascii?Q?O5k1odi0LsEGvckKooHvvKwDrncr+n4mgvZjzEN9TYmPi8EFqofmQ05Oy71D?= =?us-ascii?Q?QyeynLfJ+Boss4NKgG82nO7B9ACkmn/SJOwpG6NDCZubfzL2Ll1/gVniTojT?= =?us-ascii?Q?fcvpbnYAU3LI+KzMapoNi5vtpX5ztzsIdZAaK9LH7LFlVXbo1FLenEy0Ba2s?= =?us-ascii?Q?jTOmNhQ0XuB5XHkUXUnEmVxbJ6IAWxE0vgItHKtF2phEHof8MVUa1q0HaI8O?= =?us-ascii?Q?qgHZvlLgByztKcrtZDvxnMdtVQGuSxh2rGAcHv+f8mkdKu9c5ndOO2viz9/o?= =?us-ascii?Q?Gk925mQUwVgihOKNwlVSzV2RSFHQkgdx7JpJfxo/W09kbApkvsd0S7ql22pk?= =?us-ascii?Q?cn5JI7BuBVOJAniB7rUba5LDODNumiH5wRk0m7JhhUvlyiY5PhDHI4HDtxOQ?= =?us-ascii?Q?0BwD/3cGdVo9quutH28fa50jGicO9GMjzyLFmWoHqI7Mph1oY4jBmIcv15SL?= =?us-ascii?Q?mMLUW16jKvmgr7cfrdRakGECYaTs6uLE22zbWSWoLhfIE14VEZJ7V6/vDshk?= =?us-ascii?Q?gG8e/RHUBPO5MH0edM7C6e3lesVtS7c3OdCR6U3SM2SiaPtRWjzGNPHtcgDn?= =?us-ascii?Q?Lqbd2TVv70YCPn5mJH5GYufEQlQbzT7gfw992XKzU0wZzWbUO1nPaH55aL26?= =?us-ascii?Q?VIgR9ULsaWAp97ok8bipiZgCdAxHgvohf+R2UfwvL5f6xEyuggtt8YinmdGD?= =?us-ascii?Q?wDLw=3D=3D?= X-Forefront-PRVS: 0359162B6D X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(39400400002)(39410400002)(39450400003)(39840400002)(39860400002)(39850400002)(377454003)(24454002)(38730400002)(6506006)(110136004)(478600001)(2950100002)(6916009)(50466002)(6666003)(25786009)(8676002)(53416004)(229853002)(42186005)(4326008)(50986999)(76176999)(81166006)(53936002)(6246003)(6512007)(83716003)(33656002)(8746002)(50226002)(66066001)(561944003)(7736002)(47776003)(57306001)(189998001)(93886004)(82746002)(230783001)(36756003)(6486002)(86362001)(3846002)(305945005)(23726003)(6116002)(2906002)(53546010)(5660300001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR05MB2498; H:askhan-sslvpn-nc.jnpr.net; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR05MB2498; 23:33E0O/t9wiNUo+Ia7os+vE666RWUda6fE/KD4lKEi?= =?us-ascii?Q?nPAUpyg8WdwQLaPsswbSQSn/SrAXaGbHk8KOI8r72fM/8BRi5QPd0iu0d1oI?= =?us-ascii?Q?iANSsCPbBIiwm31qNmZ3gT3iPP7U1zkcUxtT24i3Po9HccUaDg07THmfrGjM?= =?us-ascii?Q?v4KbHbNC5H67m3UEzWQWpX98w767T6qn7NJSqw+wlkKcfk+4smRp9ovi05p/?= =?us-ascii?Q?3vf/ZwEvnyqMeNd5z7tdM92hEjFzU5DnG2VjZZE95mBG2mjO2hSdKp2oK/kM?= =?us-ascii?Q?0SNH9ga8WGBaeDCoB+1ZkN4We5U74/6z0Hf+EmwpwOdM604k+EXG1OdTDwFk?= =?us-ascii?Q?WMqb+KNBAiCdJB9SybqzQu7z9pnfxS4LQNWztaNnQ/r+/i4M87xMQeMegb0A?= =?us-ascii?Q?+phgyDHGtcBH81NHOBWPCeVL9szXRVb4j6RYEhnH6TY1bWKi/JXULeTAw9Hc?= =?us-ascii?Q?8CXGPV3cLwfQ2Ouyi2YcF1858JvtfAD1jjNhcml21xJzlKZSY7QhhhrVkaza?= =?us-ascii?Q?FGuGyto0J2K726jvSkYNyqvVWMSbHtPXiTCdJDytEklIJhbwV1ldeV9E48k+?= =?us-ascii?Q?4ognwU45P835fPtrjiGlQhlWxJdlUtxwtFMnhK0i4ELefmspT6vUIUdrm6Rx?= =?us-ascii?Q?7rPR2DmfOF+YBAck48iew+iNuqESu1RzCwIGVXNHVS2moKseL9E+39L1VRsA?= =?us-ascii?Q?Uy+aoGG8gmM+xRQ0P1YG1aMOjg9JWC2ybqOvXThXRXUsWA0320/2qCNdB2lU?= =?us-ascii?Q?8MGZjrBl92hZgAIOqNSebI0rOhXKklVw25zO0t1YBQtlT2lGSqHGqjk7A9wy?= =?us-ascii?Q?kbaKaIp9wQr+QIeu7+fjn2OFyVD53CcXx/Wxa9H0pZkSNKxNnEpLQS099ZoW?= =?us-ascii?Q?T2jsYL+9PsEtxM6i/oSRCZpU+wTsS6rzrIUXMmH9+h6X9QMXpUwueD1i+aC1?= =?us-ascii?Q?FPI/QQIp1/99kq0B0tEOO5Lm+hgtxwkQf2GT/jZUQsrJzZuVlkBJClpQopl4?= =?us-ascii?Q?1gH12l5mRZmkdD/4AYIRoErFfswrau7XUYkaKJ+xasPp0xCvhJCpnNxa3FUQ?= =?us-ascii?Q?NkGdnn69yBDBAQBVj2+1raQ5EcfEdslBNLtCho3J9JFAxLyD4WNQxZt8ET2j?= =?us-ascii?Q?gKbfKCQwuycYDSEMOy7kBhqBUbHpuHtSgPP+KDsEAmXXe9HhkuqhYdK5QC5k?= =?us-ascii?Q?ZbG+feXhI3XC7c3bG8lhA0z9gcnaIBYBoOVm0VVyJHaMSQQj7mkMOV7+HG5n?= =?us-ascii?Q?S/cWo9+NWTkG9Zgw1He1uXOgPL3oanz4Mhylba711rtJDkEOR5xPT4xSy/Lw?= =?us-ascii?Q?epUf+YJzTZok6exj03siAw=3D?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR05MB2498; 6:FcjO4IzmPXRTnY/ceOggv4gP8ULmkDhYLlPpz/Qubz?= =?us-ascii?Q?Z2bQmQvPyOgqd7RNnIX61l4+dTm/OeDAKsUz5NElizNjePQOjgOmJHG47Txf?= =?us-ascii?Q?usvipwh315oNMenKMd+94eoO2w3zzeFOiLEzP9ODkmD1Y+4yH9uZVyx+3dBN?= =?us-ascii?Q?qNSUoXUlPB+sYgdT6TyMtk0uTE7br93J5w1fqRQamB11ItLUdld13+xvk5lW?= =?us-ascii?Q?4W9/mCS6f7qmUcfnY9DXeLA8lPSAEvRhu3PHps/HIv66hjJwhM4JXgxXfeET?= =?us-ascii?Q?dBBDm3qHJDU/bGiXSu6faMUEK6imjfYAltksiYwLDCZBw1d45eZmwZ+2ady+?= =?us-ascii?Q?CKUVO0I5cAnYPviEmySD/fJrv/e8RELs7jLPsXkyiDOPmbJWQIH1OMhHPgHF?= =?us-ascii?Q?GxEAugOF4nxwdbeefSUExdK4AlBma7xJNANMq+1rn6bmREYnaXHmyY4QjFYu?= =?us-ascii?Q?TgFdrE4g9sby1Z7psTSr3sUZcq6rK63zFbsYOmr3I1lbYCEnz8VuhrznWROK?= =?us-ascii?Q?MarO2tGfWri9piiddgEDyYW0NGshv2IT7ObwrmbXhBtgHKIJ7uB9+aZSjEDg?= =?us-ascii?Q?ylncsfzxuePeTlhr0h3SEAgOHFE0qwVHU4qZOBtziUbFBpdoe+YBweTX4NRM?= =?us-ascii?Q?T1TeZqNo7GLddktRFnc/xc4O5w0lXYmaxpfLiOsarjS6ym/fJqtGKG9ib+LX?= =?us-ascii?Q?+qhjHIWmlvGE44CEW4lrsXDUW3aGqzKNRpTUUS+IbzvN6ic2B22UaVf1rYnS?= =?us-ascii?Q?FWIYRlxv8aRIDM+pH1K0W5KNMmkCVddWvam2AGOPWXT8veEAQ+6WxqdrFfp/?= =?us-ascii?Q?uqiV15X6NnbupSOcrENmeJ49VBpqIXPL8WfE4KbL6tyd2u531ykT4wE6HJnm?= =?us-ascii?Q?iGal+JWQrLfNhfWYn2ey1dAkCM1vKMhz//iRKAEXuJiLGsq0axp0V8iRtvaz?= =?us-ascii?Q?IXaNc0YzOVPg67x5ZyOkASXL3YoSqPyOw+3nW5zyUb1ywgwxmVzYL/qsJGX7?= =?us-ascii?Q?r4UWlqRB/FX85q7/YNxr4R?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 5:g8vUbT5ErBUNZdOrspRVZYPseZY8JXIud0i4bUdELhkc8Jfm4nCRxHhs0F20IVlM0SoIn3kDknogbtbKlxQg+EfINVTjxe1Dt/7Hh0n/rkfdxb7KzPf0PwMfIPodxWpN+oomoRWndI1cXbkJyKmxAOtF3Uges4z4Jus+Y0PxlPZbhgJkEX/xS1kEZXyMWKVMjS9/EUO8mEal55vQYwoHlLSImyg/eioDhAvJaUDRLJ+zGfFuITrTC4uf1NVw9B511T2lVG5TC+8vRZX1NyYq4EP4PjFECOPt53AbX8PMWFcD9t24QoGfN14A2AmimQPhXRwKlrYL7OvFgh5r7J4BeVVAbuEGIlqAVXCZkpputOxcUUtcuvvvFABBbwodJPwBI9yAZ6R0BT4fbAZ3jeMpKFZIjpZVIjfRyNdd2rpfoB/IOR7jswuoU71TWjP0F2NFJgovAQdaw329h7BcgdfCjRKts7r0ADYsv4FOm9H1X3FL7wuZefd30OKAHcU+T2LO; 24:NjiwcIoXZx2+SuoRGt73cUjJlhVmaIkAwpZbG3RCZSkMccxp4LLg3+El0eg3Hk2yGwnyo+aiEh2torlBJZDsdwdoXJOiL7y6C0flqBO/WmY= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 7:mDVeJRbzXOCiJgzIzd4ni0cEWC2IibCk6xMaDAV9RU7Xn/nxc6AyMMJHCtM22tmJ/gsUcKKoaCzunT6neN95kaYs+EwVXg4uAAuK1OVNTkUe66TH2v9nB6geCnvrfFypg9WfOW4Sg9KZKaGU4VqTCTnivXK4cACoYnFndlzf6Vf3JJRI3EWaLhQdGBRhbHqygHDNYqTWH581oHd0YoWi7O4KF28zekkRPdgRJis5DcOvxPEVyS/jwurvHMZgTRZxUsDQxWx7HHvGFio2OTU6B9VOy7DpdN+4zWQ4GU9Pr1fL4WKgif99Df6irBBOBlTVYZqRsp62bjW5Qwozt0iQIe7QxWRpLqDCF0YpoBGMrygW5+NDzHJDy7v9+jsEjgrGDLaBm1aNXD+8GK6B06joRBOPLSMnWgHEYOdSdILhaQGs6ueWLd8pFx6ZHBrJb0xqIA1lrhw2eo2vnZw482gGKu4cajJCZXN7GYAV5FSMpgex2T8ArXiN0uK4RCaTO0OtrgtyYh08mqypxLblC4aCi6VEJq6Y/i6KqW2jPFOB0yBPnG0xaossxQs7BTzmDRZefPKAgLeYhYlbwku1q54cK7IL9h6fqMqbv1iNGmfPIy67kIXkpdjUvSOzgJdixqDmw+/nCItdGRZxiGcOO7jIRAuT/+URcU+3rZcyqE5tyBWQnlibb4WrdsO62T02XeWtJ3+z4zuEuik/AfXz9f1Vyev4Iheb0xqZqZN2/eadjA0b4BZLsVLgIb8+nWo6VIhUS/VR6LvtC8Jnzkf1cF2sfF8shu86oSGZW2/69ii5dBM= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jul 2017 20:15:21.6107 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR05MB2498 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 20:15:25 -0000 On Jul 4, 2017, at 3:13 PM, Job Snijders wrote: > Interesting, my perception of the document was different. Did you overlook this paragraph in the introduction, or did you see it = but find it insufficiently clear? Throughout this document, we generally assume that the route server being discussed is able to represent different RIBs towards different clients, as discussed in section 2.3.2.1 of [RFC7947]. If this is not the case, the procedures described here to allow BFD to be automatically provisioned between clients still have value; however, the procedures for signaling reachability back to the route server may not. There are some fairly obvious patches to the text you quoted, if that = turns out to be the right way to improve clarity. For example (not = necessarily final proposal): > =46rom section 4 > it is not clear to me that this behaviour is optional: >=20 > "The RS uses the received ReachTell routes as input to the NHIB and > hence the route selection process it performs on behalf of the > client." NEW: The RS uses the received ReachTell routes as input to the NHIB and hence the route selection process it performs on behalf of the client, assuming it performs one per section 2.3.2.1 of [RFC7947]. > and in section 4.4: >=20 > "In computing its per-client Loc-RIB, the RS uses the content of = the > related per-client NHIB as input to the route resolvability > condition (section 9.1.2.1 of [RFC4271]). The next hop being > resolved is looked up in the NHIB and its state determined:" NEW: In computing its per-client Loc-RIB, assuming it maintains one per section 2.3.2.1 of [RFC7947], the RS uses the content of the related per-client NHIB as input to the route resolvability condition (section 9.1.2.1 of [RFC4271]). The next hop being resolved is looked up in the NHIB and its state determined:" And probably there are other pieces that would need similar. It would be nice to find a solution that makes the document clear and = unambiguous without requiring little caveats all over the place, but if = that's what it takes, fine.=20 --John= From nobody Wed Jul 5 13:40:36 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE1213178D for ; Wed, 5 Jul 2017 13:40:34 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=nistgov.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 zIFejL6uksGL for ; Wed, 5 Jul 2017 13:40:32 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0097.outbound.protection.outlook.com [23.103.200.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 DADA912ECCE for ; Wed, 5 Jul 2017 13:40:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=skD90CXPKPbbGPiehFvOJAGrbc7iWrftoYH86yHrZFw=; b=LKGVVLTHkGWMYvmSZRG1VwTTJYPkLSaVWVTNcSCh8TEY02a8eDjcQU+NxAoBwhheqfPFs1SpJElJsbquULpaztHVtMe1rPq115JKDVinDQrQRyaCItjywoR7efM9s4mL4sIFoHd76jZVIooEIWUd5i4T3ZMXoWh0CpgK6FvcXX8= Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.11; Wed, 5 Jul 2017 20:40:30 +0000 Received: from DM2PR09MB0446.namprd09.prod.outlook.com ([fe80::1c34:a069:468b:fa58]) by DM2PR09MB0446.namprd09.prod.outlook.com ([fe80::1c34:a069:468b:fa58%13]) with mapi id 15.01.1220.018; Wed, 5 Jul 2017 20:40:30 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Jeff Haas , Job Snijders CC: "idr@ietf.org" Thread-Topic: Re: [Idr] WG adoption call for draft-ymbk-idr-bgp-open-policy (5/20 to 6/3/2017). Thread-Index: AdL1zZ9uymPZnaD1TEGDl7h+h8Va0A== Date: Wed, 5 Jul 2017 20:40:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.140.122] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR09MB0446; 7:spp/yOIe1nPDyqpFup5OSW6Jaa7ea760pgmmxkoHqTHCQ8S0bDSANWTgHJJS8NZKtZcQJVYFtWe6+buN2ZqkeREG7R5XJfSG7N5vnaYTBBhhlscSw+Fa7+YPvRPFAH3vWdXE+HTHOor7XpVId4sBrtRVJ+yfOeR/+YtS+ngVIS/aCnnAakCL8C4OWKzgdkLJgcsXqLYEg3fVKYhAIAgcrzXlQyyYcBnYsbD3ISuZk2wH7rtBne0K3HzyHE4J8xZ4ImLKTLOvpfIsnrcfgqYUhKmdCM50m0uv2/EpAwpo5a+mYT8giyMRJwDNtrA8o7WjLK1ZDeiYKCBL80cvFKvj0lkAFF/5tINtBVa17Y5X5J1dTaargY/wRQABa+Br9Ml7Xf8fQLlTrEXl1nopBhKYEqq9vzam8AFtZiY+RalQuDSJBTWndy6M2AfWNbP2jh4GAeafWNs5faX2KsfEeBxOY+hdp5o2CTjHHp+VceNvyNoTHJmilE6YhFq/S+XAEpODYk2wy1vzYtxhomlzMzyIxC8U90xMA8RLKv0onzf9VrL5JKuuzeRcO1obGqQePUmK1FViVvHXuz51cfUY5xaTSL7qUOwlI8yyxvhYtVN8ylW1aOHYqbuEnkgAxKezWVActICVPGkNyRv193F3HOQfCcrSfjzykuFn5j68S40QumBydgNpf0OIcHd6Xldcjz5lL/9aGMM9k9EOtG8vXv0skVt5Sx46Wup2Z5zCDKB4b6ghMaGVxhDaXxsBMyjElDnVk1lv6ntuvdb/c5VvmfupEZuyW1KTO9RBqqcjOZuX7SE= x-ms-office365-filtering-correlation-id: 1fa607a9-323d-4639-b83d-08d4c3e61396 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR09MB0446; x-ms-traffictypediagnostic: DM2PR09MB0446: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(236129657087228); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910037)(5005006)(8121501046)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6055026)(6041248)(20161123560025)(20161123562025)(20161123564025)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR09MB0446; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR09MB0446; x-forefront-prvs: 0359162B6D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39450400003)(39840400002)(39860400002)(39850400002)(39400400002)(5423002)(8936002)(478600001)(3846002)(230783001)(7736002)(102836003)(229853002)(8676002)(6246003)(66066001)(50986999)(6506006)(38730400002)(305945005)(81166006)(14454004)(6116002)(966005)(2900100001)(2906002)(86362001)(5250100002)(5660300001)(54356999)(55016002)(99286003)(6306002)(4326008)(74316002)(9686003)(7696004)(33656002)(53936002)(3280700002)(25786009)(3660700001)(8666007)(189998001)(6436002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0446; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2017 20:40:30.3215 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0446 Archived-At: Subject: Re: [Idr] WG adoption call for draft-ymbk-idr-bgp-open-policy (5/20 to 6/3/2017). X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 20:40:34 -0000 >> The real issue here is the simple matter of AS-graph definition. A >> stub network is always clear. Traditional papers for valley free >> routing tend to focus on the remaining up/down/lateral relationships. >> I believe these are the properties we're looking for, and that >> stub/transit is probably not a sufficient relationship. > >Shouldn't the draft perhaps focus on what _is_ clear? > Here we have the benefit of having an RFC on route leaks definition/classif= ication. https://tools.ietf.org/html/rfc7908=20 Sriram =20 From nobody Wed Jul 5 14:13:12 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E1C126CC7 for ; Wed, 5 Jul 2017 14:13:10 -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 fysCJa3fj676 for ; Wed, 5 Jul 2017 14:13:09 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D82D81200E5 for ; Wed, 5 Jul 2017 14:13:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5968; q=dns/txt; s=iport; t=1499289188; x=1500498788; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=ZuZ0ndilKpYR+xBfX7pxO/fl37HMl2ON9vEHJYfXCNA=; b=SLiKk+A46dSOZNJtg8Hkq0FqHAuGSj9OjN8wwHWaRrFh78PGVROHyYpL vwG+6c9MJqZy90lN1CX1Mhu3dXYSgF+rIrgx3uEBfKndBtUi/38k0VUpJ 6QUrJ4HG9Xlt+znPJP2WcpHVJ8lJWv4lwrHezm5dPlKes/azzfySpAGww 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DJAAA+VV1Z/4cNJK1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgm9qY4EXjgKiPIUsghGGHAIagwI/GAECAQEBAQEBAWsohRkGIwpcAgE?= =?us-ascii?q?IQgICAjAlAgQbiUNkrxWCJotCAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYMng0yFB?= =?us-ascii?q?Yd9gmEFlymHXQKTepInlTIBHziBCnUVh10BiGwBgQwBAQE?= X-IronPort-AV: E=Sophos;i="5.40,313,1496102400"; d="scan'208,217";a="445734212" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Jul 2017 21:13:08 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v65LD8k5014389 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 5 Jul 2017 21:13:08 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 5 Jul 2017 16:13:07 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Wed, 5 Jul 2017 16:13:07 -0500 From: "Jakob Heitz (jheitz)" To: idr wg Thread-Topic: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt Thread-Index: AQHS9BUunfHRezzCokubhqS6qWLW+qJCmLwAgAADHACAAAV9AIAAEJgAgAAELwCAACXgAIAABdiAgAAGlwCAAAS/gIAAAluAgAADsICAAAI9gIAABIMAgAAG2ACAANELAIAAVbOAgAGER4CAABuWgIAACY6A///raUA= Date: Wed, 5 Jul 2017 21:13:07 +0000 Message-ID: References: <20170703175308.hembxkplaniz66wb@Vurt.local> <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> <09BFF794-6899-4DA5-8EF5-DDF86513BFBA@pfrc.org> <20170704104840.mg5bflnmmjlv4jbi@Vurt.local> <20C02BA3-5C13-46FB-AFE8-85D61E469EA1@juniper.net> <1FD8FAE9-E6BF-4C48-BCD6-12C1012827E2@juniper.net> 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: [128.107.151.66] Content-Type: multipart/alternative; boundary="_000_d9d07382674b4ea5b513a3608b6bd85aXCHALN014ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 21:13:10 -0000 --_000_d9d07382674b4ea5b513a3608b6bd85aXCHALN014ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW5vdGhlciBiZW5lZml0IG9mIGFkZC1wYXRoIGlzIGNvbnZlcmdlbmNlIHRpbWUuDQoNCldpdGgg dGhlIG5leHRob3AgYWRkcmVzcyBmYW1pbHksIHdoZW4gQkdQIHN0YXJ0cywNCmJlZm9yZSB0aGUg bm9uLWJlc3QgcGF0aHMgd2lsbCBiZSBzZW50LA0KIC4gdGhlIFJTIGhhcyB0byBzZW5kIGFsbCB0 aGUgbmV4dGhvcHMsDQouIHRoZSBjbGllbnQgaGFzIHRvIHNldCB1cCBhbGwgdGhlIEJGRCBzZXNz aW9ucyBhbmQNCi4gdGhlIGNsaWVudCBoYXMgdG8gc2VuZCBhbGwgdGhlIG5leHRob3AgcmVhY2hh YmlsaXR5IGluZm8gYmFjayB0byB0aGUgUlMuDQoNClRoYW5rcywNCkpha29iLg0KDQo= --_000_d9d07382674b4ea5b513a3608b6bd85aXCHALN014ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ikx1Y2lkYSBDb25zb2xlIjsNCglwYW5vc2Ut MToyIDExIDYgOSA0IDUgNCAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNp bVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0 aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1h bDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjojNzAzMEEw Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDsNCgl0ZXh0LWRlY29y YXRpb246bm9uZSBub25lO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6IzcwMzBBMCI+QW5vdGhlciBiZW5lZml0IG9mIGFkZC1wYXRoIGlzIGNvbnZlcmdlbmNlIHRp bWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6IzcwMzBBMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBBMCI+V2l0aCB0aGUgbmV4dGhvcCBhZGRyZXNz IGZhbWlseSwgd2hlbiBCR1Agc3RhcnRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM3MDMwQTAiPmJlZm9yZSB0aGUgbm9uLWJlc3Qg cGF0aHMgd2lsbCBiZSBzZW50LA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBBMCI+Jm5ic3A7LiB0aGUgUlMgaGFzIHRvIHNl bmQgYWxsIHRoZSBuZXh0aG9wcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNzAzMEEwIj4uIHRoZSBjbGllbnQgaGFzIHRvIHNldCB1 cCBhbGwgdGhlIEJGRCBzZXNzaW9ucyBhbmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNzAzMEEwIj4uIHRoZSBjbGllbnQgaGFzIHRv IHNlbmQgYWxsIHRoZSBuZXh0aG9wIHJlYWNoYWJpbGl0eSBpbmZvIGJhY2sgdG8gdGhlIFJTLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OiM3MDMwQTAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7THVjaWRh IENvbnNvbGUmcXVvdDs7Y29sb3I6IzcwMzBBMCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7THVjaWRhIENvbnNvbGUmcXVvdDs7Y29sb3I6IzcwMzBBMCI+SmFrb2Iu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6IzcwMzBBMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_d9d07382674b4ea5b513a3608b6bd85aXCHALN014ciscocom_-- From nobody Wed Jul 5 15:54:14 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BAFF126B72 for ; Wed, 5 Jul 2017 15:54:12 -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 IQ2UetI2kZRk for ; Wed, 5 Jul 2017 15:54:10 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24BB2129B38 for ; Wed, 5 Jul 2017 15:54:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23572; q=dns/txt; s=iport; t=1499295250; x=1500504850; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=JTj1MRkY0bZtMofpG+LlhAUj+traJAfnc5/weaxbPJs=; b=PazS5lw4zkjjiuWeXxqVTrmn3wXKySVzcugiGfzpu/iOELy2LkZgfWhn 3a/DHgdEvdnECW1kaGdz34NtfHLCc84sCMP4ooCzgSPFi+OdD9chYUIyk dFFxTIvXyEfs814GhR7wDAcDmJzwuFQvGh8cPcgN9VBSu7BkW49zpG0vj Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANAQCSbF1Z/4YNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9qY4EQB44CkUcilgCCES6FbgIagwI/GAECAQEBAQEBAWsohRg?= =?us-ascii?q?BAQEBAgEjVgUHBAIBCA4DAwECAScDAgICMBQJCAIEAQ0FiUtcCBCvPYImKYsbA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBGAWDJ4NMgWErC4JuhDAWDjYWgl0wgjEFhxy?= =?us-ascii?q?CM4hWhQSHXQKHRYcJhTWSHpUyAR84gQp1FVsBhwJ2hkSBMoENAQEB?= X-IronPort-AV: E=Sophos;i="5.40,314,1496102400"; d="scan'208,217";a="445767436" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Jul 2017 22:54:09 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v65Ms9oC013076 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 5 Jul 2017 22:54:09 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 5 Jul 2017 17:54:08 -0500 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1210.000; Wed, 5 Jul 2017 17:54:08 -0500 From: "Rajiv Asati (rajiva)" To: Jeffrey Haas , John Scudder CC: Robert Raszuk , idr wg Thread-Topic: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt Thread-Index: AQHSmnRjZQMhW6yq5kum3Hd4lOeZoKGSjLmAgABQ7oCAAAtWgP//sAtXgAKMygD//8REAIAASs2AgDN6BYCAffApgA== Date: Wed, 5 Jul 2017 22:54:08 +0000 Message-ID: References: <58C6751D.60306@foobar.org> <20170314204212.GD12864@pfrc.org> <815723FC-B143-4410-B0FF-D9FB4F827862@cisco.com> <20170314213607.GH12864@pfrc.org> <579D00D9-D80F-4625-BF16-0D5112C2FA98@cisco.com> In-Reply-To: <579D00D9-D80F-4625-BF16-0D5112C2FA98@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.22.0.170515 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.173.92] Content-Type: multipart/alternative; boundary="_000_A426D813F4F14629A788DF8378AA4E30ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 22:54:13 -0000 --_000_A426D813F4F14629A788DF8378AA4E30ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SmVmZiwgSm9obiwNCg0KSSBkaWRu4oCZdCBzZWUgdGhlIGxhdGVzdCAtMDMgYWRkcmVzc2luZyB0 aGUgYmVsb3cuIEFueSBwbGFucz8NCg0KLS0NCkNoZWVycywNClJhaml2DQoNCkZyb206IFJhaml2 IEFzYXRpIDxyYWppdmFAY2lzY28uY29tPg0KRGF0ZTogU3VuZGF5LCBBcHJpbCAxNiwgMjAxNyBh dCAzOjQyIFBNDQpUbzogSmVmZnJleSBIYWFzIDxqaGFhc0BwZnJjLm9yZz4NCkNjOiAicm9iZXJ0 QHJhc3p1ay5uZXQiIDxyb2JlcnRAcmFzenVrLm5ldD4sICJpZHJAaWV0Zi5vcmciIDxpZHJAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0lkcl0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1pZHItcnMt YmZkLTAyLnR4dA0KDQpIaSBKZWZmLA0KDQoNCiAgIEJ1dCBtb3JlIGltcG9ydGFudGx5LCB5b3Un bGwgc3RvcCBzZW5kaW5nIGl0IHRvd2FyZCB5b3VyIG93biBwZWVyaW5nIGFuZA0KICAgYXR0cmFj dGluZyBibGFja2hvbGVkIHRyYWZmaWMuDQpJbmRlZWQuIFRoYXTigJlzIGtleS4NCg0KQW5kIGl0 IGNvdWxkIHJlbHkgb24gdGhlIHJvdXRlIHJlc29sdmFiaWxpdHkgY29uZGl0aW9uIHRvIGJlIGFw cHJvcHJpYXRlbHkgbW9kaWZpZWQsIGFzIGRlc2NyaWJlZCBpbg0KaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtaWRyLWJncC1iZXN0cGF0aC1zZWxlY3Rpb24tY3JpdGVyaWEu DQoNCiAgICBSUy1CRkQgYmFzaWNhbGx5IHJlaW52ZW50cyB0aGUgc2FtZSBwcm9jZWR1cmUgaW4g eW91ciBkcmFmdCwgc2ltcGx5IGJlaW5nDQogICAgc3BlY2lmaWMgYWJvdXQgdGhlIHVzZSBvZiBC RkQgYXMgdGhlIGRhdGFwbGFuZSBsaXZlbmVzcyBjaGVjayBtZWNoYW5pc20uDQogICAgSG93ZXZl ciwgYXMgeW91IG5vdGUgaW4gdGhlIFJTLUJGRCBkcmFmdCwgd2UgZG8gbGVhdmUgdGhlIG9wdGlv biBmb3Igb3RoZXINCiAgICBtZWNoYW5pc21zLg0KDQogICAgSSBzdXNwZWN0IHRoZSBvdGhlciBh dXRob3JzIG9mIFJTLUJGRCBhcmVuJ3QgcGFydGljdWxhciB3aGVyZSB3ZSBwaWNrIHVwIG91cg0K ICAgIHRleHQgZm9yIHRoZSByZXNvbHZhYmlsaXR5IGNvbmRpdGlvbi4gIEhvd2V2ZXIsIGlmIHRo ZSBzdWdnZXN0aW9uIGlzIHRvIG1ha2UNCiAgIGEgcmVmZXJlbmNlIHRvIHlvdXIgZHJhZnQsIHlv dSdsbCBuZWVkIHRvIGJyaW5nIGl0IGJhY2sgZnJvbSB6b21iaWUgc3RhdGUNCiAgICBhbmQgcHJv Z3Jlc3MgaXQuIDotKQ0KDQpBZ3JlZWQuIEl0IGlzIGFsaXZlICgtMDcgdmVyc2lvbikuIGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlkci1iZ3AtYmVzdHBhdGgtc2VsZWN0 aW9uLWNyaXRlcmlhLTA3DQpJdCBjYW4gYmUgdXNlZCBhcyBhIG5vcm1hdGl2ZSByZWZlcmVuY2Ug aW4geW91ciBkcmFmdC4NCg0KLS0NCkNoZWVycywNClJhaml2IEFzYXRpDQpEaXN0aW5ndWlzaGVk IEVuZ2luZWVyLCBDaXNjbw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSmVm ZnJleSBIYWFzIDxqaGFhc0BwZnJjLm9yZzxtYWlsdG86amhhYXNAcGZyYy5vcmc+Pg0KRGF0ZTog VHVlc2RheSwgTWFyY2ggMTQsIDIwMTcgYXQgNTozNiBQTQ0KVG86IFJhaml2IEFzYXRpIDxyYWpp dmFAY2lzY28uY29tPG1haWx0bzpyYWppdmFAY2lzY28uY29tPj4NCkNjOiAicm9iZXJ0QHJhc3p1 ay5uZXQ8bWFpbHRvOnJvYmVydEByYXN6dWsubmV0PiIgPHJvYmVydEByYXN6dWsubmV0PG1haWx0 bzpyb2JlcnRAcmFzenVrLm5ldD4+LCAiaWRyQGlldGYub3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+ IiA8aWRyQGlldGYub3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtJZHJd IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtaWRyLXJzLWJmZC0wMi50eHQNCg0KICAgIFJhaml2LA0K DQogICAgT24gVHVlLCBNYXIgMTQsIDIwMTcgYXQgMDk6MDg6MjRQTSArMDAwMCwgUmFqaXYgQXNh dGkgKHJhaml2YSkgd3JvdGU6DQogICAgPiBJcyB0aGUgYXNzdW1wdGlvbiBoZXJlIHRoYXQgdGhl IGNsaWVudCByb3V0ZXJzIGhhdmUgcm91dGluZyB2aWV3IGxpbWl0ZWQgdG8gd2hhdOKAmXMgcHJv dmlkZWQgYnkgdGhlIFJvdXRlIFNlcnZlcj8gSWYgbm90LCB0aGVuIHdvdWxkbuKAmXQgQ2xpZW50 IFJvdXRlcnMgYmVuZWZpdCBmcm9tIGhhdmluZyB0byBpbnZhbGlkYXRlIHRoZSBwYXRoIGxlYXJu ZWQgZnJvbSB0aGUgcmVtb3RlIGNsaWVudCByb3V0ZXIgYXMgc29vbiBhcyB0aGUgY29ubmVjdGl2 aXR5IGNoZWNrIGZhaWxlZD8NCg0KICAgIFRoaXMgaXMgd2hhdCBJIGJlbGlldmUgdGhlIHByb2Nl ZHVyZSBzYXlzLiAgU2VlIHNlY3Rpb24gNi4NCg0KICAgID4gT2YgY291cnNlLCBDbGllbnQgUm91 dGVycyBjb252ZXlpbmcgdGhlIGxhY2sgb2YgTkxSSSByZWFjaGFiaWxpdHkgcGVyIE5IIHRvIHRo ZSBSb3V0ZSBTZXJ2ZXIsIGFuZCBleHBlY3RpbmcgUm91dGUgU2VydmVyIHRvIHByb3ZpZGUgYSBk aWZmZXJlbnQgTkhzIG9mIHRoZSBOTFJJcywgYW5kIGV4cGVjdGluZyBpdCB0byBiZSBmdW5jdGlv bmFsLCB3aGlsZSBzdGlsbCBhdHRyYWN0aW5nIHRoZSB0cmFmZmljIGZvciB1bnJlYWNoYWJsZSBk ZXN0aW5hdGlvbnMgc2luY2UgdGhlIExvYy1SSUIgaXMgc3RpbGwgcG9pbnRpbmcgdG8gdGhlIHVu cmVhY2hhYmxlIE5IIGZvciB0aGUgYWZmZWN0ZWQgTkxSSXMuDQoNCiAgICBUaGUgdGhpbmcgdGhh dCBpcyBzb21ld2hhdCBkaWZmZXJlbnQgZm9yIGEgSVhQIGVudmlyb25tZW50IHJ1bm5pbmcgYSBy b3V0ZQ0KICAgIHNlcnZlciB0aGFuIG5vcm1hbCBlQkdQIGlzIHRoZSBsb3cgKHRvIHplcm8pIGxp a2VsaWhvb2Qgb2YgaGF2aW5nIGEgYmFja3VwDQogICAgcGF0aC4gIElmIDEwLzggd2FzIGxlYXJu ZWQgZnJvbSB0aGUgcm91dGUgc2VydmVyIGZvciBuZXh0aG9wIDE5Mi4wLjIuMSwgYW5kDQogICAg eW91IHN0b3AgYmVpbmcgYWJsZSB0byByZWFjaCB0aGF0IG5leHRob3AsIHJlbW92aW5nIGl0IGZy b20geW91ciBmb3J3YXJkaW5nDQogICAgKHVucmVhY2hhYmxlKSBpcyB5b3VyIG9ubHkgY2hvaWNl Lg0KDQogICAgWW91ICptaWdodCogaGF2ZSBhIHNvdXJjZSBvZiB0aGF0IHBhdGggaW50ZXJuYWxs eS4gIEluIHRoYXQgY2FzZSwgeW91IGNhbg0KICAgIHVzZSBpdC4NCg0KICAgIEJ1dCBtb3JlIGlt cG9ydGFudGx5LCB5b3UnbGwgc3RvcCBzZW5kaW5nIGl0IHRvd2FyZCB5b3VyIG93biBwZWVyaW5n IGFuZA0KICAgIGF0dHJhY3RpbmcgYmxhY2tob2xlZCB0cmFmZmljLg0KDQogICAgPiBJIHdvbmRl ciB3aGV0aGVyICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pZHItYmdw LWJlc3RwYXRoLXNlbGVjdGlvbi1jcml0ZXJpYSBiZSB1c2VmdWwgaGVyZS4NCg0KICAgIEluIGEg c2Vuc2Ugb2YgZ29vZCB0aW1pbmcsIEpvaG4gU2N1ZGRlciBoYWQgYnJvdWdodCB0aGlzIHRvIG15 IGF0dGVudGlvbg0KICAgIGFib3V0IGFuIGhvdXIgYWdvLg0KDQogICAgUlMtQkZEIGJhc2ljYWxs eSByZWludmVudHMgdGhlIHNhbWUgcHJvY2VkdXJlIGluIHlvdXIgZHJhZnQsIHNpbXBseSBiZWlu Zw0KICAgIHNwZWNpZmljIGFib3V0IHRoZSB1c2Ugb2YgQkZEIGFzIHRoZSBkYXRhcGxhbmUgbGl2 ZW5lc3MgY2hlY2sgbWVjaGFuaXNtLg0KICAgIEhvd2V2ZXIsIGFzIHlvdSBub3RlIGluIHRoZSBS Uy1CRkQgZHJhZnQsIHdlIGRvIGxlYXZlIHRoZSBvcHRpb24gZm9yIG90aGVyDQogICAgbWVjaGFu aXNtcy4NCg0KICAgIEkgc3VzcGVjdCB0aGUgb3RoZXIgYXV0aG9ycyBvZiBSUy1CRkQgYXJlbid0 IHBhcnRpY3VsYXIgd2hlcmUgd2UgcGljayB1cCBvdXINCiAgICB0ZXh0IGZvciB0aGUgcmVzb2x2 YWJpbGl0eSBjb25kaXRpb24uICBIb3dldmVyLCBpZiB0aGUgc3VnZ2VzdGlvbiBpcyB0byBtYWtl DQogICAgYSByZWZlcmVuY2UgdG8geW91ciBkcmFmdCwgeW91J2xsIG5lZWQgdG8gYnJpbmcgaXQg YmFjayBmcm9tIHpvbWJpZSBzdGF0ZQ0KICAgIGFuZCBwcm9ncmVzcyBpdC4gOi0pDQoNCiAgICAt LSBKZWZmDQoNCg0KDQo= --_000_A426D813F4F14629A788DF8378AA4E30ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpzcGFuLmFwcGxlLXRhYi1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXRhYi1z cGFuO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxl LW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SmVmZiwg Sm9obiwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JIGRpZG7igJl0IHNlZSB0aGUgbGF0ZXN0IC0wMyBhZGRy ZXNzaW5nIHRoZSBiZWxvdy4gQW55IHBsYW5zPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj4tLSZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+UmFqaXYgJm5ic3A7PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij5SYWppdiBBc2F0aSAmbHQ7cmFqaXZhQGNpc2NvLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+ U3VuZGF5LCBBcHJpbCAxNiwgMjAxNyBhdCAzOjQyIFBNPGJyPg0KPGI+VG86IDwvYj5KZWZmcmV5 IEhhYXMgJmx0O2poYWFzQHBmcmMub3JnJmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7cm9iZXJ0 QHJhc3p1ay5uZXQmcXVvdDsgJmx0O3JvYmVydEByYXN6dWsubmV0Jmd0OywgJnF1b3Q7aWRyQGll dGYub3JnJnF1b3Q7ICZsdDtpZHJAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJl OiBbSWRyXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWlkci1ycy1iZmQtMDIudHh0PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBK ZWZmLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7cGFkZGluZzowaW4gMGluIDBp biA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXJpZ2h0OjBpbiIgaWQ9Ik1BQ19PVVRM T09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyZuYnNwOyBCdXQgbW9yZSBpbXBvcnRhbnRseSwgeW91J2xsIHN0b3Agc2VuZGluZyBp dCB0b3dhcmQgeW91ciBvd24gcGVlcmluZyBhbmQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBhdHRyYWN0aW5nIGJsYWNraG9s ZWQgdHJhZmZpYy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluZGVlZC4gVGhhdOKAmXMga2V5LiA8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5kIGl0IGNvdWxkIHJl bHkgb24gdGhlIHJvdXRlIHJlc29sdmFiaWxpdHkgY29uZGl0aW9uIHRvIGJlIGFwcHJvcHJpYXRl bHkgbW9kaWZpZWQsIGFzIGRlc2NyaWJlZCBpbiZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaWRyLWJncC1iZXN0cGF0aC1zZWxlY3Rpb24tY3Jp dGVyaWEiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlkci1iZ3AtYmVz dHBhdGgtc2VsZWN0aW9uLWNyaXRlcmlhPC9hPi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0 LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4t cmlnaHQ6MGluIiBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7UlMtQkZEIGJh c2ljYWxseSByZWludmVudHMgdGhlIHNhbWUgcHJvY2VkdXJlIGluIHlvdXIgZHJhZnQsIHNpbXBs eSBiZWluZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7c3BlY2lmaWMgYWJvdXQgdGhlIHVzZSBvZiBCRkQg YXMgdGhlIGRhdGFwbGFuZSBsaXZlbmVzcyBjaGVjayBtZWNoYW5pc20uPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDtIb3dldmVyLCBhcyB5b3Ugbm90ZSBpbiB0aGUgUlMtQkZEIGRyYWZ0LCB3ZSBkbyBsZWF2 ZSB0aGUgb3B0aW9uIGZvciBvdGhlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7bWVjaGFuaXNtcy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7SSBzdXNwZWN0IHRoZSBvdGhlciBhdXRob3JzIG9mIFJTLUJGRCBh cmVuJ3QgcGFydGljdWxhciB3aGVyZSB3ZSBwaWNrIHVwIG91cjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 dGV4dCBmb3IgdGhlIHJlc29sdmFiaWxpdHkgY29uZGl0aW9uLiZuYnNwOyZuYnNwO0hvd2V2ZXIs IGlmIHRoZSBzdWdnZXN0aW9uIGlzIHRvIG1ha2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBhIHJlZmVyZW5jZSB0byB5b3Vy IGRyYWZ0LCB5b3UnbGwgbmVlZCB0byBicmluZyBpdCBiYWNrIGZyb20gem9tYmllIHN0YXRlPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDthbmQgcHJvZ3Jlc3MgaXQuIDotKTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BZ3JlZWQu IEl0IGlzIGFsaXZlICgtMDcgdmVyc2lvbikuIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLWlkci1iZ3AtYmVzdHBhdGgtc2VsZWN0aW9uLWNyaXRlcmlhLTA3 Ij4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlkci1iZ3AtYmVzdHBh dGgtc2VsZWN0aW9uLWNyaXRlcmlhLTA3PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgY2FuIGJlIHVzZWQgYXMgYSBub3JtYXRpdmUgcmVm ZXJlbmNlIGluIHlvdXIgZHJhZnQuPHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsN Cjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+LS0gPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5DaGVlcnMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5SYWppdiBBc2F0aTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+RGlzdGluZ3Vpc2hlZCBFbmdpbmVlciwgQ2lzY288bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkZyb206IEplZmZyZXkgSGFhcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpoYWFzQHBmcmMu b3JnIj5qaGFhc0BwZnJjLm9yZzwvYT4mZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EYXRlOiBUdWVzZGF5LCBNYXJjaCAxNCwgMjAxNyBhdCA1 OjM2IFBNPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UbzogUmFqaXYgQXNhdGkgJmx0OzxhIGhyZWY9Im1haWx0bzpyYWppdmFAY2lzY28uY29tIj5y YWppdmFAY2lzY28uY29tPC9hPiZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkNjOiAmcXVvdDs8YSBocmVmPSJtYWlsdG86cm9iZXJ0QHJhc3p1 ay5uZXQiPnJvYmVydEByYXN6dWsubmV0PC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJv YmVydEByYXN6dWsubmV0Ij5yb2JlcnRAcmFzenVrLm5ldDwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVm PSJtYWlsdG86aWRyQGlldGYub3JnIj5pZHJAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86aWRyQGlldGYub3JnIj5pZHJAaWV0Zi5vcmc8L2E+Jmd0OzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3ViamVjdDogUmU6IFtJZHJd IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtaWRyLXJzLWJmZC0wMi50eHQ8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7UmFqaXYsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO09uIFR1 ZSwgTWFyIDE0LCAyMDE3IGF0IDA5OjA4OjI0UE0gJiM0MzswMDAwLCBSYWppdiBBc2F0aSAocmFq aXZhKSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZndDsgSXMgdGhlIGFzc3VtcHRpb24gaGVy ZSB0aGF0IHRoZSBjbGllbnQgcm91dGVycyBoYXZlIHJvdXRpbmcgdmlldyBsaW1pdGVkIHRvIHdo YXTigJlzIHByb3ZpZGVkIGJ5IHRoZSBSb3V0ZSBTZXJ2ZXI/IElmIG5vdCwgdGhlbiB3b3VsZG7i gJl0IENsaWVudCBSb3V0ZXJzIGJlbmVmaXQgZnJvbSBoYXZpbmcgdG8gaW52YWxpZGF0ZSB0aGUg cGF0aCBsZWFybmVkIGZyb20gdGhlIHJlbW90ZSBjbGllbnQgcm91dGVyDQogYXMgc29vbiBhcyB0 aGUgY29ubmVjdGl2aXR5IGNoZWNrIGZhaWxlZD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7VGhpcyBpcyB3aGF0IEkgYmVsaWV2ZSB0aGUgcHJvY2VkdXJlIHNheXMuJm5i c3A7Jm5ic3A7U2VlIHNlY3Rpb24gNi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jmd0OyBPZiBjb3Vyc2UsIENsaWVudCBSb3V0ZXJzIGNvbnZleWluZyB0aGUgbGFjayBv ZiBOTFJJIHJlYWNoYWJpbGl0eSBwZXIgTkggdG8gdGhlIFJvdXRlIFNlcnZlciwgYW5kIGV4cGVj dGluZyBSb3V0ZSBTZXJ2ZXIgdG8gcHJvdmlkZSBhIGRpZmZlcmVudCBOSHMgb2YgdGhlIE5MUklz LCBhbmQgZXhwZWN0aW5nIGl0IHRvIGJlIGZ1bmN0aW9uYWwsIHdoaWxlIHN0aWxsIGF0dHJhY3Rp bmcgdGhlIHRyYWZmaWMNCiBmb3IgdW5yZWFjaGFibGUgZGVzdGluYXRpb25zIHNpbmNlIHRoZSBM b2MtUklCIGlzIHN0aWxsIHBvaW50aW5nIHRvIHRoZSB1bnJlYWNoYWJsZSBOSCBmb3IgdGhlIGFm ZmVjdGVkIE5MUklzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtUaGUg dGhpbmcgdGhhdCBpcyBzb21ld2hhdCBkaWZmZXJlbnQgZm9yIGEgSVhQIGVudmlyb25tZW50IHJ1 bm5pbmcgYSByb3V0ZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7c2VydmVyIHRoYW4gbm9ybWFsIGVCR1Ag aXMgdGhlIGxvdyAodG8gemVybykgbGlrZWxpaG9vZCBvZiBoYXZpbmcgYSBiYWNrdXA8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwO3BhdGguJm5ic3A7Jm5ic3A7SWYgMTAvOCB3YXMgbGVhcm5lZCBmcm9tIHRo ZSByb3V0ZSBzZXJ2ZXIgZm9yIG5leHRob3AgMTkyLjAuMi4xLCBhbmQ8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwO3lvdSBzdG9wIGJlaW5nIGFibGUgdG8gcmVhY2ggdGhhdCBuZXh0aG9wLCByZW1vdmluZyBp dCBmcm9tIHlvdXIgZm9yd2FyZGluZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7KHVucmVhY2hhYmxlKSBp cyB5b3VyIG9ubHkgY2hvaWNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDtZb3UgKm1pZ2h0KiBoYXZlIGEgc291cmNlIG9mIHRoYXQgcGF0aCBpbnRlcm5hbGx5LiZuYnNw OyZuYnNwO0luIHRoYXQgY2FzZSwgeW91IGNhbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7dXNlIGl0Ljxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtCdXQgbW9yZSBpbXBvcnRhbnRs eSwgeW91J2xsIHN0b3Agc2VuZGluZyBpdCB0b3dhcmQgeW91ciBvd24gcGVlcmluZyBhbmQ8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO2F0dHJhY3RpbmcgYmxhY2tob2xlZCB0cmFmZmljLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmZ3Q7IEkgd29uZGVyIHdoZXRoZXImbmJzcDsm bmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pZHIt YmdwLWJlc3RwYXRoLXNlbGVjdGlvbi1jcml0ZXJpYSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtaWRyLWJncC1iZXN0cGF0aC1zZWxlY3Rpb24tY3JpdGVyaWE8L2E+IGJl IHVzZWZ1bCBoZXJlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtJbiBh IHNlbnNlIG9mIGdvb2QgdGltaW5nLCBKb2huIFNjdWRkZXIgaGFkIGJyb3VnaHQgdGhpcyB0byBt eSBhdHRlbnRpb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2Fib3V0IGFuIGhvdXIgYWdvLiA8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7UlMtQkZEIGJhc2ljYWxseSByZWludmVu dHMgdGhlIHNhbWUgcHJvY2VkdXJlIGluIHlvdXIgZHJhZnQsIHNpbXBseSBiZWluZzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7c3BlY2lmaWMgYWJvdXQgdGhlIHVzZSBvZiBCRkQgYXMgdGhlIGRhdGFwbGFu ZSBsaXZlbmVzcyBjaGVjayBtZWNoYW5pc20uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtIb3dldmVyLCBh cyB5b3Ugbm90ZSBpbiB0aGUgUlMtQkZEIGRyYWZ0LCB3ZSBkbyBsZWF2ZSB0aGUgb3B0aW9uIGZv ciBvdGhlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7bWVjaGFuaXNtcy48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7SSBzdXNwZWN0IHRoZSBvdGhlciBhdXRob3JzIG9mIFJTLUJG RCBhcmVuJ3QgcGFydGljdWxhciB3aGVyZSB3ZSBwaWNrIHVwIG91cjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7dGV4dCBmb3IgdGhlIHJlc29sdmFiaWxpdHkgY29uZGl0aW9uLiZuYnNwOyZuYnNwO0hvd2V2 ZXIsIGlmIHRoZSBzdWdnZXN0aW9uIGlzIHRvIG1ha2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2EgcmVm ZXJlbmNlIHRvIHlvdXIgZHJhZnQsIHlvdSdsbCBuZWVkIHRvIGJyaW5nIGl0IGJhY2sgZnJvbSB6 b21iaWUgc3RhdGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2FuZCBwcm9ncmVzcyBpdC4gOi0pPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy0tIEplZmY8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_A426D813F4F14629A788DF8378AA4E30ciscocom_-- From nobody Wed Jul 5 15:54:40 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E483129482 for ; Wed, 5 Jul 2017 15:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 ZOY2I94LGxa3 for ; Wed, 5 Jul 2017 15:54:35 -0700 (PDT) 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 CA773126B72 for ; Wed, 5 Jul 2017 15:54:33 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id k192so100365654ith.1 for ; Wed, 05 Jul 2017 15:54:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=lHt92YAOkbYq1sEyt5x0H3VSg0KcO8BT07WBKHMshWc=; b=lyYHQrxZfxbxA4npuwPfPZrQoCSzFffvuLNn67Tcrba4HK87mA8FUA+CCaNc8XEFMe 6YNkWM6UI1+vNV+u3+j97mhXctrEmcwAPlDXvW2UjP/kgiky1DFR0TM8Diakmy36ic66 nmUuuedIaXubRG//7Em1DUmnkDMDWrdy5GMgOiKe1NcmPU/jqtfhQwaW2WkkUoqYwDwK cBv1G+P0Tn76HJ0odA+03MCJB+YOQaEhYWm3jaxsrWitiJxTlweKl5bXtdiOSUewMU5O GmN1TyExIJbLEbon2Z/XL9T1tcU2CmRdmvIT9CVIgdaD9tkpJ1jifaXRLB9y8qDvJ6UC MR/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=lHt92YAOkbYq1sEyt5x0H3VSg0KcO8BT07WBKHMshWc=; b=EaSkL8p7OfT2B4Aol63d6+jdWce9hGqvFSaQ9K7oyOxWVpyns2W+gLXQ45wjmQ2hZm ISz1aDlItSssF3LNcgV2WE4Y0a0ExIvp9uW5R9xbuKyehuTIuMHpl4xcmn/yCokwFlxQ NY2QUVcz443V9gjCHWore3tVAD3g81DEm4IBES4w+HHvh3RrIvQcvG1sloUPGibij1zr 6gC5OhYLo313NyXXPfsVZPSD/J7e1ml0kIrrjnLrJCHylUtOV8RGsi7+IqB0Ov8k2y/1 NBKiY5csEmBehGgzeCPqm4a5IafTyMFyQHpJslkMfsJTYjd4kkfuf3oZyhwFHpyXURy7 U8kg== X-Gm-Message-State: AIVw110ji8pVHsRszeqgjZNfKnu4xO8aLtTIdyxzI7pQdKdS0c/qloe8 l4VsjFfrloSGBTs9YT/PbRDzXi/5Mf6T X-Received: by 10.107.28.84 with SMTP id c81mr17750679ioc.186.1499295273019; Wed, 05 Jul 2017 15:54:33 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.32.15 with HTTP; Wed, 5 Jul 2017 15:54:31 -0700 (PDT) In-Reply-To: References: <20170703175308.hembxkplaniz66wb@Vurt.local> <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> <09BFF794-6899-4DA5-8EF5-DDF86513BFBA@pfrc.org> <20170704104840.mg5bflnmmjlv4jbi@Vurt.local> <20C02BA3-5C13-46FB-AFE8-85D61E469EA1@juniper.net> <1FD8FAE9-E6BF-4C48-BCD6-12C1012827E2@juniper.net> From: Robert Raszuk Date: Thu, 6 Jul 2017 00:54:31 +0200 X-Google-Sender-Auth: rW4XXzkK6AVFVKAHXcq8CUnxUdc Message-ID: To: "Jakob Heitz (jheitz)" Cc: idr wg Content-Type: multipart/alternative; boundary="001a1140986e296f90055399e243" Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 22:54:37 -0000 --001a1140986e296f90055399e243 Content-Type: text/plain; charset="UTF-8" Hi Jakob, I assume that new SAFI is "informational" what really means that during client bring up time it has no dependency to real AFs (1/1 & 2/1) best paths on the client. Your point is correct when you assume that the best path RS sends out is a bad one which is sort of unlike if one follows John's suggestion to based best path selection for client A based on the feedback from other clients B-Z. But I already expressed my opinion on such scheme .... Cheers, R. On Wed, Jul 5, 2017 at 11:13 PM, Jakob Heitz (jheitz) wrote: > Another benefit of add-path is convergence time. > > > > With the nexthop address family, when BGP starts, > > before the non-best paths will be sent, > > . the RS has to send all the nexthops, > > . the client has to set up all the BFD sessions and > > . the client has to send all the nexthop reachability info back to the RS. > > > > Thanks, > > Jakob. > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > --001a1140986e296f90055399e243 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jakob,

<= /div>
I assume that new SAFI is "informational"= what really means that during client bring up time it has no dependency to= real AFs (1/1 & 2/1) best paths on the client.=C2=A0

Your point is correct when you assume= that the best path RS sends out is a bad one which is sort of unlike if on= e follows John's suggestion to based best path selection for client A b= ased on the feedback from other clients B-Z. But I already expressed my opi= nion on such scheme ....=C2=A0

Cheers,
R.


On Wed, Jul 5, 2017 at 11:1= 3 PM, Jakob Heitz (jheitz) <jheitz@cisco.com> wrote:

Another benefit of add-path is convergence t= ime.

=C2=A0

With the nexthop address family, when BGP st= arts,

before the non-best paths will be sent,

=C2=A0. the RS has to send all the nexthops,=

. the client has to set up all the BFD sessi= ons and

. the client has to send all the nexthop rea= chability info back to the RS.

=C2=A0

Thanks,

Jakob.

=C2=A0


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


--001a1140986e296f90055399e243-- From nobody Wed Jul 5 20:21:15 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7C86129B6A for ; Wed, 5 Jul 2017 20:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_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=juniper.net 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 d4xboRjvkJmw for ; Wed, 5 Jul 2017 20:21:11 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0122.outbound.protection.outlook.com [104.47.42.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 B828C129AB7 for ; Wed, 5 Jul 2017 20:21:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=DtETrvzEpidbX4QKthr8KzMA/wxkqYTORhWZuFMuPmI=; b=h3v1SQ04KrJlu+2RSD9Jy1Eko80j8AtG00aD3ihKtW1VqAULFo3jVGWE3r6/PXzRoem241ifXiD/bHKNI9yDD+thgmIZv4B7+abgbS19/uWsY2XXgfnstAz3ArRTqck0AlMLbJlhhWdTBhtRc9PC5dU49VkfhrchA2aRuGoiimA= Received: from CY1PR05MB2507.namprd05.prod.outlook.com (10.167.10.134) by CY1PR05MB1995.namprd05.prod.outlook.com (10.162.216.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.6; Thu, 6 Jul 2017 03:21:10 +0000 Received: from CY1PR05MB2507.namprd05.prod.outlook.com ([10.167.10.134]) by CY1PR05MB2507.namprd05.prod.outlook.com ([10.167.10.134]) with mapi id 15.01.1240.013; Thu, 6 Jul 2017 03:21:10 +0000 From: John Scudder To: "Jakob Heitz (jheitz)" CC: idr wg Thread-Topic: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt Thread-Index: AQHS9D5iAfPwC43N0E6gQjXGHlpN/w== Date: Thu, 6 Jul 2017 03:21:10 +0000 Message-ID: References: <20170703175308.hembxkplaniz66wb@Vurt.local> <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> <09BFF794-6899-4DA5-8EF5-DDF86513BFBA@pfrc.org> <20170704104840.mg5bflnmmjlv4jbi@Vurt.local> <20C02BA3-5C13-46FB-AFE8-85D61E469EA1@juniper.net> <1FD8FAE9-E6BF-4C48-BCD6-12C1012827E2@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [75.151.14.9] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR05MB1995; 7:LbiXQUt5fGk3vTYtBUG+d3Cpynq+nsLGlWD/jAe1tQJnUsmx2R/Kp3QaJ322GtrCqkQ/AC2Mg01pYN38j1jr+piO0lm6hC/nimtoImRkKykT7Lqfnrk5oyxSJ0/lKmuFnHwBfHlh7V3ud05E40aCXkDDnqMcm8CHXE7JhIL2hjnj/oOhOsFc3HNwmBglWq4NpJJxbvuEMInO7nTKdpL4XZOCLS6gkc+jSsv0oiYL84MzWoggBxMjkXWmdgoxEu1xaDuSqvTyrWcrDaxwGJrTWpWx4Nai8jZ5sDnF7Zij/xf8L5aTK2jY9enNb0Y97fDsJeu4B0C0w0GaDjNpUmj6JyNpVWMWIG/8jZezX898xP6G4jiFYaMAHh64Hq4mcDvbicjbfiQkgtbRMVFKI566HUcuPKdGi1e1YwPpQuhjOf5Onh8wWu0rhdGr5D/zyMLGooy0PEgM36/fP1vm5mKWa06y6/OXqjs3Q/UfJKMbomPopqcOJpXDTmyZ4RGdB9fWz/+TJQuFOF8d0Qsl9cL2DetZdUjlolXFlTcvOTs8sZj5yo+/gRuS0Z2SuvDMhuEzp3sEn/lDcGsi/EhITqwWTKKCJvg2DaP7CRAHC9nB+zCOQQKawh2inGhHpNUHQCP1LtgEYzA2AQVWz87oDvqP1jD+oSS5Z0fq0j5wx38F1JawVQEOXfXxo7mC93Z1/IqUNHsL/KpbU18iKWbY7UB/AEDKQr98uhMvY9lwTvO1vv4QhnyUc9ndCesRgzGi3CNCXTTwFx1BXx5Es0scpPgAYctbyVuZ/hmA5QTWZ1U4oaQ= x-ms-office365-filtering-correlation-id: 8726f000-b36f-49b3-e9a2-08d4c41e0c8f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY1PR05MB1995; x-ms-traffictypediagnostic: CY1PR05MB1995: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(236129657087228)(95692535739014)(50300203121483)(148574349560750); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(2017060910041)(5005006)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(6055026)(6041248)(20161123558100)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR05MB1995; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR05MB1995; x-forefront-prvs: 03607C04F0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39410400002)(39850400002)(39400400002)(39450400003)(39860400002)(39840400002)(24454002)(377454003)(6506006)(99286003)(6486002)(50986999)(6436002)(7736002)(2906002)(54896002)(53936002)(54356999)(6512007)(36756003)(77096006)(76176999)(229853002)(236005)(3660700001)(6916009)(230783001)(33656002)(2950100002)(93886004)(14454004)(3280700002)(25786009)(189998001)(110136004)(38730400002)(2900100001)(102836003)(6246003)(53546010)(3846002)(5660300001)(86362001)(81166006)(66066001)(82746002)(83716003)(6116002)(8676002)(478600001)(4326008)(8936002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB1995; H:CY1PR05MB2507.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_F55CBE76FD1D462D993AF2E88E9F3184junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jul 2017 03:21:10.3132 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB1995 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 03:21:14 -0000 --_000_F55CBE76FD1D462D993AF2E88E9F3184junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gSnVsIDUsIDIwMTcsIGF0IDU6MTMgUE0sIEpha29iIEhlaXR6IChqaGVpdHopIDxqaGVpdHpA Y2lzY28uY29tPG1haWx0bzpqaGVpdHpAY2lzY28uY29tPj4gd3JvdGU6DQoNCldpdGggdGhlIG5l eHRob3AgYWRkcmVzcyBmYW1pbHksIHdoZW4gQkdQIHN0YXJ0cywNCmJlZm9yZSB0aGUgbm9uLWJl c3QgcGF0aHMgd2lsbCBiZSBzZW50LA0KIC4gdGhlIFJTIGhhcyB0byBzZW5kIGFsbCB0aGUgbmV4 dGhvcHMsDQouIHRoZSBjbGllbnQgaGFzIHRvIHNldCB1cCBhbGwgdGhlIEJGRCBzZXNzaW9ucyBh bmQNCi4gdGhlIGNsaWVudCBoYXMgdG8gc2VuZCBhbGwgdGhlIG5leHRob3AgcmVhY2hhYmlsaXR5 IGluZm8gYmFjayB0byB0aGUgUlMuDQoNCklmIHlvdSByZWFkIHRoZSBkcmFmdCBjYXJlZnVsbHkg eW91J2xsIHNlZSB0aGlzIGlzIG5vdCB0aGUgY2FzZS4gVW5yZXBvcnRlZCBuZXh0aG9wcyBhcmUg c3BlY2lmaWVkIGFzIGhhdmluZyBpbXBsaWNpdCBzdGF0ZSAidW5rbm93biIgd2hpY2ggaXMgZWxp Z2libGUgZm9yIHNlbGVjdGlvbi4NCg0KLS1Kb2huDQo= --_000_F55CBE76FD1D462D993AF2E88E9F3184junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <614CA6D3B3E0B3498A1933B9DF390A40@junipernetworks.onmicrosoft.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PjwvZGl2Pg0KPGRpdj5PbiBKdWwgNSwgMjAxNywgYXQgNToxMyBQTSwgSmFrb2IgSGVpdHog KGpoZWl0eikgJmx0OzxhIGhyZWY9Im1haWx0bzpqaGVpdHpAY2lzY28uY29tIj5qaGVpdHpAY2lz Y28uY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6IzcwMzBBMCI+V2l0aCB0aGUgbmV4dGhvcCBhZGRyZXNzIGZhbWlseSwgd2hlbiBCR1Agc3Rh cnRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOiM3MDMwQTAiPmJlZm9yZSB0aGUgbm9uLWJlc3QgcGF0aHMgd2lsbCBiZSBzZW50LA0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6IzcwMzBBMCI+Jm5ic3A7LiB0aGUgUlMgaGFzIHRvIHNlbmQgYWxsIHRoZSBuZXh0aG9wcyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjojNzAzMEEwIj4uIHRoZSBjbGllbnQgaGFzIHRvIHNldCB1cCBhbGwgdGhlIEJGRCBzZXNzaW9u cyBhbmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjojNzAzMEEwIj4uIHRoZSBjbGllbnQgaGFzIHRvIHNlbmQgYWxsIHRoZSBuZXh0aG9w IHJlYWNoYWJpbGl0eSBpbmZvIGJhY2sgdG8gdGhlIFJTLjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxicj4NCjxkaXY+SWYgeW91IHJlYWQgdGhlIGRyYWZ0IGNhcmVmdWxseSB5 b3UnbGwgc2VlIHRoaXMgaXMgbm90IHRoZSBjYXNlLiBVbnJlcG9ydGVkIG5leHRob3BzIGFyZSBz cGVjaWZpZWQgYXMgaGF2aW5nIGltcGxpY2l0IHN0YXRlICZxdW90O3Vua25vd24mcXVvdDsgd2hp Y2ggaXMgZWxpZ2libGUgZm9yIHNlbGVjdGlvbi4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8ZGl2Pi0tSm9objwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_F55CBE76FD1D462D993AF2E88E9F3184junipernet_-- From nobody Wed Jul 5 21:04:47 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 526B01243FE for ; Wed, 5 Jul 2017 21:04:45 -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 8QxkcUz2WAKg for ; Wed, 5 Jul 2017 21:04:43 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29BEC126DCA for ; Wed, 5 Jul 2017 21:04:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10842; q=dns/txt; s=iport; t=1499313883; x=1500523483; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=CyQCXdwS0Va76nQs1BuD4TiOn9twWxIXlgbIvfQppuQ=; b=jYLSmiXiSEZnS2aToq/ek9WSE5/Oz2KnzprY/ZJ11S4SS2P54GOMRL93 qmNtP/etjZnsVZXCzFdZb63+kk8VbIrYx/1Bnp+lBwiv4k1tqGVIA6dtf M8z2h4hDpl3Q7Zh+abSDhMZZ8Upy5A10GrOHZwuC1jyQbq8UtL6gFQKys c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CjAAB2tV1Z/5JdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9qY4EQB44CkWiQV4UsghGGHAIagwI/GAECAQEBAQEBAWsohRg?= =?us-ascii?q?BAQEBAyMKTBACAQgOAwQBASgDAgICMBQJCAIEDgUIiUNkr2iCJotGAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBHYMng0yFBYUggl2CYQWXLIdfApN6ghWJO4ZXlTUBHzi?= =?us-ascii?q?BCnUVhVwcgWYBdod2gQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.40,315,1496102400"; d="scan'208,217";a="450199195" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jul 2017 04:04:42 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v6644gdU019822 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 6 Jul 2017 04:04:42 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 5 Jul 2017 23:04:41 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Wed, 5 Jul 2017 23:04:41 -0500 From: "Jakob Heitz (jheitz)" To: John Scudder CC: idr wg Thread-Topic: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt Thread-Index: AQHS9BUunfHRezzCokubhqS6qWLW+qJCmLwAgAADHACAAAV9AIAAEJgAgAAELwCAACXgAIAABdiAgAAGlwCAAAS/gIAAAluAgAADsICAAAI9gIAABIMAgAAG2ACAANELAIAAVbOAgAGER4CAABuWgIAACY6A///raUCAAL0bAP//txnA Date: Thu, 6 Jul 2017 04:04:41 +0000 Message-ID: <696fbda3aa2b4af9b0fc8f4757e7b541@XCH-ALN-014.cisco.com> References: <20170703175308.hembxkplaniz66wb@Vurt.local> <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> <09BFF794-6899-4DA5-8EF5-DDF86513BFBA@pfrc.org> <20170704104840.mg5bflnmmjlv4jbi@Vurt.local> <20C02BA3-5C13-46FB-AFE8-85D61E469EA1@juniper.net> <1FD8FAE9-E6BF-4C48-BCD6-12C1012827E2@juniper.net> 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.54.193] Content-Type: multipart/alternative; boundary="_000_696fbda3aa2b4af9b0fc8f4757e7b541XCHALN014ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 04:04:45 -0000 --_000_696fbda3aa2b4af9b0fc8f4757e7b541XCHALN014ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHJlYXNvbiB5b3UgbmVlZCB0aGlzIG5leHRob3AgYWRkcmVzcyBmYW1pbHkgaXMgdG8ga25v dw0Kd2hpY2ggbmV4dGhvcHMgYXJlIHVucmVhY2hhYmxlLCBubz8NClNvIHRoYXQgeW91IGNhbiBz ZW5kIGEgcGF0aCBvdGhlciB0aGFuIHRoZSBiZXN0IHBhdGgsIG5vPw0KDQpJIHNhaWQgbm9uLWJl c3QuDQoNCldpdGggYWRkLXBhdGgsIHlvdSBnZXQgdGhlIG5vbi1iZXN0IHVwIGZyb250LCBzbyB3 aGVuDQpjb25uZWN0aXZpdHkgdG8gdGhlIGJlc3QgaXMgYnJva2VuLCB5b3UgYWxyZWFkeSBoYXZl IHRoZSBhbHRlcm5hdGl2ZS4NCg0KVGhhbmtzLA0KSmFrb2IuDQoNCkZyb206IEpvaG4gU2N1ZGRl ciBbbWFpbHRvOmpnc0BqdW5pcGVyLm5ldF0NClNlbnQ6IFdlZG5lc2RheSwgSnVseSAwNSwgMjAx NyA4OjIxIFBNDQpUbzogSmFrb2IgSGVpdHogKGpoZWl0eikgPGpoZWl0ekBjaXNjby5jb20+DQpD YzogaWRyIHdnIDxpZHJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0lkcl0gSS1EIEFjdGlvbjog ZHJhZnQtaWV0Zi1pZHItcnMtYmZkLTAzLnR4dA0KDQpPbiBKdWwgNSwgMjAxNywgYXQgNToxMyBQ TSwgSmFrb2IgSGVpdHogKGpoZWl0eikgPGpoZWl0ekBjaXNjby5jb208bWFpbHRvOmpoZWl0ekBj aXNjby5jb20+PiB3cm90ZToNCg0KV2l0aCB0aGUgbmV4dGhvcCBhZGRyZXNzIGZhbWlseSwgd2hl biBCR1Agc3RhcnRzLA0KYmVmb3JlIHRoZSBub24tYmVzdCBwYXRocyB3aWxsIGJlIHNlbnQsDQog LiB0aGUgUlMgaGFzIHRvIHNlbmQgYWxsIHRoZSBuZXh0aG9wcywNCi4gdGhlIGNsaWVudCBoYXMg dG8gc2V0IHVwIGFsbCB0aGUgQkZEIHNlc3Npb25zIGFuZA0KLiB0aGUgY2xpZW50IGhhcyB0byBz ZW5kIGFsbCB0aGUgbmV4dGhvcCByZWFjaGFiaWxpdHkgaW5mbyBiYWNrIHRvIHRoZSBSUy4NCg0K SWYgeW91IHJlYWQgdGhlIGRyYWZ0IGNhcmVmdWxseSB5b3UnbGwgc2VlIHRoaXMgaXMgbm90IHRo ZSBjYXNlLiBVbnJlcG9ydGVkIG5leHRob3BzIGFyZSBzcGVjaWZpZWQgYXMgaGF2aW5nIGltcGxp Y2l0IHN0YXRlICJ1bmtub3duIiB3aGljaCBpcyBlbGlnaWJsZSBmb3Igc2VsZWN0aW9uLg0KDQot LUpvaG4NCg== --_000_696fbda3aa2b4af9b0fc8f4757e7b541XCHALN014ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJMdWNpZGEgQ29uc29s ZSI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNCA1IDQgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseToiXEBTaW1TdW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyog U3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29O b3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmss IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVy bGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAs IGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJ Y29sb3I6IzcwMzBBMDsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7 DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 IzcwMzBBMCI+VGhlIHJlYXNvbiB5b3UgbmVlZCB0aGlzIG5leHRob3AgYWRkcmVzcyBmYW1pbHkg aXMgdG8ga25vdzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOiM3MDMwQTAiPndoaWNoIG5leHRob3BzIGFyZSB1bnJlYWNoYWJsZSwgbm8/ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6IzcwMzBBMCI+U28gdGhhdCB5b3UgY2FuIHNlbmQgYSBwYXRoIG90aGVyIHRoYW4gdGhlIGJl c3QgcGF0aCwgbm8/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6IzcwMzBBMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBBMCI+SSBzYWlkIG5vbi1iZXN0 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOiM3MDMwQTAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM3MDMwQTAiPldpdGggYWRkLXBhdGgsIHlvdSBnZXQgdGhl IG5vbi1iZXN0IHVwIGZyb250LCBzbyB3aGVuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBBMCI+Y29ubmVjdGl2aXR5IHRvIHRo ZSBiZXN0IGlzIGJyb2tlbiwgeW91IGFscmVhZHkgaGF2ZSB0aGUgYWx0ZXJuYXRpdmUuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Izcw MzBBMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7THVj aWRhIENvbnNvbGUmcXVvdDs7Y29sb3I6IzcwMzBBMCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7THVjaWRhIENvbnNvbGUmcXVvdDs7Y29sb3I6IzcwMzBBMCI+SmFr b2IuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjojNzAzMEEwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+IEpvaG4gU2N1ZGRlciBbbWFpbHRvOmpnc0BqdW5pcGVyLm5ldF0NCjxi cj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEp1bHkgMDUsIDIwMTcgODoyMSBQTTxicj4NCjxi PlRvOjwvYj4gSmFrb2IgSGVpdHogKGpoZWl0eikgJmx0O2poZWl0ekBjaXNjby5jb20mZ3Q7PGJy Pg0KPGI+Q2M6PC9iPiBpZHIgd2cgJmx0O2lkckBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFtJZHJdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtaWRyLXJzLWJmZC0wMy50eHQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g SnVsIDUsIDIwMTcsIGF0IDU6MTMgUE0sIEpha29iIEhlaXR6IChqaGVpdHopICZsdDs8YSBocmVm PSJtYWlsdG86amhlaXR6QGNpc2NvLmNvbSI+amhlaXR6QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBBMCI+V2l0aCB0aGUgbmV4dGhvcCBhZGRyZXNzIGZhbWls eSwgd2hlbiBCR1Agc3RhcnRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBBMCI+YmVmb3JlIHRoZSBub24tYmVzdCBwYXRo cyB3aWxsIGJlIHNlbnQsDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM3MDMwQTAiPiZuYnNwOy4gdGhlIFJTIGhhcyB0byBzZW5k IGFsbCB0aGUgbmV4dGhvcHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNzAzMEEwIj4uIHRoZSBjbGllbnQgaGFzIHRvIHNldCB1 cCBhbGwgdGhlIEJGRCBzZXNzaW9ucyBhbmQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM3MDMwQTAiPi4gdGhlIGNsaWVudCBoYXMg dG8gc2VuZCBhbGwgdGhlIG5leHRob3AgcmVhY2hhYmlsaXR5IGluZm8gYmFjayB0byB0aGUgUlMu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JZiB5b3UgcmVhZCB0aGUgZHJhZnQgY2FyZWZ1bGx5IHlvdSdsbCBzZWUgdGhpcyBpcyBu b3QgdGhlIGNhc2UuIFVucmVwb3J0ZWQgbmV4dGhvcHMgYXJlIHNwZWNpZmllZCBhcyBoYXZpbmcg aW1wbGljaXQgc3RhdGUgJnF1b3Q7dW5rbm93biZxdW90OyB3aGljaCBpcyBlbGlnaWJsZSBmb3Ig c2VsZWN0aW9uLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4tLUpvaG48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_696fbda3aa2b4af9b0fc8f4757e7b541XCHALN014ciscocom_-- From nobody Thu Jul 6 01:34:22 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A57A1293E1 for ; Thu, 6 Jul 2017 01:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 dRXc6QqR7fdC for ; Thu, 6 Jul 2017 01:34:20 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 52A01127241 for ; Thu, 6 Jul 2017 01:34:20 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1dT2Es-00022p-Rb; Thu, 06 Jul 2017 08:34:19 +0000 Date: Thu, 06 Jul 2017 10:34:17 +0200 Message-ID: From: Randy Bush To: Jeffrey Haas Cc: idr@ietf.org In-Reply-To: <20170705180212.GA15632@pfrc.org> References: <001e01d2d14c$32ed2e10$98c78a30$@ndzh.com> <19180.1496426777@x59.NIC.DTAG.DE> <20170705180212.GA15632@pfrc.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Idr] WG adoption call for draft-ymbk-idr-bgp-open-policy (5/20 to 6/3/2017). X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 08:34:21 -0000 life is simple. you are tryingt o detect valley violations. whether you call it dogs and cats, coffee and tea, ... are merely fun ways of trying to make simple things appear complex and are not constructive. randy From nobody Thu Jul 6 01:36:03 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D08FF12EB69 for ; Thu, 6 Jul 2017 01:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 fj4AiaglJ4r6 for ; Thu, 6 Jul 2017 01:36:00 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 A1F2B126B6D for ; Thu, 6 Jul 2017 01:36:00 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1dT2GV-00023N-Ez; Thu, 06 Jul 2017 08:35:59 +0000 Date: Thu, 06 Jul 2017 10:35:57 +0200 Message-ID: From: Randy Bush To: Robert Raszuk Cc: idr wg In-Reply-To: References: <20170703175308.hembxkplaniz66wb@Vurt.local> <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> <09BFF794-6899-4DA5-8EF5-DDF86513BFBA@pfrc.org> <20170704104840.mg5bflnmmjlv4jbi@Vurt.local> <20C02BA3-5C13-46FB-AFE8-85D61E469EA1@juniper.net> <1FD8FAE9-E6BF-4C48-BCD6-12C1012827E2@juniper.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 08:36:02 -0000 btw, the massive smokescreen of bs is not worth the time of anyone serious. please do not expect serious folk to play further. randy From nobody Thu Jul 6 02:56:42 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0327312702E for ; Thu, 6 Jul 2017 02:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5] 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 3oOElShoyPQ6 for ; Thu, 6 Jul 2017 02:56:38 -0700 (PDT) Received: from mail-lf0-f48.google.com (mail-lf0-f48.google.com [209.85.215.48]) (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 97141120721 for ; Thu, 6 Jul 2017 02:56:37 -0700 (PDT) Received: by mail-lf0-f48.google.com with SMTP id b207so9376818lfg.2 for ; Thu, 06 Jul 2017 02:56:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition:user-agent; bh=6ePCQqwLTn3kVLf7pK3PM6aCKtNC/VtfVVZpekaVcoI=; b=lBzoxpjiWuUs++73esESGh05ip2zA8bxCW4VB4KL+M8S0E9a2IHCLDc6n1jIBmag8+ hNpD6CgLTyTSHBXxDRE0tuIACz7kgKyXubNrAcjzLT6CIh7xoy1/7SXej3tXMZ8TVw42 jFvT3kElwqbeWtDRppEJuC59hJ/51bp1g6J3o2UMvxzsQXZuWIFOUGL81Gi1FXNFXEeb 5eeYsQQue6DD5jAsMWXIdPO3QL4yb1bbNzb+da2Tv3ztMkZtS31E5dio4iiSzWwqZ5ZA vqdkBT4/jMikmCTVFsPH4RP1L2OCFhFkWkwqkozsHlhKTM5bZf2YI/E7uxqtc9nW3k/J odvA== X-Gm-Message-State: AKS2vOwD2q4+tsmp5XGH9oPglMWOV08fpfvIN8qPKs5AFTC+qGH0kNg8 t+8o51HD2OVY9DW2zqFA1Q== X-Received: by 10.80.186.130 with SMTP id x2mr25232593ede.72.1499334995511; Thu, 06 Jul 2017 02:56:35 -0700 (PDT) Received: from localhost ([89.200.47.198]) by smtp.gmail.com with ESMTPSA id c8sm10981655edc.13.2017.07.06.02.56.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Jul 2017 02:56:34 -0700 (PDT) Date: Thu, 6 Jul 2017 11:56:32 +0200 From: Job Snijders To: idr@ietf.org Message-ID: <20170706095632.ywtpk5gfiae3agxn@Vurt.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett User-Agent: NeoMutt/20170609 (1.8.3) Archived-At: Subject: [Idr] [rfc-editor@rfc-editor.org: [GROW] RFC 8212 on Default External BGP (EBGP) Route Propagation Behavior without Policies] X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 09:56:40 -0000 thank you all for your feedback. Kind regards, Job ----- Forwarded message from rfc-editor@rfc-editor.org ----- Date: Wed, 5 Jul 2017 15:51:58 -0700 (PDT) From: rfc-editor@rfc-editor.org To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Cc: drafts-update-ref@iana.org, grow@ietf.org, rfc-editor@rfc-editor.org Subject: [GROW] RFC 8212 on Default External BGP (EBGP) Route Propagation Behavior without Policies A new Request for Comments is now available in online RFC libraries. RFC 8212 Title: Default External BGP (EBGP) Route Propagation Behavior without Policies Author: J. Mauch, J. Snijders, G. Hankins Status: Standards Track Stream: IETF Date: July 2017 Mailbox: jared@akamai.com, job@ntt.net, greg.hankins@nokia.com Pages: 7 Characters: 12552 Updates: RFC 4271 I-D Tag: draft-ietf-grow-bgp-reject-08.txt URL: https://www.rfc-editor.org/info/rfc8212 DOI: 10.17487/RFC8212 This document updates RFC 4271 by defining the default behavior of a BGP speaker when there is no Import or Export Policy associated with an External BGP session. This document is a product of the Global Routing Operations 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 _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow ----- End forwarded message ----- From nobody Thu Jul 6 04:17:26 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98AAE127275 for ; Thu, 6 Jul 2017 04:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-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=juniper.net 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 RVyQ2DBy_8mS for ; Thu, 6 Jul 2017 04:17:23 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0102.outbound.protection.outlook.com [104.47.36.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CDB5129AF3 for ; Thu, 6 Jul 2017 04:17:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Z0xGeCGZ0+hCILtlv650Ic1giJQj5K1RF+D+ecIiVp0=; b=Sz9OHS+tAj7tSuKhTTYdUKSoaVn9pqqU4jPLjDHu/PWDsAOxXAPYI1sIfCCOLuJdO8aAXiM2UH67GwHPoDXdLrNoq0AxAziB0qIaBIbIurN/1Y0b5b1ebAs6i2EZCQvARvvci16aLzkkKrxgo3ESjalGmy+z9RjOLCY/2Vvgd80= Received: from CY1PR05MB2507.namprd05.prod.outlook.com (10.167.10.134) by CY1PR05MB2505.namprd05.prod.outlook.com (10.167.10.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.6; Thu, 6 Jul 2017 11:17:22 +0000 Received: from CY1PR05MB2507.namprd05.prod.outlook.com ([10.167.10.134]) by CY1PR05MB2507.namprd05.prod.outlook.com ([10.167.10.134]) with mapi id 15.01.1240.013; Thu, 6 Jul 2017 11:17:21 +0000 From: John Scudder To: "Jakob Heitz (jheitz)" CC: John Scudder , idr wg Thread-Topic: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt Thread-Index: AQHS9D5iAfPwC43N0E6gQjXGHlpN/w== Date: Thu, 6 Jul 2017 11:17:20 +0000 Message-ID: References: <20170703175308.hembxkplaniz66wb@Vurt.local> <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> <09BFF794-6899-4DA5-8EF5-DDF86513BFBA@pfrc.org> <20170704104840.mg5bflnmmjlv4jbi@Vurt.local> <20C02BA3-5C13-46FB-AFE8-85D61E469EA1@juniper.net> <1FD8FAE9-E6BF-4C48-BCD6-12C1012827E2@juniper.net> <696fbda3aa2b4af9b0fc8f4757e7b541@XCH-ALN-014.cisco.com> In-Reply-To: <696fbda3aa2b4af9b0fc8f4757e7b541@XCH-ALN-014.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [75.151.14.9] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR05MB2505; 7:7pKhwJ+z72UfouyygGWmeKxEWznMZWGCu1pPcPZXrnXQTWJuPwoq/T1oeAPMYueP8ti/Vf/rMEEd4Wdy6YTxEWOX9VDzIsgvH6uzqRCGrvQB7J75iAaxctHOOhoZ77ntOKSoklQQpfsbzFTPRLKmief9sIpocjZT0yYxZU6h7a5cx3yfRpAKumgstmm4/FYNn0j0oTUv3lJ+KnsYzp/A3QyhKn3j0UOaqcb3S732G2kJQgaDFJDuNGhbJxRJQvRjODQpOwByQkOlUN2becTMqaHPvo1vMEYj3j5A6+IP4fS7fvIau/TnmrgMgHzszv7QZKO/EGmy2aKWzj8DXS9vdFRE94ligSI9i0LsSmdLPgM6S87L++wMZIFvpQ5B9qF5VmaQ6n+F6nMeYjsxeHw4pc2BsmjPBOXmd+k1NvblGH0juj5sVVCSHb45bddXwnVVkdxGynyO4K0d24W3jwEd0eZf5iBjZh0isDhe1Q665UgRnmy9IybLNfT6XxOxFfKF9J94noucSM9Ey4SgoGuQSu2OyhXMo30f8dWNuTu2WOz59Kdzr1KS7CNZBQBw2bAlEL02simE27UkyORjaodKLiqYe25LeZKfK8mW2soQrNfRxpfEiVBG86pgnIe6jo69m1K2AVV8PB03jVSl3y80EbIHAWZR+4erI2GRl8wpRTdUlaUGv01hZuyLrxgU8xNxk6GJgRrcSQBslnyvPmvzZDm4B4OB1nEOlTKeMJOAf++dWRYCNyFI3LK9t1GYZdiMG7RdiqBYKuODXRo53EvN0S0gZTdOXfaOjnwuC2/DCtQ= x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(39860400002)(39400400002)(39850400002)(39410400002)(39840400002)(39450400003)(377454003)(24454002)(25786009)(3280700002)(54896002)(54906002)(2906002)(8676002)(2900100001)(76176999)(5660300001)(6916009)(2950100002)(8936002)(6116002)(81166006)(53936002)(102836003)(93886004)(50986999)(66066001)(33656002)(14454004)(110136004)(230783001)(6246003)(83716003)(7736002)(478600001)(77096006)(229853002)(53546010)(189998001)(38730400002)(6436002)(3660700001)(86362001)(99286003)(3846002)(54356999)(4326008)(6506006)(236005)(6512007)(36756003)(82746002)(6486002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2505; H:CY1PR05MB2507.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: fb749158-85fb-4f48-3f07-08d4c46091f0 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY1PR05MB2505; x-ms-traffictypediagnostic: CY1PR05MB2505: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(236129657087228)(95692535739014)(50300203121483)(148574349560750); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR05MB2505; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR05MB2505; x-forefront-prvs: 03607C04F0 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_ADB9D2E97DBF4F5E89FA58B4389A90EDjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jul 2017 11:17:20.9021 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2505 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 11:17:26 -0000 --_000_ADB9D2E97DBF4F5E89FA58B4389A90EDjunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gSnVsIDYsIDIwMTcsIGF0IDEyOjA0IEFNLCBKYWtvYiBIZWl0eiAoamhlaXR6KSA8amhlaXR6 QGNpc2NvLmNvbTxtYWlsdG86amhlaXR6QGNpc2NvLmNvbT4+IHdyb3RlOg0KDQpUaGUgcmVhc29u IHlvdSBuZWVkIHRoaXMgbmV4dGhvcCBhZGRyZXNzIGZhbWlseSBpcyB0byBrbm93DQp3aGljaCBu ZXh0aG9wcyBhcmUgdW5yZWFjaGFibGUsIG5vPw0KU28gdGhhdCB5b3UgY2FuIHNlbmQgYSBwYXRo IG90aGVyIHRoYW4gdGhlIGJlc3QgcGF0aCwgbm8/DQoNCkkgc2FpZCBub24tYmVzdC4NCg0KV2l0 aCBhZGQtcGF0aCwgeW91IGdldCB0aGUgbm9uLWJlc3QgdXAgZnJvbnQsIHNvIHdoZW4NCmNvbm5l Y3Rpdml0eSB0byB0aGUgYmVzdCBpcyBicm9rZW4sIHlvdSBhbHJlYWR5IGhhdmUgdGhlIGFsdGVy bmF0aXZlLg0KDQpZZXMsIG15IG1pc3Rha2UuDQoNCi0tSm9obg0K --_000_ADB9D2E97DBF4F5E89FA58B4389A90EDjunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <3F6755A2403FA04AA9E92D2EB8B9BB9B@junipernetworks.onmicrosoft.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PjwvZGl2Pg0KPGRpdj5PbiBKdWwgNiwgMjAxNywgYXQgMTI6MDQgQU0sIEpha29iIEhlaXR6 IChqaGVpdHopICZsdDs8YSBocmVmPSJtYWlsdG86amhlaXR6QGNpc2NvLmNvbSI+amhlaXR6QGNp c2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOiM3MDMwQTAiPlRoZSByZWFzb24geW91IG5lZWQgdGhpcyBuZXh0aG9wIGFkZHJlc3MgZmFt aWx5IGlzIHRvIGtub3c8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjojNzAzMEEwIj53aGljaCBuZXh0aG9wcyBhcmUgdW5yZWFjaGFibGUs IG5vPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOiM3MDMwQTAiPlNvIHRoYXQgeW91IGNhbiBzZW5kIGEgcGF0aCBvdGhlciB0aGFuIHRo ZSBiZXN0IHBhdGgsIG5vPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOiM3MDMwQTAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM3MDMwQTAiPkkgc2FpZCBub24t YmVzdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjojNzAzMEEwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNzAzMEEwIj5XaXRoIGFkZC1wYXRoLCB5b3UgZ2V0 IHRoZSBub24tYmVzdCB1cCBmcm9udCwgc28gd2hlbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM3MDMwQTAiPmNvbm5lY3Rpdml0eSB0 byB0aGUgYmVzdCBpcyBicm9rZW4sIHlvdSBhbHJlYWR5IGhhdmUgdGhlIGFsdGVybmF0aXZlLjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxicj4NCjxkaXY+WWVzLCBteSBtaXN0 YWtlLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+LS1Kb2huPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_ADB9D2E97DBF4F5E89FA58B4389A90EDjunipernet_-- From nobody Thu Jul 6 06:03:37 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 765A512EB43; Thu, 6 Jul 2017 06:03:36 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 edbGM6C4Me-8; Thu, 6 Jul 2017 06:03:33 -0700 (PDT) Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39B54129B40; Thu, 6 Jul 2017 06:03:33 -0700 (PDT) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id B5BA116188C; Thu, 6 Jul 2017 15:03:31 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.10]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 9C3E718006A; Thu, 6 Jul 2017 15:03:31 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM5C.corporate.adroot.infra.ftgroup ([fe80::4bd:9b2b:3651:6fba%19]) with mapi id 14.03.0352.000; Thu, 6 Jul 2017 15:03:31 +0200 From: To: "draft-ietf-idr-tunnel-encaps@ietf.org" CC: "idr@ietf.org" Thread-Topic: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04 Thread-Index: AQHS0aHw2gkF+4EIwk6O9LK6laxSJKJHCTuQ Date: Thu, 6 Jul 2017 13:03:31 +0000 Message-ID: <15528_1499346211_595E3523_15528_221_1_53C29892C857584299CBF5D05346208A477F1D9A@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <2AEDAB02-02F4-46C2-92CA-8880BBAFAAAB@juniper.net> In-Reply-To: <2AEDAB02-02F4-46C2-92CA-8880BBAFAAAB@juniper.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 13:03:36 -0000 Hi all, Pseudo-randomly parsing the draft, I may have a comment on section 3.2.5 (G= TP) https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-06#section-3.2.5 " Local TEID: Contains a 32-bit Tunnel Endpoint Identifier of a GTP t= unnel assigned by EPC ([vEPC]). Local Endpoint Address: Contains an IPv4 or IPv6 anycast address. This is used, along with the Local TEID, to set up a tunnel in the reverse direction. See [vEPC] for details." It seems this should make [vEPC] a normative reference. For RFC publication= , this may be an issue as this draft looks like an expired individual draft= . May be another, more generic, document could be found to specify the usag= e of a GTP tunnel. Thanks, Regards, --Bruno > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G. Scudder > Sent: Saturday, May 20, 2017 9:47 PM > To: idr@ietf.org > Cc: draft-ietf-idr-tunnel-encaps@ietf.org > Subject: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-= 04 >=20 > Hi All, >=20 > A working group last call has been requested for draft-ietf-idr-tunnel-e= ncaps-04. Please > reply to the list with your comments. As usual note we cannot advance th= e draft without > participation from the group. Please get your comments in before June 5,= 2017. >=20 > Authors, please confirm that any relevant IPR has been disclosed. >=20 > https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-04 >=20 > Thanks, >=20 > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Jul 6 09:49:24 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8D413165C; Thu, 6 Jul 2017 09:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=juniper.net 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 4bdj_Kvd1L7M; Thu, 6 Jul 2017 09:49:20 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0130.outbound.protection.outlook.com [104.47.33.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAB15127869; Thu, 6 Jul 2017 09:49:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hyZGV2j6vY3qmk2vztWhFt4rwfc1exWJULvN2gHLD6g=; b=flphb1Bi3wt4jz5nXlDDzoMcQAOMpV1xiio+81ww6Ox8KJethDEzmKZYvYYeRkBSbgjy7X4s4FnH3NChouDJM9CAQZAuOQfo9n/NdMWdvZGFBiNpdTKOAWJHYhDLCys2V/UoGGaEaZ1G0zzFHwumvxmZkPBSpJuhc0VBnVVOoTw= Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.39.5] (66.129.241.10) by SN1PR05MB2192.namprd05.prod.outlook.com (10.169.124.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.6; Thu, 6 Jul 2017 16:49:17 +0000 To: bruno.decraene@orange.com, "draft-ietf-idr-tunnel-encaps@ietf.org" Cc: "idr@ietf.org" References: <2AEDAB02-02F4-46C2-92CA-8880BBAFAAAB@juniper.net> <15528_1499346211_595E3523_15528_221_1_53C29892C857584299CBF5D05346208A477F1D9A@OPEXCLILM21.corporate.adroot.infra.ftgroup> From: Eric C Rosen Message-ID: Date: Thu, 6 Jul 2017 12:49:14 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <15528_1499346211_595E3523_15528_221_1_53C29892C857584299CBF5D05346208A477F1D9A@OPEXCLILM21.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: [66.129.241.10] X-ClientProxiedBy: DM5PR2001CA0015.namprd20.prod.outlook.com (10.172.43.25) To SN1PR05MB2192.namprd05.prod.outlook.com (10.169.124.140) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 31d8742d-7fbc-4e58-7f2b-08d4c48ef17d X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(48565401081)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:SN1PR05MB2192; X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2192; 3:+UghHWRErH1/0qu8MDATX0vGHzhi3CRI2NzDIRdX+eg2hMN1Ovq0WApV7GFgD4MIJCcVIXMLdZqsir0uvMPKHPVRv6oAre/CgIdj4gpgzeyxPIj6U0DKWVDK8bH1Ovw0UFvs7bV85whA4RKufyrW3989GHrIboJinhttynHtHkJCImVOd5Ce6r9008vJASTrITv3E2Tp9Qi7ybRjwcZqr0X897SILcsECoZywHKBHJUX7glic1XeLheHdnj6dAUBazEBaNj/Tq2N3GArTETl0Jb4f+lVwp0wUKSSunQYrzL/C4uZ9rI2VUiuRHhPGCd4Z/SuxzqyrGIbpcqOtA4rCfaCf7bWfoYzhc1LSz7AC89OH8hc4a8jpCq7eg6FJoMXgAS850fUf1sijcCtTPx9uD8ojTpi6hjtyssWfJP4ZdltaXkbPbfDRytXLJtk3hBcuAkwzMV9pszqe8UFCb+ORueQjMisjwzB+pnR9h0ZW58hp65O4VcJQviCd4Bzh1GUHCFIER2bD0EbVGqFLw/5RTRFP5C7lRaYgXLvKnseCb1wR8xjXE0DmjDRgvn5zGFpx65dc9Khg0ehGjJInj89QaQlUpMvX8i9Cqrp6kbYandg4FGnXRhEZ2rNcoD7OocNYuNSeFjdMJkfOeGrMYaqudwQWe55fU+EA7EuAbfcfcD4clMORsZ89Jovb/LJQA34ngUgMWaA3Un50rvtmrVHaG6c+i6QPHkpfBWWZKMVXRoJ3E1UP3Q8JQTdvfVFUg2mJzSilige2hOtzBHaYusX6Q== X-MS-TrafficTypeDiagnostic: SN1PR05MB2192: X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2192; 25:XQe24CkDuqwCO3uzLoRemXCkrPdsinYZgEjbxhiMmnFlyIYmRz3DLBeh9JbxCWxEofRM3Rj0n/DEusSuaxtKCVVLeBg6DSekIoJ2FzvCAgj1LOJy/yCeEeG1X8AZgdOIBcO+CGrNN+lg/zJV1F1fRkhJdGXMdMpLyWEvrJWicyVlpHZhYi0X8oP11Rs+kbuEUk9Zn7GapOqGw9WiNsscUW6KeCGqd16/fZhYe9Bp/nM9VdlwH2WWpTBRAn2OwhDPIfHaNvhY9LDS5UJA3VSMsza2ggcyjJFXrjRItZnSen+1QYuHTSY68hTDCU+fhYBoK7Fhp59HPvOV/bmVBgc54qCjyL6WIMu1enUZ6fLcM0o2AgkmHMKCRoMcKflKgdCVgSfhtQuzbhOEmoxAmvJPmP/7yBX0aiPR3C3XZT94GnS/1U6tVjfhBXo9iQp/1eljHLAm9ueHbiluB3VphmhmN2JFhITKHP19WFvbwDXpJ7Er5mEPSzeYN+NkyAxrlX4Fc11ZXmEh9MxfVRNddlkY+JwxyTgPab+9X9eMjvvg2LeVkwqmbvYPUli7W/uVl/2aLj4eAUBkTM++kWNnG5ScpECvur02zofqSH2D4vgDuCCZaH0DZOSee1zB5H5hqElEvc85DnYWGcBzHA+S40dtWr3mz96lAoMsBUpv9PbSaKOcGmo5RLZbHADbOdGDHDf22bmaFxiUkhVkYNuan11yhco8fhvM2GV7VDf5AIbnvlUX8gv80aWfHiL5OYKfxLhPNAGInZ0NCKaNPhOjBlWyywbaqTU0ws7THbQ60HTqdwFfOPYhroTiVCZpq3Xd1z7w1pMbNBvTFqbEF8M6pAFT1vCHfBWehcdE/f4bP294WWnzR3ipGvnafCv+MCQxqWbVJGUuXehwXselAeDzstk3wXV5DMhT9MsWKGwHPgSveU0= X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2192; 31:FMv3uKTOi6GEjogW7pn2q6f4r6ccLDI1mtQ90Gn6rBeBM5bY0paITrXWDPKhRRcSKqnihPoxZvei7JnLaYjFhiDhsj/A8kBss9Y41blylb9itzHjwXCMzdaXbV1LeJN5yxT3pgzcsP7LpZHAJhKyLLQ5Lbm+bS9MNClpi7162+FyBKh3z51wwgI2jkbRB14iFfWtDoYZre167qtM5YbcQ1dyM8JRlSQtb7RJpfvLL9MQ8tuFHnWz7EgRY7yM/tCB7ycP1Lle6p+Kp9/S7mL8EdhgwoAtEbWZKXAwLWR5Tu8Ph9QUvdsniT0srcKFilYVLnFVGjxRGSJrOnhtwXeUC01t99LdUgdb3Kk6PFvSL0CuQZeWOz/5zFNdfHuCRJtTTAGe0oNduWYamvuR27siyjTrnttbW86tHO2rykh8xAeY4wnrnEiUtYmwB6Vu0GULGeQ0yM6jqU9X5KqpPo04+BIVwrbI44fixFwppTJFsN+QnqYPxDRHn9PqdF+gOJ8EgSaS7AxlQWlPRnWyoySNI45vyJO0GdqoVbfHdgSJZLM++f7h5h8tknrpbxnjtJALcQKKHN/LuuCJXWS0JEZIuAv7tAr+L+0Ln6JFYT7yj5Avo8EJPlplrfjJpUvPByvN2vcKKTiv7T/gPy9CfEWWKpAWC0PI2lzkIkO9ZgzEAjk= X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2192; 20:raAbjKI4i3xpTte1oXx6FriglzYByxzdTSXWez76paqwD/jyRRoPZj+3SycyH6Mt7PUdBKWplXUVo/o15tW9hWN83x32QfKBtHVDjPeaP1eRvqI6ETVmyjZxgHoBY2/y8fVL6yKPPTmuvravr0g22FCVJLHQ9r87VXyf3FCY+dGcUv0U2K0iy3iIsF3TOJy9v3obrazEPkeZwTjAk5s8NA+x7zC6UAbUDnVRqstaaTwPL3agaGte3po7k3tBBK02osZgqmKhchQkYFBlzcxlIXF8LYNeMwNSirw2FzthiF9RE9Lu2er4p0LavPmSQrHbhCzKaMe78JrZXsZuQ3Ml6KxLdwYhj7n9SMq2TyHTQGA1j6qUmV82643XXrKEzni/tnQrcyEJmOKsIrH+NF8HLBuyMrSw0yppvg2jjwf7s1yjSbrrKdGGmZ9p2C2jC7vexgh3BOfyQJwqIIOpTNkChaMqp4bO3vyccXzodRafFt7RXTtbX9OJvanKKUrFo105EiKt+AndhAhyQHidsBMFeRNa6I9vJX/VMC3rLcl9vaZhFeWaLwwn42Z/hk/XXMZJkcdGj7aIITt+inZMgKO3uE3hk1hfvikmxe1siMReUh8= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278178393323532)(236129657087228)(18271650672692); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123560025)(20161123558100)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN1PR05MB2192; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN1PR05MB2192; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtTTjFQUjA1TUIyMTkyOzQ6a3RVamtVSDdxdGppdFVJemZEbEVJKzVMU01F?= =?utf-8?B?MkRKcHhGc2FKdlJYTWlLS1RNWi9qeDZPclN4Qkh6dWozU0NuNUZkbTBMTTkr?= =?utf-8?B?dnA3dWUxSHp2WVp6ckFvZ3laL0lxNnZIR3JsLzNDZklnL1YrWUFicmpEcmk0?= =?utf-8?B?OU1MSUFkbEowMzUzRkE3d2tYSkdRRVdFMUJLcmt6Vm1SdjkxMzVKNTFGd2xJ?= =?utf-8?B?RmdpcGkxVWw1RzJoZ3REVnJMMUM1T1oyNHdxd0c2RW9QU1dEalhzdlBpU3F4?= =?utf-8?B?K1FVQ3hXcnB3bFBFZkZvNnlZdjRZb0ZGNmF5elBkN0ovNU9WUk5aVFpNNXZI?= =?utf-8?B?NDZaUU1XaFhtRWlzVkd3aVBSd3lQeXN2N2NLeGpJcVNNaHorcXBSMzYwQWhv?= =?utf-8?B?L21wN0FaZDJpYUlvL1BReU9USXBoUlUzWEw5dkd6cW1lKzZseUVXWjExRUww?= =?utf-8?B?OVJBVlR2cVlOV0NNNHFhYUlFTzVoYWJudGZSbXpsTHMxQjJMbUdob0p5UGgz?= =?utf-8?B?eGllUTFCVTRoTHJjQ0czemUyMkQ0NExIR3VDMWNmNGxFdURKYktoR3M1RDFW?= =?utf-8?B?WWlsWW5vTG5wL0xkMzZkVWFELzNNSm0ydEM5TGxZcENxUlZVTGF1Q214YzZR?= =?utf-8?B?YmtWWnVBSzhnbzU5TDkyMU9LTXB5VWF3dERGWk5PazYzbUlmZG9XY1ZyTVRw?= =?utf-8?B?QUJWNWNweXFGRVFERG5SOWZnMXRKZWRIRndiN09CNXFxVXpSL3ZnWmVqRkNy?= =?utf-8?B?b0RNMFUvNXFxOXhndGN0b3pEeHd2R0M2T0R5bS84dTlyb3Ezbk9ucGRLeGkr?= =?utf-8?B?eGZpZDNFZFZMNHMySkRtQ2VlT2ZJQlNRYnNobUQ0ZEpLL1hLUE5FUUlkYmlS?= =?utf-8?B?bTEvN3kzU3NHK3JaaGJLbFJXQzNmY2k0Y1lmNDVHTEtmZjhROGpHMlBkM25W?= =?utf-8?B?VWg0eDA5MGxHeDkweWZ4alN2YnliV0hzc3hyYXFVVU8wbDFINmhnRU5oZUV3?= =?utf-8?B?aVVZTUhhVUtMdVBrYWprdmdrL2VVOTg3a2RkT2NMRDgwaTYvWWZvVk1lR0dR?= =?utf-8?B?TDROdVJtZW1pSnpETXY0d1pZaURaTXIyajJrOWpCQlZjRmxOOEZCVno2TjRK?= =?utf-8?B?WnhFRUp6MjluT3RNZ1QwSnJzM25BNFpZSVZzWTd5Y2kzNGpQZW9TRGVxdUZr?= =?utf-8?B?dnJseUFWUDRRcU9xSUpoejliMzY2Q3NIOXI5VkxobzZOQzlvNDg2by8zcFVD?= =?utf-8?B?OEJyK2IxaTdXZFRUcEVXbExSZ1ppUWorTld6TkVCVTBVQU8rcW9jMWh6L0Fj?= =?utf-8?B?MmUyTlRkUU5tT1ZaTzFDWE1kODhOZ2hObTRvMWRGZ1ZmVk5PdUVuUUwva3pY?= =?utf-8?B?dkU5YXU2UGVhWnpQem9ISzhiYVVmRSswVG1rOXJVTHhNanh5ckx0MXE4OGk2?= =?utf-8?B?WXFPbHlUQk1FbEI3aTQ0ZWtkVFRObEIyZzBrYy93cjVmYUt4ZXFaVVF6TFpr?= =?utf-8?B?SWE3VS9RZGQvcUdoek9GSG5ZUXFTMDdPZENmM2wyaHFzWUZtdlBEQks0dVZx?= =?utf-8?B?S3o5YWtublcvNHpEbVAxVTVsOE95ZTdTRW1OaER5Z2k2bnRGbWU3aWFaL1BZ?= =?utf-8?B?ZmtDWlRTdmtXZ0pJZGxtQ080a0tJU2R4UWZTYjdlV0VWWldmV1kydTNMSkE1?= =?utf-8?Q?+2D0yGjB0hoV73AKHTwiysrVcJEg9stG2EATZp?= X-Forefront-PRVS: 03607C04F0 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(39400400002)(39850400002)(39860400002)(39410400002)(39840400002)(39450400003)(24454002)(377454003)(6116002)(2950100002)(33646002)(64126003)(90366009)(230700001)(6916009)(66066001)(6666003)(83506001)(50466002)(305945005)(229853002)(4326008)(47776003)(53546010)(23676002)(3846002)(31686004)(230783001)(86362001)(25786009)(966005)(3260700006)(2906002)(5660300001)(54356999)(38730400002)(53936002)(6306002)(36756003)(42186005)(189998001)(478600001)(6486002)(6246003)(50986999)(7736002)(77096006)(81166006)(31696002)(110136004)(2501003)(8676002)(76176999)(4001350100001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR05MB2192; H:[172.29.39.5]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtTTjFQUjA1TUIyMTkyOzIzOjRiZXdGa0diVXZ2VmViRWM0NG9zTGJUVkVv?= =?utf-8?B?REE1bi9XbnRKaG80TnVpZDJETXF2NEZ1cnB5NjBsNEZmaDhtVTIwZGgwOG0w?= =?utf-8?B?YWhKK3pEUUpCcnZRRWVWT3VVbVg4cGIvQ01zeHpuWnpwUjdUcGpZcDljYXlP?= =?utf-8?B?bGJ2R29RbTIydFJOZm91SnNuWEZ3cUYva0JxOEQ5bVhLVDhxQXRpeFBvNy8y?= =?utf-8?B?M1VXUWpWVC90NGVZSWJ1TFI4ckN6TGNEUXNrM2kwS0NvUE1iT01WcG9rYlBn?= =?utf-8?B?UnZsbzdVdC9SQzNYODZJR2Y0c25YSUxkRTNmS3FOVkxGU0tIaVBuVmFmREZo?= =?utf-8?B?SjlDa3dpVjZDYUhta1VsTzVHOUwrQWhTL1dqTzFyMDRCRkZmNzhlbVVoQ0Mz?= =?utf-8?B?VFZMaDVma2ZvNGsyUUx3Zk1xbXg4L3JwRmY2M2xNbzFtckJzLzdEa1NaMEp0?= =?utf-8?B?M1pVYkMrd0c5bExTRGIwRnE2SlYwTGYzMDRkd2VQeGhNaHJtSmtVMVYwTHB1?= =?utf-8?B?MUU3RnJnZUVBQXlybDlhNkFXWTBJQVlCdjBjQlN4TnRRYTdhYkRubklha2Zz?= =?utf-8?B?RmtBSm1nOUxvTjFnSlgxYXVnMUZzMnRpUGI0aXo1ZEt6Z0taSGpHdW83VEhm?= =?utf-8?B?cDJ1SzNvL28za0x1aUdtWUVXS3NhM1JkcE9NWEJWNnFSUE9ULzlORVZESWZR?= =?utf-8?B?d1lyTCtTMHh0TDBUZGRpdXpnbHZiL2J4YjdpendjQi9wd0lUZTQ3NzBsc1g1?= =?utf-8?B?a2RtNWNNbmpLNytXT1BSQUdqN3hJb2tEc1Q3KzVWbG9wUklYQTNqa1c2RGp0?= =?utf-8?B?d3VzUEk0TzM5MnY2WmhaeGU2LzJaMnhGS0UzbWVwd045a2RpMlJ0SEVxQlJ3?= =?utf-8?B?ZlhYZ3FudnVFZTBKUTVXeEdnVlg0Q1RhQkZtZ1ltTGpLOUhpVTBLUkd4MnQ3?= =?utf-8?B?QzMyTG9JYkVrdEQ5czJDSUZ1WVJ4TC9zdi9BTjBLMUtzM1ZTQ3l2MTZQTnZO?= =?utf-8?B?WjA3a1ZTQ1cyWlkwZTE2UFFXV2YxQUFHK3Q3dzJ1N3B4cW1nQi9wRUowQkN3?= =?utf-8?B?aS9yVTUzRUdHdXZ6c2V0L21GakVpYTlVREhvckVQcmVYUitSTUd2UFJTZ0d1?= =?utf-8?B?aFk1dTFuZE1YcGJpa240RDBTeUt5MzlVdXB2L3l3dEZDNEdoczIwWmJZWXlK?= =?utf-8?B?VlZ5am9qbGZ2eXNwWDNVM1lqK3VySmNSdzJENWNaRlJQM1BWUGg1aHhFSjcz?= =?utf-8?B?SkQ2dWpoUTk3T1VjUmtmMTVBc1ZPeU5pazg0YU8xeWt6djhtSnVQL3dOTkxE?= =?utf-8?B?akgzNXhCNEZDSDFSSnFPanR6dlFDaE5uZmFnZndaTXZzUlJHN2p1RERKdk9y?= =?utf-8?B?VmhQVzlBZktTKzhBL0l2ZTVLZDh5c2tMMlRnT2k2MklTbm82alpXZmRNK0pp?= =?utf-8?B?LzhTT3NhN2RnTjBORmVDbThpcitSU0c1MUp0RjJtdzNRWG52UGVBeXVVVW83?= =?utf-8?B?RDRYakRLSkhGZ0JnZGg0Z0hsWUgrbmF1ekFBS1c5Z0RRTjA0UVQwT1I1cTk2?= =?utf-8?B?VlJDNHRlVGNyS1piajZGWTZQdnNzQU1uS3VMc2FNYUo5ZmdaMTdGd0FBSFlt?= =?utf-8?B?QVBuTTJtNWxiY1NOdDN5TjlEWi9jNWQwWVp1REROK05qWmVXYlA4T25VZE5H?= =?utf-8?B?dWExZmV2ZjZMUTZWMXVWSHliYTE1Z3UrdjdVSmtOMFN6NVBMZW9pdENzYlZh?= =?utf-8?B?bDBDNzVEOVRxUUdLRGRLMFh4OHV5U1YvYys0ZWR3UTVPOWMrY0s1VFprN0JB?= =?utf-8?B?eWFIRnpPaTV1U0FGNktsb0d3UVdiRkY4VE1CSEs1R2F5WVhkdkMvVXBTNHJk?= =?utf-8?Q?JOm4Eq7lpw226lBp2yQXzeDH4LfD4Lgb?= X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtTTjFQUjA1TUIyMTkyOzY6WGlxOUU1Wm14V3g5Y0JCTko3bWN5QTRVbytY?= =?utf-8?B?MUd0enJlNjZCQnUraEVaY1cwWkc1aUk3Tkh1Vld6a3Y5Ri80VlJyY1VwNzZk?= =?utf-8?B?YjZWTXh2WkpQVGhYT0k0SXpnV0tTZURNUTBpUmdWM2pXTi9LS3BIaEM1WUtt?= =?utf-8?B?UVBpWURaWW50RDBnSjlvSEN6ZjlHZi9meEI2SXJCSm16Vndia0VvdnVPK1BE?= =?utf-8?B?d2ExL3QybXlmanFTb0k4OXI0bDdKV0NndS9GUVlGc1AwQmZPTWNxU295RFRq?= =?utf-8?B?UGwwRUZTYkhwQVhXUzVHeUtVbnBYdnd0d3BFMG00MGxPWVEvbkVNMDdXUXo2?= =?utf-8?B?eXdINmNsd1paQTBvQmQ5cTJXOGxuMHlPbFNZU3IySENUK0d4UFd1bTdidUlq?= =?utf-8?B?NXpQZTMyaUkxUlhsMCtMNTZCSVVDVXg0OXZrSlFFR2VKSmRrbGtoWlV6NFVv?= =?utf-8?B?WnpUcFB0NHRlanJrQ0tvSDRDVm4zVTJwV2pyVWlETTBtVVdZT3FJTmc2MHFs?= =?utf-8?B?ay9JV0FFRldLV2Y2WVMvMDhrRVRnWWhaU1YzM2JKbG1RaDhxWjBid2tncjdY?= =?utf-8?B?K1hXWDJDSTNPZ2JuNE0rMmVOLzRuNVkyL3Ixc3h2QitXckVGTW5HM05Nd3ZS?= =?utf-8?B?dnhPdm1nQ1l3UTh2azFoRWw0YVVia3BkbmVkN0VzZy9MQTkzZ1l1QWptV3ly?= =?utf-8?B?UXlmNDdrRXRDRUJONkZITGl4OFZsK1N5UkNyWmhCZGxuclVBNnJ6NllPZng4?= =?utf-8?B?aGgvT1kzY29MNkd3SmNEY3lBQ05PTHdrTTQ3ODcrTC9MbWtGWkZmZHZ2N0xG?= =?utf-8?B?WE5SVFRJc1NzU0dWR1h4Y1dqZHdkbGxEeU9qUnZTQzBRZmh5ZDhSZ0ZrdmJZ?= =?utf-8?B?ZWc5V1lMQ3lESzhBbFBzNmhiV3Ivc0JhRnhwbHhUcTd2S3FBWXpHcThRcnYy?= =?utf-8?B?am5sYTJOY09qR2Y1Mng2VHQ0TTFuOVIwaHZudzBWdHE5cURyd0l4ckFkNW5V?= =?utf-8?B?cVUxWDZlZlBEbEdRcHcrdEIrVWk4SXNIa1FmSE5Md0x5OWhSZUhoalFhakty?= =?utf-8?B?YzNEMmxxMnRNZkNWaHZLRUxwYk1tY2RRSUF2eXJITTJrQ1h4Tm9jWVdWSHJj?= =?utf-8?B?YTZVUE9taXhZdzB5Q01QWUZzT09OVnViLytnVmtjRk8vMVNYZmM3RWNYYXU1?= =?utf-8?B?aTV3ZEVscDJKVm12ek1oVm42ZVl0ZTF5RUtKT3pWaitRd0dteFJ5NFY4ZXhB?= =?utf-8?B?ZDEzZnlYZE8zY2pabUcxN2tOMTZrOW1jelB0Q0FKWHp1V2l4V2dzNjRTa0Yw?= =?utf-8?B?OFM2aXRoUjlISjhBdm9ucXp0NFlKYVpkZkxHWEpYT3Rrbnh4UWFlN3RzM3NF?= =?utf-8?Q?cuwF2bR?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2192; 5:JrRZ8qKEV3LdgP5qlj6EWjorvfOiv/DT80AxZR40K+cwmAlFRj7CTuu/P+ZHk5C6xEjFOUijXkXCmoiE6CpHUNalzfMTRpXeTo5v1KCpfQ4cJoOOsKR2VFkO0kKxogaO07BpkD5X6PLXkDMC2cfkuYaDAxDWgffJVbATO5VCksW7pHL3gQe7Wpyyq9W6cywOIg+iMofUZk4tIhyhMeppdrRLgTx7Ukg0fudswHqj10Qpm2PBAh/gakKYkXZjf9g9zDz/aTtKxunOZ706kT9W6C+UfQVwwOFuzVHW0cq8he5IZR/4Yztkzl7jgOib8crYOxr/3fEYPJbK+gvJ0+NKur37WQloWeTNnfGV4FmPk9lJxvKd/mwtzvxCx5pmg/b/hbgkwasEUrnpMmgp+NtULT4fhv+Ecg3Pjwwm2RJGXRgHdRQvjTqU1EWmnnrRMPi+JJp8L+NSdBcuA/+dTFt0m/bvHa7ZJF3rJg61X538dB8sRca/WhFDtY4lwcARx9Eh; 24:RJ8kUxAsvA9v1/Gu7Pg5MWz/CtbYFe3DKy42t3r15kYDpMQf2Io5F083EYmLLCNT9d+gdOj619TXrn3Qy7ywJRsx12uoIiVNDEMqXpIJB2I= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2192; 7:7r93VUPTG4yHUFEU/TTgKBAN1VmG7Pd4E76SQdxQ3q7G+6mZWi+fWFVj/Wd+G45ZuRAcgoDGJWpNq59q3NNVscpUNuioA1ffEQ7eW3rAn3HpEXt5jDZXSQy4jXeQjA5CafRB//QDA/wTGHylkz8W4hYBJm0MTJugmbkvd0STvlc2AO0trLW/MG/m5K7Y1w4Ut1Hi+Bb/JTxCd6mQnw53Y8RrLCzF6wgI7svHGSordxV60NFoeLX84bkDE4qnSGx2Z7O/A6VirvuKLZq20uLYiduJ8FxCeG3OtuPxD8H3jWnKlCF78Y8jciluGW0XgXFBtKnv4syON03hh8R5rbC+gI0dCy1d288RiPgUZkhC6MoTtmHfh1bh2lEuT5nwnERN0rZPQjOf+meRFdz7BSKKNRhPdO8223cNkeDrPiU0B3cO8CiyAPu8HgGty2XUu/ws3arBQJ9uqZzS93D0rMq29HqBRSm6zHVxOn1TkU+9ZDeDUYc2jEjsG94nADwAGs6qafNstKTkV9qzpyDww6K4XmBKcxcjtIHL4vYiRfggJqCmRhydiFoxFLbZClyCjDwqDpZ//3MWBBXDqzZQxUwloi3FedzaLwRqahQfU/rPlIcETSrnABkjH0EvbaPFfzEVoZwbAfMoY9/vFVwDxM5Y6G1SAZQ0tsOyKuFJvvOKkorWI3letqdb3cjY9+srxSlyp6xdvg8ygkL8zxkL0OU0zrm74GEPgJFPgBN+WucAyC7CCeJ3v6WG+7XDde8uXpzmHlhDeut4AQoCEnbCesR8HzXoHZNIXhbz4xUH+pfxyr8= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jul 2017 16:49:17.2953 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR05MB2192 Archived-At: Subject: Re: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 16:49:22 -0000 On 7/6/2017 9:03 AM, bruno.decraene@orange.com wrote: > Pseudo-randomly parsing the draft, I may have a comment on section 3.2.5 (GTP) > https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-06#section-3.2.5 > > " Local TEID: Contains a 32-bit Tunnel Endpoint Identifier of a GTP tunnel assigned by EPC ([vEPC]). > > Local Endpoint Address: Contains an IPv4 or IPv6 anycast address. > This is used, along with the Local TEID, to set up a tunnel in the > reverse direction. See [vEPC] for details." > > It seems this should make [vEPC] a normative reference. For RFC publication, this may be an issue as this draft looks like an expired individual draft. May be another, more generic, document could be found to specify the usage of a GTP tunnel. It might be better to delete the section on GTP; the authors of [vEPC] can then incorporate the deleted material if they decide to revise their draft. From nobody Thu Jul 6 13:22:33 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 226B41316AC for ; Thu, 6 Jul 2017 13:22: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 J0v_hiKh40w1 for ; Thu, 6 Jul 2017 13:22:26 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CC3E12EC55 for ; Thu, 6 Jul 2017 13:22:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7066; q=dns/txt; s=iport; t=1499372546; x=1500582146; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2nH746f6DzXXVyhbG6cZUK9t4Y+etJbIWZU0E4WnVOA=; b=W82eroZN/u5XaCccHp2eetKJKwrsUWB0Bz3h7IUREP92KFCB/U0rauw+ 0/2l2rgBbjWEV7stgeRRNnUj2Qd+ez8Zt4ukyQnj3HRV13roaRlXL0coH x8Vkb+mlVPH/XnvG+uGUMTEcDz5IWpHyLkY5srxk5xxcBJLazwTEUPAyj A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DdAAC5m15Z/40NJK1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgm9qY4EYjgKiPoUsghGGHAIagxU/GAECAQEBAQEBAWsohRkGIwpMEAI?= =?us-ascii?q?BCA40AgICMCUCBA4NiUNksHiCJoszAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYMng?= =?us-ascii?q?0yBYYMkh32CYQWXLodhApN7kieVNwEfOIEKdRWHX4hbgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.40,319,1496102400"; d="scan'208,217";a="264575513" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Jul 2017 20:22:25 +0000 Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v66KMPp4005794 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 6 Jul 2017 20:22:25 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 6 Jul 2017 15:22:24 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Thu, 6 Jul 2017 15:22:24 -0500 From: "Jakob Heitz (jheitz)" To: John Scudder CC: idr wg Thread-Topic: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt Thread-Index: AQHS9BUunfHRezzCokubhqS6qWLW+qJCmLwAgAADHACAAAV9AIAAEJgAgAAELwCAACXgAIAABdiAgAAGlwCAAAS/gIAAAluAgAADsICAAAI9gIAABIMAgAAG2ACAANELAIAAVbOAgAGER4CAABuWgIAACY6A///raUCAAL0bAP//txnAgAEO71A= Date: Thu, 6 Jul 2017 20:22:24 +0000 Message-ID: <4d8bd5d458db4427a72c15a5ae94cda7@XCH-ALN-014.cisco.com> References: <20170703175308.hembxkplaniz66wb@Vurt.local> <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> <09BFF794-6899-4DA5-8EF5-DDF86513BFBA@pfrc.org> <20170704104840.mg5bflnmmjlv4jbi@Vurt.local> <20C02BA3-5C13-46FB-AFE8-85D61E469EA1@juniper.net> <1FD8FAE9-E6BF-4C48-BCD6-12C1012827E2@juniper.net> <696fbda3aa2b4af9b0fc8f4757e7b541@XCH-ALN-014.cisco.com> In-Reply-To: <696fbda3aa2b4af9b0fc8f4757e7b541@XCH-ALN-014.cisco.com> 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.43.213] Content-Type: multipart/alternative; boundary="_000_4d8bd5d458db4427a72c15a5ae94cda7XCHALN014ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 20:22:30 -0000 --_000_4d8bd5d458db4427a72c15a5ae94cda7XCHALN014ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGRyYWZ0IHByb3Bvc2VzIHRvIGZpbHRlciBwYXRocyBmcm9tIGJlc3QtcGF0aCBzZWxlY3Rp b24NCmJhc2VkIHVwb24gbmV4dGhvcCByZWFjaGFiaWxpdHkuDQoNClRoaXMgbG9va3MgbW9yZSBs aWtlIGEgbmV3IE9SRiB0eXBlIHRoYW4gYSBTQUZJLg0KU0FGSSBpcyBmb3Igb25lLXRvLW1hbnkg aW5mb3JtYXRpb24uDQpPUkYgaXMgdXNlZCBmb3IgcGVlci10by1wZWVyIGluZm8uDQpJdCB3b3Vs ZCBjZXJ0YWlubHkgbWFrZSBpdCBlYXNpZXIgdG8gd3JpdGUgdGhlIGNvZGUgZm9yIGl0DQppZiBp dCB3ZXJlIGFuIE9SRiB0eXBlLg0KV2VsbCwgMjogb25lIGZvciBSZWFjaFRlbGwgYW5kIGFub3Ro ZXIgZm9yIFJlYWNoQXNrLg0KV2FzIHRoaXMgY29uc2lkZXJlZD8NCg0KDQpUaGFua3MsDQpKYWtv Yi4NCg0K --_000_4d8bd5d458db4427a72c15a5ae94cda7XCHALN014ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ikx1Y2lkYSBDb25zb2xlIjsNCglwYW5vc2Ut MToyIDExIDYgOSA0IDUgNCAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNp bVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0 aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1h bDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWw7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjojNzAzMEEwOw0KCWZv bnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDsNCgl0ZXh0LWRlY29yYXRpb246 bm9uZSBub25lO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6IzcwMzBBMDsNCglm b250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7DQoJdGV4dC1kZWNvcmF0aW9u Om5vbmUgbm9uZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWlu IDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBBMCI+VGhlIGRyYWZ0 IHByb3Bvc2VzIHRvIGZpbHRlciBwYXRocyBmcm9tIGJlc3QtcGF0aCBzZWxlY3Rpb248bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNzAz MEEwIj5iYXNlZCB1cG9uIG5leHRob3AgcmVhY2hhYmlsaXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM3MDMwQTAiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OiM3MDMwQTAiPlRoaXMgbG9va3MgbW9yZSBsaWtlIGEgbmV3IE9SRiB0eXBlIHRoYW4gYSBTQUZJ LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOiM3MDMwQTAiPlNBRkkgaXMgZm9yIG9uZS10by1tYW55IGluZm9ybWF0aW9uLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM3MDMw QTAiPk9SRiBpcyB1c2VkIGZvciBwZWVyLXRvLXBlZXIgaW5mby48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNzAzMEEwIj5JdCB3b3Vs ZCBjZXJ0YWlubHkgbWFrZSBpdCBlYXNpZXIgdG8gd3JpdGUgdGhlIGNvZGUgZm9yIGl0PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Izcw MzBBMCI+aWYgaXQgd2VyZSBhbiBPUkYgdHlwZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNzAzMEEwIj5XZWxsLCAyOiBvbmUgZm9y IFJlYWNoVGVsbCBhbmQgYW5vdGhlciBmb3IgUmVhY2hBc2suPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBBMCI+V2FzIHRoaXMg Y29uc2lkZXJlZD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjojNzAzMEEwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNzAzMEEwIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtMdWNpZGEgQ29uc29sZSZxdW90Oztjb2xv cjojNzAzMEEwIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtMdWNp ZGEgQ29uc29sZSZxdW90Oztjb2xvcjojNzAzMEEwIj5KYWtvYi48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0x1Y2lkYSBDb25zb2xlJnF1b3Q7O2NvbG9yOiM3MDMwQTAiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_4d8bd5d458db4427a72c15a5ae94cda7XCHALN014ciscocom_-- From nobody Thu Jul 6 13:36:55 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1DB131448 for ; Thu, 6 Jul 2017 13:36:53 -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 WM86giMrGAz7 for ; Thu, 6 Jul 2017 13:36:52 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC401129A96 for ; Thu, 6 Jul 2017 13:36:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9560; q=dns/txt; s=iport; t=1499373411; x=1500583011; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=HIjamDLY68zaJaqvrQYzR0qxsHW8ejRTxPSLgQpYl5o=; b=gO/M2Iv2wkWUjsRYA0h5pty4iJMoIHbk0MFCIQLS2UtMTix3EfH+HlPy H/0CHi4XKsF98mWmQ44Gv0WzOpWaEkFMMYTh6Ie9M0vN1SAcZmIWVtMx5 YBHmR3z0EsEEE14QA94dMizP/+GLGcy4ZRSZcZb+7NgATuYNLjLuXVmv6 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DdAAD9nl5Z/5FdJa1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgm9qY4EYjgKiPoUsghGGHAIagxc/GAECAQEBAQEBAWsohRkGIwQGXAI?= =?us-ascii?q?BCEICAgIwJQIEG4lDZLB3gWw6izQBAQEBAQEBAQEBAQEBAQEBAQEBAQEdgyeDT?= =?us-ascii?q?IUFh32CYQWXLodhApN7kieVNwEfOIEKdRWHX4hbgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.40,319,1496102400"; d="scan'208,217";a="446304236" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jul 2017 20:36:51 +0000 Received: from xch-rcd-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v66Kao8P012301 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 6 Jul 2017 20:36:50 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 6 Jul 2017 15:36:50 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Thu, 6 Jul 2017 15:36:50 -0500 From: "Jakob Heitz (jheitz)" To: idr wg Thread-Topic: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt Thread-Index: AQHS9BUunfHRezzCokubhqS6qWLW+qJCmLwAgAADHACAAAV9AIAAEJgAgAAELwCAACXgAIAABdiAgAAGlwCAAAS/gIAAAluAgAADsICAAAI9gIAABIMAgAAG2ACAANELAIAAVbOAgAGER4CAABuWgIAACY6A///raUCAAL0bAP//txnAgAEO71CAAAQWUA== Date: Thu, 6 Jul 2017 20:36:50 +0000 Message-ID: <8620abbfc6444433b950c4a748fa2fed@XCH-ALN-014.cisco.com> References: <20170703175308.hembxkplaniz66wb@Vurt.local> <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> <09BFF794-6899-4DA5-8EF5-DDF86513BFBA@pfrc.org> <20170704104840.mg5bflnmmjlv4jbi@Vurt.local> <20C02BA3-5C13-46FB-AFE8-85D61E469EA1@juniper.net> <1FD8FAE9-E6BF-4C48-BCD6-12C1012827E2@juniper.net> <696fbda3aa2b4af9b0fc8f4757e7b541@XCH-ALN-014.cisco.com> <4d8bd5d458db4427a72c15a5ae94cda7@XCH-ALN-014.cisco.com> In-Reply-To: <4d8bd5d458db4427a72c15a5ae94cda7@XCH-ALN-014.cisco.com> 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.43.213] Content-Type: multipart/alternative; boundary="_000_8620abbfc6444433b950c4a748fa2fedXCHALN014ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 20:36:53 -0000 --_000_8620abbfc6444433b950c4a748fa2fedXCHALN014ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGRyYWZ0IHByb3Bvc2VzIHRvIGZpbHRlciBwYXRocyBmcm9tIGJlc3QtcGF0aCBzZWxlY3Rp b24NCmJhc2VkIHVwb24gbmV4dGhvcCByZWFjaGFiaWxpdHkuDQoNCldoeSBzdG9wIGF0IHJlYWNo YWJpbGl0eT8NCg0KQSBjbGllbnQgbWF5IG5vdCB3aXNoIHRvIGFjY2VwdCByb3V0ZXMgZnJvbSBh bm90aGVyIGNsaWVudCwgYmVjYXVzZQ0KdGhleSBkb24ndCBoYXZlIGEgY29udHJhY3Qgb3Igd2hh dGV2ZXIgcmVhc29uLg0KQ2FuIHdlIGluY2x1ZGUgdGhlIEFTTiBvZiB0aGUgbmV4dGhvcCB3aXRo IGVhY2ggbmV4dGhvcD8NCg0KT3RoZXIgcG9zc2libGUgcmVhc29ucyBmb3Igbm90IHdhbnRpbmcg YSByb3V0ZToNCi4gVGhlIEFTLXBhdGggY29udGFpbnMgYW4gdW5kZXNpcmFibGUgQVNOLg0KLiBU aGUgb3JpZ2luIEFTIGRvZXMgbm90IGhhdmUgdGhlIHJpZ2h0IHRvIGFkdmVydGlzZSB0aGUgcHJl Zml4Lg0KLiBJIHByZWZlciBhIGN1c3RvbWVyIHJvdXRlIG92ZXIgYSBwZWVyIHJvdXRlLg0KLiBU aGUgcm91dGUgaXMgYSBsZWFrLg0KLiBFdGMsIEV0Yy4NCg0KQ2FuIHlvdSBwdXQgdGhlIHdob2xl IGF0dHJpYnV0ZSBzZXQgaW50byB0aGUgUmVhY2hBc2svUmVhY2hUZWxsDQpyYXRoZXIgdGhhbiBq dXN0IHRoZSBuZXh0aG9wPw0KDQpIZWNrLCB3aHkgZG9uJ3QgeW91IGp1c3Qgc2VuZCB0aGUgY29t cGxldGUgcm91dGUgLS0+IEFkZC1wYXRoLg0KDQpUaGFua3MsDQpKYWtvYi4NCg== --_000_8620abbfc6444433b950c4a748fa2fedXCHALN014ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ikx1Y2lkYSBDb25zb2xlIjsNCglwYW5vc2Ut MToyIDExIDYgOSA0IDUgNCAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNp bVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0 aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1h bDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWw7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjojNzAzMEEwOw0KCWZv bnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDsNCgl0ZXh0LWRlY29yYXRpb246 bm9uZSBub25lO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6IzcwMzBBMDsNCglmb250LXdl aWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUg bm9uZTt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOiM3MDMwQTA7DQoJZm9udC13 ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsOw0KCXRleHQtZGVjb3JhdGlvbjpub25l IG5vbmU7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM3MDMwQTAiPlRoZSBkcmFmdCBwcm9w b3NlcyB0byBmaWx0ZXIgcGF0aHMgZnJvbSBiZXN0LXBhdGggc2VsZWN0aW9uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBBMCI+ YmFzZWQgdXBvbiBuZXh0aG9wIHJlYWNoYWJpbGl0eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNzAzMEEwIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNzAz MEEwIj5XaHkgc3RvcCBhdCByZWFjaGFiaWxpdHk/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBBMCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBB MCI+QSBjbGllbnQgbWF5IG5vdCB3aXNoIHRvIGFjY2VwdCByb3V0ZXMgZnJvbSBhbm90aGVyIGNs aWVudCwgYmVjYXVzZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOiM3MDMwQTAiPnRoZXkgZG9uJ3QgaGF2ZSBhIGNvbnRyYWN0IG9yIHdo YXRldmVyIHJlYXNvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjojNzAzMEEwIj5DYW4gd2UgaW5jbHVkZSB0aGUgQVNOIG9mIHRoZSBu ZXh0aG9wIHdpdGggZWFjaCBuZXh0aG9wPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM3MDMwQTAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM3MDMwQTAiPk90 aGVyIHBvc3NpYmxlIHJlYXNvbnMgZm9yIG5vdCB3YW50aW5nIGEgcm91dGU6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBBMCI+ LiBUaGUgQVMtcGF0aCBjb250YWlucyBhbiB1bmRlc2lyYWJsZSBBU04uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBBMCI+LiBU aGUgb3JpZ2luIEFTIGRvZXMgbm90IGhhdmUgdGhlIHJpZ2h0IHRvIGFkdmVydGlzZSB0aGUgcHJl Zml4LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOiM3MDMwQTAiPi4gSSBwcmVmZXIgYSBjdXN0b21lciByb3V0ZSBvdmVyIGEgcGVlciBy b3V0ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjojNzAzMEEwIj4uIFRoZSByb3V0ZSBpcyBhIGxlYWsuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBBMCI+LiBFdGMs IEV0Yy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjojNzAzMEEwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNzAzMEEwIj5DYW4geW91IHB1dCB0aGUgd2hvbGUg YXR0cmlidXRlIHNldCBpbnRvIHRoZSBSZWFjaEFzay9SZWFjaFRlbGw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNzAzMEEwIj5yYXRo ZXIgdGhhbiBqdXN0IHRoZSBuZXh0aG9wPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM3MDMwQTAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM3MDMwQTAiPkhl Y2ssIHdoeSBkb24ndCB5b3UganVzdCBzZW5kIHRoZSBjb21wbGV0ZSByb3V0ZSAtLSZndDsgQWRk LXBhdGguPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6IzcwMzBBMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7THVjaWRhIENvbnNvbGUmcXVvdDs7Y29sb3I6IzcwMzBBMCI+VGhhbmtzLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7THVjaWRhIENvbnNvbGUmcXVvdDs7Y29sb3I6 IzcwMzBBMCI+SmFrb2IuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_8620abbfc6444433b950c4a748fa2fedXCHALN014ciscocom_-- From nobody Thu Jul 6 13:37:25 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E45F5131882 for ; Thu, 6 Jul 2017 13:37:23 -0700 (PDT) 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, HTML_MESSAGE=0.001, 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 y91ZW9Mxp4ie for ; Thu, 6 Jul 2017 13:37:22 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 63408131850 for ; Thu, 6 Jul 2017 13:37:22 -0700 (PDT) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 2F55B1E333; Thu, 6 Jul 2017 16:46:39 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_B89D6095-B6F5-4A00-B7F6-51F089BD31F0" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jeffrey Haas In-Reply-To: <4d8bd5d458db4427a72c15a5ae94cda7@XCH-ALN-014.cisco.com> Date: Thu, 6 Jul 2017 16:37:20 -0400 Cc: John Scudder , idr wg Message-Id: <93357697-1F0A-462E-993F-6CDB7693418E@pfrc.org> References: <20170703175308.hembxkplaniz66wb@Vurt.local> <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> <09BFF794-6899-4DA5-8EF5-DDF86513BFBA@pfrc.org> <20170704104840.mg5bflnmmjlv4jbi@Vurt.local> <20C02BA3-5C13-46FB-AFE8-85D61E469EA1@juniper.net> <1FD8FAE9-E6BF-4C48-BCD6-12C1012827E2@juniper.net> <696fbda3aa2b4af9b0fc8f4757e7b541@XCH-ALN-014.cisco.com> <4d8bd5d458db4427a72c15a5ae94cda7@XCH-ALN-014.cisco.com> To: "Jakob Heitz (jheitz)" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 20:37:24 -0000 --Apple-Mail=_B89D6095-B6F5-4A00-B7F6-51F089BD31F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jul 6, 2017, at 4:22 PM, Jakob Heitz (jheitz) = wrote: >=20 > The draft proposes to filter paths from best-path selection > based upon nexthop reachability. > =20 > This looks more like a new ORF type than a SAFI. > SAFI is for one-to-many information. > ORF is used for peer-to-peer info. > It would certainly make it easier to write the code for it > if it were an ORF type. > Well, 2: one for ReachTell and another for ReachAsk. > Was this considered? I tend to consider this a bit more like rt-constrain than an ORF. I = accept your comparison for the peer-to-peer being a bit more ORF-like = than rt-constrain. I think my biggest bit of feedback is that ORF seems generally less = setup for "chatty" state changes than an rt-constrain like mechanism. = ORF still has a bit of the implication of "do a refresh to change = state", even if the results are incremental. -- jeff --Apple-Mail=_B89D6095-B6F5-4A00-B7F6-51F089BD31F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Jul 6, 2017, at 4:22 PM, Jakob Heitz (jheitz) <jheitz@cisco.com> = wrote:

The draft proposes to filter = paths from best-path selection
based = upon nexthop reachability.
 
This looks more like a new ORF = type than a SAFI.
SAFI is for one-to-many = information.
ORF is used for peer-to-peer = info.
It would certainly make it easier = to write the code for it
if it = were an ORF type.
Well, 2: one for ReachTell = and another for ReachAsk.
Was = this considered?

I tend to consider this a bit more like rt-constrain = than an ORF.  I accept your comparison for the peer-to-peer being a = bit more ORF-like than rt-constrain.

I= think my biggest bit of feedback is that ORF seems generally less setup = for "chatty" state changes than an rt-constrain like mechanism. =  ORF still has a bit of the implication of "do a refresh to change = state", even if the results are incremental.

-- jeff

= --Apple-Mail=_B89D6095-B6F5-4A00-B7F6-51F089BD31F0-- From nobody Thu Jul 6 13:40:36 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC291131882 for ; Thu, 6 Jul 2017 13:40:33 -0700 (PDT) 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, HTML_MESSAGE=0.001, 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 NMCdh8Dg9hV6 for ; Thu, 6 Jul 2017 13:40:32 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA9D131675 for ; Thu, 6 Jul 2017 13:40:32 -0700 (PDT) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 4CE641E333; Thu, 6 Jul 2017 16:49:49 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_FDEF7CD5-4419-4CA9-B28D-D21B7FA6B0B0" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jeffrey Haas In-Reply-To: <8620abbfc6444433b950c4a748fa2fed@XCH-ALN-014.cisco.com> Date: Thu, 6 Jul 2017 16:40:31 -0400 Cc: idr wg Message-Id: References: <20170703175308.hembxkplaniz66wb@Vurt.local> <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> <09BFF794-6899-4DA5-8EF5-DDF86513BFBA@pfrc.org> <20170704104840.mg5bflnmmjlv4jbi@Vurt.local> <20C02BA3-5C13-46FB-AFE8-85D61E469EA1@juniper.net> <1FD8FAE9-E6BF-4C48-BCD6-12C1012827E2@juniper.net> <696fbda3aa2b4af9b0fc8f4757e7b541@XCH-ALN-014.cisco.com> <4d8bd5d458db4427a72c15a5ae94cda7@XCH-ALN-014.cisco.com> <8620abbfc6444433b950c4a748fa2fed@XCH-ALN-014.cisco.com> To: "Jakob Heitz (jheitz)" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 20:40:34 -0000 --Apple-Mail=_FDEF7CD5-4419-4CA9-B28D-D21B7FA6B0B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Your strawman is about to file a domestic violence restraining order. These are not our use cases. If you'd like one, feel free to write a = draft covering those. The draft simply proxies information related to BGP's reachability = condition for a nexthop. If this was full-mesh, the game would be = different. If this was a RR, this would be different. The RS is = (mostly) exceptional in this case. -- Jeff > On Jul 6, 2017, at 4:36 PM, Jakob Heitz (jheitz) = wrote: >=20 > The draft proposes to filter paths from best-path selection > based upon nexthop reachability. > =20 > Why stop at reachability? > =20 > A client may not wish to accept routes from another client, because > they don't have a contract or whatever reason. > Can we include the ASN of the nexthop with each nexthop? > =20 > Other possible reasons for not wanting a route: > . The AS-path contains an undesirable ASN. > . The origin AS does not have the right to advertise the prefix. > . I prefer a customer route over a peer route. > . The route is a leak. > . Etc, Etc. > =20 > Can you put the whole attribute set into the ReachAsk/ReachTell > rather than just the nexthop? > =20 > Heck, why don't you just send the complete route --> Add-path. > =20 > Thanks, > Jakob. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr = --Apple-Mail=_FDEF7CD5-4419-4CA9-B28D-D21B7FA6B0B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Your strawman is about to file a domestic violence = restraining order.

These are not our use cases.  If you'd like one, feel = free to write a draft covering those.

The draft simply proxies information = related to BGP's reachability condition for a nexthop.  If this was = full-mesh, the game would be different.  If this was a RR, this = would be different.  The RS is (mostly) exceptional in this = case.


-- Jeff

On Jul 6, 2017, at 4:36 PM, Jakob Heitz = (jheitz) <jheitz@cisco.com> wrote:

The draft proposes to filter = paths from best-path selection
based = upon nexthop reachability.
 
Why stop at reachability?
 
A = client may not wish to accept routes from another client, because
they don't have a contract or whatever reason.
Can we include the ASN of the nexthop with each = nexthop?
 
Other possible reasons for not = wanting a route:
. The AS-path contains an = undesirable ASN.
. The origin AS does not = have the right to advertise the prefix.
. I prefer a customer route over a peer route.
. The route is a leak.
. Etc, Etc.
 
Can you put the whole attribute = set into the ReachAsk/ReachTell
rather = than just the nexthop?
 
Heck, why don't you just send the = complete route --> Add-path.
 
Thanks,
Jakob.
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

= --Apple-Mail=_FDEF7CD5-4419-4CA9-B28D-D21B7FA6B0B0-- From nobody Thu Jul 6 13:40:50 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F035131962 for ; Thu, 6 Jul 2017 13:40: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, 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 UM6FveZGMCA5 for ; Thu, 6 Jul 2017 13:40:42 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F59A13195E for ; Thu, 6 Jul 2017 13:40:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8238; q=dns/txt; s=iport; t=1499373642; x=1500583242; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gKOzAzrhAsb9SsB2gxi7sTRXqZWu6nP3rWOyYp9QlYo=; b=mu/1kLwUIk1+W1mHqXcF7QymYJBfsyy90um9lP7PvL4sjcyS9InMSjhm TCehgG+7EUBHOqy+4atpPr4lnViQOTB9cmorY2PHT747GsaAotrczyx5m lYl3QE0bv4ImgxltU/pxdQ4lYxMUe9RBbOXS+6JfuEoYmTpY/CYz11e7F Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CnAAD9nl5Z/5xdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9qY4ERB44CkWeQV4UsghGGHAKDMT8YAQIBAQEBAQEBayiFGAE?= =?us-ascii?q?BAQEDLUwQAgEIDgMEAQEoBzIUCQgCBA4FCIlDZLMdizQBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEdgyeDTIFhgySFIIU+BZcuh2ECk3uSJ5U3AR84gQp1FYdfdodlgQ0?= =?us-ascii?q?BAQE?= X-IronPort-AV: E=Sophos;i="5.40,319,1496102400"; d="scan'208,217";a="446305789" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jul 2017 20:40:40 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v66Keeap004897 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 6 Jul 2017 20:40:40 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 6 Jul 2017 15:40:39 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Thu, 6 Jul 2017 15:40:39 -0500 From: "Jakob Heitz (jheitz)" To: Jeffrey Haas CC: idr wg Thread-Topic: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt Thread-Index: AQHS9BUunfHRezzCokubhqS6qWLW+qJCmLwAgAADHACAAAV9AIAAEJgAgAAELwCAACXgAIAABdiAgAAGlwCAAAS/gIAAAluAgAADsICAAAI9gIAABIMAgAAG2ACAANELAIAAVbOAgAGER4CAABuWgIAACY6A///raUCAAL0bAP//txnAgAEO71CAAFt5AP//rHNg Date: Thu, 6 Jul 2017 20:40:39 +0000 Message-ID: <6cd082b1a0334d498d84b521408f0cbf@XCH-ALN-014.cisco.com> References: <20170703175308.hembxkplaniz66wb@Vurt.local> <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> <09BFF794-6899-4DA5-8EF5-DDF86513BFBA@pfrc.org> <20170704104840.mg5bflnmmjlv4jbi@Vurt.local> <20C02BA3-5C13-46FB-AFE8-85D61E469EA1@juniper.net> <1FD8FAE9-E6BF-4C48-BCD6-12C1012827E2@juniper.net> <696fbda3aa2b4af9b0fc8f4757e7b541@XCH-ALN-014.cisco.com> <4d8bd5d458db4427a72c15a5ae94cda7@XCH-ALN-014.cisco.com> <93357697-1F0A-462E-993F-6CDB7693418E@pfrc.org> In-Reply-To: <93357697-1F0A-462E-993F-6CDB7693418E@pfrc.org> 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.43.213] Content-Type: multipart/alternative; boundary="_000_6cd082b1a0334d498d84b521408f0cbfXCHALN014ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 20:40:47 -0000 --_000_6cd082b1a0334d498d84b521408f0cbfXCHALN014ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Jeffrey Haas [mailto:jhaas@pfrc.org] Sent: Thursday, July 06, 2017 1:37 PM To: Jakob Heitz (jheitz) Cc: John Scudder ; idr wg Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt On Jul 6, 2017, at 4:22 PM, Jakob Heitz (jheitz) > wrote: The draft proposes to filter paths from best-path selection based upon nexthop reachability. This looks more like a new ORF type than a SAFI. SAFI is for one-to-many information. ORF is used for peer-to-peer info. It would certainly make it easier to write the code for it if it were an ORF type. Well, 2: one for ReachTell and another for ReachAsk. Was this considered? I tend to consider this a bit more like rt-constrain than an ORF. I accept= your comparison for the peer-to-peer being a bit more ORF-like than rt-con= strain. I think my biggest bit of feedback is that ORF seems generally less setup f= or "chatty" state changes than an rt-constrain like mechanism. ORF still h= as a bit of the implication of "do a refresh to change state", even if the = results are incremental. [Jakob] That makes ORF even more apt. When reachability changes, a refresh = of the diffs is required. -- jeff --_000_6cd082b1a0334d498d84b521408f0cbfXCHALN014ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

From: Jeffrey Haas [mailto:jhaas@pfr= c.org]
Sent: Thursday, July 06, 2017 1:37 PM
To: Jakob Heitz (jheitz) <jheitz@cisco.com>
Cc: John Scudder <jgs@juniper.net>; idr wg <idr@ietf.org>= ;
Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt

 

 

On Jul 6, 2017, at 4:22 PM, Jakob Heitz (jheitz) <= ;jheitz@cisco.com> wrote:

 

The draft proposes to filter paths from best= -path selection

based upon nexthop reachability.=

 

This looks more like a new ORF type than a S= AFI.

SAFI is for one-to-many information.<= o:p>

ORF is used for peer-to-peer info.

It would certainly make it easier to write t= he code for it

if it were an ORF type.

Well, 2: one for ReachTell and another for R= eachAsk.

Was this considered?

 

I tend to consider this a bit more like rt-constrain= than an ORF.  I accept your comparison for the peer-to-peer being a b= it more ORF-like than rt-constrain.

 

I think my biggest bit of feedback is that ORF seems= generally less setup for "chatty" state changes than an rt-const= rain like mechanism.  ORF still has a bit of the implication of "= do a refresh to change state", even if the results are incremental.

 

[Jakob] That makes ORF even more apt. When r= eachability changes, a refresh of the diffs is required.<= /p>

 

-- jeff

 

--_000_6cd082b1a0334d498d84b521408f0cbfXCHALN014ciscocom_-- From nobody Thu Jul 6 13:50:47 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 931C4131963 for ; Thu, 6 Jul 2017 13:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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 jZD_45AeIqEs for ; Thu, 6 Jul 2017 13:50:43 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::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 7764A129A96 for ; Thu, 6 Jul 2017 13:50:43 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id v202so14210979itb.0 for ; Thu, 06 Jul 2017 13:50:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=BO6JoThgLrjWv9mZwMZZ4LztSuUOgOoqtqtJTS6uM5E=; b=TUuzry/V4iniC0fjJNOa+lGG32F7QJjwxzVtQxJwNuCeX87nI74eisvDK+aI67LnYF YPBGjM8+8Jtihopj6qnZboo6sg89UrGt+VSmw+9EGGlltsSbfO75bPsLzXpYzK2dq0nj oPYQxnjP4VHn/vFsc32rUPrIPqwBnDCmoh7LYfr9DaYTtlsoz19hpbafySRzQpcNydqr tYl7SJgvhIRfCNkhU6/At8AmKJGFEaUfjtmJUA1ldjSNcZKSKVe0NVSKhkyZKvP4em2l R1AZicqqvmM7dug05LNYoc0wXkUcLf2cCPK0NPJmeM/eDTG55/M0+9t6EFstTMqtSGgO Cutw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=BO6JoThgLrjWv9mZwMZZ4LztSuUOgOoqtqtJTS6uM5E=; b=Zp897Meq9pjt5pgLeaUisj1aXASzVsRmA0P3NOtMCJOJkVitcHo2O7c7FIMB35lEj6 0DXQkbcjAVQ0wKfrDuwuYWqzaA+M7cWKzj4HSHFh2zKaveonS9w8I7E+Q0RRmJ1La5GN mnJFvZRJH5ujshMrnBegpkodsWXVgfJRZSeiTGaI3Rpi4VRL6r/pyjyS70OiANcPShAN E1zSArBdNcaYNqh0vpfRtrWfx1r93T1x2ccKtHrJqJAT9L1Sr0LP3YvDvEM9PZVpnKoF d1t6sUdMtiEBb78Ql0wiQA3Vg5/U08kTzAJX0ffkUsNa+C5RXmMoZb6H7x3JSA4hkaZv Tc8A== X-Gm-Message-State: AIVw111rk14Fx/6JoWdfQQcdzUasZSpoNAdgQ0BLOswuRhn8jbOHiiYJ 1KhXXq3fZM4cMILre64B5fZKDlU20a+q X-Received: by 10.36.203.195 with SMTP id u186mr1233342itg.77.1499374242755; Thu, 06 Jul 2017 13:50:42 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.32.15 with HTTP; Thu, 6 Jul 2017 13:50:41 -0700 (PDT) In-Reply-To: References: <20170703175308.hembxkplaniz66wb@Vurt.local> <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> <09BFF794-6899-4DA5-8EF5-DDF86513BFBA@pfrc.org> <20170704104840.mg5bflnmmjlv4jbi@Vurt.local> <20C02BA3-5C13-46FB-AFE8-85D61E469EA1@juniper.net> <1FD8FAE9-E6BF-4C48-BCD6-12C1012827E2@juniper.net> <696fbda3aa2b4af9b0fc8f4757e7b541@XCH-ALN-014.cisco.com> <4d8bd5d458db4427a72c15a5ae94cda7@XCH-ALN-014.cisco.com> <8620abbfc6444433b950c4a748fa2fed@XCH-ALN-014.cisco.com> From: Robert Raszuk Date: Thu, 6 Jul 2017 22:50:41 +0200 X-Google-Sender-Auth: mgah3K4lBN6g026xRe56Ik-4Wmk Message-ID: To: Jeffrey Haas Cc: "Jakob Heitz (jheitz)" , idr wg Content-Type: multipart/alternative; boundary="94eb2c0af94c1ffb180553ac4550" Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 20:50:46 -0000 --94eb2c0af94c1ffb180553ac4550 Content-Type: text/plain; charset="UTF-8" Jeff, Redirect to "write a new draft" is not an option if I need both reachability based and client to client IX MTU fluctuations based path selection. And this is a real use case. //RR. On Thu, Jul 6, 2017 at 10:40 PM, Jeffrey Haas wrote: > Your strawman is about to file a domestic violence restraining order. > > These are not our use cases. If you'd like one, feel free to write a > draft covering those. > > The draft simply proxies information related to BGP's reachability > condition for a nexthop. If this was full-mesh, the game would be > different. If this was a RR, this would be different. The RS is (mostly) > exceptional in this case. > > > -- Jeff > > On Jul 6, 2017, at 4:36 PM, Jakob Heitz (jheitz) wrote: > > The draft proposes to filter paths from best-path selection > based upon nexthop reachability. > > Why stop at reachability? > > A client may not wish to accept routes from another client, because > they don't have a contract or whatever reason. > Can we include the ASN of the nexthop with each nexthop? > > Other possible reasons for not wanting a route: > . The AS-path contains an undesirable ASN. > . The origin AS does not have the right to advertise the prefix. > . I prefer a customer route over a peer route. > . The route is a leak. > . Etc, Etc. > > Can you put the whole attribute set into the ReachAsk/ReachTell > rather than just the nexthop? > > Heck, why don't you just send the complete route --> Add-path. > > Thanks, > Jakob. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > --94eb2c0af94c1ffb180553ac4550 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Jeff,

Redirect to "write a new draft" is not an opt= ion if I need both reachability based and client to client IX MTU fluctuati= ons based path selection. And this is a real use case.=C2=A0

//RR.


On Thu,= Jul 6, 2017 at 10:40 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:<= br>
Your = strawman is about to file a domestic violence restraining order.

These are not our use cases.=C2=A0 If you'd like one, feel fre= e to write a draft covering those.

The draft simpl= y proxies information related to BGP's reachability condition for a nex= thop.=C2=A0 If this was full-mesh, the game would be different.=C2=A0 If th= is was a RR, this would be different.=C2=A0 The RS is (mostly) exceptional = in this case.


-- Jeff
On J= ul 6, 2017, at 4:36 PM, Jakob Heitz (jheitz) <jheitz@cisco.com> wrote:

=
The draft proposes to filter paths from best-path = selection
base= d upon nexthop reachability.
=C2=A0
Why stop at reachability?
=C2=A0
A client may not wish to accept routes from another client, be= cause
they don= 't have a contract or whatever reason.
Can we include the ASN of the nexthop with eac= h nexthop?
= =C2=A0
Other poss= ible reasons for not wanting a route:
. The AS-path contains an undesirable ASN.<= u>
. The origin AS does = not have the right to advertise the prefix.
. I prefer a customer route over a peer route= .
. The route = is a leak.
. E= tc, Etc.
=C2=A0
Can you put = the whole attribute set into the ReachAsk/ReachTell
rather than just the nexthop?<= u>
=C2=A0<= /span>
Heck, why don't you just= send the complete route --> Add-path.
=C2=A0
Thanks,
Jakob.
=
_______________= ________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr


____________________________________= ___________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr


--94eb2c0af94c1ffb180553ac4550-- From nobody Thu Jul 6 13:51:41 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874FA131563 for ; Thu, 6 Jul 2017 13:51:39 -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 ba_UyeYjtZDY for ; Thu, 6 Jul 2017 13:51:38 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD7D2129A96 for ; Thu, 6 Jul 2017 13:51:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13176; q=dns/txt; s=iport; t=1499374297; x=1500583897; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=n1iczsU8AX2GA/RYFzHPgO8O80sRWjFerv+sbm6BvoQ=; b=Ntlu3c9QDTy5siKWVuqRJY+ve0xH+/BDOj4wL3j4aH6QCk6e/NeDgh+i 3gnOJSHbQ36wSZW3si4tTd95nynKCUMHAupNtTQZYjoRls2CX1sDov7u1 mhRhFpiamrRmqdlpLjHHbOe2+T70XP0fxcLGrpGJYXP4SPoaI25WzPGNm k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoAACTol5Z/4sNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9qY4ERB44CkWeQV4UsghEhAQqFcAKDMz8YAQIBAQEBAQEBayi?= =?us-ascii?q?FGAEBAQEDAQElBkELEAIBCA4DBAEBKAcnCxQJCAIEDgUIE4kwZBCyTzqLMwEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBARgFgyeDTIUFhSCFPgWXLodhAodFjDaSJ5U3AR8?= =?us-ascii?q?4gQp1FUmHFnaHZYENAQEB?= X-IronPort-AV: E=Sophos;i="5.40,319,1496102400"; d="scan'208,217";a="256352293" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Jul 2017 20:51:36 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v66KpaN6028058 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 6 Jul 2017 20:51:36 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 6 Jul 2017 15:51:36 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Thu, 6 Jul 2017 15:51:36 -0500 From: "Jakob Heitz (jheitz)" To: Jeffrey Haas CC: idr wg Thread-Topic: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt Thread-Index: AQHS9BUunfHRezzCokubhqS6qWLW+qJCmLwAgAADHACAAAV9AIAAEJgAgAAELwCAACXgAIAABdiAgAAGlwCAAAS/gIAAAluAgAADsICAAAI9gIAABIMAgAAG2ACAANELAIAAVbOAgAGER4CAABuWgIAACY6A///raUCAAL0bAP//txnAgAEO71CAAAQWUIAAWEeA//+trYA= Date: Thu, 6 Jul 2017 20:51:36 +0000 Message-ID: <131fa1bb3bff424e8ff5207b368a0734@XCH-ALN-014.cisco.com> References: <20170703175308.hembxkplaniz66wb@Vurt.local> <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> <09BFF794-6899-4DA5-8EF5-DDF86513BFBA@pfrc.org> <20170704104840.mg5bflnmmjlv4jbi@Vurt.local> <20C02BA3-5C13-46FB-AFE8-85D61E469EA1@juniper.net> <1FD8FAE9-E6BF-4C48-BCD6-12C1012827E2@juniper.net> <696fbda3aa2b4af9b0fc8f4757e7b541@XCH-ALN-014.cisco.com> <4d8bd5d458db4427a72c15a5ae94cda7@XCH-ALN-014.cisco.com> <8620abbfc6444433b950c4a748fa2fed@XCH-ALN-014.cisco.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.43.213] Content-Type: multipart/alternative; boundary="_000_131fa1bb3bff424e8ff5207b368a0734XCHALN014ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 20:51:39 -0000 --_000_131fa1bb3bff424e8ff5207b368a0734XCHALN014ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The game is about the RS hiding paths that the client wants. Nexthop reachability is but one of many criteria to determine the path that a client wants. Focusing on nexthop rechability will result in an incomplete solution. I don't need a draft. A complete solution to the problem already exists: https://tools.ietf.org/html/rfc7911 Thanks, Jakob. From: Jeffrey Haas [mailto:jhaas@pfrc.org] Sent: Thursday, July 06, 2017 1:41 PM To: Jakob Heitz (jheitz) Cc: idr wg Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt These are not our use cases. If you'd like one, feel free to write a draft= covering those. The draft simply proxies information related to BGP's reachability conditio= n for a nexthop. If this was full-mesh, the game would be different. If t= his was a RR, this would be different. The RS is (mostly) exceptional in t= his case. -- Jeff On Jul 6, 2017, at 4:36 PM, Jakob Heitz (jheitz) > wrote: The draft proposes to filter paths from best-path selection based upon nexthop reachability. Why stop at reachability? A client may not wish to accept routes from another client, because they don't have a contract or whatever reason. Can we include the ASN of the nexthop with each nexthop? Other possible reasons for not wanting a route: . The AS-path contains an undesirable ASN. . The origin AS does not have the right to advertise the prefix. . I prefer a customer route over a peer route. . The route is a leak. . Etc, Etc. Can you put the whole attribute set into the ReachAsk/ReachTell rather than just the nexthop? Heck, why don't you just send the complete route --> Add-path. Thanks, Jakob. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_131fa1bb3bff424e8ff5207b368a0734XCHALN014ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The game is about the RS hiding paths that t= he client wants.

Nexthop reachability is but one of many crit= eria to determine

the path that a client wants.

Focusing on nexthop rechability will result = in an incomplete solution.

I don't need a draft. A complete solution to= the problem already exists:

https://tools.ietf.org/html/rfc7911

 

 

Thanks,

Jakob.

 

From: Jeffrey Haas [mailto:jhaas@pfr= c.org]
Sent: Thursday, July 06, 2017 1:41 PM
To: Jakob Heitz (jheitz) <jheitz@cisco.com>
Cc: idr wg <idr@ietf.org>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt

 

These are not our use cases.  If you'd like one= , feel free to write a draft covering those.

 

The draft simply proxies information related to BGP'= s reachability condition for a nexthop.  If this was full-mesh, the ga= me would be different.  If this was a RR, this would be different. &nb= sp;The RS is (mostly) exceptional in this case.

 

 

-- Jeff

 

On Jul 6, 2017, at 4:36 PM, Jakob Heitz (jheitz) <= ;jheitz@cisco.com> wrote:

 

The draft proposes to filter paths from best= -path selection

based upon nexthop reachability.=

 

Why stop at reachability?<= /p>

 

A client may not wish to accept routes from = another client, because

they don't have a contract or whatever reaso= n.

Can we include the ASN of the nexthop with e= ach nexthop?

 

Other possible reasons for not wanting a rou= te:

. The AS-path contains an undesirable ASN.

. The origin AS does not have the right to a= dvertise the prefix.

. I prefer a customer route over a peer rout= e.

. The route is a leak.

. Etc, Etc.

 

Can you put the whole attribute set into the= ReachAsk/ReachTell

rather than just the nexthop?

 

Heck, why don't you just send the complete r= oute --> Add-path.

 

Thanks,

Jakob.

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

 

--_000_131fa1bb3bff424e8ff5207b368a0734XCHALN014ciscocom_-- From nobody Thu Jul 6 14:10:15 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23F7131553 for ; Thu, 6 Jul 2017 14:10:14 -0700 (PDT) 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 KMwUCIMkuEcV for ; Thu, 6 Jul 2017 14:10:11 -0700 (PDT) Received: from nipper.de (ns.nipper.de [212.86.201.219]) by ietfa.amsl.com (Postfix) with ESMTP id 0D71713180A for ; Thu, 6 Jul 2017 14:10:11 -0700 (PDT) Received: from nipper.de (localhost [127.0.0.1]) by server0.nipper.de (Postfix) with ESMTP id 8BFAB3DCEA; Thu, 6 Jul 2017 23:10:09 +0200 (CEST) To: Robert Raszuk , "John G. Scudder" References: <149909741417.22786.4679459342587499122@ietfa.amsl.com> <20170703160800.x6wcym2ma6jceqv7@Vurt.local> <20170703163846.224w6lxvbt4txqub@Vurt.local> <20170703173810.GA45648@Space.Net> <20170703175308.hembxkplaniz66wb@Vurt.local> <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> Cc: idr wg Openpgp: id=393E1B14AE49816F7EA387F6AF3E82C29441FC4C From: Arnold Nipper Message-ID: <390074f5-d322-c32e-cb63-dc0f0b07d428@nipper.de> Date: Thu, 6 Jul 2017 23:10:08 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kGGQnF3a0bfto6JvaTeMkbHq49qRm4ktD" X-Virus-Scanned: ClamAV by nipper.de Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 21:10:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kGGQnF3a0bfto6JvaTeMkbHq49qRm4ktD Content-Type: multipart/mixed; boundary="OalKM2C8XQD5XTceHl6Nlp6vs43rTKBN2"; protected-headers="v1" From: Arnold Nipper To: Robert Raszuk , "John G. Scudder" Cc: idr wg Message-ID: <390074f5-d322-c32e-cb63-dc0f0b07d428@nipper.de> Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt References: <149909741417.22786.4679459342587499122@ietfa.amsl.com> <20170703160800.x6wcym2ma6jceqv7@Vurt.local> <20170703163846.224w6lxvbt4txqub@Vurt.local> <20170703173810.GA45648@Space.Net> <20170703175308.hembxkplaniz66wb@Vurt.local> <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> In-Reply-To: --OalKM2C8XQD5XTceHl6Nlp6vs43rTKBN2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Robert On 04.07.2017 11:02, Robert Raszuk wrote: > Today vast majority of OPEN policy clients share single RS view/table s= o > you do best path and update generation once for all of them. >=20 > The moment you introduce per client state you are braking those apart > into individual views. >=20 vast majority run BIRD as RS and it is BCP to do per client (ASN) best pa= th Arnold --=20 Arnold Nipper email: arnold@nipper.de mobile: +49 172 2650958 --OalKM2C8XQD5XTceHl6Nlp6vs43rTKBN2-- --kGGQnF3a0bfto6JvaTeMkbHq49qRm4ktD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAllepzAACgkQrz6CwpRB/ExA7QCgu8wUV259YfiD1wy9fsaRjwIY 8BoAnipWrIx2TvJykehXrT69BrH8zOO7 =aYEU -----END PGP SIGNATURE----- --kGGQnF3a0bfto6JvaTeMkbHq49qRm4ktD-- From nobody Fri Jul 7 01:17:49 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9EA21241FC for ; Fri, 7 Jul 2017 01:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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 hkTPfnZr5RNQ for ; Fri, 7 Jul 2017 01:17:45 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B37A1204DA for ; Fri, 7 Jul 2017 01:17:45 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id k192so28375436ith.1 for ; Fri, 07 Jul 2017 01:17:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=cWfF134QotqenzzWAreaNH0oh6f6SVpYCwDOiHK5Je0=; b=M4XZRNWUqln07Tdz7iZvIhXkmEsPn6/LO1Hs7tuHr4IVskLrguAxS6/bPd8Z3qCC3j GgPvMDmw3B+5L5SFeLgE54aDinIUH28rWWBrINin1HvaRontj+8vzjirVHEepAGjfnHE emH702MMk0SIv/08kSE6+rPRZSo177ULBV/vUoko6P1ut5DsHIasfI7t/dNuGKC//SxI JsJvgcfv7N8JkMqT+d0gJMydL9aPpBG/B+oRWOp5fvyiu1AyDdlA4VE0KmlH+NLKaA11 HhGVksNI7xOsflX43pvkwHsSoKgsNgl5y/JBuZE4fgJHPLHd2aTXD7NBGABMwtgv/2ZK Q/bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=cWfF134QotqenzzWAreaNH0oh6f6SVpYCwDOiHK5Je0=; b=HkPccagO1Pg8m0zTSMMTEqIBBPTs5/m49xk+pz9l9wUjm2pNhYGuD/aLb6QDYQmrI5 W3Ie5fli+wjiLZiim1OhSsg2VYpKQ5gzAJt5n/aNWWD+psF9qNap7kuAmcOJUYhYl8KY Am29kKDyEY4Us4OyQBtUfBLW4TxfuFCRco2NDQCKFiWCRLIMSRMhsmQyDcFYjm6wBVgB XlRIesghPGq1eBppiV3JZ9Kyl//q2hnmXn5AIDjSIM4hAljnH9ckqPom4VxTlLbTRigV R24en3Vg7bvtdVxdPYvGz5BH6kffKd196LDvuxDWHVvy2A/ZpKSQ2QYj9YzBp53XmMST 2gLQ== X-Gm-Message-State: AIVw110NsFyOmQbCGsLUnYh2qUKfem+kJrPb18zSkDlZ9m1kWMIfwo7b U5Dhyo677cLn5OAVW1mP2CDj/fV/Kg== X-Received: by 10.107.138.17 with SMTP id m17mr1390621iod.155.1499415464781; Fri, 07 Jul 2017 01:17:44 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.32.15 with HTTP; Fri, 7 Jul 2017 01:17:43 -0700 (PDT) In-Reply-To: <390074f5-d322-c32e-cb63-dc0f0b07d428@nipper.de> References: <149909741417.22786.4679459342587499122@ietfa.amsl.com> <20170703160800.x6wcym2ma6jceqv7@Vurt.local> <20170703163846.224w6lxvbt4txqub@Vurt.local> <20170703173810.GA45648@Space.Net> <20170703175308.hembxkplaniz66wb@Vurt.local> <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> <390074f5-d322-c32e-cb63-dc0f0b07d428@nipper.de> From: Robert Raszuk Date: Fri, 7 Jul 2017 10:17:43 +0200 X-Google-Sender-Auth: hJQ6Bwa-O957FDD-1CMcLzuARnk Message-ID: To: Arnold Nipper Cc: "John G. Scudder" , idr wg Content-Type: multipart/alternative; boundary="001a113fea802638e80553b5de37" Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 08:17:48 -0000 --001a113fea802638e80553b5de37 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Arnold, vast majority run BIRD as RS and it is BCP to do per client (ASN) best path =E2=80=8BPerhaps it is a Common Practice but it is hardly "=E2=80=8BBest" o= ne. That must be why so many folks already complain today about their RS scaling issues. Copying OPEN policy nets and paths to individual per client views seems very suboptimal for RS design. Well you get what you paid for :). To contrast that let me remind everyone that Route Server design in Cisco IOS XE keep all common policy paths in single global BGP "view" and only when there is static or dynamic (by communities) policy moves subject to policy paths to individual views. So clients get sigma of per view + global updates. And you can run on your existing x86 RS blade too. The draft under discussion breaks this design and its scaling properties. Now to someone who mentioned that this is all about weak client routers let's face the numbers. The data from various route servers (two in Asia, one in EU and one in US) I have captured recently show: IX1 - 250K IPv4 total paths IX2 - 167K IPv4 total paths IX3 - 50K IPv4 total paths IX4 - 30K IPv4 total paths So with 120 bytes per path (this is size of BGP path data structure in efficient BGP code base) even if you send all clients all paths with add-paths you need on client control plane total RAM of: IX1 - 30 MB RAM IX2 - 20 MB RAM IX3 - 6 MB RAM IX4 - 3.5 MB RAM =E2=80=8BSo what problem is this draft trying to solve ? Save max 10s of = =E2=80=8BMB of RAM on the client ? Note also that even add-paths is optional. Most IX already today have two Route Servers. So it is trivial to have such one route-server to act as primary sending overall best path and second one acting as backup sending 2nd best. (The IOS XE definition of second best mandates different next hop then overall all best). All what is needed is few implementation twicks in your RS code vendor to address the problem at hand. Cheers, Robert. --001a113fea802638e80553b5de37 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Arnold,

=
vast majority run BIRD as RS and it is B= CP to do per client (ASN) best path

=E2=80=8BPerhaps it is a Common Practice but it is hardly "= ;=E2=80=8BBest" one. That must be why so many folks already complain t= oday about their RS scaling issues.=C2=A0

Copying OPEN policy nets and paths to individual per cl= ient views seems very suboptimal for RS design. Well you get what you paid = for :).=C2=A0

To contr= ast that let me remind everyone that Route Server design in Cisco IOS XE ke= ep all common policy paths in single global BGP "view" and only w= hen there is static or dynamic (by communities) policy moves subject to pol= icy paths to individual views. So clients get sigma of per view + global up= dates. And you can run on your existing x86 RS blade too.=C2=A0

The draft under discussion breaks= this design and its scaling properties.=C2=A0

=
Now to someone who mentioned that this is all abou= t weak client routers let's face the numbers.=C2=A0

The data fro= m various route servers (two in Asia, one in EU and one in US) I have captu= red recently show: =C2=A0

IX1 - 250K IPv4 total paths=C2=A0
IX2 - 167K IPv4 total paths
IX3 - 50K IPv4 total paths
IX4 - 30= K IPv4 total paths

So with 120 bytes per path (this is size of BGP path dat= a structure in efficient BGP code base) even if you send all clients all pa= ths with add-paths you need on client control plane total RAM of:

IX1 - =C2=A030 MB RAM
= IX2 - =C2=A020 MB RAM
IX3 - =C2=A06 MB RA= M
IX4 - 3.5 MB RAM

<= /div>
=E2=80=8BSo what problem is this draft trying = to solve ? Save max 10s of =E2=80=8BMB of RAM on the client ?=C2=A0

Note also that even add-paths= is optional. Most IX already today have two Route Servers. So it is trivia= l to have such one route-server to act as primary sending overall best path= and second one acting as backup sending 2nd best. (The IOS XE definition o= f second best mandates different next hop then overall all best).=C2=A0

All what is needed is few= implementation twicks in your RS code vendor to address the problem at han= d.

Cheers,
Robert.<= /div>

--001a113fea802638e80553b5de37-- From nobody Sat Jul 8 13:43:04 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5503E13154A; Sat, 8 Jul 2017 13:42:56 -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 OcIg4ICbM2IH; Sat, 8 Jul 2017 13:42:54 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C148D12EC49; Sat, 8 Jul 2017 13:42:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23888; q=dns/txt; s=iport; t=1499546573; x=1500756173; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=YsPdvJAA4FkCxFXHGWg+BjhTD79DW8t58ksjTcxR2VU=; b=QF6iAGo7PDy1A6mQgz1v6vA9ZownQGNFmvoX74e8Mdp9ip/+Fmv+Vx8i kDH8Sfdt35Lngr3yv0bLvgv8Q5h+DCxiH15FjHtLOFgGufvncaLhd72HX VqXTO/QIW7jwyaVvqHWvYBxUxweleDY+FMn0P8v435dXr5IgeyzrjkeyJ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DOAADlQmFZ/4gNJK1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgm8+LWSBFAeOApFpiC+IKYUsghEshXACGoMvPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?YAQEBAQMjCkwQAgEIEQMBAQEoAwICAh8RFAkIAgQOBQiJQ0wDFRCuXoImhy0Nh?= =?us-ascii?q?AABAQEBAQEBAQEBAQEBAQEBAQEBAQEdgyiDTIFgAYMkgleCMwYQgl2CYQWJYg6?= =?us-ascii?q?NRYcuOwKHRodUhGWCFVeBD4NliQeBRIt5iUYBDxA4gQp1FYVcHIFndgGHboENA?= =?us-ascii?q?QEB?= X-IronPort-AV: E=Sophos;i="5.40,330,1496102400"; d="scan'208,217";a="450494811" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Jul 2017 20:42:52 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v68Kgq16015775 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 8 Jul 2017 20:42:52 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 8 Jul 2017 15:42:52 -0500 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; Sat, 8 Jul 2017 15:42:52 -0500 From: "Les Ginsberg (ginsberg)" To: Pushpasis Sarkar CC: "idr-ads@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-idr-bgp-ls-node-admin-tag-extension.all@ietf.org" , "idr@ietf. org" Thread-Topic: RtgDir review: draft-ietf-idr-bgp-ls-node-admin-tag-extension-01 Thread-Index: AQHS8JhKqOb35QlmrUi/hOdnkjC4jqJE+FwAgAV7EBA= Date: Sat, 8 Jul 2017 20:42:51 +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-transport-fromentityheader: Hosted x-originating-ip: [10.24.107.117] Content-Type: multipart/alternative; boundary="_000_ed8ccfc11e8a4951a2bf67d8ad34e16bXCHALN001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] RtgDir review: draft-ietf-idr-bgp-ls-node-admin-tag-extension-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jul 2017 20:42:56 -0000 --_000_ed8ccfc11e8a4951a2bf67d8ad34e16bXCHALN001ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UHVzaHBhc3NpcyDigJMNCg0KU29ycnkgZm9yIHRoZSBkZWxheSBpbiByZXNwb25kaW5nLg0KWW91 IGhhdmUgbm90IGFkZHJlc3NlZCBhbGwgb2YgdGhlIGVkaXRvcmlhbCBjb21tZW50cyBJIHByb3Zp ZGVkIOKAkyBwbGVhc2UgZG8gYSBzZWNvbmQgcGFzcy4NCg0KQWxzbywgdGhlcmUgaXMgb25lIHN1 YnN0YW50aXZlIGlzc3VlIHdoaWNoIHlvdSBkaWQgbm90IGFkZHJlc3M6DQoNCjxzbmlwPg0KU2Vj dGlvbiAzLjEgTGFzdCBwYXJhZ3JhcGgNCg0KSSByZWNvZ25pemUgdGhpcyBzdGF0ZW1lbnQgcmVn YXJkaW5nIHBvbGljeSBiZWluZyB1c2VkIHRvIGZpbHRlciB3aGF0IGlzDQphZHZlcnRpc2VkIGlz IGNvbnNpc3RlbnQgd2l0aCBSRkMgNzc1Mi4gQnV0IGl0IHdvdWxkIGFsc28gYmUgZ29vZCB0byBp bmNsdWRlDQphIHN0YXRlbWVudCBsaWtlOg0KDQoiRGVmaW5pdGlvbiBvZiBzdWNoIGEgcG9saWN5 IGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuIg0KPGVuZCBzbmlwPg0KDQpJ ZiB5b3UgaGF2ZSBhIGNvbmNlcm4gd2l0aCB3aGF0IEkgcHJvcG9zZWQgcGxlYXNlIGxldCBtZSBr bm93IHdoYXQgaXQgaXMuDQoNClRoYW54Lg0KDQogICBMZXMNCg0KDQoNCkZyb206IFB1c2hwYXNp cyBTYXJrYXIgW21haWx0bzpwdXNocGFzaXMuaWV0ZkBnbWFpbC5jb21dDQpTZW50OiBUdWVzZGF5 LCBKdWx5IDA0LCAyMDE3IDg6NTggUE0NClRvOiBMZXMgR2luc2JlcmcgKGdpbnNiZXJnKQ0KQ2M6 IGlkci1hZHNAaWV0Zi5vcmc7IHJ0Zy1kaXJAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtaWRyLWJncC1s cy1ub2RlLWFkbWluLXRhZy1leHRlbnNpb24uYWxsQGlldGYub3JnOyBpZHJAaWV0Zi4gb3JnDQpT dWJqZWN0OiBSZTogUnRnRGlyIHJldmlldzogZHJhZnQtaWV0Zi1pZHItYmdwLWxzLW5vZGUtYWRt aW4tdGFnLWV4dGVuc2lvbi0wMQ0KDQpIaSBMZXMsDQoNClRoYW5rIHlvdSBvbmNlIG1vcmUgZm9y IHRoZSByZXZpZXcgY29tbWVudHMuIEFuZCBzb3JyeSBmb3IgdGhlIGxhdGUgcmVwbHkuIEkgaGF2 ZSBhZGRyZXNzZWQgYWxsIHlvdXIgY29tbWVudHMgaW4gdGhlIGF0dGFjaGVkIGRyYWZ0LiBQbGVh c2UgcmV2aWV3IHRoZSBzYW1lIGxldCBtZSBrbm93IGlmIHlvdSBoYXZlIGFueSBtb3JlIGNvbW1l bnRzLiBJZiBub3QgSSB3aWxsIHVwbG9hZCB0aGUgZHJhZnQgc29vbi4NCg0KVGhhbmtzIGFuZCBy ZWdhcmRzLA0KLVB1c2hwYXNpcw0KDQpPbiBXZWQsIEp1biAyOCwgMjAxNyBhdCAxMDoyNiBQTSwg UHVzaHBhc2lzIFNhcmthciA8cHVzaHBhc2lzLmlldGZAZ21haWwuY29tPG1haWx0bzpwdXNocGFz aXMuaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToNCkhpIExlcywNCg0KVGhhbmtzIGEgbG90IGZvciB0 aGUgcmV2aWV3IGNvbW1lbnRzLiBJIHdpbGwgcmVwbHkgYmFjayBhZGRyZXNzaW5nIHlvdXIgY29t bWVudHMgc29vbi4NCg0KVGhhbmtzIGFuZCByZWdhcmRzDQotUHVzaHBhc2lzDQoNCk9uIFR1ZSwg SnVuIDI3LCAyMDE3IGF0IDExOjM3IFBNLCBMZXMgR2luc2JlcmcgKGdpbnNiZXJnKSA8Z2luc2Jl cmdAY2lzY28uY29tPG1haWx0bzpnaW5zYmVyZ0BjaXNjby5jb20+PiB3cm90ZToNCkhlbGxvLA0K DQogSSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgcmV2aWV3 ZXIgZm9yIHRoaXMgZHJhZnQuIFRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHNlZWtzIHRvIHJldmll dyBhbGwgcm91dGluZyBvciByb3V0aW5nLXJlbGF0ZWQgZHJhZnRzIGFzIHRoZXkgcGFzcyB0aHJv dWdoIElFVEYgbGFzdCBjYWxsIGFuZCBJRVNHIHJldmlldywgYW5kIHNvbWV0aW1lcyBvbiBzcGVj aWFsIHJlcXVlc3QuIFRoZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcgaXMgdG8gcHJvdmlkZSBhc3Np c3RhbmNlIHRvIHRoZSBSb3V0aW5nIEFEcy4gRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhl IFJvdXRpbmcgRGlyZWN0b3JhdGUsIHBsZWFzZSBzZWUgIGh0dHA6Ly90cmFjLnRvb2xzLmlldGYu b3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXIgLg0KDQpBbHRob3VnaCB0aGVzZSBjb21tZW50 cyBhcmUgcHJpbWFyaWx5IGZvciB0aGUgdXNlIG9mIHRoZSBSb3V0aW5nIEFEcywgaXQgd291bGQg YmUgaGVscGZ1bCBpZiB5b3UgY291bGQgY29uc2lkZXIgdGhlbSBhbG9uZyB3aXRoIGFueSBvdGhl ciBJRVRGIGNvbW1lbnRzIHRoYXQgeW91IHJlY2VpdmUsIGFuZCBzdHJpdmUgdG8gcmVzb2x2ZSB0 aGVtIHRocm91Z2ggZGlzY3Vzc2lvbiBvciBieSB1cGRhdGluZyB0aGUgZHJhZnQuDQoNCg0KRG9j dW1lbnQ6IGRyYWZ0LWlldGYtaWRyLWJncC1scy1ub2RlLWFkbWluLXRhZy1leHRlbnNpb24tMDEN ClJldmlld2VyOiBMZXMgR2luc2JlcmcNClJldmlldyBEYXRlOiBKdW5lIDI3LCAyMDE3DQpJbnRl bmRlZCBTdGF0dXM6IFN0YW5kYXJkcw0KDQpTdW1tYXJ5OiAgVGhlIGRvY3VtZW50IGlzIG9mIG1v ZGVzdCBzY29wZSAtIGNvdmVyaW5nIGRlZmluaXRpb24gb2YgQkdQLUxTDQpjb2RlcG9pbnRzIGZv ciBhIHJlbGF0aXZlbHkgbmV3IElHUCBhdHRyaWJ1dGUgKE5vZGUgQWRtaW4gVGFncykuDQpXaGls ZSBJIGZvdW5kIG5vdGhpbmcgd2hpY2ggSSB3b3VsZCBjb25zaWRlciBhIG1ham9yIGlzc3VlLCB0 aGVyZSBhcmUgYSBudW1iZXINCm9mIHBsYWNlcyB3aGVyZSB0aGUgdGV4dCBsYWNrcyBjbGFyaXR5 LiBJIHRoaW5rIGFkZHJlc3NpbmcgdGhlc2UgYXJlYXMgd291bGQNCmdyZWF0bHkgaW1wcm92ZSB0 aGUgcXVhbGl0eSBvZiB0aGUgZHJhZnQuDQoNCg0KTWFqb3IgSXNzdWVzOiBOb25lDQoNCk1pbm9y IElzc3VlczoNCg0KU2VjdGlvbiAxIEludHJvZHVjdGlvbg0KDQpUaGUgYWNyb255bSBMU0RCIGlz IG5vdCBkZWZpbmVkLg0KDQpGaWd1cmUgMQ0KDQpJIGhhdmUgYSBwZXJzb25hbCBkaXNsaWtlIGZv ciBkdXBsaWNhdGluZyB0ZXh0L3BpY3R1cmVzIGZyb20gYW5vdGhlcg0Kc3BlYyB3aGVuIHRoYXQg c3BlYyBjb3VsZCBzaW1wbHkgYmUgcmVmZXJlbmNlZC4gVGhlcmUgYXJlIG9ubHkgdHdvDQpwb3Nz aWJsZSBvdXRjb21lczoNCg0KMSlUaGUgZHVwbGljYXRlZCB0ZXh0IGlzIHJlZHVuZGFudCAoYmVz dCBjYXNlKQ0KMilUaGUgdGV4dCBkaWZmZXJzIHNvbWV3aGF0IGZyb20gdGhlIG9yaWdpbmFsIGxl YWRpbmcgdG8gcG9zc2libGUNCnVuaW50ZW50aW9uYWwgbWlzaW50ZXJwcmV0YXRpb25zLg0KDQpT dWl0IHlvdXJzZWxmIG9uIHRoaXMgY29tbWVudCAtIGJ1dCBJIHdvdWxkIHByZWZlciB0aGUgZHVw bGljYXRpb24gYmUgb21pdHRlZC4NCg0KU2VjdGlvbiAyIEZpcnN0IHBhcmFncmFwaA0KDQpZb3Ug cmVmZXIgdG8gInN1Yi1UTFYiIGJ1dCB0aGF0IHJlZmVyZW5jZSBpcyB1bmNsZWFyIGFuZCBhbWJp Z3VvdXMuDQpJUy1JUyB1c2VzIGEgc3ViLVRMViBvZiBSb3V0ZXIgQ2FwYWJpbGl0eSB0byBhZHZl cnRpc2UgdGFncywgYnV0IE9TUEYNCnVzZXMgYSBUTFYgb2YgUm91dGVyIEluZm8gTFNBLg0KV2hh dCBzZWVtcyBtb3N0IHJlbGV2YW50IGhlcmUgaXMgdGhhdCB5b3UgYXJlIGRlZmluaW5nIGEgbmV3 IEF0dHJpYnV0ZQ0KVExWIGZvciBOb2RlIE5MUkkuDQoNClNlY3Rpb24gMyBTZWNvbmQgcGFyYWdy YXBoDQoNCkkgZG8gbm90IGtub3cgd2hhdCB0aGUgcGFyYWdyYXBoIGlzIHRyeWluZyB0byBzYXks IG5vciBkbw0KSSBrbm93IHdoYXQgdGhlICJUQkQiIGluIGNvbHVtbnMgNCBhbmQgNSBpbiB0aGUg Zm9sbG93aW5nIFRhYmxlIDEgaXMNCm1lYW50IHRvIHJlZmVyZW5jZS4gSWYgeW91IGFyZSBzaW1w bHkgdHJ5aW5nIHRvIGRlc2NyaWJlIHRoZSBzb3VyY2UNCm9mIHRoZSBpbmZvIGFkdmVydGlzZWQg YnkgdGhlIG5ldyBCR1AtTFMgTm9kZSBhdHRyaWJ1dGUgdGhlbiB5b3Ugc2hvdWxkDQpyZXdyaXRl IHRoZSBhYm92ZSBwYXJhZ3JhcGggYW5kIGluIHRoZSBmaWd1cmUgYmVsb3cgc2hvdzoNCg0KSVMt SVMgMjQyLzIxDQpPU1BGIFJJLUxTQS8xMA0KDQpTZWN0aW9uIDMuMQ0KDQpBIGRlc2NyaXB0aW9u IG9mIHdoZXJlIGluIHRoZSBOb2RlIE5MUkkgdGhlIGFyZWEvbGV2ZWwgaW5mb3JtYXRpb24gY2Fu IGJlIGZvdW5kDQooZnJvbSBSRkMgNzc1Mikgd291bGQgYmUgaGVscGZ1bC4NCg0KDQpTZWN0aW9u IDMuMSBQZW51bHRpbWF0ZSBQYXJhZ3JhcGgNCg0KQXMgVEFHcyB3aXRoICJnbG9iYWwiIHNjb3Bl IHdpbGwgYmUgYWR2ZXJ0aXNlZCBieSB0aGUgSUdQIG11bHRpcGxlDQp0aW1lcyAob25jZSBwZXIg YXJlYS9sZXZlbCkgSSBhc3N1bWUgeW91IGFyZSBhc2tpbmcgQkdQLUxTIGFkdmVydGlzZW1lbnRz DQp0byByZWR1Y2UgdGhlc2UgbXVsdGlwbGUgb2NjdXJyZW5jZXMgdG8gYSBzaW5nbGUgb2NjdXJy ZW5jZT8gTW9yZQ0KZXhwbGljaXQgbGFuZ3VhZ2Ugb24gdGhhdCBwb2ludCB3b3VsZCBiZSBoZWxw ZnVsLg0KDQpTZWN0aW9uIDMuMSBMYXN0IHBhcmFncmFwaA0KDQpJIHJlY29nbml6ZSB0aGlzIHN0 YXRlbWVudCByZWdhcmRpbmcgcG9saWN5IGJlaW5nIHVzZWQgdG8gZmlsdGVyIHdoYXQgaXMNCmFk dmVydGlzZWQgaXMgY29uc2lzdGVudCB3aXRoIFJGQyA3NzUyLiBCdXQgaXQgd291bGQgYWxzbyBi ZSBnb29kIHRvIGluY2x1ZGUNCmEgc3RhdGVtZW50IGxpa2U6DQoNCiJEZWZpbml0aW9uIG9mIHN1 Y2ggYSBwb2xpY3kgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4iDQoNCk5p dHM6IFBsZWFzZSBzZWUgYXR0YWNoZWQgZGlmZiBmaWxlIHdpdGggc29tZSBlZGl0b3JpYWwgY29y cmVjdGlvbnMuDQoNCg0K --_000_ed8ccfc11e8a4951a2bf67d8ad34e16bXCHALN001ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxl LW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlB1c2hwYXNzaXMg4oCTPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Tb3JyeSBm b3IgdGhlIGRlbGF5IGluIHJlc3BvbmRpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PllvdSBoYXZlIG5vdCBhZGRyZXNzZWQgYWxsIG9mIHRoZSBlZGl0b3JpYWwgY29tbWVudHMgSSBw cm92aWRlZCDigJMgcGxlYXNlIGRvIGEgc2Vjb25kIHBhc3MuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BbHNvLCB0aGVy ZSBpcyBvbmUgc3Vic3RhbnRpdmUgaXNzdWUgd2hpY2ggeW91IGRpZCBub3QgYWRkcmVzczo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxpPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbHQ7c25pcCZndDs8bzpwPjwvbzpw Pjwvc3Bhbj48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TZWN0 aW9uIDMuMSBMYXN0IHBhcmFncmFwaDxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGk+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGk+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgcmVjb2duaXplIHRoaXMg c3RhdGVtZW50IHJlZ2FyZGluZyBwb2xpY3kgYmVpbmcgdXNlZCB0byBmaWx0ZXIgd2hhdCBpczxv OnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPmFkdmVydGlzZWQgaXMgY29uc2lzdGVudCB3aXRoIFJGQyA3NzUyLiBCdXQgaXQgd291bGQg YWxzbyBiZSBnb29kIHRvIGluY2x1ZGU8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxpPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5hIHN0YXRlbWVudCBsaWtlOjxvOnA+PC9vOnA+ PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZxdW90O0RlZmluaXRpb24gb2Ygc3VjaCBhIHBvbGljeSBpcyBvdXRzaWRlIHRoZSBz Y29wZSBvZiB0aGlzIGRvY3VtZW50LiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGk+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZsdDtlbmQgc25pcCZndDs8bzpwPjwv bzpwPjwvc3Bhbj48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklmIHlvdSBoYXZlIGEgY29u Y2VybiB3aXRoIHdoYXQgSSBwcm9wb3NlZCBwbGVhc2UgbGV0IG1lIGtub3cgd2hhdCBpdCBpcy4N CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+VGhhbnguPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgTGVzPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAx LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUHVzaHBh c2lzIFNhcmthciBbbWFpbHRvOnB1c2hwYXNpcy5pZXRmQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNl bnQ6PC9iPiBUdWVzZGF5LCBKdWx5IDA0LCAyMDE3IDg6NTggUE08YnI+DQo8Yj5Ubzo8L2I+IExl cyBHaW5zYmVyZyAoZ2luc2JlcmcpPGJyPg0KPGI+Q2M6PC9iPiBpZHItYWRzQGlldGYub3JnOyBy dGctZGlyQGlldGYub3JnOyBkcmFmdC1pZXRmLWlkci1iZ3AtbHMtbm9kZS1hZG1pbi10YWctZXh0 ZW5zaW9uLmFsbEBpZXRmLm9yZzsgaWRyQGlldGYuIG9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogUnRnRGlyIHJldmlldzogZHJhZnQtaWV0Zi1pZHItYmdwLWxzLW5vZGUtYWRtaW4tdGFnLWV4 dGVuc2lvbi0wMTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5IaSBMZXMsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGFuayB5b3Ugb25jZSBtb3JlIGZvciB0aGUgcmV2aWV3IGNvbW1lbnRzLiBBbmQgc29y cnkgZm9yIHRoZSBsYXRlIHJlcGx5LiBJIGhhdmUgYWRkcmVzc2VkIGFsbCB5b3VyIGNvbW1lbnRz IGluIHRoZSBhdHRhY2hlZCBkcmFmdC4gUGxlYXNlIHJldmlldyB0aGUgc2FtZSBsZXQgbWUga25v dyBpZiB5b3UgaGF2ZSBhbnkgbW9yZSBjb21tZW50cy4gSWYgbm90IEkgd2lsbCB1cGxvYWQgdGhl IGRyYWZ0IHNvb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoYW5rcyBhbmQgcmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi1QdXNocGFzaXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBKdW4gMjgsIDIwMTcgYXQg MTA6MjYgUE0sIFB1c2hwYXNpcyBTYXJrYXIgJmx0OzxhIGhyZWY9Im1haWx0bzpwdXNocGFzaXMu aWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5wdXNocGFzaXMuaWV0ZkBnbWFpbC5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5IaSBMZXMsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGFua3MgYSBsb3QgZm9yIHRoZSByZXZpZXcgY29tbWVudHMuIEkgd2lsbCByZXBseSBiYWNrIGFk ZHJlc3NpbmcgeW91ciBjb21tZW50cyBzb29uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgYW5kIHJlZ2FyZHM8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojODg4ODg4Ij4tUHVzaHBhc2lzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgSnVuIDI3LCAy MDE3IGF0IDExOjM3IFBNLCBMZXMgR2luc2JlcmcgKGdpbnNiZXJnKSAmbHQ7PGEgaHJlZj0ibWFp bHRvOmdpbnNiZXJnQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmdpbnNiZXJnQGNpc2NvLmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVs bG8sPGJyPg0KPGJyPg0KJm5ic3A7SSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIFJvdXRpbmcg RGlyZWN0b3JhdGUgcmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuIFRoZSBSb3V0aW5nIERpcmVjdG9y YXRlIHNlZWtzIHRvIHJldmlldyBhbGwgcm91dGluZyBvciByb3V0aW5nLXJlbGF0ZWQgZHJhZnRz IGFzIHRoZXkgcGFzcyB0aHJvdWdoIElFVEYgbGFzdCBjYWxsIGFuZCBJRVNHIHJldmlldywgYW5k IHNvbWV0aW1lcyBvbiBzcGVjaWFsIHJlcXVlc3QuIFRoZSBwdXJwb3NlIG9mIHRoZQ0KIHJldmll dyBpcyB0byBwcm92aWRlIGFzc2lzdGFuY2UgdG8gdGhlIFJvdXRpbmcgQURzLiBGb3IgbW9yZSBp bmZvcm1hdGlvbiBhYm91dCB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSwgcGxlYXNlIHNlZSZuYnNw Ow0KPGEgaHJlZj0iaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtp L1J0Z0RpciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEv cnRnL3RyYWMvd2lraS9SdGdEaXI8L2E+IC48YnI+DQo8YnI+DQpBbHRob3VnaCB0aGVzZSBjb21t ZW50cyBhcmUgcHJpbWFyaWx5IGZvciB0aGUgdXNlIG9mIHRoZSBSb3V0aW5nIEFEcywgaXQgd291 bGQgYmUgaGVscGZ1bCBpZiB5b3UgY291bGQgY29uc2lkZXIgdGhlbSBhbG9uZyB3aXRoIGFueSBv dGhlciBJRVRGIGNvbW1lbnRzIHRoYXQgeW91IHJlY2VpdmUsIGFuZCBzdHJpdmUgdG8gcmVzb2x2 ZSB0aGVtIHRocm91Z2ggZGlzY3Vzc2lvbiBvciBieSB1cGRhdGluZyB0aGUgZHJhZnQuPGJyPg0K PGJyPg0KPGJyPg0KRG9jdW1lbnQ6IGRyYWZ0LWlldGYtaWRyLWJncC1scy1ub2RlLWFkbWluLXRh Zy1leHRlbnNpb24tMDE8YnI+DQpSZXZpZXdlcjogTGVzIEdpbnNiZXJnPGJyPg0KUmV2aWV3IERh dGU6IEp1bmUgMjcsIDIwMTc8YnI+DQpJbnRlbmRlZCBTdGF0dXM6IFN0YW5kYXJkczxicj4NCjxi cj4NClN1bW1hcnk6Jm5ic3A7IFRoZSBkb2N1bWVudCBpcyBvZiBtb2Rlc3Qgc2NvcGUgLSBjb3Zl cmluZyBkZWZpbml0aW9uIG9mIEJHUC1MUzxicj4NCmNvZGVwb2ludHMgZm9yIGEgcmVsYXRpdmVs eSBuZXcgSUdQIGF0dHJpYnV0ZSAoTm9kZSBBZG1pbiBUYWdzKS48YnI+DQpXaGlsZSBJIGZvdW5k IG5vdGhpbmcgd2hpY2ggSSB3b3VsZCBjb25zaWRlciBhIG1ham9yIGlzc3VlLCB0aGVyZSBhcmUg YSBudW1iZXI8YnI+DQpvZiBwbGFjZXMgd2hlcmUgdGhlIHRleHQgbGFja3MgY2xhcml0eS4gSSB0 aGluayBhZGRyZXNzaW5nIHRoZXNlIGFyZWFzIHdvdWxkPGJyPg0KZ3JlYXRseSBpbXByb3ZlIHRo ZSBxdWFsaXR5IG9mIHRoZSBkcmFmdC48YnI+DQo8YnI+DQo8YnI+DQpNYWpvciBJc3N1ZXM6IE5v bmU8YnI+DQo8YnI+DQpNaW5vciBJc3N1ZXM6PGJyPg0KPGJyPg0KU2VjdGlvbiAxIEludHJvZHVj dGlvbjxicj4NCjxicj4NClRoZSBhY3JvbnltIExTREIgaXMgbm90IGRlZmluZWQuPGJyPg0KPGJy Pg0KRmlndXJlIDE8YnI+DQo8YnI+DQpJIGhhdmUgYSBwZXJzb25hbCBkaXNsaWtlIGZvciBkdXBs aWNhdGluZyB0ZXh0L3BpY3R1cmVzIGZyb20gYW5vdGhlcjxicj4NCnNwZWMgd2hlbiB0aGF0IHNw ZWMgY291bGQgc2ltcGx5IGJlIHJlZmVyZW5jZWQuIFRoZXJlIGFyZSBvbmx5IHR3bzxicj4NCnBv c3NpYmxlIG91dGNvbWVzOjxicj4NCjxicj4NCjEpVGhlIGR1cGxpY2F0ZWQgdGV4dCBpcyByZWR1 bmRhbnQgKGJlc3QgY2FzZSk8YnI+DQoyKVRoZSB0ZXh0IGRpZmZlcnMgc29tZXdoYXQgZnJvbSB0 aGUgb3JpZ2luYWwgbGVhZGluZyB0byBwb3NzaWJsZTxicj4NCnVuaW50ZW50aW9uYWwgbWlzaW50 ZXJwcmV0YXRpb25zLjxicj4NCjxicj4NClN1aXQgeW91cnNlbGYgb24gdGhpcyBjb21tZW50IC0g YnV0IEkgd291bGQgcHJlZmVyIHRoZSBkdXBsaWNhdGlvbiBiZSBvbWl0dGVkLjxicj4NCjxicj4N ClNlY3Rpb24gMiBGaXJzdCBwYXJhZ3JhcGg8YnI+DQo8YnI+DQpZb3UgcmVmZXIgdG8gJnF1b3Q7 c3ViLVRMViZxdW90OyBidXQgdGhhdCByZWZlcmVuY2UgaXMgdW5jbGVhciBhbmQgYW1iaWd1b3Vz Ljxicj4NCklTLUlTIHVzZXMgYSBzdWItVExWIG9mIFJvdXRlciBDYXBhYmlsaXR5IHRvIGFkdmVy dGlzZSB0YWdzLCBidXQgT1NQRjxicj4NCnVzZXMgYSBUTFYgb2YgUm91dGVyIEluZm8gTFNBLjxi cj4NCldoYXQgc2VlbXMgbW9zdCByZWxldmFudCBoZXJlIGlzIHRoYXQgeW91IGFyZSBkZWZpbmlu ZyBhIG5ldyBBdHRyaWJ1dGU8YnI+DQpUTFYgZm9yIE5vZGUgTkxSSS48YnI+DQo8YnI+DQpTZWN0 aW9uIDMgU2Vjb25kIHBhcmFncmFwaDxicj4NCjxicj4NCkkgZG8gbm90IGtub3cgd2hhdCB0aGUg cGFyYWdyYXBoIGlzIHRyeWluZyB0byBzYXksIG5vciBkbzxicj4NCkkga25vdyB3aGF0IHRoZSAm cXVvdDtUQkQmcXVvdDsgaW4gY29sdW1ucyA0IGFuZCA1IGluIHRoZSBmb2xsb3dpbmcgVGFibGUg MSBpczxicj4NCm1lYW50IHRvIHJlZmVyZW5jZS4gSWYgeW91IGFyZSBzaW1wbHkgdHJ5aW5nIHRv IGRlc2NyaWJlIHRoZSBzb3VyY2U8YnI+DQpvZiB0aGUgaW5mbyBhZHZlcnRpc2VkIGJ5IHRoZSBu ZXcgQkdQLUxTIE5vZGUgYXR0cmlidXRlIHRoZW4geW91IHNob3VsZDxicj4NCnJld3JpdGUgdGhl IGFib3ZlIHBhcmFncmFwaCBhbmQgaW4gdGhlIGZpZ3VyZSBiZWxvdyBzaG93Ojxicj4NCjxicj4N CklTLUlTIDI0Mi8yMTxicj4NCk9TUEYgUkktTFNBLzEwPGJyPg0KPGJyPg0KU2VjdGlvbiAzLjE8 YnI+DQo8YnI+DQpBIGRlc2NyaXB0aW9uIG9mIHdoZXJlIGluIHRoZSBOb2RlIE5MUkkgdGhlIGFy ZWEvbGV2ZWwgaW5mb3JtYXRpb24gY2FuIGJlIGZvdW5kPGJyPg0KKGZyb20gUkZDIDc3NTIpIHdv dWxkIGJlIGhlbHBmdWwuPGJyPg0KPGJyPg0KPGJyPg0KU2VjdGlvbiAzLjEgUGVudWx0aW1hdGUg UGFyYWdyYXBoPGJyPg0KPGJyPg0KQXMgVEFHcyB3aXRoICZxdW90O2dsb2JhbCZxdW90OyBzY29w ZSB3aWxsIGJlIGFkdmVydGlzZWQgYnkgdGhlIElHUCBtdWx0aXBsZTxicj4NCnRpbWVzIChvbmNl IHBlciBhcmVhL2xldmVsKSBJIGFzc3VtZSB5b3UgYXJlIGFza2luZyBCR1AtTFMgYWR2ZXJ0aXNl bWVudHM8YnI+DQp0byByZWR1Y2UgdGhlc2UgbXVsdGlwbGUgb2NjdXJyZW5jZXMgdG8gYSBzaW5n bGUgb2NjdXJyZW5jZT8gTW9yZTxicj4NCmV4cGxpY2l0IGxhbmd1YWdlIG9uIHRoYXQgcG9pbnQg d291bGQgYmUgaGVscGZ1bC48YnI+DQo8YnI+DQpTZWN0aW9uIDMuMSBMYXN0IHBhcmFncmFwaDxi cj4NCjxicj4NCkkgcmVjb2duaXplIHRoaXMgc3RhdGVtZW50IHJlZ2FyZGluZyBwb2xpY3kgYmVp bmcgdXNlZCB0byBmaWx0ZXIgd2hhdCBpczxicj4NCmFkdmVydGlzZWQgaXMgY29uc2lzdGVudCB3 aXRoIFJGQyA3NzUyLiBCdXQgaXQgd291bGQgYWxzbyBiZSBnb29kIHRvIGluY2x1ZGU8YnI+DQph IHN0YXRlbWVudCBsaWtlOjxicj4NCjxicj4NCiZxdW90O0RlZmluaXRpb24gb2Ygc3VjaCBhIHBv bGljeSBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50LiZxdW90Ozxicj4NCjxi cj4NCk5pdHM6IFBsZWFzZSBzZWUgYXR0YWNoZWQgZGlmZiBmaWxlIHdpdGggc29tZSBlZGl0b3Jp YWwgY29ycmVjdGlvbnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_ed8ccfc11e8a4951a2bf67d8ad34e16bXCHALN001ciscocom_-- From nobody Mon Jul 10 23:27:07 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E218D131464; Mon, 10 Jul 2017 23:27:04 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 emd7tYtZq7zy; Mon, 10 Jul 2017 23:27:02 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE209131469; Mon, 10 Jul 2017 23:26:58 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML710-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQW22214; Tue, 11 Jul 2017 06:26:57 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 11 Jul 2017 07:26:55 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Tue, 11 Jul 2017 14:26:45 +0800 From: "Dongjie (Jimmy)" To: "'idr wg'" CC: "idr-chairs@ietf.org" Thread-Topic: Draft IDR agenda posted Thread-Index: AdL6DoO8otXRMd6wSiuycnMUdtulwA== Date: Tue, 11 Jul 2017 06:26:44 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C92793724F2F@NKGEML515-MBX.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.151.75] Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C92793724F2FNKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.59646FB1.0035, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 911a59466d55585bc991219ce68d8f56 Archived-At: Subject: [Idr] Draft IDR agenda posted X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 06:27:05 -0000 --_000_76CD132C3ADEF848BD84D028D243C92793724F2FNKGEML515MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, The draft agenda for IDR at IETF 99 has been posted: https://datatracker.ietf.org/meeting/99/agenda/idr/ If you requested a time slot, please check the agenda to make sure it is th= ere. Currently there is still room for new requests, if you plan to have a time = slot, please do so as early as possible. Best regards, Jie --_000_76CD132C3ADEF848BD84D028D243C92793724F2FNKGEML515MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

The draft agenda for IDR at IET= F 99 has been posted:

 

https://datatracke= r.ietf.org/meeting/99/agenda/idr/

 

If you requested a time slot, p= lease check the agenda to make sure it is there.

 

Currently there is still room f= or new requests, if you plan to have a time slot, please do so as early as = possible.

 

Best regards,=

Jie

 

--_000_76CD132C3ADEF848BD84D028D243C92793724F2FNKGEML515MBXchi_-- From nobody Tue Jul 11 06:20:32 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3FA13144D; Tue, 11 Jul 2017 06:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.292 X-Spam-Level: X-Spam-Status: No, score=-4.292 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, LOCALPART_IN_SUBJECT=1.107, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 FRcvCspHHFWd; Tue, 11 Jul 2017 06:20:24 -0700 (PDT) Received: from relais-inet.orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49470127ABE; Tue, 11 Jul 2017 06:20:21 -0700 (PDT) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id B2B5BC0317; Tue, 11 Jul 2017 15:20:19 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.42]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 76206400CC; Tue, 11 Jul 2017 15:20:19 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM41.corporate.adroot.infra.ftgroup ([fe80::c845:f762:8997:ec86%19]) with mapi id 14.03.0352.000; Tue, 11 Jul 2017 15:20:19 +0200 From: To: "draft-li-idr-congestion-status-extended-community@ietf.org" CC: "idr@ietf.org" Thread-Topic: draft-li-idr-congestion-status-extended-community Thread-Index: AdL6QNoQNEeqMklOTpKSZ/LnR6+Lyg== Date: Tue, 11 Jul 2017 13:20:19 +0000 Message-ID: <12536_1499779219_5964D093_12536_99_1_53C29892C857584299CBF5D05346208A477FE298@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Idr] draft-li-idr-congestion-status-extended-community X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 13:20:26 -0000 Hi authors, Please find below some minor comments.=20 =A72 Congestion Status Extended Community > The "Utilization" field is 1 octet. Its value is the utilization of the = exit link in unit of percent - Is this the utilization on the link or before the link (i.e. before dropp= ing the traffic in excess) ? IOW, can this be greater than 100%? I think I'= d prefer the latter, but in all cases, I like to see a text detailing the h= andling of numbers > 100%.=20 - In order to offer more granularity, sometimes the traffic is rate limited= to a capacity smaller than the physical link. e.g. the physical link has 1= 0G of traffic, but only 3G is available to the user. Please explicit whethe= r you are referring to physical or "real"/"offered"/"available" capacity. O= n my side, I'd prefer the latter. > The "Bandwidth" field is 1 octet. Its value is the bandwidth of the exit= link in unit of 10 gbps (gigabits per second). I don't see that this is extremely future proof, as the usable range is 1-2= 55. When this proposition gets used (in years from now), 100G links would p= resumably be the default. Meaning we would already have consumed *10 from t= he budget. Only leaving *25 for the future. I'd prefer a wider range with l= ess precision. e.g. bandwidth is 10^^bandwidth in gbps. (or 2^^). > The link with bandwidth less than 10 gbps is not suitable to use this fea= ture. Why not? It looks to me that the %Utilization could be useful even if the b= andwidth is not advertised. Possibly a "Bandwidth" reserved value (e.g. 0) = could be specified to indicate that the bandwidth is not advertised. This w= ould also fit the case where some ASes do not want to advertise their link = capacity. =A73. Application Considerations > The SDN controller uses the exit link utilization information to steer th= e Internet access traffic among all the exit links from the perspective of = the whole network. Indeed, presumably this information is used to influence the routing behavi= or. May be the document should indicate that the reception of such communit= y over IBGP session should not influence routing decision unless tunneling = is used to reach the BGP Next-Hop. (to avoid forwarding loops, incremental = deployment issues, complications in error handling). In addition, what are the interactions with the BGP Link Bandwidth Extended= communities? https://tools.ietf.org/html/draft-ietf-idr-link-bandwidth (I= know that the draft expired, but still it's a WG document and an official = IANA code point) Ships in the night?=20 > To avoid route oscillation, the exit router SHOULD set a threshold. W= hen the utilization change reaches the threshold, the exit router SHOULD g= enerate a BGP update message with congestion status extended community. I think that the document should better evaluate the churn introduced. In p= articular the churn is cumulative as the number of ASes crossed increase. e= .g. if we assume that each AS use the community quite carefully by not adve= rtising more than 1 update per hour, if we have 5 ASes on the way, the ingr= ess AS can receive 5 (additional) updates per prefix per hour. 4. Security Considerations > This new extended community does not directly introduce any new security = issues. What about trust/cheating considerations? Especially from remote ASes with = which you have zero relationship? e.g. advertising alleged congestion in order to TE/influence routing of oth= ers ASes, advertising plenty of fake capacity to attract more traffic/custo= mers, advertising that they are never experiencing any congestion for comme= rcial reasons, fake advertisement on "behalf" of other ASes... Thanks, Regards, --Bruno ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Jul 12 23:01:22 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C13713181C; Wed, 12 Jul 2017 23:01:21 -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 UD4FHF8uTzei; Wed, 12 Jul 2017 23:01:19 -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 DBF7E12EC06; Wed, 12 Jul 2017 23:01:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20282; q=dns/txt; s=iport; t=1499925678; x=1501135278; h=from:to:cc:subject:date:message-id:mime-version; bh=hxYy5JGcNU6Twu0pC1cJP1cYNE8WUXGQff108S/hLMs=; b=lNusz20X3X7Tsdn6Mw5cihLTTqBoo1/gsMy/vrepxdXFJ1EFVH836Sza 2mJLGrmwe8eIeAjLh70L5pZIsvw+8fEVDF1ccabzF5mqWRtf7GUg/Yr2E eJLQ/QIvE2CpltnDrKhByVSdDtOXU0elrflIAoiV8enej7zfPHcVJXHHy 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoAACWC2dZ/4wNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm8+LWSBFAeOApFydI9jhSyCESEBCoVKAhqDPj8YAQIBAQEBAQE?= =?us-ascii?q?BayiFGAEBAQEEASEKQQsMBgEZBAEBKAMCBCULFAkJAQQBDQUIiUNkEK1pgiaLI?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBAR2DKINNgWABgnA0gyaBWw8QCIJVgmEFiWO?= =?us-ascii?q?NWodvAodGg0iId4IVV4EPg2WKUJVSAQ8QOIEKdRUfKoUTHIFndodMgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.40,352,1496102400"; d="scan'208,217";a="269412946" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Jul 2017 06:01:17 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v6D61HrI027465 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 13 Jul 2017 06:01:17 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 13 Jul 2017 01:01:16 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1210.000; Thu, 13 Jul 2017 01:01:16 -0500 From: "Ketan Talaulikar (ketant)" To: Stefano Previdi , Susan Hares , "'idr wg'" , Jeff Tantsura CC: "draft-ietf-idr-bgp-ls-segment-routing-ext@ietf.org" , "draft-ietf-idr-te-pm-bgp@ietf.org" Thread-Topic: Regd BGP-LS code points early allocation for WG adopted drafts Thread-Index: AdL7nWosFbh13zxaTe29YgdiZl93UQ== Date: Thu, 13 Jul 2017 06:01:16 +0000 Message-ID: <999f002984de432bb168f60309d66b63@XCH-ALN-008.cisco.com> 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.65.80.235] Content-Type: multipart/alternative; boundary="_000_999f002984de432bb168f60309d66b63XCHALN008ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Idr] Regd BGP-LS code points early allocation for WG adopted drafts X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 06:01:22 -0000 --_000_999f002984de432bb168f60309d66b63XCHALN008ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCk1heSBJIHJlcXVlc3QgdGhlIGF1dGhvcnMgb2YgdGhlIGRyYWZ0LWlldGYtaWRy LWJncC1scy1zZWdtZW50LXJvdXRpbmctZXh0IGFuZCBkcmFmdC1pZXRmLWlkci10ZS1wbS1iZ3Ag YW5kIFdHIGNoYWlycyB0byBwbGVhc2UgcmVxdWVzdCBmb3IgZWFybHkgYWxsb2NhdGlvbiBvZiB0 aGVpciBJQU5BIGNvZGUgcG9pbnRzPw0KDQpBbHNvLCB0aGUgbGluayBNU0QgY29kZXBvaW50IGlu IGRyYWZ0LXRhbnRzdXJhLWlkci1iZ3AtbHMtc2VnbWVudC1yb3V0aW5nLW1zZCBjb2xsaWRlcyB3 aXRoIHRoZSBzdWdnZXN0ZWQgY29kZXBvaW50cyBpbiBkcmFmdC1pZXRmLWlkci10ZS1wbS1iZ3Au IEVhcmx5IGFsbG9jYXRpb25zIGZvciBXRyBhZG9wdGVkIGRyYWZ0cyB3b3VsZCBoZWxwIGF2b2lk IGNvbGxpc2lvbnMuDQoNCkplZmYsIG1heSBJIHN1Z2dlc3QgdG8gcmVxdWVzdCB0aGUgY29kZSBw b2ludCAxMTExIGZvciB0aGUgTGluayBNU0Qgc2luY2UgdGhlIFRFIFBNIGRyYWZ0IGlzIGFscmVh ZHkgYSBXRyBpdGVtIGFuZCB0aGVyZSBtYXkgYmUgaW1wbGVtZW50YXRpb25zIG91dCB0aGVyZSBh bHJlYWR5Pw0KDQpUaGFua3MsDQpLZXRhbg0KDQpGcm9tOiBJZHIgW21haWx0bzppZHItYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFN0ZWZhbm8gUHJldmlkaQ0KU2VudDogMjggSnVuZSAy MDE3IDIxOjUxDQpUbzogU3VzYW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbT47ICdpZHIgd2cnIDxp ZHJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0lkcl0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1p ZHItYmdwLWxzLXNlZ21lbnQtcm91dGluZy1leHQtMDIudHh0DQoNCkhpIFN1ZSwNCg0KWWVzLCB0 aGF0IGRlZmluaXRlbHkgd291bGQgaGVscC4NCg0KVGhhbmtzLg0KDQpzLg0KT24gSnVuZSAyOCwg MjAxNyA1OjM2OjQ2IFBNIEdNVCswMjowMCwgU3VzYW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbTxt YWlsdG86c2hhcmVzQG5kemguY29tPj4gd3JvdGU6DQoNClN0ZWZhbm86DQoNCkRpZCB5b3Ugd2Fu dCBlYXJseSBhbGxvY2F0aW9uIGZvciB0aGUgY29kZSBwb2ludHMgd2hpbGUgd2Ugd29yayB0aHJv dWdoIHRoZSBkb2N1bWVudGF0aW9uIHByb2Nlc3M/ICAgSWYgc28sIEkgd2lsbCBpbmNsdWRlIHRo aXMgaW4gdGhlIFdHIExDLg0KDQpTdWUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IElkciBbbWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Ygc3RlZmFu byBwcmV2aWRpDQpTZW50OiBNb25kYXksIEp1bmUgMjYsIDIwMTcgMzowOCBBTQ0KVG86IGlkciB3 Zw0KU3ViamVjdDogUmU6IFtJZHJdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtaWRyLWJncC1scy1z ZWdtZW50LXJvdXRpbmctZXh0LTAyLnR4dA0KDQpGWUksDQoNCnRoaXMgdmVyc2lvbiBoYXMgYmVl biBjbGVhbmVkIHVwIGZyb20gYWxsIHVudXNlZCBUTFZzIGFjY29yZGluZyB0byB0aGUgY2hhbmdl cyBiZWluZyBkb25lIGluIGRyYWZ0LWlldGYtW29zcGZ8aXNpc10tc2VnbWVudC1yb3V0aW5nLWV4 dGVuc2lvbnMuDQoNCkR1ZSB0byB0aGUgbnVtYmVyIG9mIGNvZGVwb2ludHMgdGhpcyBkcmFmdHMg cHJvcG9zZXMsIEnigJlkIGxpa2UgdG8gYXNrIHRoZSBjaGFpcnMgdG8gY29uc2lkZXIgdGhlIGRv Y3VtZW50IGZvciBwdWJsaWNhdGlvbi4NCg0KVGhhbmtzLg0Kcy4NCg0KDQoNCg0KIE9uIEp1biAy NiwgMjAxNywgYXQgODo1NiBBTSwgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0KDQoNCiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBp cyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMu DQogVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgSW50ZXItRG9tYWluIFJvdXRpbmcg b2YgdGhlIElFVEYuDQoNCiAgICAgICAgVGl0bGUgICAgICAgICAgIDogQkdQIExpbmstU3RhdGUg ZXh0ZW5zaW9ucyBmb3IgU2VnbWVudCBSb3V0aW5nDQogICAgICAgIEF1dGhvcnMgICAgICAgICA6 IFN0ZWZhbm8gUHJldmlkaQ0KICAgICAgICAgICAgICAgICAgICAgICAgICBQZXRlciBQc2VuYWsN CiAgICAgICAgICAgICAgICAgICAgICAgICAgQ2xhcmVuY2UgRmlsc2ZpbHMNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgSGFubmVzIEdyZWRsZXINCiAgICAgICAgICAgICAgICAgICAgICAgICAg TWFjaChHdW95aSkgQ2hlbg0KICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWlkci1iZ3At bHMtc2VnbWVudC1yb3V0aW5nLWV4dC0wMi50eHQNCiAgUGFnZXMgICAgICAgICAgIDogMjcNCiAg RGF0ZSAgICAgICAgICAgIDogMjAxNy0wNi0yNQ0KDQogQWJzdHJhY3Q6DQogICBTZWdtZW50IFJv dXRpbmcgKFNSKSBhbGxvd3MgZm9yIGEgZmxleGlibGUgZGVmaW5pdGlvbiBvZiBlbmQtdG8tZW5k DQogICBwYXRocyB3aXRoaW4gSUdQIHRvcG9sb2dpZXMgYnkgZW5jb2RpbmcgcGF0aHMgYXMgc2Vx dWVuY2VzIG9mDQogICB0b3BvbG9naWNhbCBzdWItcGF0aHMsIGNhbGxlZCAic2VnbWVudHMiLiAg VGhlc2Ugc2VnbWVudHMgYXJlDQogICBhZHZlcnRpc2VkIGJ5IHRoZSBsaW5rLXN0YXRlIHJvdXRp bmcgcHJvdG9jb2xzIChJUy1JUywgT1NQRiBhbmQNCiAgIE9TUEZ2MykuDQoNCiAgIFRoaXMgZHJh ZnQgZGVmaW5lcyBleHRlbnNpb25zIHRvIHRoZSBCR1AgTGluay1zdGF0ZSBhZGRyZXNzLWZhbWls eSBpbg0KICAgb3JkZXIgdG8gY2Fycnkgc2VnbWVudCBpbmZvcm1hdGlvbiB2aWEgQkdQLg0KDQoN Cg0KIFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0K IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaWRyLWJncC1scy1z ZWdtZW50LXJvdXRpbmcNCiAtZXh0Lw0KDQogVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lv bnMgYXZhaWxhYmxlIGF0Og0KIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LWlkci1iZ3AtbHMtc2VnbWVudC1yb3V0aW5nLWV4dC0NCiAwMg0KIGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1pZHItYmdwLWxzLXNlZ21lbnQtcm8NCiB1 dGluZy1leHQtMDINCg0KIEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWls YWJsZSBhdDoNCiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1p ZHItYmdwLWxzLXNlZ21lbnQtcm91dGluDQogZy1leHQtMDINCg0KDQogUGxlYXNlIG5vdGUgdGhh dCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCiBzdWJt aXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUg YXQgdG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rvb2xzLmlldGYub3JnPi4NCg0KIEludGVybmV0LURy YWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCiBmdHA6Ly9mdHAu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzPGh0dHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzPi8NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQogSWRyIG1haWxp bmcgbGlzdA0KIElkckBpZXRmLm9yZzxtYWlsdG86SWRyQGlldGYub3JnPg0KIGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQoNCg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KDQpJZHIgbWFpbGluZyBsaXN0DQpJZHJAaWV0Zi5vcmc8bWFpbHRvOklk ckBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQo= --_000_999f002984de432bb168f60309d66b63XCHALN008ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7 DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVm b3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcy LjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tSU4iIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij5IZWxsbyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPk1heSBJIHJl cXVlc3QgdGhlIGF1dGhvcnMgb2YgdGhlIGRyYWZ0LWlldGYtaWRyLWJncC1scy1zZWdtZW50LXJv dXRpbmctZXh0IGFuZCBkcmFmdC1pZXRmLWlkci10ZS1wbS1iZ3AgYW5kIFdHIGNoYWlycyB0byBw bGVhc2UgcmVxdWVzdA0KIGZvciBlYXJseSBhbGxvY2F0aW9uIG9mIHRoZWlyIElBTkEgY29kZSBw b2ludHM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5BbHNvLCB0aGUg bGluayBNU0QgY29kZXBvaW50IGluIGRyYWZ0LXRhbnRzdXJhLWlkci1iZ3AtbHMtc2VnbWVudC1y b3V0aW5nLW1zZCBjb2xsaWRlcyB3aXRoIHRoZSBzdWdnZXN0ZWQgY29kZXBvaW50cyBpbiBkcmFm dC1pZXRmLWlkci10ZS1wbS1iZ3AuDQogRWFybHkgYWxsb2NhdGlvbnMgZm9yIFdHIGFkb3B0ZWQg ZHJhZnRzIHdvdWxkIGhlbHAgYXZvaWQgY29sbGlzaW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPkplZmYsIG1heSBJIHN1Z2dlc3QgdG8gcmVxdWVzdCB0aGUgY29k ZSBwb2ludCAxMTExIGZvciB0aGUgTGluayBNU0Qgc2luY2UgdGhlIFRFIFBNIGRyYWZ0IGlzIGFs cmVhZHkgYSBXRyBpdGVtIGFuZCB0aGVyZSBtYXkgYmUgaW1wbGVtZW50YXRpb25zDQogb3V0IHRo ZXJlIGFscmVhZHk/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGFu a3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPktldGFuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IElkciBbbWFpbHRvOmlkci1ib3Vu Y2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5TdGVmYW5vIFByZXZpZGk8YnI+DQo8 Yj5TZW50OjwvYj4gMjggSnVuZSAyMDE3IDIxOjUxPGJyPg0KPGI+VG86PC9iPiBTdXNhbiBIYXJl cyAmbHQ7c2hhcmVzQG5kemguY29tJmd0OzsgJ2lkciB3ZycgJmx0O2lkckBpZXRmLm9yZyZndDs8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJZHJdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtaWRy LWJncC1scy1zZWdtZW50LXJvdXRpbmctZXh0LTAyLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SGkg U3VlLDxicj4NCjxicj4NClllcywgdGhhdCBkZWZpbml0ZWx5IHdvdWxkIGhlbHAuPGJyPg0KPGJy Pg0KVGhhbmtzLjxicj4NCjxicj4NCnMuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gSnVuZSAyOCwgMjAxNyA1OjM2OjQ2IFBNIEdNVCYjNDM7MDI6MDAsIFN1 c2FuIEhhcmVzICZsdDs8YSBocmVmPSJtYWlsdG86c2hhcmVzQG5kemguY29tIj5zaGFyZXNAbmR6 aC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBj bSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cHJlIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+U3RlZmFubzogPGJyPjxicj5EaWQgeW91IHdhbnQg ZWFybHkgYWxsb2NhdGlvbiBmb3IgdGhlIGNvZGUgcG9pbnRzIHdoaWxlIHdlIHdvcmsgdGhyb3Vn aCB0aGUgZG9jdW1lbnRhdGlvbiBwcm9jZXNzPyZuYnNwOyZuYnNwOyBJZiBzbywgSSB3aWxsIGlu Y2x1ZGUgdGhpcyBpbiB0aGUgV0cgTEMuIDxicj48YnI+U3VlIDxicj48YnI+LS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS08YnI+RnJvbTogSWRyIFs8YSBocmVmPSJtYWlsdG86aWRyLWJvdW5jZXNA aWV0Zi5vcmciPm1haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBz dGVmYW5vIHByZXZpZGk8YnI+U2VudDogTW9uZGF5LCBKdW5lIDI2LCAyMDE3IDM6MDggQU08YnI+ VG86IGlkciB3Zzxicj5TdWJqZWN0OiBSZTogW0lkcl0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1p ZHItYmdwLWxzLXNlZ21lbnQtcm91dGluZy1leHQtMDIudHh0PGJyPjxicj5GWUksPGJyPjxicj50 aGlzIHZlcnNpb24gaGFzIGJlZW4gY2xlYW5lZCB1cCBmcm9tIGFsbCB1bnVzZWQgVExWcyBhY2Nv cmRpbmcgdG8gdGhlIGNoYW5nZXMgYmVpbmcgZG9uZSBpbiBkcmFmdC1pZXRmLVtvc3BmfGlzaXNd LXNlZ21lbnQtcm91dGluZy1leHRlbnNpb25zLjxicj48YnI+RHVlIHRvIHRoZSBudW1iZXIgb2Yg Y29kZXBvaW50cyB0aGlzIGRyYWZ0cyBwcm9wb3NlcywgSeKAmWQgbGlrZSB0byBhc2sgdGhlIGNo YWlycyB0byBjb25zaWRlciB0aGUgZG9jdW1lbnQgZm9yIHB1YmxpY2F0aW9uLjxicj48YnI+VGhh bmtzLjxicj5zLjxicj48YnI+PGJyPjxicj48bzpwPjwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICM3MjlGQ0YgMS4wcHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtO21h cmdpbi1ib3R0b206Ni4wcHQiPg0KPHByZT4gT24gSnVuIDI2LCAyMDE3LCBhdCA4OjU2IEFNLCA8 YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIj5pbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmc8L2E+IHdyb3RlOjxicj4gPGJyPiZuYnNwOzxicj4mbmJzcDtBIE5ldyBJbnRlcm5l dC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGly ZWN0b3JpZXMuPGJyPiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBJbnRlci1Eb21h aW4gUm91dGluZyBvZiB0aGUgSUVURi48YnI+IDxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtUaXRsZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IEJHUCBMaW5rLVN0YXRlIGV4dGVuc2lv bnMgZm9yIFNlZ21lbnQgUm91dGluZzxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgQXV0aG9ycyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyA6IFN0ZWZhbm8gUHJldmlkaTxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgUGV0ZXIgUHNlbmFrPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBDbGFyZW5jZSBGaWxzZmlsczxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7SGFubmVzIEdyZWRsZXI8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IE1hY2goR3VveWkpIENoZW48YnI+Jm5ic3A7IEZpbGVuYW1lJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogZHJhZnQtaWV0Zi1pZHItYmdwLWxzLXNlZ21l bnQtcm91dGluZy1leHQtMDIudHh0PGJyPiZuYnNwOyBQYWdlcyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IDI3PGJyPiZuYnNwOyBE YXRlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDogMjAxNy0wNi0yNTxicj4gPGJyPiZuYnNwO0Fic3RyYWN0Ojxicj4mbmJz cDsmbmJzcDsgU2VnbWVudCBSb3V0aW5nIChTUikgYWxsb3dzIGZvciBhIGZsZXhpYmxlIGRlZmlu aXRpb24gb2YgZW5kLXRvLWVuZDxicj4mbmJzcDsmbmJzcDsgcGF0aHMgd2l0aGluIElHUCB0b3Bv bG9naWVzIGJ5IGVuY29kaW5nIHBhdGhzIGFzIHNlcXVlbmNlcyBvZjxicj4mbmJzcDsmbmJzcDsg dG9wb2xvZ2ljYWwgc3ViLXBhdGhzLCBjYWxsZWQgJnF1b3Q7c2VnbWVudHMmcXVvdDsuJm5ic3A7 IFRoZXNlIHNlZ21lbnRzIGFyZTxicj4mbmJzcDsmbmJzcDsgYWR2ZXJ0aXNlZCBieSB0aGUgbGlu ay1zdGF0ZSByb3V0aW5nIHByb3RvY29scyAoSVMtSVMsIE9TUEYgYW5kPGJyPiZuYnNwOyZuYnNw OyBPU1BGdjMpLjxicj4gPGJyPiZuYnNwOyZuYnNwOyZuYnNwO1RoaXMgZHJhZnQgZGVmaW5lcyBl eHRlbnNpb25zIHRvIHRoZSBCR1AgTGluay1zdGF0ZSBhZGRyZXNzLWZhbWlseSBpbjxicj4mbmJz cDsmbmJzcDsgb3JkZXIgdG8gY2Fycnkgc2VnbWVudCBpbmZvcm1hdGlvbiB2aWEgQkdQLjxicj4g PGJyPiZuYnNwOzxicj4mbmJzcDs8YnI+Jm5ic3A7VGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVz IHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6PGJyPiA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWlkci1iZ3AtbHMtc2VnbWVudC1yb3V0aW5nIj5odHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWlkci1iZ3AtbHMtc2VnbWVu dC1yb3V0aW5nPC9hPjxicj4gLWV4dC88YnI+IDxicj4mbmJzcDtUaGVyZSBhcmUgYWxzbyBodG1s aXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6PGJyPiA8YSBocmVmPSJodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pZHItYmdwLWxzLXNlZ21lbnQtcm91dGluZy1leHQiPmh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlkci1iZ3AtbHMtc2VnbWVudC1y b3V0aW5nLWV4dDwvYT4tPGJyPiAwMjxicj4gPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLWlkci1iZ3AtbHMtc2VnbWVudC1ybyI+aHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLWlkci1iZ3AtbHMtc2Vn bWVudC1ybzwvYT48YnI+IHV0aW5nLWV4dC0wMjxicj4gPGJyPiZuYnNwO0EgZGlmZiBmcm9tIHRo ZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDo8YnI+IDxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWlkci1iZ3AtbHMtc2VnbWVudC1y b3V0aW4iPmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWlkci1i Z3AtbHMtc2VnbWVudC1yb3V0aW48L2E+PGJyPiBnLWV4dC0wMjxicj4gPGJyPiZuYnNwOzxicj4m bmJzcDtQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJv bSB0aGUgdGltZSBvZiA8YnI+Jm5ic3A7c3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVy c2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRm Lm9yZyI+dG9vbHMuaWV0Zi5vcmc8L2E+Ljxicj4gPGJyPiZuYnNwO0ludGVybmV0LURyYWZ0cyBh cmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDo8YnI+IGZ0cDovLzxhIGhyZWY9 Imh0dHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzIj5mdHAuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzPC9hPi88YnI+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJ0ZXh0LWFs aWduOmNlbnRlciI+PGhyIHNpemU9IjQiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj48L3By ZT4NCjxwcmU+PGJyPiZuYnNwO0lkciBtYWlsaW5nIGxpc3Q8YnI+IDxhIGhyZWY9Im1haWx0bzpJ ZHJAaWV0Zi5vcmciPklkckBpZXRmLm9yZzwvYT48YnI+IDxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2lkcjwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT48 bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxo ciBzaXplPSI0IiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+PC9wcmU+DQo8cHJlIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPklkciBtYWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0i bWFpbHRvOklkckBpZXRmLm9yZyI+SWRyQGlldGYub3JnPC9hPjxicj48YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkciI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9pZHI8L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_999f002984de432bb168f60309d66b63XCHALN008ciscocom_-- From nobody Thu Jul 13 17:25:00 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 782B912ECC3; Thu, 13 Jul 2017 17:24:58 -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 NPhfrAHv7EZW; Thu, 13 Jul 2017 17:24:55 -0700 (PDT) Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DCA812EC1D; Thu, 13 Jul 2017 17:24:55 -0700 (PDT) Received: by mail-yb0-x232.google.com with SMTP id n205so25784257yba.1; Thu, 13 Jul 2017 17:24:55 -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=DDQECpu3+4PIuSuZobw6DvlcSennzr9pkmUjh+TWrKE=; b=dXAZhTb2wwaPSAMVVSo1LvSsFuRZdX0jFcXSG4rHSSbvi+18EgYEbxgMaDYMl7xL2u oQSMIvqyiCFJEjVse0GhBSP4pVdrp5zQ5PPoTWbSO6Mh1eG8yHhMhUsPdPpG2Vxd6dba d4ojmKf1ekqffCPkTRuZ6aZ91F30nBiN83v66d2cmq30gDB8ABUql3rfPEUVjnfLhtG9 9NQlx0K7SA+RfgmWXfgQWaQ6ZLM4yLQ2Jb8wCmhPU1sisyct3ynO//M8g+wf+NmCqTuN 6mAC/ts21mdnO6EoQreGB3Au4BNZ2Y8mGEGFLOQ02AjB9YltBEZ7hJCrulfMpf93gwrZ zXug== 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=DDQECpu3+4PIuSuZobw6DvlcSennzr9pkmUjh+TWrKE=; b=LGJtXjG1uZ7/WoojvV8LuCzueRBFGAa98OnIwOuUT54ql1+yvcAQWjOGZc1dWtsV33 BrwSmIvJpVYcGO0Jy/6MBoVEwpb9gGSkbTBvGrG4DsQ401EUETmqZsh76ykPLNtRzor+ n6V3xcfSqrOWKFWmim7SXFys0k19V/tooYjMPuPhzKdtN8KTa3QMn3TU82lV0SYZnCyy eymjf7DDmEBJGObI6p1pncuWibZqOoS91KZzH/+nvUvE4hBwy+nTxydfeZxcoGbhm+Mg OoVTUPRaPnAciu1TD4AsbKMg83eZn38YoRIXKzTBePnqg7pwF0saRc7n/fQjkVhTs73Y CTNw== X-Gm-Message-State: AIVw112uVQkOYiCwBXyB9ZREPRrz/X791cyvp54I+sPBVXVQ244A2AOM 1RpHTXfMkZeH/alkr5qsKKuoKojx8Q== X-Received: by 10.129.116.134 with SMTP id p128mr4114701ywc.262.1499991894741; Thu, 13 Jul 2017 17:24:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.46.129 with HTTP; Thu, 13 Jul 2017 17:24:54 -0700 (PDT) In-Reply-To: References: From: Pushpasis Sarkar Date: Thu, 13 Jul 2017 17:24:54 -0700 Message-ID: To: "Les Ginsberg (ginsberg)" Cc: "idr-ads@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-idr-bgp-ls-node-admin-tag-extension.all@ietf.org" , "idr@ietf. org" Content-Type: multipart/alternative; boundary="001a1147f9ea0d569705543c1413" Archived-At: Subject: Re: [Idr] RtgDir review: draft-ietf-idr-bgp-ls-node-admin-tag-extension-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2017 00:24:59 -0000 --001a1147f9ea0d569705543c1413 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Les, Sorry once again for the late response. Please find comments inline... On Sat, Jul 8, 2017 at 1:42 PM, Les Ginsberg (ginsberg) wrote: > Pushpassis =E2=80=93 > > > > Sorry for the delay in responding. > > You have not addressed all of the editorial comments I provided =E2=80=93= please > do a second pass. > [Pushpasis] I did a second pass.. But I could not locate which one(s) I missed out. It will be great if you list them out for me. The htmlized diff you attached earlier does not exactly highlight the diffs.. :( Request your help here... > > > Also, there is one substantive issue which you did not address: > > > > ** > > *Section 3.1 Last paragraph* > > > > *I recognize this statement regarding policy being used to filter what is= * > > *advertised is consistent with RFC 7752. But it would also be good to > include* > > *a statement like:* > > > > *"Definition of such a policy is outside the scope of this document."* > > ** > > > > If you have a concern with what I proposed please let me know what it is. > [Pushpasis] I will be very happy to add the statement. Thanks a lot for the suggestion. Thanks and Regards, -Pushpasis > > > Thanx. > > > > Les > > > > > > > > *From:* Pushpasis Sarkar [mailto:pushpasis.ietf@gmail.com] > *Sent:* Tuesday, July 04, 2017 8:58 PM > *To:* Les Ginsberg (ginsberg) > *Cc:* idr-ads@ietf.org; rtg-dir@ietf.org; draft-ietf-idr-bgp-ls-node- > admin-tag-extension.all@ietf.org; idr@ietf. org > *Subject:* Re: RtgDir review: draft-ietf-idr-bgp-ls-node- > admin-tag-extension-01 > > > > Hi Les, > > > > Thank you once more for the review comments. And sorry for the late reply= . > I have addressed all your comments in the attached draft. Please review t= he > same let me know if you have any more comments. If not I will upload the > draft soon. > > > > Thanks and regards, > > -Pushpasis > > > > On Wed, Jun 28, 2017 at 10:26 PM, Pushpasis Sarkar < > pushpasis.ietf@gmail.com> wrote: > > Hi Les, > > > > Thanks a lot for the review comments. I will reply back addressing your > comments soon. > > > > Thanks and regards > > -Pushpasis > > > > On Tue, Jun 27, 2017 at 11:37 PM, Les Ginsberg (ginsberg) < > ginsberg@cisco.com> wrote: > > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF last call and IESG review, and sometimes > on special request. The purpose of the review is to provide assistance to > the Routing ADs. For more information about the Routing Directorate, plea= se > see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir . > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF > comments that you receive, and strive to resolve them through discussion = or > by updating the draft. > > > Document: draft-ietf-idr-bgp-ls-node-admin-tag-extension-01 > Reviewer: Les Ginsberg > Review Date: June 27, 2017 > Intended Status: Standards > > Summary: The document is of modest scope - covering definition of BGP-LS > codepoints for a relatively new IGP attribute (Node Admin Tags). > While I found nothing which I would consider a major issue, there are a > number > of places where the text lacks clarity. I think addressing these areas > would > greatly improve the quality of the draft. > > > Major Issues: None > > Minor Issues: > > Section 1 Introduction > > The acronym LSDB is not defined. > > Figure 1 > > I have a personal dislike for duplicating text/pictures from another > spec when that spec could simply be referenced. There are only two > possible outcomes: > > 1)The duplicated text is redundant (best case) > 2)The text differs somewhat from the original leading to possible > unintentional misinterpretations. > > Suit yourself on this comment - but I would prefer the duplication be > omitted. > > Section 2 First paragraph > > You refer to "sub-TLV" but that reference is unclear and ambiguous. > IS-IS uses a sub-TLV of Router Capability to advertise tags, but OSPF > uses a TLV of Router Info LSA. > What seems most relevant here is that you are defining a new Attribute > TLV for Node NLRI. > > Section 3 Second paragraph > > I do not know what the paragraph is trying to say, nor do > I know what the "TBD" in columns 4 and 5 in the following Table 1 is > meant to reference. If you are simply trying to describe the source > of the info advertised by the new BGP-LS Node attribute then you should > rewrite the above paragraph and in the figure below show: > > IS-IS 242/21 > OSPF RI-LSA/10 > > Section 3.1 > > A description of where in the Node NLRI the area/level information can be > found > (from RFC 7752) would be helpful. > > > Section 3.1 Penultimate Paragraph > > As TAGs with "global" scope will be advertised by the IGP multiple > times (once per area/level) I assume you are asking BGP-LS advertisements > to reduce these multiple occurrences to a single occurrence? More > explicit language on that point would be helpful. > > Section 3.1 Last paragraph > > I recognize this statement regarding policy being used to filter what is > advertised is consistent with RFC 7752. But it would also be good to > include > a statement like: > > "Definition of such a policy is outside the scope of this document." > > Nits: Please see attached diff file with some editorial corrections. > > > > > --001a1147f9ea0d569705543c1413 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Les,

Sorry once again for the late r= esponse. Please find comments inline...


On Sat, Jul 8, 2017 at 1:42 PM, = Les Ginsberg (ginsberg) <ginsberg@cisco.com> wrote:

Pushpassis =E2=80=93

=C2=A0

Sorry for the delay in re= sponding.

You have not addressed al= l of the editorial comments I provided =E2=80=93 please do a second pass.

[Pushpasis] I did a second pass.. Bu= t I could not locate which one(s) I missed out. It will be great if you lis= t them out for me. The htmlized diff you attached earlier does not exactly = highlight the diffs.. :( Request your help here...=C2=A0
=C2=A0

=C2=A0

Also, there is one substa= ntive issue which you did not address:

=C2=A0

<snip>

Section 3.1 Last paragraph

=C2=A0

I recognize this statement regarding policy being used to filter what = is

advertised is consistent with RFC 7752. But it would also be good to i= nclude

a statement like:

=C2=A0

"Definition of such a policy is outside the scope of this documen= t."

<end snip>

=C2=A0

If you have a concern wit= h what I proposed please let me know what it is.

[Pushpasis] I will be very happy to add the statement.=C2=A0 = Thanks a lot for the suggestion.

Thanks and Regard= s,
-Pushpasis

=C2=A0

Thanx.

=C2=A0

=C2=A0=C2=A0 Les

=C2=A0

=C2=A0

=C2=A0

From: Pushpasi= s Sarkar [mailto:pushpasis.ietf@gmail.com]
Sent: Tuesday, July 04, 2017 8:58 PM
To: Les Ginsberg (ginsberg)
Cc: idr-ads@ie= tf.org; rtg-dir@i= etf.org; draft-ietf-idr-bgp-ls-node-admin-ta= g-extension.all@ietf.org; idr@ietf. org
Subject: Re: RtgDir review: draft-ietf-idr-bgp-ls-node-admin-ta= g-extension-01

=C2=A0

Hi Les,

=C2=A0

Thank you once more for the review comments. And sor= ry for the late reply. I have addressed all your comments in the attached d= raft. Please review the same let me know if you have any more comments. If = not I will upload the draft soon.

=C2=A0

Thanks and regards,

-Pushpasis

=C2=A0

On Wed, Jun 28, 2017 at 10:26 PM, Pushpasis Sarkar &= lt;pushpasis.= ietf@gmail.com> wrote:

Hi Les,

=C2=A0

Thanks a lot for the review comments. I will reply b= ack addressing your comments soon.

=C2=A0

Thanks and regards

-Pushpasis

=C2=A0

On Tue, Jun 27, 2017 at 11:37 PM, Les Ginsberg (gins= berg) <ginsberg@= cisco.com> wrote:

Hello,

=C2=A0I have been selected as the Routing Directorate reviewer for this dra= ft. The Routing Directorate seeks to review all routing or routing-related = drafts as they pass through IETF last call and IESG review, and sometimes o= n special request. The purpose of the review is to provide assistance to the Routing ADs. For more information a= bout the Routing Directorate, please see=C2=A0 http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir .

Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF comment= s that you receive, and strive to resolve them through discussion or by upd= ating the draft.


Document: draft-ietf-idr-bgp-ls-node-admin-tag-extension-01
Reviewer: Les Ginsberg
Review Date: June 27, 2017
Intended Status: Standards

Summary:=C2=A0 The document is of modest scope - covering definition of BGP= -LS
codepoints for a relatively new IGP attribute (Node Admin Tags).
While I found nothing which I would consider a major issue, there are a num= ber
of places where the text lacks clarity. I think addressing these areas woul= d
greatly improve the quality of the draft.


Major Issues: None

Minor Issues:

Section 1 Introduction

The acronym LSDB is not defined.

Figure 1

I have a personal dislike for duplicating text/pictures from another
spec when that spec could simply be referenced. There are only two
possible outcomes:

1)The duplicated text is redundant (best case)
2)The text differs somewhat from the original leading to possible
unintentional misinterpretations.

Suit yourself on this comment - but I would prefer the duplication be omitt= ed.

Section 2 First paragraph

You refer to "sub-TLV" but that reference is unclear and ambiguou= s.
IS-IS uses a sub-TLV of Router Capability to advertise tags, but OSPF
uses a TLV of Router Info LSA.
What seems most relevant here is that you are defining a new Attribute
TLV for Node NLRI.

Section 3 Second paragraph

I do not know what the paragraph is trying to say, nor do
I know what the "TBD" in columns 4 and 5 in the following Table 1= is
meant to reference. If you are simply trying to describe the source
of the info advertised by the new BGP-LS Node attribute then you should
rewrite the above paragraph and in the figure below show:

IS-IS 242/21
OSPF RI-LSA/10

Section 3.1

A description of where in the Node NLRI the area/level information can be f= ound
(from RFC 7752) would be helpful.


Section 3.1 Penultimate Paragraph

As TAGs with "global" scope will be advertised by the IGP multipl= e
times (once per area/level) I assume you are asking BGP-LS advertisements to reduce these multiple occurrences to a single occurrence? More
explicit language on that point would be helpful.

Section 3.1 Last paragraph

I recognize this statement regarding policy being used to filter what is advertised is consistent with RFC 7752. But it would also be good to includ= e
a statement like:

"Definition of such a policy is outside the scope of this document.&qu= ot;

Nits: Please see attached diff file with some editorial corrections.=

=C2=A0

=C2=A0


--001a1147f9ea0d569705543c1413-- From nobody Sat Jul 15 06:10:13 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5A9B12EC36; Sat, 15 Jul 2017 06:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_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=juniper.net 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 GuFMtgtXETtO; Sat, 15 Jul 2017 06:10:10 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0128.outbound.protection.outlook.com [104.47.42.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B713126D73; Sat, 15 Jul 2017 06:10:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=DbuRa83SgrfzuM2GxfN7FazXV39xFnk6OLy7xmAVBbo=; b=Im83hauXdWUCvrYY4NRkJiulWkFhJJpxrRMX2dUh6IZswglaUWWK610F6tE0434g4dg6Ybrhlm9u1iC9ii+1vz1U2U2H7Ent6ZSMuiJG3mbiM7rOGbqkOVkded6bGiOxuMMPzUX2QRBev9WF5bfqvcqQW78WCixSbqnPcyp7ziI= Authentication-Results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; Received: from [172.29.66.35] (193.110.55.12) by SN2PR05MB2509.namprd05.prod.outlook.com (10.166.213.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Sat, 15 Jul 2017 13:10:00 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: <999f002984de432bb168f60309d66b63@XCH-ALN-008.cisco.com> Date: Sat, 15 Jul 2017 16:09:53 +0300 Cc: Stefano Previdi , Susan Hares , idr wg , Jeff Tantsura , "draft-ietf-idr-te-pm-bgp@ietf.org" , "draft-ietf-idr-bgp-ls-segment-routing-ext@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <999f002984de432bb168f60309d66b63@XCH-ALN-008.cisco.com> To: "Ketan Talaulikar (ketant)" X-Mailer: Apple Mail (2.3124) X-Originating-IP: [193.110.55.12] X-ClientProxiedBy: BN6PR20CA0071.namprd20.prod.outlook.com (10.171.181.161) To SN2PR05MB2509.namprd05.prod.outlook.com (10.166.213.18) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 4fdb1d28-4f31-457c-8d0b-08d4cb82ce2f X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(48565401081)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:SN2PR05MB2509; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 3:kpMwjASc9VUci4rVi4VmGgszN3hOJG5k95/kZuTXy8mA44O4jr16ipWAUCTKCJh368A/soHeFd0N0dgkR/YEVKZuKSww6nobhsgaQ0uf+55gWzUZduhAZzWyVvnfPG0HlXuHv2OYDLQRpqMbYhYMWZnD52yhXBMc+u1MrCQDyStgDNGvLbAMxfwTX+izfjrD6cAlYBxazMDcevl5sNjHTRnilaZoJg1bdU6VxNmnH3gZmBAIymIC13wl+RovwLrYA2frT+juR6oq21jeoDiwwXmA9tDa6/RLB+xwouIohWSxednSsConFhFYMvRbsFfdt6ziRoG2LI2AaYI1t6u1wYwmTWhd7MIJ4IgXnDTze4t6Db3AZF8deX7Ttu3ij5w79+b1JyW9RlH+UKYU6Eo5/9NLTo1zZ4k+QkXXXJf/PtihU9OBKhBQjb7YJ8EyeUwS0/JNmTW9zhJkCZgEcAt+ThPrBCrOzMWBpQahqMO53WJ5QQ+Igbp+iqI/r2icUZTFja0TT0V2FxIKXhR8K/4i46qB8ethHfiLm/q86Qzb+FtFXQlEhx/GOkmr4+EbxtjwL3SLyvxjafPaW6hni4NzQsYLCn96/M29ljHdSQMvVaPLX+PVzILmQz7lLT5kZBU0CVkW8cWo8qmZIqZ+WPI0/pC5T9L1MKhXA/qjEPTW+VEskTb4WggdWr1RfDB1YPIb4EbOcGRnBzF+VwVWPuIBwUKEvRLJgvrj/zoRcIEyY9d9u6bFPjNWmYm6iC/nzqUvk3zoLLlaj8z2xW9RMUzOUg== X-MS-TrafficTypeDiagnostic: SN2PR05MB2509: X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 25:XT7R9vhNnB/Q/q9uuLwQcW/WEZy3wEk5FYFhWaENgqGJ0IejIz752RasSLeWvlCK2JIc+ts10bMzi9wkBcSzFh2EYbp/GBBEma1lK+jgK4sdB17VSsoDEr73dsDsZInemVWm/LArl6CbZeX3ly37uVOhtGl0QJmdlhVKgofb42eDNWFIAfQ6CIlsbiA+nEYG1oWwtlIlabUhXMNORg7qymMKmzWWEWSn4aieTqEWoWgcfG3JVnVBl8EkJ1A1mmj9XxqxEomlRwzS6oodzk2zI+Elu1Vgol7nYz9hPA5RC3olypv/YRJKUE1wiPjZcrUysxgtg60fmHpcVOq5X7GjYUrRjw+CFnKcKeGwz7x9eTXConUeLxjlrToED9Fw5XZY9jv/YP34B1Y39IYe7H9YHfohAg9czz0znSVpsynwL3M1NXP8TTm4c7zN9T3Q8NqNXMX39P1swcH8QESZnhiJeK3B3XGiMvg1fmNAyP7oBYeshxB7yehJYh/D9nmDYOR5fIb7LM5w1L6r80UekovQdtHgTGpNY1/JqBnAB6B9Q0XzjWq3g8yZcf5DKzOgLS+o0v6jqlcAl7SBKJV3bgs0GxAeAhnLOcwl7pzsRlOmkvduftx44JMA8gisq0Fy3YUgXqlMKlei0YahfezF5gtWH3nnYQGxDP7bnQkkJjm+dpPFIheGY7hDFPPhMUfkhZ1mb9NdyK/1n8NMeFYwjKDCxmQiRtM3mIRO2r42d2fJxuY2ztin52+fypmWSvZ1Ly85KcqEYPa7JJW633nvcyPMzrtIUMfeRvj76tNfWCRWEbDWl9RjIZuJb24lK2lhJU+2+GqZAtrDJg8Giw+H9Q2OC0Ep67IXSdw/O8wGBKqVWGTYNGPM3s2NFf0zyzGJ2K0SD+ZeGNW5QNsPbtFOkgp1eomkA5PnPCcssqWBPK6Pr2E= X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 31:0ZW1dFFYrRA555vYndLjpE/hCBS8N8NWsZTCDX8alwGFSz1/dLGPt2wIQLKxvvJaYKvKTsQIjSjFqWTNbZA3cMEEFI4JNxtzjm7Q+OMPLMWKorUr1aenspyyDnJDRCTfr2naws2nHu4ifeNQ67SSrJD0jhiRBtnffhvANyvw18cBRSmKu9t4uxJktY/esF1UgnqoUdpX0PCvCWM0FBpcjOuLS/wIBt08QQgxtDHgDrP5na1IBjKzlQhbp9e5A9nMbqqveQS4ucDeXbc5b8/HGgIyyRgYERb24Oxxnw05D+OWHtq4sllDQNehI7X/Jv4PEOm4sv+VR4RL7qi29etswdRwIqevzBC35stYlMDyH62EglUruw8YiPhhE1/f9ZaIMj5++HIiRKw9rSH+6wxXUP7z8Um97DNhYwX3UT8pRiTCBL1mSp1p//Dfg/H/fOMXWoBZ6593LcyulJPryILeIvArgT6GX37QOpauNEqP4SULYRq7Imv7JuUvvgFyDwCqA+gCLHiwj30bErLR5ReiB1WTaxst8+2RsPcTN/2xq9WrDEhrYRbi+nlPRWViZRnVCO18/IAdchJbNuUKSlxgVI06cXM3HiGZ1ZVFFFHG5FabMXi3Dp7OaPUvsoEylbTDIfQbSKyulX+Gg2cPWxtB9gKiFE/zN23SxieFkOa78O82C3mFs9vwHDtedj+P/XZDcio9NHmujq8e/hCKM0aBhA== X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 20:rdMyOOWRzN3prJ3ipbNQ+o9wa8+4Cfjw3dYnikM4wBG/+xQBmqgEnx0xo5H7C21rxy4iUeB9hbBOXJJCmc1su79kN8sZT/EOyPMMIXswjbYTsLr7o5YyT24sSZcYh3QjUsTDfwu2VOkQteqwMJ3Amh3q0oLybbBK+dFBxqESaKF4aXCJXHrfgCwIGn4+6PD/kTjKSbVx0y+m0j4NrtmIu3hb3gdQh6TU3qdiF0Z3beWJqVSIGb8tA7qmOzQeaDPoqqUSw1sdY/subL4mmLQglWO/bss3fzCP+kZ8aIeSAd0zzqWWrBOPi9c53uCiJjwGWMjfKn3Sl7Qq4eL52Cn2lpTrn6sR16LGwNzqsOTbfeYLz/3qcIlFIayFRwd4OZUhwElVjb1fINn3TLAegHzRTQnTKqB+DuaGA2nJkl485mh5/hhhG2OVRsqXgkNivEV5d+2LR15uRnCoAqSJX8ZNDLJHSu+5C+T7FYj0OBouK60uZetpmMlfm5p9JuM+crsp X-Exchange-Antispam-Report-Test: UriScan:(236129657087228)(95692535739014); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(2017060910075)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN2PR05MB2509; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN2PR05MB2509; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR05MB2509; 4:iNEMK9zZiO54RAy047vWujT2hZKRdS/FWqqS5TaDSp?= =?us-ascii?Q?6AHwfo21WGQh8JOtQmRxARAcNL5PiZdxs4E+7kTNw7tdjncxKtZvciWbq9df?= =?us-ascii?Q?VsrHlxqrJB1XfcOqGEpvE8ScNohUX5UHO4YL9laskrZs5VdP4KqdQc+qeZbW?= =?us-ascii?Q?BblBoj/tYaxQo9YNqC7x+6yyN1aFeeC+KluSTcUaGi4JdH6vqQSgnn87+a5G?= =?us-ascii?Q?n6/bSdeDJlioso+LWOANIaTztJqQfMfpDd3OJxbtlx3zC6+CHn0i1QgHkPWS?= =?us-ascii?Q?4xlHl9o7ah5vPht7rxOoje6eaBNPrkioKEk7EFPC/oPrRIAl9OUnyhmA43Zq?= =?us-ascii?Q?OqF+ohhM6g0bLmXj/vE8/03obu0hBZrq0bgWpZ3cA/2vOuIHdrvqo81B4Tm1?= =?us-ascii?Q?ur4l6Rdm6iDzCGLARVnW48kBcBNhZ27oI+OTIE4QupMOefCK8lvSiJBSC2kI?= =?us-ascii?Q?wkyvWTB5cjIPJw3JxP9tqv6/g2CVCyX9o5Ui6Uay2q9Vc88V4AQ5VrtRz0iF?= =?us-ascii?Q?DpP5el1BHwawo73UZLTp417g4iIajtW5GZyoHN8zxrEKjyzRSuEyfIlfPJFP?= =?us-ascii?Q?KQ4bGDsTtB41Kieyc8Ut1Wo4Ljcog3LyM8z47b9FOC0UaIgCiWTmp9wnkbtt?= =?us-ascii?Q?KQBPJib8Y/zkFSNiaRm3ob/xa4mcvl0HUtM5XiSe3kks2vq/xduG1Uul1PoI?= =?us-ascii?Q?YUhxvIFCUTz+IntnfOrxOS5gSfiiRoLeC0rxSlb0HGaYWTDsqGSeKfwLR5cU?= =?us-ascii?Q?pK4AvvMlRDI35/AlWJF4AliVfM2FQF96gEeaRpL21u38eVT3NxrtuqN6flIC?= =?us-ascii?Q?3h/pgNvoTpjtef3dQ6MMZEYYeVCDlbchwYLu6tRxfxUXMX4lNTUkk9EqfCYK?= =?us-ascii?Q?2+xg4gkt7RV4U3Br9nItbAeWePWHn/PADefYSz1oI44ty0hiqIQT5w4FWsFU?= =?us-ascii?Q?kfq91t1CBRE23u9aMG42cExdna3TGtCf0oDWG+HMisrtHWAWputqm4CGgTXV?= =?us-ascii?Q?1B74EuQj8B7WZtVfNu6GURxx0gX5Yq2TOq9DfdAcEHaIaeMcKnfpGFnyffXh?= =?us-ascii?Q?g7Nc0ClzEw8e2x9I6Yo0btu/b9uSiQj//HLMbGYV2sYPOuy1i1baKSP/oJQ7?= =?us-ascii?Q?83seiy+m7ls0dQhiShV5Nv454km4wSmycRnmcwZuU1ejag0WRSwoAwR3b5u9?= =?us-ascii?Q?Fn1SNQQXG+CyA/fIi/p4qK3vJBq9Gu9xnjI1O0RW6+srDKUFzlWZXr4InqrK?= =?us-ascii?Q?9fkjEQDMt9c4MXy5wZqmPYJxUWgYIOkRZTEp+A?= X-Forefront-PRVS: 0369E8196C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(7370300001)(6049001)(6009001)(39400400002)(39410400002)(39850400002)(39450400003)(39860400002)(24454002)(377454003)(53546010)(6916009)(6246003)(50986999)(76176999)(25786009)(38730400002)(33656002)(6486002)(6666003)(2950100002)(229853002)(2906002)(77096006)(53936002)(189998001)(478600001)(23726003)(110136004)(7350300001)(54906002)(57306001)(36756003)(305945005)(82746002)(50466002)(5660300001)(47776003)(66066001)(86362001)(4326008)(7736002)(8746002)(81166006)(8676002)(50226002)(3846002)(83716003)(6116002)(42186005)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR05MB2509; H:[172.29.66.35]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR05MB2509; 23:NvDnULtFipRAObKzA0qKRjr2fB60XeWKK+2UicrNs?= =?us-ascii?Q?Z1exA7i8Qr23rIHVOm4SF1aXQDfeBfijsenDJzx1GxE8oIUN9WQdWu2lwjGB?= =?us-ascii?Q?OvEjAMVnGj0LvPtOgRm38SaVMzo8BcVWBSkIdRBrFzf4RlVXZlr9yJcsoh6g?= =?us-ascii?Q?1I5Hs2WOGlA8hHi3jx2/IwABOGL+MnBI/u+aeY2EEoRSKkQoQtnvxzyuD9i2?= =?us-ascii?Q?tzAY7J8lQn+nqrVZ3UhdM6kZsL9D1Lb3x/Ve4duNFh6tL2X0A0sj9OesOzTr?= =?us-ascii?Q?RJ4WgfmwB+ZUHJZlFq9Oqw45mKm0lHFnXSoi6dMLRXhwjPf/c4SRZs57JQD8?= =?us-ascii?Q?tBu8q6hnoRaJ9K8f8SXvCh6TKeineTrgxc1F2I7qHa13Aq9BH5zzM+Xw9Lhz?= =?us-ascii?Q?+fIZQT0c/b2VfiYyKU5WMc2h7gpR5fuax8e++9N5wm5JYVXDynzB5KTdHgyN?= =?us-ascii?Q?+MCEayn5SzROydsZPSU8nT85gbltPY3GJN+xyafH+5IjoBk5XyDU3fLyTegr?= =?us-ascii?Q?c086+s4qfcphNb3CDvteN3U9/hXkfb+Zy+7KRUvcfbLnnqRRqb8gaa0emmgd?= =?us-ascii?Q?KpX4lVxW3hWkkSeYFEEtFKBt00rAQ6ZnMQkng29OFTweFGy6+xnZ/Pmw7AQ1?= =?us-ascii?Q?hEo7+TRgAGSf1aaETeIlx8/g/1OM7qkGgOHRUdwTCSY6HEeTDie6DzdRgAv5?= =?us-ascii?Q?T4KpXVo3LJY0fUpg8/RhO7Gr2T0eb2pxuiSGgDqk/8JH8z2xj5/uakLnm99H?= =?us-ascii?Q?aaGEu90uvsaj8gmLTw8kvHSDpGp+63dKSjIBfsFkWx1PoYauYaskc9xlhHy1?= =?us-ascii?Q?j5maz6Gpl8DtPzqvsrbOD9Ado7Q9yDn7oB4i2JENnbnMDxhmVNV3wPFXnVPb?= =?us-ascii?Q?opjWhy+ALbwXAdJoYFhhbKb1KjA194Q7oQAZBJCuXYoYePjdQffbdGH9+eXX?= =?us-ascii?Q?MTkW7pdI3gbL+Vg2JFEPDJ6/MtkGcaH4UTmVZOuteX/r+4tLm6Ond41VsOyx?= =?us-ascii?Q?wFGM0VwNZF3udcr2b+FoQYqqCxiGo780IziiqN69yKDyMFIpmLlB/hmtH9rw?= =?us-ascii?Q?z9rsOSl5TNRFfYg/cQ/Zl36MOQsWCf7jUsVPJGmHI9v/bVKr9paSfMPfNqa1?= =?us-ascii?Q?x4IHEg+5dze53eYfTsPqcwNeePvaxWYZH/B2QUE/p8Wke1ZrVXG8EDPjBZOu?= =?us-ascii?Q?FIvTCxG6uOnk7FOTb1IhiK7B+hZxozqdOhXLAqLVfHTFWbNeaUCAS9duTOWH?= =?us-ascii?Q?gGiGYIDOZvBtGlPZo6mqje/pU9D+JKeK2uujFFvEWNBmjyhMUpx2DuJvM8O8?= =?us-ascii?B?Zz09?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR05MB2509; 6:PVavDHJYZIV905yDcQsf9dNe9japbitU8Fg2Z/F27n?= =?us-ascii?Q?zu9g+H4dsidgOX3yyA+IezDCmD7ama7twr6er4Y9Q46SK7NatBAgwkMNQBpH?= =?us-ascii?Q?J52pntP9Zz2+2HcDxPHs4HxkRQMzocWUe9xeE7gek/EERE/uiKEke96lO8r9?= =?us-ascii?Q?vlYoI3WJtA6ppwfvyIf/7pxunPTkg6iPjgDaBG/TfoDb8aeUN6IwzeetQPZy?= =?us-ascii?Q?cyhAC3CW7ddNep2iEmR+54S9Ycc/8twrmWy9SjelH11Crzvk450Hx0m7Sbb5?= =?us-ascii?Q?ABWpjTKDMpFciyT/TDKIvYVUlSuacubwChLxCm9b6WEkyByG3z99eNVDlQpo?= =?us-ascii?Q?1Rcb5PAPei1v7C0HLGA8sFx0xnGQmsfojVS9STLGLVb1O9PdT9BMlVZYIM4Q?= =?us-ascii?Q?yNiObGOVtATJ+HrUWYR9IV1nsFOp/G4trXfQvxZ0KdxreoJKYsAHb2lNVXQA?= =?us-ascii?Q?osVq13w4pMC2HMaC4pxnGR9WeIpqEGCbCKfL9jWp73hW4OpI69U2wNqTxuu9?= =?us-ascii?Q?NVAtXM9SsahdMUyc5s4BmeM31PhzI1B/NfT9/x0r+qspTBQLUuE4z+tkMl6/?= =?us-ascii?Q?tIgH8vlnWPefjA2Squ33O35MbtMVZMLjxt10jPvp7/QHLcqnrKMySsKfR7mK?= =?us-ascii?Q?dmEeRHidjgDfhGgf6orqrbv70opY7gfDz4/a4NjxqZ80qhvFOIh3zSWjoIoI?= =?us-ascii?Q?TAx34XLX4J/DOZP7Jnwuoyac5Yrdmv88JBpB9FZcPJVscmjRIaj/LEUdc9uV?= =?us-ascii?Q?c8yXt/QYC4utAJRBljeb3CwK+4O800gD74pLdlBlTe3XP+77mPoufUjjWvg9?= =?us-ascii?Q?+arQzvlGKNqEL+OrqCPXaN3xnwR7oAkAnFU/iN9bTP9djdLD3UIVTeYFIvSi?= =?us-ascii?Q?xLJ2tTjKGoUcrnj1EJLnNZoLlUUkakgHJYqfGPV35oZ/y3GUFi2dsLivj1C7?= =?us-ascii?Q?DdZjQtQ3Xxv87oWOFNLVJqjR4bRf5NMkQtU3Oq0LkwTh01ZHw3R/WmY6NjTy?= =?us-ascii?Q?8w1cq0i1hUJz5f/3W9393n?= X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 5:TPvnyK08UlJOfhgRCw07PFMz31S39P4MZSuYWlqPzAXObuMoWY3ftH6DW1KDP08Ziz/Yde2nwXyJLnMMv43fLDzUOeJrQib2i9/SxroD4yD28A2Q88nJTViRu6OugFBZvvJkNhrZvlQs6FVdVZDZdgctdVPhzTnCkFY6mMjFFte1NQQ7pv0EoKKkvCaMIYo8uMxojYxfds0wai/We/NnhLUkI3i4EIJO7zZYRVmBOPiCuu1Iw3oR/FySpsyPTk8mKLuv7kH7IwnpbE/dHbXNdcu+FtmUEO+iQhj1i1x5+Qe+vsS9DerXjJle3xAasLYdBroQdcSJvjRINlFBhgi30pk5HIMxWYEAgWmcMHkw0x6lB321Xjvn/x94B7hokryU0CuwW0ETqtI4UXfP6ZXHmHOL/GQ58Nhj1OwgXt8K4LUYQNyW1hLzCsSbEhEMrst4A0JlBa0eBYi6k9Wh7ESqFC09KJixm7FfGcyaQqp9rjASrqk0B72xypzZb2U9aKaQ; 24:dUJ/Qjhq1eJ6UU9WveDoD7iiCv4mr3PxL1kXnANyykspgZkWEPPupQ1yYuNlznIYzMpid6fzVqRpEQVoNm8aO9JzKQbt7N/L1q9gwwSKax8= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 7:/1ius7NzCDIg/TV7GYARxXRf74KdeE4esfq5EI5Apaji381Vomj4M4IomLaZpCIGrd4/Xj/7ttXu1VCYTeLWaaAMYve1dSoT+Dov3YIaHzbcR5JkNtICtJhoXs7d0ZPydhIV4sx0pFQAFQ7ekfQC5d+B7W7FRdw9Xsw38ngvLJ96W0pKFVqDSgQMAosUIuJ3FCNHnCsoUW8RztkOUr8jmRrEE2V5TWZSmlvOVOgAkhN3mmYvzNURZihJx8GGBR4Mhyt+QJmohdf2hDwcwJGmfWdjEMPiaXLIBJdsN4UQDP2z93GAAc6kYVVwRWuuxw5eNQtWsn/e0Sm+JgXRCw4F1D+L187vS7MqogzR9NBd4HqN1JZOUP5ehlkvDMdI+bNXhtrrzvYJri92jFfXB7/bUaTGjIBXfgxmz0Vfax+xyzc3oKnHSAp79QjIIgEIpxSMWUnQPCb1LnI07PmUj9N0LpoltKgrMXqJK3mACUM6XeGRoGQJCstCpZv3uBprmIufR/00OPHcJfZ67Jnvuy6/cFnqg8HgOMkiGAOGgP25sQfQNJUXKCT4K1RLIfdB92vv0Og2fdh/f2c6DZdySLcdN+kBx+pBoWfGOEfjpYI7m2rydXPmWyU7YhLR5k5dWtPuwPUtvvLryblOqp91R+Mu+NAE8YHEtkXRt5ID/bJGz9qaVypOLx9ZlA9jsu8iKR6LFwcQ2KucrhF9xxUmZKSDrKvW2TMjhyKlmtEb998K7kmmR69Ann7bG9cUD8+Xm2MawIhHVe6IGWg37r5aUyn5jHOU7e0wFCe2QA6IU7SLnrQ= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jul 2017 13:10:00.4773 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR05MB2509 Archived-At: Subject: Re: [Idr] Regd BGP-LS code points early allocation for WG adopted drafts X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 13:10:12 -0000 On Jul 13, 2017, at 9:01 AM, Ketan Talaulikar (ketant) = wrote: >=20 > May I request the authors of the = draft-ietf-idr-bgp-ls-segment-routing-ext and draft-ietf-idr-te-pm-bgp = and WG chairs to please request for early allocation of their IANA code = points? Thanks. Will start a discussion on this shortly. =20 > Also, the link MSD codepoint in = draft-tantsura-idr-bgp-ls-segment-routing-msd collides with the = suggested codepoints in draft-ietf-idr-te-pm-bgp. Early allocations for = WG adopted drafts would help avoid collisions. Thanks for pointing this out (and also to Jie who pointed out similar.) = This is also why IDR WG guidelines are to NOT put any "suggested" code = points in WG drafts or drafts targeted to become WG drafts. :-( =20 > Jeff, may I suggest to request the code point 1111 for the Link MSD = since the TE PM draft is already a WG item and there may be = implementations out there already? Better still, please refrain from putting "suggested" code points in = drafts at all, and let IANA do their work. As you say, early allocation = is the right way to handle this. --John From nobody Sat Jul 15 06:35:52 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2976131B68; Sat, 15 Jul 2017 06:35:51 -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, 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 l1bBozfJ3TGf; Sat, 15 Jul 2017 06:35:50 -0700 (PDT) Received: from mail-wr0-x244.google.com (mail-wr0-x244.google.com [IPv6:2a00:1450:400c:c0c::244]) (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 E64C8131B5B; Sat, 15 Jul 2017 06:35:49 -0700 (PDT) Received: by mail-wr0-x244.google.com with SMTP id z81so95867wrc.0; Sat, 15 Jul 2017 06:35: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 :references:in-reply-to:mime-version:content-transfer-encoding; bh=bcADbcygGC8og/+SHuUvIurNV8JhKdDj42rfwXarLtE=; b=szTVTvQMzmgTJIxiqoSAMzez4D0gLOv4MyiOixn3zAQyrPg+z5JO6HsMUkfNXM8koF m2J7crUGISjHw3shfhXz0ff3NobvV3hnB8WSqwgzfiHAZiGzWdDcOToh5Fqbxh5Y6kfD S5FcBlvkR6+jWg6sNjfNEcTcM17eixny5VYT46uaHl1CpjXp5yamwPsaqFi6OwfnbyyI 7Wu1D2/C31vKbIRRd7u+asafyOHVtdp5xbIlNbp59DPkq4ZIa4MNO1t56c/+RB8qLbaw 1AjbfcA1XqbH8rMrCM5139vEvDYE85W6JW3qKtx69YcLih9ErcaJx+hmEFu/iL5ZUxPM jWzQ== 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=bcADbcygGC8og/+SHuUvIurNV8JhKdDj42rfwXarLtE=; b=CgY/8dwPr6QHcWQPCRaBbHIBXB5ThDPe77bv2VZYbvGttkbAV3P1Q0ONmdExet/n5P o1OKPGDLADTfA3Vqb6Zw/ejTMYm+vMYw1x6te1AJQvJRzRQJWO6Haukf93yw+OJ1YYVC KW1xuNBzoiQCf8i4S/7psJBtXZnYpBjhjJcftOSa26tGjTiPiWoma9PnHWKLtvTMXfn7 djAPLEZWtN8cHrkvM/R18VDOZWhOuG8/G8dFFEq6vjsFUYH0ywraCQOGyvMOHlAT4QQh XaZLHiUaFrJaJk2wVx2vcbLhwIvYPOeA0C0cG6JD2lpvwT0EbSzs/MfnF6E87UINW3QV zc0Q== X-Gm-Message-State: AIVw110NcGFJdCLWkfqOqMWjzTSssTP9pKB5YDtRDlxYKzXTlLtn/9hM i7EdSaFpSOfjpekc4Ec= X-Received: by 10.223.160.174 with SMTP id m43mr6724660wrm.194.1500125748436; Sat, 15 Jul 2017 06:35:48 -0700 (PDT) Received: from [31.133.150.241] ([2001:67c:1232:144:61e1:5115:fb36:80a]) by smtp.gmail.com with ESMTPSA id 32sm13720721wry.31.2017.07.15.06.35.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 15 Jul 2017 06:35:47 -0700 (PDT) User-Agent: Microsoft-MacOutlook/f.24.0.170702 Date: Sat, 15 Jul 2017 15:35:45 +0200 From: Jeff Tantsura To: "John G. Scudder" , "Ketan Talaulikar (ketant)" CC: Stefano Previdi , Susan Hares , idr wg , "draft-ietf-idr-te-pm-bgp@ietf.org" , "draft-ietf-idr-bgp-ls-segment-routing-ext@ietf.org" Message-ID: <7DCAAFA1-1E14-4374-834B-4E6FB174ACFE@gmail.com> Thread-Topic: [Idr] Regd BGP-LS code points early allocation for WG adopted drafts References: <999f002984de432bb168f60309d66b63@XCH-ALN-008.cisco.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: Re: [Idr] Regd BGP-LS code points early allocation for WG adopted drafts X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 13:35:51 -0000 John, Would you want the authors of draft-tantsura-idr-bgp-ls-segment-routing-msd to remove suggested values or wait for early allocation and replace? Thanks! Cheers, Jeff On 7/15/17, 15:10, "John G. Scudder" wrote: On Jul 13, 2017, at 9:01 AM, Ketan Talaulikar (ketant) wrote: > > May I request the authors of the draft-ietf-idr-bgp-ls-segment-routing-ext and draft-ietf-idr-te-pm-bgp and WG chairs to please request for early allocation of their IANA code points? Thanks. Will start a discussion on this shortly. > Also, the link MSD codepoint in draft-tantsura-idr-bgp-ls-segment-routing-msd collides with the suggested codepoints in draft-ietf-idr-te-pm-bgp. Early allocations for WG adopted drafts would help avoid collisions. Thanks for pointing this out (and also to Jie who pointed out similar.) This is also why IDR WG guidelines are to NOT put any "suggested" code points in WG drafts or drafts targeted to become WG drafts. :-( > Jeff, may I suggest to request the code point 1111 for the Link MSD since the TE PM draft is already a WG item and there may be implementations out there already? Better still, please refrain from putting "suggested" code points in drafts at all, and let IANA do their work. As you say, early allocation is the right way to handle this. --John From nobody Sat Jul 15 07:15:51 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 808B9129B26 for ; Sat, 15 Jul 2017 07:15: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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.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 kEBp-axhAkwe for ; Sat, 15 Jul 2017 07:15:49 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3A9C131B7E for ; Sat, 15 Jul 2017 07:15:48 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id f67so46119490wmh.1 for ; Sat, 15 Jul 2017 07:15:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eLEG7hO5jdxLUdaQPnokLlFz1zEG+2uGgxShDet8kCQ=; b=lb+gYofem55/9dPZM2tJI0/nE3YB+sSX6xNrF2uEaRWqixxR5ql0iQkCJuE9U/e4z8 A2PEhJpyfxp0Epeh3LcPYGDO32aK0x/s5vwzYrcx62WCDIT7/8dv8w6hkohcXlY/VZxd DQKrtk6xw5QDVC5pBxpwwZ2qljoUev8DlmUi77Q769nXq+a3I8pVS51dCuQsbYJ5uRWe f5kPlHcHiXmzSi6omYYNmLEHmO0Pq9WcHYmZBRrzzh/bmnjcZxqqzst+oFHnQtyEbn69 O4EavsZl5KKHQSUJT2LFY1H7mOZbXU0ohXM00iSuAxrmNlkem0SuU+bZHaCmtpfb8iiu Gerg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eLEG7hO5jdxLUdaQPnokLlFz1zEG+2uGgxShDet8kCQ=; b=lGnonWFX3CPWZvGYyEVCckr4QYXmJ99GEk1jsEGSsp3B1DVqkw4fBsNfkpwy2nrcUL 9L5jTGM/pcwr2z5BL82vylh1ouExav1JVuIHaWO15L4ffjUHdmmfY874DvCJ6BKbBAya fi426+hrPmCe20E2RkTGEEG++y1elOIs/A5WXI3SDNij+N8KLWw9JP3q9GBM8M2iK0/6 9jwLzTz199RdpL/wffvB6eoZWbb7lvfgcUAHpb6rT3lz7UYYmsUwff5aL9RPcEdPpNrm nJms34aZkJ+n0K37oKPGXmNEO3Eb09yI1t3OSDHvTQL0JfIwjDzOjbpx/XKfJt/hgPw1 F5/Q== X-Gm-Message-State: AIVw111iqAmzQXx3bxp+GI1eik5OmrkNIwwovyE7gAjPDykCn5NFuaVA onqVetRQR4l4QdVuevedXgje+EVhd7JO X-Received: by 10.28.29.21 with SMTP id d21mr1105732wmd.37.1500128147101; Sat, 15 Jul 2017 07:15:47 -0700 (PDT) MIME-Version: 1.0 References: <999f002984de432bb168f60309d66b63@XCH-ALN-008.cisco.com> <7DCAAFA1-1E14-4374-834B-4E6FB174ACFE@gmail.com> In-Reply-To: <7DCAAFA1-1E14-4374-834B-4E6FB174ACFE@gmail.com> From: Job Snijders Date: Sat, 15 Jul 2017 14:15:35 +0000 Message-ID: To: Jeff Tantsura , "John G. Scudder" , "Ketan Talaulikar (ketant)" Cc: Stefano Previdi , Susan Hares , "draft-ietf-idr-bgp-ls-segment-routing-ext@ietf.org" , "draft-ietf-idr-te-pm-bgp@ietf.org" , idr wg Content-Type: multipart/alternative; boundary="001a114b25da537a0f05545bcd78" Archived-At: Subject: Re: [Idr] Regd BGP-LS code points early allocation for WG adopted drafts X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 14:15:50 -0000 --001a114b25da537a0f05545bcd78 Content-Type: text/plain; charset="UTF-8" On Sat, 15 Jul 2017 at 15:35, Jeff Tantsura wrote: > Would you want the authors of > draft-tantsura-idr-bgp-ls-segment-routing-msd to remove suggested values > or wait for early allocation and replace? The outcome of the IANA Early Allocation process is not directly connected to self-assigning (squatting) in the current document. I would suggest the squatted codepoint should be removed at the earliest opportunity (Monday morning). Uploading new drafts is cheap and easy after all. Kind regards, Job > --001a114b25da537a0f05545bcd78 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, 15 Ju= l 2017 at 15:35, Jeff Tantsura <jefftant.ietf@gmail.com> wrote:
Would =C2=A0you want the authors of draft-tantsura-idr-bgp-ls-segmen= t-routing-msd=C2=A0 to remove suggested values or wait for early allocation= and replace?

The outcome of the IANA Early Allocation process i= s not directly connected to self-assigning (squatting) in the current docum= ent. I would suggest the squatted codepoint should be removed at the earlie= st opportunity (Monday morning). Uploading new drafts is cheap and easy aft= er all.=C2=A0

Kind regar= ds,

Job
--001a114b25da537a0f05545bcd78-- From nobody Sat Jul 15 07:17:42 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA286129B26; Sat, 15 Jul 2017 07:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, 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 BKzubXyl7ZkN; Sat, 15 Jul 2017 07:17:39 -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 243A61276AF; Sat, 15 Jul 2017 07:17:39 -0700 (PDT) Received: by mail-wm0-x241.google.com with SMTP id j85so15434851wmj.0; Sat, 15 Jul 2017 07:17:39 -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; bh=dD42KFZ2INoQC/xn+5KD7NEkwC/nBdMIeaD8WKEir+w=; b=n9zwHIQIMOzm23byXgj3fo/z7AKMw/DNMIQMZaVg50MoH55G6ATB02jMmSgKT/gN9a rg034cy5iVUc8MHvFtrdUQAA1omhzR4u3wc7Pze2LpGXpjzapW2fB46dyvDavmIhZqLN ppGWOTZtCq+NlTkxwkADU/LlpR2sEnRbqNHwRbPJvQ6nLys74ZM5F7lw4St6yjvDioA/ bT+TYt997YxnhcUR3LI0GhfpZRrRaBOfdft16e4MEbPHT/7cuErFTSyBHjC8FNODs9Oq AaOht/3zxy4CoJnDzaNWEMwC5vCUZsEr+N49nZWv4V+QEELoaNav5/fSz9Dq8lsifHs2 5tkQ== 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=dD42KFZ2INoQC/xn+5KD7NEkwC/nBdMIeaD8WKEir+w=; b=qAV+ydNs/YMe/5bMLbfy10sZ9FNNF0kCCC/92CNK6SHeNHy1Cv/NUnN5L2vZAPZ549 8gks6sVaQtez3A+CTjTQ+XL/eb5R7FwdeoBc6vAw30VrHmiYPpwEj3Hfd6GB+4PLHX0O pGd1RMfEmHWhCyWx7Q+fFQJoHY6j0D83KjSIUpaLmo3LLGU0QFQoNKknm0s6j2l8zcRQ SzEG4w0KDog7bSCSXYEAB8sLjqRKn0jbAWil+PGuYGsz6V+Xi0A9930/r7Hq+W6usuXU whz7NbPp9XgB2DVu58i33PhbV/uqruUXixsIundFLGZ59WZxCjSkWUszUxXJ0IAI4qeG 6tVw== X-Gm-Message-State: AIVw1109/bWqMitLFLalT7aB3pyoa+ACXekqOFL9rIoiPuYqXEXMKJxk aqkIOBXWh01Kng== X-Received: by 10.28.11.134 with SMTP id 128mr1314577wml.79.1500128257713; Sat, 15 Jul 2017 07:17:37 -0700 (PDT) Received: from [31.133.150.241] (dhcp-96f1.meeting.ietf.org. [31.133.150.241]) by smtp.gmail.com with ESMTPSA id b195sm11741813wmf.0.2017.07.15.07.17.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 15 Jul 2017 07:17:36 -0700 (PDT) User-Agent: Microsoft-MacOutlook/f.24.0.170702 Date: Sat, 15 Jul 2017 16:17:36 +0200 From: Jeff Tantsura To: Job Snijders , "John G. Scudder" , "Ketan Talaulikar (ketant)" CC: Stefano Previdi , Susan Hares , "draft-ietf-idr-bgp-ls-segment-routing-ext@ietf.org" , "draft-ietf-idr-te-pm-bgp@ietf.org" , idr wg Message-ID: <37805F15-E265-4C37-B491-2BCBABD29D2D@gmail.com> Thread-Topic: [Idr] Regd BGP-LS code points early allocation for WG adopted drafts References: <999f002984de432bb168f60309d66b63@XCH-ALN-008.cisco.com> <7DCAAFA1-1E14-4374-834B-4E6FB174ACFE@gmail.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3582980256_1421760731" Archived-At: Subject: Re: [Idr] Regd BGP-LS code points early allocation for WG adopted drafts X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 14:17:41 -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_3582980256_1421760731 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable That=E2=80=99s the plan! =20 Cheers, Jeff =20 =20 From: Job Snijders Date: Saturday, July 15, 2017 at 16:15 To: Jeff Tantsura , "John G. Scudder" , "Ketan Talaulikar (ketant)" Cc: Stefano Previdi , Susan Hares , "= draft-ietf-idr-bgp-ls-segment-routing-ext@ietf.org" , "draft-ietf-idr-te-pm-bgp@ietf.org" , idr wg Subject: Re: [Idr] Regd BGP-LS code points early allocation for WG adopted = drafts =20 =20 On Sat, 15 Jul 2017 at 15:35, Jeff Tantsura wrote= : Would you want the authors of draft-tantsura-idr-bgp-ls-segment-routing-ms= d to remove suggested values or wait for early allocation and replace? =20 =20 The outcome of the IANA Early Allocation process is not directly connected = to self-assigning (squatting) in the current document. I would suggest the s= quatted codepoint should be removed at the earliest opportunity (Monday morn= ing). Uploading new drafts is cheap and easy after all.=20 =20 Kind regards, =20 Job --B_3582980256_1421760731 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

That=E2=80=99s the plan!

 <= /o:p>

Cheers,

Jeff

&nb= sp;

 

Fro= m: Job Snijders <jo= b@instituut.net>
Date: Saturday, July 15, 2017 at 16:15
T= o: Jeff Tantsura <jefftant.ietf@gmail.com>, "John G. Scudder&= quot; <jgs@juniper.net>, "Ketan Talaulikar (ketant)" <ket= ant@cisco.com>
Cc: Stefano Previdi <stefano@previdi.net>,= Susan Hares <shares@ndzh.com>, "draft-ietf-idr-bgp-ls-segment-ro= uting-ext@ietf.org" <draft-ietf-idr-bgp-ls-segment-routing-ext@ietf.= org>, "draft-ietf-idr-te-pm-bgp@ietf.org" <draft-ietf-idr-te= -pm-bgp@ietf.org>, idr wg <idr@ietf.org>
Subject: Re: [Id= r] Regd BGP-LS code points early allocation for WG adopted drafts=

 = ;

 

On Sat, 15 Jul 2= 017 at 15:35, Jeff Tantsura <jef= ftant.ietf@gmail.com> wrote:

Wou= ld  you want the authors of draft-tantsura-idr-bgp-ls-segment-routing-m= sd  to remove suggested values or wait for early allocation and replace= ?

 

 

The outcome of the IANA Early Allocation process is not directly connected= to self-assigning (squatting) in the current document. I would suggest the = squatted codepoint should be removed at the earliest opportunity (Monday mor= ning). Uploading new drafts is cheap and easy after all. 

 

Kind regards,

 

Job

--B_3582980256_1421760731-- From nobody Sat Jul 15 08:19:39 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB93112FEEB; Sat, 15 Jul 2017 08:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_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=juniper.net 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 UfbtwM9XitoB; Sat, 15 Jul 2017 08:19:36 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0120.outbound.protection.outlook.com [104.47.38.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D12C124E15; Sat, 15 Jul 2017 08:19:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qV/3lJF2UPzV3alEwEjGzhlKbTch7Wc+PvWqynr8HYc=; b=KvcfllxIKH9hjHZqiyZBha457zwkCvqaVgSmyzANFGOlgxkkJ+Qfc2r793OfZmoQlvA3TY4Cm36yoha8e4i7ZJImhjNZztHpd5q8jNB/Go97LIyfbwU3vDMuiU/YEyvPx/DoB+V6uMCFDGsnIeZ71MndZTTBwu3/Q3cAgt7la9Q= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; Received: from [172.29.66.35] (193.110.55.12) by BN3PR05MB2498.namprd05.prod.outlook.com (10.167.3.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Sat, 15 Jul 2017 15:19:32 +0000 From: "John G. Scudder" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 15 Jul 2017 18:19:19 +0300 Message-Id: Cc: draft-ietf-idr-bgp-ls-segment-routing-ext@ietf.org, idr-chairs@ietf.org To: idr@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Originating-IP: [193.110.55.12] X-ClientProxiedBy: AM3PR07CA0132.eurprd07.prod.outlook.com (10.165.223.18) To BN3PR05MB2498.namprd05.prod.outlook.com (10.167.3.27) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f7d80291-9ac1-40ac-1dbb-08d4cb94e61d X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(48565401081)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR05MB2498; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 3:03mUyPKxjvyQz5FkfzB0fr5nIThTborOowcAt6F9h/0yhvPZcuPLfqACWOW+OyyBBG6IbaG64oFFonfnzJdXrC9MqycLpFhN5ZF2DFoXYPezJcClvILCqah/8cCpxPkHKNZcMLMu8+toCpsKijXAGK2JfBxiBJm8HIolT8jxa/F8cGAtbXvhjuJ4NYgO09JAQRU+bBED2teYWMBjt0LKPmFh3SZ6nGbNAnEUw0XVWSCoTL0tEdYd6HAw/TuT7kRXjrR2D32qkgVGyUWqve4IyqkgpshD0Fai9pxyAoawcLo24TTz91kLkJoOdrZFEwIXLdpM/fnWlPOnx0AjN4YUnfYYlpJNpGWIMX3L+OIHjiXbzYxiPnZoSSk+LZa4DoiXIhQRBwxhaAz3vhnPTpWQFlSWZjzZ0Ylo+XIztOHBEu7X7jF6VgIXbfCoo4vZofgXQEDwfhHMnx37TFLxFkL6rhJ8odqiI/0xuHCH/r0gRg+LlAGCwpswSBcMzudNHsMUz6gy4xUpxEdEhzohAXWNALfyCL8lxGkcE9i0OFVMDQKb5Aon0sP0jDesB0NbEZu2zv7RHrRZ39hbkRzR82apzukZBLRFx3Wq3riO+wqLUTEvA0t5e5bMK2UbqPcna37zB2dHOG2vteeOjijemFlrEuA9USyAEYdhumuFYTqEf9B/67jjoKd5NiPN3nTq/VLkYWzH4b5c6LqqjcEjODAAIR2cOTQQ5xfA2ohVlgpRG2PBHUTPFTNsxGj7koOcdgOKjl6/qmU3AwxF9+0jet2Ruw== X-MS-TrafficTypeDiagnostic: BN3PR05MB2498: X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 25:o0DSSwo9l7ukEmg+wZfL1RTMtQsSBSLtpV9LquC0gk+Pz6KJZHFJ/0ApWisOgsBvE+E3RTjBUvmZ6+rI/SNCOJtw/GgtLvsuXCkkXrjZHkfNc3yZSe9sa2H4rdsJ2JJvsTzjYC5SdYBeDcEpLjAjmsyqqjHZD1mhMPWthaLxtZj6N9/h4mTkchPfAGr9rIQM9dbvfgTHZxOWCDu+6Pox4j5cBsr03C0+hs1q5omgHjhNQ891x5An5k+sIg2EeFjjWYQDPuU3977Yjzs9lxHO+T2o5ahgP7s4BvO9Z+iC4eeTRz64lPGTI/rPCw60er3m4Uu7E50fPldTM/XZg9UXXtUpzq4XT7MuFke7x+7JpUGPyufqBR7Vzpjbl0TktTd3UZTKoAuuTtwgIQpeHtoIMubqXGUgFfcnQDBQJXDEKyBR9C3dVodJWfRmVQLWmrfGT0w/xB+AxHkm9SRsB+k/CC8s+VIuvnifIifqmwJnbpsx8KiW/hO399McduisVGZlZ/29owRdG/dh4epIxDLi7hg3TTq+hesXnyNOvw1A0Y7Wr+WtPWOPRQ0XQZj1KvdoFk5RpQlDgtlkxMBWA4PaxP1C6eQVxeP2htwhJBcpMJXFvDuYL35HIclumFbJrSEqEVGzheIh8BbsJo5PEqkbogM/ehlsUh1n/NsJEhpzSPQnEaXLJC4hZ5HdlqxgMKXAPrP+7oHM0dWB66x26Q23K1yCHviIdHqLTT+cBlXlGm0PX4DKiEKPbA7cES8vBMyzWLIWcvp75bsPs2Dt89WTiM4W2tAW8A1Nk9s05v8ir9l3bPfxSwesZWMQBMpgxcyizT0nN2i/i+EGkfrYi9ii0bhdytU9bGQMOlVowRt8xvsOnpabuXj5t4QQ0mckf73en8ze2wDsBXCrQRV5MZ/FRdztMnWvka7PU+ZVU/nsRhk= X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 31:V5zMSePL7LM1Vm4vc/B0i1bm/EnYqW++udoMaBSeYp1L3rtggp3aGfd4648IYh8UeMuqYUB8Hzszm+QdxjI9EkVsE2HbKGqagfBWo1/Oh0kScbTAgovbquuJO+2w6T17oLId+CtHZ+ar8L0Pjv5u/xzb4+BIzVpFF4jPSli/rt/veLh3ZgruwL31Sh7PnutIimJ2gRPPrSxSJ/S1p39EfHkc46+W3n3qoNcGCfW/vCI5U+ARA+jzGHBJY8PxA3NieNEqmHDHNCWr36HVS122UkeGwepe6mPZTuYKDOh4pQHDgO09aZpkFWMOswRjGwh4cvfkf/RiGGQkOnoqDGsJS5NAn8mnk8o+OfvKTVzgUej9XOn2ziiMsIcAp8J9lEkSXsYtdP+kUidDug0acd6VcGV4QmWRlk6Bbb6DQaMcam3YpJ+JAf03Ca2q8shPqgyEgVSAaLtgAdCR3JYKib+5nv3jWf7KYImTkDE+DhFDor58A8eXdMG/uN4fciPehPry4DiOVeIApBo6ajPkW012EF5t8DHQIJ19OPbEaJWUWdCgANFeGDSbVrJANdn+nk7sL3UjQc2kw68MXfh+OPCJo+AKyYfqE5YkanB47DrOTzsVLcvqUtAVvHiH98wq8bWAXs1K1r/EkPG8SgbCUOmGylI+rdAvnKRvPk81LvdrCVOcQTJJTW3cNxwWkAPrXdzXAA55kxRxc906OSXl698Dyg== X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 20:ugqoDTD0iDSx9wwfjrxwmSN5EvMExNFlUacNhkGyw3HzYLfuvyNgkKEI9YgoXzXopCGBYCnHbtJU6RkAy/IrMQB27NTlTRtO+g+5IHg+hXVvVRnCFfBsdWCAlmXiOnCAYuMRoh4a5WfN6IRpcmrkzeOs0EiGNnyZRumOYOJDTB6Ng/MVbAUyX3MqWWAI2t7hCWF8cpAZcJEl3i5ue8rtJe0zryImkDtEYoXu3mTfAz/6obraQiKHKyWlpO0fOzTg01viZXtJgiydHIuKRHtgekfAvZPsgDTAtfQKBhVyG/rpMyR7i/6HGwqeyHwlkC46k31POA5IgP8XpP7GsVWfmfSlChhUN4qbGQpUae/dhve9MRlPPWpqX3+veeqPqIHdvcMIyYJZysivvcnozTX5GrrAlnUZ8d0bzKSOS1OgXKRHv9KvrsLXi0JBJHSRMc68DEeMRumiijnDZQGTbviowlBKfvpngvYX7AeHP0IfVq38yzOtFXiQIwdHMZPabYH1 X-Exchange-Antispam-Report-Test: UriScan:(236129657087228); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(5005006)(8121501046)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(20161123564025)(20161123558100)(20161123562025)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR05MB2498; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR05MB2498; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR05MB2498; 4:9OJtr2K7MbmthyuRmENpY70une0x5SDXQBwcvx/f29?= =?us-ascii?Q?xL9ZGiV1+y5erfczz7BWp83rU0fro29qnZfnaQl7nQDivLitUcvRV+ovb5s7?= =?us-ascii?Q?TgFVKH/a3muqSABszT8OdASVtFnOpN+iOt28wGTWjzFwkYXK57wOkcGy2NeM?= =?us-ascii?Q?HKLwrsbWEkWS0QkNV8RxaK3mgHv7gU/50M6VFa0V7guNesH1i5EmMSbtB9qx?= =?us-ascii?Q?Kpz0j4yN8z+Hs20d37W2y1e1UMcGspwGA+qas+QWI12QR21XiBA80XXAuugq?= =?us-ascii?Q?B6hxwrJDDRGcxYOBHjSrZTMxcGFhV/+UEET6nW7NqNX1j2cg5WWlB2v2f0dd?= =?us-ascii?Q?R1hTXDciUdQy7Z9MjNk+L7zeN+u0pcMX4c5UlncFnAehytzgC/mfQeYf8lFH?= =?us-ascii?Q?tLCmN3xqn2dvj23RB3I3tCaHIbtfXYa0tqNTSUBI5npCdBjH72xjh8vJOSmL?= =?us-ascii?Q?5S6oITMnkUmNKLc8HrbZS5YyJTdFcdVckwVy8JV/mNG+nH7pbZRCRW1VwZ5f?= =?us-ascii?Q?VSYXez053XzpNKDXLto6o0WqlVlCu6bQgkZ3FTJlbp+iw5OfmhrgPZs0D0q8?= =?us-ascii?Q?MvfjdI7fiIW1+tSDmaiH8SSMyhMVL/FA7N4QuSshcowbzQmskWmRgurdqzPL?= =?us-ascii?Q?TUmeQgC2EQlCUQP3ed+V++xhxhRl6rXA0Tt0NcjJboIuZZzM4ETOC0I2puYP?= =?us-ascii?Q?sNoaRNmH2md9pEQ+A9L1gZoaOuZkCaY4r4ZFdIsv7wabrOQF8IUnr8prK7gQ?= =?us-ascii?Q?mHa+/uXWJB4YrEXv1ZbF0FfWknoqv8BoNm1QuOmqXDfwy3fAYAMfVg7zW/Wy?= =?us-ascii?Q?vxrFlpE3AUnh0pwhug901MEGL0ZreynThDyNCGFRPLm1lHlqhZaol6PLG/63?= =?us-ascii?Q?plTJPasEsKXTpmVn5Y2n3k0qx+G01TWkiri3xV5BibSEE90JHNctkeXiYeT/?= =?us-ascii?Q?eeqdWn/EiFWfW9esZHnCcGJtoTLHYK9C3ynSYh4fzvGUiCRRUCT5UOwglN9e?= =?us-ascii?Q?ye7RDY+4XZokHfT3JZHHkhwwfqxL0H75KlwPE39pLr+1tjSuN1S2Zt8MmZv5?= =?us-ascii?Q?WOTKMnF/nHB8jPww0cBc3JVwJXOBFsiuw8c7VYtMpGXOg/3yIH+oCHbt6ri5?= =?us-ascii?Q?EDdWq7REpG3UKFhzdMCbGsG+uSd7tq3tc7tRZ74Oa5w3DAU2jubBEOPBJgww?= =?us-ascii?Q?LkYke8P5u2/4qv9b6j/eJft0WiwEn3JraAfZXqHoMYjVECM69+JOeF6qG7XF?= =?us-ascii?Q?EKUKxWMfFMaji/JPA=3D?= X-Forefront-PRVS: 0369E8196C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(7370300001)(4630300001)(6009001)(6049001)(39400400002)(39410400002)(39450400003)(39840400002)(39850400002)(39860400002)(53754006)(50986999)(305945005)(38730400002)(53936002)(4326008)(478600001)(966005)(450100002)(110136004)(6666003)(50466002)(2351001)(230783001)(2361001)(2906002)(90366009)(6306002)(36756003)(33656002)(6916009)(25786009)(81166006)(6116002)(8746002)(82746002)(8676002)(47776003)(57306001)(77096006)(7736002)(50226002)(7350300001)(66066001)(86362001)(3846002)(189998001)(6486002)(5660300001)(83716003)(42186005)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR05MB2498; H:[172.29.66.35]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR05MB2498; 23:ZdlwAegjDyGuCnR2PPJtqBWf5RLDbTZ8lwWP5v+t0?= =?us-ascii?Q?dL0yT8EWpu+6hKedCsGqfehCrA6uBtsAPXaGM+t2zo6EcU3L0D1jFG6rRDng?= =?us-ascii?Q?Qd1aOp95iX3g+OrfQDauH77y0fkDc/JbkO4oq0kKZkk6h8OzdRKAlA+eIX+v?= =?us-ascii?Q?ZlFDjA/XoopLAjbMOPj04saO+e2uOk9SC+ws7wGey9AYk1qYUC1HJl7Dxvek?= =?us-ascii?Q?l4HOXcOn+83ILMStDjc+kgo1tu3WfTeazlYnVJWwX01KgfJ0pKYCTZimLaIu?= =?us-ascii?Q?rPjb69TiqHj595muURHGXHK1a8MDtRvkWD53jy7dpyz2bn3YWmi1l1Z22PiH?= =?us-ascii?Q?dn2Ml7rO6Uih6ETG9VgcuAnerGtDwlSyts4FOfsCVvJSppoVYzxjTwLwAEKy?= =?us-ascii?Q?XN9tqYm0yeysFGubc8m87BzFiAPZEv9CdZwF7VH07f7jQ6XOpTkEP+gEGdVK?= =?us-ascii?Q?GiKYOKUT+7voU8wr4p342bPlpbRjBj798kcIH42Vv0a3Bc059OPL34+3YvrS?= =?us-ascii?Q?n27l5OCLs+KCWpELxMijx9caV4E9CUQOOyTHu1sYp3wiNIOg0Al+ozdA0HpS?= =?us-ascii?Q?oBYOcUTK6wUuQtqGwp0LnKFA63O+WHg0s8JZFHXfJjzoLL+ZKEcS9bLUchOk?= =?us-ascii?Q?FRzUSQdxhrA9sSxN/RI+j2d4FUM44G2oHhdHqWi6Xc4ZcE27pmRSgUo9q44e?= =?us-ascii?Q?pyOg+8Mmf/X0z8chggTwK4Yi6wQpce/vGyM9QL+RHFtObvS4v06ZXdxpEWzR?= =?us-ascii?Q?vYXn7CRLIn3Gljje1lhw81GzZzWCwGANyK9vfSvK73KosH88ycWUa+VZfnYW?= =?us-ascii?Q?bTfWlHS+vAWDQxK+hyhxwDpukD8gOO7toVVcE5KFHuzb62jmjIDPEBxp4QID?= =?us-ascii?Q?bfQGRpJSI7eFvcOcGlZIg87p/OLu0GjzaZGYcRoovmG0KeNYcasm7qQ/YAf7?= =?us-ascii?Q?j2zAQ5rFhxRgm+i2Ea4G+oo9jcP5fOp0GE5cb2kYkkZLTK02Arbo61/Z0ibV?= =?us-ascii?Q?v3JrDb30SE9Xq/o+N0EUMfV6Y8rUHNCfWysTfPo+nDRYBUc5AB37msYlB2kc?= =?us-ascii?Q?/ZtuXpRaBMk/tGbv08aUQefgJcqrpZKiM31L0lLXQ2aYBsIuNM39fyZxKH+u?= =?us-ascii?Q?9dRQX0O6pBPuGzbIOeGk1Q6tDGyK8d+oVWlZdL1obnH1BWK9leGFfeFfbAb/?= =?us-ascii?Q?LlNY2qfCudHlyUsLe0MbqdjG4koxb4kfw8gPeyginA6A7F27+gFsGD7hVxAf?= =?us-ascii?Q?ytg7w9YFrDGmZMvDMqUiHOj3Rqe/BE3oGOTdYGR?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR05MB2498; 6:k8IwzXSWnSYbuOnrUq/bwJlZuNNTr3N5XdGG7/SDYu?= =?us-ascii?Q?WiMt4Y/Tx2pjmZAm/mxk5e5RGNgI7LM1rzqWPMAokBvzKTiEvPvWm9YEKkV/?= =?us-ascii?Q?sRONzOCpmKSGCS9BonstCy6rV4RrkRWqcGa+hWF1FZTVwrU3Sx2yGyp0fpn0?= =?us-ascii?Q?qImZUa8yXLhUximozOZGCmWQyabH7r8h7hso5z3wFMIsH/bDGguoG/fQwbUA?= =?us-ascii?Q?rDbiHCXUW+C5LgToGQxpqExbZ9TKu+beZh9BP0q609B+FSvzRidNteSZY6Nk?= =?us-ascii?Q?b81A7cntju9Y5SVHAkpHBndnku53aBIlyAME3Y9YnfJ07/d6l0yV+SOvUbwN?= =?us-ascii?Q?E7ztsPRZOUvRADfk8PAGzEQIzP+VuuvL1wmTuES+69zCb8ID+Jy8AYpgYcEt?= =?us-ascii?Q?bjFWQ5GSAE6uamBC0F4hYDmQj5eq0oEHiyEQD2MXPiRfu/hNFBYqvI/G9exu?= =?us-ascii?Q?e5IpY7WyfvjGj/v1HB0Y6R6+5uON/eL5VhPbbDp05YgV9ex3UtCc2WF53sDx?= =?us-ascii?Q?Bs1TgJ3lHDsyjNCv5xzIpZzu4FAav958tH9nvqmwJXTg+wYmHKewkgWv6ZEA?= =?us-ascii?Q?YaR5waFxFcUhVHUkkFJJLA3cc5x3bldUpuiUb1tLP7eeLs7x7ZvBaem0iaYE?= =?us-ascii?Q?KdYJB1sd/ANyz1DUc/H5Lg2Kdd5JS0NCkDhFCFCqMlIFNwdCHnTzjtO2ZXtZ?= =?us-ascii?Q?X2AD38oMqKpVrOkdA7CFiURKpbjsWi3UvOG3kaPM0HcGk/fPdkjfW77I9y2g?= =?us-ascii?Q?9rJGrpQCuJ/APNejJS8KEvUwitNk1rhlWSU/unpFhn1HtfE6IpYLXC/EIKYB?= =?us-ascii?Q?DsnqQWCzAUzukIOY8MqoHJqhcAyJh2Qk9suJZVFHEXgX5/00BHcieKCiZM1y?= =?us-ascii?Q?tr11EaRFNqxj/k8vV3f0PAvmE0cpYKUFhny8mBvPOXNiiU5B0cQc2AY11Rie?= =?us-ascii?Q?BBB7k13xVnUUryBUAfHZJSPeGobCr42VUq8WTppwxRjUpjY4XQUWBf4O0n8J?= =?us-ascii?Q?5TWbgF9rQkgl3Hn1EQjRV3?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 5:F5H+HiRr1T7mumwar8eNyomupdPwOyZ8WESostqECs4O41NkB0TaVaafvXcpt6fvCDRgnS/ydAsopHnYeEcOL0/Y/OuAXV9ZhjRu1DBbJJNdfsclkoO4CB9Zzyv0+Um1NY56Fzp1U9++PG/yMHjT1RvmwSZA9K0XnEKupIkktHAmcMcRo6sM6hnXv9EYej6ZcchflhtNgWwLTkkYZ0sQASa8f6MGhiH9SZanBuMW36oDz56elnUU6As16kpqR9DRKD75cqsB9bS2Lqh1p1CuSIJdkS5UbGcNE4YuIizQsuKk9YeEumkshtRmMGY51CyWzmzJx8GFM0fjm/mOKSWTKDM/cxD/CUL4sTdgY+hhMJ7dQbq8/PaqfVp/tKlDwNF2SKKYLEdwHGvXzhGuyCVOGCi1m3CJZys9jr62jEiX+0KqLJU7pml0n2EzJQ5EbBsuzmSLK5uVQ24EmBof0En/vjrWizpwV2Sorc0Cq85zd1g/N7l5S068/SLjBHrglAno; 24:GqnEHQa8j6CAgzu/hotlljpY8yBhsUZx7N9SzesCqolutRjnEXWBeZEd016ghaX940YkvzE3+49tkTPkZPR9w+JafIPYknUSSZlfoZMTJOI= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 7:MogIXSzRf4gagk9wPKXvtQ5rLrVIvbCCiwuMIEqlQzeeapNmN1652f7f/TE5Dx6grdqdNeO4p3nF+neWFWjpjF8U8JXy9Lz6in45+MiaBb088hxsDaaLr11e1u24/gjrUVH9+VR+nBqiLiWVuvw80F0JH0hLe7e+ZpqGAGS4CC59UM9vKb6Q2fAt6Zje5G6waY6BFIS4I01jo+jBOPBd35TE+YKXcpmjYUc4z1hfB4Fd9Kqkn7xkZgi5F6eEA9mXtczYjJPk/PGEcIlD+AvpwWMiii2IG43HOeDua3isWRPrEE/uax+IHQS4RSPxMBaFiAXlqINMY8+MmEgKVP7Sc2tRRQ4XmqPYrTF2OTMfEGrjjUY6dAEklXt4kNf9VAyV7z5JJuKgzBNOvbGt7q4hduC1EXJ2CLnoZXtrnAkx2H7zEAPrcIk43k1XAUBMGZMlaZ0yEbwDMWYdbURr1EXFwWMJmPObSSa+60WIulnL3sSI2o7r9Heefg4h46FbOVVxeAL01+dRqkCbGyzRYx1i0bZttVcKuPLJKM6/fCyPRm6SSBam7LLS2mCD+j8S0wU1o/t9KDCFz444EF61o79oau2sdZBA+J9iRtQLqVgVsXaRArF86zTqUhVNocu6TWs0EDVbsW65wsL3e4iwVqqrFHShSnmigGXDNS/HRwOEf9nuG12yRSu0eT2yr0kMxFzXUnNxWq+aRAPBYYFnEEkMjar9KMCpCpkALEjE1+aPa/p+DiXZ4sktP6/Uyl33F2axn6DHCzDiYaTMoVyPg7yjzNx6MmiQp8C6XO1NY/Tjk4Q= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jul 2017 15:19:32.7973 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR05MB2498 Archived-At: Subject: [Idr] early allocation for draft-ietf-idr-bgp-ls-segment-routing-ext X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 15:19:38 -0000 Hi All (and authors, please take special note), We have a request for early allocation of the code points for = draft-ietf-idr-bgp-ls-segment-routing-ext. This begins a two (working) = week period for discussion, to conclude July 28, 2017. As a reminder, RFC 7120 has the following conditions for Early = Allocation: a. The code points must be from a space designated as "RFC Required", "IETF Review", or "Standards Action". Additionally, requests for early assignment of code points from a "Specification Required" registry are allowed if the specification will be published as an RFC. Yes. Assuming the registry is "BGP-LS Node Descriptor, Link Descriptor, = Prefix Descriptor, and Attribute TLVs", it's "Specification Required". b. The format, semantics, processing, and other rules related to handling the protocol entities defined by the code points (henceforth called "specifications") must be adequately described in an Internet-Draft. WG members can decide for themselves if they're "adequately described" = but my working assumption is they are. c. The specifications of these code points must be stable; i.e., if there is a change, implementations based on the earlier and later specifications must be seamlessly interoperable. The fact the authors have seen fit to list values (see below) suggests = they think the spec is stable, although explicit confirmation of this = would be nice. d. The Working Group chairs and Area Directors (ADs) judge that there is sufficient interest in the community for early (pre-RFC) implementation and deployment, or that failure to make an early allocation might lead to contention for the code point in the field. WG adoption of the draft and active work on it suggests there is = sufficient interest. This email is an opportunity to discuss further as = needed. I also note that the draft "suggests" (i.e., squats on) the various code = points in question. This is a generally discouraged practice in the IETF = and specifically discouraged in IDR, see = https://trac.ietf.org/trac/idr/wiki/Checklist%20for%20writing%20a%20BGP-re= lated%20draft Authors, please remove the "suggested" code points and = reissue the draft at first opportunity. When (if) the early allocation = request is fulfilled, you can reissue with the proper code points. While you're at it, I notice the IANA Considerations section doesn't = name the registry the allocations are requested from. I assume it's = "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and = Attribute TLVs". Please say so explicitly in the IANA section. Thanks, --John= From nobody Sat Jul 15 08:23:56 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE3C21316D0; Sat, 15 Jul 2017 08:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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=juniper.net 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 GHtXdQE7w0tY; Sat, 15 Jul 2017 08:23:53 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0122.outbound.protection.outlook.com [104.47.34.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 051F712FEEB; Sat, 15 Jul 2017 08:23:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=A01PUzrqkczG3zhc55h/ctYqSr6e/Z5R8gIfUeghxJA=; b=jwNI4GwUj0HrbTFfW0MXf2UbnTqFojuw16iabrA0nijrzrcOTXp3q4jr3tYiwz9YGTHRJ7t5THLGnpat+JF/rYv9Ebvhlm0kbWkdmSzjNoFp9VQTNEuMqeZFw/L2bV5z/gDz1yH82wOQWKk6pk8bTlBrySyK1fWsNE3WpQiIG40= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; Received: from [172.29.66.35] (193.110.55.12) by SN2PR05MB2512.namprd05.prod.outlook.com (10.166.213.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Sat, 15 Jul 2017 15:23:50 +0000 From: "John G. Scudder" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 15 Jul 2017 18:23:44 +0300 Message-Id: Cc: draft-ietf-idr-te-pm-bgp@ietf.org, idr-chairs To: idr wg Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Originating-IP: [193.110.55.12] X-ClientProxiedBy: BN6PR0101CA0010.prod.exchangelabs.com (10.174.85.23) To SN2PR05MB2512.namprd05.prod.outlook.com (10.166.213.21) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 7a051546-0910-4a04-7bb2-08d4cb957fc6 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(48565401081)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:SN2PR05MB2512; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2512; 3:Y1JoiZQPwE3OKHtztS7GyLiaIM5w0eydLdBNPD6sXaUEGxuBiYeVC4RmOOSNV6Xq1AlLdFMX9Tbh8ZJ27FyXuzdgx2ZC8EwrSCUecB01CzhhtoHVGYiK070UXiZ9u6SXdh5McqCGWMuJQPkGLOPgP0Gh1Mn8dByyfTNKDWZuBgUZ7ysSpxSrreolsa0HPG9dUcQ3NvgerVA1WD9LdA8oPvraUm88uyN8b8repEzsFWgbZw2g3tMcYhinqwoimS3hpTQLFWWL3hq+gkXeVPHJBSJdEFWJqslYEsgcvY+3FBvY4sOE8t9NuBT5YqI8P9yzn7fJZvLXUCun0iJuBkSlM66Fi6eCJWI9f/F5Divj7botYqhJII1tlSStbaS/pSLtLMzBbTk9CRyS9JYtG9cN3clsDMPaRpdLvoRLq4+dF+2+r73z/O/SjSv7Rql6e1Xp7KAk01pI5Bz1gpp+u1SK7VkhRDs6l8nxrqtgFcowtRDbCRg/1bTxLBX9wMM/7n0+wgJj5UfbqWfzrRckWnOJfa/gJvSk3F9lAMQNkgzWIIwipx/eua/IFp03nBzpGwTL0ID/SxhXAA5rA8nHV50OAkNukibj4+qBMCdE/L7V5xLUBH/hseBAGs9MmGnhulFY3AfGNmLkmTWUiUCqjrg4h/kEQ/dV7k7D40DXN0Kb7rA3mZ+BaPtku2p8emUj2Cu4MW06lB7HC8M141HeQxTwLcXxYgsW08trTOINm5kRSpm1LB2d2xAaqRrYQlC9BYWvDKdAgQ284nweWCYx6PdtvQ== X-MS-TrafficTypeDiagnostic: SN2PR05MB2512: X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2512; 25:8Xt4BmHB+nlo5+HJAgkU0n5B9+DfJk/V8BDgCjuGXd97tbkCIdAfdQvw/FT0i/NEs2wPsBWfA9xMo4hBo7KpxbmKxQ9V1BFmteO7NARSMYXgZWsONowTs8nJjU2k1ga8UntLS9webuXS4VyTPxYu/DaY4wgMoeb65GRb4s1QjP8bu6T5F5IdVMXWstEQg6k2J807NcV4ZGwT1UBRg9PIRPtotIB2kh441Y9q/Aqx2PSJgaDevTQW3KwMN+ULuGbKv5AwxATJ2Nhwf1i34rK5un4I3OTORrLAsdvG5exF1lum2Jyl6tf2BjWKL1g/yn+1CYlRcethOcYyGLpxl3EN/oKWvv0iPhJ6qkZV0VTUgI1Fj3Scfp2P0j0V8ex9lYkq1EjVG+ALtFMDcmDS12pPOGsGI9W2kXu67iH5zenEe/EEOSSY5hMaoG5n6KiIMljDjyMVkqiJ/7BLSCf0mQcOKovgukktI47Uda84AdvpJp4qeyONAcOuuCVt3UiLQFFOeOXZvRvOsIHMZXXvNcfMgKdhJtW1KsIhMnNcDQcY+9fq4Qyhy9Ja1eOiL7lPRd3Ki5R6Ntg/Ewv2qQR+gVbkVFYJm2CmemFUVfVBK+DgGGpfCX3oOfjqblPxO3S6Z5R16AvZSNnG+iuFawqQ/ZctLlS9mRwGIDGMGz/9c64py/yVANYs1JZxgcPpOr5EHpsTia8cx27bXqY6sdVUCGWgTY5sBZhr3YHL1o/NCQTEaJWIBimL5WYArVCbP6T1OTA6XM4eIQLQkuUJP3jxgv+0xxIJx48zIPn7hzrDVcG8FVnj+ObpIBlOPHZZO0+DiUXM4YVkYewNFNRraInVtTnNqZJYGKSQ1p5J2xrZMWdXoR+pPtPI1Scd1D4gUEoYb3n4uf4qQfCBm47wgzFsRNkWHz0Uh8TXoxAE+qBSUzuGeuY= X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2512; 31:PQccPgozOZG8fxPqQz45U0J2wKIcO/jj3WsEoqAQC6gmvJZ7j4NelYD4yQoEjstdMki9QTwPEpZ5KOW12hbbrkoKYjlGKVoSTk/oa9qqLYH916HexZUBX8VT+ddfqd+JFOUQtxHs4VDg9ECjkSsi+st/D1yprOwxcwwOC/qUL1yfynA5cMDqaVHrgyCTQtZdfzxHZ3FER06rx/ayM5gTqiQ3fOFpgMjk9z2sRghaftAXBPctir8A9oZCb4KwwQ58KxE59Z0Uo9KtZY7a0Qa+fDi6ZQWLOg7GWOL8E3L5A60nbTINM4+5vocUqTBEqc+uFOS++2zfZgMiqRlA6xbMu8eikaFHLZz+LcV861VwcXZKJfVL3Kfj5Y/tPHjP+Gifw4q+HhkYiwwbBNaXURyJT3h0ejFdvPJAPodRWjhdiPJWboEmJGcdOU0CTiWPXY6pInxVkCgcASOanzf+9pGWQ5VOSRlm+00OYnPT3Rv2J3VRAtWhl5PB4pLOQLgD8j/u3HJoNVSFseya+8MlI+EnCluAvOfOa6gDWl29eIy8HuT5Nh2qWvmNXDilGrGhINf/9V1aqWLdJs51njoR8JdRfCyr6BlCu5EaKKdT2nwcpuGnb4nspp3qnr2yJd6zbsmw7o13uml0l0E/oA0ssrAa1cuZVlV7UWz3mA2hL7TrG26OzNbchQkuU7f4oPchQUVNGc4u/5cR7+p7HubqL9Zobg== X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2512; 20:pKop3MbW3pj7cxdi81uqERwqKx4wVICPGXT9vDbZNxZ+TUec9ZMS77xOcSerG2Hw8rhixPstqI1RqrhNUlzcL1jc9wF1c4y5gk3JQsedAb5rSQsHGKuomIs0viWLI2zJBe+9t8cKm+wZpIj0N8VMeCMMpx0I7ntw6tZ4G2nyugY5qkVwRyMMx32dCN2TBPwT109yywJSh7HH1Mq+6T0p9x2H5b3nw/LjewqOCWkkEAMNXsaDycK2Ki0kCYij9b+iMnj5DF1/4h+FWmw6DAnL2fG6KE68yvGejky09Uy1S2fZvjnFkNZ5v7a1VQUi65ijhLhaJhqVR9AhXwpvHoM0v0ZJNS4vN/Oe0IGU0U/VJoqZmNNzxubChWebrmXj1XPfIfDg8JbUBcBJidvhaD6jHxc33Z/5Hlxwjy0e/85h/zTPSDiM2RjxzUlrB+mR03bKQP7SjLri0P+kw2xD28wzB+7aHnQm5OoNav0zlhiT7lZT6cLz7P/1YamPVIzbGpwN X-Exchange-Antispam-Report-Test: UriScan:(236129657087228); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(2017060910075)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN2PR05MB2512; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN2PR05MB2512; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR05MB2512; 4:OND6A4dvsYEYd/5LaU2FOhcGsr9+sxe3D+oJc9Ogxr?= =?us-ascii?Q?kh0X1s3BdgJL0yScL11DooxcpFeH2L443ReHYtXVvl6xw21sDkc7aA13QOi1?= =?us-ascii?Q?gmyjaQ5BcnRgH06ZXnPpUavRWE+BuupZCjo13TZdMzkvZyLK8hG01rsDGB+h?= =?us-ascii?Q?bCMycm7Wtduavu6ps1OewUpYDboSpI8AzwYJOkA+Wws1vphvSmutmHIQNHFM?= =?us-ascii?Q?VdP0hd1YYkw36pCZfG4/Mr3PuRBNpQ2lPzFMMx7mfkj5i1TO9/D3i+h6DFN3?= =?us-ascii?Q?5WGoLWrktTuK9bNyjxHev2pTf1E+rWJZX8lNn4nLbjOIfZzdWBq6WIXPmoOK?= =?us-ascii?Q?zjHAmma1fb2i07oLOTBcDFOb2W3n3H4DC2brCRkqZfgGLcqDs7TihDTk3fN5?= =?us-ascii?Q?DdIb32yHAZlObUL0UXpIl0WTxMNLoO6R1oHdgjvO9/Lr+i7yLF4cFzsSMY38?= =?us-ascii?Q?1urgVWvvmVI2xdV/C0X7nfJ0TmkgDJvqxTRsFqvvo+EY6VPY1cLQH/94yJnz?= =?us-ascii?Q?B4ekuRweyCWZ6YDh+mHYl7EwvK7iML385IeUSp9aCjH8c4KODCwioJqYXTUe?= =?us-ascii?Q?wMtYUrCu22EYwaGWrpwBctx7AEe6xDXcgWeM1CVsqOgB4acB4F4AVfqJTwHG?= =?us-ascii?Q?RnK/P4F7jOmE6WVMgZzR81nu2gLQAUU6B641P7XPYACTct8Oaj/zpDMTJpoD?= =?us-ascii?Q?z6Eg9ClGjUXfWC/pIHw4bhc0toD2bNgbFdDU57mX9gqro8jvBiGRU9LFsInR?= =?us-ascii?Q?5r5auKVMbNB8GD7QOtv8CAE/UGXYarSv3MEWwKiCzHc01ieEM50WTKV/GJMx?= =?us-ascii?Q?79dCAGqm094ClhuXTvcTGN5nWrLqW0Wm3x+DuV4RUqNq3xs2YcWqcrJY1tZt?= =?us-ascii?Q?4Iru5+DrMrmP6H5MdgLbesjlGO222nLuxeKYkxvdT30wG8UFCRxauTBbi7Ww?= =?us-ascii?Q?JOBzR0wJPOtGIFrHSMKNCOi5a1xVa+rckv6ofpr9AevABUSeGKPdfZ3W6HSC?= =?us-ascii?Q?yvRmodRGD0rqTjE9x5O8knJ+KD9m9ruVm9jttM579JFU2mPPVAFjP+VvajH+?= =?us-ascii?Q?t5RreFLhGJzoqHhXhhYmaYf2YnOlncZdVKZCPnjIBIfGYRufSOTFjsWpBd7l?= =?us-ascii?Q?6vALUgD1OdhfqVbUjfNTwaETIdY4sdrQDkK8iBcsqRmCTL9wa9jMQsEyFgpb?= =?us-ascii?Q?zJo4IavUWTJAGogXx1JB99rJStXT7IWk2oCno4NIM0z38y1ckxaE+7SLDa27?= =?us-ascii?Q?Ado8ji05NDfgwgmD4=3D?= X-Forefront-PRVS: 0369E8196C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(7370300001)(4630300001)(6049001)(6009001)(39410400002)(39840400002)(39450400003)(39860400002)(39400400002)(39850400002)(53754006)(7736002)(6116002)(53936002)(50986999)(8746002)(3846002)(6306002)(450100002)(478600001)(2906002)(8676002)(81166006)(33656002)(50466002)(230783001)(966005)(36756003)(110136004)(38730400002)(25786009)(305945005)(42186005)(4326008)(47776003)(50226002)(57306001)(7350300001)(6666003)(82746002)(66066001)(189998001)(83716003)(5660300001)(6486002)(77096006)(90366009)(86362001)(6916009)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR05MB2512; H:[172.29.66.35]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR05MB2512; 23:dSeI+MjBBR6G6z/wGuk5f/+Y1F0L/qqM+TO56rNIr?= =?us-ascii?Q?svIax5TXdnz7tu1F5Kp3sc7fJqp6Dbnd3353iFxGgI6mqmgkgYixM1FjR3Hr?= =?us-ascii?Q?h+S+8pgN45DEWJOqblZSXPyRMKnkO/zToynsw3jODK5rDLdZTVLHBO/ORn8f?= =?us-ascii?Q?8tXN+KUGehSUOAjBem2WOAnNo3iDPOoIaQC0MfULvytdsAlglu07n4KIKIEE?= =?us-ascii?Q?o3CWrJtK0yIi3QgJ3uT2uu6S8BorGGjYHZ2h/+LgDwSzp2sMDvVIttnHIZxO?= =?us-ascii?Q?/EaGTh52awV01Xn58ab39L44VOO4nypqtCU9t8Md/+jZRXqaCmzTcgI8v7Ib?= =?us-ascii?Q?CEi1VgVTHAVpSvJn1Y1IxmtIo9CoALep3UE/mpFFEZlKu0mz6UwLskNrgWVS?= =?us-ascii?Q?VowODw9/flWgW1tEmNBDYUO1YHmrIGWS+qiev0rhjI1t7rBqLMi/5SrThnsE?= =?us-ascii?Q?MAtuU9GSKtQqf0wDqimyxEsMtUXgTfAFuf1343lu3oIdkBiBykS5l+S8BfHG?= =?us-ascii?Q?M/N++hiDk90C2fRYkmLBD5SnjIGV/KjLYRJacWwUoDXve0JRDlKxaY8/+RGk?= =?us-ascii?Q?GGIs7W6bfJfX0RWkQ75VpW0SjvYgrJW6jY25Q28QUGbHoTrDO4Dc3hvMyW/j?= =?us-ascii?Q?rhnZyAJBgi0lT0N7IFWrn488CMfZpWNsGAMNWYd5ZtDLvO27RYMD3fLov+Dr?= =?us-ascii?Q?nOhDMy4mvc2jWcyXw896TS3cMQa34s4rpnc9/1pb/EPXaTAy4d/xoizTZi1q?= =?us-ascii?Q?oRqulsAacBkVqwgaOZmgDxNmiMYeoFPpghMsk63iK3R2NdzQq5c/IS4e8LfP?= =?us-ascii?Q?qgAzyUmSwqI9Zgd6c+GqsrVZo7KOhyJlrmLJOS4rWfYzX5254cIMEp/6qLeB?= =?us-ascii?Q?lzj+ohHlGHvVIQlqpgtiIn2DQ0cUq5TNBGUNwFsiyAQvjFpe5CTYGiHUhevj?= =?us-ascii?Q?50lxtuPySFZ6I0fywljgM4NCfyFA6MlFAp5XLiKhAGQgBhrpiSmV5l6nsez/?= =?us-ascii?Q?m9BN+iRGCPe3TlzC/nLjAdrWalVfc86dbt9MDx6Jnvi9sa/1/W2z8Nx07b6U?= =?us-ascii?Q?fCoDMC5TdZAnf2QqTzKUoHU3cK7OaF6tJekJedybSG9IfQP9cd8evCOr66mk?= =?us-ascii?Q?Hmp4l5Cf7E/yvFiIDHx8Ha8WCAzzyhQ8C2zO5hS6seqOxz+RCGQQ96DZH2tq?= =?us-ascii?Q?jTiqUIKnQk7YPklc5o38hR+BxhOdeyObW0Q3ExZDyQep6cEUuevdFVrZXN7Q?= =?us-ascii?Q?1nJOk+TymLwfdAf3uM=3D?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR05MB2512; 6:R3PVWxsFruwJss7bs9yERiNaGMdEiaOkdNUn8Lt1ep?= =?us-ascii?Q?psOwS6JUnssaVDxOd+p+d9abe0jt4oubUFkyPcqnSVPcToCvWWo0cUULQipn?= =?us-ascii?Q?DUAK/iCiVLCvE4bucajf10AfMoP5Xmphes4OCCv1yt7BSPvMeBjNm+Y59xJj?= =?us-ascii?Q?oC0rUdKlZ5Ln7Or4ALdPcc2TUzbctNCBRh0Nm4Wbs1Fuc9p56DNbur2Hl5Hs?= =?us-ascii?Q?QCqjjH/TJrFlso568hYOFWT1lNBnDiFwe02SLarxaKm7BrZ2+vSHOFs8gLPt?= =?us-ascii?Q?HRHeM6tXv0NiZ734atB20EZnwGWqMctkpO1p9RCxmOBCO8z0i5QUgryRHNzf?= =?us-ascii?Q?QBatzv3w9YN8fz0Zj2Ef9pgi6Zvx9Q/88CgHicoakB0AkHO8lAWlI4Zba8HD?= =?us-ascii?Q?wA0S6HrZkgc3QFbQMAlT0WtRY4XlNMCkVuS5g/Ll1p1Cw6kc6Y+1EfM5iON0?= =?us-ascii?Q?PZkBBUChPqXS1/731UymhEl1tVK4w9fQTASAaIK92Ia4cugisH4l24Wg3kmE?= =?us-ascii?Q?A9eMKM8tLS9M3yw4iSGQYVgRw51Zn+pQWdMIq+UugEiRC0rNUMVzvCOJNIlS?= =?us-ascii?Q?SBCzMDZviSybIjXZ7/Ucht1OWl8aB91dGszH/Zpsv8w0VEnkM6rSc2swxKmx?= =?us-ascii?Q?EI1oyjYa/O+Rb+P3UOXaaXO7sUzyP9850owEkq3LjZRaYyA3s2EA4S+nYwtw?= =?us-ascii?Q?2e5IJS1ba9j5m1Ine9rxTFMxzRiE1FdAW7clbvIn9G6xL4X7ZFpoWciB+H+d?= =?us-ascii?Q?EoiwK6KLTTuVFWmiarYoI8lw/j4hbFG9je1/UnWdFsp0AwEOvmcSrCu5KjLC?= =?us-ascii?Q?jz6AIt22lMozJgtJEA8m0HZAqsi1mcPbnMXBgfwgPPZJeeXST3SWE0oY6BV4?= =?us-ascii?Q?fCTczH7b5wf3nbm0NpWqI6OvB1szWmHnm9224piyPl7gUTQH3o5JuhoovSFl?= =?us-ascii?Q?a8dhovSXNus0LfWqDrw7GjCrXMdZHdts/EQVKxUtrVsdDFGsGeO2v2PXs0iz?= =?us-ascii?Q?XcEQTTisz6nUofQ+Ep/fUF?= X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2512; 5:ncdvIBMxWmwqMbzPh3sC3YayrFk1DY5Ebgl9503Le7fKe93mWXtU36HNNz6S+iEfm9ZF8Q/qhYngI4n1pWeLIktpQmqhvKotITV5krJ8el2g/r1C7O7ZHm9V5sWU+F2YbfANRz0806hs5VWYS6OQMvpYMF0gwByjIfSTkHqFX4F9Xulr/+t0sLHeg7zkdcHqamAvhpnr2ueFeiE/XQ7R2Du6Tl11ykD6c93chNMmcwB4yBY/fdkcT0rc85yb9O81kMz7OD55/jX0ZPdpOp2o6n4ftryWYaIotDvT7Gm0wr2WN6n6zFebVdHpqgLc+8QuXc8C65Z83ikbcJrhMyIDMNlwD6xtNZndfQ4MV0w6A4MdRh7NOqqe17wn72SMvnQUiSt/eNmaj2xDDEIz0rRlOBpBrG8sbZfgw7H+/OcrRzXadSXaW5YCxTn8TpXL+Q5J9WsOs7uuNv4OqJD2lo4UUDL3mhg76A5TnqRe078LxS3bIeBWJVBQrZqomp0Aok+7; 24:LjW+yMRkK6Kl3h0pKS0e23L0cyF6rEuIQYWG0z28O/v62exSq6Pg0iHEQrpRDYoHevvjKijuoA6HSWVLZMsE/OtCZkGBAfAy80X1Q9vUwUw= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2512; 7:/oKig+n3O0mrRXOJs46nU+WQJyM9UoXDL2KT8UyN3cD4N2YLiACIkZx/JG+owBKTXTskBvoH5ai7qOknVJz7KTDoHdgoyY+kU0YKYabZyDQ1ZuKx+KvYtEfK9xNrNmMzCGrg45ddfitzrnpX376EJB0XAJSqpO5Z4LRwRD7oAGw6GEJufOCvxmLnGCEXcDljIRNsB4NpD3wnLk+8OJkISQ8gooljq+bwXEX5qZvuBUOEpIMwLLKRk6A/YnrqpKKTe5C6iIzJn2X7yVL1+GQHewPPX5lmqgD5lsuLMD1JiwjT6BN1cMIUXNbM1j/1MqeuO13bDNZU0ZhloBUu4qSIz8bL1nAHfN8ZxQkLaoBCGbEz3BsmzPFl6yr2BBy2eCpOMST8gAkMp/6bilAGPY1xxZQd8+8QR9jWlPKbSDTzTp0RVKCoeWCo09jOqW9FDBgrYtzK+pS3eIQf3Te4vptKGHE0gXLE1JsMNw2ROWZyAqRrd3+12kJMRGsS/gF0hDRKEKz3mLU+RtySbjyHhAb6cGoYMO5Mra2yEPVcKsRGz6JlMbSrWFUX1sDBxzQeDZ8/1PMASSHqLidffS4XhEzM8EhP1jGr0cacBwKCV4hv7jv0yRXJBux7GfLcWyI939/+k/w0NgHb9XPJyInlbrTjf80IrFc7sdSS23414+h7h24EznTRzBfe+E/Im0UfT4mM3b8bViSgYWaVLRnGFwIwo+fZe1tsfKwSmSh/WP//ece02ZOQKr66YFUCALKzY6tSMbwHKgfSDaD0dOsf48aDDBUKXimOra51fspbHJwJEM8= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jul 2017 15:23:50.5675 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR05MB2512 Archived-At: Subject: [Idr] early allocation for draft-ietf-idr-te-pm-bgp X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 15:23:55 -0000 Hi All (and authors, please take special note), We have a request for early allocation of the code points for = draft-ietf-idr-te-pm-bgp. This begins a two (working) week period for = discussion, to conclude July 28, 2017. As a reminder, RFC 7120 has the following conditions for Early = Allocation: a. The code points must be from a space designated as "RFC Required", "IETF Review", or "Standards Action". Additionally, requests for early assignment of code points from a "Specification Required" registry are allowed if the specification will be published as an RFC. Yes. The registry "BGP-LS Node Descriptor, Link Descriptor, Prefix = Descriptor, and Attribute TLVs", is "Specification Required". b. The format, semantics, processing, and other rules related to handling the protocol entities defined by the code points (henceforth called "specifications") must be adequately described in an Internet-Draft. WG members can decide for themselves if they're "adequately described" = but my working assumption is they are. c. The specifications of these code points must be stable; i.e., if there is a change, implementations based on the earlier and later specifications must be seamlessly interoperable. The fact the authors have seen fit to list values (see below) suggests = they think the spec is stable, although explicit confirmation of this = would be nice. d. The Working Group chairs and Area Directors (ADs) judge that there is sufficient interest in the community for early (pre-RFC) implementation and deployment, or that failure to make an early allocation might lead to contention for the code point in the field. WG adoption of the draft and active work on it suggests there is = sufficient interest. This email is an opportunity to discuss further as = needed. I also note that the draft "suggests" (i.e., squats on) the various code = points in question. This is a generally discouraged practice in the IETF = and specifically discouraged in IDR, see = https://trac.ietf.org/trac/idr/wiki/Checklist%20for%20writing%20a%20BGP-re= lated%20draft Authors, please remove the "suggested" code points and = reissue the draft at first opportunity. When (if) the early allocation = request is fulfilled, you can reissue with the proper code points. Thanks, --John= From nobody Sat Jul 15 08:42:04 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCF913189D for ; Sat, 15 Jul 2017 08:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_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=juniper.net 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 OwlSSyXIIHwd for ; Sat, 15 Jul 2017 08:42:00 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0112.outbound.protection.outlook.com [104.47.40.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9699129AD3 for ; Sat, 15 Jul 2017 08:41:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4d2kyAFUKYVf/Azp6klBr6zEGDb+l1r0i8oT8iLKePM=; b=XNy98ofaVd6+2vs5Q1/Tcib0VgkzugfDzk4ucg47eg614fRxACJfCdqvIeFtUSFvpytNorugNPEZSjGtQaMBL+zACeX25buOEbCvipcsGdYwGuCCZmyGsfQTmIqwWsl740zng6X8e41+1lqTaT2X1VEQgk/dyU5+N4mNwogANnI= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; Received: from [172.29.66.35] (193.110.55.12) by CO2PR05MB2502.namprd05.prod.outlook.com (10.166.95.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Sat, 15 Jul 2017 15:41:57 +0000 From: "John G. Scudder" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 15 Jul 2017 18:41:49 +0300 Message-Id: <5436099D-D57A-4D29-A744-0E8A3572845F@juniper.net> Cc: hannes@rtbrick.com, adrian@olddog.co.uk To: idr@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Originating-IP: [193.110.55.12] X-ClientProxiedBy: BN6PR20CA0054.namprd20.prod.outlook.com (10.171.181.144) To CO2PR05MB2502.namprd05.prod.outlook.com (10.166.95.148) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: e48bd21a-d340-4bd8-07c0-08d4cb98079b X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(48565401081)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CO2PR05MB2502; X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2502; 3:Lx4nseMrVah3Rl/fpd+lLMQPmDVuaaCUlhLDIEqKlG5KeciSWHM2WMtulQDhho64z9MWjAkoeAtEHDFJoj33aHT/7j4F5SwtetgW1/or3k0+t7vpM9Xl/G+2v1ZEaF8e/pCM0vpSZctyuiPtpH18+Vyx60gIzrsyjJfNc3NLWF4qUeodR0y03oFAmsoxELS1z3NdXWHIhXh/BN+IX2jnjgqr/+CkqWUCf6cRaVBSXd+L3kEsjum/tvCzwfvshlnSkUGlKvCv2K+EwValZGeop1fieN3l+ukRm4PZLst+cS9pR4eJbu7mPQsPgj6ReODnh3MtNfr3HB3SVEcZnpNkcw+Cr4H2mcC2at6rn2syqxHKHwNzzBDn2U2fLqTeNXFu4c1E9GUBJuKY2ZD32W4FbZybQAf75cAMmUUy0NFTgwTgwLwGl82exBI5zsHE3vQeeTaOVj2Y596/jXsRKiU4MI9yNtMVm/Anzu9FfOeJx+vjiZiflJKAOAr/Xr3/r2kHR/yEGJLyykvF+vO2HNM+b+RhBZS5ZOO4Ad2ZIggYxGzFc8AMlc0mfvHatHcAUSri6CFKt3V60sdfRBZOsybvKntLzWxnZq04c3bfVGMZUfAilTzj4awR5ZH87pG8zgbf16EWVLepCRFnPuKsfsCM2cHrRYCvNtvbukVx6P2WFAPHSOsvkyRnl9jwc+sqnB8pFFhqx19zKYfb+G0zDNUH9jlXPylwRUJsmlxXW6NfgMNcH+9rbPhckZpOYlI9V0UxHHi7PLUfwir39Vq7GR6TFg== X-MS-TrafficTypeDiagnostic: CO2PR05MB2502: X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2502; 25:h5VRAMBRj7+EkMx/GWJN6sR3AcuGheQMbTjywpFXaLDxOBHeMCRRaOQSCJqM7BxqwGGwxRwS6dLL8mKp1AP7hV/3H5e5tcQ7pOvXuSqQjU/EcT7kLjW24DvtN2vd3oCpnWoprokf2WU11UWeLOjGCRzY4jZ2j1t4rQ2HuXLbkmP03sLmAjeeXPboISzBWMQ3KGsqEMcbuoQscaCzVuIRBzwsN0IcAf6s7wap09w4n2JUUZlg3PbNO9EddrY8sQpMg780wfU918WHvgTF5yK/g1482Kf9pylZfWM3GnW2zR+g276ESJqlgPLsSTzci3s2Eys6M4Ph54OMf46bmBlBs1mcABY5Jn0nPJgWm66WFsbb6D3LH8Rkkv4CZ58TtM0yjA496c6l/gswrxDR6ZN63psaOR/GlU84CCQwdruHkY29hAaVcPWoL+BIUZXq06Bmxw/Lqb9BUj5j6VNNcz5hm2MwpyIGmUe1Bj07HH8OC53ClnvsbhRDYiDjCookmKI5UQ0FfAiFTRkqI+RSIG4akqGeYzxialHDqMnHAnnSNAFDhhp1O/BmxLaaePNkP1QY2oQwsm+O032csQKxC+qK2EKWNhdLF7NnJrALKnQDYE69zxqfMhCnfbhP3Kx9lDSxAivzsbptdEEI+At9Q9r6ELiL6QxSXzd75zyZO5rmxS2SwgqCWhgU2BaetwXlpNKiFGtk6SMAq19vXzT2nRQy+bm3+WD1zhTAF+pIdUUWd3HIu/75Bie/2XmNXMAEhGVeghCFWS30eg93VaGMfNuDP/Pl+hqYnqW7ABzWra8KkT3+mqNyEgj2Nqe/U/YpuLIatxFCmhcvGDgQMXkXcKUjBzxzvN7nSyLSaoO4p77gG6bXWXfC1dYqyoa8AWtdtmPhp13/ZaOaSGJwLT8V0ZoEqUSZicvJDCSwxUeBCauTKTs= X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2502; 31:Pzw/IVgsht9MHn4oQXMgU/tVfxoRbHRKW7VgTrpTl0RnX5rSY32z2m1vlKFKIaaGjga+dO8+gU/32IMtiNTJa4/4GOSHsWwVpt8bPxR6yyZ/zfaKI+/IcVqo/Em5z2zW0GEZxdI5UYH1z+7bRHlqNZOhecP3p/IZl4itq855cK4UB81XYNKUVHk8G40pa4YT2mswwbR1f+sruvp4JqTK0Vk/EKVXPZOwbod+D3FsJO+oYQsENinQtGFmysj/F+CvfgIaEIKRdsHRH6grmd6KmRfuCYkRmlZTBkC0gebAPzbScsvk64fadNwcpUAa2cX2ywhRyz7R2F3fvIWnKgvXITXfywx1C0taQyPDHNUcjRYfBCQeJGef9RaCA3kikZZ7jsXFtGLE9vtrgUiX7vaG+bj8jRTrdOyxpetFLWKcKdpIHnN8Tk8xYJC9qFPsRx2PROMh/pjxouapePZ63N2UBUrAN6c3zKLs2aE+UgATUrFpupf3UecsnT8me9D/pcMCb1lF3l3qDFE4bdu3cYmn1IQKsZhMPmQOR/C9gqAc3AjUDr1n6aL12Mhpkw1YrWAi2yOK18AVJbA2LoubPCM4XQeaxfLY1kWK/r11uVuDQdZ0decFcHnCNWPLm+SQTgJfAtEsRWBBiDo1K32T/b787hfNEotZqzAE0YH+k4ixzt3U2ZQuu+KPDVrBwC9IbysqND/lp3wGdnH4T13DudC38w== X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2502; 20:TLIUeM7JhmEpV2eMj3nFZK2hUiqqwXwC0BJE5vzAYwDleh74RqFM2WVsDI+DXRKig3dN0k/hrHiC3clWivgvT5X5zJUtN+b7RNtPJLUKt+DUATZVh3Pd9n2MctPKgxU8Mv+aNkU9qVKvhSuKL4y/rJtK+vsdPZx5/DqJLsW2zxGXQxxU4gnEcFhS23kcfJTT1zeqCX7TIxXnDBRDpepMWIhy+u7f1k8AmHsvTCfoJuEWPTnJULQFv5cYFkXvPQlW/spJGdPxQxqktATwlVJr4bKmpsou0ukNHyiNBmZ+AUS4zLQ3YvDonEuCXXzEu97l9l0Vl8EDgPNSiYegqfzT31WodXJ+0URToF/y2erPxV4lj/PUeKAEAzfAflJ01oXT/X91XOn9oReSrtiZVUPiEYoMZoNgGWsMs5XsxCX5aPdz5UVtVcBr789m19IRDEIVW0XGl9L1NpReE1ueveIAS0M/Vp6DoOjwaFEiCbIq8E3pgkZUs+9D2v1JQkMKe6pg X-Exchange-Antispam-Report-Test: UriScan:(236129657087228)(247924648384137); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(2017060910075)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CO2PR05MB2502; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CO2PR05MB2502; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO2PR05MB2502; 4:bV82Wue+JrkBO74Eh9x2UKhWvoULbYR/vh8kDU/Soz?= =?us-ascii?Q?HH6jFCYSfj+S1j2mN3EiLXJj3TgyUWi6mtlKM6vS3NqZk1gVGZkWDzRTVUef?= =?us-ascii?Q?Y73XsM+m94BSiJvAsEQpTGPQGLp0PLb+nGFnXMl1eFMjxoahK+abDQgSUImD?= =?us-ascii?Q?tg4iuZqIfhVT3k8Pi7yl0qUL8+PsFF+aZmwbTeyg5sSSJxzXDAsqGhCLXLpy?= =?us-ascii?Q?Nn/DhfvD1zyvkVbLAs7wkWmz8dO2t3w5gWQG9brGu7Sck3UWHElcOFrxprAd?= =?us-ascii?Q?SWMwHRbBOPgrxTLK+q7jlwh0odxCCqRUBXZCtK/ahG2oAyItJ3KqwEgWYV6U?= =?us-ascii?Q?3cuJuVOIFpeL/sAq+MQkU4aZFcfWepcTqznJ8MSC+BmRBRn1jWtE5YeY6PRG?= =?us-ascii?Q?NTc5uERtg9GCzGRWYhYEFnz+6Dk35niz8RQj3g+/pwW9AuWaO3kMViW3gEMf?= =?us-ascii?Q?N0gyMkd3VWAdU4bx3wQ5xQrjvW2KfadwaQ/nAotdg/oznxDf4GFtC7vB5ifc?= =?us-ascii?Q?2i+eWsY2o6qGynPJhcT/sOy16tgZy2zl4TtAUvTm5ctz/VZerOTghPcdDRzl?= =?us-ascii?Q?4q7dKDeYoOxN2WPTyNSQUZWnl1kr6mDkgpqnp+keZURWbd/fie66333dqNof?= =?us-ascii?Q?d5PC+xC5tT0o9XpzuPtzQwSPRb0eJ+vP9P7tY0h+BGMDZTCvXxDCevof8wzh?= =?us-ascii?Q?+l8yxs7+8UBEHgfOrJQrOebnB5i4KYWQ9B0Gv/eXHDLFa9VgqoMyrcN6rO2r?= =?us-ascii?Q?HeTRfQUaVIcGET7uhzBrjZ+Z3Y6S/Zse7W5D410kuHC+T08MIsE6VNGTTmbI?= =?us-ascii?Q?cUzhLj9duVH9M8a823W9I786sSnZwCfK9bs5XZCCR9uxRmyaf91LzjGcC1up?= =?us-ascii?Q?tzTEcHz4LXtvonSoWfhrst4tiAGIWnJJBYPTO9CyYvb9gzis5w3fQ/OTAFjY?= =?us-ascii?Q?6jylDLnp78ELX7/77ORVSQ9tyhbGFwzW5aW85dFeXO48m8ygVB8PauHRc9hY?= =?us-ascii?Q?h9ZW8jaiPuJxUl/gckJfud+W5G4RN06hx6fK6wWhU3C6DWLrPKSMm51ZYJMO?= =?us-ascii?Q?kTmPWFBPxwg6PhS+8/mmPEVviOfmDYum56ufZqm23QnjYYB0/L8BdDPZsReN?= =?us-ascii?Q?XNUmtPU4wDUQjNfQlt70kdrTliQ+qYSth/scKg9fWJrH91HqqWNT5zYCu3sb?= =?us-ascii?Q?LbWmosAKZ3BD6hj1ZmHAUVGc1z2sD9i2x0x3sz9onTE7ef2g30XUfggQ7RaJ?= =?us-ascii?Q?Xbh4V4kC3qfwUff29w77IAnSDZyrWCyzJYzOzG?= X-Forefront-PRVS: 0369E8196C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(7370300001)(6009001)(6049001)(39400400002)(39860400002)(39840400002)(39450400003)(39850400002)(39410400002)(53754006)(66066001)(110136004)(38730400002)(2351001)(2361001)(42186005)(4326008)(189998001)(77096006)(36756003)(83716003)(7350300001)(53936002)(966005)(50986999)(82746002)(7736002)(6486002)(6916009)(33656002)(81166006)(8676002)(6666003)(86362001)(3846002)(6116002)(57306001)(47776003)(50466002)(6306002)(25786009)(90366009)(478600001)(50226002)(2906002)(5660300001)(305945005)(8746002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2502; H:[172.29.66.35]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO2PR05MB2502; 23:CWlLnMCS08kjrNS2HZatVZ2aKFWR6gs4swVRTMyxv?= =?us-ascii?Q?b7ZA3Umk4/oG+P6M9b9brG3ehm4ST1yOhTAoYQnKBavitQxksIfAKG0FdHd5?= =?us-ascii?Q?Rods28ahEc7MBlZU3WKs5EkDIdrmHQRQtnoX3dCG+ytBa50mreqDNmHWe7H0?= =?us-ascii?Q?cUHi6s+/xw6bdj1O/xmczjzqTYfmzpXnkPaMcbrbmNRZL8HF84vPz04BCOxd?= =?us-ascii?Q?0zgQCA+ID4ResvUdJSSGzTKyghLeDugdxQWfFY8Yt0VfOsNg4w6xUy+hetp/?= =?us-ascii?Q?LMxijEUN1BI9FM6ILNm4cAJaGC52O/p1gePv4UaH1BlDl5RkwQu1apkgLgrq?= =?us-ascii?Q?YWfN96qyGV6cWApelw4xqANiC+F/dwUZJjyyCNp73n1m5S9bG2VOP4lbEdBV?= =?us-ascii?Q?oy5ita5NANuh/ErXszbc1gWpfdNq7sy/yiOVWSn40I3NfXIZ5tYebdjT4YKa?= =?us-ascii?Q?ebyI+5oqgbt8fXZqcF4jxL+7N5n1bqr4vO4I9+3Ljgd0tbBJ8HjXKLCK2KtL?= =?us-ascii?Q?N2diOO70sc4oHWg+vuyohFShiLvraOUq5C9BgRraKUuN2h5O8s1CGp/bOiJb?= =?us-ascii?Q?l/tbTly80OXAKZQQQd3iVoUHS02Wa1EY6tdmclAOimx7vqC4PXQTqlbwu3Hi?= =?us-ascii?Q?2dayGrjxAIfSg1P5lkBX2zleuUjd03nVAR0/7Ju7kTiRhYT8tGfZk8oWi7PA?= =?us-ascii?Q?4ZV2k1HkYqu2lnnES+359h2NnYa1y65Ag0sdCzb9mD+OaW5/ShZvj9W9luNc?= =?us-ascii?Q?6wT3TO3JJRivVWDCPRFrzYdakcUxmgIg+P0gqZDJV8VPNKjVWDVE35+lNr91?= =?us-ascii?Q?QNNfbdzyWrj8YAqb1TCCoU/ZLIC3uCkwaclrZTBvPhgFUo1i2K//UXRlXeWa?= =?us-ascii?Q?c8QslFx1ZLp0ByB/3afMMuFc4HULMOQ7p6L+08/7mG37JLMoQVw41iQaQQt3?= =?us-ascii?Q?MJI6M6L1201pyzCCdPuAaBpSSY/X6jXTkBK7F+xWYlfOq9d+pnUn+o9D7g/X?= =?us-ascii?Q?63Cwit/Aa1M45s8AMZ9JcygXdN8P+lB4vqQ9IsrjjjLPSiN85jCD9JbK8LKC?= =?us-ascii?Q?Z9mNGoIYYMDYAbTbZ7kwZk0o3AFBJjnv03QDoOwA32ZVGgjCAqXyoNlJ1cCc?= =?us-ascii?Q?knd9cbTYdNPx4lM0NiiHvUILnVYo9Qu8fab40n3J8xzSDYhbI3ABX2fK7to3?= =?us-ascii?Q?htBRDWi3RNUNRqY3bcsStlFrMyL6re1l1sSgioz2Bw+mbAwUZKF+TQR4w=3D?= =?us-ascii?Q?=3D?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO2PR05MB2502; 6:veXOEstN2qNSoUKAg4HI6JgI2j4O78nDiLLFTrG/u2?= =?us-ascii?Q?xExWH6MYT0fvQf0T5i4UE8lpvNJVyAqqKA6u0auyRgD9RAs7PFyPThvdJ+p7?= =?us-ascii?Q?r/7t77KhXUYAvl+dTa8sqO6un7GS+HCRZDa5q84T9iJDqaYBOtcM5v7HgjQ9?= =?us-ascii?Q?k1C/JSNOF+fxtRfid059016UgOZpKrWc3aZypL1XX6C69JYtfZTPlkJMrm4E?= =?us-ascii?Q?93hT0+dgARUztme3PsKJp+TvZLpFPtZ5K71RAV15RWFB8Egghz5wJsQfkScc?= =?us-ascii?Q?KaQqCOcJXgUWHoKQ88xbLmJPP41trKR4eImVxFZFmvXXtbm0Z+iGvxEPsLnG?= =?us-ascii?Q?JFfbX7bUKmaZn81Mv7bPUOcjJYI8S+tE1NwvyrIybvlqncktRN1uszwqRH+S?= =?us-ascii?Q?e+3eZ5xs0gpyowHk1B3/cG0U93pEO6QxTGjMNR/QHfdm1076dgK0qmURT/iQ?= =?us-ascii?Q?ZIIi5bdHPVMm1NhnKykio/1Uk5Ev33Oed+qmFvyFoCYAfPiI5lOvTNLQIvS2?= =?us-ascii?Q?nJ7Ll/uw8dc2kJgPZzccUdHixJWUVeQdqL/5wAB0NlDrMcktCAVit7dJ53ng?= =?us-ascii?Q?iwl39Ev9b0hAXY7rKa17Tv5MVWvbCyyiV+bP00WapFhekBggus5a6RLVyzhe?= =?us-ascii?Q?Y61Tw5LVaQvOsV+oFlH2e0GiVTyC74nqMgIWQtceJp/VnVuZnb4j/ZikcR8j?= =?us-ascii?Q?LKEDA0OMcnlHuS8csjnl7eZiBIA4EoFpgptb1kLI0sX7aF+WTGyPy3YpM9a6?= =?us-ascii?Q?y1XCA9MsD9wCl7QnFyAmNZH3o7bHH/jeSyxze69WtqikTgSIAuVBDmx7SVU/?= =?us-ascii?Q?Fkg8+cv3vOJKcuZu6I6n5PSbt5GYiue9orSW8sw2YJWU0YCBR3Fc3drv1q3i?= =?us-ascii?Q?gUzCNpIEG1iTo76gd4kuIR5NG3B+pg06nZIwQKvzit/4kYs8pCJ/8ODjTNsC?= =?us-ascii?Q?MR6o4jOUBRju3Um+8L156INQY1818Hyl8wbvist2Wut2c/31OmSgvkfElgqc?= =?us-ascii?Q?A6DR995Rn+MdeBBvwXJKAp?= X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2502; 5:7TowLRDtIA2UbWcXnxJ6+v+eUT+FsP60oAqah1MYvMv/f2cQMrO8OzhluZsiqJPHdXGu4fSSuP3PxarVoQgXEzTMhQldcZGHeSRlJN090dZW5L4ZWvQEcuIaNNmmVXl6IXxRJ4MUFu3whqWNsxXiPjOtG2bDsPHcMj0ZVzNFCBDqFqJm1WqAWEeyz7noSuVOe4G61Ua9ayA/gM4g/oHe/+9v8SRF0EoN40N+RmaK8zyCBn2qQNqwWcH0aJHpvMHA3Aq/SFl5Oh4iWEIDIMLrlyCesYYBst+IXiF/Eq5Vxc7Mi9D/6O88nM4TEZ3Su3MJGp0TLmISuUpXhdjYjyEOD5gu2BkUZGrIKjqfc2muF69im0p3LtF2+KPHp/VOqzR/m4Y4HQ9ZuyfOUx3uGjsMcvoc7Rgi0TEyNoNHU36rfsblb1fL2ykzffJW/SYwAgAKDMaVdslQm74KjHEm7mzyXSfj8DOrspqY+EX7mYbUJwpKjQbURmCTLcUwRRMFn1tZ; 24:BKC7EEJtrf7Hj0TARCBaiuHvGAvM0vrFkGTunWC+LU4hm/2hLkNk9DJt7PgbjMvmMTgtnUVwrQSlxKqaGFA2m2a6/YjQAsit6853cyxor0g= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2502; 7:CUuxd6pIBzVZ1HPQti2O0tfynvD7lsUpGS2OBEd4WMJjkcpneDN+WVSEqze2RUma3jH0gHgCQsTcOuBIPtjHcr727SWzpHxSq/Qnl8pEljA6yI5+GISVPkWGetGPNbcAjRoWIsnupDEt7Dfr4TLTR0eqekjkUWWFFKDrdfTvqvZiVLKTfDAcQolAPM/46rUO49sqRu5bI7m0Os0CG7lkv4vVhlRu5dSlnXSrb8EOT+PSNWb2exxNkJNXZkY3FUE5kuoQafJLE2Vwuk8jL6dtI4ALrDN/o4IEvqKqmSPL5Myr7gUzj4VoMrJfTRQ/NQ+vWozM5ndgGyRT7famELirpjyqewcS+piS1oNeJ/VeqLLwkYY0vYbxV8U68L0S4a4PXaQp4QVlynvYY+qZnlJ0xjICd9B0wzzR/irqy7pyHYtF/jdsPIRmphYrYAKtaCeqflNJD4aoZwWWMHAuKtcwnFtrfZsXPhhQncxmNdIB/S/CcyzUuj+ez8+q/9lUdM+EE374VgUnwUFYwg3o4dI6nWTqDZAC6LALPUP2R7X00aooraeQlx8AooETvn1s2fiEo+N4wJoo/KcEW0igxGSKIGNNrVuAdSsmzfdmiD7Pu3RFGy7oH7wIBZzfCt6fL32vEnolA70wRW0zNzLvd+HSIKWyR4n1WQLbhrCGL2IAh2F2bt6at42viYn4dWL/13jJQZ4jvBK0ep5aptGgot3LQVdQjZbNZ1OYWZc1UOf4j7ywsNrr1A1o82Biu6whxZuzA6vNgyAoIWIiMMwXC2sWg6+vVCovZaKDQn6EhT09yuA= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jul 2017 15:41:57.4931 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2502 Archived-At: Subject: [Idr] allocation policy for BGP-LS registries X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 15:42:02 -0000 Hi All, You may have noticed that I just sent out a few emails scolding authors = for squatting on code points in the "BGP-LS Node Descriptor, Link = Descriptor, Prefix Descriptor, and Attribute TLVs" registry. This is one = of the things I least enjoy doing. I notice that all of the BGP-LS registries have the "Specification = Required" policy. Experience shows this tends to invite such behavior. I = further notice that three of these registries are for 16-bit spaces = (BGP-LS Protocol-IDs is an 8-bit space). I'd like to invite discussion about whether the WG thinks we should = convert the three 16-bit registries to First Come First Served (FCFS).=20= For those unfamiliar with the respective allocation policies, all the = gory details are in RFC 5226, but for our purposes "Specification = Required" is almost the same as requiring an RFC in order for the code = point to be issued. By contrast, FCFS allows anyone to get a code point = at any time with minimum effort. While there are some drawbacks to FCFS, = the major advantage is that there is minimum impediment to coordinating = implementations in an organized and disciplined way. Hannes and Adrian in the cc because they're the "designated experts" on = those registries. If the WG wants to make this change, someone would need to write a draft = to do so. Such drafts can be very short, see for example = https://tools.ietf.org/html/rfc7803 (this is just the first one I came = across). It would be great to see someone volunteer for this work. = (Perhaps someone who has been eager to take the shortcut of "suggesting" = code points, hint hint?) Thanks, --John= From nobody Sat Jul 15 10:12:06 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A31F2127078 for ; Sat, 15 Jul 2017 10:12:05 -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 C-bEAlkDV62v for ; Sat, 15 Jul 2017 10:12:04 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2FBC1200ED for ; Sat, 15 Jul 2017 10:12:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3174; q=dns/txt; s=iport; t=1500138723; x=1501348323; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=lZXU6y8yChQE7AQdw3Jy9GZl4fWOpUtPGqFWrvTC9Sw=; b=G4FURFUr4oap+LzEFFe6eA0bf4BjaA2VlIpMexGK6tDlsKi5lMOASqOr 0Ja0ot1EkkhuZcA4bWZk0bkAO0+7VHMq9MmEywFu4Wvv2273qoUTJF974 lxZi1S72rtSGpyBZagbvaRveB/HeYueP2pqg4qwNiYEgcABC85iV7eUc0 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYAACDS2pZ/49dJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkgRQHjgSnY4IRIQuFGwIag1c/GAECAQEBAQEBAWsohRkCAQM?= =?us-ascii?q?BASERNwMLEAIBCBoCJgICAiULFRACBAENBYovEK1egiaLFQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBARgFgQuCHYUugySEOjCDE4JhBZ80AodIg0qDR4U7giWQCpVWAR8?= =?us-ascii?q?4gQp1FUmHFnaHZ4ENAQEB?= X-IronPort-AV: E=Sophos;i="5.40,364,1496102400"; d="scan'208";a="451032909" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jul 2017 17:12:02 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v6FHC2Wq021592 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 15 Jul 2017 17:12:02 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; Sat, 15 Jul 2017 13:12:01 -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; Sat, 15 Jul 2017 13:12:01 -0400 From: "Acee Lindem (acee)" To: "John G. Scudder" , "idr@ietf.org" CC: "hannes@rtbrick.com" Thread-Topic: [Idr] allocation policy for BGP-LS registries Thread-Index: AQHS/YFrqC2/VhdJZUaDQQ+Ucs1BUqJVH+sA Date: Sat, 15 Jul 2017 17:12:01 +0000 Message-ID: References: <5436099D-D57A-4D29-A744-0E8A3572845F@juniper.net> In-Reply-To: <5436099D-D57A-4D29-A744-0E8A3572845F@juniper.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="utf-8" Content-ID: <920F52D057E9CC48B737F70172936EA3@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] allocation policy for BGP-LS registries X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 17:12:06 -0000 SGkgSm9obiwgZXQgYWwsIA0KDQpJIHRoaW5rIHdlIGhhdmUgY29udHJhZGljdGluZyBnb2FscyBo ZXJlIG9mIGVuY291cmFnaW5nIGltcGxlbWVudGF0aW9ucw0KYW5kIGRpc2NvdXJhZ2luZyBzdWdn ZXN0aW9uIG9mIElBTkEgY29kZSBwb2ludHMuIEkgd291bGQgcHJvcG9zZSB0aGF0IHdlDQrigJxs b3dlciB0aGUgYmFy4oCdIGZvciBlYXJseSBhbGxvY2F0aW9uIGFuZCBhbGxvdyBpdCBhcyBzb29u IGFzIGEgZG9jdW1lbnQgaXMNCmFjY2VwdGVkIGJ5IHRoZSBXRy4gQWxzbywgSSB3b3VsZCByZW1v dmUgdGhlIEFEIGZyb20gb2JzdHJ1Y3RpbmcgdGhlDQphbGxvY2F0aW9uIGJ1dCByZWFsaXplIHRo aXMgbWF5IGJlIGEgY29udHJvdmVyc2lhbCBvcGluaW9uLg0KDQpUaGFua3MsDQpBY2VlIA0KDQpP biA3LzE1LzE3LCAxMTo0MSBBTSwgIklkciBvbiBiZWhhbGYgb2YgSm9obiBHLiBTY3VkZGVyIg0K PGlkci1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBqZ3NAanVuaXBlci5uZXQ+IHdyb3Rl Og0KDQo+SGkgQWxsLA0KPg0KPllvdSBtYXkgaGF2ZSBub3RpY2VkIHRoYXQgSSBqdXN0IHNlbnQg b3V0IGEgZmV3IGVtYWlscyBzY29sZGluZyBhdXRob3JzDQo+Zm9yIHNxdWF0dGluZyBvbiBjb2Rl IHBvaW50cyBpbiB0aGUgIkJHUC1MUyBOb2RlIERlc2NyaXB0b3IsIExpbmsNCj5EZXNjcmlwdG9y LCBQcmVmaXggRGVzY3JpcHRvciwgYW5kIEF0dHJpYnV0ZSBUTFZzIiByZWdpc3RyeS4gVGhpcyBp cyBvbmUNCj5vZiB0aGUgdGhpbmdzIEkgbGVhc3QgZW5qb3kgZG9pbmcuDQo+DQo+SSBub3RpY2Ug dGhhdCBhbGwgb2YgdGhlIEJHUC1MUyByZWdpc3RyaWVzIGhhdmUgdGhlICJTcGVjaWZpY2F0aW9u DQo+UmVxdWlyZWQiIHBvbGljeS4gRXhwZXJpZW5jZSBzaG93cyB0aGlzIHRlbmRzIHRvIGludml0 ZSBzdWNoIGJlaGF2aW9yLiBJDQo+ZnVydGhlciBub3RpY2UgdGhhdCB0aHJlZSBvZiB0aGVzZSBy ZWdpc3RyaWVzIGFyZSBmb3IgMTYtYml0IHNwYWNlcw0KPihCR1AtTFMgUHJvdG9jb2wtSURzIGlz IGFuIDgtYml0IHNwYWNlKS4NCj4NCj5JJ2QgbGlrZSB0byBpbnZpdGUgZGlzY3Vzc2lvbiBhYm91 dCB3aGV0aGVyIHRoZSBXRyB0aGlua3Mgd2Ugc2hvdWxkDQo+Y29udmVydCB0aGUgdGhyZWUgMTYt Yml0IHJlZ2lzdHJpZXMgdG8gRmlyc3QgQ29tZSBGaXJzdCBTZXJ2ZWQgKEZDRlMpLg0KPg0KPkZv ciB0aG9zZSB1bmZhbWlsaWFyIHdpdGggdGhlIHJlc3BlY3RpdmUgYWxsb2NhdGlvbiBwb2xpY2ll cywgYWxsIHRoZQ0KPmdvcnkgZGV0YWlscyBhcmUgaW4gUkZDIDUyMjYsIGJ1dCBmb3Igb3VyIHB1 cnBvc2VzICJTcGVjaWZpY2F0aW9uDQo+UmVxdWlyZWQiIGlzIGFsbW9zdCB0aGUgc2FtZSBhcyBy ZXF1aXJpbmcgYW4gUkZDIGluIG9yZGVyIGZvciB0aGUgY29kZQ0KPnBvaW50IHRvIGJlIGlzc3Vl ZC4gQnkgY29udHJhc3QsIEZDRlMgYWxsb3dzIGFueW9uZSB0byBnZXQgYSBjb2RlIHBvaW50DQo+ YXQgYW55IHRpbWUgd2l0aCBtaW5pbXVtIGVmZm9ydC4gV2hpbGUgdGhlcmUgYXJlIHNvbWUgZHJh d2JhY2tzIHRvIEZDRlMsDQo+dGhlIG1ham9yIGFkdmFudGFnZSBpcyB0aGF0IHRoZXJlIGlzIG1p bmltdW0gaW1wZWRpbWVudCB0byBjb29yZGluYXRpbmcNCj5pbXBsZW1lbnRhdGlvbnMgaW4gYW4g b3JnYW5pemVkIGFuZCBkaXNjaXBsaW5lZCB3YXkuDQo+DQo+SGFubmVzIGFuZCBBZHJpYW4gaW4g dGhlIGNjIGJlY2F1c2UgdGhleSdyZSB0aGUgImRlc2lnbmF0ZWQgZXhwZXJ0cyIgb24NCj50aG9z ZSByZWdpc3RyaWVzLg0KPg0KPklmIHRoZSBXRyB3YW50cyB0byBtYWtlIHRoaXMgY2hhbmdlLCBz b21lb25lIHdvdWxkIG5lZWQgdG8gd3JpdGUgYSBkcmFmdA0KPnRvIGRvIHNvLiBTdWNoIGRyYWZ0 cyBjYW4gYmUgdmVyeSBzaG9ydCwgc2VlIGZvciBleGFtcGxlDQo+aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL3JmYzc4MDMgKHRoaXMgaXMganVzdCB0aGUgZmlyc3Qgb25lIEkgY2FtZQ0KPmFj cm9zcykuIEl0IHdvdWxkIGJlIGdyZWF0IHRvIHNlZSBzb21lb25lIHZvbHVudGVlciBmb3IgdGhp cyB3b3JrLg0KPihQZXJoYXBzIHNvbWVvbmUgd2hvIGhhcyBiZWVuIGVhZ2VyIHRvIHRha2UgdGhl IHNob3J0Y3V0IG9mICJzdWdnZXN0aW5nIg0KPmNvZGUgcG9pbnRzLCBoaW50IGhpbnQ/KQ0KPg0K PlRoYW5rcywNCj4NCj4tLUpvaG4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPklkciBtYWlsaW5nIGxpc3QNCj5JZHJAaWV0Zi5vcmcNCj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0KDQo= From nobody Sat Jul 15 11:16:04 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1DA126C7A for ; Sat, 15 Jul 2017 11:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-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=juniper.net 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 Beytn51TUylo for ; Sat, 15 Jul 2017 11:16:01 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0121.outbound.protection.outlook.com [104.47.36.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67A311241FC for ; Sat, 15 Jul 2017 11:16:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ymzo70bWM5WFWt0VGti0yIb0L8iZNG5v77Utuoi2tFI=; b=HFAZUGnmnDeQaFMB9Ozv350fjTrMJwxeHdeoomDqRU+vVn5RbZdM/Klr876mmuBxJVwUAIkJ238V0SBCEGmUDulAn8nRxi65wcCif8Co8SAeE5GlMcQ8qwFyHhRo4iccEs2JDEfJ7Qxin4MB2IR0UJefWI9cQI6ZLkJPOE+O7TI= Authentication-Results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; Received: from [172.29.66.35] (193.110.55.12) by CO2PR05MB2501.namprd05.prod.outlook.com (10.166.95.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Sat, 15 Jul 2017 18:15:58 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: Date: Sat, 15 Jul 2017 21:15:46 +0300 Cc: "idr@ietf.org" , "hannes@rtbrick.com" , adrian@olddog.co.uk Content-Transfer-Encoding: quoted-printable Message-Id: <180D7A03-AFBE-4F42-9885-D229897131EA@juniper.net> References: <5436099D-D57A-4D29-A744-0E8A3572845F@juniper.net> To: "Acee Lindem (acee)" X-Mailer: Apple Mail (2.3124) X-Originating-IP: [193.110.55.12] X-ClientProxiedBy: DB6PR07CA0201.eurprd07.prod.outlook.com (10.166.153.31) To CO2PR05MB2501.namprd05.prod.outlook.com (10.166.95.147) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 3db1fd9f-8911-4417-eee4-08d4cbad8ba1 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(48565401081)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CO2PR05MB2501; X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2501; 3:BrPIPpHiC8V2YJazCsSh0qBaH/L3aXOK3jF9TvloElihUN5q8QqYlR/hZlGZsFxpn0FHlNkzqWCznHpj2eqUUehPCKsqniVopSu9KXwTems114yXD5CSTmV66SYB6jK54zSXb1EFHxoof2MTtT4NjP9PAY1hJ6sAhXh6XVAqLh9OAhSgLn7lIL7bCT9GtPEZLqLMRdnVvJZrKB2rTCbhZrAN/+haug3csvFx/Mf3Q/d6wcRe0fOXCpUofATGtsfwv1llo8c54qlFpVESNLjD2UoQnaieiacNb5Y4SLmscqpi/F1Ou/5MmLKAmd7RDbalQFNaeos451G62GmKYM7l8+yuCnWk/04NKaBcDiFflUmetUXLAWfA9hm9L6y15/cKp808NYlFfVSBVG1+N6u/FqUqWEJtZ/vCE15K0ruK2AfIgg1kTCGGu95Iw4KsbWqjJ2qVytUGgqxvNqRlhq9zNtxUss6oTl59kAL/KAXI4EWtlWpLC6Gx3Xme4zrVaC9EYJJmdmCY5bHCGs6OFGoP5gDR8k3HqfvpkE8iS/8KlyEYfkW/Hza9V4C6rNlwUyYItkT/ftzpglAh9gVKXHri4xkxVjcvWCgBJ10/mvtBW/zorc5LLZKsR2unN/BEzPXWp2cofYDrLmbZ3y/BBXgWcCqPPQQgaC4ucx5PZer3Z0bsbMSXiFN2ddy1/qJ182WYTOIeXUBggSWNLgwbOX6KK8r1ud0vW3Vns6LedAZr4qszgoW1MYtXM6kkCaFyxIWzP1tDY+MSKIRyRpizTRRsxQ== X-MS-TrafficTypeDiagnostic: CO2PR05MB2501: X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2501; 25:MUEy2ATywuyJ7nE+p81RupnbLvlxaLrC3NRiJF5Q6kIFVduyyrNu344WpvuBrbF2g90gfyojqDqua6MByO/1YB7G5D2wW06zZAQ5D5Y3hRumHZMivwgk+lk57cAtiqBcfekLseFrE9GNRVYQdeDUtopRWsmiXN8vNN/urNh+XFDZe5NnYE2WG9mq4fXoMbt+V/l0i+CnblTwx3cc2HiCk26Q4qtoeGbYbILeNj2FehNybmPY2LaUw58Pa/nh/SsuRKRij6kUPXoEGFOZpKIkDsDQGdCpPwYLLNF3k8BdhzhuANXhkUWNNDrAszrAi6jrjvQEr1/Q10BzwpXd5okDJARkH62HGYsClqtUU+9JQFPIC4dkjyPkltabiwKTVGj0tFXU2BscPSXVELWVd609ffd16LkfLHHa+Onq+S7Bn7r3soRYdlpf8lq4MlhJxOJFTMdCKlTs6lZd+vtppbclFV80n7cEKujp21o3yPJDesxbBRY5mqnvK+D/pHhdsZcStCZ/QDiDujScKWKwRzEZ+/JRRDt7hbkOaloGNHM0Jy1i8406ygTLRiYWCYyoetIBNgk+n/+k8od2g0BaBNuKMehm4FQ3ll9ik46QSdPCws4+emELnvTY+6+Fzw25tOxYjRrncCA9Lg+CyHrSRjZsYZ5eTgdO6xwy0Sb1XUDUVC3+AQCbQM+cERHsRuoYadtNpvVHqkVfhuXFI6kPbqlLMg/YTi/cte0Q9HjFYu0kwID2sgLkAYgD/siS7JR9miBoW564WCkvLzPAoYxhcgx6kycibqpyD9sw8DHVTcs9BeluOblP3iPpazkd1wK/V4RDR2vCCjMol3MRRcmBeUTo67HKvAMYr+pGyDcpQ03ANsqcPr4ln3airydGCQV8Cr1Y+NIMD3/BN7N8QsfiZk8wbhC/nasRIIvKZTDCk0XmiJM= X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2501; 31:89UUn/VQeNx5jv5HqDBxeArJhll+zEfDsse6bAGDXb8EH8vZuJpx61iVcOfQK6p6vkcuua8m8Ae3nw2EjzZYOYRNyWVrLIKC23dj2Lj6UJu3no0SpYqbzubheasK8AX3FASEKMXQ/aFvIAJio2DGJ87TbVc1PZp0CBvbJSK26C+7FQ8eM3BVaTvr4gFwji/wFMZD76fY8xfYRXcsZelpI5bTO2hnpP5AUbdRS3VXGUQhYYV3KQws6XBYBYXBiFaWgGevjnk6cH2v0dqdR2kN1O5fVAOLwvuUGUI3q4ZM2dBj8BUPvYZWJ4zLtwxHjyLjMIdr+syCCx+LlvUgfN/56oyV1dCb2eQLf9c2a7oRoujmQAu7+TKqewoU6LdnPSr1Q5WZ45RNjhjQYEoL90hBH9fF0PXUiYNo1B55f36Zj1pYtWTdQDOZROcO1fswlG5owqJzuAO2dN9dMCcCJ7aBsa3/lBIFK9elEKYzT0hVNRIuApPJXj6EytTsx3ZBriabwBirGJASynOi6MHZto7H2X4I///NVDRYKso7Yi41DJNhvi7K6PIKPjc6Y2Vn+bradT/5usCjTRt0oABdPdLHBi/SFKyF3ePOCH6ZR1RewXwiRTNg1DzZnBdyUuy/8zrP+oNPE33RKP7HtSAWB3EYJytiEAjpiTyk72sXB2nQohbTnPLRJR8bUOVyFV5Er7l5gUnjqGZB2eThhpsy2z59NQ== X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2501; 20:mebI5i4uY4htpmDujc3zTMANpO1mxju1ek8HMsPDQKWoPTpYP0r4zevC855+tvgLKqDcZgSYgD+SA2O3it9w0udNy6L3pmWzs4xbsq0gMTGB7B7r6lrbDXoizLapBXLqk3qncvDRy+0o8aHRqHGFxnP9iAqvZmlw4hBB9mKsctOEcPt1lrkshPvBPK4q1p6vtSDWmK8Y+X77kiU890Yz5AiBcFC7djNA+yq9Ukx9Q5TvumpUhZuAlIf5JMdj3/Cz6ZlCS9FkPTCQpF8lE4q4gkf2PQMsbg0ac0e4J/VfGVg2cXtTCxIt+1SGfQl7s+JMkP3J36r8ftQq2MNVOsq3dgfU5Q3hoTRUHojZn5sVLZWFrLWg3apIaO6E3EKeMY5muUQScnqtjoS4qrnK+93ARdEJRowaw9xTy25VWrooIQjzomDS2rFVVgt3d0/fo05URg3JVQlHPx1Tyq7cSX3BoeXCMk0x0QvDeKpb/zxclzM5MwWxgKso/CCkqGqKjt4y X-Exchange-Antispam-Report-Test: UriScan:(278178393323532)(236129657087228)(95692535739014); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(2017060910075)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CO2PR05MB2501; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CO2PR05MB2501; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDTzJQUjA1TUIyNTAxOzQ6YldXcFlhUVFOT2ZUZjh2dldQay9Za21QakJ2?= =?utf-8?B?MDhyRzF6QXVHRk90QW5TUjlCemtQbjdtcEt3NUJWNHRiRjZzekpDdjBEVHMw?= =?utf-8?B?K3ZQSDRyOHZRWklWK3JDeTN2dUJXRGt4Yzl1Q0J2QUp0WEwrWFBsVG94aHhj?= =?utf-8?B?VXZPbWcrSTNOOUhDTTUyZ09Rb0ZEVU9hMXQ1QlJsNnFjMnN0ckpRSk1lR1Vz?= =?utf-8?B?UExWcWZxdkpYVUwvOGEySm95QUNDd2hLNlBiR3A4UDRPR2QxL09uaTZTc3Bi?= =?utf-8?B?eU9EakRRRURXdEI5VTgzaCtRanRwM01weFVuT0RQRys0Y3FZdDRBN1RzZy9t?= =?utf-8?B?VExyS1NwcjR0b3VtZ3YyZVNQTmpBcW9zOEMxdTJIU21icG5rekNRVktHckVR?= =?utf-8?B?dThSK1B0bnVOMVVVUXBRVkhBSFNVS0N5c1BnL2JZTndDSmF5ZHp0ZERtTmE3?= =?utf-8?B?RFlxQlhsY3hWR1ZDbyt2WFVPWEZrcHpubFlVcU9mbVA4QmRsd0c5TFF5SENY?= =?utf-8?B?VU1KZ3VYcm9PbUhDM2pVc1FMd3BDcWFqTkxnM3hpaWhzcTFybU1DNXlTYkw1?= =?utf-8?B?R0RCS3J1OUNZWkdqak1EOXFsRThPK2xNVzdSMXc5c0xVVmVTME5WS0FkSnpI?= =?utf-8?B?L2VESnNQbmZOVXR6b3QzL3hhUHhoUVlnbEkxVk9pTFFUeFR2MEVWVnpZL2VB?= =?utf-8?B?MGdydDl1UU9mYVB5aVZ1OXp1K3J6cGxHQmoxMUVhVS9CZHhINlhrMmpPUlpo?= =?utf-8?B?QWJXdGRSSHlxUDB0eVllV2VKdlVXa1c5elVjeWNNVldFanFtNytSYlYzMXUw?= =?utf-8?B?cVVPQXZIKzlVa0tueVc5T3hPK2F3YWlURXh4VTZPTEIvTlpGTmNuNDFRZGNE?= =?utf-8?B?WTI4bnk2U3BVZnNGaUZDRTRSei9nYWdSRXgxOTk0R3ZnUExEaWlwRTFBT0RR?= =?utf-8?B?WDdqbTFjN3ZhSStpajlYWWNDMktLSmphdGg1VVc4Wmt6dW9QSnNwdE1JR0VL?= =?utf-8?B?WTJSLy9QZU9yRGdEY0J2aS9HbldCYS9HN2xjU1JRR3F2d0VXbXJsSGxFNUh2?= =?utf-8?B?V2tuMEN6cU5tNFRyZ2dLcE5kNy80UUpBN0RtU0NpZkYya24rNkIxVVVONGFL?= =?utf-8?B?ZFUwaXNwMHl2L3ZRNXQySjhuUkRGdC9nUnpiUFFxZWduMXpZT0NrTWZnSnow?= =?utf-8?B?d2NldGk2akRDQ0F6OFNNalMwTnRaN1VDWXJiQnpxemlsRWxYN21pS1pIN21k?= =?utf-8?B?c3pib2p3cGlSS05BZ3VzVkcxOUVEUzJ4TWFVTXcreFZ1a3dxR2pLamJhOFUv?= =?utf-8?B?MVJBRmZwMzJhdm9yYVVrekpFVUdvUmwzUmdsam50RmZyR2hUOFZHemhFK1lv?= =?utf-8?B?YjVtcXpuNXZrYUVmbDQ0cFYzdVgyeFhJK3dWWEE5OVhCanhBbVNwQ3FRZi9F?= =?utf-8?B?V1p2bGQyYTNKS3V5NnhqUHpHTDhlKzAySFpIUjk0NGhCLzhwVURwVkxjbDhS?= =?utf-8?B?Mm5NSkYya3FyUGxPQ3VVa285Sy9YMktlVDE3aXhWWEZ0bm05VWc0L28rejVI?= =?utf-8?B?SHVFcGdwTXkrTGxZbk8zUlZYMkROdENEZTBMTkdtT1UyTWMxbGRYcmFVWksw?= =?utf-8?B?L2lZajR4TUVoNnB2VCtURk9acUNsQnhwOGY2S3hwa0dpTUdqRU03SWppc3VF?= =?utf-8?B?ckl6cWZiLzhyZVYzY3VtcytZQnkyUnpYTjBoZGpmQjFMaElCK0g3U1plcTNE?= =?utf-8?Q?lk1zSyfYFTgYsXHKyFSnh2CL2L5Tm4ZPT/zs=3D?= X-Forefront-PRVS: 0369E8196C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(7370300001)(6049001)(6009001)(39840400002)(39410400002)(39850400002)(39400400002)(39860400002)(39450400003)(377454003)(24454002)(42186005)(5660300001)(8746002)(66066001)(2950100002)(6916009)(86362001)(305945005)(7736002)(81166006)(8676002)(47776003)(54906002)(4326008)(33656002)(90366009)(25786009)(53936002)(110136004)(38730400002)(6246003)(50226002)(3846002)(36756003)(23676002)(57306001)(83716003)(229853002)(82746002)(478600001)(2906002)(50466002)(6116002)(53546010)(6666003)(6486002)(50986999)(189998001)(7350300001)(77096006)(76176999)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2501; H:[172.29.66.35]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDTzJQUjA1TUIyNTAxOzIzOmRXWXN0cjNmZTZGRlpRTjlGNmhmZzdOWUJp?= =?utf-8?B?RkNNOXV2WHQ2cHUrQ0ZsT0tDb0tFQ1ZRczFYQ1VKaEkySEdxTUxzcmU5SjRh?= =?utf-8?B?QUZkWU5UNmJZTnJqOCtzd0dLVjZmS3B5dS9xZGNuQm5NRHdsaEZNRkRFUkFq?= =?utf-8?B?L1hSUEhwYUREUHNKNzZlUW42a2NweEpqZ0JQMHR6emdxNXorYklJcWdFYlpE?= =?utf-8?B?ZEsrYk0zM204RmNENjdweHQxTDNxNkovSUx1RXByaWNIellQSFhEWVRjNjZn?= =?utf-8?B?RWttS2JyeEdMeVlXY3VGSFI5VW9nYVM3STdZaXZxdUo1a1l1UDhhcWxzbDVj?= =?utf-8?B?WWJqS1RJdE9yWFFYM3BLR2Evb0ozS0dTMStqamxPZUF0QWtxYkt4bVVzTXJx?= =?utf-8?B?alpwcCtRL0RLbC9UTWdzdXFKL2lhUlhlZWNiSHNwVVNCMFV0L0pVdHdGM1Nl?= =?utf-8?B?citmNWZId08wQy9NUlAwdHMxKzFPNm9qT1BEOW9jaGRBeWlLc2VZcERjZUpl?= =?utf-8?B?eXVXVVpqMjRKN1NhVUdoeTVTb21JVjg1VC9YZjMrMTdQdzZBVkczMG0zWDYr?= =?utf-8?B?YnV2ZzFoQ0J2SHBLZGxLeVdkQkhJVG9IaDFHNmlla09OOUZWcmRTTlgvSHF5?= =?utf-8?B?K3lzRTZickY1TnA5c1U1aGRUdnlPR1Fad0MyU3J2VXZVaEZKTTNLZGVVOGJS?= =?utf-8?B?N2RObnFPWFFzbXpuTFo4YldnS3NxSno3VWQxVDhKaDh4Qmk5S1lDaThmS29P?= =?utf-8?B?RTA5dlYwMndBVEx2RVNlTnViOXVzYnVKZ2pYWjNLaW1wTzlHMDlOdGc2VU9E?= =?utf-8?B?WDA4djBnOWdoZUJMMVFFNGNRQlRlK0c4VHM4NGY2UEVKRjB2Y1c1UHBTWGQz?= =?utf-8?B?SjZxR0c3MFJhV05SVjFrWFhSVml4OU5TangrblFrQ3JGbUJWdVJqdnp3c2V3?= =?utf-8?B?cUJLaGhZZTZaVWZVVUVjRDI4UGZPQnNoWUwwdi9lc0NCbVh1MElGTGRjNk04?= =?utf-8?B?ZVVSVEtjMS8xeThaUTdZTEEvNFFlNXdDMU13aTFOYUFlOFExQ1NvRm1ncFVw?= =?utf-8?B?b3FJNGVQQzBnYjVGT0o4MFUvZ0dvK1VkY2dyZFFPUy9DUnEyQm0vRm0zblpT?= =?utf-8?B?L3hYT2ZXREMvSlNzY3RVUVFOY0w2eDFDSVZVaEY0Qk5hOVRDcDFvNXo3d2Zv?= =?utf-8?B?MlJmNnFKdXo0QjFZZDN3VE1IV3JaOXJxeWtTQmJhSlZ4OFJHNzN6cmNXa3Q1?= =?utf-8?B?Q0wrL3kwdVNmd2hPajBMVnc1MUJyK2dzYTJPbkl6M3k3MVlPd21PSkZBdTJB?= =?utf-8?B?bUlCZXRhKytVdDVKR0x6MXc2eHExMHNQY0VDZ0piSU1lY01KWmRvVFpzSHpG?= =?utf-8?B?WTdSblhHRFVlNGVsekQ2cHhtOFRVQmowS3psZXFKMmRPMjBHTFEvb2JhL1Vz?= =?utf-8?B?NTJaWG1qcStCR1dxZXhKczgzQXdHdmxjNWFSK2ZCVEhiQVFBTTNGQVFVNVNr?= =?utf-8?B?WmJpR1kzSmNlcmpLMWdJR2NJUE5Pd1E0QWsvZmFNQkpFalBadXlWQkhlRFRi?= =?utf-8?B?RS96SWcxTnMwZmJUZ1pCRUpJQ1NuQ0hTK2Q3UElwa2ppWTRrdXhJSGJTVTJO?= =?utf-8?B?S1ExT3VCQStFWktsa3RFaTdNb1lJRzZBUHpKbzdzU09lRVBBZEZvOVVnRk4x?= =?utf-8?B?dkxPUy9hVjNLcnB3c1ZBNVBqcnZicUFHR0E3dHU3cUlheDQ3SkNkTStMQ2Rz?= =?utf-8?B?VWorSTk5V1dOM2hXL2cvR21yaCtPZ0RxZDRqeW94MkxySkU2QjFWak9XTnNR?= =?utf-8?Q?X/plTpiI7cbJ7?= X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDTzJQUjA1TUIyNTAxOzY6dG9RRUlZMWNXWHhxMlVNQ3JzZEcxVHg4ZWhC?= =?utf-8?B?clFqMUUwUStVMzBiUXVBWUdJVXBPZUdEUXdLQWVBY09ydytkSFlrMlZZRGlL?= =?utf-8?B?YW9mY0pVZW9mcC8rMjhoSnd5NFVIT1dHUnRlMkNsWHNPYXNQSmpmWnc5dWh2?= =?utf-8?B?d2RYUk5Dd0NtS2tQeWlUY2dGZGlGT2JxWTIxSGJVNWlPUU1HZ0puTlVQZFdx?= =?utf-8?B?WEVQckFSK3JYai9hMTV0MkdoZzM5cER4TlVPbWk2aENNMS8welpEVUwvRVJx?= =?utf-8?B?OFB0OWx1TGpmTUkwRS9JNGh4VnJSUEVkZEhzVnUyRGFqRUJZTm9zQzBQVnFz?= =?utf-8?B?V0VWWXpvc1M3ZVdGV2dIdytTakFMYmpTSVNWcXNVYU5JSkg0L2hselV3Ym1l?= =?utf-8?B?TkUyWDNMZEZGZGlKSWJPZkdCQ1cyQkNHVTJ4SEJLa2lBTDA4dEk1eEJHTFQx?= =?utf-8?B?MmRRVFVLRHJaOGJWRzVDYytxZ2NITlJhS2FQTkhnNEs5WjNvdENJS2JxQVpy?= =?utf-8?B?VUNpZlF5SlZoc2FrR2ptNWxNVTJJK2JCS3dsR1dab0E1NzE1ZlRpalBldjFG?= =?utf-8?B?dmJHM2M3T1RFK0tHWkRxbS9mYnJNNDZHL3ZrTmprSCtnVlpYUXBDWmV5ZW9z?= =?utf-8?B?NE5UVWRjTitBczc5MW5GTDFUbVZHWUdzRDhlMGNoNVE5QUczV3JyRFhjUVNT?= =?utf-8?B?QnFwb0Y2NGhrRXdIaklUTy9odFBNWG5DdVZQWUNSRmQ0MmhlS3RyNHYyU2FT?= =?utf-8?B?YnNTbW5qei9xNVFCS3Q0anlyYk5ZWnNzWkZDVWlXSkJNZlJzNnI4dnlvZEpH?= =?utf-8?B?WTZzUDJWWllpUTF6NWo1Wm04MkF0ekltbng5c0xwM01jRlFCeFc0QmtRbU82?= =?utf-8?B?TmJkK003M21KUXozZVQvSkQ3TzE3eWFpTWk1SWtTbVNUSzhJOUVuYTFWUStm?= =?utf-8?B?WUlISWVpZ2hpbzh3MVFGTTNMY2VxNlV1MFhlU2NuanZPMGJ3QlUxdm1zUDNC?= =?utf-8?B?M3RlUUtzbFFqOXJTeXVLZnZNVXNCTi84TWkybkRuSkFaMXFnc2h4UnQzZnpy?= =?utf-8?B?WlNiQXNyM0FxTnBiankyZVVLMExtUWI4ZXZKSS9ZbytJZ2lyeC9kNTZwRTM5?= =?utf-8?B?L2R3S3FDSUExQU1pZ3lmSFpmT3dDUWk0TmJFM3poQllmSWtCckZRUFdUeEtY?= =?utf-8?B?UVNZMUZtVWsrZFhwZGVRSjJMOFlJaXFwbnFOMCtOZ1JXU0tmcmZSZFl4SFA5?= =?utf-8?B?VXRudzdBNEVsYzQ5c0lRdTZ2cWpMR0grZFh3VE5kelNrMnJueUE1NkF6WHc5?= =?utf-8?B?aVhmeFNpYkdsN2hMQjhTOEFFM0laSDEybjhIKzh1MldrTVJROHN1aTRkWS80?= =?utf-8?Q?t9IWEiG?= X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2501; 5:3jQTHOU9ck4AYtEjRZh+y+SuQm/Gv0jjFDIOp6JWpXPCe6Huxe5O8g0pceMXRPNxL/Qd22+EDQBte08j2m4L3g6Rqzh+wEKauk+mkxzpG2ydR298nlhuJlWGVSxyHRlly3vts9AeH7Ffy03o1sG7GPhL+0T6X3aMc6g24uBRkfqKUw2k3UcKHxX/fiIoBU2+4uybVJq7i+GRWOHFFFjEa66dXyTFmDCb3IBFkxAhDLn/2rm5Lxh2yONnHzKdmWfTD701y0LbdDXwhP24zqhjePoxtNXlyza4X0axd+J/e5YdcWghc1WDHm+Q4NDqfZSuDQvEnqQb1nJrMx3TuJ7cd2RAXQxhl81z2wLFY3x3mrJtCUf+zQE2rwg3Y/oOd2E1vLIRH0+fxuv87T/fkESK7i5IvjScJwenZl3bhcKxpOSJHvefkqyOVJLPk67yLHabU85TqFZ8BE9jb5Emrj0CzllauiCOXkhAzY0SJeEDoTIhyEboejPvfb9KTOG42fFw; 24:joa5vg3P7L3PBiqlyLXUr5fvW6+xG3g3hm4XsB/ebZqUYvruRBAPUb44Yb6JVuYNI3qF37NyXDsbDg7+7Agbf5kfQeiMiSGytA8gJsacNOE= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2501; 7:Q6Wuf+dn1ilAQ5aLxGHiXH5dFmnr6hlFEAdkkSs5Zfp9UpR8TmxM/5eDTZLewZ3p5OKnGknFO4PW7TeO41DZgs7Ku5SNZ07VhyoI1u502cEAHEO8TjmLb/JlEOqJLjP1veBAymcGuCjtlGDDo5GGz77gUqKY8sgSxVe9SqLOYsWCwh0RVPyk2VpW2iHk+7EljIqEGNfmV9VOBL2g87TrKaGFe7FoyCBxZFebXFzqDFEpEudUpwfKdslF57ALaRKq6FBfny/OQRWcr6FpzBF6h73rJYqLw+A1HoTGSfQms9yZ7R2E6OxLM05eE2m7HMJm2rensJGxP1ViOXwSHHwHDj4EQP277Y1a6m5R3wfjuo2/5bpaQq3X/Q/P5Wb3tthngKxCwEm9X0qxRT6B2+Sph5hqZolWLOOghU9ZRtzxpZqtXLNWU0aGqRTramdPtpq2vuMtQPdot4mBH5mv0dE4XWtp9c7VtM8i5GThfyCXQJUqKJimg3PQf+Oegidjp3m5GrQ6OFnrb1Y+lBwZHtr78ChzqFgn9UjR5hFIn/lexxFcFEihqLN4XNs7nYUHPqmP8jMkYdVd3f/qqOcKvI6A6RTXlxSAByOBZZlglbfCUBqJIrdFhuoAn15ERfvOC9eJx42FwqU+/AFeYryIcf8VAuil3wAnNXyAWLhh7g/fGcms/ohZ3/mMdKLXya5lra0wEtylnOvv+WHifTZyZ8X49rnrnaa/LoifWB0mWU9/XfHsw9L7bOOkbG5mASRr6VyF0QvYiAEe54kii2DY7MclNQQ2ClBF4B/AtOXeTpgrEkc= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jul 2017 18:15:58.2258 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2501 Archived-At: Subject: Re: [Idr] allocation policy for BGP-LS registries X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 18:16:03 -0000 Hi Acee, > On Jul 15, 2017, at 8:12 PM, Acee Lindem (acee) = wrote: >=20 > I think we have contradicting goals here of encouraging = implementations > and discouraging suggestion of IANA code points. I would propose that = we > =E2=80=9Clower the bar=E2=80=9D for early allocation and allow it as = soon as a document is > accepted by the WG. Also, I would remove the AD from obstructing the > allocation but realize this may be a controversial opinion. We as the IDR WG don't have the latitude to rewrite RFC 7120. If you = want to change the allocation rules, I encourage you to submit a = 7120bis.=20 Do you see a problem with changing the allocation policy as I previously = suggested? That is something we do have change control over. --John= From nobody Sat Jul 15 11:52:03 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CEF8126E64 for ; Sat, 15 Jul 2017 11:52:02 -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, RCVD_IN_DNSWL_LOW=-0.7, 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 P-rGfkOYwBuv for ; Sat, 15 Jul 2017 11:51:59 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAB511250B8 for ; Sat, 15 Jul 2017 11:51:58 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v6FIpucY028237; Sat, 15 Jul 2017 19:51:56 +0100 Received: from 950129200 ([193.86.203.3]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v6FIpsLp028212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Jul 2017 19:51:55 +0100 Reply-To: From: "Adrian Farrel" To: "'John G. Scudder'" , Cc: References: <5436099D-D57A-4D29-A744-0E8A3572845F@juniper.net> In-Reply-To: <5436099D-D57A-4D29-A744-0E8A3572845F@juniper.net> Date: Sat, 15 Jul 2017 19:51:53 +0100 Message-ID: <05db01d2fd9b$6df64520$49e2cf60$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQEzgIKmIpKDmfMeFQjoidQoB4IQ06OUNJWg X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23198.001 X-TM-AS-Result: No--14.198-10.0-31-10 X-imss-scan-details: No--14.198-10.0-31-10 X-TMASE-MatchedRID: xcONGPdDH5owJ6xbTjBa5uJmMZmLmwx5c3ewuwbSaG6CsBeCv8CM/Y5z Ry9spvXWYEwjdRBgFKW9IDmfKlAy8PQYZJBBoF8RTQh9A4m9EtFqZ4nWssFp2Np1biJhIyNRp7u eaEkDqTPmzWi0ELzEefaaEZAHJRdeR3YbmGJC20zIOn6NK8S1a63/cqRXNyHnjU67CM+uPQQErq zpg/UGWldXgL2RLMnzj4cP9/Zx+lVj97rcNMasqSlrosmS0SOAnvBHr/aFnM4EC1L5wWS9ivv06 Bvu8HNovXZ3TOJCsZxelai6VK7PtK+E45fdyyZXBEfU2vugRF3HeXKrbMIpABFT6ltzclWNn+qk 6BZy3Ktmz3oAaqhwt6uJm2QuCxjNFkrTnESQKQJT46Ow+EhYOPbzwLYeVoY0EoJn5DrIHyoDkd7 WQNL44uLzNWBegCW2XC3N7C7YzrdWRVlrjsKO8N0H8LFZNFG7NwH7I8fAFRqyXisF88VAPouD/9 XNGz31Ru2PjtpwFIAJm7Vj5jzpGDZJCryoRjpk Archived-At: Subject: Re: [Idr] allocation policy for BGP-LS registries X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 18:52:02 -0000 Personally, I'm old grouch! Early assignment is easy and I fail to see why an I-D would squat (and risk implementations clashing over code points) when early allocation is not much harder than FCFS. Certainly, by the time a document is a WG document we should have a really good idea about whether it is stable enough to get a code point on early allocation. Before a document is a WG document it seems to me that it is little more than a punt an burning codepoints (even FCFS from a large registry) seems a poor idea because as (if) the document matures the meaning will change and then we have to ask whether the code point applies to the early version or the more mature version. A > -----Original Message----- > From: John G. Scudder [mailto:jgs@juniper.net] > Sent: 15 July 2017 16:42 > To: idr@ietf.org > Cc: hannes@rtbrick.com; adrian@olddog.co.uk > Subject: allocation policy for BGP-LS registries > > Hi All, > > You may have noticed that I just sent out a few emails scolding authors for > squatting on code points in the "BGP-LS Node Descriptor, Link Descriptor, Prefix > Descriptor, and Attribute TLVs" registry. This is one of the things I least enjoy > doing. > > I notice that all of the BGP-LS registries have the "Specification Required" policy. > Experience shows this tends to invite such behavior. I further notice that three of > these registries are for 16-bit spaces (BGP-LS Protocol-IDs is an 8-bit space). > > I'd like to invite discussion about whether the WG thinks we should convert the > three 16-bit registries to First Come First Served (FCFS). > > For those unfamiliar with the respective allocation policies, all the gory details are > in RFC 5226, but for our purposes "Specification Required" is almost the same as > requiring an RFC in order for the code point to be issued. By contrast, FCFS allows > anyone to get a code point at any time with minimum effort. While there are > some drawbacks to FCFS, the major advantage is that there is minimum > impediment to coordinating implementations in an organized and disciplined > way. > > Hannes and Adrian in the cc because they're the "designated experts" on those > registries. > > If the WG wants to make this change, someone would need to write a draft to do > so. Such drafts can be very short, see for example > https://tools.ietf.org/html/rfc7803 (this is just the first one I came across). It > would be great to see someone volunteer for this work. (Perhaps someone who > has been eager to take the shortcut of "suggesting" code points, hint hint?) > > Thanks, > > --John= From nobody Sat Jul 15 12:21:34 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B374D1270A7 for ; Sat, 15 Jul 2017 12:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-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=juniper.net 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 D7k9Goz2lTSZ for ; Sat, 15 Jul 2017 12:21:31 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0103.outbound.protection.outlook.com [104.47.37.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3CA91243F6 for ; Sat, 15 Jul 2017 12:21:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qeQWBvdnNXaRf9ESjpbDHCQLvVpU+gUoc1tLoh1Wnjo=; b=ZduknKnxaI9ma41uzc3HJYD7hUVGbUV4e31wSPpD/pxSDczn2X9lbTEVuykLZY64gZ/Zr0+H0eg7GIArm6bdbd7g0vh/n7KRl1+/ADUVJeLjYAusWJAZ7ct2L6gNTDlFWGE1mfKf1ReIqjCWEQz64dDYwbGrjrrQ6dkprBASiLM= Authentication-Results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; Received: from [172.29.66.35] (193.110.55.12) by SN2PR05MB2509.namprd05.prod.outlook.com (10.166.213.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Sat, 15 Jul 2017 19:21:27 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: Date: Sat, 15 Jul 2017 22:21:18 +0300 Cc: "idr@ietf.org" , "hannes@rtbrick.com" , adrian@olddog.co.uk Content-Transfer-Encoding: quoted-printable Message-Id: <4BFA27C2-97E3-4777-A688-EA2E33DAB741@juniper.net> References: <5436099D-D57A-4D29-A744-0E8A3572845F@juniper.net> To: "Acee Lindem (acee)" X-Mailer: Apple Mail (2.3124) X-Originating-IP: [193.110.55.12] X-ClientProxiedBy: CY4PR16CA0046.namprd16.prod.outlook.com (10.171.216.33) To SN2PR05MB2509.namprd05.prod.outlook.com (10.166.213.18) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: ce974d88-2b86-4ffb-c158-08d4cbb6b207 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(48565401081)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:SN2PR05MB2509; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 3:luch/5Wm15j0uKTiqwCWq7n7hS3UtMh5s41IWWp8wDRHe+GOJPgMdtrLA7ip8NY+EsOB2X2cF5fMu379fFxVufcGbRv5FjsM3UIZWrRCxfuJXmD5Au6DZiP2Vq6w5qKR5RjLVIfdS+H/7dQYdg/Yj0tM++EIeN95JiLQMUfXCGE0ZXnW78JAh9HvlaHYDOIfb4lTzezEWaLoNYLh9NAavamGY3WpM4fAFBOkifAtAbgWIWPykaJEgh0jMZ9LeaGbuh00oNHJEFD/XegVbTkF7rH18bwmuVPL38+B9NykGOohkxCBDOZ06dssQ+AFkGwkW8eY/Qu/NIJm7oJZ6G2/DPrVkQyeudCnN+scb1NUDR1lB/2mJJXkmF35Tbc5qEvew1Ct+FztYSntb6rLUPYH7dDSMd98fC3GlxG6VK/oVJQsY0U0BYv+Jfs3Q3w2kz1ZiTCQBtpATJIQjPysc+8z/dbwKgNmgx8sugszmTGbk1EOu5f8/Wkt/3g1vXmp/yne62MyKR65BPhRKDlg3ICJuHRYqVd85VWetYu0+96AlRjqeeigHsJfjAT21XNrcWf9DM4t4JB58552V2H5tdAAacW0npjhQg1qZ3axWDpv8V7txRPdBgaXE0LG6611lhY1AvaWbYwA5EzKczXyBPVDIah06YyxI/iJ1jh/rI1jNX3rVwZoaS94Kt+QcnF2yJtbqZKoDUE47cwtqcMiL4NAVsCyrpPOjQq3r02u3ROhcg+7eLzlxEY7NQ90gFEIEWlgm1jiu0vxh9yA38alrZKLlQ== X-MS-TrafficTypeDiagnostic: SN2PR05MB2509: X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 25:e2VAoF6eQ1oUnjn5Tt7rrpwd1k8FzxSXX0Ve/ETcDwgA5xKY5wOQ2fqLgh3KtELkwGIRlRHOLQZHQF7DG/RDN2fp5NH7iazDQWaLYDB0n9uDvhGZWogykud/FNe7T8rQD6dbJfmw/K2yXqxXuuxLg0by54cLc8L9K9xc5JfbUxbmHwvFHg2YrCQfeB25VdtXrQIrCtw/eaROjmuWMm4+OYkr9QOayPOUdG5eP7tI9QZSqzXZZfnjTl1/KGTc5PgxBeFVp/EauMmAzLxaUblWzBMlCQWdX94/1UoRnB80VdYBKSE1fiju74h5fV5mBvl5IzBBUY4V4Kvh8IEt3jAKNCcNcIUWIuD1wzLnYXqalZk9iBxXcYihfSOvQymzPsMgAdzIMqH7S0k2G7AVsrj4GKqNS4k2e7bAY27ByaExCPqyfUKl8hQwyvATvBfM9+IGxhE5biJs/KGaqZ1rxxqTQj69Rdh962kHTwRS6PPKiQWj/A7vQETXlHMjt1LJspttG2DqnRztd0uSHAwwlR6SDqht8CJC583NMqxJ8YFP18v26rm6N4htM9zwD48JwUBrMifI4WU9MpCSPmrumR57iJR06Xh0UfJr0GLqQZAVaYv8NnaAH2tODceyHN833gbkwRhJcLFe7gS0KFZtbI1W1Gqdnwv8MHAwBkclFjIDDu3sIFG79wkT8QBp5D1uN0deqQ36eBXGqw6jVECrNm+QF4lUeTxtPbD6dRO8sROrwxy0sMxJDyREfLChdMX4CdTkPk+FlQfxGP/0VeP3ftCOD0PwnH14lE/P375enjkc5c6A73479UC1qLhyoYwk4RFh0L6VuewkHwck4T82U5ll3IKYfduuSUJlnmZWlVZgR6GdTAw86muA8V8c6HMMHXsNyQa007F+s9JiauR2F8I3gizuhodBNMKstqPqzJKdhOk= X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 31:gUw96bu5FwFsfe1jinvTaBb2LxW6eStlCEYsFr1i5hu3wMuqgQr4Z4XeYQICIRwAy1S5Rm5ub+qk6V53/Wxhet6P4n6jRnoIFdNI4FWEjss2VYliFGqowGF8OmLwCnAN5+x+51AjAvOrAzTr8JVWUEUzoTx9pGDD7gYWhpSQlQ9et3Fn7MGEsRl0NN3TX9M89YqSw9CnshjCPsN5h6ZxrIsVl1MZpbG85Vy/R8uRkPLCJvkSV0s+3NBRcjv7t0Pg94kUpqleGuN9jwBvhXWel/8CG0eL27pyLUleoE/JoZUdOSZV2unQwel1A0QidqOuZ5OOj4Vrm5eVCeyoGtYl10wgZlgMkmMwo2l68uUeBSSR7wPKnyY22o31E3/UaBKc9k7KSzm7l+HufYArt24V6vzR91dJA0vkVCJFM5rn/LTy8MNcgwk773JBcKqVj+2IbXnfIZudiPUjV7NHCjvz2Vjzhm4AIeWe1gw+gwSWCTQtcVa9LfOAlpxrnWo1kDP6pOhOZXK162kS2oW34uc42nOWhMr844JnAlXMY8/MTYaAEv8m3gB2zvmduPxufdJdkjRTrmylxN9uF6EH23PO25IkWgPGJJ1fvNf4z/MdmmsIxWwGXwCOrlc8hmGS5OQO6tCngskgfr+ioO2gdRzSGQBVIVJR1NPCymtrBKVouwRX60PYkYZPQgWV0ca2tYk9B1KXjCOzr1DBIzlvTYitgQ== X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 20:S3dikFhp8Qqqx7NVp3nMF+Nku2NPgVMMMZB3GSL6rVhGZbAGfAgJzsmd+YMgsbWLtoEoaAy8CcXdZHnWvjLlDUUpuintjS6/0fvTVNOeDh32Fs9eDYhIXxtQLm26MezIiSaNtDc73xauy8M/5oyuUr/w7rS6Q9EZH7UAESkpIJobyMBj/pJNi1COn5bWNRcZdoZM9chtS5r/dfypk4+YxdVwWSyqYp+O0IVgw1forqFlWrj2/QhigH6GNTt3tvTe1lv4LaSl5vyTmEpu5JoljcBoX8Hm8HLYZosWrHhAL5V89usLvE+yqN40GwKsFnipsRlMTTsokdGfZ+WTfALUOu4r9APltyNoBy0lQmrPr4n0EuKBn8nVRQuUhXDCeFS62GjCkxWD3KEDuM4e0slnFeD/+IbDWtj5oLr3jf25Lo2l25AUdSqB1j+VkpKiG98zAGKDczw/On0cwhx/TmOEOV2dTg+FtUIcg1mQQeKWF4isa2hPKTXLsj8rRIKNslSF X-Exchange-Antispam-Report-Test: UriScan:(236129657087228)(95692535739014)(247924648384137); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(2017060910075)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN2PR05MB2509; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN2PR05MB2509; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR05MB2509; 4:Ad3MktP166qw6aw7ABtvcIKMfycMDVOubjw7d8Igp1?= =?us-ascii?Q?0VHJoXOWYk+wvtY3QtV8kEQs8un69Vy42QXrg1WqDYYO2/xd88sezN5tqjC6?= =?us-ascii?Q?5JABX8/Q/JGLYUGp0CvjedPpgwV386+bmbwm0xPQ/9ZYWXu7+7RY0iiLiuYt?= =?us-ascii?Q?8ycGV3EwEbOwAW+RA8Z0t4Np0ZS7485/Kfh+Hj2OG8nD2M00Te8H58XP31NI?= =?us-ascii?Q?pXdam3I977dQQM03mftMCsSIkeqhmB7XBmvBtIVBo82xsUU2hFr1g7dN42hV?= =?us-ascii?Q?Qolc1gxvLo9H9q0N4tryzgCvlZCakzfE7JJ4PLt5KHSLc9eiRQdmGgKCeikb?= =?us-ascii?Q?fvt0Z0TKKQtPi4zZa911UKvJB0cRC1LInXRvE+yysxpjL3rRKEhylSe8yY1T?= =?us-ascii?Q?E6jNu/O/LC+TyeSIpW8a4d9uxq8S4NHL7tJiI+v9xyjEbR+bIZiGsdm7XEEd?= =?us-ascii?Q?b/J4gNrkTqr90PtWeogz5sEME8xGS2UVEyERaEesF7YGVlIZ84aDyr9tLEop?= =?us-ascii?Q?uuBLb8He6mQRKsYJRuG2RPNJ9Tmtv6Eh1+R0GMyGLs3aKy2uzwlsGY0S2Xm+?= =?us-ascii?Q?2nQzurKasa2CClnyzgcwu32lRaI96FgLw48GY3cMqTZYACPWjeBJXKQ8sb68?= =?us-ascii?Q?n5v2QoyTbdKTiMuq8hA2Nn5FTdZeweFAYB8m1lwGlB+/p71dkyQEO4QwVdwx?= =?us-ascii?Q?H2I67/tpY3Ptf72AZX8jpNfbQIWwvazJTRDFfw6vadz8Mt5aEP7aYvnuUTu5?= =?us-ascii?Q?uQTueC3rW06VG332comuyTri6yUWgdjW5S8JQDCi1X+Q1AwJyFpuUdZ/a/9s?= =?us-ascii?Q?mp6dYYgaBuC0r1JPI3zzbqh5IuhAvjmXG03BjlmWU6wGsogZfSTTQudyUj4w?= =?us-ascii?Q?p52U1G3Etggvy8YA2QkO6uy4fAAi1PeQQ9gRXKNVwMLssMz4TyXIewz8jqWr?= =?us-ascii?Q?DuMTKA19c6ETxzjyaJYcBq1oo7MeErPaXILODIHRCLQYo6nnvqEkaSZM6xnj?= =?us-ascii?Q?bi80p+AKt28wsIfu0wupiJX56Ouifub/cOX2xt3dlcA82YYx9twQi1RLzw2D?= =?us-ascii?Q?B7FNNoxF69coZ4pATOqiqyMYvSLoLo4peGzwqBVqQYgoPofQ4+4wRUagGoYM?= =?us-ascii?Q?bFNTigG25jS/9kDQC5acD+HxM620epXpVvBSNj+BGMpw4icvvg41LFwvqLZ4?= =?us-ascii?Q?tB46e8jQapTRg0+Kcn4pdGwytGi4y/5874QpFZOLFFvyEapxGe76DwAYVMNy?= =?us-ascii?Q?H+IYus5yn6lg4xUjZYWcsEVKOq/OcxTt6ufnGjRaWXGPvE+Baj+27pcg21u/?= =?us-ascii?Q?D+Oxh7CTvbBDckHNer5hA=3D?= X-Forefront-PRVS: 0369E8196C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(7370300001)(6049001)(6009001)(39860400002)(39450400003)(39840400002)(39400400002)(39410400002)(39850400002)(377454003)(24454002)(86362001)(5660300001)(47776003)(66066001)(57306001)(50226002)(305945005)(36756003)(83716003)(50466002)(82746002)(7736002)(3846002)(8676002)(6116002)(81166006)(8746002)(42186005)(4326008)(38730400002)(25786009)(33656002)(53936002)(76176999)(2950100002)(2906002)(6666003)(77096006)(229853002)(6486002)(53546010)(6916009)(50986999)(6246003)(110136004)(7350300001)(54906002)(189998001)(478600001)(23726003)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR05MB2509; H:[172.29.66.35]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR05MB2509; 23:qFaEwb9IEQ2A9XL8rTRAul3ZlsMnnYXOe4IGXpxq+?= =?us-ascii?Q?eCidWTOboC33GCLWtValC82R9SMYzf1kvTggchc4ugcMptPz81haQspumalA?= =?us-ascii?Q?LzgjT0OoHRtzY1EPByBej5s1YjZDJCzO3JUnxp4H6iyZSRl0oKtQhGwKukeS?= =?us-ascii?Q?8jmFWSB93ICvxb69ZiIN3AnefcFxhC2zzAEEb8YJ603IBRLr5EWfMd3gazR8?= =?us-ascii?Q?CtFLq9bGQyYgRaHG0Hfe+A9M7QZSw8Ujzyi1RFCXPXaHG1jIg6NORowRYAl0?= =?us-ascii?Q?efwedEyQPu81ljp3/kzzQpxPlJAiih6o19pCU2F/IHpQ7GV1JSfygIkSsgIQ?= =?us-ascii?Q?p2liEyFvhJvMk+bRKQht6GgoCNcZH3GfaYdr4k7ejkDfdmnz3SLLsFpUbSwe?= =?us-ascii?Q?2STUm8WRKy/aJ+ZtmvlzaYH4I6jlx7DuuJGbvGp9sVE3f2/t7My3/cagb8nd?= =?us-ascii?Q?SIa49FrOsmY3xYoIpV/6zqcgZWK3Ufgqyi0Tri1jmbAch243qV0hQ+64kSjt?= =?us-ascii?Q?h80hw0ao3awVGHhXEwYXdv2tE9PIsZrABkBIIKd3TeJkrO+acEExfi97bel1?= =?us-ascii?Q?4TmsY0Htg86hEpQuMY8YkVIOMOcleFrj0ECC/mprBSfZj3z47QMnKqJLjRh+?= =?us-ascii?Q?W30xzrHu8nawHpis7gTRCxdhGvAyUpL5JbWcx/Gath2qTZYRxeKEgBffiHvT?= =?us-ascii?Q?Uuo5Wsz9zYrqQdvqN8QfAw1t2lukJdzK76UHu18bMAir9g8w5iRkFeqb9Hdp?= =?us-ascii?Q?TdfJFUj3n0Zh1Ge/FlBg6Ynv8jS0iyPkagJ/YiGllriSPOoTdE9qxMvMLwwU?= =?us-ascii?Q?dgZ/0VVDygFkEfja9XHwVZ+SqRLJrpi0hYfD77Vp4hOiMjzyrMY6PBJLGXH6?= =?us-ascii?Q?sZaZ7G90aEM4PZ/MSYVJ8jtm42LNSoYdXzLLmwpS2PInm81SHmAonYQtE+7O?= =?us-ascii?Q?sSv6BJNTZOFFTztcFym91WWzOgtQ+mnnkdq59bmOTZM8EeZABnhwc7LnUmU/?= =?us-ascii?Q?fYHm9DVb+PoRUwBBWJmecW+y/CpmnI4ZRWlz6LD/nGs4TIPK26H3flvr3IF3?= =?us-ascii?Q?VlUMZ7PP01rEicHpTQ1BF6lra6VCuRGtnsvyGwb/A8u4PkVzKUbsvud2IEST?= =?us-ascii?Q?ktNDMCTIwjfyg+Qhn61HKfWBvgemGn0h+5l907US/eTba7fObdxjJWI0LZp8?= =?us-ascii?Q?EMEbiLxGlKzCRiQCIa3kdUm4NhcM4xwbtDXv8VesGHM/gOTdYvya5cqP92MC?= =?us-ascii?Q?y21fOPV1EaYZZqYg1Vp/zlPAhWeTf/rtXZeeopApAN/s0rY9adgOqBCt386U?= =?us-ascii?Q?wcZSd3CLhksSUMiSsg3JE8=3D?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR05MB2509; 6:ocA6iV6YBUU99Gdwo2CY/PXSRtzRPHgPA5V5Py2QbC?= =?us-ascii?Q?BbP2CbS5dLiQdbhableghWo9YZaPhLZgXOdX3gsAFh9ThqH9zvIKd8EFuZFv?= =?us-ascii?Q?iTYVFPZnnJFn5a0wqqRDVufM9Rgj7i39qiijuWlrOcG69Gm3hrbN8hKK0Ef9?= =?us-ascii?Q?VPt24H5dJvms6iIgfuk4smINTYPfKYzlIlitcbJokDdkxtNQ05mcNnTYJMSD?= =?us-ascii?Q?JzirMsmF6r/g1B4gOJuZg1o7FywMqZb7LD2VXfaCmqimF3t06PI2hldrAi7/?= =?us-ascii?Q?RxzumpewLiQBXlWNtr9cyACrTWcIBmAj95GFsvvy9ouzwgwFEptmMjSbWaUP?= =?us-ascii?Q?qRncl9H6MtQSB3JZwIy4wUd003XSmTtsTuD5glAtY9cIUvMPy7odCcmG9M96?= =?us-ascii?Q?iwqNwvRLKrI4qcfndCh02AFwLwsMZLXXKF8fDP3+jETyWvFjby+KXCBlC0d0?= =?us-ascii?Q?/6xGNsezaIStcddDkytkLs7kdaek1hkBqEFXb3aB4TpbEpvSxjTTzDCo2M0d?= =?us-ascii?Q?pdxYDTF4T2Gsir85C0yU1ejJh6tOIH4LTHWxMsL/x0WSyo7H4am4LHrd8xGp?= =?us-ascii?Q?DyEahxN4hjBYInDoZU+9LTZAmd8npt02rryfxdpwDq5NZU9wUpPJNhw4va9J?= =?us-ascii?Q?Uuo7k1btFoGAeVVlcw4hDMPO/BAWA3hRPvmaGY2C3JN3I0/9LE3gL2dxJWCO?= =?us-ascii?Q?wy3mDXC8wwAhqN8O3Jz6UjfhTWcgMcY82EEHq3OHMG4O4KPzfN1U2CgpNGJH?= =?us-ascii?Q?DyxVeRABZAaRDbO1daR1iNUz/GGvM4tvYDFoxgOkQpqVx1gixYuM7+JTEl1Y?= =?us-ascii?Q?y3uwSFhpPEqfe9vO/W7pVfcl+gOvJhdDLPEWanDrEnRVMEyH8a205fyktJhJ?= =?us-ascii?Q?rhJbbOR4SGDkaGaqKk0WgOOdSKlqc7oCdQ7alYPF44YoeAdTtGP4Vu6GH0kH?= =?us-ascii?Q?oKkzuKXC/miOjbRL8c8oTazNQoKHTc/vonUt5734iR5B4E2ktDW3CJwb+EOJ?= =?us-ascii?Q?UM4LhjregkD3e17vmpzCtG?= X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 5:ri/Rybxz0Zye3cDc5sXPJ0GtJ02osi1gfID095YPG314HlAdM4l64vHv1Ep5Hzn54YSQbRFZnReUjiz0xV1FRkHbZ9CLNV7zTdw+nzhxl5ImCZu0/yESsVgWPypGrJ0n5pKMABjyKeatQoL8IM3bZiQUxZ+LihELgjPWT+pphccJIO2rX40TP/a7a8UtE0gGPEsJjxlcBw8hEcPBYo7LXZCAp0nfD52gR+pE7GCmPX0ucxzd78L1j2JRkA42fqh7J1W9KczuAf4p318uBi7w7V+zV0qhOA0czK9WCgvRQnNN2QXsWt47lDDb/GdTlHimQHRki8K2sbdk8C6M7EZQEK984FnwccOEPKo9hp0WPvkKzbSxhBQX/ZWrxh2cOo9iw2OuII3wdU7+lTwNL9TzB43CD2LBPfufZeGgOdfKrBnnREaN5lfFqnXrVq5YpVAVW5PLxxNqBJSVyndrvWF/U6OOmwvHYkuNSaG9NyxPQntBltU1r/lVPaLiMtzee6z9; 24:OEgK7nMY3jG+ZfjtEzI51GLYzxP+lHnWXJfH5IBRuyzso5P9PmoYuD4H2LzpgEehXBhSpS/vh+M148VYVNyrh2S03kFvuFPMEo+8SD71xEI= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 7:dwrYg8hCdlmfHh9Y13pdxRmdCLLAbN1yZk2wHGhsRcy8TEEV3L5bIRS/5EMKWJAczT2OeA0pnvNew8ZBV8/83gzjfwoa/5gu3q3IfImwFbU77MrUfQO9sMkFSXCIbrGjmNhIR4lFHGLmaAKRsJyf2DkKyzGVl+Bv0F05+KHdQkNnp2Mpop9tb9HOkvg+sUhY15maojEiaLYFsUpy1QyrO4Gd+QGTnboNT+4eHPZ4J3f3nTKlGOjVJVal49XLLFQcx/mWSrr/S6OlXBRAmr/o12otFRtUJi5MMFLRz10WRfWSOw0FcocuDENtLQHtRYT/pma8Hb+JJjVX2gtWpilmc3/QlSCGyOVkgjKTTHLSt1r164ZrY3ExVRs4DPHuM4keXoKb9/8Rub8HQtcW176WMhrsl+7PjipsDmha5HX0QyD0F26tQhJa1nvG9upW8kIZNYSAG9MxdR/0PeubEyp90+cDspPnXtajm+5j63DPX6XmGNNmNDQCvMnFhbq0frlC+VvH+fvDhZLoMalWc2777uIwj/VabUpBih/Ae/t/Xp30465FMpJmV05LmtIN66pOPTn9E3pKVJRsmZC4zmhYkIM+RLE7XWzu8I0FgXj1wv8VBslyV1DrnNw+niV6aVijQP7IrocOEDqa+DmA6NvkLEDW1bD6172akABdOytUtz6YGDvJHZ6e0AvN3HB3TlmxG0DKsMO0wX0ozySMA7ts8+aqDyNAuovvHL0oTgGdw6/iVBhMj6GqBPURkk37l7t36MrUVV5hILMXlaizgp8HOghTw2RF+4NmUginrj92VlI= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jul 2017 19:21:27.8671 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR05MB2509 Archived-At: Subject: Re: [Idr] allocation policy for BGP-LS registries X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 19:21:33 -0000 One more thing: > On Jul 15, 2017, at 8:12 PM, Acee Lindem (acee) = wrote: >=20 > Also, I would remove the AD from obstructing the > allocation but realize this may be a controversial opinion. FWIW, I don't recall cases of the AD "obstructing the allocation" for = early allocations IDR has requested. I just checked our most recent = request, and the turnaround between sending the request to Alvaro and = him approving was 24 minutes. So apart from the fact IDR isn't the forum to rewrite RFC 7120, I also = question whether this particular aspect needs fixing. --John= From nobody Sat Jul 15 12:35:09 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04110127B73 for ; Sat, 15 Jul 2017 12:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, 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 d5cJ6Iye2PhO for ; Sat, 15 Jul 2017 12:35:07 -0700 (PDT) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::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 1BF2F126D46 for ; Sat, 15 Jul 2017 12:35:07 -0700 (PDT) Received: by mail-pg0-x229.google.com with SMTP id 123so9913256pgd.3 for ; Sat, 15 Jul 2017 12:35:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=GUcFzLX2F5YIRMA8a93stpI+4mC0hHWeDD8TtyAZpy8=; b=LsmEfkhQTU6RPbkrws6A3bGAmlvXeXSBT6ABOMh/KSKAi+2gRBy3Q8tieCUSLs1k8r fiCpnpcXXiBzHIeXxgFwO4ZJ9M6J1m8xoukjkKxEPJA7R+KTu7wZIq09QUJeF1OIT+oy WLRQpGculo/oS9TIIUWYaBk1XjYoKRKRC5IiTmVIED0a1gE9Zkq1bal5EGsthvpHPjPI RyUOQ0F+zUoB7PnFl1N4tFPskBsC8jtWoFX0KD38ZqTyKYu7/PdSDgqaYD198kJ4B0VM /pOmVZYn7UJB9vBmveBIMhpTlv1ca8NAj8td6eSpZSkxNNuheu3bg/fQRM7ZqJuVFGM+ /Pig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=GUcFzLX2F5YIRMA8a93stpI+4mC0hHWeDD8TtyAZpy8=; b=NEBwn8nlSOCV65q6HQsgkXX9DyWoxhsTwus2aXwvf5Uy2jgAjHRLPvnNmKMIfyUsNc aGs79vHgWelsj0H2OzachQftA3oPsGMLhF94BweGwODXEu3cwqZZr9i2pVAzv8pTixPl NeOHGzLBumBFUgt42RCwOqqnaUnTYvXSY4UAVjeYJxWqaV4+opQPljtfip+Kga0uB6se psXahCDs/QU1Ll/9V/uvQBqQuuH5rUPH5qzzsq7LtpBdK2NZRyzwR2gF2zYkepMh55p4 58Knlxq0tivUcdueJ6mKtxiCxyvDQqf8mtvW+cISiqQuaOzhA6zV7DSkjl9NiAzJbKBz Xl4A== X-Gm-Message-State: AIVw112LtIbduM+iZnua3Clpz1Kc3MGXP+L1LzIHqJ3O5HdV/0597N6f W4C2A8Qk3jnckyAx5rvz8JKgh48L9A== X-Received: by 10.84.248.10 with SMTP id p10mr21995026pll.89.1500147306511; Sat, 15 Jul 2017 12:35:06 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.100.163.98 with HTTP; Sat, 15 Jul 2017 12:35:05 -0700 (PDT) In-Reply-To: <05db01d2fd9b$6df64520$49e2cf60$@olddog.co.uk> References: <5436099D-D57A-4D29-A744-0E8A3572845F@juniper.net> <05db01d2fd9b$6df64520$49e2cf60$@olddog.co.uk> From: Robert Raszuk Date: Sat, 15 Jul 2017 21:35:05 +0200 X-Google-Sender-Auth: Z8DcgZ7lIkes0oc5pBLCY5xJXsU Message-ID: To: Adrian Farrel Cc: "John G. Scudder" , idr wg , Hannes Gredler Content-Type: multipart/alternative; boundary="f403045fe3ec50c2e9055460438c" Archived-At: Subject: Re: [Idr] allocation policy for BGP-LS registries X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 19:35:09 -0000 --f403045fe3ec50c2e9055460438c Content-Type: text/plain; charset="UTF-8" Hi Adrian, When someone is prototyping new idea way before his new extension is a WG document he has two choices: *A* Squat a code point and do not tell any one. *B* Squat a code point and *publish it* such that others doing other prototypes will not take the same values. What we have today as "early allocations" is way past point of time where a code gets written. And as it is normal that due to IETF not being that quick new ideas leak into products (read vendor's marketing advantage or enterprise own add-on) and we have an "Oooops effect" few months or years later. So IMHO the only effective way to avoid the mess (in parallel/orthogonal to current early allocation procedure) is an IDR wiki page where those who want could just log-in and put their "temporarily borrowed" code points for their prototypes bearing in mind that later IANA could honor it or not. Regards, R. On Sat, Jul 15, 2017 at 8:51 PM, Adrian Farrel wrote: > Personally, I'm old grouch! > > Early assignment is easy and I fail to see why an I-D would squat (and risk > implementations clashing over code points) when early allocation is not > much > harder than FCFS. > > Certainly, by the time a document is a WG document we should have a really > good > idea about whether it is stable enough to get a code point on early > allocation. > > Before a document is a WG document it seems to me that it is little more > than a > punt an burning codepoints (even FCFS from a large registry) seems a poor > idea > because as (if) the document matures the meaning will change and then we > have to > ask whether the code point applies to the early version or the more mature > version. > > A > > > -----Original Message----- > > From: John G. Scudder [mailto:jgs@juniper.net] > > Sent: 15 July 2017 16:42 > > To: idr@ietf.org > > Cc: hannes@rtbrick.com; adrian@olddog.co.uk > > Subject: allocation policy for BGP-LS registries > > > > Hi All, > > > > You may have noticed that I just sent out a few emails scolding authors > for > > squatting on code points in the "BGP-LS Node Descriptor, Link Descriptor, > Prefix > > Descriptor, and Attribute TLVs" registry. This is one of the things I > least > enjoy > > doing. > > > > I notice that all of the BGP-LS registries have the "Specification > Required" > policy. > > Experience shows this tends to invite such behavior. I further notice > that > three of > > these registries are for 16-bit spaces (BGP-LS Protocol-IDs is an 8-bit > space). > > > > I'd like to invite discussion about whether the WG thinks we should > convert > the > > three 16-bit registries to First Come First Served (FCFS). > > > > For those unfamiliar with the respective allocation policies, all the > gory > details are > > in RFC 5226, but for our purposes "Specification Required" is almost the > same > as > > requiring an RFC in order for the code point to be issued. By contrast, > FCFS > allows > > anyone to get a code point at any time with minimum effort. While there > are > > some drawbacks to FCFS, the major advantage is that there is minimum > > impediment to coordinating implementations in an organized and > disciplined > > way. > > > > Hannes and Adrian in the cc because they're the "designated experts" on > those > > registries. > > > > If the WG wants to make this change, someone would need to write a draft > to do > > so. Such drafts can be very short, see for example > > https://tools.ietf.org/html/rfc7803 (this is just the first one I came > across). It > > would be great to see someone volunteer for this work. (Perhaps someone > who > > has been eager to take the shortcut of "suggesting" code points, hint > hint?) > > > > Thanks, > > > > --John= > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --f403045fe3ec50c2e9055460438c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Adrian,

=
When someone is prototyping new idea way before hi= s new extension is a WG document he has two choices:

*A* Squat a code point and do not tell any o= ne.

*B* Squat a code p= oint and *publish it* such that others doing other prototypes will not take= the same values.=C2=A0

What we have today as "early allocations" is way past point of = time where a code gets written. And as it is normal that due to IETF not be= ing that quick new ideas leak into products (read vendor's marketing ad= vantage or enterprise own add-on) and we have an "Oooops effect" = few months or years later.=C2=A0

So IMHO the only effective way to avoid the mess (in parallel/or= thogonal to current early allocation procedure) is an IDR wiki page where t= hose who want could just log-in and put their "temporarily borrowed&qu= ot; code points for their prototypes bearing in mind that later IANA could = honor it or not.=C2=A0

Regards,
R.


On Sat, Jul 15,= 2017 at 8:51 PM, Adrian Farrel <adrian@olddog.co.uk> wrot= e:
Personally, I'm old grouch!

Early assignment is easy and I fail to see why an I-D would squat (and risk=
implementations clashing over code points) when early allocation is not muc= h
harder than FCFS.

Certainly, by the time a document is a WG document we should have a really = good
idea about whether it is stable enough to get a code point on early allocat= ion.

Before a document is a WG document it seems to me that it is little more th= an a
punt an burning codepoints (even FCFS from a large registry) seems a poor i= dea
because as (if) the document matures the meaning will change and then we ha= ve to
ask whether the code point applies to the early version or the more mature<= br> version.

A

> -----Original Message-----
> From: John G. Scudder [mailto:jgs@j= uniper.net]
> Sent: 15 July 2017 16:42
> To: idr@ietf.org
> Cc: hannes@rtbrick.com; adrian@olddog.co.uk
> Subject: allocation policy for BGP-LS registries
>
> Hi All,
>
> You may have noticed that I just sent out a few emails scolding author= s for
> squatting on code points in the "BGP-LS Node Descriptor, Link Des= criptor,
Prefix
> Descriptor, and Attribute TLVs" registry. This is one of the thin= gs I least
enjoy
> doing.
>
> I notice that all of the BGP-LS registries have the "Specificatio= n Required"
policy.
> Experience shows this tends to invite such behavior. I further notice = that
three of
> these registries are for 16-bit spaces (BGP-LS Protocol-IDs is an 8-bi= t
space).
>
> I'd like to invite discussion about whether the WG thinks we shoul= d convert
the
> three 16-bit registries to First Come First Served (FCFS).
>
> For those unfamiliar with the respective allocation policies, all the = gory
details are
> in RFC 5226, but for our purposes "Specification Required" i= s almost the same
as
> requiring an RFC in order for the code point to be issued. By contrast= , FCFS
allows
> anyone to get a code point at any time with minimum effort. While ther= e are
> some drawbacks to FCFS, the major advantage is that there is minimum > impediment to coordinating implementations in an organized and discipl= ined
> way.
>
> Hannes and Adrian in the cc because they're the "designated e= xperts" on those
> registries.
>
> If the WG wants to make this change, someone would need to write a dra= ft to do
> so. Such drafts can be very short, see for example
> https://tools.ietf.org/html/rfc7803 (this is just t= he first one I came
across). It
> would be great to see someone volunteer for this work. (Perhaps someon= e who
> has been eager to take the shortcut of "suggesting" code poi= nts, hint hint?)
>
> Thanks,
>
> --John=3D

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

--f403045fe3ec50c2e9055460438c-- From nobody Sat Jul 15 12:39:09 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38489128990 for ; Sat, 15 Jul 2017 12:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-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=juniper.net 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 8HSHcnwHOel3 for ; Sat, 15 Jul 2017 12:39:04 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0112.outbound.protection.outlook.com [104.47.38.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84DD7126D46 for ; Sat, 15 Jul 2017 12:39:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1JXvzSzNEZTNpjssC+6UzMATLoTDsFLrC34aCn+5W7M=; b=HSOYczfDDwSEWM2eiMLblrYe7+2soEO2vkDS4qCk5jMeX8cc5XPTyCn89D5lwvfJKtLMLucJFTp1//p77DaDqv3S7DuA7C0JKoBXUQDgozWw4L30MiVfHsB3L+vGMiFOMviIpKEqp3VVPrrn9hL6p8Z5c3N9p5WTqzj9kgTUfM0= Authentication-Results: raszuk.net; dkim=none (message not signed) header.d=none;raszuk.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.66.35] (193.110.55.12) by CO2PR05MB2502.namprd05.prod.outlook.com (10.166.95.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Sat, 15 Jul 2017 19:39:01 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_ECA3981E-28DA-4947-9F22-6E43BD76C220" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: Date: Sat, 15 Jul 2017 22:38:53 +0300 Cc: Adrian Farrel , idr wg , Hannes Gredler Message-Id: <1317FF86-1D38-4A36-9177-F4CB440AE4C6@juniper.net> References: <5436099D-D57A-4D29-A744-0E8A3572845F@juniper.net> <05db01d2fd9b$6df64520$49e2cf60$@olddog.co.uk> To: Robert Raszuk X-Mailer: Apple Mail (2.3124) X-Originating-IP: [193.110.55.12] X-ClientProxiedBy: BN6PR11CA0030.namprd11.prod.outlook.com (10.173.25.16) To CO2PR05MB2502.namprd05.prod.outlook.com (10.166.95.148) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d6e92997-3d75-420e-9dd8-08d4cbb925b8 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(48565401081)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CO2PR05MB2502; X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2502; 3:97cnuB6HLLeQuJxzAbo1mVh4bHs7AoT3wyvk5cV+swh+JMG7ZEkvQO7OYLNkHA+zgxiZA/GH4VyNI8QRRAAB3KdKAY2d8sgcMQDSa/CWJkf/Cqmj2Byo7FzrwB3+sVsMP7F3dUhU011yuXlqo7l3QfdPQZiHmPGVdwk74QYRRo24d3DPfpJ8bXyfvLOKImvCe7NR0O8mP+6qQQ0huTVhIIzvVb1IsC0eP3xpGSACRR0JvrVq+GN2+YMMJv1G32TOIrKEgo1v1Exfi7o7l7pnn0qMmRcCzNBXlithwnIQFnQvFL+2f9QMOIiFIbPR0wWrm7eLEFpIrizHV/DNVzvYQNaOdNJLUaq4VGZ89NQHb09A3NxNcCYzqImTQjCaDMkPYJeUmFuBOduuReOceD+sar4t0Wl+/A4P6edjJGnkf2u0zRICcKdBi6Pv+ejLavfascyqtS0MmRSzHf+G6fuK/NiWKLY3m4Qik6dhK7BN1vAjBNpEA9Q2C8q54LipO1v57eL9mtoTZXhwsaS2yGsuoJwbnBkxM5KwjP2y/hMzzd6SoYzY2DBavT1WaawrT2+A3vUdBv/CcAW4kVVbCXuD6m0FTTu8Py72MbFKG5el7dV9XrtHkB73Pm/qyReq5lU3bDQm+KmeEvK5ESkIu6SUNiPmlfZTC2y4Ixz2opWB2ykDuQGh6gpw/3xf9fPYpYFSIaLRJnpIzZjIMPgwdmjfnWKqyxQMJEPqmKZtTZgVuRJ2C8aY9UougrF7dyDtLOVWzX7B7pOcCw4iyA8+Jty+Gw== X-MS-TrafficTypeDiagnostic: CO2PR05MB2502: X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2502; 25:xIlBHjteIjGp9x9N1/gD2dmB1iyVX5LKQ+h5Uv5UMeiLTOBvCCr73GEphlL4zj8WF6Ab/4T4RxY/WazAoteXrQuIgn/w4lFoC/IH0FwIsUbZfzdTAZjfoESq3yuoNcCVB29XlYhUprqO51nlbTwuKp3gsIR+IO+iGj24DcwQnJ+G/A7EIOifNU0XFfP4GgCcBO7Kc5eMLheJTkODGlW9CPNa3ELI3EXr8rJpXyPZw/gna6sraY2dyOKLfIsNT+VJ5YzGtCwTEEkStiHIkEXEBt92J1BeK10sGyct8l016Q5fDk4eSJtYlUpoJK5bkUUBYC6qJmvk9yORnzy24pwi8fjD/MCVNSUMQ78ljeJx4YaZt8juqVlLYaTwCJVIIncsIfKyvN8fGLa1cp1M7FVsQIOOpQYOnBx0YXqdiTzdNp6XtDsFziqpSL2GXDwtfT2Q3jFR2xGwM+1I6jU0kG4UG6Gpv+OePK8hQv7zUjozRmXyVUYc4dwz+B68An+DSSxb39DSwB77yrebKJyL9uxQ8rtv/h8cvQ49FC6twQM+IpWTpchEMtV/0YGm9XTuPBWzPzk4Ft48PnKIHBTY4ThZaHchcgYl19iRn79jb6Gew8BjPIBHZEXpin51ACpQ0hxs1IRbq57BNYDJailnXZDIDrURd7eFoBHYjmC6kYrjvIaaRg7PWfgjqcJkhb/P294PO0EshIluSLermGKbfCWhMai86HD2YwILrRw0wi4zgbsBd/F+6RZIxZ4VemVxxhCtD22IIMson7CqQkjDnYfNE00GoeKF7ik/AmG6MG7ilKHZ4kDfkcnxjcCjCnI4r6tdaJ+0BKnfkrUplJRnSNSHR1t/xAU0HDmDjtw9WbiHC/zheEJQOZ2jJ6XyCmrC+sWIluzJ7aStC2De879bVGIPX/NFSFYWX11tMij4SyOL5o8= X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2502; 31:2+7aQG9iMrhBWPGTkLOlaHIuRnGL6gFT/bhHY8glc2OCQN5gnxKhNm92/++RgOeje54ic4YpH6q6gAgzwV8PKU3kuuoSx0vXl7mQBaEL57rPLpSMP9h/rUCPfoIgGtpOGW1FVEfZOR9xxVsHtgBYUIZ3kfGJChaBELUk/3wKcDpdqp7kCSNWps3agkg+B674YLm/sdzs0K7XvPrgdZo6c22ey3069a8UtEufx0/lurBhh5nZV+cGG9SUiOyv9TalYVglkv8yNJZooLVtZ9gO97FBIyTYP+UqA42zDpGOSHJjFbc/QMKM/EcxQ0uLycaYlz17FzYu/UHFWTzACT+OvLS1ffz4v/OORoxc9LyhE4fwnyyYUMmtewowhtX5JR788a3Z2XmJNPmUZDaYGYJ2IZqa9N/TLG/fKT2oPcb4njKBZ1HZeL+CjMfqb0kXtTeE2Mk/eYqkyCYUAxTApDh/av3tfFeTYKNAF7lT9HeNiy7Dp0t+SjkckCxYISZURO//bOx9b3O4HWq6k3bl8LIG6Nsi1MhjxO9hZ6gQZoHVlHSXvo65h9E+4763ucjgoMkd5AVWs0ocAfMnDE3RLsWcbzawmVrA3uCDZVC/z5u/P3lcBAE45zBeQgdcIr6+zMHv+T9L7wgdFwCwcIrDqYi9ueKlM+aCctsdLgdBd0tISXjKCSbe+XO121CXVomkkw/JOBiej1CwHRU4j5yWNmJiEA== X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2502; 20:fVBvvmCMzQFhSHT6gDlbeYx4X2UcEAHL3CjgadazP5xlHL9v15amT1kHJYZG5eqZHNCSiEMdtKOoJWWn62XkeGhhHvbOD8jT2oKBwn+d/KJ3xcXQvdhuIBrv32QUADtWty8Lt4PHvzCjJb48FFzmHD/38Q6XTbAR1K50duZHr7mZPi/cgQZeiBEIhCwEL5s9+M2StkIFrYeTot9X+26Nth1cIermLtBGxAiqrq6QK9a6AdFqVI/BYg+kdaZN9irRD5t0xtqhFRTJW1X1PSt3+3CULBNuswlUCp9lKZAWdmZ+6JhaPviMQZoKXcTCz8qtJj6zZn9IjQqNR9keNGxYPnXvbH4Z3XaupyonBOGJtXGDqi3dQHp92vBAVZBXfZEtwyKf8yC7dbtCG7pwGgZwx9UQNWgqHAJipd2/ZyOX0OcWvS1PBHD/CB1dkkIkXpxiCJ31IkFFOv1fwjeJbAEtb/Ty3r25gKdxXltSuPIITjWd62EDnSa3mmZ6vL+hZOJU X-Exchange-Antispam-Report-Test: UriScan:(236129657087228)(50300203121483); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(2017060910075)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CO2PR05MB2502; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CO2PR05MB2502; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO2PR05MB2502; 4:BLvqwCbWEp7cV9IoEdC2m9brMtI1l1gQr1upzSTMAj?= =?us-ascii?Q?5wHexx/BmBalZWT5pBoM9HvEtA3KrV97O9nFidqo6uN4eiXZJ24UULUItdv2?= =?us-ascii?Q?zrPvRbSjp5assqQrzTzWuUr0yhMjp332zHI38WoxxSkk/YpdwUPTAKk9xSel?= =?us-ascii?Q?FvIw8GfXk2d1L9N3mHlAqoCXh8U8CDMctpCfmZ4LrAXZ6NbTP+fCjUkKTPUV?= =?us-ascii?Q?he1mCgNylP3rNI2z1HpXtY78WX2lZPEj4jpr/sx2kukd3BJv6B5EqCEEyd6z?= =?us-ascii?Q?l7DImuxA3oaseWJgIKkyAZpUx9mVn+kCqZM+kb62wDkxKRCUHlvN6ebMSWC2?= =?us-ascii?Q?7RqyIFxX2h57OK2wAxeTkB5UAL+jpex/nwPccH+13JUFVg7WzmjiLzFi80ja?= =?us-ascii?Q?5BKDWZ/jzXpx+Cnpu5Dr4PXNIVEdpV39QtWIq2kuU++dePjzAhKFXgt2OCYz?= =?us-ascii?Q?kktJnsSwLE9874IX7pjdMHaNrdvK+E7WFF4nzP4//Lf4cIrRjrcVVNz5BG++?= =?us-ascii?Q?3qRvedko2svCrmYnOrrhpsJqNvkmo2HeRLvW11Lonqt+4I6SwXWqmr6UG12r?= =?us-ascii?Q?LtGV93cqBux/KUNUzb5LP2urFh9+VS4sZrcRIuxh/wVlottMZtcInvAQ3IR7?= =?us-ascii?Q?/tYj7P+EWHPdOjtCzsOa2fsP8PFgBuz5HATgPCWDjGC5y+Kv7w5/Vr7bSfZ+?= =?us-ascii?Q?6btsmFVjF3U5j1eZ6lNpnbMgeJBckD4nltU1b9oIswWnt9CCsHGG8+6kwj0c?= =?us-ascii?Q?i31Imobw7Gv1d8vzH2DJNf+6ZrczkkmCEeMVlk00pqDt6VdhTVKmTSP88sn+?= =?us-ascii?Q?+49UdNhlmzCfLPa5VpVPRYqFrwTijuoFQhfrSsth3T+iD5Q49MzwCwSRG2ef?= =?us-ascii?Q?0bPioUxtmoztTN6bDNK4RboUayPa3QnbAsefdasYabS2GRs6BLqgjyJcM2uj?= =?us-ascii?Q?QsYARiNYsAAjkS9McLvq6vNwiMWGy1tuhx3kmFunVJ+ScwXLlwLkEhG3a+0E?= =?us-ascii?Q?E11xfpkw32OeuzYCCuzwqrcO7U/vsYDZhls8vgfoyqnOYgByG+ZiYmPjq0Gb?= =?us-ascii?Q?jAdEO9PJsJSPATBGO8x+487oOYZTzc363bV9YtoP8Pv162iPGFl3BP3zc9Cn?= =?us-ascii?Q?1BR8Y+d9oXF1ET66xqgRvhdTa58fGYZDYtVlPCxacXRuCY7tntpkuTRFp9kr?= =?us-ascii?Q?Dqn2Wn2iWaDzjdJcoa/RYCNIKTYCK3D09ySIKmeZbJ4jUg8KX5KAD0hWu8Ae?= =?us-ascii?Q?g9kPXho/Wlx6BBvXrh5vTTnFS/skxdYlkTlf3Z?= X-Forefront-PRVS: 0369E8196C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(7370300001)(6049001)(39400400002)(39840400002)(39860400002)(39450400003)(39410400002)(39850400002)(377454003)(24454002)(66066001)(6246003)(110136004)(38730400002)(42186005)(4326008)(189998001)(77096006)(36756003)(83716003)(7350300001)(84326002)(53936002)(50986999)(82746002)(229853002)(6486002)(76176999)(7736002)(53546010)(33656002)(6916009)(86362001)(8676002)(6666003)(81166006)(6116002)(3846002)(57306001)(236005)(2950100002)(2906002)(54906002)(25786009)(478600001)(50226002)(5660300001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2502; H:[172.29.66.35]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO2PR05MB2502; 23:7FwtQ4J3Sg9VoreVNV8xC1FDIJgst3gXEky0VqOn3?= =?us-ascii?Q?CTJiGwSyqPO0tUdevBa9nsInNKNgYPOQZQnlFtatpSgRtvX6yUPhluWKxeTy?= =?us-ascii?Q?JS3oY1JL0qc8za3tnXEEgNjgl5mo8TCC5WJbEWH+8J+Ytj+MwZQCwaaH4Ucu?= =?us-ascii?Q?9V66oAXSPAh7WnOV0uEiuSNaiPLO+X6XVkgG6toig3LOmNzkp8O/r64JEggo?= =?us-ascii?Q?dWVNB+Ljy2h5eaT9V807SK1a8s86kR0qA69gNsT5B9Inq7D91F4/60pXnPe+?= =?us-ascii?Q?BdDhNSZ4LuOPfId0ndInpST+nCbxqSm70sCjCvVQTHSnKzOWecHPs/22wASS?= =?us-ascii?Q?52qEcDN4oUBa0aPr3erQg8APG6iPFKLbYDgxWg3f8756U7meVgjTicFhcUtn?= =?us-ascii?Q?EGofJCeP+oSpBFI8yS2Sx5/JXYcBprZvCbBl0LLi+dZJrjyaoNbQ9668PjNg?= =?us-ascii?Q?a21eIbNmZe2e9qQl7H4SVRjwmTX/phJG2j6Dq3BwbUyHipr0N1QMzl95oXyo?= =?us-ascii?Q?9fhZWa4aFRhbyXgZWcKELhxYNOkRPaHzFSweHJZ2dUwxHh+gXxVYrjKqURl3?= =?us-ascii?Q?lJzNKl/jElzys7rcKh4NR19dUgFehTph7leEizAmAiJuKm3oQexfW5lTZmSQ?= =?us-ascii?Q?Et8JN09BC9/GNTEnpbTaqrle8JX3uCDLXMjVYa9NVLmOeF1geeJVzr+zz58S?= =?us-ascii?Q?P6Ljieu4o/y8k8giVEN4scsmhn2Vd8BWGVeH9cuMRqa/8ScB52/4egn5igEB?= =?us-ascii?Q?2d+snMy9rLwS3CFlGASNftDqVQknNwgPsVeU8Ri5OaIKBJe1BqI4FfM4H0OI?= =?us-ascii?Q?s4UTX5ZvZTynhJSHFJBHZrG6XWH4XeiYJRkhJFnk/3uVlxbzZtseCDC1tTS/?= =?us-ascii?Q?CfK4pMsiS5EPjhondHIX6KCxUW/4XZApj+5ad16FMGrWEjvUVXgJqwZMaJkH?= =?us-ascii?Q?uoXzbMg1x9UiDRvlrBt/2oqMQv2+bT2uKhirjhyiXXy6H4oDi3SxMxx+XbIl?= =?us-ascii?Q?Ekp1wlwP30ozuLqfFTGyw3l5Z5Br4UvLbLXQXj1Hlsj+jLimHpG2oCO1x8Ja?= =?us-ascii?Q?lLQFa5brmAe02TLnWY+FuESeLFbQJEtrPgpWzThCoXcosukcXnQ6qIG+ovFX?= =?us-ascii?Q?lUG/+aTVPgoCu1SNDTPTb7IRCT+riTF4ryJSyPoCAYnn/H+XTjRRWMv/nldU?= =?us-ascii?Q?0xgOASZBVE1lkBCUwZla6z+AoAVyc/5DOs+tdGSBWKPpZONvX0P0XbB2w=3D?= =?us-ascii?Q?=3D?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO2PR05MB2502; 6:d6TxEWjjD9O8BNtnpY+McjXM+CSzKO+3lsCttZL2F0?= =?us-ascii?Q?ZFQ1ByLRH+ypT3kDi3nPTn6KRlcPVEmES9XvOdGCiEeBCVXPBw4gekiXleYn?= =?us-ascii?Q?eTvEyiJb6WG3hHva7VJFVk4tC1md5aIN45ASfbmgmHhi+x3zJyqK4JNlw3O5?= =?us-ascii?Q?PWmmj2GHQYhclfT/a8IbQUsOGFH6J9XQHM22GQz2/duBWHKyAXZepmsjUXz+?= =?us-ascii?Q?AoRbiT1scXg2MHc70S33nlZD8pWWS/Xfc4nPSayuimQ24QXvAyIAyTSlRhcL?= =?us-ascii?Q?ql+0uT5s27WR62T1pjbfokyFX2ACywXkIvcRgGqO+yRtgK8bOwvLGxWw3tDW?= =?us-ascii?Q?pXSwd29MgsqqPULs1YMaKRbmUtf/rMkwHA0eHDYHtBfPiHIavtjI6uMMjF3x?= =?us-ascii?Q?be6YeTWH/cr02wOgnkDGqAR9b2NAnrIbDBAezjWP8aVQcvl1mjuC6PLau2Bf?= =?us-ascii?Q?30XAuOR81Q86C/M/qEPB8Uru5wQPOsrIUlMes3EhuGNrQSZDO42bTEzsvELH?= =?us-ascii?Q?BaQrDb0Juta/hyfNXBMIuTVX5PAB1KtxaWyk8795oBHJcQSKe5DBC03XTCNM?= =?us-ascii?Q?ynpgRLoAC+ERBMAwvDDDAxnNHiwF+69pIW7xEozUuBEel2EaTo9Wb7x44oQJ?= =?us-ascii?Q?IG8RiZFb4KcjJj17RhmBXf3b+cJzbLfbCEMGj3TCqcvDVuEIY+QwBKX5KZjG?= =?us-ascii?Q?/tZJnROp3IiAA7QoJzv8VZppiYm8U2ICBuVYKOnz1dZN9ZgeIMkO2TBRsqcw?= =?us-ascii?Q?IDeHCBOGmPHY2uqgosD3NqroqszzRvhVCOcpOqfN+3VI291frAbhw2q98JIL?= =?us-ascii?Q?JEY7ZaejY7ji/V4LnJ7a7+Zv5C3+HjE+GYqzR6YqayR0jzqQjeAMdH3RtBuR?= =?us-ascii?Q?8riW/YcX4L5DN6r8GQ7JuIASQ2ov3jfgmz/kauB6PrZWNcU2uxIKuxW/QxmR?= =?us-ascii?Q?DekCP6VKD7znRS6XjjzyTRJ6/nd6xf0iP9mkSN5iqeQ7gUKu7e6umOBaaZlo?= =?us-ascii?Q?FtLrtpPHVAN0xZzMZ1FEov?= X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2502; 5:h6xjRGLFUKT4jgbFiTvWk6OplfWXCNfeNq5zssp8yCwOhyaqmfx6PzO7E+bHsDqKSet/WvGpVDFOqIhyzgmAW9sycrm5GGR3SZMFbwT8LNRIkVEUOlwfTjRhT2LxngxQIyw9nx4JBo/FbIQlAwGpPtIbWSsmJip3LC1zc1SJhbjWhKZ4/IivAOuDXfxkmT5uoR9dJ4vCx/Gw/zEYL1fBsjqMRmd0HVvHSSzPOqQRVWdVNN/wk5BJVfBhUXGh91HYoJS6OZwa+Nxl/+Q4GwTH3iUSetag/swm47huNFCtHVP+v5MNtT0Ke7ZP1utrJ97K15VecryJ8tmKr0WYo9Iao+RvzMizWgBViQg8AZb5bhQe/tBzv34DkaO1xPhQ8U9pzjkuj74CT4e26lBueO/PBqrW1hYhs4issr9Z/9pnlvIyFkmpA6YP+v/g3pxp6LINqdscH/hk9c6fTQh886vGbSLLZR4EVQ8qnDznjaVFIjcrTgAIp4SWIyi4htvfX9nO; 24:94qtj9xwtzCiGtYfrij2PYfDCrwRLVaXAFQYfMoIo5c6is2LIE0eKpuGgdWoAhdSb2y3jgNslPBtdsTfUokV25DDB89IQTkI7TTtCW/9ZzI= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2502; 7:NtTDSQT5ZMGEKMZahAXmVEG20a+JEEABdcdEC6RGODU5MEkWJ5HEULED47DW+bcfrbpUBh+U4Waam1ANrH8cXqGbyOyVJi3mJxnzGbfbANFydnq/llbi5loVFyvfJNOQJmUfTYkEf9m7Z69X07qRepSUTIjdB+niw3ustfafNO3l0ZpZhzCLLwKBf2rHgMnIeGWhMakOFIJG8sSX/Sy8zuPXnGxvU3ggICOzwC/zRkr0sboZeC68R71QdiXImP1GqnuQgFY//j6dAdgbNeYSVgntcUTD53qopugqbn+UTxV28v0iCYpbRHUHVbYAPYSZ2YYuna+rhZjyz/x/f2nAuXD2EUJzh8TC8Tzi/RNXZwE7UkmR8wdp5BRwepuipfTCl3V6OkJCs1phgN3XuRhnikgfgQNebWz2Qz9j5TdZ5dYi1pB5dum1JgTQuKVLwiN/6FEwoPsrD6OsNWKEv/tsYclSTlpmq3ZjnuPYq/25byh7kdxZOo4HYxrsfcm8EPHZvL3oVRNDhHxJi5Ynya21WILREbjmZ7c9F8SQB0K2wC7TbJGgUDNPUsA+FcYLWPXarXU1GnWVtTTQhgu2l4NC06ibWenq2tqJW6RCNKZlI/TMktD9HgrI/InMNsLUOg0HLFx17xy75lTIPCS2XDaON2JjsRlWowNyIMKZTQnzVshtoUZGLVbtVhTwSqA/o9s5UoZ2J29hhS0at7xauPlZHADO2/9A7+yDzSmwyYH651yPM6Z+jWa/I0si8QR3guvrm4166a7BZU2ou6a0yvWRIEY5QlCoxY0U2iZBKgJzIrE= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jul 2017 19:39:01.0357 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2502 Archived-At: Subject: Re: [Idr] allocation policy for BGP-LS registries X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 19:39:07 -0000 --Apple-Mail=_ECA3981E-28DA-4947-9F22-6E43BD76C220 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 15, 2017, at 10:35 PM, Robert Raszuk wrote: >=20 > So IMHO the only effective way to avoid the mess (in = parallel/orthogonal to current early allocation procedure) is an IDR = wiki page where those who want could just log-in and put their = "temporarily borrowed" code points for their prototypes bearing in mind = that later IANA could honor it or not.=20 How would this be different from FCFS allocation by IANA? --John --Apple-Mail=_ECA3981E-28DA-4947-9F22-6E43BD76C220 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Jul 15, 2017, at 10:35 PM, Robert Raszuk <robert@raszuk.net> = wrote:

So IMHO = the only effective way to avoid the mess (in parallel/orthogonal to = current early allocation procedure) is an IDR wiki page where those who = want could just log-in and put their "temporarily borrowed" code points = for their prototypes bearing in mind that later IANA could honor it or = not. 

How would = this be different from FCFS allocation by IANA?

--John

= --Apple-Mail=_ECA3981E-28DA-4947-9F22-6E43BD76C220-- From nobody Sat Jul 15 12:50:39 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2614A128B8F for ; Sat, 15 Jul 2017 12:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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 HiazfEKhuiiy for ; Sat, 15 Jul 2017 12:50:37 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::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 E08051270A7 for ; Sat, 15 Jul 2017 12:50:36 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id 123so9999257pgd.3 for ; Sat, 15 Jul 2017 12:50:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=5ZDtax62jLiuvjvLqFhWQ/SjsMRvncjxqnDn8y0qiFc=; b=eX05JJ4A3hi9D9/OvGbtz3BxCLYnhqPDPISQii+4K5OoG0dYpTLZthAwPWxPtkOG8+ xBuOnmFfMLrcm/4wsbFZ0BtecuquVuTOpsS7/sKLeOXVgNrW4gLWzN7XSu1ENIEJji8K auyuoI0olzWjqEQgGM6K0VZ0aLg+ntkPINcPeK7FUAI8TtbjEZgQ3qW4d9UV80quqND8 NgmK/6bj5Eb+wcmljJOF91ZXKdGv3nW4zn6Fi0o3cDw1XhHU30TXzuDghAb9+S8GBCnq Axx/0WZi1n7K8pRKfnluxFvCxoDy7mFvoDXSb+LunWMHW+SPh2sR6+nxplTJNpZzVnqV ydsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=5ZDtax62jLiuvjvLqFhWQ/SjsMRvncjxqnDn8y0qiFc=; b=k13gqlyP/hO5eXEr6LkIH+moXOuWKfhpqB8WzyiWmwlZbTYRfobu8ys8Gn3ooVBq5E D2l1Rjxkhoy38Kj8/t5Co/COp2qHY71tPtOg2ThDge87AU6Ikl1UtgBJHRLsFY7KoTMP M5VVvjk6Tytw+4EtmASkmpAFRpYms9omhf2bM9FgtIwJISTKBqAQPVGOI54FZg5MM3kg Zb1XjtJfHeGaWt8UEmo3Xltf8FUobviXU16i0C/DcKDR2IaOoSSyrBrZ1Cmw7RVBPtnR Hi6srtVRmlyP7qRJZtXbLBpSq35PqJFp2vpsjmT6FFmLDiPnqRxFoRC1C8fMNlY6I/s2 oEXA== X-Gm-Message-State: AIVw112JFj6uvwPUMUGNc7GDwZy/Jp7H944FS32sEY/YXBjWL9536xFw hodhyjF8GnYQgaafqkYQDWGiQXfL2XRH7VM= X-Received: by 10.84.248.10 with SMTP id p10mr22040398pll.89.1500148236365; Sat, 15 Jul 2017 12:50:36 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.100.163.98 with HTTP; Sat, 15 Jul 2017 12:50:35 -0700 (PDT) In-Reply-To: <1317FF86-1D38-4A36-9177-F4CB440AE4C6@juniper.net> References: <5436099D-D57A-4D29-A744-0E8A3572845F@juniper.net> <05db01d2fd9b$6df64520$49e2cf60$@olddog.co.uk> <1317FF86-1D38-4A36-9177-F4CB440AE4C6@juniper.net> From: Robert Raszuk Date: Sat, 15 Jul 2017 21:50:35 +0200 X-Google-Sender-Auth: Ipg9LsDMeZI8nDEfTkgoNtST0B4 Message-ID: To: "John G. Scudder" Cc: Adrian Farrel , idr wg , Hannes Gredler Content-Type: multipart/alternative; boundary="f403045fe3ecbd341d0554607a3b" Archived-At: Subject: Re: [Idr] allocation policy for BGP-LS registries X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 19:50:38 -0000 --f403045fe3ecbd341d0554607a3b Content-Type: text/plain; charset="UTF-8" John, For one IANA requires some document to do any allocation isn't it ? When you come up with an idea and are coding it there is no IETF draft for it for a long time. Second where in IANA registers there if FCFS space for say new attribute type, bgp error codes & sub-codes? Thx, R. On Sat, Jul 15, 2017 at 9:38 PM, John G. Scudder wrote: > On Jul 15, 2017, at 10:35 PM, Robert Raszuk wrote: > > > So IMHO the only effective way to avoid the mess (in parallel/orthogonal > to current early allocation procedure) is an IDR wiki page where those who > want could just log-in and put their "temporarily borrowed" code points for > their prototypes bearing in mind that later IANA could honor it or not. > > > How would this be different from FCFS allocation by IANA? > > --John > > --f403045fe3ecbd341d0554607a3b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
John,

For one IANA requires some document to do any allocatio= n isn't it ? When you come up with an idea and are coding it there is n= o IETF draft for it for a long time.=C2=A0

Second where in IANA registers there if FCFS space for= say new attribute type, bgp error codes & sub-codes?

Thx,
R.




On Sat, Jul 15, 2017 at 9:38 PM, John G. Scudde= r <jgs@juniper.net> wrote:
<= div style=3D"word-wrap:break-word">On Jul 15, 2017, at 10:= 35 PM, Robert Raszuk <robert@raszuk.net> wrote:
So IMHO the only effective way to avoid the= mess (in parallel/orthogonal to current early allocation procedure) is an = IDR wiki page where those who want could just log-in and put their "te= mporarily borrowed" code points for their prototypes bearing in mind t= hat later IANA could honor it or not.=C2=A0

How would this be different from FCFS allocation by IANA?

--Joh= n


--f403045fe3ecbd341d0554607a3b-- From nobody Sat Jul 15 13:09:03 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB187129ABE for ; Sat, 15 Jul 2017 13:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-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=juniper.net 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 64j193RHBhdV for ; Sat, 15 Jul 2017 13:08:59 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0135.outbound.protection.outlook.com [104.47.33.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86E0E12942F for ; Sat, 15 Jul 2017 13:08:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nYtY84JMsW5HnNGZQvgMnRY8LT+twEH9BatkkUTMRTg=; b=ZozUoubb/NOGvRGQX9xw5hJVqGL3jZI0KSV8ymTMGd5D682Njz+BtXQnr0hWiePD4/MFzFT8GdOxjPOnwy6IaBkhME8GHaIN3rQ+niJuKQ1IYV5DrAnKQEGfIv8mirjkkfFdJuIczC4zjZQfnfAKxk85GycILtC+U1BitT1RKX8= Authentication-Results: raszuk.net; dkim=none (message not signed) header.d=none;raszuk.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.66.35] (193.110.55.12) by CY1PR05MB2507.namprd05.prod.outlook.com (10.167.10.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Sat, 15 Jul 2017 20:08:56 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: Date: Sat, 15 Jul 2017 23:08:48 +0300 Cc: Adrian Farrel , idr wg , Hannes Gredler Content-Transfer-Encoding: quoted-printable Message-Id: References: <5436099D-D57A-4D29-A744-0E8A3572845F@juniper.net> <05db01d2fd9b$6df64520$49e2cf60$@olddog.co.uk> <1317FF86-1D38-4A36-9177-F4CB440AE4C6@juniper.net> To: Robert Raszuk X-Mailer: Apple Mail (2.3124) X-Originating-IP: [193.110.55.12] X-ClientProxiedBy: BN6PR0101CA0030.prod.exchangelabs.com (10.174.85.43) To CY1PR05MB2507.namprd05.prod.outlook.com (10.167.10.134) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c0e3026f-1451-40b6-6ef5-08d4cbbd53b3 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(48565401081)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY1PR05MB2507; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 3:y+Ojmo5oJtfChD5pROnV1xNO866kXTi/zRpXTTaQxvheQlNU/RpRPBVe4rtG/Z91H4EKrbGKMDwR8qFRep4VcMA+ipbhi1mjce/yGvfLtoHgYhwlKeOWPLrg3gxvN2dxyUL/phCxpqixUNmwEAB8098czxTQWMZ5EurxtCdZHS1TZe62sw81ULx0zPQueYX4shd3bnca8O73ZlU+MXCOwH9Tm7baINlr64nFMH04MppVUzyPua7Q1N4C1TQTfQM3NREx6toQGP7Ru8TStH6o7GwwnLqEEizUWfFvSGH3xYTjgOaaVKwpw5Td/tFJ+Axcan8Mjl044bhYqGfvoH9b1zfvBHD7V65EJ3UHCYFXYkPLrRcPNUs1/xbLLUpx8qB6KoR/5DpkkSBbr8dLR1YbLXB1qCwXkLSwzmtET2VE6us8cuEQwsI/NosTrvZF+nj3JTUtSrLwVK2jVoh1C4aUPuSoLiaJrc6YL50MQUA4Pn8/03tPYc2uM+WIxO1OG2oMr8tva09MGBM+dVQRdXZ97I/sZrsc3zFLsqRmrn2+DxFmSksRk3tB4fj4NslM1GRO4o4XXqMiH3MTjpYd5BsaXAthwcE2SXz0Na8Ea4acXH7K+6tg3EwEe7wSwoi0omZrTigWQTjfQYv26URVDu6xdmYt3NqQ7dZBFRCp7nKDodpNsYWXO53Lj+lXHc+MHyUt2fXLXtl5QVhx9gqUfSKgS+XsHIrwpDJ+Jbh91z+80tRyiyJWAitZbg9VlJsWRf0MQNx7qEGH/qhYoh+7n2KIeg== X-MS-TrafficTypeDiagnostic: CY1PR05MB2507: X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 25:1WlhemWBuTEijaqOR60FbOgC0JKFVgWbrlwR7kXnTqDreS7oLqBeQeSqJjXypWeS75BDoSr4Sdlid/3VgmHihxeKFNWk9Rl4n6GQ3VXvUmDvv4BD481JN/zw6PxZFp56CThfCEn8xkvyYatU2Isccok7a9ggfzw6FBRBrMXYPINSzbGO+qJh1heTSkyaNlCwV8I8dVDFHiSQUcEYJx3c+QIjgSigCANFsaqIEyqoF5onFFaWko71DotBPcX03ozHJlz1rU5Y6phDvp7/HhsQ1/ixNUVwXselffDjK3TeZlfNkvscWP6KqpLT1EfUbg0a4f/YgO3faWTeaA8npUc/gDAasaumFb5wfjiJFTHLpsE2Hb9nMeyoixRCs/aWuT440FtkN9tnhSlxnFnIzwGTRxP/D1rpg9bMfI9Rmjn2AIXjMRq6vOefC7lyjOvqhjAwf6R5T/e6U7EjYOHsfW/dEXOwbyFhjyChN+tT4Oh1PJrZetAGZ5qTwhARkxUmGhhmJUxMmnJvDGe0OAL4NhmVDANVOoYnVmi8i7K8tM07iMgVWTiQK8pqznbt+G4cTLbbZ+2+G7ZvntlAtuPHLCETUhE7pVnVsv3+tXhcQfO0S/dsPzjOKdXmlyCqCn5ejtJ0gaK+RFFRy7hLfrwNpqaewWSVJbrDMBVe5iso2RQ8A8HEcjGpSmrq/Pju+7FIAmlS5ve8arXAVan+77xeIVjnYUEGSH3SOYjdwqODbzKAkZsFgY/UQSaU1AINswceOSSAvcUfdHt5NmWipVoQ3TqJ3jJwRFNr6Bl6/iFf0k40a/Yv6X8krji7iDeDLyCI2zGBHvnhOfUdJ/Ws0b5w6bkqtG1nU4m1j7LTH1BSbiR1kGdcU7AkucQVsgm5mMabMST+sjsKcolS88ImtoMiLdqcN3RUu8R/hkFDGlJ5U06Z+LY= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 31:2tBBH1MueUYaAVl72y2Jff7u6TEMIcKjmsKZTFnVKAQuC9YvZI3LctVLvsdbTHBT/84msxVd8yn2jXDBvsfKlaTSPze9rbEGCXS8xP9XvPTzrtrI5qCltwiZ40IDBPPqIYr4dmanCZU81wPXMBxdp1GNJ4sH7IrC9uPEo1Utd2aAfMTzIZb/6sbSSqZcp6mMbnWtN6ynFSgEObJ9zIHFeHDzry7eNrgYTOWaSV9tmLsLWheUV6qbiYmRAZEjjjpPMBIjKzbuXRdERS9bMScf2M3MJRmt8LHEBMZ4oRrD1/ha6qPVOSR8CDjuQSSaE0WVrSW5gnqWFDViL5H5Jg8QmBEwYPOlNqZmwBNRFRsY4aCsG+lx73AsPx1eJRcwbgvvUNgcsoI+VZiGqNdign5cuNu5vIeLNOVNKwaZlH2WUEnXnhEt1593g8j25r0IZjMKsY9D1dOAV3uddophdRsAhtQWKCELNFndoBVAiUTYofP4RkZ68z7HlusygL4KBX74dKhwMR+nDviUb5iNfLy77b+MXHQ9lBG/6XXEV1PAtOJvri+AS38N0TAdJ59DOHYeZomIQYmeSqWB2mrf7dUQdwyrx46w2A83jwHB+TPhZz2ns4cMUwp83R2ogFVegv1QMOWIRnRNfkxK0MpKCXc17Gq4Xw8+PBPfGZjDs4u/+f+sU/9bt1H8gVpv3G3dNXBvQLLlLpLWoHcnoI1CgfPC3KXhaGprxLp0vFEBf0TCBZw= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 20:oweFEW6PuKf0iq+xewZwiHSzn93zs8k9kJnssGvOr3kC/qU7j32mFKdY3xxQ8/OzkGHcOf9i90l3JcEY+xKvuHS+LbIcxQeqOm2mvKQhGa9+xcbj7/Tg+7vhXKiQRE2uxzF7ab9BraXJUFXibGRRH39ga+rpPgUD8HKbves7tqelB4/0Tw7TwYFjM0ZVE2uFSQ/ooP7Tc2MYa8cHHSzR5mJrNyFmLbYjiiI1r30jAmY6A5ukvmmrAFK6kkJDtbkuKwb0fGE9TCeEhXsZYUQTrmFzljRoWYLayoWpZVF4HObmZaTgFyg8NKjWEjqXF/01oImnfddnWjq1QDdAN1o9gq4nsbCRJ7B7rJVwkULQ67VKHiieRypb5Pt3hlHQSqFwjw+tgVdyzxJFdOuw3DHT0BTh2rcjX9ZOKEW6Ctnk2jL2mO4u9+STjN2jF62VB+rrBzcnHH+d98ZiW/gtbjPwSPJLW9DXqIVI1n65unNk7EKNPHnSmD/SghkVLJS/EkLB X-Exchange-Antispam-Report-Test: UriScan:(278178393323532)(236129657087228)(100405760836317)(148574349560750)(247924648384137); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(2017060910075)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6055026)(6041248)(20161123560025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR05MB2507; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR05MB2507; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB2507; 4:nvGpZWS1j68t4B0YXZcp/9HWn/UmhAvWh6VC0TulO/?= =?us-ascii?Q?knynj+NZHssauUdSqwRzRn43iENXlSBdBiV/hj66Gx3wihA6CMB3A5Ev55w7?= =?us-ascii?Q?KB8Uszd9bDLkrQnK8qjszYe2dKK2kd1JnfUMQefOI39m8Vod/ZbRia0F1Ne/?= =?us-ascii?Q?Wz145VfaP6XY57Hd0W687nmBIY+CnaC9Yu8sCPqWsoLn98/khYFmKv/fDqk8?= =?us-ascii?Q?NkEgQThO3cw7YFL2mFAEK0wAdADL2sKvnnenAgGEGRXVWPG7djycTl24hx4X?= =?us-ascii?Q?uXxGNhw1i24xkfdnfUapgzjNs5/v9Wcd6Km3yDdbQcbxILmH3u/vYCnnYGJf?= =?us-ascii?Q?ta2ifHBU3PILtXgcqSMMTvT+evWIjR5UtyYjGZ4AvfemncXQXTal1dUhP8UP?= =?us-ascii?Q?EmHoqvEraV4LV6zBFW1gc8tTLPeWNzPNKBlI/n4k5797uToJGfjaJKe6y3WY?= =?us-ascii?Q?YU2drVkGwvt8f7jxz6o5y2qOD3ch9YcQwY3rllLr5Kyusg8x72ONsAiQnjTV?= =?us-ascii?Q?9m2un25/t24dsgkiO3olastKBCFpsBwxhGw5h6dbD5MVsMWm8PWR3Rwr7mPg?= =?us-ascii?Q?OD1jdc3qrbqIkDBIeGODQV4pomsrq0gvEa1GIbviXzhhS/wSbbWYRiAtsTvF?= =?us-ascii?Q?zayzxtbgRHsAbUwYLYYN6XfjVWukAoiVnJYADy0Krc8NjbHoQcnB+tlY8LgV?= =?us-ascii?Q?E+c8uRyaE9hBoHmfEsxgDACuJ+sAvsBYQDtqAgHTAR8Rlq0VTHPlGZ1/xRr+?= =?us-ascii?Q?fiq4zt5aCgfko/3d2CxYEV2kFIAgwCoJq2Qracyl1KPB2TJLYVY0gbVrdjjQ?= =?us-ascii?Q?ILkZ3kCLaH2vXt2mcpy8g5uKP0MzpEho/UVJjJEdW+pyv8oM/BuUvMTfAiZA?= =?us-ascii?Q?O7phR8IXeyItkk1Y49wAHO34GoEjAx1TlDJrwi0pJpsONDbPE2gV4qdUpjlM?= =?us-ascii?Q?E7fMVbeGpCOkPo53TX25EVcJVKe5p+4wySJhqP30Qkq/v/8h4r+INd2Pb4PA?= =?us-ascii?Q?5k72d+fKoOXBJSw56TqS1eWKwlkzypxxFyIVGjoqmDw1y2cWSDFtLjCX//Nt?= =?us-ascii?Q?+Q/aAVwci5qVbbSM4QnrzT96+IFOBd5iKQjuD7CsB4tz0IeC9fTT2rJ1T3R0?= =?us-ascii?Q?Cov1bG/Bvor1BXfkl/oP8/hDZyd1AuiQefVEtbn3o6gqQAsDXvdFint7iN9F?= =?us-ascii?Q?Yl5vVJF8oGGfEamf1ApekG9oWxYKs4grexihanO/IKhVwvYpyaBSa+s+mqsL?= =?us-ascii?Q?2PGTkoM4XaWyVOOYoFGynKZHM1B+QAYe/bam6dOXxVA93Rmje245cj6Ra/KC?= =?us-ascii?Q?FLtioeEOOMHkTOYSuYvbX3aQM7S8Sud3m5CiryJnU13hfVzG3IFZGpjfKLfe?= =?us-ascii?Q?MyLa/V7mwrU8/GA3P1OGC9ht0=3D?= X-Forefront-PRVS: 0369E8196C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(7370300001)(6049001)(6009001)(39410400002)(39850400002)(39400400002)(39860400002)(39840400002)(39450400003)(377454003)(24454002)(6246003)(305945005)(76176999)(42186005)(33656002)(53936002)(8676002)(50986999)(38730400002)(50466002)(110136004)(5660300001)(81166006)(189998001)(25786009)(478600001)(93886004)(4326008)(50226002)(54906002)(8746002)(86362001)(47776003)(82746002)(57306001)(7736002)(83716003)(2950100002)(77096006)(229853002)(6486002)(6666003)(7350300001)(3846002)(53546010)(6116002)(36756003)(2906002)(66066001)(6916009)(23726003)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2507; H:[172.29.66.35]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB2507; 23:h7gcoE+CiWKqCHMLmBcrfT+nvoPYyynPzlJdfT0YA?= =?us-ascii?Q?qqCWGT1m59lxhJUZPzTIVnX2U9pMkheiVXA4wzliUtnUO09zm2wr7d9Vaxb3?= =?us-ascii?Q?LYNgumIBQDtpi6NCGiLWM/goFn3MmoZc7jv7O5YHKHHAfBLGrLn7k93rwHGf?= =?us-ascii?Q?gL0utAxu5LB91BXmvjqa/D6lQDDwU4b3Yuev4T1dfFXMkf2bH26/McDMV79x?= =?us-ascii?Q?8JYUTjbWFFsPWZAttjEN6BE06vgwLeUkld4zPoRUJ9dt9cT+VzwbCTEfN6ZP?= =?us-ascii?Q?ZiSPfgoZxSfz+Swi06o9ddQ9xnXPHxQHo4vCjB+5ngiEOegcYR8ktLdUy/cs?= =?us-ascii?Q?ffjkmAVO0G/4IgPvq0cR51703iT/tQAv9gJwDOH2bxK+nM4qQ9rbXGFxWY5f?= =?us-ascii?Q?CQJ2xvr+K0SfUQu/wzMQp68xXe0yFJ/KgZIkjSOfknTOCQXDnYpOWiG8L3pW?= =?us-ascii?Q?eCZAqla3COK1Hp8HkPjMU69CV/lR4kwjdip8K44sEyop7LHIuC4WPn8iuUZS?= =?us-ascii?Q?ce+kx5iCHKyjNSpCblmbAN78Ll9XvDZPjXKb1AWV2BN0Ds0g3xqKQf4gDuJF?= =?us-ascii?Q?Vz0eTUH84uI89jR/PKYMxwCfhvFjM6JhSXpw+RLJFfiCfGtWic0b9jnhFEpv?= =?us-ascii?Q?SFQmhpynPNxJ8cIckfVCMdOqPECOJ83s5K/QrOTvgD9VefQRujbvdixhyhzl?= =?us-ascii?Q?njPFMpdn6nCELq828uVi/EU/adXa3Sn6ulIWcfIbPOdzxUoO8pCMiPx7jiDf?= =?us-ascii?Q?xtYEdBcB12B9QoV0u+TuspsM4qwUFbvJb8xCxpmxmWhryFjOreJxo0HBmCAK?= =?us-ascii?Q?/meStC8YQ+S7pL+NmRyD++22gDp2/mU/9kl6EEdqau/3up3APFinSDjbOGDJ?= =?us-ascii?Q?tDjZgXIjV6mJrEzqEL6/ZtbeVX/l821K0eK6REIuUwejno0agEgZ+OMbaXZE?= =?us-ascii?Q?qW2V0FsV+RANA9Gs+oCa9iR9WhOEyWkVKZ/mB163Zi31PcS68qMmd55rBYaZ?= =?us-ascii?Q?nK3kMuVHilAvyjxUBUWr9EOBJZ2ZwV/4Kg8L1cXULDtYtkpce09weMDmZJeb?= =?us-ascii?Q?NHOi99TiW9juLwm7ZVBKZnV+dId2qL2NBB3QFbbRpDSlqiMiCLOMHipexDei?= =?us-ascii?Q?bnaV8HLfYiyTLEUNj+mq3I1AKzpVZxodSgpn2kn2xthsuDfIAk3U56tNi3vM?= =?us-ascii?Q?Eg/oumeTEzNje35ZwXDtHFFhv0nLQQ1Urv8wpINkKSn00/cD3GqPjMne1SGZ?= =?us-ascii?Q?dRtYXcgCHQoHH0rxkMrPWq/ebje5cre3nt1CHOnNa2Qslx+oAjQf4xnIlBGH?= =?us-ascii?Q?GnA+M7+DdV/6cPKwbCRvU4xbOoHWRFbRXhE4df0CaI4?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB2507; 6:lKuDuCvYAFylkAkG9FLOdF+fC9X5VXHBbUKUgB9DCU?= =?us-ascii?Q?gC6EmNF0+n+WQJLvLPgXPoNEkL3hKQYS7RMD94WCTmyCcbnc1hN9TXam5VQQ?= =?us-ascii?Q?Y9PjgnrnkHs2yoGh0mEKcbzr1PeSbTmdAKxcHOqs8hMPSJwFFgSQNsIB0D5V?= =?us-ascii?Q?p67I+eiPfqKuCQd8hVsK2Ls41GpyrAWcKX3tqjQ+NmE2593IjR5U9kG5dBQG?= =?us-ascii?Q?FGIC81YEpXON0cIMvGumF4FTi8zDXicADnfWspAXUqo2LdVrUTAXCvc5nGwx?= =?us-ascii?Q?HmcUIvrzf9nvqzaHMpw6RDx1N9fJ5K5JhcUnCwNKQyr9UvoLBDHqbHXdV9x2?= =?us-ascii?Q?kpu0+4EEecR8bPms1CbugBrJO8PIGmrO6cIxkJssOEstZ0OzPQmu7VgaKlYh?= =?us-ascii?Q?aiwH+/xbSWLEGh1wh552tOuDhzJPeTtgOrsQ2HR7YBInQjTjzojx3KvLwSqo?= =?us-ascii?Q?ua032Nvvka7OdssBIQtAwzHYNt6glAqNt5AT4Zy55OX1hMN8T8Cy5ND8wbio?= =?us-ascii?Q?p/QtUqLgq1afr7rFTYxfXDKHUwbEBZXj8b2fMz7oP3cHhozfY/yBHDSeJxBf?= =?us-ascii?Q?HWdzEs8hZAmuM4B82ohooQLetOC+LrARZ3Mz3d5amIO2IMoBz1z9SHF+FQ3h?= =?us-ascii?Q?87EASnRTbwAWuL7UoiZ61KG2yBetrAGTAKlo6DPoeveYXFwZmkpy/ngI/wO5?= =?us-ascii?Q?1nC08FxPH2kHcaQmmlVHzL10Np3g9sU/zYc+vhLCj3hXnd+DoKQ/x6GSMHAO?= =?us-ascii?Q?LFD3LNz6fxbGNtfyujIZh+wjemyHtXxpLD+lbB/GCTI7sifMSmAJUxXAWi7p?= =?us-ascii?Q?GhZcOxyFt6Vtkt6qHk096hqmR+hM+okVu3dC0JH4VfSEuwcTTg7FoLElXd/8?= =?us-ascii?Q?0Z8un/yNAgCKsMNlMCkK9EhFWNDsUmZd6Mj3cwSGmC0rT/CbJNnBq6n/KFWl?= =?us-ascii?Q?BApZEZ+ziHRjIto1epfLap8K6OnKSjk/Rj/UYXseNNxat54Tzocm4F6JEjrl?= =?us-ascii?Q?bnw4f5Q03EUmy5bQjEHrA1?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 5:8c+xu84yDnMqcyxmtZUUjF2X/rzh+fW+Scg7RQgTo2LJ89lizwYe7520kqrHVV8nVqI3pqpNUdY36j/L67ejVXgfqKN1LeGevAlZ1Df7dxpI4FZPSnpMDfslgVag9u6G1A9ftyTU2t9YzpRItgvGUuVvJcwyADIynWa8vxpRi20Um+9u0M5HcaIv69gFps0oqDLj5anlKJx+H9Xt7FqDIezx7mptai+IOTehSyDyYyJQdT3kh/lxyp+5YVeChiN0KqfRlq5KduWHL7vxjOlqbJHCzqYMVi/eqlDwBmm1cWt2bZcWur4kQ6v2nM4aDD6BLC6ooGheZlkvMrJdLzT52FzS5zcguvnYrDhYnXYYrE7v4o7c7RLnIj2kzaPracBWOqyF3YthG0fz+rjpUxRFEXjzL+HoWPdqXexBsGKjtV4XqhAYQDnYs4hN3WdW+qzBl5M7tcA3Kl6jQwl8UqqE6j6PrSwK8gpZsAyL1t7Ry9Z+xDTCQxbhMvsld/YGQTRT; 24:3XuMTLLte7mXPr6kr7fNJ9Xvt6sKyHL93H6ddgrPu2O32njHZ9th/icqKnbye1sFQRXHbgSVe4IHyerPDD89WkijyJvaykaS6TFH1cILb38= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 7:bLQ1G7NozS0KoQYc4JSK139Hzpnld+ttYchc1NzZtd1IFSFkTrfsWLAfZq9GDFVKvrAbCaYQfNrEDd6o4EMr3WAJm7Fnzvs49/Drt+EGLcc8wAetpKP6jKcIoiBITwN9uoNzspil0/c9J2FRLe3GSBd4AkpSw16B5k2Nx8+9r7+sMn09TN1nllui1Dr2wLUNbbxQtYO16xd7nQC01s8mCcHeHiiKAHWXn6Ugt5wiQbwFqUL/2GIVvOS00ftyZgUKXmKv5WUtGZZ9vxJDw3O7IXrdNGi5huXhubsQQ9G9s8iBVrafK4NGxFNsNkvwuUluv7QzcKjvE9Kqx6WXjXxfq5H0zeHeEqkhgfLrA17lbgdrMFVTE0h5Iu3th6p3FyYi+BhzE1N5Mv4A9RcA8k6omM6TA7FuP0cSZgHFFumFaQPwjOeLVZSAuICawDvsIMWmrprJ/vD/D9EcrMt9RBSBMtuqO5hMDNFokL7sjtEpjOZpwaSFKozh86G6hHqXTmMldvMRedOc36HHQrnQXtHz9bR/iKpzJNrF7z8yMe4Bin5RR2pTgjVSB1KDptofLJN+v4WnDT8kze/xWmSL17YZ2CIULJ9AkGKk+1n9IL69fRlgq66tNGTFIp4Iw7i0rKVGKUw6s2V1Gda1JYEEEVVSBBV04xBf5R6MrFqCjvurHVAHbeUHKvMKkBJhnFY7hqzu07PmEXJUWQ5a+124d/Ihyt2XQ/QOh9FBSOEQbQ7hY4U2AndeKlo7qDA0CiD+8m4JLAhCZMHBKxI0512aBFqCYU7PLaW3eq5HscCOwmhCVX0= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jul 2017 20:08:56.2264 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2507 Archived-At: Subject: Re: [Idr] allocation policy for BGP-LS registries X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 20:09:02 -0000 On Jul 15, 2017, at 10:50 PM, Robert Raszuk wrote: > For one IANA requires some document to do any allocation isn't it ? No. I've pasted the FCFS policy from RFC 5226 at the end. ("Brief = description" means just that, a one-liner.) > Second where in IANA registers there if FCFS space for say new = attribute type, bgp error codes & sub-codes? If the WG wants the allocation policy for any of these (or a sub-range = of any of them) to be FCFS, we can make it so, just like I suggested in = my message at the beginning of this thread.=20 IMO if we don't like the allocation policy of a given registry, we = should change it, not create a workaround. If we don't have consensus to = change the allocation policy, then a workaround (that has the same = effect as changing the policy) would also seem to be inappropriate. --John =46rom RFC 5226: First Come First Served - Assignments are made to anyone on a first come, first served basis. There is no substantive review of the request, other than to ensure that it is well-formed and doesn't duplicate an existing assignment. However, requests must include a minimal amount of clerical information, such as a point of contact (including an email address) and a brief description of how the value will be used. Additional information specific to the type of value requested may also need to be provided, as defined by the namespace. For numbers, the exact value is generally assigned by IANA; with names, specific text strings can usually be requested. From nobody Sat Jul 15 14:03:55 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D732712EC61 for ; Sat, 15 Jul 2017 14:03:53 -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 Rt_7_8muFTbh for ; Sat, 15 Jul 2017 14:03:52 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A669129B06 for ; Sat, 15 Jul 2017 14:03:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1244; q=dns/txt; s=iport; t=1500152632; x=1501362232; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=aLarw296L00bN7A7HrKEq4QXbsJlTDxHltCEZXCk4lM=; b=GZ3mYRU65Ih7awgiQKzTzKpLZ22VpyVl9zDzzRzEGMCCxJ3DDd24aJW3 0Uy+rWju8iPW21gThtFG/X4tI/+9Sv+DNvSxuAcLp+uQS2Nvd8qQWjLgD skh3DyPT2gcy4Bj00NwuoLZGJOmvuSlThhA6gHkW4psjlM7pxkteUki/i 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYAAD0gmpZ/4MNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1qBeAeOBJFelgSCEYVHAhqDVz8YAQIBAQEBAQEBayiFGQEFIxF?= =?us-ascii?q?FEAIBCBgCAiYCAgIwFRACBA4Fii+tXIImixMBAQEBAQEBAQEBAQEBAQEBAQEgg?= =?us-ascii?q?QuCHYUugySEaoMTgmEBBJ80ApQUki+VVgEfOIEKdRWHX3aHZ4ENAQEB?= X-IronPort-AV: E=Sophos;i="5.40,365,1496102400"; d="scan'208";a="453956627" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Jul 2017 21:03:51 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v6FL3p7e030820 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 15 Jul 2017 21:03:51 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; Sat, 15 Jul 2017 17:03:50 -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; Sat, 15 Jul 2017 17:03:50 -0400 From: "Acee Lindem (acee)" To: "John G. Scudder" CC: "idr@ietf.org" , "hannes@rtbrick.com" , "adrian@olddog.co.uk" Thread-Topic: [Idr] allocation policy for BGP-LS registries Thread-Index: AQHS/YFrqC2/VhdJZUaDQQ+Ucs1BUqJVH+sAgABnMQD//9aqgA== Date: Sat, 15 Jul 2017 21:03:50 +0000 Message-ID: References: <5436099D-D57A-4D29-A744-0E8A3572845F@juniper.net> <4BFA27C2-97E3-4777-A688-EA2E33DAB741@juniper.net> In-Reply-To: <4BFA27C2-97E3-4777-A688-EA2E33DAB741@juniper.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.24.81.236] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] allocation policy for BGP-LS registries X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 21:03:54 -0000 DQoNCk9uIDcvMTUvMTcsIDM6MjEgUE0sICJKb2huIEcuIFNjdWRkZXIiIDxqZ3NAanVuaXBlci5u ZXQ+IHdyb3RlOg0KDQo+T25lIG1vcmUgdGhpbmc6DQo+DQo+PiBPbiBKdWwgMTUsIDIwMTcsIGF0 IDg6MTIgUE0sIEFjZWUgTGluZGVtIChhY2VlKSA8YWNlZUBjaXNjby5jb20+IHdyb3RlOg0KPj4g DQo+PiBBbHNvLCBJIHdvdWxkIHJlbW92ZSB0aGUgQUQgZnJvbSBvYnN0cnVjdGluZyB0aGUNCj4+ IGFsbG9jYXRpb24gYnV0IHJlYWxpemUgdGhpcyBtYXkgYmUgYSBjb250cm92ZXJzaWFsIG9waW5p b24uDQo+DQo+RldJVywgSSBkb24ndCByZWNhbGwgY2FzZXMgb2YgdGhlIEFEICJvYnN0cnVjdGlu ZyB0aGUgYWxsb2NhdGlvbiIgZm9yDQo+ZWFybHkgYWxsb2NhdGlvbnMgSURSIGhhcyByZXF1ZXN0 ZWQuIEkganVzdCBjaGVja2VkIG91ciBtb3N0IHJlY2VudA0KPnJlcXVlc3QsIGFuZCB0aGUgdHVy bmFyb3VuZCBiZXR3ZWVuIHNlbmRpbmcgdGhlIHJlcXVlc3QgdG8gQWx2YXJvIGFuZCBoaW0NCj5h cHByb3Zpbmcgd2FzIDI0IG1pbnV0ZXMuDQo+DQo+U28gYXBhcnQgZnJvbSB0aGUgZmFjdCBJRFIg aXNuJ3QgdGhlIGZvcnVtIHRvIHJld3JpdGUgUkZDIDcxMjAsIEkgYWxzbw0KPnF1ZXN0aW9uIHdo ZXRoZXIgdGhpcyBwYXJ0aWN1bGFyIGFzcGVjdCBuZWVkcyBmaXhpbmcuDQoNCkl0IHdhc27igJl0 IGluIElEUi4gSG93ZXZlciwgSeKAmW0gYXdhcmUgb2YgcHVzaC1iYWNrIG9uIHRoZSBncm91bmRz IGFuDQphY2NlcHRlZCBXRyBkb2N1bWVudCB3b3VsZCBub3QgYmUgcHVibGlzaGVkIGluIDEgeWVh ciAodGhlIHRlcm0gb2YgZWFybHkNCmFsbG9jYXRpb25zKS4gSeKAmWQgbGlrZSB0byByZW1vdmUg dGhpcyBkaXNjcmV0aW9uLg0KDQpUaGFua3MsDQpBY2VlIA0KDQo+DQo+LS1Kb2huDQoNCg== From nobody Sat Jul 15 14:08:50 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4E512F26C for ; Sat, 15 Jul 2017 14:08:49 -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 nzdaeQoA6DE3 for ; Sat, 15 Jul 2017 14:08:48 -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 1CFA3127599 for ; Sat, 15 Jul 2017 14:08:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1488; q=dns/txt; s=iport; t=1500152928; x=1501362528; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=DYo25z8IFhEhWM98fpdU4iEmaeWlMN+juXHzMXeRDL4=; b=YLfXfbjE/pfEg559F+Ts20a+vvPtGZBUpcn8Fh54NJJv0680E7kZ26Bu InlVDSx/nYnkKADPE37Mt0yCAm8c1rn7JuPyLA84rXFHR22AFz22IVVzk AfaO193Ou22Vw0SoUcOQ8N/sZxyf/SGndER3hWSgvm9UTHtpqLm91teNO 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYAACug2pZ/5pdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1qBeAeOBJFelgSCEYVHAhqDVz8YAQIBAQEBAQEBayiFGQEFIxF?= =?us-ascii?q?FEAIBCBgCAiYCAgIwFRACBA4Fii+tTYImixMBAQEBAQEBAQEBAQEBAQEBAQEgg?= =?us-ascii?q?QuCHYUugySEaoMTgmEBBJ80ApQUki+VVgEfOIEKdRWHX3aHZ4ENAQEB?= X-IronPort-AV: E=Sophos;i="5.40,365,1496102400"; d="scan'208";a="270514489" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jul 2017 21:08:47 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v6FL8kUL017864 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 15 Jul 2017 21:08:47 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 15 Jul 2017 17:08:45 -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; Sat, 15 Jul 2017 17:08:45 -0400 From: "Acee Lindem (acee)" To: "John G. Scudder" CC: "idr@ietf.org" , "hannes@rtbrick.com" , "adrian@olddog.co.uk" Thread-Topic: [Idr] allocation policy for BGP-LS registries Thread-Index: AQHS/YFrqC2/VhdJZUaDQQ+Ucs1BUqJVH+sAgABU4gD//+e3gA== Date: Sat, 15 Jul 2017 21:08:45 +0000 Message-ID: References: <5436099D-D57A-4D29-A744-0E8A3572845F@juniper.net> <180D7A03-AFBE-4F42-9885-D229897131EA@juniper.net> In-Reply-To: <180D7A03-AFBE-4F42-9885-D229897131EA@juniper.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.24.81.236] Content-Type: text/plain; charset="utf-8" Content-ID: <09BFB4D0E1073747A56AD36B54703FBA@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] allocation policy for BGP-LS registries X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 21:08:49 -0000 SGkgSm9obiwgDQoNCk9uY2UgYSBkcmFmdCBpcyBhY2NlcHRlZCBhcyBhIFdHIGRvY3VtZW50LCBp ZiB3ZSBhcmUgbm90IGFibGUgdG8g4oCcc3VnZ2VzdOKAnQ0KdmFsdWVzIGFzIHdlIGhhZCBpbiB0 aGUgcGFzdCwgd2UgYXJlIGdvaW5nIHRvIGhhdmUgdG8gYmUgbXVjaCBtb3JlDQpkaWxpZ2VudCBh bmQgcGVyc2lzdGVudCBhYm91dCByZXF1ZXN0aW5nIGVhcmx5IGFsbG9jYXRpb24uDQoNClRoYW5r cywNCkFjZWUgDQoNCk9uIDcvMTUvMTcsIDI6MTUgUE0sICJKb2huIEcuIFNjdWRkZXIiIDxqZ3NA anVuaXBlci5uZXQ+IHdyb3RlOg0KDQo+SGkgQWNlZSwNCj4NCj4+IE9uIEp1bCAxNSwgMjAxNywg YXQgODoxMiBQTSwgQWNlZSBMaW5kZW0gKGFjZWUpIDxhY2VlQGNpc2NvLmNvbT4gd3JvdGU6DQo+ PiANCj4+IEkgdGhpbmsgd2UgaGF2ZSBjb250cmFkaWN0aW5nIGdvYWxzIGhlcmUgb2YgZW5jb3Vy YWdpbmcgaW1wbGVtZW50YXRpb25zDQo+PiBhbmQgZGlzY291cmFnaW5nIHN1Z2dlc3Rpb24gb2Yg SUFOQSBjb2RlIHBvaW50cy4gSSB3b3VsZCBwcm9wb3NlIHRoYXQgd2UNCj4+IOKAnGxvd2VyIHRo ZSBiYXLigJ0gZm9yIGVhcmx5IGFsbG9jYXRpb24gYW5kIGFsbG93IGl0IGFzIHNvb24gYXMgYSBk b2N1bWVudA0KPj5pcw0KPj4gYWNjZXB0ZWQgYnkgdGhlIFdHLiBBbHNvLCBJIHdvdWxkIHJlbW92 ZSB0aGUgQUQgZnJvbSBvYnN0cnVjdGluZyB0aGUNCj4+IGFsbG9jYXRpb24gYnV0IHJlYWxpemUg dGhpcyBtYXkgYmUgYSBjb250cm92ZXJzaWFsIG9waW5pb24uDQo+DQo+V2UgYXMgdGhlIElEUiBX RyBkb24ndCBoYXZlIHRoZSBsYXRpdHVkZSB0byByZXdyaXRlIFJGQyA3MTIwLiBJZiB5b3Ugd2Fu dA0KPnRvIGNoYW5nZSB0aGUgYWxsb2NhdGlvbiBydWxlcywgSSBlbmNvdXJhZ2UgeW91IHRvIHN1 Ym1pdCBhIDcxMjBiaXMuDQo+DQo+RG8geW91IHNlZSBhIHByb2JsZW0gd2l0aCBjaGFuZ2luZyB0 aGUgYWxsb2NhdGlvbiBwb2xpY3kgYXMgSSBwcmV2aW91c2x5DQo+c3VnZ2VzdGVkPyBUaGF0IGlz IHNvbWV0aGluZyB3ZSBkbyBoYXZlIGNoYW5nZSBjb250cm9sIG92ZXIuDQo+DQo+LS1Kb2huDQoN Cg== From nobody Sat Jul 15 14:09:00 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C98AC130134 for ; Sat, 15 Jul 2017 14:08:51 -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 STS2sT0NNhAm for ; Sat, 15 Jul 2017 14:08:50 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 540C6127599 for ; Sat, 15 Jul 2017 14:08:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4480; q=dns/txt; s=iport; t=1500152930; x=1501362530; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=BRcs2RRQBnLMwqpa6qfPUToXSP1jEAMs6lI6+zXweIo=; b=AaRheopLIHh/CSbbiJHHTSPGVPZEEK8bU7FghkADWPXFqjBOThtMDvl6 A2OPj1Gp+VPdWbb6kbv1q2+ChwCWC5cEjtT5LZ+RsohfCE1rAPMIE07Fo dwd9RTK+4VmNzxFekrmsP5nc9LaeSfMZb9qFikcuYdjFkjB4WmQQ5Kia4 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYAAAdhGpZ/4MNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkgRQHjgSRXpYEghEhC4UbAhqDVz8YAQIBAQEBAQEBayiFGAE?= =?us-ascii?q?BAQEDAQEhETcDCwwEAgEIEQQBAQMCIwMCAgIlCxQBCAgCBAENBYovEK09giaLE?= =?us-ascii?q?wEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQuCHYUughiBDIQ6g0OCYQWfNAKHSIN?= =?us-ascii?q?Kg0eFO4IlkAqVVgEfOIEKdRVJhxZ2h2eBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.40,365,1496102400"; d="scan'208";a="453957739" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Jul 2017 21:08:49 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v6FL8nnU000585 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 15 Jul 2017 21:08:49 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; Sat, 15 Jul 2017 17:08:48 -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; Sat, 15 Jul 2017 17:08:48 -0400 From: "Acee Lindem (acee)" To: "adrian@olddog.co.uk" , "'John G. Scudder'" , "idr@ietf.org" CC: "hannes@rtbrick.com" Thread-Topic: [Idr] allocation policy for BGP-LS registries Thread-Index: AQEzgIKmqC2/VhdJZUaDQQ+Ucs1BUqOUNJWggAAiooA= Date: Sat, 15 Jul 2017 21:08:48 +0000 Message-ID: References: <5436099D-D57A-4D29-A744-0E8A3572845F@juniper.net> <05db01d2fd9b$6df64520$49e2cf60$@olddog.co.uk> In-Reply-To: <05db01d2fd9b$6df64520$49e2cf60$@olddog.co.uk> 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.81.236] Content-Type: text/plain; charset="utf-8" Content-ID: <9CBCA31F3541DA4495B40E088DD85A98@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] allocation policy for BGP-LS registries X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 21:08:52 -0000 DQoNCk9uIDcvMTUvMTcsIDI6NTEgUE0sICJJZHIgb24gYmVoYWxmIG9mIEFkcmlhbiBGYXJyZWwi DQo8aWRyLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGFkcmlhbkBvbGRkb2cuY28udWs+ IHdyb3RlOg0KDQo+UGVyc29uYWxseSwgSSdtIG9sZCBncm91Y2ghDQo+DQo+RWFybHkgYXNzaWdu bWVudCBpcyBlYXN5IGFuZCBJIGZhaWwgdG8gc2VlIHdoeSBhbiBJLUQgd291bGQgc3F1YXQgKGFu ZA0KPnJpc2sNCj5pbXBsZW1lbnRhdGlvbnMgY2xhc2hpbmcgb3ZlciBjb2RlIHBvaW50cykgd2hl biBlYXJseSBhbGxvY2F0aW9uIGlzIG5vdA0KPm11Y2gNCj5oYXJkZXIgdGhhbiBGQ0ZTLg0KPg0K PkNlcnRhaW5seSwgYnkgdGhlIHRpbWUgYSBkb2N1bWVudCBpcyBhIFdHIGRvY3VtZW50IHdlIHNo b3VsZCBoYXZlIGENCj5yZWFsbHkgZ29vZA0KPmlkZWEgYWJvdXQgd2hldGhlciBpdCBpcyBzdGFi bGUgZW5vdWdoIHRvIGdldCBhIGNvZGUgcG9pbnQgb24gZWFybHkNCj5hbGxvY2F0aW9uLg0KDQpB Z3JlZWQgYW5kIGFsbCBJ4oCZbSBzdWdnZXN0aW5nIGlzIHRoYXQgV0cgYWNjZXB0YW5jZSBiZSBj cml0ZXJpYSBlbm91Z2ggZm9yDQplYXJseSBhbGxvY2F0aW9uLiANCg0KPkJlZm9yZSBhIGRvY3Vt ZW50IGlzIGEgV0cgZG9jdW1lbnQgaXQgc2VlbXMgdG8gbWUgdGhhdCBpdCBpcyBsaXR0bGUgbW9y ZQ0KPnRoYW4gYQ0KPnB1bnQgYW4gYnVybmluZyBjb2RlcG9pbnRzIChldmVuIEZDRlMgZnJvbSBh IGxhcmdlIHJlZ2lzdHJ5KSBzZWVtcyBhIHBvb3INCj5pZGVhDQo+YmVjYXVzZSBhcyAoaWYpIHRo ZSBkb2N1bWVudCBtYXR1cmVzIHRoZSBtZWFuaW5nIHdpbGwgY2hhbmdlIGFuZCB0aGVuIHdlDQo+ aGF2ZSB0bw0KPmFzayB3aGV0aGVyIHRoZSBjb2RlIHBvaW50IGFwcGxpZXMgdG8gdGhlIGVhcmx5 IHZlcnNpb24gb3IgdGhlIG1vcmUgbWF0dXJlDQo+dmVyc2lvbi4NCg0KV2VsbCwgdGhlIGJlc3Qg d2F5IHRvIHJlYWNoIHN0YWJpbGl0eSBpcyB0aHJvdWdoIGltcGxlbWVudGF0aW9uLiBIb3dldmVy LA0KSSBhZ3JlZSB0aGF0IHRoaXMgaXMgdGhlIHByb2Nlc3MgdG9kYXkuDQoNClRoYW5rcywNCkFj ZWUgDQoNCg0KPg0KPkENCj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9t OiBKb2huIEcuIFNjdWRkZXIgW21haWx0bzpqZ3NAanVuaXBlci5uZXRdDQo+PiBTZW50OiAxNSBK dWx5IDIwMTcgMTY6NDINCj4+IFRvOiBpZHJAaWV0Zi5vcmcNCj4+IENjOiBoYW5uZXNAcnRicmlj ay5jb207IGFkcmlhbkBvbGRkb2cuY28udWsNCj4+IFN1YmplY3Q6IGFsbG9jYXRpb24gcG9saWN5 IGZvciBCR1AtTFMgcmVnaXN0cmllcw0KPj4gDQo+PiBIaSBBbGwsDQo+PiANCj4+IFlvdSBtYXkg aGF2ZSBub3RpY2VkIHRoYXQgSSBqdXN0IHNlbnQgb3V0IGEgZmV3IGVtYWlscyBzY29sZGluZyBh dXRob3JzDQo+PmZvcg0KPj4gc3F1YXR0aW5nIG9uIGNvZGUgcG9pbnRzIGluIHRoZSAiQkdQLUxT IE5vZGUgRGVzY3JpcHRvciwgTGluaw0KPj5EZXNjcmlwdG9yLA0KPlByZWZpeA0KPj4gRGVzY3Jp cHRvciwgYW5kIEF0dHJpYnV0ZSBUTFZzIiByZWdpc3RyeS4gVGhpcyBpcyBvbmUgb2YgdGhlIHRo aW5ncyBJDQo+PmxlYXN0DQo+ZW5qb3kNCj4+IGRvaW5nLg0KPj4gDQo+PiBJIG5vdGljZSB0aGF0 IGFsbCBvZiB0aGUgQkdQLUxTIHJlZ2lzdHJpZXMgaGF2ZSB0aGUgIlNwZWNpZmljYXRpb24NCj4+ UmVxdWlyZWQiDQo+cG9saWN5Lg0KPj4gRXhwZXJpZW5jZSBzaG93cyB0aGlzIHRlbmRzIHRvIGlu dml0ZSBzdWNoIGJlaGF2aW9yLiBJIGZ1cnRoZXIgbm90aWNlDQo+PnRoYXQNCj50aHJlZSBvZg0K Pj4gdGhlc2UgcmVnaXN0cmllcyBhcmUgZm9yIDE2LWJpdCBzcGFjZXMgKEJHUC1MUyBQcm90b2Nv bC1JRHMgaXMgYW4gOC1iaXQNCj5zcGFjZSkuDQo+PiANCj4+IEknZCBsaWtlIHRvIGludml0ZSBk aXNjdXNzaW9uIGFib3V0IHdoZXRoZXIgdGhlIFdHIHRoaW5rcyB3ZSBzaG91bGQNCj4+Y29udmVy dA0KPnRoZQ0KPj4gdGhyZWUgMTYtYml0IHJlZ2lzdHJpZXMgdG8gRmlyc3QgQ29tZSBGaXJzdCBT ZXJ2ZWQgKEZDRlMpLg0KPj4gDQo+PiBGb3IgdGhvc2UgdW5mYW1pbGlhciB3aXRoIHRoZSByZXNw ZWN0aXZlIGFsbG9jYXRpb24gcG9saWNpZXMsIGFsbCB0aGUNCj4+Z29yeQ0KPmRldGFpbHMgYXJl DQo+PiBpbiBSRkMgNTIyNiwgYnV0IGZvciBvdXIgcHVycG9zZXMgIlNwZWNpZmljYXRpb24gUmVx dWlyZWQiIGlzIGFsbW9zdA0KPj50aGUgc2FtZQ0KPmFzDQo+PiByZXF1aXJpbmcgYW4gUkZDIGlu IG9yZGVyIGZvciB0aGUgY29kZSBwb2ludCB0byBiZSBpc3N1ZWQuIEJ5IGNvbnRyYXN0LA0KPj5G Q0ZTDQo+YWxsb3dzDQo+PiBhbnlvbmUgdG8gZ2V0IGEgY29kZSBwb2ludCBhdCBhbnkgdGltZSB3 aXRoIG1pbmltdW0gZWZmb3J0LiBXaGlsZSB0aGVyZQ0KPj5hcmUNCj4+IHNvbWUgZHJhd2JhY2tz IHRvIEZDRlMsIHRoZSBtYWpvciBhZHZhbnRhZ2UgaXMgdGhhdCB0aGVyZSBpcyBtaW5pbXVtDQo+ PiBpbXBlZGltZW50IHRvIGNvb3JkaW5hdGluZyBpbXBsZW1lbnRhdGlvbnMgaW4gYW4gb3JnYW5p emVkIGFuZA0KPj5kaXNjaXBsaW5lZA0KPj4gd2F5Lg0KPj4gDQo+PiBIYW5uZXMgYW5kIEFkcmlh biBpbiB0aGUgY2MgYmVjYXVzZSB0aGV5J3JlIHRoZSAiZGVzaWduYXRlZCBleHBlcnRzIiBvbg0K Pj50aG9zZQ0KPj4gcmVnaXN0cmllcy4NCj4+IA0KPj4gSWYgdGhlIFdHIHdhbnRzIHRvIG1ha2Ug dGhpcyBjaGFuZ2UsIHNvbWVvbmUgd291bGQgbmVlZCB0byB3cml0ZSBhDQo+PmRyYWZ0IHRvIGRv DQo+PiBzby4gU3VjaCBkcmFmdHMgY2FuIGJlIHZlcnkgc2hvcnQsIHNlZSBmb3IgZXhhbXBsZQ0K Pj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc4MDMgKHRoaXMgaXMganVzdCB0aGUg Zmlyc3Qgb25lIEkgY2FtZQ0KPmFjcm9zcykuIEl0DQo+PiB3b3VsZCBiZSBncmVhdCB0byBzZWUg c29tZW9uZSB2b2x1bnRlZXIgZm9yIHRoaXMgd29yay4gKFBlcmhhcHMgc29tZW9uZQ0KPj53aG8N Cj4+IGhhcyBiZWVuIGVhZ2VyIHRvIHRha2UgdGhlIHNob3J0Y3V0IG9mICJzdWdnZXN0aW5nIiBj b2RlIHBvaW50cywgaGludA0KPj5oaW50PykNCj4+IA0KPj4gVGhhbmtzLA0KPj4gDQo+PiAtLUpv aG49DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj5JZHIgbWFpbGluZyBsaXN0DQo+SWRyQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9pZHINCg0K From nobody Sat Jul 15 20:53:50 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF02E13172B for ; Sat, 15 Jul 2017 20:53:48 -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 RPfqLeDyqmel for ; Sat, 15 Jul 2017 20:53:47 -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 B2B3713171D for ; Sat, 15 Jul 2017 20:53:47 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=31.133.153.78; From: "Susan Hares" To: "'idr wg'" Date: Sat, 15 Jul 2017 23:47:26 -0400 Message-ID: <003a01d2fde6$3ef73720$bce5a560$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003B_01D2FDC4.B7E68180" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdL95efwA7hfFxtUQfihp+nf2ttiHw== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] WG adoption call for draft-tantsura-idr-bgp-ls-segment-routing-msd X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 03:53:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_003B_01D2FDC4.B7E68180 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The WG adoption call for draft-tantsura-idr-bgp-ls-segment-routing-msd has completed, and this draft has been adopted. The authors should submit this draft as: draft-ietf-idr-bgp-ls-segment-routing-msd.txt. Sue Hares and John Scudder ------=_NextPart_000_003B_01D2FDC4.B7E68180 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The WG = adoption call for draft-tantsura-idr-bgp-ls-segment-routing-msd has = completed, and this draft has been adopted.  The authors should = submit this draft as:

draft-ietf-idr-bgp-ls-segment-routing-msd.txt. =

 

Sue Hares and John Scudder =

------=_NextPart_000_003B_01D2FDC4.B7E68180-- From nobody Sat Jul 15 21:12:02 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CBD0127735 for ; Sat, 15 Jul 2017 21:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.346 X-Spam-Level: ** X-Spam-Status: No, score=2.346 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 GV8qbyn_54SJ for ; Sat, 15 Jul 2017 21:12:00 -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 E75631252BA for ; Sat, 15 Jul 2017 21:11:59 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=31.133.153.78; From: "Susan Hares" To: Date: Sun, 16 Jul 2017 00:05:51 -0400 Message-ID: <004a01d2fde8$d0e19390$72a4bab0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004B_01D2FDC7.49D068C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdL96FNgF84352ItQdiSO11zQkKH5w== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] draft-previdi-idr-segment-routing-te-policy Adoption call - extended X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 04:12:01 -0000 This is a multipart message in MIME format. ------=_NextPart_000_004B_01D2FDC7.49D068C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit IDR WG: We did an adoption call for draft-previdi-idr-segment-routing-te-policy from 6/15 to 6/30. See https://www.ietf.org/mail-archive/web/idr/current/msg18299.html Perhaps some of you were on vacation or focus on IETFs we only got 7 responses (including the authors). We're going to extend this WG Adoption call for 1 additional week (7/15 to 7/22) to see if we can obtain a few more responses. Thank you, Sue Hares and John Scudder ------=_NextPart_000_004B_01D2FDC7.49D068C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IDR WG: =

 

We did an adoption call for = draft-previdi-idr-segment-routing-te-policy from 6/15 to 6/30.  See =

= https://www.ietf.org/mail-archive/web/idr/current/msg18299.html<= /o:p>

 

Perhaps some of you were on vacation or focus on IETFs = we only got 7 responses (including the authors).   We’re = going to extend this WG Adoption call for 1 additional week (7/15 to = 7/22) to see if we can obtain a few more responses.

 

Thank you, =

Sue Hares and John Scudder =

------=_NextPart_000_004B_01D2FDC7.49D068C0-- From nobody Sat Jul 15 21:26:15 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4925127735 for ; Sat, 15 Jul 2017 21:26:13 -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 bfPgDx50BX1S for ; Sat, 15 Jul 2017 21:26:12 -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 9E45A1252BA for ; Sat, 15 Jul 2017 21:26:12 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=31.133.153.78; From: "Susan Hares" To: Date: Sun, 16 Jul 2017 00:20:11 -0400 Message-ID: <006601d2fdea$d1700600$74501200$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0067_01D2FDC9.4A5F0240" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdL96o3j4xs2x08mT8ScdB/8mwmkSw== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] WG Early Allocation Call for draft-ietf-idr-wide-bgp-community-04.txt - 6/14 to 6/28 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 04:26:14 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0067_01D2FDC9.4A5F0240 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The early allocation call has completed, and the IDR WG has consensus on granting the draft-ietf-idr-wide-bgp-community drafts an early allocation. We will forward this request to Alvaro Retana for processing. Sue Hares ------=_NextPart_000_0067_01D2FDC9.4A5F0240 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The early = allocation call has completed, and the IDR WG has consensus on granting = the draft-ietf-idr-wide-bgp-community drafts an early = allocation.   We will forward this request to Alvaro Retana = for processing.

 

Sue Hares =

------=_NextPart_000_0067_01D2FDC9.4A5F0240-- From nobody Sat Jul 15 21:27:33 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16842127735; Sat, 15 Jul 2017 21:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 HbmaolodvORS; Sat, 15 Jul 2017 21:27:29 -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 6210B1252BA; Sat, 15 Jul 2017 21:27:29 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=31.133.153.78; From: "Susan Hares" To: "'Pushpasis Sarkar'" , "'Les Ginsberg \(ginsberg\)'" Cc: , , , "'idr@ietf. org'" Date: Sun, 16 Jul 2017 00:21:19 -0400 Message-ID: <007301d2fdea$faaa11f0$effe35d0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0074_01D2FDC9.739BF460" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdL96hoZgcvq+UuKQYGqTQV3fUAI+g== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] RtgDir review: draft-ietf-idr-bgp-ls-node-admin-tag-extension-01 - WG LC extended (7/15-7/22) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 04:27:31 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0074_01D2FDC9.739BF460 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Pushpasis and Less:=20 =20 We appreciate you working hard to close these issues. The WG LC will = stay open for 1 more week. Please try to close on these issues within = this week.=20 =20 Thank you,=20 =20 Sue Hares=20 =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Pushpasis Sarkar Sent: Thursday, July 13, 2017 8:25 PM To: Les Ginsberg (ginsberg) Cc: rtg-dir@ietf.org; idr-ads@ietf.org; = draft-ietf-idr-bgp-ls-node-admin-tag-extension.all@ietf.org; idr@ietf. = org Subject: Re: [Idr] RtgDir review: = draft-ietf-idr-bgp-ls-node-admin-tag-extension-01 =20 Hi Les, =20 Sorry once again for the late response. Please find comments inline... =20 =20 On Sat, Jul 8, 2017 at 1:42 PM, Les Ginsberg (ginsberg) = wrote: Pushpassis =E2=80=93 =20 Sorry for the delay in responding. You have not addressed all of the editorial comments I provided = =E2=80=93 please do a second pass. [Pushpasis] I did a second pass.. But I could not locate which one(s) I = missed out. It will be great if you list them out for me. The htmlized = diff you attached earlier does not exactly highlight the diffs.. :( = Request your help here...=20 =20 =20 Also, there is one substantive issue which you did not address: =20 Section 3.1 Last paragraph =20 I recognize this statement regarding policy being used to filter what is advertised is consistent with RFC 7752. But it would also be good to = include a statement like: =20 "Definition of such a policy is outside the scope of this document." =20 If you have a concern with what I proposed please let me know what it = is. [Pushpasis] I will be very happy to add the statement. Thanks a lot for = the suggestion. =20 Thanks and Regards, -Pushpasis =20 Thanx. =20 Les =20 =20 =20 From: Pushpasis Sarkar [mailto:pushpasis.ietf@gmail.com]=20 Sent: Tuesday, July 04, 2017 8:58 PM To: Les Ginsberg (ginsberg) Cc: idr-ads@ietf.org; rtg-dir@ietf.org; = draft-ietf-idr-bgp-ls-node-admin-tag-extension.all@ietf.org; idr@ietf. = org Subject: Re: RtgDir review: = draft-ietf-idr-bgp-ls-node-admin-tag-extension-01 =20 Hi Les, =20 Thank you once more for the review comments. And sorry for the late = reply. I have addressed all your comments in the attached draft. Please = review the same let me know if you have any more comments. If not I will = upload the draft soon. =20 Thanks and regards, -Pushpasis =20 On Wed, Jun 28, 2017 at 10:26 PM, Pushpasis Sarkar = wrote: Hi Les, =20 Thanks a lot for the review comments. I will reply back addressing your = comments soon. =20 Thanks and regards -Pushpasis =20 On Tue, Jun 27, 2017 at 11:37 PM, Les Ginsberg (ginsberg) = wrote: Hello, I have been selected as the Routing Directorate reviewer for this = draft. The Routing Directorate seeks to review all routing or = routing-related drafts as they pass through IETF last call and IESG = review, and sometimes on special request. The purpose of the review is = to provide assistance to the Routing ADs. For more information about the = Routing Directorate, please see = http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir . Although these comments are primarily for the use of the Routing ADs, it = would be helpful if you could consider them along with any other IETF = comments that you receive, and strive to resolve them through discussion = or by updating the draft. Document: draft-ietf-idr-bgp-ls-node-admin-tag-extension-01 Reviewer: Les Ginsberg Review Date: June 27, 2017 Intended Status: Standards Summary: The document is of modest scope - covering definition of = BGP-LS codepoints for a relatively new IGP attribute (Node Admin Tags). While I found nothing which I would consider a major issue, there are a = number of places where the text lacks clarity. I think addressing these areas = would greatly improve the quality of the draft. Major Issues: None Minor Issues: Section 1 Introduction The acronym LSDB is not defined. Figure 1 I have a personal dislike for duplicating text/pictures from another spec when that spec could simply be referenced. There are only two possible outcomes: 1)The duplicated text is redundant (best case) 2)The text differs somewhat from the original leading to possible unintentional misinterpretations. Suit yourself on this comment - but I would prefer the duplication be = omitted. Section 2 First paragraph You refer to "sub-TLV" but that reference is unclear and ambiguous. IS-IS uses a sub-TLV of Router Capability to advertise tags, but OSPF uses a TLV of Router Info LSA. What seems most relevant here is that you are defining a new Attribute TLV for Node NLRI. Section 3 Second paragraph I do not know what the paragraph is trying to say, nor do I know what the "TBD" in columns 4 and 5 in the following Table 1 is meant to reference. If you are simply trying to describe the source of the info advertised by the new BGP-LS Node attribute then you should rewrite the above paragraph and in the figure below show: IS-IS 242/21 OSPF RI-LSA/10 Section 3.1 A description of where in the Node NLRI the area/level information can = be found (from RFC 7752) would be helpful. Section 3.1 Penultimate Paragraph As TAGs with "global" scope will be advertised by the IGP multiple times (once per area/level) I assume you are asking BGP-LS = advertisements to reduce these multiple occurrences to a single occurrence? More explicit language on that point would be helpful. Section 3.1 Last paragraph I recognize this statement regarding policy being used to filter what is advertised is consistent with RFC 7752. But it would also be good to = include a statement like: "Definition of such a policy is outside the scope of this document." Nits: Please see attached diff file with some editorial corrections. =20 =20 =20 ------=_NextPart_000_0074_01D2FDC9.739BF460 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Pushpasis and Less:

 

We appreciate you working hard to close these issues.=C2=A0 The WG LC = will stay open for 1 more week.=C2=A0 Please try to close on these = issues within this week.

 

Thank you,

 

Sue Hares

 

From:= = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Pushpasis = Sarkar
Sent: Thursday, July 13, 2017 8:25 PM
To: Les = Ginsberg (ginsberg)
Cc: rtg-dir@ietf.org; idr-ads@ietf.org; = draft-ietf-idr-bgp-ls-node-admin-tag-extension.all@ietf.org; idr@ietf. = org
Subject: Re: [Idr] RtgDir review: = draft-ietf-idr-bgp-ls-node-admin-tag-extension-01

 

Hi = Les,

 

Sorry once again for the late response. Please find = comments inline...

 

 

On Sat, = Jul 8, 2017 at 1:42 PM, Les Ginsberg (ginsberg) <ginsberg@cisco.com> = wrote:

Pushpassis =E2=80=93

 

Sorry for the delay in responding.

You have not addressed all of the editorial comments I provided = =E2=80=93 please do a second = pass.

[Pushpasis] I did a second pass.. But I could not = locate which one(s) I missed out. It will be great if you list them out = for me. The htmlized diff you attached earlier does not exactly = highlight the diffs.. :( Request your help = here... 

 

 

Also, there is one substantive issue which you did not = address:

 

<snip>

Section 3.1 Last paragraph

 

I recognize this statement regarding policy being used to filter what = is

advertised is consistent with RFC 7752. But it would also be good to = include

a statement like:

 

"Definition of such a policy is outside the scope of this = document."

<end snip>

 

If you have a concern with what I proposed please let me know what it = is.

[Pushpasis] I will be very happy to add the = statement.  Thanks a lot for the = suggestion.

 

Thanks and Regards,

-Pushpasis

 

Thanx.

 

   Les

 

 

 

From:= = Pushpasis Sarkar [mailto:pushpasis.ietf@gmail.com]
Sent: = Tuesday, July 04, 2017 8:58 PM
To: Les Ginsberg = (ginsberg)
Cc: idr-ads@ietf.org; rtg-dir@ietf.org; = draft-ietf-idr-bgp-ls-node-admin-tag-extension.all@ietf= .org; idr@ietf. org
Subject: Re: RtgDir review: = draft-ietf-idr-bgp-ls-node-admin-tag-extension-01

 <= /o:p>

Hi = Les,

 <= /o:p>

Thank you = once more for the review comments. And sorry for the late reply. I have = addressed all your comments in the attached draft. Please review the = same let me know if you have any more comments. If not I will upload the = draft soon.

 <= /o:p>

Thanks and = regards,

-Pushpasis

 <= /o:p>

On Wed, Jun = 28, 2017 at 10:26 PM, Pushpasis Sarkar <pushpasis.ietf@gmail.com> = wrote:

Hi = Les,

 <= /o:p>

Thanks a = lot for the review comments. I will reply back addressing your comments = soon.

 <= /o:p>

Thanks and = regards

-Pushpasis

=

 <= /o:p>

On Tue, Jun = 27, 2017 at 11:37 PM, Les Ginsberg (ginsberg) <ginsberg@cisco.com> wrote:

Hello,
 I have been selected as the Routing Directorate reviewer for = this draft. The Routing Directorate seeks to review all routing or = routing-related drafts as they pass through IETF last call and IESG = review, and sometimes on special request. The purpose of the review is = to provide assistance to the Routing ADs. For more information about the = Routing Directorate, please see  http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir .

Although these comments are primarily for the use of the = Routing ADs, it would be helpful if you could consider them along with = any other IETF comments that you receive, and strive to resolve them = through discussion or by updating the draft.


Document: = draft-ietf-idr-bgp-ls-node-admin-tag-extension-01
Reviewer: Les = Ginsberg
Review Date: June 27, 2017
Intended Status: = Standards

Summary:  The document is of modest scope - = covering definition of BGP-LS
codepoints for a relatively new IGP = attribute (Node Admin Tags).
While I found nothing which I would = consider a major issue, there are a number
of places where the text = lacks clarity. I think addressing these areas would
greatly improve = the quality of the draft.


Major Issues: None

Minor = Issues:

Section 1 Introduction

The acronym LSDB is not = defined.

Figure 1

I have a personal dislike for = duplicating text/pictures from another
spec when that spec could = simply be referenced. There are only two
possible = outcomes:

1)The duplicated text is redundant (best case)
2)The = text differs somewhat from the original leading to = possible
unintentional misinterpretations.

Suit yourself on = this comment - but I would prefer the duplication be = omitted.

Section 2 First paragraph

You refer to = "sub-TLV" but that reference is unclear and = ambiguous.
IS-IS uses a sub-TLV of Router Capability to advertise = tags, but OSPF
uses a TLV of Router Info LSA.
What seems most = relevant here is that you are defining a new Attribute
TLV for Node = NLRI.

Section 3 Second paragraph

I do not know what the = paragraph is trying to say, nor do
I know what the "TBD" in = columns 4 and 5 in the following Table 1 is
meant to reference. If = you are simply trying to describe the source
of the info advertised = by the new BGP-LS Node attribute then you should
rewrite the above = paragraph and in the figure below show:

IS-IS 242/21
OSPF = RI-LSA/10

Section 3.1

A description of where in the Node = NLRI the area/level information can be found
(from RFC 7752) would be = helpful.


Section 3.1 Penultimate Paragraph

As TAGs = with "global" scope will be advertised by the IGP = multiple
times (once per area/level) I assume you are asking BGP-LS = advertisements
to reduce these multiple occurrences to a single = occurrence? More
explicit language on that point would be = helpful.

Section 3.1 Last paragraph

I recognize this = statement regarding policy being used to filter what is
advertised is = consistent with RFC 7752. But it would also be good to include
a = statement like:

"Definition of such a policy is outside the = scope of this document."

Nits: Please see attached diff file = with some editorial corrections.

 <= /o:p>

 <= /o:p>

 

------=_NextPart_000_0074_01D2FDC9.739BF460-- From nobody Sun Jul 16 03:10:08 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33A0E126DC2; Sun, 16 Jul 2017 03:10:06 -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 aixxY7zicw2Q; Sun, 16 Jul 2017 03:10:04 -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 F26EC120725; Sun, 16 Jul 2017 03:10:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=38776; q=dns/txt; s=iport; t=1500199804; x=1501409404; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=eAfWMDNS1PyOudj1sLWIKuRrEgwFTqul1L2cAJzD0vA=; b=Z7VU7bErOGhLynvNJXhtNv+l9DC2oZATaISUFkPTbOeILyexvIb5juSq c3Ienx1iemfUNgf2yLIML14++XzjV56/XDDwCWU4lkb7tpACV3QBKXbgI CVAW/S5JeTc8Vdmc1M1nvahfZon+DM5uLVLhPFIwLuiaSMRhrH1yXpHqB U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAAAYOmtZ/5pdJa1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgm8+LWSBFAeOBJFfdIc6jVaCESyFGwIag1c/GAECAQEBAQEBAWsohRg?= =?us-ascii?q?BAQEBAyMKTBACAQgOAwMBAQEhAQIEAwICAh8RFAkIAQEEAQ0FCIlDTAMVEK1rg?= =?us-ascii?q?iaHKQ2DXQEBAQEBAQEBAQEBAQEBAQEBAQEBAR2DKINNgWABghhYNIJXgjMGEIJ?= =?us-ascii?q?dgmEFiWMPjVCHNzsCh0iHXIRnghVXgQ+DaYkQgUSMColMAQ8QOIEKdRVJhRMcG?= =?us-ascii?q?YFOdgGHSIENAQEB?= X-IronPort-AV: E=Sophos;i="5.40,368,1496102400"; d="scan'208,217";a="456300580" 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; 16 Jul 2017 10:10:02 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v6GAA1RL014872 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 16 Jul 2017 10:10:02 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 16 Jul 2017 05:10:01 -0500 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; Sun, 16 Jul 2017 05:10:01 -0500 From: "Les Ginsberg (ginsberg)" To: Susan Hares , "'Pushpasis Sarkar'" CC: "rtg-dir@ietf.org" , "idr-ads@ietf.org" , "draft-ietf-idr-bgp-ls-node-admin-tag-extension.all@ietf.org" , "'idr@ietf. org'" Thread-Topic: [Idr] RtgDir review: draft-ietf-idr-bgp-ls-node-admin-tag-extension-01 - WG LC extended (7/15-7/22) Thread-Index: AdL96hoZgcvq+UuKQYGqTQV3fUAI+gAMWSIw Date: Sun, 16 Jul 2017 10:10:01 +0000 Message-ID: References: <007301d2fdea$faaa11f0$effe35d0$@ndzh.com> In-Reply-To: <007301d2fdea$faaa11f0$effe35d0$@ndzh.com> 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.108.129] Content-Type: multipart/alternative; boundary="_000_d144ee9836fa49c5b71f761ae036cb69XCHALN001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] RtgDir review: draft-ietf-idr-bgp-ls-node-admin-tag-extension-01 - WG LC extended (7/15-7/22) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 10:10:06 -0000 --_000_d144ee9836fa49c5b71f761ae036cb69XCHALN001ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VlIOKAkw0KDQpGWUksIEkgaGF2ZSB1bmljYXN0IGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gdG8g UHVzaHBhc2lzLiBJIGFtIGhvcGVmdWwgaGUgd2lsbCBiZSBhYmxlIHRvIGNvbXBsZXRlIHRoZSBl ZGl0b3JpYWwgY2hhbmdlcyBiYXNlZCBvbiB0aGlzIGluZm8uDQoNCiAgIExlcw0KDQpGcm9tOiBT dXNhbiBIYXJlcyBbbWFpbHRvOnNoYXJlc0BuZHpoLmNvbV0NClNlbnQ6IFNhdHVyZGF5LCBKdWx5 IDE1LCAyMDE3IDk6MjEgUE0NClRvOiAnUHVzaHBhc2lzIFNhcmthcic7IExlcyBHaW5zYmVyZyAo Z2luc2JlcmcpDQpDYzogcnRnLWRpckBpZXRmLm9yZzsgaWRyLWFkc0BpZXRmLm9yZzsgZHJhZnQt aWV0Zi1pZHItYmdwLWxzLW5vZGUtYWRtaW4tdGFnLWV4dGVuc2lvbi5hbGxAaWV0Zi5vcmc7ICdp ZHJAaWV0Zi4gb3JnJw0KU3ViamVjdDogUkU6IFtJZHJdIFJ0Z0RpciByZXZpZXc6IGRyYWZ0LWll dGYtaWRyLWJncC1scy1ub2RlLWFkbWluLXRhZy1leHRlbnNpb24tMDEgLSBXRyBMQyBleHRlbmRl ZCAoNy8xNS03LzIyKQ0KDQpQdXNocGFzaXMgYW5kIExlc3M6DQoNCldlIGFwcHJlY2lhdGUgeW91 IHdvcmtpbmcgaGFyZCB0byBjbG9zZSB0aGVzZSBpc3N1ZXMuICBUaGUgV0cgTEMgd2lsbCBzdGF5 IG9wZW4gZm9yIDEgbW9yZSB3ZWVrLiAgUGxlYXNlIHRyeSB0byBjbG9zZSBvbiB0aGVzZSBpc3N1 ZXMgd2l0aGluIHRoaXMgd2Vlay4NCg0KVGhhbmsgeW91LA0KDQpTdWUgSGFyZXMNCg0KRnJvbTog SWRyIFttYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQdXNocGFzaXMg U2Fya2FyDQpTZW50OiBUaHVyc2RheSwgSnVseSAxMywgMjAxNyA4OjI1IFBNDQpUbzogTGVzIEdp bnNiZXJnIChnaW5zYmVyZykNCkNjOiBydGctZGlyQGlldGYub3JnOyBpZHItYWRzQGlldGYub3Jn OyBkcmFmdC1pZXRmLWlkci1iZ3AtbHMtbm9kZS1hZG1pbi10YWctZXh0ZW5zaW9uLmFsbEBpZXRm Lm9yZzsgaWRyQGlldGYuIG9yZw0KU3ViamVjdDogUmU6IFtJZHJdIFJ0Z0RpciByZXZpZXc6IGRy YWZ0LWlldGYtaWRyLWJncC1scy1ub2RlLWFkbWluLXRhZy1leHRlbnNpb24tMDENCg0KSGkgTGVz LA0KDQpTb3JyeSBvbmNlIGFnYWluIGZvciB0aGUgbGF0ZSByZXNwb25zZS4gUGxlYXNlIGZpbmQg Y29tbWVudHMgaW5saW5lLi4uDQoNCg0KT24gU2F0LCBKdWwgOCwgMjAxNyBhdCAxOjQyIFBNLCBM ZXMgR2luc2JlcmcgKGdpbnNiZXJnKSA8Z2luc2JlcmdAY2lzY28uY29tPG1haWx0bzpnaW5zYmVy Z0BjaXNjby5jb20+PiB3cm90ZToNClB1c2hwYXNzaXMg4oCTDQoNClNvcnJ5IGZvciB0aGUgZGVs YXkgaW4gcmVzcG9uZGluZy4NCllvdSBoYXZlIG5vdCBhZGRyZXNzZWQgYWxsIG9mIHRoZSBlZGl0 b3JpYWwgY29tbWVudHMgSSBwcm92aWRlZCDigJMgcGxlYXNlIGRvIGEgc2Vjb25kIHBhc3MuDQpb UHVzaHBhc2lzXSBJIGRpZCBhIHNlY29uZCBwYXNzLi4gQnV0IEkgY291bGQgbm90IGxvY2F0ZSB3 aGljaCBvbmUocykgSSBtaXNzZWQgb3V0LiBJdCB3aWxsIGJlIGdyZWF0IGlmIHlvdSBsaXN0IHRo ZW0gb3V0IGZvciBtZS4gVGhlIGh0bWxpemVkIGRpZmYgeW91IGF0dGFjaGVkIGVhcmxpZXIgZG9l cyBub3QgZXhhY3RseSBoaWdobGlnaHQgdGhlIGRpZmZzLi4gOiggUmVxdWVzdCB5b3VyIGhlbHAg aGVyZS4uLg0KDQoNCkFsc28sIHRoZXJlIGlzIG9uZSBzdWJzdGFudGl2ZSBpc3N1ZSB3aGljaCB5 b3UgZGlkIG5vdCBhZGRyZXNzOg0KDQo8c25pcD4NClNlY3Rpb24gMy4xIExhc3QgcGFyYWdyYXBo DQoNCkkgcmVjb2duaXplIHRoaXMgc3RhdGVtZW50IHJlZ2FyZGluZyBwb2xpY3kgYmVpbmcgdXNl ZCB0byBmaWx0ZXIgd2hhdCBpcw0KYWR2ZXJ0aXNlZCBpcyBjb25zaXN0ZW50IHdpdGggUkZDIDc3 NTIuIEJ1dCBpdCB3b3VsZCBhbHNvIGJlIGdvb2QgdG8gaW5jbHVkZQ0KYSBzdGF0ZW1lbnQgbGlr ZToNCg0KIkRlZmluaXRpb24gb2Ygc3VjaCBhIHBvbGljeSBpcyBvdXRzaWRlIHRoZSBzY29wZSBv ZiB0aGlzIGRvY3VtZW50LiINCjxlbmQgc25pcD4NCg0KSWYgeW91IGhhdmUgYSBjb25jZXJuIHdp dGggd2hhdCBJIHByb3Bvc2VkIHBsZWFzZSBsZXQgbWUga25vdyB3aGF0IGl0IGlzLg0KW1B1c2hw YXNpc10gSSB3aWxsIGJlIHZlcnkgaGFwcHkgdG8gYWRkIHRoZSBzdGF0ZW1lbnQuICBUaGFua3Mg YSBsb3QgZm9yIHRoZSBzdWdnZXN0aW9uLg0KDQpUaGFua3MgYW5kIFJlZ2FyZHMsDQotUHVzaHBh c2lzDQoNClRoYW54Lg0KDQogICBMZXMNCg0KDQoNCkZyb206IFB1c2hwYXNpcyBTYXJrYXIgW21h aWx0bzpwdXNocGFzaXMuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnB1c2hwYXNpcy5pZXRmQGdtYWls LmNvbT5dDQpTZW50OiBUdWVzZGF5LCBKdWx5IDA0LCAyMDE3IDg6NTggUE0NClRvOiBMZXMgR2lu c2JlcmcgKGdpbnNiZXJnKQ0KQ2M6IGlkci1hZHNAaWV0Zi5vcmc8bWFpbHRvOmlkci1hZHNAaWV0 Zi5vcmc+OyBydGctZGlyQGlldGYub3JnPG1haWx0bzpydGctZGlyQGlldGYub3JnPjsgZHJhZnQt aWV0Zi1pZHItYmdwLWxzLW5vZGUtYWRtaW4tdGFnLWV4dGVuc2lvbi5hbGxAaWV0Zi5vcmc8bWFp bHRvOmRyYWZ0LWlldGYtaWRyLWJncC1scy1ub2RlLWFkbWluLXRhZy1leHRlbnNpb24uYWxsQGll dGYub3JnPjsgaWRyQGlldGYuIG9yZw0KU3ViamVjdDogUmU6IFJ0Z0RpciByZXZpZXc6IGRyYWZ0 LWlldGYtaWRyLWJncC1scy1ub2RlLWFkbWluLXRhZy1leHRlbnNpb24tMDENCg0KSGkgTGVzLA0K DQpUaGFuayB5b3Ugb25jZSBtb3JlIGZvciB0aGUgcmV2aWV3IGNvbW1lbnRzLiBBbmQgc29ycnkg Zm9yIHRoZSBsYXRlIHJlcGx5LiBJIGhhdmUgYWRkcmVzc2VkIGFsbCB5b3VyIGNvbW1lbnRzIGlu IHRoZSBhdHRhY2hlZCBkcmFmdC4gUGxlYXNlIHJldmlldyB0aGUgc2FtZSBsZXQgbWUga25vdyBp ZiB5b3UgaGF2ZSBhbnkgbW9yZSBjb21tZW50cy4gSWYgbm90IEkgd2lsbCB1cGxvYWQgdGhlIGRy YWZ0IHNvb24uDQoNClRoYW5rcyBhbmQgcmVnYXJkcywNCi1QdXNocGFzaXMNCg0KT24gV2VkLCBK dW4gMjgsIDIwMTcgYXQgMTA6MjYgUE0sIFB1c2hwYXNpcyBTYXJrYXIgPHB1c2hwYXNpcy5pZXRm QGdtYWlsLmNvbTxtYWlsdG86cHVzaHBhc2lzLmlldGZAZ21haWwuY29tPj4gd3JvdGU6DQpIaSBM ZXMsDQoNClRoYW5rcyBhIGxvdCBmb3IgdGhlIHJldmlldyBjb21tZW50cy4gSSB3aWxsIHJlcGx5 IGJhY2sgYWRkcmVzc2luZyB5b3VyIGNvbW1lbnRzIHNvb24uDQoNClRoYW5rcyBhbmQgcmVnYXJk cw0KLVB1c2hwYXNpcw0KDQpPbiBUdWUsIEp1biAyNywgMjAxNyBhdCAxMTozNyBQTSwgTGVzIEdp bnNiZXJnIChnaW5zYmVyZykgPGdpbnNiZXJnQGNpc2NvLmNvbTxtYWlsdG86Z2luc2JlcmdAY2lz Y28uY29tPj4gd3JvdGU6DQpIZWxsbywNCg0KIEkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBS b3V0aW5nIERpcmVjdG9yYXRlIHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgUm91dGluZyBE aXJlY3RvcmF0ZSBzZWVrcyB0byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVk IGRyYWZ0cyBhcyB0aGV5IHBhc3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZp ZXcsIGFuZCBzb21ldGltZXMgb24gc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUg cmV2aWV3IGlzIHRvIHByb3ZpZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuIEZvciBt b3JlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ugc2Vl ICBodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dpa2kvUnRnRGlyIC4N Cg0KQWx0aG91Z2ggdGhlc2UgY29tbWVudHMgYXJlIHByaW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0 aGUgUm91dGluZyBBRHMsIGl0IHdvdWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVy IHRoZW0gYWxvbmcgd2l0aCBhbnkgb3RoZXIgSUVURiBjb21tZW50cyB0aGF0IHlvdSByZWNlaXZl LCBhbmQgc3RyaXZlIHRvIHJlc29sdmUgdGhlbSB0aHJvdWdoIGRpc2N1c3Npb24gb3IgYnkgdXBk YXRpbmcgdGhlIGRyYWZ0Lg0KDQoNCkRvY3VtZW50OiBkcmFmdC1pZXRmLWlkci1iZ3AtbHMtbm9k ZS1hZG1pbi10YWctZXh0ZW5zaW9uLTAxDQpSZXZpZXdlcjogTGVzIEdpbnNiZXJnDQpSZXZpZXcg RGF0ZTogSnVuZSAyNywgMjAxNw0KSW50ZW5kZWQgU3RhdHVzOiBTdGFuZGFyZHMNCg0KU3VtbWFy eTogIFRoZSBkb2N1bWVudCBpcyBvZiBtb2Rlc3Qgc2NvcGUgLSBjb3ZlcmluZyBkZWZpbml0aW9u IG9mIEJHUC1MUw0KY29kZXBvaW50cyBmb3IgYSByZWxhdGl2ZWx5IG5ldyBJR1AgYXR0cmlidXRl IChOb2RlIEFkbWluIFRhZ3MpLg0KV2hpbGUgSSBmb3VuZCBub3RoaW5nIHdoaWNoIEkgd291bGQg Y29uc2lkZXIgYSBtYWpvciBpc3N1ZSwgdGhlcmUgYXJlIGEgbnVtYmVyDQpvZiBwbGFjZXMgd2hl cmUgdGhlIHRleHQgbGFja3MgY2xhcml0eS4gSSB0aGluayBhZGRyZXNzaW5nIHRoZXNlIGFyZWFz IHdvdWxkDQpncmVhdGx5IGltcHJvdmUgdGhlIHF1YWxpdHkgb2YgdGhlIGRyYWZ0Lg0KDQoNCk1h am9yIElzc3VlczogTm9uZQ0KDQpNaW5vciBJc3N1ZXM6DQoNClNlY3Rpb24gMSBJbnRyb2R1Y3Rp b24NCg0KVGhlIGFjcm9ueW0gTFNEQiBpcyBub3QgZGVmaW5lZC4NCg0KRmlndXJlIDENCg0KSSBo YXZlIGEgcGVyc29uYWwgZGlzbGlrZSBmb3IgZHVwbGljYXRpbmcgdGV4dC9waWN0dXJlcyBmcm9t IGFub3RoZXINCnNwZWMgd2hlbiB0aGF0IHNwZWMgY291bGQgc2ltcGx5IGJlIHJlZmVyZW5jZWQu IFRoZXJlIGFyZSBvbmx5IHR3bw0KcG9zc2libGUgb3V0Y29tZXM6DQoNCjEpVGhlIGR1cGxpY2F0 ZWQgdGV4dCBpcyByZWR1bmRhbnQgKGJlc3QgY2FzZSkNCjIpVGhlIHRleHQgZGlmZmVycyBzb21l d2hhdCBmcm9tIHRoZSBvcmlnaW5hbCBsZWFkaW5nIHRvIHBvc3NpYmxlDQp1bmludGVudGlvbmFs IG1pc2ludGVycHJldGF0aW9ucy4NCg0KU3VpdCB5b3Vyc2VsZiBvbiB0aGlzIGNvbW1lbnQgLSBi dXQgSSB3b3VsZCBwcmVmZXIgdGhlIGR1cGxpY2F0aW9uIGJlIG9taXR0ZWQuDQoNClNlY3Rpb24g MiBGaXJzdCBwYXJhZ3JhcGgNCg0KWW91IHJlZmVyIHRvICJzdWItVExWIiBidXQgdGhhdCByZWZl cmVuY2UgaXMgdW5jbGVhciBhbmQgYW1iaWd1b3VzLg0KSVMtSVMgdXNlcyBhIHN1Yi1UTFYgb2Yg Um91dGVyIENhcGFiaWxpdHkgdG8gYWR2ZXJ0aXNlIHRhZ3MsIGJ1dCBPU1BGDQp1c2VzIGEgVExW IG9mIFJvdXRlciBJbmZvIExTQS4NCldoYXQgc2VlbXMgbW9zdCByZWxldmFudCBoZXJlIGlzIHRo YXQgeW91IGFyZSBkZWZpbmluZyBhIG5ldyBBdHRyaWJ1dGUNClRMViBmb3IgTm9kZSBOTFJJLg0K DQpTZWN0aW9uIDMgU2Vjb25kIHBhcmFncmFwaA0KDQpJIGRvIG5vdCBrbm93IHdoYXQgdGhlIHBh cmFncmFwaCBpcyB0cnlpbmcgdG8gc2F5LCBub3IgZG8NCkkga25vdyB3aGF0IHRoZSAiVEJEIiBp biBjb2x1bW5zIDQgYW5kIDUgaW4gdGhlIGZvbGxvd2luZyBUYWJsZSAxIGlzDQptZWFudCB0byBy ZWZlcmVuY2UuIElmIHlvdSBhcmUgc2ltcGx5IHRyeWluZyB0byBkZXNjcmliZSB0aGUgc291cmNl DQpvZiB0aGUgaW5mbyBhZHZlcnRpc2VkIGJ5IHRoZSBuZXcgQkdQLUxTIE5vZGUgYXR0cmlidXRl IHRoZW4geW91IHNob3VsZA0KcmV3cml0ZSB0aGUgYWJvdmUgcGFyYWdyYXBoIGFuZCBpbiB0aGUg ZmlndXJlIGJlbG93IHNob3c6DQoNCklTLUlTIDI0Mi8yMQ0KT1NQRiBSSS1MU0EvMTANCg0KU2Vj dGlvbiAzLjENCg0KQSBkZXNjcmlwdGlvbiBvZiB3aGVyZSBpbiB0aGUgTm9kZSBOTFJJIHRoZSBh cmVhL2xldmVsIGluZm9ybWF0aW9uIGNhbiBiZSBmb3VuZA0KKGZyb20gUkZDIDc3NTIpIHdvdWxk IGJlIGhlbHBmdWwuDQoNCg0KU2VjdGlvbiAzLjEgUGVudWx0aW1hdGUgUGFyYWdyYXBoDQoNCkFz IFRBR3Mgd2l0aCAiZ2xvYmFsIiBzY29wZSB3aWxsIGJlIGFkdmVydGlzZWQgYnkgdGhlIElHUCBt dWx0aXBsZQ0KdGltZXMgKG9uY2UgcGVyIGFyZWEvbGV2ZWwpIEkgYXNzdW1lIHlvdSBhcmUgYXNr aW5nIEJHUC1MUyBhZHZlcnRpc2VtZW50cw0KdG8gcmVkdWNlIHRoZXNlIG11bHRpcGxlIG9jY3Vy cmVuY2VzIHRvIGEgc2luZ2xlIG9jY3VycmVuY2U/IE1vcmUNCmV4cGxpY2l0IGxhbmd1YWdlIG9u IHRoYXQgcG9pbnQgd291bGQgYmUgaGVscGZ1bC4NCg0KU2VjdGlvbiAzLjEgTGFzdCBwYXJhZ3Jh cGgNCg0KSSByZWNvZ25pemUgdGhpcyBzdGF0ZW1lbnQgcmVnYXJkaW5nIHBvbGljeSBiZWluZyB1 c2VkIHRvIGZpbHRlciB3aGF0IGlzDQphZHZlcnRpc2VkIGlzIGNvbnNpc3RlbnQgd2l0aCBSRkMg Nzc1Mi4gQnV0IGl0IHdvdWxkIGFsc28gYmUgZ29vZCB0byBpbmNsdWRlDQphIHN0YXRlbWVudCBs aWtlOg0KDQoiRGVmaW5pdGlvbiBvZiBzdWNoIGEgcG9saWN5IGlzIG91dHNpZGUgdGhlIHNjb3Bl IG9mIHRoaXMgZG9jdW1lbnQuIg0KDQpOaXRzOiBQbGVhc2Ugc2VlIGF0dGFjaGVkIGRpZmYgZmls ZSB3aXRoIHNvbWUgZWRpdG9yaWFsIGNvcnJlY3Rpb25zLg0KDQoNCg0K --_000_d144ee9836fa49c5b71f761ae036cb69XCHALN001ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U3VlIOKAkzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RllJLCBJ IGhhdmUgdW5pY2FzdCBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIHRvIFB1c2hwYXNpcy4gSSBhbSBo b3BlZnVsIGhlIHdpbGwgYmUgYWJsZSB0byBjb21wbGV0ZSB0aGUgZWRpdG9yaWFsIGNoYW5nZXMg YmFzZWQgb24gdGhpcyBpbmZvLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IExlczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBTdXNhbiBIYXJlcyBbbWFpbHRvOnNo YXJlc0BuZHpoLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgSnVseSAxNSwgMjAx NyA5OjIxIFBNPGJyPg0KPGI+VG86PC9iPiAnUHVzaHBhc2lzIFNhcmthcic7IExlcyBHaW5zYmVy ZyAoZ2luc2JlcmcpPGJyPg0KPGI+Q2M6PC9iPiBydGctZGlyQGlldGYub3JnOyBpZHItYWRzQGll dGYub3JnOyBkcmFmdC1pZXRmLWlkci1iZ3AtbHMtbm9kZS1hZG1pbi10YWctZXh0ZW5zaW9uLmFs bEBpZXRmLm9yZzsgJ2lkckBpZXRmLiBvcmcnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbSWRy XSBSdGdEaXIgcmV2aWV3OiBkcmFmdC1pZXRmLWlkci1iZ3AtbHMtbm9kZS1hZG1pbi10YWctZXh0 ZW5zaW9uLTAxIC0gV0cgTEMgZXh0ZW5kZWQgKDcvMTUtNy8yMikNCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5QdXNocGFzaXMgYW5kIExlc3M6DQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldlIGFwcHJl Y2lhdGUgeW91IHdvcmtpbmcgaGFyZCB0byBjbG9zZSB0aGVzZSBpc3N1ZXMuJm5ic3A7IFRoZSBX RyBMQyB3aWxsIHN0YXkgb3BlbiBmb3IgMSBtb3JlIHdlZWsuJm5ic3A7IFBsZWFzZSB0cnkgdG8g Y2xvc2Ugb24gdGhlc2UgaXNzdWVzIHdpdGhpbiB0aGlzIHdlZWsuDQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5r IHlvdSwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+U3VlIEhhcmVzDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+IElkciBbbWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24g QmVoYWxmIE9mIDwvYj5QdXNocGFzaXMgU2Fya2FyPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5 LCBKdWx5IDEzLCAyMDE3IDg6MjUgUE08YnI+DQo8Yj5Ubzo8L2I+IExlcyBHaW5zYmVyZyAoZ2lu c2JlcmcpPGJyPg0KPGI+Q2M6PC9iPiBydGctZGlyQGlldGYub3JnOyBpZHItYWRzQGlldGYub3Jn OyBkcmFmdC1pZXRmLWlkci1iZ3AtbHMtbm9kZS1hZG1pbi10YWctZXh0ZW5zaW9uLmFsbEBpZXRm Lm9yZzsgaWRyQGlldGYuIG9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0lkcl0gUnRnRGly IHJldmlldzogZHJhZnQtaWV0Zi1pZHItYmdwLWxzLW5vZGUtYWRtaW4tdGFnLWV4dGVuc2lvbi0w MTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIExlcyw8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvcnJ5IG9uY2UgYWdhaW4gZm9y IHRoZSBsYXRlIHJlc3BvbnNlLiBQbGVhc2UgZmluZCBjb21tZW50cyBpbmxpbmUuLi48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU2F0LCBKdWwgOCwg MjAxNyBhdCAxOjQyIFBNLCBMZXMgR2luc2JlcmcgKGdpbnNiZXJnKSAmbHQ7PGEgaHJlZj0ibWFp bHRvOmdpbnNiZXJnQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmdpbnNiZXJnQGNpc2NvLmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Q dXNocGFzc2lzIOKAkzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNvcnJ5IGZvciB0aGUgZGVsYXkgaW4gcmVzcG9u ZGluZy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Zb3UgaGF2ZSBub3QgYWRkcmVz c2VkIGFsbCBvZiB0aGUgZWRpdG9yaWFsIGNvbW1lbnRzIEkgcHJvdmlkZWQg4oCTIHBsZWFzZSBk byBhIHNlY29uZCBwYXNzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W1B1c2hwYXNpc10gSSBkaWQgYSBzZWNvbmQgcGFz cy4uIEJ1dCBJIGNvdWxkIG5vdCBsb2NhdGUgd2hpY2ggb25lKHMpIEkgbWlzc2VkIG91dC4gSXQg d2lsbCBiZSBncmVhdCBpZiB5b3UgbGlzdCB0aGVtIG91dCBmb3IgbWUuIFRoZSBodG1saXplZCBk aWZmIHlvdSBhdHRhY2hlZCBlYXJsaWVyIGRvZXMgbm90IGV4YWN0bHkgaGlnaGxpZ2h0IHRoZSBk aWZmcy4uIDooIFJlcXVlc3QgeW91ciBoZWxwIGhlcmUuLi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+QWxzbywgdGhlcmUgaXMgb25lIHN1YnN0YW50aXZlIGlzc3VlIHdoaWNoIHlvdSBk aWQgbm90IGFkZHJlc3M6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41 aW4iPg0KPGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZsdDtz bmlwJmd0Ozwvc3Bhbj48L2k+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6LjVpbiI+DQo8aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+U2VjdGlvbiAzLjEgTGFzdCBwYXJhZ3JhcGg8L3NwYW4+PC9pPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPGk+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L2k+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8 aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSByZWNvZ25pemUg dGhpcyBzdGF0ZW1lbnQgcmVnYXJkaW5nIHBvbGljeSBiZWluZyB1c2VkIHRvIGZpbHRlciB3aGF0 IGlzPC9zcGFuPjwvaT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDouNWluIj4NCjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5hZHZlcnRpc2VkIGlzIGNvbnNpc3RlbnQgd2l0aCBSRkMgNzc1Mi4gQnV0IGl0IHdvdWxk IGFsc28gYmUgZ29vZCB0byBpbmNsdWRlPC9zcGFuPjwvaT48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxpPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5hIHN0YXRlbWVudCBsaWtlOjwvc3Bhbj48L2k+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8 aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjwvaT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDou NWluIj4NCjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mcXVv dDtEZWZpbml0aW9uIG9mIHN1Y2ggYSBwb2xpY3kgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhp cyBkb2N1bWVudC4mcXVvdDs8L3NwYW4+PC9pPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZsdDtlbmQgc25pcCZndDs8L3NwYW4+PC9pPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPGk+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L2k+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JZiB5b3UgaGF2ZSBhIGNvbmNlcm4gd2l0aCB3aGF0IEkg cHJvcG9zZWQgcGxlYXNlIGxldCBtZSBrbm93IHdoYXQgaXQgaXMuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5bUHVzaHBhc2lzXSBJIHdpbGwgYmUgdmVyeSBoYXBweSB0byBhZGQgdGhlIHN0YXRl bWVudC4mbmJzcDsgVGhhbmtzIGEgbG90IGZvciB0aGUgc3VnZ2VzdGlvbi48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIGFuZCBSZWdh cmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ LVB1c2hwYXNpczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0 OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbnguPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7Jm5ic3A7IExlczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0 LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUHVzaHBhc2lzIFNhcmthciBbbWFpbHRvOjxhIGhy ZWY9Im1haWx0bzpwdXNocGFzaXMuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5wdXNo cGFzaXMuaWV0ZkBnbWFpbC5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEp1 bHkgMDQsIDIwMTcgODo1OCBQTTxicj4NCjxiPlRvOjwvYj4gTGVzIEdpbnNiZXJnIChnaW5zYmVy Zyk8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzppZHItYWRzQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+aWRyLWFkc0BpZXRmLm9yZzwvYT47DQo8YSBocmVmPSJtYWlsdG86cnRnLWRp ckBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Zy1kaXJAaWV0Zi5vcmc8L2E+OyA8YSBocmVm PSJtYWlsdG86ZHJhZnQtaWV0Zi1pZHItYmdwLWxzLW5vZGUtYWRtaW4tdGFnLWV4dGVuc2lvbi5h bGxAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCmRyYWZ0LWlldGYtaWRyLWJncC1scy1ub2Rl LWFkbWluLXRhZy1leHRlbnNpb24uYWxsQGlldGYub3JnPC9hPjsgaWRyQGlldGYuIG9yZzxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogUnRnRGlyIHJldmlldzogZHJhZnQtaWV0Zi1pZHItYmdwLWxz LW5vZGUtYWRtaW4tdGFnLWV4dGVuc2lvbi0wMTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSBMZXMsPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhbmsgeW91IG9u Y2UgbW9yZSBmb3IgdGhlIHJldmlldyBjb21tZW50cy4gQW5kIHNvcnJ5IGZvciB0aGUgbGF0ZSBy ZXBseS4gSSBoYXZlIGFkZHJlc3NlZCBhbGwgeW91ciBjb21tZW50cyBpbiB0aGUgYXR0YWNoZWQg ZHJhZnQuIFBsZWFzZSByZXZpZXcgdGhlIHNhbWUgbGV0IG1lIGtub3cgaWYgeW91IGhhdmUNCiBh bnkgbW9yZSBjb21tZW50cy4gSWYgbm90IEkgd2lsbCB1cGxvYWQgdGhlIGRyYWZ0IHNvb24uPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5U aGFua3MgYW5kIHJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPi1QdXNocGFzaXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFdlZCwgSnVuIDI4LCAyMDE3IGF0IDEwOjI2 IFBNLCBQdXNocGFzaXMgU2Fya2FyICZsdDs8YSBocmVmPSJtYWlsdG86cHVzaHBhc2lzLmlldGZA Z21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+cHVzaHBhc2lzLmlldGZAZ21haWwuY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5I aSBMZXMsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ VGhhbmtzIGEgbG90IGZvciB0aGUgcmV2aWV3IGNvbW1lbnRzLiBJIHdpbGwgcmVwbHkgYmFjayBh ZGRyZXNzaW5nIHlvdXIgY29tbWVudHMgc29vbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoYW5rcyBhbmQgcmVnYXJkczxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iY29sb3I6Izg4ODg4OCI+LVB1c2hwYXNpczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVHVl LCBKdW4gMjcsIDIwMTcgYXQgMTE6MzcgUE0sIExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpICZsdDs8 YSBocmVmPSJtYWlsdG86Z2luc2JlcmdAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+Z2luc2Jl cmdAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPkhlbGxvLDxicj4NCjxicj4NCiZuYnNwO0kgaGF2ZSBiZWVuIHNlbGVjdGVkIGFz IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgUm91 dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1y ZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBhc3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVT RyByZXZpZXcsIGFuZCBzb21ldGltZXMgb24gc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBv ZiB0aGUNCiByZXZpZXcgaXMgdG8gcHJvdmlkZSBhc3Npc3RhbmNlIHRvIHRoZSBSb3V0aW5nIEFE cy4gRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUsIHBs ZWFzZSBzZWUmbmJzcDsNCjxhIGhyZWY9Imh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEv cnRnL3RyYWMvd2lraS9SdGdEaXIiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vdHJhYy50b29scy5p ZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dpa2kvUnRnRGlyPC9hPiAuPGJyPg0KPGJyPg0KQWx0aG91 Z2ggdGhlc2UgY29tbWVudHMgYXJlIHByaW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGlu ZyBBRHMsIGl0IHdvdWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxv bmcgd2l0aCBhbnkgb3RoZXIgSUVURiBjb21tZW50cyB0aGF0IHlvdSByZWNlaXZlLCBhbmQgc3Ry aXZlIHRvIHJlc29sdmUgdGhlbSB0aHJvdWdoIGRpc2N1c3Npb24gb3IgYnkgdXBkYXRpbmcgdGhl IGRyYWZ0Ljxicj4NCjxicj4NCjxicj4NCkRvY3VtZW50OiBkcmFmdC1pZXRmLWlkci1iZ3AtbHMt bm9kZS1hZG1pbi10YWctZXh0ZW5zaW9uLTAxPGJyPg0KUmV2aWV3ZXI6IExlcyBHaW5zYmVyZzxi cj4NClJldmlldyBEYXRlOiBKdW5lIDI3LCAyMDE3PGJyPg0KSW50ZW5kZWQgU3RhdHVzOiBTdGFu ZGFyZHM8YnI+DQo8YnI+DQpTdW1tYXJ5OiZuYnNwOyBUaGUgZG9jdW1lbnQgaXMgb2YgbW9kZXN0 IHNjb3BlIC0gY292ZXJpbmcgZGVmaW5pdGlvbiBvZiBCR1AtTFM8YnI+DQpjb2RlcG9pbnRzIGZv ciBhIHJlbGF0aXZlbHkgbmV3IElHUCBhdHRyaWJ1dGUgKE5vZGUgQWRtaW4gVGFncykuPGJyPg0K V2hpbGUgSSBmb3VuZCBub3RoaW5nIHdoaWNoIEkgd291bGQgY29uc2lkZXIgYSBtYWpvciBpc3N1 ZSwgdGhlcmUgYXJlIGEgbnVtYmVyPGJyPg0Kb2YgcGxhY2VzIHdoZXJlIHRoZSB0ZXh0IGxhY2tz IGNsYXJpdHkuIEkgdGhpbmsgYWRkcmVzc2luZyB0aGVzZSBhcmVhcyB3b3VsZDxicj4NCmdyZWF0 bHkgaW1wcm92ZSB0aGUgcXVhbGl0eSBvZiB0aGUgZHJhZnQuPGJyPg0KPGJyPg0KPGJyPg0KTWFq b3IgSXNzdWVzOiBOb25lPGJyPg0KPGJyPg0KTWlub3IgSXNzdWVzOjxicj4NCjxicj4NClNlY3Rp b24gMSBJbnRyb2R1Y3Rpb248YnI+DQo8YnI+DQpUaGUgYWNyb255bSBMU0RCIGlzIG5vdCBkZWZp bmVkLjxicj4NCjxicj4NCkZpZ3VyZSAxPGJyPg0KPGJyPg0KSSBoYXZlIGEgcGVyc29uYWwgZGlz bGlrZSBmb3IgZHVwbGljYXRpbmcgdGV4dC9waWN0dXJlcyBmcm9tIGFub3RoZXI8YnI+DQpzcGVj IHdoZW4gdGhhdCBzcGVjIGNvdWxkIHNpbXBseSBiZSByZWZlcmVuY2VkLiBUaGVyZSBhcmUgb25s eSB0d288YnI+DQpwb3NzaWJsZSBvdXRjb21lczo8YnI+DQo8YnI+DQoxKVRoZSBkdXBsaWNhdGVk IHRleHQgaXMgcmVkdW5kYW50IChiZXN0IGNhc2UpPGJyPg0KMilUaGUgdGV4dCBkaWZmZXJzIHNv bWV3aGF0IGZyb20gdGhlIG9yaWdpbmFsIGxlYWRpbmcgdG8gcG9zc2libGU8YnI+DQp1bmludGVu dGlvbmFsIG1pc2ludGVycHJldGF0aW9ucy48YnI+DQo8YnI+DQpTdWl0IHlvdXJzZWxmIG9uIHRo aXMgY29tbWVudCAtIGJ1dCBJIHdvdWxkIHByZWZlciB0aGUgZHVwbGljYXRpb24gYmUgb21pdHRl ZC48YnI+DQo8YnI+DQpTZWN0aW9uIDIgRmlyc3QgcGFyYWdyYXBoPGJyPg0KPGJyPg0KWW91IHJl ZmVyIHRvICZxdW90O3N1Yi1UTFYmcXVvdDsgYnV0IHRoYXQgcmVmZXJlbmNlIGlzIHVuY2xlYXIg YW5kIGFtYmlndW91cy48YnI+DQpJUy1JUyB1c2VzIGEgc3ViLVRMViBvZiBSb3V0ZXIgQ2FwYWJp bGl0eSB0byBhZHZlcnRpc2UgdGFncywgYnV0IE9TUEY8YnI+DQp1c2VzIGEgVExWIG9mIFJvdXRl ciBJbmZvIExTQS48YnI+DQpXaGF0IHNlZW1zIG1vc3QgcmVsZXZhbnQgaGVyZSBpcyB0aGF0IHlv dSBhcmUgZGVmaW5pbmcgYSBuZXcgQXR0cmlidXRlPGJyPg0KVExWIGZvciBOb2RlIE5MUkkuPGJy Pg0KPGJyPg0KU2VjdGlvbiAzIFNlY29uZCBwYXJhZ3JhcGg8YnI+DQo8YnI+DQpJIGRvIG5vdCBr bm93IHdoYXQgdGhlIHBhcmFncmFwaCBpcyB0cnlpbmcgdG8gc2F5LCBub3IgZG88YnI+DQpJIGtu b3cgd2hhdCB0aGUgJnF1b3Q7VEJEJnF1b3Q7IGluIGNvbHVtbnMgNCBhbmQgNSBpbiB0aGUgZm9s bG93aW5nIFRhYmxlIDEgaXM8YnI+DQptZWFudCB0byByZWZlcmVuY2UuIElmIHlvdSBhcmUgc2lt cGx5IHRyeWluZyB0byBkZXNjcmliZSB0aGUgc291cmNlPGJyPg0Kb2YgdGhlIGluZm8gYWR2ZXJ0 aXNlZCBieSB0aGUgbmV3IEJHUC1MUyBOb2RlIGF0dHJpYnV0ZSB0aGVuIHlvdSBzaG91bGQ8YnI+ DQpyZXdyaXRlIHRoZSBhYm92ZSBwYXJhZ3JhcGggYW5kIGluIHRoZSBmaWd1cmUgYmVsb3cgc2hv dzo8YnI+DQo8YnI+DQpJUy1JUyAyNDIvMjE8YnI+DQpPU1BGIFJJLUxTQS8xMDxicj4NCjxicj4N ClNlY3Rpb24gMy4xPGJyPg0KPGJyPg0KQSBkZXNjcmlwdGlvbiBvZiB3aGVyZSBpbiB0aGUgTm9k ZSBOTFJJIHRoZSBhcmVhL2xldmVsIGluZm9ybWF0aW9uIGNhbiBiZSBmb3VuZDxicj4NCihmcm9t IFJGQyA3NzUyKSB3b3VsZCBiZSBoZWxwZnVsLjxicj4NCjxicj4NCjxicj4NClNlY3Rpb24gMy4x IFBlbnVsdGltYXRlIFBhcmFncmFwaDxicj4NCjxicj4NCkFzIFRBR3Mgd2l0aCAmcXVvdDtnbG9i YWwmcXVvdDsgc2NvcGUgd2lsbCBiZSBhZHZlcnRpc2VkIGJ5IHRoZSBJR1AgbXVsdGlwbGU8YnI+ DQp0aW1lcyAob25jZSBwZXIgYXJlYS9sZXZlbCkgSSBhc3N1bWUgeW91IGFyZSBhc2tpbmcgQkdQ LUxTIGFkdmVydGlzZW1lbnRzPGJyPg0KdG8gcmVkdWNlIHRoZXNlIG11bHRpcGxlIG9jY3VycmVu Y2VzIHRvIGEgc2luZ2xlIG9jY3VycmVuY2U/IE1vcmU8YnI+DQpleHBsaWNpdCBsYW5ndWFnZSBv biB0aGF0IHBvaW50IHdvdWxkIGJlIGhlbHBmdWwuPGJyPg0KPGJyPg0KU2VjdGlvbiAzLjEgTGFz dCBwYXJhZ3JhcGg8YnI+DQo8YnI+DQpJIHJlY29nbml6ZSB0aGlzIHN0YXRlbWVudCByZWdhcmRp bmcgcG9saWN5IGJlaW5nIHVzZWQgdG8gZmlsdGVyIHdoYXQgaXM8YnI+DQphZHZlcnRpc2VkIGlz IGNvbnNpc3RlbnQgd2l0aCBSRkMgNzc1Mi4gQnV0IGl0IHdvdWxkIGFsc28gYmUgZ29vZCB0byBp bmNsdWRlPGJyPg0KYSBzdGF0ZW1lbnQgbGlrZTo8YnI+DQo8YnI+DQomcXVvdDtEZWZpbml0aW9u IG9mIHN1Y2ggYSBwb2xpY3kgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4m cXVvdDs8YnI+DQo8YnI+DQpOaXRzOiBQbGVhc2Ugc2VlIGF0dGFjaGVkIGRpZmYgZmlsZSB3aXRo IHNvbWUgZWRpdG9yaWFsIGNvcnJlY3Rpb25zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_d144ee9836fa49c5b71f761ae036cb69XCHALN001ciscocom_-- From nobody Sun Jul 16 07:36:37 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B744212EB99; Sun, 16 Jul 2017 07:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.346 X-Spam-Level: ** X-Spam-Status: No, score=2.346 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 dKvTmyFF3gMl; Sun, 16 Jul 2017 07:36:29 -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 D027C129B5E; Sun, 16 Jul 2017 07:36:28 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=31.133.153.78; From: "Susan Hares" To: "'idr@ietf. org'" Cc: , "'Stefano Previdi \(sprevidi\)'" , "'Hannes Gredler'" , "'Mach Chen'" , "'Dongjie \(Jimmy\)'" , "'Clarence Filsfils \(cfilsfil\)'" Date: Sun, 16 Jul 2017 10:30:14 -0400 Message-ID: <001401d2fe40$0b2a9db0$217fd910$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01D2FE1E.84194BD0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AdL+P70mae4rLOdjTaS/cqwHO+49oQ== X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] IPR Call for draft-ietf-idr-bgp-ls-segment-routing-ext prior to WG LC X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 14:36:31 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0015_01D2FE1E.84194BD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Stefano, Hannes, Mach, Clarence: This begins an IPR call for draft-ietf-idr-bgp-ls-segment-routing-ext prior to WG LC. Please indicate if you know of any IPR regarding this draft. After all authors respond, we will start WG LC. Susan Hares PS - Please note that John Scudder started a WG early adoption call in another thread. Please respond to the IPR request for the WG LC on this thread. ------=_NextPart_000_0015_01D2FE1E.84194BD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stefano, = Hannes, Mach, Clarence:

 

This begins = an IPR call for draft-ietf-idr-bgp-ls-segment-routing-ext prior to WG = LC.   Please indicate if you know of any IPR regarding this = draft.  After all authors respond, we will start WG LC. =   

 

Susan Hares

 

PS – = Please note that John Scudder started a WG early adoption call in = another thread.  Please respond to the IPR request for the WG LC on = this thread.

      

------=_NextPart_000_0015_01D2FE1E.84194BD0-- From nobody Sun Jul 16 07:40:25 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D80E127342 for ; Sun, 16 Jul 2017 07:40:23 -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] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=previdi-net.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 xOO0v7cIORH9 for ; Sun, 16 Jul 2017 07:40:21 -0700 (PDT) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (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 57D3C126D73 for ; Sun, 16 Jul 2017 07:40:21 -0700 (PDT) Received: by mail-wm0-x244.google.com with SMTP id 15so6910337wmm.3 for ; Sun, 16 Jul 2017 07:40:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=previdi-net.20150623.gappssmtp.com; s=20150623; h=date:user-agent:in-reply-to:references:mime-version :content-transfer-encoding:subject:to:cc:from:message-id; bh=CVIpejdlG8aKsrjXrDMO5Goo7Z/IZXhL8ANf63k/NZg=; b=XET14GTCUbV73voXnE0lajesJZkmRCka/dRqz/2HJgBJn5c9ZbhUTgyzm3cEnQksRW x/aFyNdASc/iMC3y6tFfWAEz4fWYKDirxu+fuAtWk3FEhc2A2s00NxOVeCT6QAKAmcLx X2zdr7I38Dql3VaR6f52bvmSmUzQmaQr5A0AGnTAHYW4+QKnWG8cl3XBj6J2YC6eYLhh 8oy5a43UVSW7ezvN6FKqQv7GH06IVgpBElbIiur7fXR5mmqnNJBZHXt1Zm1CQRe0Omb+ ofSomNR9CrWWl3Ggkd+aSb8vki4tqczCBkcm/aadMENddkoxh3yNX00TGt/fG890xUTF WzaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:user-agent:in-reply-to:references :mime-version:content-transfer-encoding:subject:to:cc:from :message-id; bh=CVIpejdlG8aKsrjXrDMO5Goo7Z/IZXhL8ANf63k/NZg=; b=eUdVtTmQkCWybPbZ7fCIIwmcoowhw/X+TTQBzKejR8kv2PFaFXDC6mhD5MWI4kZJ4o tkwDoI5fupuS64TXmGJ4beTFtHO8U4cGAzgudMCTM/vDb7ytaWiH/vugOiZQY6konZvK IyXAgWDBGLyddsgXW8kd56sSXe5fC2gOP5/9m0oAMVSHuGyyyVRszWnPoA3ACrYkRmZP SWHHXUzuTzS9kmpRPMtVN3vFPlcRxypNX6hzFvGqo+Kd1KZY7R2I6T4sSTGO7MhGdEUB fhKMtuuBn6sIHQbZAxazzGJz1ABlESbIXSKONQOtQstATWdcPdjdfbbLGR4FDcE15Q5M C3Ig== X-Gm-Message-State: AIVw112PMeNLQsC9/v2tZxXTKxUQv27RKgGc+x+jPffxPsrHY3m8N+yc Hz+/DsnUUj7EtvKJ X-Received: by 10.28.203.79 with SMTP id b76mr1665681wmg.81.1500216019766; Sun, 16 Jul 2017 07:40:19 -0700 (PDT) Received: from [192.168.0.100] (host162-156-dynamic.57-82-r.retail.telecomitalia.it. [82.57.156.162]) by smtp.gmail.com with ESMTPSA id i32sm27736447wra.5.2017.07.16.07.40.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 16 Jul 2017 07:40:18 -0700 (PDT) Date: Sun, 16 Jul 2017 16:40:05 +0200 User-Agent: K-9 Mail for Android In-Reply-To: <001401d2fe40$0b2a9db0$217fd910$@ndzh.com> References: <001401d2fe40$0b2a9db0$217fd910$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----G889GF8872DH91M7JL2B40S4SIX6T5" Content-Transfer-Encoding: 7bit To: Susan Hares ,"'idr@ietf. org'" CC: draft-ietf-idr-bgp-ls-segment-routing-ext@ietf.org, "'Stefano Previdi (sprevidi)'" , 'Hannes Gredler' , 'Mach Chen' , "'Dongjie (Jimmy)'" , "'Clarence Filsfils (cfilsfil)'" From: Stefano Previdi Message-ID: <221CE525-2A99-4571-BE33-485B246C3E17@previdi.net> Archived-At: Subject: Re: [Idr] IPR Call for draft-ietf-idr-bgp-ls-segment-routing-ext prior to WG LC X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 14:40:23 -0000 ------G889GF8872DH91M7JL2B40S4SIX6T5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I'm not aware of any IPR related to this draft=2E s=2E On July 16, 2017 4:30:14 PM GMT+02:00, Susan Hares wro= te: >Stefano, Hannes, Mach, Clarence:=20 > >=20 > >This begins an IPR call for draft-ietf-idr-bgp-ls-segment-routing-ext >prior >to WG LC=2E Please indicate if you know of any IPR regarding this >draft=2E >After all authors respond, we will start WG LC=2E =20 > >=20 > >Susan Hares > >=20 > >PS - Please note that John Scudder started a WG early adoption call in >another thread=2E Please respond to the IPR request for the WG LC on >this >thread=2E=20 > > =20 ------G889GF8872DH91M7JL2B40S4SIX6T5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi,

I'm not aware of any IPR related to this draft=2E

s=2E

On July 16, 2017 4:30:14 PM GMT+02:= 00, Susan Hares <shares@ndzh=2Ecom> wrote:

Stefano, Hannes, Mach, = Clarence:

 

This begins an IPR call for draft-ietf-idr-bgp-ls-segment-routing-= ext prior to WG LC=2E   Please indicate if you know of any IPR re= garding this draft=2E  After all authors respond, we will start WG LC= =2E   

 

Susan Hares

 

PS – Please note that John Scudder started a= WG early adoption call in another thread=2E  Please respond to the IP= R request for the WG LC on this thread=2E

      

------G889GF8872DH91M7JL2B40S4SIX6T5-- From nobody Sun Jul 16 16:12:52 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52ACD129562 for ; Sun, 16 Jul 2017 16:12:51 -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 lMOCJGnK1rME for ; Sun, 16 Jul 2017 16:12:50 -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 258ED1200C1 for ; Sun, 16 Jul 2017 16:12:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2027; q=dns/txt; s=iport; t=1500246770; x=1501456370; h=subject:references:to:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=vuSO3ssPn58GiemZOwZ/7r+bGJSO26pVo/6w+XXUINQ=; b=OcvCMJSsbT44y+2xXmynOgrmxNsCIxaK9rlA51KKfgyGAbZ6zixFg1Yk HjBUnq31eW1RJ+aMUmPhK/mvbCldMmyVBzP9qBP3r1cuRT5iYHgVYN9kq mjDskLnF0swhitky9nKM/pVif/hYwOYuSzrvXEBnVRiP4ubP0yi1vjUKD 4=; X-IronPort-AV: E=Sophos;i="5.40,371,1496102400"; d="scan'208";a="274383403" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Jul 2017 23:12:49 +0000 Received: from [10.24.21.51] ([10.24.21.51]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v6GNCmLX019867; Sun, 16 Jul 2017 23:12:49 GMT References: <150024582910.32415.1807192204466699245@ietfa.amsl.com> To: "idr@ietf.org" Cc: Enke Chen , Naiming Shen , Robert Raszuk From: Enke Chen X-Forwarded-Message-Id: <150024582910.32415.1807192204466699245@ietfa.amsl.com> Message-ID: <1840203b-a02f-deef-4299-3fe64aee033d@cisco.com> Date: Sun, 16 Jul 2017 16:12:48 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <150024582910.32415.1807192204466699245@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Idr] Fwd: I-D Action: draft-chen-bfd-unsolicited-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 23:12:51 -0000 Hi, Folks: Here is a proposal for "unsolicited bfd". We (the authors) believe that "add-path + unsolicited bfd" is a simper solution to the nexthop liveness issue at the IXP with Route Servers. Thanks. -- Enke -------- Forwarded Message -------- Subject: I-D Action: draft-chen-bfd-unsolicited-00.txt Date: Sun, 16 Jul 2017 15:57:09 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Unsolicited BFD for Sessionless Applications Authors : Enke Chen Naiming Shen Robert Raszuk Filename : draft-chen-bfd-unsolicited-00.txt Pages : 6 Date : 2017-07-16 Abstract: For operational simplification of "sessionless" applications using BFD, in this document we present procedures for "unsolicited BFD" that allow a BFD session to be initiated by only one side, and be established without explicit per-session configuration or registration by the other side (subject to certain per-interface or per-router policies). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-chen-bfd-unsolicited/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-chen-bfd-unsolicited-00 https://datatracker.ietf.org/doc/html/draft-chen-bfd-unsolicited-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 Sun Jul 16 18:45:54 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCC9131537 for ; Sun, 16 Jul 2017 18:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.801 X-Spam-Level: X-Spam-Status: No, score=-3.801 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_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, 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=umn.edu 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 UyHDhPaYsuI4 for ; Sun, 16 Jul 2017 18:45:51 -0700 (PDT) Received: from mta-p5.oit.umn.edu (mta-p5.oit.umn.edu [134.84.196.205]) (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 D8F44131532 for ; Sun, 16 Jul 2017 18:45:50 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id 3749496F for ; Mon, 17 Jul 2017 01:45:50 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p5.oit.umn.edu ([127.0.0.1]) by localhost (mta-p5.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0sFLd-dIdiD for ; Sun, 16 Jul 2017 20:45:50 -0500 (CDT) Received: from mail-io0-f197.google.com (mail-io0-f197.google.com [209.85.223.197]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p5.oit.umn.edu (Postfix) with ESMTPS id F0910909 for ; Sun, 16 Jul 2017 20:45:49 -0500 (CDT) Received: by mail-io0-f197.google.com with SMTP id n64so66729447ioo.4 for ; Sun, 16 Jul 2017 18:45:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8pvSMbNiTI+B8flJi/EKr6fd0M0R4e361TdNAGN324o=; b=Odf6lV9TeKMpjR2KNJWSdf1725OUgIOdIXil8uJtrnK+doqdchjdSujqp9d/1539mL DdZ2Z85I82WcM2Lm3wD0HyMbj5B+x3HdofeeYXHKJolIuXChXozvUfz7itKoHHWKbejZ cjs/k04GRoRU2pquaLLGHp+i8DRjtcAp2IKGEdGONnN0cZ4OIZXZBGakvlFvt7YaeI49 FFRt4IFUNyIyvh9SL3MO3bRxU9cVxzGF2iiosUDRHipdfOsc0UMY72D5P82bRXhm8d3Y KmIHObuYvcQCiQGFlf9hLTDs6yDxSvhDrtqkkqvvg8pYmFjK766dO/PCuDmKmv0l8Urc rpaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8pvSMbNiTI+B8flJi/EKr6fd0M0R4e361TdNAGN324o=; b=JrW6GH+2JBuu9rhcIvjH+t3M/o2W0y8rv9j2Q/VFJxVnd/Wn+JXw9ImQNczeDZAk6X QY5nP+M5F2sPLc3L6WXSRpnQ0Y9B8lT+/tInrM7pqHM1A6a88pxzz1xEiv8Kt9jZNSmQ jaiwAf1BUvYFUKS5w+mowjPe+MXkYixvfBSmUAmrF+pWuSSNyr++E6UCJichEuyd7KvU RezI76kj3lhtwJtJGMaYmzWOreG2E8UhBYqb5EFRL9cT9hwA7J0utC0/Zhi6OiDQ+tBo xSO+eunuoIKwbcevj6uHt0pkmcrDKcLYCTV9Ls2rGgIPi0GC9N2bf0TjC/eklAoEAM0E meLw== X-Gm-Message-State: AIVw1135icIfpjWQ8L61cLPC07t6VGWIVMOhCsP55IsYz7uRBhwxTN/+ QMvAgw0XFDnX/Z9icfL5XIhI4DMBz842kJXdctQKV2eEGiqQRSmTLgCE2wTJSAxaMZWNfArr7g= = X-Received: by 10.107.130.195 with SMTP id m64mr18247701ioi.145.1500255949239; Sun, 16 Jul 2017 18:45:49 -0700 (PDT) X-Received: by 10.107.130.195 with SMTP id m64mr18247697ioi.145.1500255949080; Sun, 16 Jul 2017 18:45:49 -0700 (PDT) Received: from [172.20.20.20] ([73.94.200.205]) by smtp.gmail.com with ESMTPSA id 95sm8373928ios.36.2017.07.16.18.45.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 16 Jul 2017 18:45:48 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: David Farmer X-Mailer: iPhone Mail (14F89) In-Reply-To: <1840203b-a02f-deef-4299-3fe64aee033d@cisco.com> Date: Sun, 16 Jul 2017 20:45:47 -0500 Cc: "idr@ietf.org" , Robert Raszuk Content-Transfer-Encoding: quoted-printable Message-Id: <9F5A4248-CEC9-4B45-BC85-CA5B329C567E@umn.edu> References: <150024582910.32415.1807192204466699245@ietfa.amsl.com> <1840203b-a02f-deef-4299-3fe64aee033d@cisco.com> To: Enke Chen Archived-At: Subject: Re: [Idr] Fwd: I-D Action: draft-chen-bfd-unsolicited-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 01:45:52 -0000 Sent from my iPhone > On Jul 16, 2017, at 18:12, Enke Chen wrote: >=20 > Hi, Folks: >=20 > Here is a proposal for "unsolicited bfd". We (the authors) believe that > "add-path + unsolicited bfd" is a simper solution to the nexthop liveness > issue at the IXP with Route Servers. >=20 > Thanks. -- Enke Unless I missed something one side or the other actually has to actually be c= onfigured to initiate the BFD session, otherwise two peers at an IX are perf= ectly willing to do BFD but there will be no active BFD sessions between the= m. No doubt, this is better that both sides having to configure BFD, but is n= ot the fully automated solution that I and I think others are looking for. I'm fine with using add-path with the IX RS, but I want automatic initiation= of the BFD sessions within the IX, and a mechanism to at least prefer next-= hops that are doing BFD with me, over ones that won't or aren't, if not out r= ight ignore next-hops that won't do BFD with me. Thanks David Farmer= From nobody Sun Jul 16 19:20:41 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A39212ECC8 for ; Sun, 16 Jul 2017 19:20:39 -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 ISBLvYfPBDRg for ; Sun, 16 Jul 2017 19:20:38 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBB4A12EC05 for ; Sun, 16 Jul 2017 19:20:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1412; q=dns/txt; s=iport; t=1500258037; x=1501467637; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=ZeHVLiZ3xPtG9a3gglqAm5xja66hkhzjXDKgtWPMpCs=; b=l0fbe+MS6pT2LYzRWMIupov6iishUs/2PjgWni0A+aOjFQQsLjN6kD3S VY6OGckiIM5tYg/5SrHP0iZRinSdaENP+yyUuj/VKCMcQaqmXsqLC5FZy OZz+6mf/miGMnA/vdRzpGtGJ3w8NqQqeLF9xvPBRowyuUtYYUmdx7UYC4 4=; X-IronPort-AV: E=Sophos;i="5.40,372,1496102400"; d="scan'208";a="270765818" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Jul 2017 02:20:37 +0000 Received: from [10.24.21.51] ([10.24.21.51]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v6H2KaiO016449; Mon, 17 Jul 2017 02:20:37 GMT To: David Farmer References: <150024582910.32415.1807192204466699245@ietfa.amsl.com> <1840203b-a02f-deef-4299-3fe64aee033d@cisco.com> <9F5A4248-CEC9-4B45-BC85-CA5B329C567E@umn.edu> Cc: "idr@ietf.org" , Robert Raszuk , Enke Chen , Naiming Shen From: Enke Chen Message-ID: Date: Sun, 16 Jul 2017 19:20:35 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <9F5A4248-CEC9-4B45-BC85-CA5B329C567E@umn.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Idr] Fwd: I-D Action: draft-chen-bfd-unsolicited-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 02:20:39 -0000 Hi, David: For deployment I think that the only new config would be to enable the "unsolicited bfd" feature on the interface attached to the IXP (and "ttl" check if not the default). BFD sessions would be established with the nexthops dynamically, and without configuring BFD peers. Thanks. -- Enke On 7/16/17 6:45 PM, David Farmer wrote: > > > Sent from my iPhone > >> On Jul 16, 2017, at 18:12, Enke Chen wrote: >> >> Hi, Folks: >> >> Here is a proposal for "unsolicited bfd". We (the authors) believe that >> "add-path + unsolicited bfd" is a simper solution to the nexthop liveness >> issue at the IXP with Route Servers. >> >> Thanks. -- Enke > > Unless I missed something one side or the other actually has to actually be configured to initiate the BFD session, otherwise two peers at an IX are perfectly willing to do BFD but there will be no active BFD sessions between them. No doubt, this is better that both sides having to configure BFD, but is not the fully automated solution that I and I think others are looking for. > > I'm fine with using add-path with the IX RS, but I want automatic initiation of the BFD sessions within the IX, and a mechanism to at least prefer next-hops that are doing BFD with me, over ones that won't or aren't, if not out right ignore next-hops that won't do BFD with me. > > Thanks > > David Farmer > From nobody Sun Jul 16 23:28:44 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2788E130154; Sun, 16 Jul 2017 23:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.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 rMxz0BG2GFIG; Sun, 16 Jul 2017 23:28:41 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A77E912ECF0; Sun, 16 Jul 2017 23:28:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=767; q=dns/txt; s=iport; t=1500272921; x=1501482521; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=wwh8xQmSq09kwW/8ySraoFJ4FdhFd01rEqZZl3DritI=; b=ONuYG5T4CfRbIxiKh2p1aSZdpaDmiO6F8HYwlGPGbAGiQWRIoSpL3FUf PpxBwbWZpgvAZJNLmNKqDVhj5w+GMWNO8uqjpkPo4KFSZhGKRPICmc7s7 T60RdwnQD6W4PI1Gg3/cCi/PGJ7unsAy8VJqNQNNPQzKpY07xD+iKCXxB U=; X-IronPort-AV: E=Sophos;i="5.40,373,1496102400"; d="scan'208";a="656134969" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jul 2017 06:28:39 +0000 Received: from [10.61.101.3] (dhcp-10-61-101-3.cisco.com [10.61.101.3]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v6H6ScNX030011; Mon, 17 Jul 2017 06:28:38 GMT To: Stefano Previdi , Susan Hares , "'idr@ietf. org'" References: <001401d2fe40$0b2a9db0$217fd910$@ndzh.com> <221CE525-2A99-4571-BE33-485B246C3E17@previdi.net> Cc: draft-ietf-idr-bgp-ls-segment-routing-ext@ietf.org, "'Stefano Previdi (sprevidi)'" , "'Hannes Gredler'" , "'Mach Chen'" , "'Dongjie (Jimmy)'" From: Clarence Filsfils Message-ID: <97d39884-653e-786a-a6fc-8d6522b3c3c4@cisco.com> Date: Mon, 17 Jul 2017 08:28:38 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <221CE525-2A99-4571-BE33-485B246C3E17@previdi.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Idr] IPR Call for draft-ietf-idr-bgp-ls-segment-routing-ext prior to WG LC X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 06:28:42 -0000 I'm not aware of any IPR related to this draft. Cheers, Clarence On 16-Jul-17 16:40, Stefano Previdi wrote: > Hi, > > I'm not aware of any IPR related to this draft. > > s. > > On July 16, 2017 4:30:14 PM GMT+02:00, Susan Hares wrote: > > Stefano, Hannes, Mach, Clarence: > > > > This begins an IPR call for > draft-ietf-idr-bgp-ls-segment-routing-ext prior to WG LC. Please > indicate if you know of any IPR regarding this draft. After all > authors respond, we will start WG LC. > > > > Susan Hares > > > > PS – Please note that John Scudder started a WG early adoption call > in another thread. Please respond to the IPR request for the WG LC > on this thread. > > > From nobody Mon Jul 17 00:51:40 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 000D3131A80 for ; Mon, 17 Jul 2017 00:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtbrick.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 O_E_OtUdPYEK for ; Mon, 17 Jul 2017 00:51:36 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B78A2131A63 for ; Mon, 17 Jul 2017 00:51:35 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id 70so20353358wmo.1 for ; Mon, 17 Jul 2017 00:51:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtbrick.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3cLDtyU/Ngw57NP5SH/9s8hiLbguKE8G7Sdl8otx/C4=; b=WxOs6MjJAgkD0T447BmPA6F0S/tncNwSTvfvZ0BHBtS1AMilPmCWrBGhlkug59Qqvs qjQ+sOLltAKFp1FkFGxOIuylwUuvmahiIFl9u37/RListxWpjCnhXn+YnCfqKt4CqBFl qb4kn4D4Ww+A6T68PeU+nxOKLzIERj0pkXAtb/lPZ0KBns/ZpOM3lxV/goV5aeNxjeNk k7ur6oec9szGqXyh236RzBnbsCQXD2Ytn1VTPJS2Yas1NQsyW9dM/1NE9BPOtk4bgaJ4 2mymLUVkRd2KNG0oS6XKwIkdWS+pVnLrqw87sGvBUVRpalRbYgOkm0xOTVI6I4f8wol4 IJBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3cLDtyU/Ngw57NP5SH/9s8hiLbguKE8G7Sdl8otx/C4=; b=tsdbtnlKTC2yJrdwGbYiqn1vTYpWPQ79408PSBDoIb8D2tkdvbSoEMjLKhCPLRI0cz R+3C2ShNNX06JdRGmceXnomRoFpfWP+uReTr+1ibNXrcK7FqxiRmTFS5r1uZRDGJ06J9 GuIbtGvPkCk2zafNr1xv9sNADtlnl1mwnRSZPrhsYNV1NoWXzzgvz8HMWDAzkIZXqh3m mVLdcEIfEKMHk4Qip+iT687/dqDrCLGcaCR39kSzxNNMP0P4U+vPkxMjwikNh9bPJX2p BHkPOnjZAuAfLzg9zZ7GlFdkRwnNU12jzf/eVBYR/1d/DzcS/DieZN/RVi7asdcDCjcj Fp2w== X-Gm-Message-State: AIVw113VLdlo0W8sEumXp+7WYrg45beJ2NTFYd2boYCCQz2SYyRloQRe CvcThOF7A9KaqWT3 X-Received: by 10.28.109.218 with SMTP id b87mr3697597wmi.125.1500277894322; Mon, 17 Jul 2017 00:51:34 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:961:6e4a:effa:7709? ([2001:67c:370:128:961:6e4a:effa:7709]) by smtp.gmail.com with ESMTPSA id 185sm12780447wmn.33.2017.07.17.00.51.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Jul 2017 00:51:33 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-7CB7B3D8-9212-42DA-9E4F-08B6FFB38987 Mime-Version: 1.0 (1.0) From: Hannes Gredler X-Mailer: iPhone Mail (14E277) In-Reply-To: <001401d2fe40$0b2a9db0$217fd910$@ndzh.com> Date: Mon, 17 Jul 2017 09:51:32 +0200 Cc: "idr@ietf. org" , draft-ietf-idr-bgp-ls-segment-routing-ext@ietf.org, "Stefano Previdi (sprevidi)" , Mach Chen , "Dongjie (Jimmy)" , "Clarence Filsfils (cfilsfil)" Content-Transfer-Encoding: 7bit Message-Id: References: <001401d2fe40$0b2a9db0$217fd910$@ndzh.com> To: Susan Hares Archived-At: Subject: Re: [Idr] IPR Call for draft-ietf-idr-bgp-ls-segment-routing-ext prior to WG LC X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 07:51:38 -0000 --Apple-Mail-7CB7B3D8-9212-42DA-9E4F-08B6FFB38987 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable not aware of any IPR. - /hannes > On 16 Jul 2017, at 16:30, Susan Hares wrote: >=20 > Stefano, Hannes, Mach, Clarence: > =20 > This begins an IPR call for draft-ietf-idr-bgp-ls-segment-routing-ext prio= r to WG LC. Please indicate if you know of any IPR regarding this draft. A= fter all authors respond, we will start WG LC. =20 > =20 > Susan Hares > =20 > PS =E2=80=93 Please note that John Scudder started a WG early adoption cal= l in another thread. Please respond to the IPR request for the WG LC on thi= s thread. > =20 --Apple-Mail-7CB7B3D8-9212-42DA-9E4F-08B6FFB38987 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
not aware of any IPR. - /ha= nnes

Stefano, Hannes, Mach, Clarence:

 

This begins an IPR call for d= raft-ietf-idr-bgp-ls-segment-routing-ext prior to WG LC.   Please i= ndicate if you know of any IPR regarding this draft.  After all authors= respond, we will start WG LC.   

 

Susan Hares

<= p class=3D"MsoNormal"> 

PS =E2=80=93= Please note that John Scudder started a WG early adoption call in another t= hread.  Please respond to the IPR request for the WG LC on this thread.=

      <= o:p>

= --Apple-Mail-7CB7B3D8-9212-42DA-9E4F-08B6FFB38987-- From nobody Mon Jul 17 01:47:01 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8376131B0D; Mon, 17 Jul 2017 01:46:59 -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 9eOhNy-ORoDr; Mon, 17 Jul 2017 01:46:58 -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 E2DAC131A8E; Mon, 17 Jul 2017 01:46:57 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=31.133.141.64; From: "Susan Hares" To: "'Hannes Gredler'" Cc: "'idr@ietf. org'" , "'Clarence Filsfils \(cfilsfil\)'" , References: <001401d2fe40$0b2a9db0$217fd910$@ndzh.com> In-Reply-To: Date: Mon, 17 Jul 2017 04:40:56 -0400 Message-ID: <00eb01d2fed8$6a25d120$3e717360$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EC_01D2FEB6.E3171750" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJKUAU+iv5LNhwm5dm43XFXKsAGggL6d59yoVE84+A= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] IPR Call for draft-ietf-idr-bgp-ls-segment-routing-ext prior to WG LC X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 08:47:00 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00EC_01D2FEB6.E3171750 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Thank you Hannes. I am still missing Mach=E2=80=99s IPR statement.=20 =20 Sue=20 =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Hannes Gredler Sent: Monday, July 17, 2017 3:52 AM To: Susan Hares Cc: idr@ietf. org; Clarence Filsfils (cfilsfil); = draft-ietf-idr-bgp-ls-segment-routing-ext@ietf.org Subject: Re: [Idr] IPR Call for = draft-ietf-idr-bgp-ls-segment-routing-ext prior to WG LC =20 not aware of any IPR. - /hannes On 16 Jul 2017, at 16:30, Susan Hares wrote: Stefano, Hannes, Mach, Clarence:=20 =20 This begins an IPR call for draft-ietf-idr-bgp-ls-segment-routing-ext = prior to WG LC. Please indicate if you know of any IPR regarding this = draft. After all authors respond, we will start WG LC. =20 =20 Susan Hares =20 PS =E2=80=93 Please note that John Scudder started a WG early adoption = call in another thread. Please respond to the IPR request for the WG LC = on this thread.=20 =20 ------=_NextPart_000_00EC_01D2FEB6.E3171750 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Thank you Hannes. =C2=A0=C2=A0I am still missing = Mach=E2=80=99s IPR statement.

 

Sue =

 

From:= = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Hannes = Gredler
Sent: Monday, July 17, 2017 3:52 AM
To: = Susan Hares
Cc: idr@ietf. org; Clarence Filsfils (cfilsfil); = draft-ietf-idr-bgp-ls-segment-routing-ext@ietf.org
Subject: = Re: [Idr] IPR Call for draft-ietf-idr-bgp-ls-segment-routing-ext prior = to WG LC

 

not = aware of any IPR. - /hannes


On 16 Jul 2017, at = 16:30, Susan Hares <shares@ndzh.com> = wrote:

Stefano, Hannes, Mach, Clarence:

 

This begins = an IPR call for draft-ietf-idr-bgp-ls-segment-routing-ext prior to WG = LC.   Please indicate if you know of any IPR regarding this = draft.  After all authors respond, we will start WG LC. =   

 

Susan Hares

 

PS =E2=80=93 = Please note that John Scudder started a WG early adoption call in = another thread.  Please respond to the IPR request for the WG LC on = this thread.

      

------=_NextPart_000_00EC_01D2FEB6.E3171750-- From nobody Mon Jul 17 01:51:15 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53484131771 for ; Mon, 17 Jul 2017 01:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 s4iBWPR4rjj4 for ; Mon, 17 Jul 2017 01:51:11 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D314F131B15 for ; Mon, 17 Jul 2017 01:51:11 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id h64so39566372iod.0 for ; Mon, 17 Jul 2017 01:51:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=adVplvgw0zq4taASxDF1fGJIDxm8yFKOfDi3wlJIxGw=; b=VsrJUUsDvMKQXHAhxJzNiAAoycIvnpJhNykkpTfQ1LimkZB5z/o+N+Z/7tWHfyMRXc JZwejW4zahq3/zwPnAIboZsvUiOSEHUQQP3Vbo6bCkX2s3ESef+Ml/huROJIVjA96fL2 geBXAAF6nGVuwESReQTWbcg/pf8qYDC6Wwm+IRfXYCP35MAS40YrMGj9U4uySTgIMq1l u89+qU5cWgwdjCR9xLRJ/CdeOM2u6InZkCkY9vmd6IORoH4BtScUQAZ0bzf5APu5ws3n iZoOTNudQodxsoSrwnP2lCb5+7wCUqYw6RCigqUlqNjMrraoSv25RMKfT6ru9/ySEzNy oxUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=adVplvgw0zq4taASxDF1fGJIDxm8yFKOfDi3wlJIxGw=; b=G7qKEYa0XuL8VwBj1nbiw3ASkWWtEpEAKupsaY+Ub0cTiJjC+W5gosOBTBQvohz51+ 0JvhgB2V2ypcL2ZsU8sgAfboBMlxfjhBLIk4ImsysC6qqk0+zng/4KIGgPNBi+R24Ofp 8BKxjOJTfTp+x8a2y/8Z+xhsgscVRVLUJhANWVk9AXLdsrqewOei7QZd73MK3scsj+51 16oDkukqSJvR2XSLhKmBAS3/dVNISAg6dkQ3rvHxxuoV0+kEKdQp0LNDxUGEOhtB2+0G TkTtgRCmioYVLeb4EDxRPqG4Jg0j8MZp0xtAwIxNfoHT8vHVNksWBcNXbIJzPCCmX70K wkBw== X-Gm-Message-State: AIVw110MF0TQS4VfYp3AmbS2bcWAyxGfbGO7I6MuyR1Lx7tdz5jGFdfm 89lUBleud5OuoFUQyLPYdq8iAg5Scw== X-Received: by 10.107.20.135 with SMTP id 129mr18703788iou.132.1500281471052; Mon, 17 Jul 2017 01:51:11 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.153.21 with HTTP; Mon, 17 Jul 2017 01:51:10 -0700 (PDT) Received: by 10.79.153.21 with HTTP; Mon, 17 Jul 2017 01:51:10 -0700 (PDT) In-Reply-To: References: <150024582910.32415.1807192204466699245@ietfa.amsl.com> <1840203b-a02f-deef-4299-3fe64aee033d@cisco.com> <9F5A4248-CEC9-4B45-BC85-CA5B329C567E@umn.edu> From: Robert Raszuk Date: Mon, 17 Jul 2017 10:51:10 +0200 X-Google-Sender-Auth: 4VB8p-0RcakCikvNmrwAfD4XiOk Message-ID: To: Enke Chen , David Farmer Cc: Naiming Shen , idr wg Content-Type: multipart/alternative; boundary="001a114fbd922532a905547f8030" Archived-At: Subject: Re: [Idr] Fwd: I-D Action: draft-chen-bfd-unsolicited-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 08:51:13 -0000 --001a114fbd922532a905547f8030 Content-Type: text/plain; charset="UTF-8" Likewise to addresss the other point you stated BGP can be augmented to prefer paths with validated next hops using unsolicited bfd or other test tools. Thx, R On Jul 17, 2017 04:20, "Enke Chen" wrote: Hi, David: For deployment I think that the only new config would be to enable the "unsolicited bfd" feature on the interface attached to the IXP (and "ttl" check if not the default). BFD sessions would be established with the nexthops dynamically, and without configuring BFD peers. Thanks. -- Enke On 7/16/17 6:45 PM, David Farmer wrote: > > > Sent from my iPhone > >> On Jul 16, 2017, at 18:12, Enke Chen wrote: >> >> Hi, Folks: >> >> Here is a proposal for "unsolicited bfd". We (the authors) believe that >> "add-path + unsolicited bfd" is a simper solution to the nexthop liveness >> issue at the IXP with Route Servers. >> >> Thanks. -- Enke > > Unless I missed something one side or the other actually has to actually be configured to initiate the BFD session, otherwise two peers at an IX are perfectly willing to do BFD but there will be no active BFD sessions between them. No doubt, this is better that both sides having to configure BFD, but is not the fully automated solution that I and I think others are looking for. > > I'm fine with using add-path with the IX RS, but I want automatic initiation of the BFD sessions within the IX, and a mechanism to at least prefer next-hops that are doing BFD with me, over ones that won't or aren't, if not out right ignore next-hops that won't do BFD with me. > > Thanks > > David Farmer > --001a114fbd922532a905547f8030 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Likewise to addresss the other point you stated BGP = can be augmented to prefer paths with validated next hops using unsolicited= bfd or other test tools.

Thx,=
R


On Jul 17, 2017 04:20, "Enke Chen" <enkechen@cisco.com> wrote:
Hi, David:

For deployment I think that the only new config would be to enable the &quo= t;unsolicited
bfd" feature on the interface attached to the IXP (and "ttl"= check if not the default).
BFD sessions would be established with the nexthops dynamically, and withou= t configuring
BFD peers.

Thanks.=C2=A0 -- Enke

On 7/16/17 6:45 PM, David Farmer wrote:
>
>
> Sent from my iPhone
>
>> On Jul 16, 2017, at 18:12, Enke Chen <enkechen@cisco.com> wrote:
>>
>> Hi, Folks:
>>
>> Here is a proposal for "unsolicited bfd".=C2=A0 We (the = authors) believe that
>> "add-path + unsolicited bfd" is a simper solution to the= nexthop liveness
>> issue at the IXP with Route Servers.
>>
>> Thanks.=C2=A0 -- Enke
>
> Unless I missed something one side or the other actually has to actual= ly be configured to initiate the BFD session, otherwise two peers at an IX = are perfectly willing to do BFD but there will be no active BFD sessions be= tween them. No doubt, this is better that both sides having to configure BF= D, but is not the fully automated solution that I and I think others are lo= oking for.
>
> I'm fine with using add-path with the IX RS, but I want automatic = initiation of the BFD sessions within the IX, and a mechanism to at least p= refer next-hops that are doing BFD with me, over ones that won't or are= n't, if not out right ignore next-hops that won't do BFD with me. >
> Thanks
>
> David Farmer
>

--001a114fbd922532a905547f8030-- From nobody Mon Jul 17 02:16:43 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8590A12EB5F; Mon, 17 Jul 2017 02:16:42 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 ZbJdpYWPXEOb; Mon, 17 Jul 2017 02:16:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 900D512F28A; Mon, 17 Jul 2017 02:16:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DKR22939; Mon, 17 Jul 2017 09:16:37 +0000 (GMT) Received: from DGGEML403-HUB.china.huawei.com (10.3.17.33) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 17 Jul 2017 10:16:36 +0100 Received: from DGGEML508-MBX.china.huawei.com ([169.254.3.135]) by DGGEML403-HUB.china.huawei.com ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0301.000; Mon, 17 Jul 2017 17:15:32 +0800 From: Mach Chen To: Susan Hares , "'idr@ietf. org'" CC: "draft-ietf-idr-bgp-ls-segment-routing-ext@ietf.org" , "'Stefano Previdi (sprevidi)'" , "'Hannes Gredler'" , "Dongjie (Jimmy)" , "'Clarence Filsfils (cfilsfil)'" Thread-Topic: IPR Call for draft-ietf-idr-bgp-ls-segment-routing-ext prior to WG LC Thread-Index: AdL+P70mae4rLOdjTaS/cqwHO+49oQAnZTJg Date: Mon, 17 Jul 2017 09:15:31 +0000 Message-ID: References: <001401d2fe40$0b2a9db0$217fd910$@ndzh.com> In-Reply-To: <001401d2fe40$0b2a9db0$217fd910$@ndzh.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.67.154] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE29184506Cdggeml508mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.596C8076.0016, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.135, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 1022e48e38a8b67ea156846730bf00a5 Archived-At: Subject: Re: [Idr] IPR Call for draft-ietf-idr-bgp-ls-segment-routing-ext prior to WG LC X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 09:16:43 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE29184506Cdggeml508mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sue, I am not aware of any IPR that applies to this document. Best regards, Mach From: Susan Hares [mailto:shares@ndzh.com] Sent: Sunday, July 16, 2017 10:30 PM To: 'idr@ietf. org' Cc: draft-ietf-idr-bgp-ls-segment-routing-ext@ietf.org; 'Stefano Previdi (s= previdi)'; 'Hannes Gredler'; Mach Chen; Dongjie (Jimmy); 'Clarence Filsfils= (cfilsfil)' Subject: IPR Call for draft-ietf-idr-bgp-ls-segment-routing-ext prior to WG= LC Stefano, Hannes, Mach, Clarence: This begins an IPR call for draft-ietf-idr-bgp-ls-segment-routing-ext prior= to WG LC. Please indicate if you know of any IPR regarding this draft. = After all authors respond, we will start WG LC. Susan Hares PS - Please note that John Scudder started a WG early adoption call in anot= her thread. Please respond to the IPR request for the WG LC on this thread= . --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE29184506Cdggeml508mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sue,

 

I am not aware of any IPR that applies to this document.

 

Best regards,

Mach

 

From: Susan Hares [mailto:shares@ndzh.com]
Sent: Sunday, July 16, 2017 10:30 PM
To: 'idr@ietf. org'
Cc: draft-ietf-idr-bgp-ls-segment-routing-ext@ietf.org; 'Stefano Pre= vidi (sprevidi)'; 'Hannes Gredler'; Mach Chen; Dongjie (Jimmy); 'Clarence F= ilsfils (cfilsfil)'
Subject: IPR Call for draft-ietf-idr-bgp-ls-segment-routing-ext prio= r to WG LC

 

Stefano, Hannes, Mach, Clarence= :

 

This begins an IPR call for dra= ft-ietf-idr-bgp-ls-segment-routing-ext prior to WG LC.   Please i= ndicate if you know of any IPR regarding this draft.  After all author= s respond, we will start WG LC.   

 

Susan Hares

 

PS – Please note that Joh= n Scudder started a WG early adoption call in another thread.  Please = respond to the IPR request for the WG LC on this thread.

     &= nbsp;

--_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE29184506Cdggeml508mbxchi_-- From nobody Mon Jul 17 02:42:02 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E667F129417 for ; Mon, 17 Jul 2017 02:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.347 X-Spam-Level: ** X-Spam-Status: No, score=2.347 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 aAG2YM_XtlaQ for ; Mon, 17 Jul 2017 02:42:00 -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 971611315FF for ; Mon, 17 Jul 2017 02:41:55 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=31.133.141.64; From: "Susan Hares" To: "'idr@ietf. org'" Date: Mon, 17 Jul 2017 05:35:45 -0400 Message-ID: <001f01d2fee0$11747560$345d6020$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0020_01D2FEBE.8A64AA20" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdL+34j1x/OxqugKRpega2ZuoyB6nA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] draft-ietf-idr-bgp-ls-segment-routing-ext prior to WG LC (7/17 - 7/31) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 09:42:01 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0020_01D2FEBE.8A64AA20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This begins a 2 week WG LC for draft-ietf-idr-bgp-ls-segment-routing-ext from 7/17/17 to 7/31/17. You can obtain the draft at: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-ext/ In your discussions, please indicate if you believe this draft is ready for publication. Also, it would be helpful to know if have experience with any of the implementations of this draft. Sue Hares and John Scuder ------=_NextPart_000_0020_01D2FEBE.8A64AA20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This = begins a 2 week WG LC for draft-ietf-idr-bgp-ls-segment-routing-ext from = 7/17/17 to 7/31/17.  You can obtain the draft at:

https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segmen= t-routing-ext/

 

In your = discussions, please indicate if you believe this draft is ready for = publication.  Also, it would be helpful to know if have experience = with any of the implementations of this draft. 

 

Sue Hares = and John Scuder

 

------=_NextPart_000_0020_01D2FEBE.8A64AA20-- From nobody Mon Jul 17 05:42:18 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECF2131B5B for ; Mon, 17 Jul 2017 05:42:17 -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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=previdi-net.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 yUwXG0a1QdQN for ; Mon, 17 Jul 2017 05:42:15 -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 B286D131B5A for ; Mon, 17 Jul 2017 05:42:14 -0700 (PDT) Received: by mail-wr0-x22b.google.com with SMTP id a10so11093285wrd.0 for ; Mon, 17 Jul 2017 05:42:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=previdi-net.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=siy4LF0aMh0oe67Npjf4NYTtcIBwsy1KGPzMIaKZaTE=; b=msFXF+FxJfLec/t/iS5AuAn3B+eFjcRDCbJgK1D73gaWd9FMiB4xWOgkVFlpu7zP7z q6/2ZWKnoSJbxcTg1rWiD3ZxWtPOQysxxX+jCSG2KCoZkYCjV4aE+K796Oi7Cr/fjfjE KSTCzvuZp/hmky/+nDH4whe7dz52mOBRjqJoZj8B9NG3NjP2N449u7wlWB+28alHyscR sXV5AR+Gl9IRbJ5g5GhzlRA70CuP+yh5VfTNGt7yLVuR7DbkQXo2nMCVpUI9mFzsFoW4 1uKwdIH4zLsqgoah51KOTPC9dFgTrYob3dEaf2+4GKxefc/bVzuj7RJA+2FGYPF7o0vU TkZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=siy4LF0aMh0oe67Npjf4NYTtcIBwsy1KGPzMIaKZaTE=; b=j+0NHd4LTDuwJ9JkbgipXaykdTbbjBxN+lhfksOUtouWan9CPbmzzRy/m3xoHV0hPo CDGP84c1r+rKWgGDRTphMdc3ia4D5c+M0+MHcYJ64uPnYsDlPcxzu3Ui1z2H5NtyHkwq H2nvbF5kJ2UDnhdZlzHGCK2TTdnsbQHmbQpyjywwlxoqtxD3mVCG3o+YdTmtrqiTJkRp P+CSlHYWqTIEULXAse9GC2Y29IFbxuO3MvIfcQbH2HsTrgorwPsmO4b00jwKOW6FV2ZD 8s6dLQvNdcekIcc3kMiISb8F8/bpvbBDm8R7VH5mCPzJR5fXUyZayi4FOnjKGVNCGS22 YqVg== X-Gm-Message-State: AIVw113O8uyrSOYUpejrSuBZa/hrX0+0/1M8GeyAeC5yrnMjVsaIvEqR C45kc6QJ+phsET51WITkCw== X-Received: by 10.223.152.208 with SMTP id w74mr5487815wrb.202.1500295333108; Mon, 17 Jul 2017 05:42:13 -0700 (PDT) Received: from ?IPv6:2001:420:c0c0:1003::f0? ([2001:420:c0c0:1003::f0]) by smtp.gmail.com with ESMTPSA id 21sm9875658wmo.16.2017.07.17.05.42.11 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 17 Jul 2017 05:42:12 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: text/plain; charset=utf-8 From: stefano previdi In-Reply-To: Date: Mon, 17 Jul 2017 14:42:25 +0200 Cc: idr@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <149824800169.17379.9099679082498238196@ietfa.amsl.com> To: Nandan Saha X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [Idr] I-D Action: draft-previdi-idr-segment-routing-te-policy-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 12:42:17 -0000 Hi Nandan, sorry for being late. See below. > On Jul 3, 2017, at 2:14 PM, Nandan Saha wrote: >=20 > Hello! >=20 > I have some questions on the NLRI encoding. > 1. Can the value of NLRI length be less than 96 for IPv4 AFI and less > than 192 for IPv6 AFI? IOW, can it be less than full mask length for > the end point address? no. > 2. If the answer to (1) is "yes", then what is the rationale for > keeping the end point address field of the NLRI fixed length? (4 or 16 > bytes depending on AFI). Should the end point become variable length > like the NLRI encoding defined in RFC4760? > 3. If the answer to (1) is "no", how are summary addresses to be = represented? there=E2=80=99s no such concept of =E2=80=9Csummary address=E2=80=9D for = the endpoint encoding. The draft is going to be updated and the term = =E2=80=9Csummary address=E2=80=9D will be removed from the endpoint = filed description. Sorry for the confusiuon. > Another question which is unrelated to the changes in version 7 of the = draft. > Section "4.2.1. Acceptance of an SR Policy NLRI" says > " If the NLRI is not one of the legal lengths, a router supporting > this document and that imports the route MUST consider it to be > malformed and MUST apply the "treat-as-withdraw" strategy of [RFC7606] > " > It's not clear to me how a receiver can extract a valid route from a > malformed NLRI. you just have to check the nlri length. > The "treat-as-withdraw" can be applied if the NLRI is > well formed but some other attributes are malformed, which seems to be > implied by the following line at the end of the subsection > "A unacceptable SR Policy update that has an invalid NLRI portion MUST > trigger a reset of the BGP session.=E2=80=9D that is correct. s. >=20 > Thank you! > Best regards, > Nandan >=20 > On Sat, Jun 24, 2017 at 1:30 AM, wrote: >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Inter-Domain Routing of the IETF. >>=20 >> Title : Advertising Segment Routing Policies in BGP >> Authors : Stefano Previdi >> Clarence Filsfils >> Paul Mattes >> Eric Rosen >> Steven Lin >> Filename : = draft-previdi-idr-segment-routing-te-policy-07.txt >> Pages : 30 >> Date : 2017-06-23 >>=20 >> Abstract: >> This document defines a new BGP SAFI with a new NLRI in order to >> advertise a candidate path of a Segment Routing Policy (SR Policy). >> An SR Policy is a set of candidate paths consisting of one or more >> segment lists. The headend of an SR Policy may learn multiple >> candidate paths for an SR Policy. Candidate paths may be learned = via >> a number of different mechanisms, e.g., CLI, NetConf, PCEP, or BGP. >> This document specifies the way in which BGP may be used to >> distribute candidate paths. New sub-TLVs for the Tunnel >> Encapsulation Attribute are defined. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> = https://datatracker.ietf.org/doc/draft-previdi-idr-segment-routing-te-poli= cy/ >>=20 >> There are also htmlized versions available at: >> = https://tools.ietf.org/html/draft-previdi-idr-segment-routing-te-policy-07= >> = https://datatracker.ietf.org/doc/html/draft-previdi-idr-segment-routing-te= -policy-07 >>=20 >> A diff from the previous version is available at: >> = https://www.ietf.org/rfcdiff?url2=3Ddraft-previdi-idr-segment-routing-te-p= olicy-07 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Mon Jul 17 07:17:43 2017 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E5C65131BDA; Mon, 17 Jul 2017 07:17:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.56.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150030105591.28768.823493532198672648@ietfa.amsl.com> Date: Mon, 17 Jul 2017 07:17:35 -0700 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-tunnel-encaps-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 14:17:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing of the IETF. Title : The BGP Tunnel Encapsulation Attribute Authors : Eric C. Rosen Keyur Patel Gunter Van de Velde Filename : draft-ietf-idr-tunnel-encaps-07.txt Pages : 41 Date : 2017-07-17 Abstract: RFC 5512 defines a BGP Path Attribute known as the "Tunnel Encapsulation Attribute". This attribute allows one to specify a set of tunnels. For each such tunnel, the attribute can provide the information needed to create the tunnel and the corresponding encapsulation header. The attribute can also provide information that aids in choosing whether a particular packet is to be sent through a particular tunnel. RFC 5512 states that the attribute is only carried in BGP UPDATEs that have the "Encapsulation Subsequent Address Family (Encapsulation SAFI)". This document deprecates the Encapsulation SAFI (which has never been used in production), and specifies semantics for the attribute when it is carried in UPDATEs of certain other SAFIs. This document adds support for additional tunnel types, and allows a remote tunnel endpoint address to be specified for each tunnel. This document also provides support for specifying fields of any inner or outer encapsulations that may be used by a particular tunnel. This document obsoletes RFC 5512. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-tunnel-encaps/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-07 https://datatracker.ietf.org/doc/html/draft-ietf-idr-tunnel-encaps-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-tunnel-encaps-07 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 Jul 17 07:40:41 2017 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A71E1131C28; Mon, 17 Jul 2017 07:40:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.56.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150030243356.28823.11729932425751070221@ietfa.amsl.com> Date: Mon, 17 Jul 2017 07:40:33 -0700 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-bgp-ls-segment-routing-msd-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 14:40:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing of the IETF. Title : Signaling Maximum SID Depth using Border Gateway Protocol Link-State Authors : Jeff Tantsura Uma Chunduri Greg Mirsky Siva Sivabalan Filename : draft-ietf-idr-bgp-ls-segment-routing-msd-00.txt Pages : 7 Date : 2017-07-17 Abstract: This document proposes a way to signal Maximum SID Depth (MSD) supported by a node at node and/or link granularity by a BGP-LS speaker. In a Segment Routing (SR) enabled network a centralized controller that programs SR tunnels needs to know the MSD supported by the head-end at node and/or link granularity to push the SID stack of an appropriate depth. MSD is relevant to the head-end of a SR tunnel or Binding-SID anchor node where Binding-SID expansions might result in creation of a new SID stack. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-msd/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-msd-00 https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-segment-routing-msd-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 Mon Jul 17 08:50:57 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA41131C7A; Mon, 17 Jul 2017 08:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.114 X-Spam-Level: X-Spam-Status: No, score=-0.114 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 DfGSMN4ywB5n; Mon, 17 Jul 2017 08:50:53 -0700 (PDT) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-oln040092254010.outbound.protection.outlook.com [40.92.254.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A43612EC12; Mon, 17 Jul 2017 08:50:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7zWXSIyXlin4ibIfohkJdCG/blI1PuJG/SVl9xL5mTQ=; b=Ou8EQQb4/XRkLA0gkuiI682JrKHO0W4vPAGLbnM5C02NVTTUz2in65nwsUOv4Ao4b71GV9S55qYusL0z6n3lhe9MmpbizU79JEEWjO87uOSYDICQUOk3DR/mFLF0DPpPKSZGdzHSZmgUxO11V0RNUUOXjB0R3y/fgQkY5X+GSXCj6JYS+kP4sRTDwmRQoq8279V3jEhimDl3A1z9xaLUk8SO1oJlcLwTtft/Ipe79+cWyDxG8IWoVoon850BpaXIREkLM2GDjfDBnjgxo8Dbi4bOzZj5emExYuD/sGl4IZGa3BIIqy6+APPr08PCg/JokbmWPnfoR0dcB7jxvfPUsw== Received: from PU1APC01FT058.eop-APC01.prod.protection.outlook.com (10.152.252.53) by PU1APC01HT248.eop-APC01.prod.protection.outlook.com (10.152.253.209) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1220.9; Mon, 17 Jul 2017 15:50:50 +0000 Received: from HK2PR0601MB1361.apcprd06.prod.outlook.com (10.152.252.51) by PU1APC01FT058.mail.protection.outlook.com (10.152.253.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.9 via Frontend Transport; Mon, 17 Jul 2017 15:50:49 +0000 Received: from HK2PR0601MB1361.apcprd06.prod.outlook.com ([fe80::b591:87c3:a316:be96]) by HK2PR0601MB1361.apcprd06.prod.outlook.com ([fe80::b591:87c3:a316:be96%13]) with mapi id 15.01.1261.022; Mon, 17 Jul 2017 15:50:50 +0000 From: li zhenqiang To: "bruno.decraene@orange.com" , "draft-li-idr-congestion-status-extended-community@ietf.org" CC: idr Thread-Topic: draft-li-idr-congestion-status-extended-community Thread-Index: AQHS/xR2ZquQmAoAMES5a+pKpEUSQQ== Date: Mon, 17 Jul 2017 15:50:50 +0000 Message-ID: References: <12536_1499779219_5964D093_12536_99_1_53C29892C857584299CBF5D05346208A477FE298@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=hotmail.com; x-incomingtopheadermarker: OriginalChecksum:B27207A9A229D9B33DA8742695C8B2980E99988D310B47BA783E26D05537A62B; UpperCasedChecksum:1150BBB669EB994A9946027748A56DD10651AB2E0F237DC9717D8D9A5BCDB038; SizeAsReceived:7479; Count:45 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [Bv3a/HBObXK4Kx95UqcZfmOlKn8iOmCU] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; PU1APC01HT248; 7:hHw896vgAGjzJjivMax9F3+NSY0MxRoz3vr1BtxSDbwtIuBJx5rbRxeXoIxkEC00ZD6VDrcpB/cV1S77LOAl4Go28nMSGJIWmHhQRpA6VLiikzl+4dWGUlRyRKSDpQzMjHPxW6s2wRrAuR277Yplih3R8wqLeNT9Xvaa9XtSI2RphpmnCuboiyh+blV+5m3Pr/LvIa+prcr4cyx6Mre+BqZ/36ci6FFyFfHGk9GlzXbqh+pbDChgWWzNImr0iwHxESeFk61pl807tZeCJEu3Iepup1C+pyX88+lJI07ZYUsMoNC00jhmBO8E3b7JfOpf5nmwDkvpFkENj2T3FPolGGWWjd6hp/YrXAC58250TFNDVrjEywEZPS4LBqtt/2cv/mLCmNT6mUo+HQHi+5WZNU4IcqZW3kxYpYDAZTbkBgwjxViTYVQRhLMR3cpF2oMoGt8SVH4TAwg1UY1qr7at8PGXRpSXi5RvRy/C2f751tSQHdbAvC42FINiw5Yy+CZ03P9DgTcvm596CLCh230vdVlMVyh6IigxOur/292PFb9omj8v5N3wvrLyCK1zQEZOl1M6/Qa2JJRVRS9wW31SuKpBLRIRsqtTbhH/I0hQ/qlZdQd+5d+fdHGnpNie14Px9xqmXDm8erI18vn1tgBAb3Kvorgh9i6F5kWGoXGMVs0jUlQONQmEhfyAxs1TdcDOer+Uq1rT5LalQwE/9ERTDDVrXQQ0/zXMFG34RYcWIiyxBte992MjLQoIeSmVKg06vSr/xau+Irn0kyFYmh5/bQ== x-incomingheadercount: 45 x-eopattributedmessage: 0 x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:PU1APC01HT248; H:HK2PR0601MB1361.apcprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: 0b5bf971-0f2f-4d13-df4a-08d4cd2b9891 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322350)(1603101448)(1601125374)(1701031045)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:PU1APC01HT248; x-ms-traffictypediagnostic: PU1APC01HT248: x-exchange-antispam-report-test: UriScan:(278178393323532)(236129657087228)(192374486261705)(48057245064654)(148574349560750)(18271650672692)(194151415913766)(167848164394848)(209349559609743)(247924648384137); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031); SRVR:PU1APC01HT248; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:PU1APC01HT248; x-forefront-prvs: 0371762FE7 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HK2PR0601MB1361F407B2018606BEC9AEE5FCA00HK2PR0601MB1361_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2017 15:50:50.0567 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT248 Archived-At: Subject: Re: [Idr] draft-li-idr-congestion-status-extended-community X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 15:50:55 -0000 --_000_HK2PR0601MB1361F407B2018606BEC9AEE5FCA00HK2PR0601MB1361_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gQnJ1bm8sDQoNClRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHlvdXIgY29uc3RydWN0aXZl IGNvbW1lbnRzLiBQbGVhc2Ugc2VlIG15IHJlcGx5IGlubGluZSwgYmVnaW5zIHdpdGggUmVwbHku IFNvcnJ5IGZvciB0aGUgbGF0ZSByZXNwb25zZS4NCg0KQmVzdCBSZWdhcmRzLA0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCmxpX3poZW5xaWFuZ0Bob3RtYWlsLmNvbQ0KDQpGcm9t OiBicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPG1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2Uu Y29tPg0KRGF0ZTogMjAxNy0wNy0xMSAyMToyMA0KVG86IGRyYWZ0LWxpLWlkci1jb25nZXN0aW9u LXN0YXR1cy1leHRlbmRlZC1jb21tdW5pdHlAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWxpLWlkci1j b25nZXN0aW9uLXN0YXR1cy1leHRlbmRlZC1jb21tdW5pdHlAaWV0Zi5vcmc+DQpDQzogaWRyQGll dGYub3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBkcmFmdC1saS1pZHItY29uZ2Vz dGlvbi1zdGF0dXMtZXh0ZW5kZWQtY29tbXVuaXR5DQpIaSBhdXRob3JzLA0KDQpQbGVhc2UgZmlu ZCBiZWxvdyBzb21lIG1pbm9yIGNvbW1lbnRzLg0KDQrCpzIgIENvbmdlc3Rpb24gU3RhdHVzIEV4 dGVuZGVkIENvbW11bml0eQ0KDQo+IFRoZSAiVXRpbGl6YXRpb24iIGZpZWxkIGlzIDEgb2N0ZXQu ICBJdHMgdmFsdWUgaXMgdGhlIHV0aWxpemF0aW9uIG9mIHRoZSBleGl0IGxpbmsgaW4gdW5pdCBv ZiBwZXJjZW50DQoNCi0gSXMgdGhpcyB0aGUgdXRpbGl6YXRpb24gb24gdGhlIGxpbmsgb3IgYmVm b3JlIHRoZSBsaW5rIChpLmUuIGJlZm9yZSBkcm9wcGluZyB0aGUgdHJhZmZpYyBpbiBleGNlc3Mp ID8gSU9XLCBjYW4gdGhpcyBiZSBncmVhdGVyIHRoYW4gMTAwJT8gSSB0aGluayBJJ2QgcHJlZmVy IHRoZSBsYXR0ZXIsIGJ1dCBpbiBhbGwgY2FzZXMsIEkgbGlrZSB0byBzZWUgYSB0ZXh0IGRldGFp bGluZyB0aGUgaGFuZGxpbmcgb2YgbnVtYmVycyA+IDEwMCUuDQpSZXBseTogSWYgaXQgaXMgZWFz eSB0byBnZXQgdGhlIHV0aWxpemF0aW9uIGJlZm9yZSB0aGUgbGluaywgd2UgY2FuIHVzZSBpdC4g QnV0IEkgYW0gbm90IHN1cmUgYWJvdXQgaXQuIElmIHlvdSBjYW4sIHBsZWFzZSBjb250cmlidXRl IHNvbWUgdGV4dCB0aGF0IEkgd2lsbCBpbmNvcnBvcmF0ZSBpbiB0aGUgbmV4dCB2ZXJzaW9uLg0K DQotIEluIG9yZGVyIHRvIG9mZmVyIG1vcmUgZ3JhbnVsYXJpdHksIHNvbWV0aW1lcyB0aGUgdHJh ZmZpYyBpcyByYXRlIGxpbWl0ZWQgdG8gYSBjYXBhY2l0eSBzbWFsbGVyIHRoYW4gdGhlIHBoeXNp Y2FsIGxpbmsuIGUuZy4gdGhlIHBoeXNpY2FsIGxpbmsgaGFzIDEwRyBvZiB0cmFmZmljLCBidXQg b25seSAzRyBpcyBhdmFpbGFibGUgdG8gdGhlIHVzZXIuIFBsZWFzZSBleHBsaWNpdCB3aGV0aGVy IHlvdSBhcmUgcmVmZXJyaW5nIHRvIHBoeXNpY2FsIG9yICJyZWFsIi8ib2ZmZXJlZCIvImF2YWls YWJsZSIgY2FwYWNpdHkuIE9uIG15IHNpZGUsIEknZCBwcmVmZXIgdGhlIGxhdHRlci4NClJlcGx5 OiBJIGFncmVlIHRoYXQgdGhlIGJhbmR3aWR0aCBzaG91bGQgYmUgdGhlIGNvbmZpZ3VyZWQgIGF2 YWlsYWJsZSBjYXBhY2l0eSBvZiB0aGUgbGluay4gSSB3aWxsIGV4cGxpY2l0IGl0IGluIHRoZSBu ZXh0IHZlcnNpb24uDQoNCj4gVGhlICJCYW5kd2lkdGgiIGZpZWxkIGlzIDEgb2N0ZXQuICBJdHMg dmFsdWUgaXMgdGhlIGJhbmR3aWR0aCBvZiB0aGUgZXhpdCBsaW5rIGluIHVuaXQgb2YgMTAgZ2Jw cyAoZ2lnYWJpdHMgcGVyIHNlY29uZCkuDQoNCkkgZG9uJ3Qgc2VlIHRoYXQgdGhpcyBpcyBleHRy ZW1lbHkgZnV0dXJlIHByb29mLCBhcyB0aGUgdXNhYmxlIHJhbmdlIGlzIDEtMjU1LiBXaGVuIHRo aXMgcHJvcG9zaXRpb24gZ2V0cyB1c2VkIChpbiB5ZWFycyBmcm9tIG5vdyksIDEwMEcgbGlua3Mg d291bGQgcHJlc3VtYWJseSBiZSB0aGUgZGVmYXVsdC4gTWVhbmluZyB3ZSB3b3VsZCBhbHJlYWR5 IGhhdmUgY29uc3VtZWQgKjEwIGZyb20gdGhlIGJ1ZGdldC4gT25seSBsZWF2aW5nICoyNSBmb3Ig dGhlIGZ1dHVyZS4gSSdkIHByZWZlciBhIHdpZGVyIHJhbmdlIHdpdGggbGVzcyBwcmVjaXNpb24u IGUuZy4gYmFuZHdpZHRoIGlzIDEwXl5iYW5kd2lkdGggaW4gZ2Jwcy4gKG9yIDJeXikuDQpSZXBs eTogSW5kZWVkIHRoaXMgaXMgb25lIG9mIHRoZSBrZXkgcG9pbnRzIHdlIHNob3VsZCBjb25zaWRl ciBkdXJpbmcgdGhlIGRlc2lnbiBvZiB0aGUgbWVjaGFuaXNtLiBJbiB1bml0IG9mIDEwIGdicHMs IG9uZSBvY3RldCBjYW4gZXhwcmVzcyB0aGUgYmFuZHdpZHRoIGZyb20gMTBnYnBzIHRvIDI1NTBn YnBzLiBJIHRoaW5rIGl0IHNob3VsZCBiZSBvayBmb3IgdGhlIGZ1dHVyZS4gWW91ciBzdWdnZXN0 aW9uIGlzIGRpZmZpY3VsdCB0byBleHByZXNzIDQwZ2JwcywgMTAwZ2JwcyBhbmQgNDAwZ2JwcyBl dGMuIEFueXdheSB3ZSB3aWxsIHRoaW5rIGFib3V0IHlvdXIgc3VnZ2VzdGlvbiBhbmQgdHJ5IHRv IGZpbmQgYSBiZXR0ZXIgc29sdXRpb24uIFlvdXIgZnVydGhlciBzdWdnZXN0aW9uIGlzIHdlbGNv bWUuDQoNCj4gVGhlIGxpbmsgd2l0aCBiYW5kd2lkdGggbGVzcyB0aGFuIDEwIGdicHMgaXMgbm90 IHN1aXRhYmxlIHRvIHVzZSB0aGlzIGZlYXR1cmUuDQoNCldoeSBub3Q/IEl0IGxvb2tzIHRvIG1l IHRoYXQgdGhlICVVdGlsaXphdGlvbiBjb3VsZCBiZSB1c2VmdWwgZXZlbiBpZiB0aGUgYmFuZHdp ZHRoIGlzIG5vdCBhZHZlcnRpc2VkLiBQb3NzaWJseSBhICJCYW5kd2lkdGgiIHJlc2VydmVkIHZh bHVlIChlLmcuIDApIGNvdWxkIGJlIHNwZWNpZmllZCB0byBpbmRpY2F0ZSB0aGF0IHRoZSBiYW5k d2lkdGggaXMgbm90IGFkdmVydGlzZWQuIFRoaXMgd291bGQgYWxzbyBmaXQgdGhlIGNhc2Ugd2hl cmUgc29tZSBBU2VzIGRvIG5vdCB3YW50IHRvIGFkdmVydGlzZSB0aGVpciBsaW5rIGNhcGFjaXR5 Lg0KUmVwbHk6IEFncmVlLiBXZSB3aWxsIHJldmlzZSB0aGUgZHJhZnQgdG8gcmVmbGVjdCB0aGlz Lg0KDQrCpzMuICBBcHBsaWNhdGlvbiBDb25zaWRlcmF0aW9ucw0KDQo+IFRoZSBTRE4gY29udHJv bGxlciB1c2VzIHRoZSBleGl0IGxpbmsgdXRpbGl6YXRpb24gaW5mb3JtYXRpb24gdG8gc3RlZXIg dGhlIEludGVybmV0IGFjY2VzcyB0cmFmZmljIGFtb25nIGFsbCB0aGUgZXhpdCBsaW5rcyBmcm9t IHRoZSBwZXJzcGVjdGl2ZSBvZiB0aGUgd2hvbGUgbmV0d29yay4NCg0KSW5kZWVkLCBwcmVzdW1h Ymx5IHRoaXMgaW5mb3JtYXRpb24gaXMgdXNlZCB0byBpbmZsdWVuY2UgdGhlIHJvdXRpbmcgYmVo YXZpb3IuIE1heSBiZSB0aGUgZG9jdW1lbnQgc2hvdWxkIGluZGljYXRlIHRoYXQgdGhlIHJlY2Vw dGlvbiBvZiBzdWNoIGNvbW11bml0eSBvdmVyIElCR1Agc2Vzc2lvbiBzaG91bGQgbm90IGluZmx1 ZW5jZSByb3V0aW5nIGRlY2lzaW9uIHVubGVzcyB0dW5uZWxpbmcgaXMgdXNlZCB0byByZWFjaCB0 aGUgQkdQIE5leHQtSG9wLiAodG8gYXZvaWQgZm9yd2FyZGluZyBsb29wcywgaW5jcmVtZW50YWwg ZGVwbG95bWVudCBpc3N1ZXMsIGNvbXBsaWNhdGlvbnMgaW4gZXJyb3IgaGFuZGxpbmcpLg0KUmVw bHk6IFRoYW5rcyBmb3IgcG9pbnRpbmcgb3V0IHRoaXMuIFdlIHdpbGwgYWRkIHNvbWUgZGVzY3Jp cHRpb24gaW4gbmV4dCByZXZpc2lvbi4NCg0KSW4gYWRkaXRpb24sIHdoYXQgYXJlIHRoZSBpbnRl cmFjdGlvbnMgd2l0aCB0aGUgQkdQIExpbmsgQmFuZHdpZHRoIEV4dGVuZGVkIGNvbW11bml0aWVz PyBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pZHItbGluay1iYW5kd2lk dGggIChJIGtub3cgdGhhdCB0aGUgZHJhZnQgZXhwaXJlZCwgYnV0IHN0aWxsIGl0J3MgYSBXRyBk b2N1bWVudCBhbmQgYW4gb2ZmaWNpYWwgSUFOQSBjb2RlIHBvaW50KQ0KU2hpcHMgaW4gdGhlIG5p Z2h0Pw0KUmVwbHk6IFNvIGZhciB0aGlzIGRyYWZ0IGRpZG7igJl0IGNvbnNpZGVyIHRoZSBpbnRl cmFjdGlvbiB3aXRoIHRoZSBsaW5rIGJhbmR3aWR0aCBFeHQuIGNvbW11bml0eS4gQXMgdGhlIGxp bmsgYmFuZHdpZHRoIEV4dC4gY29tbXVuaXR5IGlzIG5vbi1yYW5zaXRpdmUsIGFuZCB0aGUgZ2xv YmFsIGFkbWluaXN0cmF0b3Igc3ViZmllbGQgaXMgb25seSAyLW9jdGV0cywgaXQgbWF5IG5vdCBi ZSBhcHBsaWNhYmxlIHRvIGFsbCB0aGUgc2NlbmFyaW9zIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3Vt ZW50Lg0KDQo+ICAgVG8gYXZvaWQgcm91dGUgb3NjaWxsYXRpb24sIHRoZSBleGl0IHJvdXRlciBT SE9VTEQgc2V0IGEgdGhyZXNob2xkLiAgIFdoZW4gdGhlIHV0aWxpemF0aW9uIGNoYW5nZSByZWFj aGVzIHRoZSB0aHJlc2hvbGQsIHRoZSBleGl0IHJvdXRlciAgU0hPVUxEIGdlbmVyYXRlIGEgQkdQ IHVwZGF0ZSBtZXNzYWdlIHdpdGggY29uZ2VzdGlvbiBzdGF0dXMgZXh0ZW5kZWQgIGNvbW11bml0 eS4NCg0KSSB0aGluayB0aGF0IHRoZSBkb2N1bWVudCBzaG91bGQgYmV0dGVyIGV2YWx1YXRlIHRo ZSBjaHVybiBpbnRyb2R1Y2VkLiBJbiBwYXJ0aWN1bGFyIHRoZSBjaHVybiBpcyBjdW11bGF0aXZl IGFzIHRoZSBudW1iZXIgb2YgQVNlcyBjcm9zc2VkIGluY3JlYXNlLiBlLmcuIGlmIHdlIGFzc3Vt ZSB0aGF0IGVhY2ggQVMgdXNlIHRoZSBjb21tdW5pdHkgcXVpdGUgY2FyZWZ1bGx5IGJ5IG5vdCBh ZHZlcnRpc2luZyBtb3JlIHRoYW4gMSB1cGRhdGUgcGVyIGhvdXIsIGlmIHdlIGhhdmUgNSBBU2Vz IG9uIHRoZSB3YXksIHRoZSBpbmdyZXNzIEFTIGNhbiByZWNlaXZlIDUgKGFkZGl0aW9uYWwpIHVw ZGF0ZXMgcGVyIHByZWZpeCBwZXIgaG91ci4NClJlcGx5OiBXZSB3aWxsIHRoaW5rIGFib3V0IGl0 IGZ1cnRoZXIuIFNvbWV0aGluZyBsaWtlIFRUTCAodGltZSB0byBsaXZlKSB0byBiZSBpbnRyb2R1 Y2VkPyBUbyBoYXZlIGxhcmdlciBzcGFjZSB0byBmaXQgdGhpcywgdXNlIEJHUCBjb21tdW5pdHkg Y29udGFpbmVyIGluc3RlYWQ/IE9yIGRvICB5b3UgIGhhdmUgIHNvbWUgIHN1Z2dlc3Rpb25zPw0K DQo0LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCj4gVGhpcyBuZXcgZXh0ZW5kZWQgY29tbXVu aXR5IGRvZXMgbm90IGRpcmVjdGx5IGludHJvZHVjZSBhbnkgbmV3IHNlY3VyaXR5IGlzc3Vlcy4N Cg0KV2hhdCBhYm91dCB0cnVzdC9jaGVhdGluZyBjb25zaWRlcmF0aW9ucz8gRXNwZWNpYWxseSBm cm9tIHJlbW90ZSBBU2VzIHdpdGggd2hpY2ggeW91IGhhdmUgemVybyByZWxhdGlvbnNoaXA/DQpl LmcuIGFkdmVydGlzaW5nIGFsbGVnZWQgY29uZ2VzdGlvbiBpbiBvcmRlciB0byBURS9pbmZsdWVu Y2Ugcm91dGluZyBvZiBvdGhlcnMgQVNlcywgYWR2ZXJ0aXNpbmcgcGxlbnR5IG9mIGZha2UgY2Fw YWNpdHkgdG8gYXR0cmFjdCBtb3JlIHRyYWZmaWMvY3VzdG9tZXJzLCBhZHZlcnRpc2luZyB0aGF0 IHRoZXkgYXJlIG5ldmVyIGV4cGVyaWVuY2luZyBhbnkgY29uZ2VzdGlvbiBmb3IgY29tbWVyY2lh bCByZWFzb25zLCBmYWtlIGFkdmVydGlzZW1lbnQgb24gImJlaGFsZiIgb2Ygb3RoZXIgQVNlcy4u Lg0KUmVwbHk6IFRoZSB0cnVzdC9jaGVhdGluZyBwcm9ibGVtIHlvdSBtZW50aW9uZWQgaXMgYSBn ZW5lcmFsIGlzc3VlIGZvciBCR1AuIENhbiB3ZSBtYWtlIHN1cmUgdGhhdCB0aGUgcm91dGVzIGFk dmVydGlzZWQgYnkgYSBCR1AgcGVlciBzaG91bGQgYmUgYWR2ZXJ0aXNlZCBieSBpdD8gVGhlIEJH UCBwZWVyIGNhbiBnZW5lcmF0ZSBzb21lIHJvdXRlcyBtYWxpY2lvdXNseS4gQW55d2F5LCAgd2Ug d2lsbCBhZGQgc29tZSBhbmFseXNpcyB0byB0aGlzIHByb2JsZW0gaW4gbmV4dCByZXZpc2lvbi4g Rm9yIGV4YW1wbGUsICB0aGUgQkdQIHJlY2VpdmVyIG1heSBjaG9vc2UgdG8gb25seSB0cnVzdCB0 aGUgY29uZ2VzdGlvbiAgaW5mb3JtYXRpb24gYWR2ZXJ0aXNlZCBieSBzb21lIHBhcnRpY3VsYXIg QVNlcywgb3IgQVNlcyB3aXRoaW4gcGFydGljdWxhciBob3BzLiBBbnkgc3VnZ2VzdGlvbiBmcm9t IHlvdT8NCg0KVGhhbmtzLA0KUmVnYXJkcywNCi0tQnJ1bm8NCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpDZSBtZXNz YWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlv bnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCnBh cyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBT aSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25h bGVyDQphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBq b2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdh bHRlcmF0aW9uLA0KT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVz c2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQpUaGlzIG1l c3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJp dmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KdGhleSBz aG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlz YXRpb24uDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ug bm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2ht ZW50cy4NCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9y IG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4N ClRoYW5rIHlvdS4NCg0K --_000_HK2PR0601MB1361F407B2018606BEC9AEE5FCA00HK2PR0601MB1361_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5ib2R5IHsgbGluZS1oZWlnaHQ6IDEu NTsgfWJsb2NrcXVvdGUgeyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgbWFy Z2luLWxlZnQ6IDAuNWVtOyB9Ym9keSB7IGZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTog 5b6u6L2v6ZuF6buROyBjb2xvcjogcmdiKDAsIDAsIDApOyBsaW5lLWhlaWdodDogMS41OyB9PC9z dHlsZT4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdj48c3Bhbj48L3NwYW4+SGVsbG8gQnJ1bm8sPC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGFuayB5b3UgdmVyeSBtdWNoIGZvciB5b3Vy IGNvbnN0cnVjdGl2ZSBjb21tZW50cy4gUGxlYXNlIHNlZSBteSByZXBseSBpbmxpbmUsIGJlZ2lu cyB3aXRoIFJlcGx5LiBTb3JyeSBmb3IgdGhlIGxhdGUgcmVzcG9uc2UuPC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj5CZXN0IFJlZ2FyZHMsPC9kaXY+DQo8aHIgc3R5bGU9IndpZHRoOiAy MTBweDsgaGVpZ2h0OiAxcHg7IiBjb2xvcj0iI2I1YzRkZiIgc2l6ZT0iMSIgYWxpZ249ImxlZnQi Pg0KPGRpdj48c3Bhbj4NCjxkaXYgc3R5bGU9Ik1BUkdJTjogMTBweDsgRk9OVC1GQU1JTFk6IHZl cmRhbmE7IEZPTlQtU0laRTogMTBwdCI+DQo8ZGl2PmxpX3poZW5xaWFuZ0Bob3RtYWlsLmNvbTwv ZGl2Pg0KPC9kaXY+DQo8L3NwYW4+PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7IG1hcmdpbi1sZWZ0OiAwLjVlbTsiPg0KPGRpdj4m bmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxkaXYgc3R5bGU9IlBBRERJ TkctUklHSFQ6IDhweDsgUEFERElORy1MRUZUOiA4cHg7IEZPTlQtU0laRTogMTJweDtGT05ULUZB TUlMWTp0YWhvbWE7Q09MT1I6IzAwMDAwMDsgQkFDS0dST1VORDogI2VmZWZlZjsgUEFERElORy1C T1RUT006IDhweDsgUEFERElORy1UT1A6IDhweCI+DQo8ZGl2PjxiPkZyb206PC9iPiZuYnNwOzxh IGhyZWY9Im1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tIj5icnVuby5kZWNyYWVuZUBv cmFuZ2UuY29tPC9hPjwvZGl2Pg0KPGRpdj48Yj5EYXRlOjwvYj4mbmJzcDsyMDE3LTA3LTExJm5i c3A7MjE6MjA8L2Rpdj4NCjxkaXY+PGI+VG86PC9iPiZuYnNwOzxhIGhyZWY9Im1haWx0bzpkcmFm dC1saS1pZHItY29uZ2VzdGlvbi1zdGF0dXMtZXh0ZW5kZWQtY29tbXVuaXR5QGlldGYub3JnIj5k cmFmdC1saS1pZHItY29uZ2VzdGlvbi1zdGF0dXMtZXh0ZW5kZWQtY29tbXVuaXR5QGlldGYub3Jn PC9hPjwvZGl2Pg0KPGRpdj48Yj5DQzo8L2I+Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOmlkckBpZXRm Lm9yZyI+aWRyQGlldGYub3JnPC9hPjwvZGl2Pg0KPGRpdj48Yj5TdWJqZWN0OjwvYj4mbmJzcDtk cmFmdC1saS1pZHItY29uZ2VzdGlvbi1zdGF0dXMtZXh0ZW5kZWQtY29tbXVuaXR5PC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+SGkgYXV0aG9ycyw8L2Rpdj4NCjxkaXY+Jm5ic3A7 PC9kaXY+DQo8ZGl2PlBsZWFzZSBmaW5kIGJlbG93IHNvbWUgbWlub3IgY29tbWVudHMuIDwvZGl2 Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+wqcyJm5ic3A7IENvbmdlc3Rpb24gU3RhdHVzIEV4 dGVuZGVkIENvbW11bml0eTwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jmd0OyBUaGUg JnF1b3Q7VXRpbGl6YXRpb24mcXVvdDsgZmllbGQgaXMgMSBvY3RldC4mbmJzcDsgSXRzIHZhbHVl IGlzIHRoZSB1dGlsaXphdGlvbiBvZiB0aGUgZXhpdCBsaW5rIGluIHVuaXQgb2YgcGVyY2VudDwv ZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+LSBJcyB0aGlzIHRoZSB1dGlsaXphdGlvbiBv biB0aGUgbGluayBvciBiZWZvcmUgdGhlIGxpbmsgKGkuZS4gYmVmb3JlIGRyb3BwaW5nIHRoZSB0 cmFmZmljIGluIGV4Y2VzcykgPyBJT1csIGNhbiB0aGlzIGJlIGdyZWF0ZXIgdGhhbiAxMDAlPyBJ IHRoaW5rIEknZCBwcmVmZXIgdGhlIGxhdHRlciwgYnV0IGluIGFsbCBjYXNlcywgSSBsaWtlIHRv IHNlZSBhIHRleHQgZGV0YWlsaW5nIHRoZSBoYW5kbGluZyBvZiBudW1iZXJzICZndDsgMTAwJS4N CjwvZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1 LCAyNTUpOyI+UmVwbHk6IElmIGl0IGlzIGVhc3kgdG8gZ2V0IHRoZSB1dGlsaXphdGlvbiBiZWZv cmUgdGhlIGxpbmssIHdlIGNhbiB1c2UgaXQuIEJ1dCBJIGFtIG5vdCBzdXJlIGFib3V0IGl0LiBJ ZiB5b3UgY2FuLCBwbGVhc2UgY29udHJpYnV0ZSBzb21lIHRleHQgdGhhdCBJIHdpbGwgaW5jb3Jw b3JhdGUgaW4gdGhlIG5leHQgdmVyc2lvbi4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8ZGl2PjxzcGFu IHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDApOyI+PGJyPg0KPC9zcGFu PjwvZGl2Pg0KPGRpdj4tIEluIG9yZGVyIHRvIG9mZmVyIG1vcmUgZ3JhbnVsYXJpdHksIHNvbWV0 aW1lcyB0aGUgdHJhZmZpYyBpcyByYXRlIGxpbWl0ZWQgdG8gYSBjYXBhY2l0eSBzbWFsbGVyIHRo YW4gdGhlIHBoeXNpY2FsIGxpbmsuIGUuZy4gdGhlIHBoeXNpY2FsIGxpbmsgaGFzIDEwRyBvZiB0 cmFmZmljLCBidXQgb25seSAzRyBpcyBhdmFpbGFibGUgdG8gdGhlIHVzZXIuIFBsZWFzZSBleHBs aWNpdCB3aGV0aGVyIHlvdSBhcmUgcmVmZXJyaW5nIHRvIHBoeXNpY2FsDQogb3IgJnF1b3Q7cmVh bCZxdW90Oy8mcXVvdDtvZmZlcmVkJnF1b3Q7LyZxdW90O2F2YWlsYWJsZSZxdW90OyBjYXBhY2l0 eS4gT24gbXkgc2lkZSwgSSdkIHByZWZlciB0aGUgbGF0dGVyLjwvZGl2Pg0KPGRpdj48c3BhbiBz dHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1 LCAyNTUpOyI+UmVwbHk6IEkmbmJzcDthZ3JlZSZuYnNwO3RoYXQmbmJzcDt0aGUmbmJzcDtiYW5k d2lkdGgmbmJzcDtzaG91bGQmbmJzcDtiZSZuYnNwO3RoZSZuYnNwO2NvbmZpZ3VyZWQmbmJzcDsm bmJzcDthdmFpbGFibGUmbmJzcDtjYXBhY2l0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bGluay4g SSB3aWxsIGV4cGxpY2l0IGl0IGluIHRoZSBuZXh0IHZlcnNpb24uPC9zcGFuPjwvZGl2Pg0KPGRp dj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jmd0OyBUaGUgJnF1b3Q7QmFuZHdpZHRoJnF1b3Q7IGZpZWxk IGlzIDEgb2N0ZXQuJm5ic3A7IEl0cyB2YWx1ZSBpcyB0aGUgYmFuZHdpZHRoIG9mIHRoZSBleGl0 IGxpbmsgaW4gdW5pdCBvZiAxMCBnYnBzIChnaWdhYml0cyBwZXIgc2Vjb25kKS48L2Rpdj4NCjxk aXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PkkgZG9uJ3Qgc2VlIHRoYXQgdGhpcyBpcyBleHRyZW1lbHkg ZnV0dXJlIHByb29mLCBhcyB0aGUgdXNhYmxlIHJhbmdlIGlzIDEtMjU1LiBXaGVuIHRoaXMgcHJv cG9zaXRpb24gZ2V0cyB1c2VkIChpbiB5ZWFycyBmcm9tIG5vdyksIDEwMEcgbGlua3Mgd291bGQg cHJlc3VtYWJseSBiZSB0aGUgZGVmYXVsdC4gTWVhbmluZyB3ZSB3b3VsZCBhbHJlYWR5IGhhdmUg Y29uc3VtZWQgKjEwIGZyb20gdGhlIGJ1ZGdldC4gT25seSBsZWF2aW5nICoyNQ0KIGZvciB0aGUg ZnV0dXJlLiBJJ2QgcHJlZmVyIGEgd2lkZXIgcmFuZ2Ugd2l0aCBsZXNzIHByZWNpc2lvbi4gZS5n LiBiYW5kd2lkdGggaXMgMTBeXmJhbmR3aWR0aCBpbiBnYnBzLiAob3IgMl5eKS48L2Rpdj4NCjxk aXY+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgbGluZS1oZWlnaHQ6IDEuNTsiPlJlcGx5OiZu YnNwOzwvc3Bhbj5JbmRlZWQmbmJzcDt0aGlzJm5ic3A7aXMgb25lIG9mIHRoZSBrZXkgcG9pbnRz IHdlJm5ic3A7c2hvdWxkJm5ic3A7Y29uc2lkZXImbmJzcDtkdXJpbmcmbmJzcDt0aGUmbmJzcDtk ZXNpZ24mbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lY2hhbmlzbS4gSW4gdW5pdCBvZiAxMCBnYnBz LCBvbmUgb2N0ZXQgY2FuIGV4cHJlc3MgdGhlDQogYmFuZHdpZHRoIGZyb20gMTBnYnBzIHRvIDI1 NTBnYnBzLiBJIHRoaW5rIGl0IHNob3VsZCBiZSBvayBmb3IgdGhlIGZ1dHVyZS4gWW91ciBzdWdn ZXN0aW9uIGlzIGRpZmZpY3VsdCB0byBleHByZXNzIDQwZ2JwcywgMTAwZ2JwcyBhbmQgNDAwZ2Jw cyBldGMuIEFueXdheSB3PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBsaW5lLWhlaWdo dDogMS41OyI+ZSZuYnNwO3dpbGwmbmJzcDt0aGluayZuYnNwO2Fib3V0Jm5ic3A7eW91ciZuYnNw O3N1Z2dlc3Rpb24gYW5kIHRyeSB0byBmaW5kDQogYSBiZXR0ZXIgc29sdXRpb24uIFlvdXIgZnVy dGhlciBzdWdnZXN0aW9uIGlzIHdlbGNvbWUuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 IDEwLjVwdDsgbGluZS1oZWlnaHQ6IDEuNTsiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9kaXY+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4mZ3Q7IFRoZSBsaW5rIHdpdGggYmFuZHdpZHRoIGxlc3Mg dGhhbiAxMCBnYnBzIGlzIG5vdCBzdWl0YWJsZSB0byB1c2UgdGhpcyBmZWF0dXJlLjwvZGl2Pg0K PGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+V2h5IG5vdD8gSXQgbG9va3MgdG8gbWUgdGhhdCB0aGUg JVV0aWxpemF0aW9uIGNvdWxkIGJlIHVzZWZ1bCBldmVuIGlmIHRoZSBiYW5kd2lkdGggaXMgbm90 IGFkdmVydGlzZWQuIFBvc3NpYmx5IGEgJnF1b3Q7QmFuZHdpZHRoJnF1b3Q7IHJlc2VydmVkIHZh bHVlIChlLmcuIDApIGNvdWxkIGJlIHNwZWNpZmllZCB0byBpbmRpY2F0ZSB0aGF0IHRoZSBiYW5k d2lkdGggaXMgbm90IGFkdmVydGlzZWQuIFRoaXMgd291bGQgYWxzbyBmaXQgdGhlIGNhc2Ugd2hl cmUNCiBzb21lIEFTZXMgZG8gbm90IHdhbnQgdG8gYWR2ZXJ0aXNlIHRoZWlyIGxpbmsgY2FwYWNp dHkuPC9kaXY+DQo8ZGl2PjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAy NTUsIDI1NSk7Ij5SZXBseTombmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMCwg MCwgMCk7IGZvbnQtc2l6ZTogMTAuNXB0OyBsaW5lLWhlaWdodDogMS41OyBiYWNrZ3JvdW5kLWNv bG9yOiByZ2JhKDAsIDAsIDAsIDApOyI+QWdyZWUuJm5ic3A7V2UmbmJzcDt3aWxsJm5ic3A7cmV2 aXNlJm5ic3A7dGhlJm5ic3A7ZHJhZnQmbmJzcDt0byZuYnNwO3JlZmxlY3QmbmJzcDt0aGlzLjwv c3Bhbj48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PsKnMy4mbmJzcDsgQXBwbGljYXRp b24gQ29uc2lkZXJhdGlvbnM8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZndDsgVGhl IFNETiBjb250cm9sbGVyIHVzZXMgdGhlIGV4aXQgbGluayB1dGlsaXphdGlvbiBpbmZvcm1hdGlv biB0byBzdGVlciB0aGUgSW50ZXJuZXQgYWNjZXNzIHRyYWZmaWMgYW1vbmcgYWxsIHRoZSBleGl0 IGxpbmtzIGZyb20gdGhlIHBlcnNwZWN0aXZlIG9mIHRoZSB3aG9sZSBuZXR3b3JrLjwvZGl2Pg0K PGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+SW5kZWVkLCBwcmVzdW1hYmx5IHRoaXMgaW5mb3JtYXRp b24gaXMgdXNlZCB0byBpbmZsdWVuY2UgdGhlIHJvdXRpbmcgYmVoYXZpb3IuIE1heSBiZSB0aGUg ZG9jdW1lbnQgc2hvdWxkIGluZGljYXRlIHRoYXQgdGhlIHJlY2VwdGlvbiBvZiBzdWNoIGNvbW11 bml0eSBvdmVyIElCR1Agc2Vzc2lvbiBzaG91bGQgbm90IGluZmx1ZW5jZSByb3V0aW5nIGRlY2lz aW9uIHVubGVzcyB0dW5uZWxpbmcgaXMgdXNlZCB0byByZWFjaCB0aGUgQkdQIE5leHQtSG9wLg0K ICh0byBhdm9pZCBmb3J3YXJkaW5nIGxvb3BzLCBpbmNyZW1lbnRhbCBkZXBsb3ltZW50IGlzc3Vl cywgY29tcGxpY2F0aW9ucyBpbiBlcnJvciBoYW5kbGluZykuPC9kaXY+DQo8ZGl2PjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDEwLjVwdDsgbGluZS1oZWlnaHQ6IDEuNTsgYmFja2dyb3VuZC1jb2xv cjogd2luZG93OyI+UmVwbHk6Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDAs IDAsIDApOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDAsIDAsIDAsIDApOyI+VGhhbmtzJm5ic3A7 Zm9yJm5ic3A7cG9pbnRpbmcmbmJzcDtvdXQmbmJzcDt0aGlzLiZuYnNwO1dlJm5ic3A7d2lsbCZu YnNwO2FkZCZuYnNwO3NvbWUmbmJzcDtkZXNjcmlwdGlvbiZuYnNwO2luJm5ic3A7bmV4dCZuYnNw O3JldmlzaW9uPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXNp emU6IDEwLjVwdDsgbGluZS1oZWlnaHQ6IDEuNTsgYmFja2dyb3VuZC1jb2xvcjogcmdiYSgwLCAw LCAwLCAwKTsiPi48L3NwYW4+PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5JbiBhZGRp dGlvbiwgd2hhdCBhcmUgdGhlIGludGVyYWN0aW9ucyB3aXRoIHRoZSBCR1AgTGluayBCYW5kd2lk dGggRXh0ZW5kZWQgY29tbXVuaXRpZXM/IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLWlkci1saW5rLWJhbmR3aWR0aCZuYnNwOyAoSSBrbm93IHRoYXQgdGhlIGRyYWZ0IGV4 cGlyZWQsIGJ1dCBzdGlsbCBpdCdzIGEgV0cgZG9jdW1lbnQgYW5kIGFuIG9mZmljaWFsIElBTkEg Y29kZSBwb2ludCk8L2Rpdj4NCjxkaXY+U2hpcHMgaW4gdGhlIG5pZ2h0PyA8L2Rpdj4NCjxkaXY+ UmVwbHk6Jm5ic3A7PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYmEoMCwgMCwgMCwg MCk7IGZvbnQtc2l6ZTogMTAuNXB0OyBsaW5lLWhlaWdodDogMS41OyI+U28mbmJzcDtmYXImbmJz cDt0aGlzJm5ic3A7ZHJhZnQmbmJzcDtkaWRu4oCZdCZuYnNwO2NvbnNpZGVyJm5ic3A7dGhlJm5i c3A7aW50ZXJhY3Rpb24mbmJzcDt3aXRoJm5ic3A7dGhlJm5ic3A7bGluayZuYnNwO2JhbmR3aWR0 aCZuYnNwO0V4dC4mbmJzcDtjb21tdW5pdHkuJm5ic3A7QXMmbmJzcDt0aGUmbmJzcDtsaW5rJm5i c3A7YmFuZHdpZHRoJm5ic3A7RXh0LiZuYnNwO2NvbW11bml0eSZuYnNwO2lzJm5ic3A7bm9uLXJh bnNpdGl2ZSwmbmJzcDthbmQmbmJzcDt0aGUmbmJzcDtnbG9iYWwmbmJzcDthZG1pbmlzdHJhdG9y Jm5ic3A7c3ViZmllbGQmbmJzcDtpcyZuYnNwO29ubHkmbmJzcDsyLW9jdGV0cywmbmJzcDtpdCZu YnNwO21heSZuYnNwO25vdCZuYnNwO2JlJm5ic3A7YXBwbGljYWJsZSZuYnNwO3RvJm5ic3A7YWxs Jm5ic3A7dGhlJm5ic3A7c2NlbmFyaW9zJm5ic3A7ZGVzY3JpYmVkJm5ic3A7aW4mbmJzcDt0aGlz Jm5ic3A7ZG9jdW1lbnQuPC9zcGFuPjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jmd0 OyZuYnNwOyZuYnNwOyBUbyBhdm9pZCByb3V0ZSBvc2NpbGxhdGlvbiwgdGhlIGV4aXQgcm91dGVy IFNIT1VMRCBzZXQgYSB0aHJlc2hvbGQuJm5ic3A7Jm5ic3A7IFdoZW4gdGhlIHV0aWxpemF0aW9u IGNoYW5nZSByZWFjaGVzIHRoZSB0aHJlc2hvbGQsIHRoZSBleGl0IHJvdXRlciZuYnNwOyBTSE9V TEQgZ2VuZXJhdGUgYSBCR1AgdXBkYXRlIG1lc3NhZ2Ugd2l0aCBjb25nZXN0aW9uIHN0YXR1cyBl eHRlbmRlZCZuYnNwOyBjb21tdW5pdHkuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5J IHRoaW5rIHRoYXQgdGhlIGRvY3VtZW50IHNob3VsZCBiZXR0ZXIgZXZhbHVhdGUgdGhlIGNodXJu IGludHJvZHVjZWQuIEluIHBhcnRpY3VsYXIgdGhlIGNodXJuIGlzIGN1bXVsYXRpdmUgYXMgdGhl IG51bWJlciBvZiBBU2VzIGNyb3NzZWQgaW5jcmVhc2UuIGUuZy4gaWYgd2UgYXNzdW1lIHRoYXQg ZWFjaCBBUyB1c2UgdGhlIGNvbW11bml0eSBxdWl0ZSBjYXJlZnVsbHkgYnkgbm90IGFkdmVydGlz aW5nIG1vcmUgdGhhbiAxIHVwZGF0ZQ0KIHBlciBob3VyLCBpZiB3ZSBoYXZlIDUgQVNlcyBvbiB0 aGUgd2F5LCB0aGUgaW5ncmVzcyBBUyBjYW4gcmVjZWl2ZSA1IChhZGRpdGlvbmFsKSB1cGRhdGVz IHBlciBwcmVmaXggcGVyIGhvdXIuPC9kaXY+DQo8ZGl2PlJlcGx5OiBXZSB3aWxsJm5ic3A7PHNw YW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYmEoMCwgMCwgMCwgMCk7IGZvbnQtc2l6ZTog MTAuNXB0OyBsaW5lLWhlaWdodDogMS41OyI+dGhpbmsmbmJzcDthYm91dCZuYnNwO2l0Jm5ic3A7 ZnVydGhlci4gU29tZXRoaW5nIGxpa2UgVFRMICh0aW1lIHRvIGxpdmUpIHRvIGJlIGludHJvZHVj ZWQ/IFRvIGhhdmUgbGFyZ2VyIHNwYWNlIHRvIGZpdCB0aGlzLCB1c2UgQkdQIGNvbW11bml0eSBj b250YWluZXIgaW5zdGVhZD8gT3INCiBkbyAmbmJzcDt5b3UgJm5ic3A7aGF2ZSAmbmJzcDtzb21l ICZuYnNwO3N1Z2dlc3Rpb25zPzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7 IGxpbmUtaGVpZ2h0OiAxLjU7IGJhY2tncm91bmQtY29sb3I6IHdpbmRvdzsiPiZuYnNwOyZuYnNw Ozwvc3Bhbj48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PjQuJm5ic3A7IFNlY3VyaXR5 IENvbnNpZGVyYXRpb25zPC9kaXY+DQo8ZGl2PiZndDsgVGhpcyBuZXcgZXh0ZW5kZWQgY29tbXVu aXR5IGRvZXMgbm90IGRpcmVjdGx5IGludHJvZHVjZSBhbnkgbmV3IHNlY3VyaXR5IGlzc3Vlcy48 L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PldoYXQgYWJvdXQgdHJ1c3QvY2hlYXRpbmcg Y29uc2lkZXJhdGlvbnM/IEVzcGVjaWFsbHkgZnJvbSByZW1vdGUgQVNlcyB3aXRoIHdoaWNoIHlv dSBoYXZlIHplcm8gcmVsYXRpb25zaGlwPzwvZGl2Pg0KPGRpdj5lLmcuIGFkdmVydGlzaW5nIGFs bGVnZWQgY29uZ2VzdGlvbiBpbiBvcmRlciB0byBURS9pbmZsdWVuY2Ugcm91dGluZyBvZiBvdGhl cnMgQVNlcywgYWR2ZXJ0aXNpbmcgcGxlbnR5IG9mIGZha2UgY2FwYWNpdHkgdG8gYXR0cmFjdCBt b3JlIHRyYWZmaWMvY3VzdG9tZXJzLCBhZHZlcnRpc2luZyB0aGF0IHRoZXkgYXJlIG5ldmVyIGV4 cGVyaWVuY2luZyBhbnkgY29uZ2VzdGlvbiBmb3IgY29tbWVyY2lhbCByZWFzb25zLCBmYWtlIGFk dmVydGlzZW1lbnQNCiBvbiAmcXVvdDtiZWhhbGYmcXVvdDsgb2Ygb3RoZXIgQVNlcy4uLjwvZGl2 Pg0KPGRpdj5SZXBseTombmJzcDs8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdiYSgw LCAwLCAwLCAwKTsgZm9udC1zaXplOiAxMC41cHQ7IGxpbmUtaGVpZ2h0OiAxLjU7Ij5UaGUmbmJz cDt0cnVzdC9jaGVhdGluZyZuYnNwO3Byb2JsZW0geW91Jm5ic3A7bWVudGlvbmVkJm5ic3A7aXMg YSZuYnNwO2dlbmVyYWwmbmJzcDtpc3N1ZSZuYnNwO2ZvciZuYnNwO0JHUC4gQ2FuIHdlIG1ha2Ug c3VyZSB0aGF0IHRoZSByb3V0ZXMgYWR2ZXJ0aXNlZCBieSBhIEJHUCBwZWVyIHNob3VsZCBiZSBh ZHZlcnRpc2VkIGJ5IGl0PyBUaGUNCiBCR1AgcGVlciBjYW4gZ2VuZXJhdGUgc29tZSByb3V0ZXMg bWFsaWNpb3VzbHkuIEFueXdheSw8L3NwYW4+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6 IHJnYmEoMCwgMCwgMCwgMCk7IGZvbnQtc2l6ZTogMTAuNXB0OyBsaW5lLWhlaWdodDogMS41OyI+ Jm5ic3A7IHdlJm5ic3A7d2lsbCZuYnNwO2FkZCZuYnNwO3NvbWUmbmJzcDthbmFseXNpcyZuYnNw O3RvJm5ic3A7dGhpcyZuYnNwO3Byb2JsZW0mbmJzcDtpbiZuYnNwO25leHQmbmJzcDtyZXZpc2lv bi4mbmJzcDtGb3ImbmJzcDtleGFtcGxlLCAmbmJzcDt0aGUmbmJzcDtCR1AgcmVjZWl2ZXIgbWF5 Jm5ic3A7Y2hvb3NlJm5ic3A7dG8mbmJzcDtvbmx5Jm5ic3A7dHJ1c3QmbmJzcDt0aGUmbmJzcDtj b25nZXN0aW9uDQogJm5ic3A7aW5mb3JtYXRpb24mbmJzcDthZHZlcnRpc2VkJm5ic3A7YnkmbmJz cDtzb21lJm5ic3A7cGFydGljdWxhciZuYnNwO0FTZXMsIG9yJm5ic3A7QVNlcyZuYnNwO3dpdGhp biZuYnNwO3BhcnRpY3VsYXImbmJzcDtob3BzLiBBbnkgc3VnZ2VzdGlvbiBmcm9tIHlvdT88L3Nw YW4+PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5UaGFua3MsPC9kaXY+DQo8ZGl2PlJl Z2FyZHMsPC9kaXY+DQo8ZGl2Pi0tQnJ1bm88L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2 Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PkNlIG1lc3NhZ2UgZXQgc2Vz IHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRl bnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYzwvZGl2Pg0KPGRpdj5w YXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4g U2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWdu YWxlcjwvZGl2Pg0KPGRpdj5hIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUg bGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNj ZXB0aWJsZXMgZCdhbHRlcmF0aW9uLDwvZGl2Pg0KPGRpdj5PcmFuZ2UgZGVjbGluZSB0b3V0ZSBy ZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxz aWZpZS4gTWVyY2kuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5UaGlzIG1lc3NhZ2Ug YW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdl ZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OzwvZGl2Pg0KPGRpdj50 aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0 aG9yaXNhdGlvbi48L2Rpdj4NCjxkaXY+SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBp biBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMuPC9kaXY+DQo8ZGl2PkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJl ZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlm aWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC48L2Rpdj4NCjxkaXY+VGhhbmsgeW91LjwvZGl2Pg0K PGRpdj4mbmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_HK2PR0601MB1361F407B2018606BEC9AEE5FCA00HK2PR0601MB1361_-- From nobody Tue Jul 18 02:25:18 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55A96131DDC for ; Tue, 18 Jul 2017 02:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.802 X-Spam-Level: X-Spam-Status: No, score=-4.802 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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=juniper.net 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 Y3vhzCYYyoFM for ; Tue, 18 Jul 2017 02:25:11 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0098.outbound.protection.outlook.com [104.47.32.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFC09131DDF for ; Tue, 18 Jul 2017 02:24:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FpXWQflqB5Mn4R51+0QhRIl00oKifxRQSNp0YflIqmk=; b=ZBpk5Um/E9+72jjvRAxWgIidXVhUpOwyfTqWQG5xVVVHOXdkDDmY+kG2Iw09g/x38NOxRewy8eLCh+TJ6izfg+lXSgR+tqPzNDga6hAMSlftmhOjGQl5IfBSQC+xq2Wq9iAIGB97Nck3wMy8lpaCFhySWrR8wjElr6DypHJlc/E= Authentication-Results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; Received: from [172.29.65.1] (193.110.55.12) by CY1PR05MB2505.namprd05.prod.outlook.com (10.167.10.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Tue, 18 Jul 2017 09:24:43 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: Date: Tue, 18 Jul 2017 11:24:37 +0200 Cc: Jeffrey Haas , Robert Raszuk , idr wg Content-Transfer-Encoding: quoted-printable Message-Id: <83CF8B1D-A9A2-4845-9FF4-3521B286B21D@juniper.net> References: <58C6751D.60306@foobar.org> <20170314204212.GD12864@pfrc.org> <815723FC-B143-4410-B0FF-D9FB4F827862@cisco.com> <20170314213607.GH12864@pfrc.org> <579D00D9-D80F-4625-BF16-0D5112C2FA98@cisco.com> To: "Rajiv Asati (rajiva)" X-Mailer: Apple Mail (2.3124) X-Originating-IP: [193.110.55.12] X-ClientProxiedBy: BN6PR10CA0045.namprd10.prod.outlook.com (10.175.102.159) To CY1PR05MB2505.namprd05.prod.outlook.com (10.167.10.26) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: ec4e9453-5890-4712-844e-08d4cdbed3d8 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(48565401081)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY1PR05MB2505; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2505; 3:xqm2OfLkUNoF+9bZ8qSOVAqGBPSNLZVQlk4JY0gxYjo5Y7s2hjRDJMicTi4k4QS63ILAKJsO1tc7XnvzW3njT/KSCUV5oqlSWiVq+s3vDpJWh2p9VyjddMUSTPtj/9IaFlEN8XAUzGdwFSbMYK9w46jFpNGWE5EGR+I/bR/A+zM7W/bwXDjTpC/xwFh3G6rqv1ik7wYTiIR5fEA4erxwEbN9uEHC2JQqBC2gEdUZmBVoU+oToUGueRieTRabot+9WunW2o8a9o/8rD3MI8DNy4xM6PKgH0cVIgHQ8FLz03qWUnDKlLTGiDNZho8NJgXiT4WjKCGsJKNbBaK9XCKyDKgml6DgJ26ht0r/7i3/OeDYMP51dyY0mmAOT+gmYmtjgKN2kPLZDzB7+wfjDG6K5cvYuEcfVQR3Ccrn765i47GMlB+nvnTmpyYM8eQcNkEXQxmmcdWTuJzN2j+yJ+FYcpfF5xqvXE2H0x7z6/NKm55hKSCI8mqT6/z3h0iNrjdiTQIVbPjdRmRvjDJ/9zivoDECZLN2WL7YM6c/l/B01gtiqr9X3j+y6NnvXNt8RigQUU/DA+kppmK4ZlDRfDz0KlRTSsJ3HJbA7n/llmyjQD/j8jcZy+3FmGS7HyPSa6B0lmZ4xCP6PTVl6iRY95crY/vvLr/3pPQowkjZip5cg4I7d0qti6iitQbXvxniDtwHy4EzBdOmyJzudzFOEwZO+jxoHVxsoixN4/XrO1mMEnCEwB1f1vqULH1SMf1nvrOfSwOYaYvBAyrbi6cDmq1Plw== X-MS-TrafficTypeDiagnostic: CY1PR05MB2505: X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2505; 25:JirE+JwybcLnYb9fAusXJF7DeM1EFcO9Yy/cQ/QpS+phP4GIbxFahJPPNgs90gzM2GCgxknYpcmzUfsQheS0a+3Js8VgBcZjTlgMQz+rssDr94oCF8D6ymsBtbPfkTLZGPpy0MA032L4eDAOZWvr+NsgnAFzH/onl8htKB5sVog2XV7g82YrcdVuWzu6UzJ2ktP06BljgixeT3HySRvK3M4TuR4GWm+WWm9DcYUacvKmbjoGXRb9Nv68T851Kuy/d7QB4QeDG1pi9P8Hjmkj9J9U9gAmB8I55MBBY4Y1mB+6GZ2qdo6L661EWuvO/P7eF2Ff8Vtlt1qaPiGDSXGpq84iBXmGBkn2yyDOZDG7lYt6Vx4hpI6dM3XCWgtx1Wg1lGQb37ge1yoNc9XCdnAeNgf5cLSITWjFWFyAdkgJjp2XzB1lEPku4dFNTCJh0lp+1G+T2WHCOmEmajZgpeAvKmFJs/AkwBiBoi2Wep2gMzkVPAZkI4x3RS+rpJMo5jWfzllC+rGJyHaZ67zsPZfPPoBc3aL+AEb/1XExuV+s+KGrNoCgIDKobVPvkKvU/vSNiDJOPTulrRem1GtGUyM7Fv04/c2JuRMPnFVt7fIUgQz3dqFiSLWdxgMJtFSNalBwBPRJN6upZ+aHVUhBsLCOHL/rynPTJQJxkMCY6FYruAPYMyD1jB9uVRi6f5/IJE4WdXum5JdMUfJHgGklvQwvp6CTCd6bozJTWOWzA3Nvuvb1TY17JM5OlX25mHDULBdAwy5xRltVxkT11RFrmMO+Xuc4rqHfQKnzn6JLljGvTkxXywCNe02xK0OljOH8KvP558xsNAwdTKLPgr2x03BnhlKMDSJmbZyyp8NKUcuQtK77tK4kcXwfa/p05QnStoashlMu8URnuWKBRMwxhpghWyW90RzB9VeALtkL0D12pLg= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2505; 31:C3MLNcD3xbNi53m4aYUw1AePoMdQFpp7TyOvNlqDccKp2zMjzkgf67Cz8Xjk2734pnsGaaX5QwcIyaX5oSX0jGrDZOdJwL36SCRZA6Q0H/cvm4+GACTlqaVCiyVCOJbZI1N3IUD5FjLIsZhNCA+nx/n9AjiKQcoUMQ4tT4pNfG48hyBcW35VhOc4utyYuUe76TcjlMu7opJFs+/BH2FJgv3oWpYkBklWTalERSG8TpdCVpPCb8RWELwd3od0SSBAvp5c/RITOocClQ2KaZqZkozrtx71wSFhMVPzni8A7lud1X+pKHREmXU5XhuEBFq4+6OcsPcVH04RYu37F1iL+aRevlgZqTfo6bYrrxwQw6Ktoq7LOLK1f8DGRjaxDxRafjPQT3vq8xvvJGQJ4hZ1gI28AoHNt2RGu1b5zzVjYRfrsn0c3GblCb4d4i8mlYl+tQ/0grJe17keDkIe2D+qoG2sfysA2rIpGAwIDHf7G0T2tmKVROqEcA2VhwHQ6WVbjeRxSpIZj0O5BU+UuHTNTb/SAwAegRLqSl0vYhzQSSiHC7mGcVV72RPlculn/JQd4tySlV4HWX6gf9HplxTeOJz68XmjLf+Qs66VTax11KeBvDMzVBFyWxL4Qq4v40s1JOxYeFv+omc5f09JO180zPV66VoyYA0gH73Q/2+ydBj4DCusPtgIzCzPo9J0jvXPyYh0n8FWkZBKNd3IQ8EzzA== X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2505; 20:FciVblbf+YWWzfpm8rCU9N57BUfqeHR/6sKY2qGqGTqZq98YSm2jIJqzi7zllXETqpVNjT+huHHFoz/HVC5pPb6Zu51xn2z7X951SKvLB+OoEaTcjPK6NxahL5EwvUeBGdtwiL3oIZE1ZYUpWFdtjA5Es78PfKdB0DDn8kW4v3wVQYs07FW5pyiPQmBOsw4KRvceOlQzU1ru68XzKAuWWk4KO6BtVGA7XpSvPFdhGNd40ES9vv0vXXMFmMpjWJ7g92m7+PC30QO2kS0Y2hIF5X8aVn0zI6433l72aN+kf3Bds6oUCF0mGUJlC8Aw2UmpqBoFnhskGKwpBnHVLs6L2lE0uZPoOrij9zUfBb+lNAcc1qbR5QsEjZUHboZmhcVXvCavYgW2Qayi+LTtELIyia9hMRWrB5/VCVg6CPCMuBJBEpzjHcv5UL8EZT/7dGUcsFH1C1B1JMOVt6kh5pdgTVPfazdpGgYsvAPyvEc5Dg2HpbFnNc9Wf6hGG4wEIlSl X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(236129657087228)(48057245064654)(95692535739014); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(2017060910075)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123564025)(20161123558100)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR05MB2505; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR05MB2505; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTFQUjA1TUIyNTA1OzQ6dWN4dnBVWnlHTkcvSkk3YzFvMlpsNU5YQkVy?= =?utf-8?B?a0hCWnJuc1BmTnhxUkFOM05tSFFTQ3gvaUdjYXdGdFlWY2dwRGhKZzhOQTE2?= =?utf-8?B?S2I4ckUyVFprcG9LQThQUzNIYnJIM0dlVzlUekI2RVMrc1g2eXJzVytUd0ph?= =?utf-8?B?dWptMkdQdmJGZmp3VERNL2w0bCtKeXZPMzRWMVhUUGtnRzdkSjdIdm0vOVJY?= =?utf-8?B?a2RrTVMzbGIrWnZZRHZzQms2ZVhSc3d5ZExaaHN2WWhSNndWRUZFRWVNWjYx?= =?utf-8?B?ZCtCYUxnS3oxRjJhVkRHQW0rd0lFYmxCU2tvcTF1cXJySllLVDNtVHB3MU9W?= =?utf-8?B?UTBzMnBTM2pLV2RyQVFJUGpNcmNkQkNDV2NNd1RkQUpIci9JZ1MzMTQvT3o5?= =?utf-8?B?cUx6Y203cjM5cG5UQXV3NVVNSnpTR2V1eDIzVS8rbVh6ZkhNTmhnbXdQY1N0?= =?utf-8?B?WGVNMVhUaG5idjZrT1daWFlGY0RDNTNuLzdSdlFxK2w5NlZ0aEdKeE5VeGR4?= =?utf-8?B?WDJXaFU1OU1YN2IxbnVHM2R5ZzQvYjQyTk1LcVBlWGFzRDhaNVlwWm9xSUp3?= =?utf-8?B?SlAwc0hsaysxenZGTUM5RFVya1JpUWlmelFFWitsZnpLTkpTZFVFcVpBN0Z6?= =?utf-8?B?RjJRUHp1VGJabm9LYnNZc1p4T0luLytleVNkcTJqeHpYRWp4c1A3Z0RteDVk?= =?utf-8?B?aW81bDdqQm9FdTVrR2liSWJ4MTVJUnBBRG9ieFNSQldjbmE1cHdSOE9vVDJM?= =?utf-8?B?OHdTaW1nN2RCdjdsVmtFU0pEUHkrZk5oM2MyYjBkY2tzM2x6UFZVeSttVEls?= =?utf-8?B?Mkp0UTBvd25rQTJJb1VQemtONHZGVGFaMjViMXd1RVFwam9jNTl5VzZjRDF0?= =?utf-8?B?UkxyTGRqdEtKL0RidnNwSk1xajI2aVk4dUROR3Y4SWlVZTVIOW1nUUliVlV6?= =?utf-8?B?Y3AxTnJYcTNkbkNIRXlXaVY1OWN3cnNYc2p1NU5HbkJRSmF2UFc0WlFNbC9C?= =?utf-8?B?dnVZWUdzV1pGLy9hNWVwVmlNVzR1V3ZMUTRnQzI0SDRRNmRlcExVMTZXUGJF?= =?utf-8?B?UXJjTDZLZUJQclIzc0dpak1DWjNIZ2Z3VFJreGFGZFZTOVVqNjBmN2pIZWx5?= =?utf-8?B?dndiN0N3azFzeStCWjdNQXNlS09BZVBPUmdSZjN4d1Z3dHlkb3lpN3VQbDVM?= =?utf-8?B?ZnZXeGhBYVBCNFpEcG56VjJVMWkxRm1TQ05rbytObnhvYnQyelF5Y2tTUG1I?= =?utf-8?B?STJZaWtEL05nVlJxZUpCV2huTG91SlBrdDJrSFlFeFhXZFAwWTE0NnYwbVJj?= =?utf-8?B?UHZPdjBnSkhybzdBWm9KQkdLcUFYNnZ2V1RaNHVtc1J0eEQ5L3hORXRXclR6?= =?utf-8?B?blhQTGlzTWpFOGlQYlc4NWEzdU8veHNZNXF5QjJ3NUcrbTltTGo0ZGhIZ2U3?= =?utf-8?B?WnF2ZjZEc1dPcEdsLzkxS3N4WXBqYVR2ZkhVRnJBS2tvMVRZOURoa0daeHQ5?= =?utf-8?B?SjFRYXdiOEQrZzRBM3R1UkZnNkE3YmVEM296S1Axd2VNcWFmNUw0TnZtc2pH?= =?utf-8?B?dlhVZkJKTEZBUEZhdER6R0p3ZzBwZS9vZnJLMHJzUmZJamZTclVDWjcxWFNj?= =?utf-8?B?ZU9DakRnYmE4cFl3WDlzcmZTSVpIZHhVSzhKVEJpVVR3aUhFemhSbXk3TVIy?= =?utf-8?B?U1JwUFdPbXlBeDNJRTlFbGFCMmpjVTFhbFpwalptdXVCMmlzd0ROOVk2RlBV?= =?utf-8?B?WWVEeFZOeVZiN0J3bGg5TFptNzlNaTNSQkZON0dlRkloSEZXRXBWOTlnSWNK?= =?utf-8?B?cm1qRUxTZFpjNGEzRjRmeDJwK2ZCRmphVnA1OERualp3UT09?= X-Forefront-PRVS: 037291602B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(7370300001)(4630300001)(6009001)(6049001)(39450400003)(39850400002)(39860400002)(39400400002)(39840400002)(39410400002)(377454003)(24454002)(13464003)(7736002)(82746002)(83716003)(36756003)(6666003)(23676002)(966005)(6486002)(86362001)(7350300001)(6916009)(53546010)(2950100002)(2906002)(189998001)(229853002)(305945005)(77096006)(50226002)(110136004)(6246003)(54906002)(6306002)(230783001)(38730400002)(4326008)(90366009)(5660300001)(25786009)(53936002)(93886004)(76176999)(8746002)(50466002)(50986999)(47776003)(66066001)(33656002)(57306001)(81166006)(6116002)(478600001)(8676002)(42186005)(3846002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2505; H:[172.29.65.1]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTFQUjA1TUIyNTA1OzIzOlJabFMxUUJNdTNjTlA2UEJpZlF0dFdBNlNh?= =?utf-8?B?TG5mV0xBY3IrWVV3cmpaOTRDVkpuaWsySTBDS0JMV3o5R2pmVnpUR3hjQVo5?= =?utf-8?B?b1hkMlUzclg4ZkU0RDdrNjI5THcrMngvNmU0aThiVG9DUWZtLzJ4QW1xY1Zz?= =?utf-8?B?aVdkc2pOelQvUkxub2xuQmNyK2lXZ1JSOEZNSUxkMHZzbGNvTWJzME1pbTFC?= =?utf-8?B?ZGVHV1JPakgxeXhUQ2E1YzVUM05mOW5MNXl1RnArVkl3c1RJY1g3cGN5YlJ2?= =?utf-8?B?OERjMUJkRWZQb1JpcVhHTVdvRThsL2J6YjBGZnJjS214L05FdHFYMHA3MzBw?= =?utf-8?B?ZUIyN1NrY1VvTjZqWXFwWWZqUlpycTZ0WGVVNFM4U3NUQVpWTk1kZW92ZEdR?= =?utf-8?B?ak5lQk9rdTc1ejhqOXZ1aWJxVVp1Zzh5bGtjeXFuQUE2YjF4bUJRdWpMUWVU?= =?utf-8?B?cUtpU1JLVW54a3FrUWNPZ0xEaXBuU2xMY0VzNnQ0SUZwYkp5ZjBLRDRGZjFS?= =?utf-8?B?MmlpTXZXUGg3WkZQdDFVYVlBTkl1a0FqYWw4MEhRSFVIcEJUZ3ZCRWhhbVh0?= =?utf-8?B?ZlVYZ3kzdmNxdWUwbGhLVENMdFlqYVVtWm9NU09NbjJMd0Qva0dEenhVWEZw?= =?utf-8?B?dFMzb21EenF3ZFlUYTVrbXBveHZpSWxLdk5Sek85bHVNYTIvNTFSVkNyV0FG?= =?utf-8?B?VkZKTXU1QlRGL1d1cUNTbGVnT0NSQnc0OXBRYmtUTVpOWCtiTFhMcjhZamNJ?= =?utf-8?B?YUdmbXY5YjgyaGM2VUhIRUxlamYwNGZhVHd3S1puQnlicWtyUDdFeXFGM0lJ?= =?utf-8?B?U1hIVHZlaXZZZWFDUkFuS2VlOVJsRWVud3VUWUdaQ1cvSjhCZTdCWDlNekRN?= =?utf-8?B?N3NyUi9ISnVsN2hnSnpPL2ZaYWdCdzNjZ0ZzK2J6WUtMTjJQdWVXL0NZWFFR?= =?utf-8?B?UU1oTERhZURyU202V1M1eTdnRStCSUVNTTN0R1dEV2hPSXMvaVZqbzVSOVNy?= =?utf-8?B?ZUFTMTl4UnBQUTlUS290U1hJTnUzYnJRSmRjcHJSekVxZXZWZkJBTldkTWhy?= =?utf-8?B?RW12STFLS2JXZ3hKVEtrQ25rSjN4ZHdQaGVwaEhxZmdOaWRGRnVYZ1FWVzFk?= =?utf-8?B?NFJORElqTXJuNzh0OG9QakFQNVlhWllzeG9lZm5XNXdxdk9xZVh0cTdYZmRa?= =?utf-8?B?cWs3Qjg3dlpES1ZrOGsyZnJvNmlKR25DYytld1BLVUxJcnljSm9XYUdYOGxV?= =?utf-8?B?WFRLaFlPSWxmM0t4ZTh6S2dsK2ZtendldVpBcFNuUm9VQ2lRcEE2RXRWZ3BC?= =?utf-8?B?bFJpTmZqNjd1cmFyOE5PMnNDbm1xRmpEd2ZpQ0syYzk0aVo0TjhvUnBSQ01q?= =?utf-8?B?djNiQ2F5UldjMnF4QWpydS9hN0lUdHloZ25IeVV3MmhzQTVsVmlpZHR4eWpV?= =?utf-8?B?Z2hScUorNFl5S0Fzd1MxN1VTcnMrajJFQlkxaWFWMkg5VFBhREtaMVZ4SWV3?= =?utf-8?B?LzdySDhRd3RZVWM3bGxPaHVQUy9jM1o4bTV3OXNlTlRDajNUdFEvQWEzd0Fp?= =?utf-8?B?VWJwUElLZi95dndSTGxsSFJLdGFNb0p6bWxJNGRjNGlNdHB4SWF1UWVpcWxC?= =?utf-8?B?NGlsc0FiVlVvdDNsSzRoTU9iOUFzWGpLM2dyVk52cGxjWDhuOVJPWUVqZUNt?= =?utf-8?B?SzlmNlN5dHBwdktucjVndTdWMnMwU1pUdnRjVkJ6ODEyaUpaZGVxelA0T0cy?= =?utf-8?B?YmluWjlOMnc1RVdSQXh5bjhabGtySDY0d21SVUF2VER3a2R6clNvMlV6OTlL?= =?utf-8?B?ZFIxTzRpcklmZ28vK2hvcnp1RUkrUFFBQTZONXc1OCswakFqQTIvcm9GdTRa?= =?utf-8?B?NWc1SnhSd3N0azVlQXgyc1ozTk43WGN6U3VINjNTd2YrN0FmYXhWTURzZzRw?= =?utf-8?B?WlVuT1diVTFBPT0=?= X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTFQUjA1TUIyNTA1OzY6NFM4YUdJOENHUEZUeTYyS004UkFYR2pBNURE?= =?utf-8?B?dDJNMWNIWDYyMXlpL1hweUZTT3ZrMGpGMWZSNVhrc3RCUDVybk5IQjkwR3pt?= =?utf-8?B?RHVRNmxsTWxEUjE0dnBaclFIQ2Q3amlRQXNnc3AyRS9mdnh0dlZvUEowMkE2?= =?utf-8?B?bE9YNHNISVh5WStQaDdSdytpVmtWY3Y5WmpOSGIrRThaSFFGK2pMTElWV1Z5?= =?utf-8?B?aHBkUFpaOGdOcy9yRUhCUkdHVVhwVEVsaklYeWxpNnNmcEhNRUxjS2pzRHRo?= =?utf-8?B?Z2tINUxNOG4vOThnTW1NaEwrMkpkQXVPenpRc1J1Z1FlOE5BTlA4YVBRL05h?= =?utf-8?B?ak12V1plbndzSC9tWnhlRlJZNnBkd0JGVC9tZ2ZuYXhSQXoxbkVKaEpmc3V4?= =?utf-8?B?VTFMd1RaVStJUnJ5bTJUTXpQNGs4ZENUVFVPby9OQmhQSmh4S2V1dllwMUtY?= =?utf-8?B?NnVBRm9LKzA1R2prNTFiMlFQVkQ1dGNuMGppaWZkQk8rZ00vdjJiWE5hNlNU?= =?utf-8?B?K2NPeXZRUk9JQ2M4dWJjUnFOaTlEempBVzdGaVBYQmI1a0c4RlBoblFCVW5a?= =?utf-8?B?R1pHdklUUFRoT2RDQXBBWUxrSWNhdjJMMTQ1TmxIOHRmQVltbnlnS2w0bDR2?= =?utf-8?B?RDdKOXYzMW5GcWZQVUdNbzV5S0U4b1RDNDQvejF2RmxXaXZkT0R0NzhSc0F2?= =?utf-8?B?K2RXSkxJQlJlVldWNHF2eHFwbVY5eWs4bDduRS85VEp5Z2IzeFRla250bzEx?= =?utf-8?B?ZjJtUlNzQjBpSU9pMDZyYW0xUHVMNkw0MHhSR0hzaGxpRndnanR2MHhlWVVq?= =?utf-8?B?akdWamIzU0ZIdlJLakluODBrNEhnMzQ3Y05vYlM4VHJJYzJBMzdORzJYVjJ1?= =?utf-8?B?K0d0VnFUMDk4c3NrTXY1WmxwZFIvZk1xTEVoUTAwNzc4cE5QRk04YkxGSUh6?= =?utf-8?B?MG91S3lsUk90NEJHMWtRRG5LeFdCUjNONEpqN2VmaVIrN1hnaCt2bnlRVFVi?= =?utf-8?B?bW5weGRwbmVxZkNDeXJVamdIVlJxb1hvUytlbW55bXhQMEp4cFd2Skk4STZR?= =?utf-8?B?a2U4b2VzcXJhTFpnRU9meVJHSHoxcityVWVGVm9STDhFUldzbU5JUEZvcDFa?= =?utf-8?B?U3FWUVphZ2NOODhvMzdiSE1xekQxQVJ2NCtTOEZJbmJEcDZ6RHlNS1ZuNTgy?= =?utf-8?B?R01FeGdMNEp2ajlOMmNqbGtyQU1oZGFWY0Y1K0cvUVRMbmFCd3pMMGVNQ0tI?= =?utf-8?B?OTg4aXlEMDdnU0laVDNMNGJGNVRFSVpKeDhXQXNHQXBlNTJoOHpVdGJ1b3F2?= =?utf-8?B?cVljUUdUaDMzenpLQ0taZHNWcVdtWDR2c1pSQUVORVk1c2ZMeDFwUTdGd2lN?= =?utf-8?Q?vQwjpCg?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2505; 5:ZPXbas4rduiiI0yGvBEx+VZnwTDKf6SqM7r+MXJfWBjFP1MdhlWPUIbGLQ4YWo3T63tAYi0cRoy4c9SzJI4W8jmrcdU0pL0qgN1EmDJO8iulnnCDvvcxaLctGxX89oRBA25xpA9b2pE2Xl/I+hWnKDOxx5TbVMEZm4DEq1vxMw/ttNrXNFuyLC8i1gWnL535uTgsYj7jLpIws7ebN1qAzuU9Kp1Evp+RboVTKwJqA3KvqQG9ZGqZO9YqrWU1JqufIxypFG3EiJgxtKE+MN8wLuc1FMmG380Q8WsxIdfwdAeyK/S+beqhzXA2GOtqA3CbjFrVsjO8p7/MSTPcQj5z5pp0WFKQ83Egccnx22E2J0FoVUxtAva+0DuENkv8jNDaZhCJ5tANgsFTeJB1z4eRy6j/J8FJo+O1Aj5/nJYtzm1VjhiTHNUIGWwFrcmnHdsR3Yd4yr9M42AfYm74QugfTf2eASC8IwJO4Qvj7RrGHXThjvmuq3mpSDRDPbUGTapB; 24:+8B1tZWJF60vcAYloULIMugVrOxIVTBMwTUqr5O303hRPmohztSgL+lTI5DA6mJhv4FmsHAoxLY7nWpOalQVWjgQeEF5fXir8Q7qrOiclQo= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2505; 7:5J7656QoEAXLJXxbthWksRjsJX96ltDxG+i2xnaePqgetQVI6igxCQByBuEE5Izg1lKbQQCGmDjjX784EK3ygdCS3Xh/5AM7vajNyPZb2uWVP4XPuI4bbTTR5S7IlK38L/IrcE6YGDKdavWRSQ0Lc07WGXWUo5tUKKe7DrnMPBjf6yzvtJpluydGcHPDIYQRHf6kXlbnmWgU5gJc5sS7ZGgyevGVInr5/Tzvnjy6ZO/9f+g6CG5pH24lbXwmGH/FGlN3Evj2/s79lef7tcsrj9Fv1ahBu8BnH+SSDnfDfA9h2HqmJLJDH6FQ9fdADhJFN0e0oQ4LEvm6Vy5FT+upgMumtyVsfvMnZkHcvpnTMGH2cxXd6fcGs/cbplsQG2FkEw5sl1tjsPi4VlP1EpjPLWouBE1X5943nQWdFCidioWO179rXRReJSJD69dgGqvOJBtSPv+RKbFnOqsASKJqXbsoY1SHXBzZFwD8OhDd4j17p7s+n6axNnCi/yeACLrHoShc/sM1jcSdhwE7kLoWTvyaR+JG2krgRRwu2E31c/RddKpQL0Cz9Z4DFhtI90g1k2/nO+QCo65xoOEgecuxv/YjSrCtJO+rDHcFxUPNKndBp5SGkH0sdGVZt9cpjAOP/kcQpwHcVEwmPxE3CHd//Ws5v8S5+d5VwilBEnsdQu5K01EE1jLXOP5DrB+tmZ0KlJMahWFdPIM3fKA8+xZ6qJMEGOGDgS775Y5dHqrkLxeZGRm3jCwYO66fXJ/zkaacaWaglVFhR6YeYbmeR4stZFyupye+dZBscAOt40PFQpo= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Jul 2017 09:24:43.6195 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2505 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 09:25:16 -0000 Hi Rajiv, In reviewing draft-ietf-idr-bgp-bestpath-selection-criteria-07, I note = section 3 has: The mechanism(s) to perform the "path availability" check and the selection of particular data plane are a matter of a policy and outside the scope of this document. RS-BFD represents an instance of a specific path availability check and = selection of data plane. Based on that, it seems to me the RS-BFD could = add something like the following in the introduction: [I-D.ietf-idr-bgp-bestpath-selection-criteria] discusses enhancement of the route resolvability condition of section 9.1.2.1 of [RFC4271] to include next hop reachability and path availability checks. This specification represents in part an instance of such, implemented using BFD as the OAM mechanism. If you have other suggestions for text, please send them. Thanks, --John > On Jul 6, 2017, at 12:54 AM, Rajiv Asati (rajiva) = wrote: >=20 > Jeff, John, > =20 > I didn=E2=80=99t see the latest -03 addressing the below. Any plans? > =20 > --=20 > Cheers, > Rajiv =20 > =20 > From: Rajiv Asati > Date: Sunday, April 16, 2017 at 3:42 PM > To: Jeffrey Haas > Cc: "robert@raszuk.net" , "idr@ietf.org" = > Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt > =20 > Hi Jeff, > =20 > =20 >> But more importantly, you'll stop sending it toward your own = peering and >> attracting blackholed traffic. > Indeed. That=E2=80=99s key.=20 > =20 > And it could rely on the route resolvability condition to be = appropriately modified, as described in =20 > = https://tools.ietf.org/html/draft-ietf-idr-bgp-bestpath-selection-criteria= . > =20 >> RS-BFD basically reinvents the same procedure in your draft, = simply being >> specific about the use of BFD as the dataplane liveness check = mechanism. >> However, as you note in the RS-BFD draft, we do leave the option = for other >> mechanisms. >> =20 >> I suspect the other authors of RS-BFD aren't particular where we = pick up our >> text for the resolvability condition. However, if the suggestion = is to make >> a reference to your draft, you'll need to bring it back from = zombie state >> and progress it. :-) > =20 > Agreed. It is alive (-07 version). = https://tools.ietf.org/html/draft-ietf-idr-bgp-bestpath-selection-criteria= -07 > It can be used as a normative reference in your draft.=20 > =20 > --=20 > Cheers, > Rajiv Asati > Distinguished Engineer, Cisco > =20 > -----Original Message----- > From: Jeffrey Haas > Date: Tuesday, March 14, 2017 at 5:36 PM > To: Rajiv Asati > Cc: "robert@raszuk.net" , "idr@ietf.org" = > Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt > =20 > Rajiv, > =20 > On Tue, Mar 14, 2017 at 09:08:24PM +0000, Rajiv Asati (rajiva) = wrote: > > Is the assumption here that the client routers have routing view = limited to what=E2=80=99s provided by the Route Server? If not, then = wouldn=E2=80=99t Client Routers benefit from having to invalidate the = path learned from the remote client router as soon as the connectivity = check failed? > =20 > This is what I believe the procedure says. See section 6. > =20 > > Of course, Client Routers conveying the lack of NLRI = reachability per NH to the Route Server, and expecting Route Server to = provide a different NHs of the NLRIs, and expecting it to be functional, = while still attracting the traffic for unreachable destinations since = the Loc-RIB is still pointing to the unreachable NH for the affected = NLRIs. > =20 > The thing that is somewhat different for a IXP environment running = a route > server than normal eBGP is the low (to zero) likelihood of having = a backup > path. If 10/8 was learned from the route server for nexthop = 192.0.2.1, and > you stop being able to reach that nexthop, removing it from your = forwarding > (unreachable) is your only choice. > =20 > You *might* have a source of that path internally. In that case, = you can > use it. > =20 > But more importantly, you'll stop sending it toward your own = peering and > attracting blackholed traffic. > =20 > > I wonder whether = https://tools.ietf.org/html/draft-ietf-idr-bgp-bestpath-selection-criteria= be useful here. > =20 > In a sense of good timing, John Scudder had brought this to my = attention > about an hour ago.=20 > =20 > RS-BFD basically reinvents the same procedure in your draft, = simply being > specific about the use of BFD as the dataplane liveness check = mechanism. > However, as you note in the RS-BFD draft, we do leave the option = for other > mechanisms. > =20 > I suspect the other authors of RS-BFD aren't particular where we = pick up our > text for the resolvability condition. However, if the suggestion = is to make > a reference to your draft, you'll need to bring it back from = zombie state > and progress it. :-) > =20 > -- Jeff > =20 > =20 > =20 From nobody Tue Jul 18 02:48:19 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08189131A67 for ; Tue, 18 Jul 2017 02:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_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=juniper.net 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 H7oZC4UlteWm for ; Tue, 18 Jul 2017 02:48:16 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0108.outbound.protection.outlook.com [104.47.33.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E19761286B2 for ; Tue, 18 Jul 2017 02:48:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ojFks5RabSqY3WZ4DVHzoj1n3S2HOO4A1y26dVD20NM=; b=hvr3O2UDHw48dKSXZMDhqHvlMvDh5sac/9tvYOXSukE1PyyEm7Z6a5nTP7I3SD88LLlkEOQ9LwASqZJ1OZCGFrqppideP7CD/w9J3S734okTTqtLiMiogZwbSSA3f9INa8WDilKErHPXEpzxmstuUVAE6oEU+60s2nAs+VjuJIA= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; Received: from [172.29.65.1] (193.110.55.12) by BN3PR05MB2498.namprd05.prod.outlook.com (10.167.3.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Tue, 18 Jul 2017 09:48:13 +0000 From: "John G. Scudder" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Jul 2017 11:48:08 +0200 References: To: idr@ietf.org Message-Id: <6B725DB2-B1C9-4326-BB02-683F1DA6BB74@juniper.net> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Originating-IP: [193.110.55.12] X-ClientProxiedBy: BN6PR20CA0051.namprd20.prod.outlook.com (10.171.181.141) To BN3PR05MB2498.namprd05.prod.outlook.com (10.167.3.27) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 812b7d68-3584-448a-6618-08d4cdc21b8b X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(48565401081)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR05MB2498; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 3:ppsXU+8slVbZTbVJI273HBNhcE8flXF4fG36Vu/IlpMhRYiCtL5wbR02D5WXrnaXEDIj/pmJoe5aPRFQ31HbRpfvyQFzp126ghe2TU7sXXVddSPyFM5vh+bPRfsadXxls+mI0LmlQzyfdz6ECdF92084vEQ/BF8csCPv0nVfBW0+sxnf41tPK1Jby8TiX9H92PSVXvg2lNK87atbsnDJyz1faPy71DYNj9S4OTgIOkGKT1NsZuWL8cyBC7ac7XN5fgsenmX48Num8LkJ4hRiHK/gRxPIyj8WzCfz6LKyuI7H2Ks3otq7o1eSE95Z8CSjdlExYnf8vEwtTllC6z5ouKmROzfi/6dJh/EV7T8W+KutSF/KeA3JtR0V/+ad6zGZSp0lv/DIh/PrEuBH4bYSpEU/fdEHE/jF40wLivK4AUcOIhdFDNW6btCF51uodAvov4NdvjYTKezWaMIdpqQMlW+pmIJXDeVtPA+O5TDd9sGn4jQSTlWDxuJHwzEHPAGU/QVSiyYCDM4i3hymTL0pblSuDmO8tc6VxJ27+p3EEQD3yYeaxcK2DbsiUknUro0HGQLv6AWKgQXwtbdIDGFlNfm7deA8pzyrVmZ1reb599/vjSEMhf0rRcHiOL9zHOZf/dURrTIfm4DKuQ+9TS4ZhKxLO7LGHvVPTLlm9tT4IN8qnCnlazXSpVlF9DRW4gLV7edv70YacEwwv+5uqpaLMQUtQMEGoFdFoS+lkzdcnxgsEyadmD29tA+mbEEBQg3A38md5zWThHuqRYFD1LWPFg== X-MS-TrafficTypeDiagnostic: BN3PR05MB2498: X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 25:7lLxmhac5srF3JVuY+5dOCZxZ7eGKbwa+tVpcYI88mv4Ocz/CU6QLJ0BV7S6DRWnW6ZXKCScSw8AHDjDpmiW0yiX7/HkCubpCKpftSDfwEOUfc42l1lqaJ9o65e4SQ74ToVV99Y+pk9WOGGQVp7hwZhuQxyUbILhbFb/Sztq6ARCWs6/FyuNZyZ8/PYu6z8+B58o7eHw07hz6M7pI+3kwY4UIZ9tCbVbZb90pYO5dRMUDBRecANpuQS97qlPGj3YxmNXa+T+5zH4QgCvw0UR1R4Ovjn78CCDUtVsR5eGVYfmTPoefsYchHWkNCYtyOISIErt2D8i/1Zt3fX35jTr9pFIQYEtm9PQ5BG/oAZZLfZeq8ZHI2U4hPSFxHesFcp2zDrahB1d4iRscgUgoB4seSFqze1z3Ol8TPGBz9ridylywdWXTv4faSoXLtbLJsOWbvz69iMi8bcKF3srJpG0hXN2XfK169gGcMwrOl8UigZpjNQmDJ3Vts9SsxwZJtRg9999LutSBxXpSpul0lZ404RyM/w4IqLqdioeX1iavhae+VZk6GW2427smaxnHHI46+knRmUiJY+qcWgoKxz9j3qXiyqif040eVZKkcMkiIAkP0sPI1MwLm5kY1gJwB/Eu9LhVq/UNdLX6BCCzsb1VRX5zsYq5g8DMz7BxiiYT84OKuuRBz4IM9IroKakJzfSZcZLkMfQ3/0K3x2bDILJnBcVfWQe8KAPmBc1eeYZ8bQjCA3svw0XBUQLqa8gO6m5/k2e0O3xvcdj0Ed4pMJqDo78CPY4B1m63z/i7CtTC4ZXgMQi5DymOTRWh3CNhBWjEUZINdSWvIDX0ReHLJww9EBTjXW/8JQt7Bm2veKuriPufU1oN3S+twTHiFnOJilHk2V+hP/InLqBjpCDFvmztMtE1ZFrg7+qqTSwQMjXgd0= X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 31:hvMxSOXHeD+F1Z1DKoYAk3hiPAfJU03zWG5nk93KBhr5TJCsmjxU2lRYp5TBVZU4FwmanZsaYsRgnVTluttV6iHUoBeWAA4+Kl47zENvhnkLdQhblq3bCW3GLAyQ2Xuk3Tk2MLU49diGkfCxgR4d2G21aIVWxGgIRTR7+nogKTKNiHdNim2n5YI4MHUOCL0fQhtLbZIxtsb//962RWQYUvbnIfdqWRL7lE1LlPxr0vOjB+f9BDYpWgdXw/jd7ZdUrRoOEI8hPTRRb8oFbERMg5ANbYwtaZGv54DbJDooVohJVJAyip9vetHJTsgkd3B1azKpbmrOUky68Mcx2luQ0HFPQoqikQeJQQwhKq2vj9ehm5BIqq9Ws//aee+C4LHpsmVCyOsOfLCjbEfedAHtIPV1xC28YxLSuua06e+Ayc6e4hfpfOb4KBrglY/W/BQcNx1J8sdTyMz+WjHs40u6KqxgzFhmQkftrh/CdjxfEyV/CB7JfG/iiw4yhROXFbHZRh3dDUSwhFiUcNekQOw5FqB9Os/u3mrxhLE021FMqbSWJv0+HtWyvsIyXiup6g4KHEQtiLJBFOsYgHoukx5QDwUQl/COvBqpGGAT85VG7WTM/Izp/Y2+h1hL1dUq3od1PwzKzksisUQgLfIDUvbW8hCTqefasHBUo1UjbzATzSTyeS4BlvQwqGSV/xOLTLbNS1g6mRJZnREwpul1vCorAA== X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 20:LA9gO9mi/tOUWo+39bw81v6UoF+RxskVa1OdX0IC7gY99T7rjPtDSQ0zAIhgWrd7ng3cwU1ts8V6BGQ6z4xllElHguCpf6oI1qNUDWSljGh4dKrYyDP39WPNqvIqqRcRGnOBSIB/IuNZ0eXOLfJtjgXkT0WmG0oANUKiOGqcvHJjxAEaJxGAdjBkCCtXYHnsARPYq45EOV2XAy/1bC5JerZNqOxZDQc1qPqeZQp7rwwtSguXvEyHunhKo0awE7UPcA4v3C6Ee9o4G+DEp6oDhTwJ7kt0ZDc47aLo/cY6jWTGgUnKbKeOMr6nMIQtyTe33CYVl3dnXgiDbn2L15LINhPIQ9ZUuXeCp3Mk1kEKwxGwpVQSzKEo3wTz3im25Tl4N3s6BpOnbbiCSBlXrNZMkaTZArFtuIvCQgYMhxA8NMppxg6Ve4WzmZkA6BAj7ii04kdy5v28i5dgypQh0E4rl1czsW4qjamoDZquSKEs2GEWH5iOO1Vlu8Shpc69XJGj X-Exchange-Antispam-Report-Test: UriScan:(278178393323532)(236129657087228)(138986009662008)(95692535739014)(158140799945019)(247924648384137); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(6055026)(6041248)(20161123564025)(20161123558100)(20161123560025)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR05MB2498; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR05MB2498; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR05MB2498; 4:OLnIDWxz9uGLTlfrsRqpZHA7WJ28SRRSHh47K1ZVzb?= =?us-ascii?Q?i3mxCZhxD9WBu4smTynA1QhGH8cKXqlq02WEDdVH1YLerg7eFrDgBAuR9CZH?= =?us-ascii?Q?smzGYQ8iTEXZPcR71g5nn0v8omfY/oZBbQ9jsowYhRSAlz5+mRVYYIvU8oSO?= =?us-ascii?Q?v7yoMwYi4DizdBzNAcPVWl964g/ziCDAdrT4SqZ6c5uYMeA5Yrkq1Su68gzm?= =?us-ascii?Q?6LbneJMtdatIdBYvKYwWwcbvAn1lYXpfCRg8G2utsbAgXrwDTIbhUigq/TKu?= =?us-ascii?Q?DAthyuG7UA1egkA6ht6qfVl/jk9qE88PSjg/mS1QpZpl7vOTOPMvWZR22VPj?= =?us-ascii?Q?wfrkuW5FwBm72YD9yFtEN0t9IrKdzEHnldDMjzIHs5+c8zk8ctVhkpFMlYS7?= =?us-ascii?Q?zC/4dSquEeZJHUGMNnFhtgJ2QM5Ltt8Rb89ewPpBWBU5RpBXRrHRcDIV3s9C?= =?us-ascii?Q?xYB/Ssb0Ljlb9fDuoEuLB+z9Ydr+fOHDzcUQv/bvIf+Wz8hJgy1YzSOmGUe+?= =?us-ascii?Q?zwuLd9gxDEyKu9rN2VE0IQ1TjdPSVpOUUSv35ipObht9V52gp49q9+RSSPNN?= =?us-ascii?Q?8b8McywDFyL6xhxHkkIl2uMwnt18LouYiS1Az5+25kqmDvOhUQ/RG6RrutZ6?= =?us-ascii?Q?pn6y12fu2egzzAOsJCWalHdrrC2lMMn300yaN5I9u1KlvoEAbmRoTl1BpL3j?= =?us-ascii?Q?afj7u6T7EjZpBWmyfHfVfYR0c27rEHGAHQtXc3/zQjDWxlSyKFbD42KB/RXP?= =?us-ascii?Q?opun3QjCcVdkLXDk9OSrIBTn4vsiX4OW1hZlyHY5XZnl9foeb48p5jcN1hry?= =?us-ascii?Q?BkXUvLWDr2I4MYq3zg+f/13D8+w3gqyT3WDYa+77F5ezUDaO7l8/zMxn7ZC/?= =?us-ascii?Q?hGGYPQFHiVoSpjnjiyJaJdINDX2Dqr3l/xpRm6om5oDl7RcfMEoMl0sfhHmp?= =?us-ascii?Q?e3noA53p018GHZZ1HkzVSMD96Z5L3mrhepCoJ+PPjX1rgJ2ipZbkldg54HyV?= =?us-ascii?Q?ATL8aw69bRfmWagbzEvl6naRymAE7kWHKZgIOTOjghETl2Kt/xYipv7cCICl?= =?us-ascii?Q?xeB28T6wdYUdi9kE/z20yR/nZJ3mVggJOk0Igu6PgDu0D3jbwMS5OsHOVuax?= =?us-ascii?Q?C95RHLQSvU5B1F1br2/qLss3AWzZchD6Ayi54pyxo++gsX3gxP+YInz90chN?= =?us-ascii?Q?eCZjMv3vJo6czFSEMmF8+dYgGBu1fA49nBXFdNKjs+MwrnPEq1D6/HUnM5Yv?= =?us-ascii?Q?jasRPoSUxswZYQbisa4sJGygioucQnmogxHNwxeSqWJHFuFjjW2W/7Btc/uX?= =?us-ascii?Q?R2IrBY9De3a8PBY+0XnCkgneK8418gn057/poIURGh0YWFM7FlxG0j1ZhPEY?= =?us-ascii?Q?hJy+fR3Kj8S1W/GFfKoYVfc896K/AbQrOQ+t29wWLys9DyfCyP0nym+U3A5v?= =?us-ascii?Q?S44yIGrg=3D=3D?= X-Forefront-PRVS: 037291602B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(7370300001)(4630300001)(6049001)(6009001)(39410400002)(39400400002)(39840400002)(39850400002)(39450400003)(39860400002)(377454003)(69234005)(53754006)(377424004)(50226002)(110136004)(305945005)(2351001)(6916009)(90366009)(66066001)(76176999)(23726003)(2361001)(50986999)(478600001)(229853002)(50466002)(8746002)(3846002)(6116002)(5660300001)(38730400002)(47776003)(86362001)(36756003)(7736002)(33656002)(81166006)(42186005)(77096006)(2473003)(82746002)(6486002)(83716003)(53936002)(2906002)(189998001)(57306001)(7350300001)(25786009)(6666003)(230783001)(8676002)(24704002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR05MB2498; H:[172.29.65.1]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR05MB2498; 23:AITZh7JJw7roMSf8gQMXofx7SnLN253f4NrS5C7Hl?= =?us-ascii?Q?D48r9V7w2LXBMi//sS14dEumiCGH+1n0VHObKFfa+Zgr5kPs1m6Od4M2EdR7?= =?us-ascii?Q?qPvGM2p/fedn9BQUJKeQZ7V4vWFWj6nt8bFMTPhHnmfcX8y2ZMnKr+pGVSue?= =?us-ascii?Q?P3fy9ABDWYgKe5bNHBtmH/eg/cT4Fpu60+45cZVmt6jQ4DMvbTzJC9g0WOQ5?= =?us-ascii?Q?lvw97eaR8eKs+kmxFB5CS1zR06a8Ulmt7cLTTyG2eLHByDSIU7FFyaA4Z/CS?= =?us-ascii?Q?ZfxmwhI/CMbKsLOa8N/m7sNs7qPoiLvROGv5yu1dixSXZ8+is4BsqJi83L/J?= =?us-ascii?Q?Hf/2Dl291sFzSa487bKNiTmx5cEwkb+wRshMqgnDDrIyH6XtrtUgCY9Vfvg9?= =?us-ascii?Q?ONixrPuc5148Mpw3d0S7GHltVzWDjn2zRotq88CophudTCaRt3fVfkI15Uf6?= =?us-ascii?Q?BFYswpGfa/9NFdQriNVYONHlh0zmcQ+eV0zbFH/OS3y5cWPI1D43REJ96eOp?= =?us-ascii?Q?iRbxroKxHUOR8q8vSvgEmxl25OcGX8o5UK0kES9j58uIFsQYa9BjtR98dJiu?= =?us-ascii?Q?WgpedSeF8soLUHW7lCTRK9iXa30Uj/aRgtcREn9pyZT4JZnAMgeOUSutoAI8?= =?us-ascii?Q?WDhapwTj0/Jm2HbZhToE3H1Oa5DKKvNSJYThKfTrMLEZPHrabeojK4r9/gTV?= =?us-ascii?Q?6PhpJ9Oqm6il/JtO3m4qMh+1rX4N6rHWYplD0+CU2Y7SbbqPaSITbDKA6x0v?= =?us-ascii?Q?c42L6Od9oJfiJ8l21nBP0pST0wjRND4eppczEjGqgqgZC1sw4TYf9WEs1kCw?= =?us-ascii?Q?WQOcV20O9SVLeRc5e6+wc7PmowyS3E/ZUcAkfRL6x9lzQNPWP1h6pienvRVi?= =?us-ascii?Q?+JjgA5k3lWJiZMZo3/UH5VCZ+xZ13Wga3cpwEIv6LaJ3iOgqwZt2QtKi9MeN?= =?us-ascii?Q?abD5VHic6DgySv++3QSX07VQNyf9M9m2yRhb7Td6/yNZG5hQG6u5koKG+LtF?= =?us-ascii?Q?1oqXsuDBfBb7nKGmVQIKPWcm0Abyvs9p3y2gHffFy6lK6O26biKlCN4nS0ll?= =?us-ascii?Q?kh+rK+E+t3nPynfwaoLwtJlec2LNNV5OJ+bK4C0Mp+qaEewCbL+zuMm6n7RF?= =?us-ascii?Q?vC5aRVS0cnyaNqELnlrx+FmPWWprTM4YNQ7HLp+psGigq78NP3yHDw7xLGvd?= =?us-ascii?Q?HwOpytEk0xJ6tK7lAuw9echVdQdtKNYrkQR4LIV/vJ7MHTnwhZjyTa+vb+td?= =?us-ascii?Q?0hw13TZS6/Z4NTjSup4hJvGZ2OEsyF0IXfJ+INwn9TlNTp/fjys1MUmrEJcG?= =?us-ascii?Q?zc87drDtSHYW4t1NbAJ/isqXnpB/SDY6Rz8M3YMIpnDGxGSvLVtFgrMaev3D?= =?us-ascii?Q?6f8tjuqtdM7a2qrZLrgwRklPm0=3D?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR05MB2498; 6:cNtV9ZwLW5bt4MaecgX9l3lIn/Fwzf+zFLbUz/jobf?= =?us-ascii?Q?rBDbJ9SErflcsPCj6ZIqZJDvUMh55lYP919UDZSrb4i/hKuJjFZAvapg/vhL?= =?us-ascii?Q?t6izHcnI1YTRMYeGxPMTHBuPigpC9hWp2kzMt1esmhW/mvYFAfYznCtsQm6J?= =?us-ascii?Q?VfFaIlTcCM7aW1kWoqJ97TXKZuQ8WB/r9Lgcc35joYVXAT2HHwFRMfZ8mwRu?= =?us-ascii?Q?HMv61lO9kfJ+q9SA5yezy/6Ll0kxTAS67+qt3nx/LWwha5pv62XtVGBXCqid?= =?us-ascii?Q?KvLt8YeBB5ksr8lI4VRWmA1/CtIGT1tDX+DP7Qq0MEgI8yXS6DAYGv5f+EkB?= =?us-ascii?Q?uqWg+9F1TYo7rCrIvet4YwHUP+upAViqLBhljzOz6HT8BXsaHsWkNGaQ5Acc?= =?us-ascii?Q?0/MYbNvmqcbvvuisnsqaKVSAez2PAfhHDz8DHVyThR3wiRLy8DS9xYqyE23U?= =?us-ascii?Q?gmq/tLrk64CBoUuxH43TEl2E2L+QP0SRLROmd8nlxX/WpfTkqiFBA9zOMzwf?= =?us-ascii?Q?lsjezUagswbHvqBYuK7WT908BGiqIsX/JB0E+ziO9Wxm6+Pkk7smD/EwNItX?= =?us-ascii?Q?T9Q6MNK/nef/8LxCilCXXvMXxj1BJZx4M3X/f7TZOb5q0AcELG0aHlSn/WbL?= =?us-ascii?Q?Tl8eZvEw9w3now4VFd8UYBKHPGxsjZVm/rsCQsrswIYCKiZ1zJavsG0qkHDb?= =?us-ascii?Q?2swQ4a+bTfm5LVtV9S36Z74Fogo+9XeC3yO5dvwXO2IXYKQcYZXDctZx13LB?= =?us-ascii?Q?pWrRWZex2j6NIr4ZO7VoDEEvjCY/LQWWyLBQO9UMxS4g3XWR2RbcyBx9n2tP?= =?us-ascii?Q?IuDaHYxlo8BUf1kKmRc3urgfBG2MtmGxVL46r0wZmCa28qe8G8GE2Wn81maQ?= =?us-ascii?Q?eMQKpdHRPE7qZKqbV38lkTYVN2EEbChsbrS6T2rLE+jMV2SDjajxcSEXH6Qs?= =?us-ascii?Q?jHdAgF/iO3rFqhTy5sM74H9RNvNYcJJT1WLcTcOWuwjiVl2BT8GZrxThab04?= =?us-ascii?Q?o+HpWohfgECcTfcGRiDk7a?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 5:JgggQFH6P5+hFQuf/x+jb/He6IUW9qOFO0tXJL8T89VR7SSYl9nOpXufmiB1MiZuq6mKjOfqarax/Z+KFXHkiQB1Hb8phIJqvHmYV9adc70MAlarwMRtvODXSgCf4IBQeEoYkO/enPv9Lph5nb0WCO5jqw7Eei2KXl5Q5WdH6a1sYJ9ArXsE+NTJLE9CtX7vzH5VfqYLbqsv6jfNijrjTpl/vwgu1wpo14YFpA5h0y95AFKCPgrWyUOTiMZIX0NOj+S1P6eIbd+Y6rJIUVjrJDlusZhE3zha8nFaqHx56fKi9Z5oW/5XfppyXbaUOebgMWSbIGMX+wWOpEYNOe3EuzQ8TKrM6iOONCfngXQqXB0vY0j65hJiAjQ0nVuOiuDWHVqASIU9ExrZzcrjGFLfgDJiFb31K1N7hNMJME2XbahYcfpN11un7s6P4lYeXFKmRfklSGIFR4NCL9UAKeutSP/K2PGdKQub2giQRQVuYzImFVH5bl8ZZnVYqRx+wTW+; 24:Put7cZwK5tDm2RBawp84z+EgWLQhozqXZLSJzOIdhR6vTmcYd+pHOY6KsAiiQMUFoDTg/70YfpUaFQvne9TfHCU2u/n9UhwQ6YpB4yDlUZ8= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 7:Pw8cj1mT4zIw+ddEi/jN3xSbPWLhrNZN7lld35CggZyOc27uLF8rNW1ybX56dA0mWNJYYBc9hEc8SfDrigk4Cqep7MrMGAaHCQNVqKfbZhIvSELQUUO20tMw+eMTuf5DrbFUsGJrcZk2orKZoEmxmf+duL2Dm9HIR+wlxkdT0H+vlkiUjxUir3ZWR5uEn8i0VNFwfmxGm59g2Y7ZAb37JfnOCfNk5tbnW8h1PsIyH91fJ4sSk+NrzpRSQOXlyHmvXjgXmevK3zzM0UvmAN9t49HOHevNAl1SaVwRybTlz0DNgYhUgKw028hVQavzqg82mbGgfpuRX1v9ryB2aeUGFkwjLjPFDvcSgiQHfLP0i5pPE5YEUfRF5U2eQ24rTUm7D9CfWgUhMtHo5qAcc2MJiUp9uEbzyJ6Izkrc/4T+c6UOR1uEk6/9mw1pVsV17C26dbETg8tIi5jPVDDGMWs6Sdg356w1LgmSZZJcfPrfB5ikkEfShDwcVLl30ifRp/eok9nw+wJLmbV79F/GD6Af18d2DoSfZQld/ErlB61yXXdbfjdE/8MaBKKZiKQAuRrb0dDqttFQhgNVi0LY0B5XGDqD3FeS1tq5XbDnAOq5zcg+jpHyZ2a9M+8jqhw7KXDMx/3nQsgZ8v2RSf81f5dUWUAMPBxs6Qfk8oYkBWfKox58nSjBWEasCos/MoGgtpeDDoS1FOsyhiRg+Zpm4/sLhd7m6obbvLf39H0OwNO/DhHvUWv5CpeiPbdhyPVhi7sA2HQeqiUyZX1p2ANz6+jPhbtlZ/EDYvkIjWByrp64mEM= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Jul 2017 09:48:13.1999 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR05MB2498 Archived-At: Subject: [Idr] Fwd: [IANA #970769] Early allocation for draft-ietf-idr-tunnel-encaps X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 09:48:18 -0000 FYI. --John > Begin forwarded message: >=20 > From: Amanda Baber via RT > Subject: [IANA #970769] Fwd: [Idr] Early allocation for = draft-ietf-idr-tunnel-encaps > Date: July 18, 2017 at 11:24:06 AM GMT+2 > Cc: , , = , > Reply-To: >=20 > Hi all, >=20 > We've completed the following early allocations in the BGP Tunnel = Encapsulation Attribute Sub-TLVs registry: >=20 > 6 Remote Endpoint (TEMPORARY - registered 2017-07-18, expires = 2018-07-18) [draft-ietf-idr-tunnel-encaps] > 7 IPv4 DS Field (TEMPORARY - registered 2017-07-18, expires = 2018-07-18) [draft-ietf-idr-tunnel-encaps] > 8 UDP Destination Port (TEMPORARY - registered 2017-07-18, expires = 2018-07-18) [draft-ietf-idr-tunnel-encaps] > 9 Embedded Label Handling (TEMPORARY - registered 2017-07-18, = expires 2018-07-18) [draft-ietf-idr-tunnel-encaps] > 10 MPLS Label Stack (TEMPORARY - registered 2017-07-18, expires = 2018-07-18) [draft-ietf-idr-tunnel-encaps] > 11 Prefix SID (TEMPORARY - registered 2017-07-18, expires = 2018-07-18) [draft-ietf-idr-tunnel-encaps] >=20 > If the document hasn't been sent to the IESG by that time, we'll = contact you in June 2018 to ask whether you want to renew the = allocations for another year. A second allocation beyond that one would = require IESG approval. >=20 > Best regards, >=20 > Amanda Baber > Lead IANA Services Specialist From nobody Wed Jul 19 00:31:51 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60ED612EE45 for ; Wed, 19 Jul 2017 00:31:49 -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, 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 (1024-bit key) header.d=arista.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 TLjHIVr5mnoY for ; Wed, 19 Jul 2017 00:31:46 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::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 A2B33129562 for ; Wed, 19 Jul 2017 00:31:46 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id y47so28907680uag.0 for ; Wed, 19 Jul 2017 00:31:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arista.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7Lqt3XBiSt0mKoLau+x8lJ+YXmR1BbtRKU+m+XunLFk=; b=Q85f1kdYAGEfpNo8EiRzyS6e2akx08MbEpSirOJ00ZXvvW7OzqV3E/i9btU/ydPVOK XZ+7deB33UiiFp9QSJixrHJlJsyc4zwn/cIHoprh4XWxAdsDYP0ON0vISBo9i2pcpoaJ uXJxP9m7890bAZZw9IXpGWn9TUp+CLycE7GtY= 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=7Lqt3XBiSt0mKoLau+x8lJ+YXmR1BbtRKU+m+XunLFk=; b=dOZ+Uswya+qsJ5RiROinoBIKny912rj2q4/vpcuDDqsL6hWBP2OnSknXOfhBmHooIW 35Pko37A9ZCJjGxRoULQx8bRWY6L3GSOckutCMkpz4gGy4MEq2luJ8Mt3xK+n0AkTXuD DBKFYwE8Z6xKfF4+Iaa7KEnnxzUePqBkJ+nw+4h9rmC/AvpVFBPKNHvm1lOfqeRCgw/g XXsLl0jQCfCjSW8gfXfH0hw8hBUkvOkhpJstoDAGayyyjjX8rmyGasPA6w543ISXzZx/ HwdAJCsPvu9uEVfRkXsWGDbmmuQDPYjitzpW6gURGdZsuejhYW/5TT0pwt5TJnXflkCQ 0IJg== X-Gm-Message-State: AIVw113ivGivdtuj4IeS1SUkCVxozklUoc2np3l0wolwymX8LAl2qNw4 u4DLt1F7l6dkZTI6Hi93DyJPglUctXScOEU= X-Received: by 10.159.59.16 with SMTP id i16mr874072uah.80.1500449505659; Wed, 19 Jul 2017 00:31:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.4.161 with HTTP; Wed, 19 Jul 2017 00:31:45 -0700 (PDT) In-Reply-To: References: <149824800169.17379.9099679082498238196@ietfa.amsl.com> From: Nandan Saha Date: Wed, 19 Jul 2017 13:01:45 +0530 Message-ID: To: stefano previdi Cc: idr@ietf.org Content-Type: multipart/alternative; boundary="f403043c4c98c9f2160554a69fe0" Archived-At: Subject: Re: [Idr] I-D Action: draft-previdi-idr-segment-routing-te-policy-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 07:31:49 -0000 --f403043c4c98c9f2160554a69fe0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you Stefano for clarifying. On Mon, Jul 17, 2017 at 6:12 PM, stefano previdi wrote: > Hi Nandan, > > sorry for being late. See below. > > > > On Jul 3, 2017, at 2:14 PM, Nandan Saha wrote: > > > > Hello! > > > > I have some questions on the NLRI encoding. > > 1. Can the value of NLRI length be less than 96 for IPv4 AFI and less > > than 192 for IPv6 AFI? IOW, can it be less than full mask length for > > the end point address? > > no. > > > > 2. If the answer to (1) is "yes", then what is the rationale for > > keeping the end point address field of the NLRI fixed length? (4 or 16 > > bytes depending on AFI). Should the end point become variable length > > like the NLRI encoding defined in RFC4760? > > 3. If the answer to (1) is "no", how are summary addresses to be > represented? > > > there=E2=80=99s no such concept of =E2=80=9Csummary address=E2=80=9D for = the endpoint encoding. > The draft is going to be updated and the term =E2=80=9Csummary address=E2= =80=9D will be > removed from the endpoint filed description. Sorry for the confusiuon. > > > > Another question which is unrelated to the changes in version 7 of the > draft. > > Section "4.2.1. Acceptance of an SR Policy NLRI" says > > " If the NLRI is not one of the legal lengths, a router supporting > > this document and that imports the route MUST consider it to be > > malformed and MUST apply the "treat-as-withdraw" strategy of [RFC7606] > > " > > It's not clear to me how a receiver can extract a valid route from a > > malformed NLRI. > > > you just have to check the nlri length. > > > > The "treat-as-withdraw" can be applied if the NLRI is > > well formed but some other attributes are malformed, which seems to be > > implied by the following line at the end of the subsection > > "A unacceptable SR Policy update that has an invalid NLRI portion MUST > > trigger a reset of the BGP session.=E2=80=9D > > > that is correct. > > s. > > > > > > Thank you! > > Best regards, > > Nandan > > > > On Sat, Jun 24, 2017 at 1:30 AM, wrote: > >> > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > directories. > >> This draft is a work item of the Inter-Domain Routing of the IETF. > >> > >> Title : Advertising Segment Routing Policies in BGP > >> Authors : Stefano Previdi > >> Clarence Filsfils > >> Paul Mattes > >> Eric Rosen > >> Steven Lin > >> Filename : draft-previdi-idr-segment- > routing-te-policy-07.txt > >> Pages : 30 > >> Date : 2017-06-23 > >> > >> Abstract: > >> This document defines a new BGP SAFI with a new NLRI in order to > >> advertise a candidate path of a Segment Routing Policy (SR Policy). > >> An SR Policy is a set of candidate paths consisting of one or more > >> segment lists. The headend of an SR Policy may learn multiple > >> candidate paths for an SR Policy. Candidate paths may be learned vi= a > >> a number of different mechanisms, e.g., CLI, NetConf, PCEP, or BGP. > >> This document specifies the way in which BGP may be used to > >> distribute candidate paths. New sub-TLVs for the Tunnel > >> Encapsulation Attribute are defined. > >> > >> > >> The IETF datatracker status page for this draft is: > >> https://datatracker.ietf.org/doc/draft-previdi-idr-segment- > routing-te-policy/ > >> > >> There are also htmlized versions available at: > >> https://tools.ietf.org/html/draft-previdi-idr-segment- > routing-te-policy-07 > >> https://datatracker.ietf.org/doc/html/draft-previdi-idr- > segment-routing-te-policy-07 > >> > >> A diff from the previous version is available at: > >> https://www.ietf.org/rfcdiff?url2=3Ddraft-previdi-idr- > segment-routing-te-policy-07 > >> > >> > >> 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/ > >> > >> _______________________________________________ > >> Idr mailing list > >> Idr@ietf.org > >> https://www.ietf.org/mailman/listinfo/idr > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > > --f403043c4c98c9f2160554a69fe0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you Stefano for clarifying.=C2=A0

On Mon, Jul 17, 2017 at 6:12 P= M, stefano previdi <stefano@previdi.net> wrote:
Hi Nandan,

sorry for being late. See below.


> On Jul 3, 2017, at 2:14 PM, Nandan Saha <nandan@arista.com> wrote:
>
> Hello!
>
> I have some questions on the NLRI encoding.
> 1. Can the value of NLRI length be less than 96 for IPv4 AFI and less<= br> > than 192 for IPv6 AFI? IOW, can it be less than full mask length for > the end point address?

no.


> 2. If the answer to (1) is "yes", then what is the rationale= for
> keeping the end point address field of the NLRI fixed length? (4 or 16=
> bytes depending on AFI). Should the end point become variable length > like the NLRI encoding defined in RFC4760?
> 3. If the answer to (1) is "no", how are summary addresses t= o be represented?


there=E2=80=99s no such concept of =E2=80=9Csummary address=E2=80=9D= for the endpoint encoding. The draft is going to be updated and the term = =E2=80=9Csummary address=E2=80=9D will be removed from the endpoint filed d= escription. Sorry for the confusiuon.


> Another question which is unrelated to the changes in version 7 of the= draft.
> Section "4.2.1. Acceptance of an SR Policy NLRI" says
> " If the NLRI is not one of the legal lengths, a router supportin= g
> this document and that imports the route MUST consider it to be
> malformed and MUST apply the "treat-as-withdraw" strategy of= [RFC7606]
> "
> It's not clear to me how a receiver can extract a valid route from= a
> malformed NLRI.


you just have to check the nlri length.


> The "treat-as-withdraw" can be applied if the NLRI is
> well formed but some other attributes are malformed, which seems to be=
> implied by the following line at the end of the subsection
> "A unacceptable SR Policy update that has an invalid NLRI portion= MUST
> trigger a reset of the BGP session.=E2=80=9D


that is correct.

s.


>
> Thank you!
> Best regards,
> Nandan
>
> On Sat, Jun 24, 2017 at 1:30 AM, <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 Inter-Domain Routing of the IETF.=
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0: Advertising Segment Routing Policies in BGP
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: Stefano Previdi
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Clarence Filsfils
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Paul Mattes
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Eric Rosen
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Steven Lin
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : d= raft-previdi-idr-segment-routing-te-policy-07.txt
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0: 30
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 : 2017-06-23
>>
>> Abstract:
>>=C2=A0 =C2=A0This document defines a new BGP SAFI with a new NLRI i= n order to
>>=C2=A0 =C2=A0advertise a candidate path of a Segment Routing Policy= (SR Policy).
>>=C2=A0 =C2=A0An SR Policy is a set of candidate paths consisting of= one or more
>>=C2=A0 =C2=A0segment lists.=C2=A0 The headend of an SR Policy may l= earn multiple
>>=C2=A0 =C2=A0candidate paths for an SR Policy.=C2=A0 Candidate path= s may be learned via
>>=C2=A0 =C2=A0a number of different mechanisms, e.g., CLI, NetConf, = PCEP, or BGP.
>>=C2=A0 =C2=A0This document specifies the way in which BGP may be us= ed to
>>=C2=A0 =C2=A0distribute candidate paths.=C2=A0 New sub-TLVs for the= Tunnel
>>=C2=A0 =C2=A0Encapsulation Attribute are defined.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatr= acker.ietf.org/doc/draft-previdi-idr-segment-routing-te-policy/
>>
>> There are also htmlized versions available at:
>> https://tools.iet= f.org/html/draft-previdi-idr-segment-routing-te-policy-07
>> https:/= /datatracker.ietf.org/doc/html/draft-previdi-idr-segment-routing-= te-policy-07
>>
>> A diff from the previous version is available at:
>> https://w= ww.ietf.org/rfcdiff?url2=3Ddraft-previdi-idr-segment-routing-te-p= olicy-07
>>
>>
>> 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/
>>
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr=
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr


--f403043c4c98c9f2160554a69fe0-- From nobody Wed Jul 19 02:16:59 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 442FB131C52 for ; Wed, 19 Jul 2017 02:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-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 YFDxD-HdFvUz for ; Wed, 19 Jul 2017 02:16:53 -0700 (PDT) Received: from mail-it0-f71.google.com (mail-it0-f71.google.com [209.85.214.71]) (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 8C4D51277BB for ; Wed, 19 Jul 2017 02:16:53 -0700 (PDT) Received: by mail-it0-f71.google.com with SMTP id s132so37548110ita.6 for ; Wed, 19 Jul 2017 02:16:53 -0700 (PDT) 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:date :message-id:subject:from:to:cc; bh=MZ2ZT9nCQNeNtTrmiL73zGAJRwgazBc+5m2/zsZsxJo=; b=XPOSNEn3o4lWPGBmflFX2qEI5rDuzWQcGxE9JeiGlZg8eSiXiqMHExQlRbp2KGA2Ix 9rUa4nFcJ5oTMoBHGGtiT/lahWqEa3w4al3fRQZbAlw7Ytr0k7B5kln+hl1LRP8nKLEl GByj2TDzMmBNlCGEtEfAvynymNpS9AY0+TByis6CjZksv1DQt7jTOM5J/c9oWE8nafAx Flj4GfsYvnfb1aTXK0I7rvUxopinaqL9HKd/r4Tv7GkTZGpprvZdE8/0KqHDTkJpMIOb zyTrPaQHYl3F7Bo5bwW7s+EtwQoZI/NTrZUPXzM8UMxWLfLWKw9pdj3h3A6/iuJeeF/V dkcA== X-Gm-Message-State: AIVw112WlcUWGrLkJxsENLTIEkDD9Tl+Cuw8S7rRLLLh89vt0pyGnpeW OQT3xSIxCebxmE5Ac4AQwVt4IMkkICHEQfjSBJI62Ho= X-Received: by 10.36.121.211 with SMTP id z202mr766184itc.12.1500455812805; Wed, 19 Jul 2017 02:16:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.4.161 with HTTP; Wed, 19 Jul 2017 00:31:45 -0700 (PDT) In-Reply-To: References: <149824800169.17379.9099679082498238196@ietfa.amsl.com> Date: Wed, 19 Jul 2017 13:01:45 +0530 Message-ID: From: Nandan Saha To: stefano previdi Cc: idr@ietf.org Content-Type: multipart/alternative; boundary="94eb2c13a0c4c0da4a0554a69ff6" Archived-At: Subject: Re: [Idr] I-D Action: draft-previdi-idr-segment-routing-te-policy-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 09:16:55 -0000 --94eb2c13a0c4c0da4a0554a69ff6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you Stefano for clarifying. On Mon, Jul 17, 2017 at 6:12 PM, stefano previdi wrote: > Hi Nandan, > > sorry for being late. See below. > > > > On Jul 3, 2017, at 2:14 PM, Nandan Saha wrote: > > > > Hello! > > > > I have some questions on the NLRI encoding. > > 1. Can the value of NLRI length be less than 96 for IPv4 AFI and less > > than 192 for IPv6 AFI? IOW, can it be less than full mask length for > > the end point address? > > no. > > > > 2. If the answer to (1) is "yes", then what is the rationale for > > keeping the end point address field of the NLRI fixed length? (4 or 16 > > bytes depending on AFI). Should the end point become variable length > > like the NLRI encoding defined in RFC4760? > > 3. If the answer to (1) is "no", how are summary addresses to be > represented? > > > there=E2=80=99s no such concept of =E2=80=9Csummary address=E2=80=9D for = the endpoint encoding. > The draft is going to be updated and the term =E2=80=9Csummary address=E2= =80=9D will be > removed from the endpoint filed description. Sorry for the confusiuon. > > > > Another question which is unrelated to the changes in version 7 of the > draft. > > Section "4.2.1. Acceptance of an SR Policy NLRI" says > > " If the NLRI is not one of the legal lengths, a router supporting > > this document and that imports the route MUST consider it to be > > malformed and MUST apply the "treat-as-withdraw" strategy of [RFC7606] > > " > > It's not clear to me how a receiver can extract a valid route from a > > malformed NLRI. > > > you just have to check the nlri length. > > > > The "treat-as-withdraw" can be applied if the NLRI is > > well formed but some other attributes are malformed, which seems to be > > implied by the following line at the end of the subsection > > "A unacceptable SR Policy update that has an invalid NLRI portion MUST > > trigger a reset of the BGP session.=E2=80=9D > > > that is correct. > > s. > > > > > > Thank you! > > Best regards, > > Nandan > > > > On Sat, Jun 24, 2017 at 1:30 AM, wrote: > >> > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > directories. > >> This draft is a work item of the Inter-Domain Routing of the IETF. > >> > >> Title : Advertising Segment Routing Policies in BGP > >> Authors : Stefano Previdi > >> Clarence Filsfils > >> Paul Mattes > >> Eric Rosen > >> Steven Lin > >> Filename : draft-previdi-idr-segment- > routing-te-policy-07.txt > >> Pages : 30 > >> Date : 2017-06-23 > >> > >> Abstract: > >> This document defines a new BGP SAFI with a new NLRI in order to > >> advertise a candidate path of a Segment Routing Policy (SR Policy). > >> An SR Policy is a set of candidate paths consisting of one or more > >> segment lists. The headend of an SR Policy may learn multiple > >> candidate paths for an SR Policy. Candidate paths may be learned vi= a > >> a number of different mechanisms, e.g., CLI, NetConf, PCEP, or BGP. > >> This document specifies the way in which BGP may be used to > >> distribute candidate paths. New sub-TLVs for the Tunnel > >> Encapsulation Attribute are defined. > >> > >> > >> The IETF datatracker status page for this draft is: > >> https://datatracker.ietf.org/doc/draft-previdi-idr-segment- > routing-te-policy/ > >> > >> There are also htmlized versions available at: > >> https://tools.ietf.org/html/draft-previdi-idr-segment- > routing-te-policy-07 > >> https://datatracker.ietf.org/doc/html/draft-previdi-idr- > segment-routing-te-policy-07 > >> > >> A diff from the previous version is available at: > >> https://www.ietf.org/rfcdiff?url2=3Ddraft-previdi-idr- > segment-routing-te-policy-07 > >> > >> > >> 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/ > >> > >> _______________________________________________ > >> Idr mailing list > >> Idr@ietf.org > >> https://www.ietf.org/mailman/listinfo/idr > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > > --94eb2c13a0c4c0da4a0554a69ff6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you Stefano for clarifying.=C2=A0

On Mon, Jul 17, 2017 at 6:12 P= M, stefano previdi <stefano@previdi.net> wrote:
Hi Nandan,

sorry for being late. See below.


> On Jul 3, 2017, at 2:14 PM, Nandan Saha <nandan@arista.com> wrote:
>
> Hello!
>
> I have some questions on the NLRI encoding.
> 1. Can the value of NLRI length be less than 96 for IPv4 AFI and less<= br> > than 192 for IPv6 AFI? IOW, can it be less than full mask length for > the end point address?

no.


> 2. If the answer to (1) is "yes", then what is the rationale= for
> keeping the end point address field of the NLRI fixed length? (4 or 16=
> bytes depending on AFI). Should the end point become variable length > like the NLRI encoding defined in RFC4760?
> 3. If the answer to (1) is "no", how are summary addresses t= o be represented?


there=E2=80=99s no such concept of =E2=80=9Csummary address=E2=80=9D= for the endpoint encoding. The draft is going to be updated and the term = =E2=80=9Csummary address=E2=80=9D will be removed from the endpoint filed d= escription. Sorry for the confusiuon.


> Another question which is unrelated to the changes in version 7 of the= draft.
> Section "4.2.1. Acceptance of an SR Policy NLRI" says
> " If the NLRI is not one of the legal lengths, a router supportin= g
> this document and that imports the route MUST consider it to be
> malformed and MUST apply the "treat-as-withdraw" strategy of= [RFC7606]
> "
> It's not clear to me how a receiver can extract a valid route from= a
> malformed NLRI.


you just have to check the nlri length.


> The "treat-as-withdraw" can be applied if the NLRI is
> well formed but some other attributes are malformed, which seems to be=
> implied by the following line at the end of the subsection
> "A unacceptable SR Policy update that has an invalid NLRI portion= MUST
> trigger a reset of the BGP session.=E2=80=9D


that is correct.

s.


>
> Thank you!
> Best regards,
> Nandan
>
> On Sat, Jun 24, 2017 at 1:30 AM, <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 Inter-Domain Routing of the IETF.=
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0: Advertising Segment Routing Policies in BGP
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: Stefano Previdi
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Clarence Filsfils
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Paul Mattes
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Eric Rosen
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Steven Lin
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : d= raft-previdi-idr-segment-routing-te-policy-07.txt
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0: 30
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 : 2017-06-23
>>
>> Abstract:
>>=C2=A0 =C2=A0This document defines a new BGP SAFI with a new NLRI i= n order to
>>=C2=A0 =C2=A0advertise a candidate path of a Segment Routing Policy= (SR Policy).
>>=C2=A0 =C2=A0An SR Policy is a set of candidate paths consisting of= one or more
>>=C2=A0 =C2=A0segment lists.=C2=A0 The headend of an SR Policy may l= earn multiple
>>=C2=A0 =C2=A0candidate paths for an SR Policy.=C2=A0 Candidate path= s may be learned via
>>=C2=A0 =C2=A0a number of different mechanisms, e.g., CLI, NetConf, = PCEP, or BGP.
>>=C2=A0 =C2=A0This document specifies the way in which BGP may be us= ed to
>>=C2=A0 =C2=A0distribute candidate paths.=C2=A0 New sub-TLVs for the= Tunnel
>>=C2=A0 =C2=A0Encapsulation Attribute are defined.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatr= acker.ietf.org/doc/draft-previdi-idr-segment-routing-te-policy/
>>
>> There are also htmlized versions available at:
>> https://tools.iet= f.org/html/draft-previdi-idr-segment-routing-te-policy-07
>> https:/= /datatracker.ietf.org/doc/html/draft-previdi-idr-segment-routing-= te-policy-07
>>
>> A diff from the previous version is available at:
>> https://w= ww.ietf.org/rfcdiff?url2=3Ddraft-previdi-idr-segment-routing-te-p= olicy-07
>>
>>
>> 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/
>>
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr=
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr


--94eb2c13a0c4c0da4a0554a69ff6-- From nobody Wed Jul 19 04:48:39 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1648A131794 for ; Wed, 19 Jul 2017 04:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 koavlCEM4gxw for ; Wed, 19 Jul 2017 04:48:37 -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 BFD3813178B for ; Wed, 19 Jul 2017 04:48:36 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=31.133.141.64; From: "Susan Hares" To: "'idr@ietf. org'" Date: Wed, 19 Jul 2017 07:42:35 -0400 Message-ID: <004601d30084$1e4f1a60$5aed4f20$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0047_01D30062.973E8BD0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdMAg/lU7iCu2TOrTVqD4h1yUV5p+Q== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] draft-previdi-idr-segment-routing-te-policy-07 - has been adopted X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 11:48:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0047_01D30062.973E8BD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The WG Adoption poll on draft-previdi-idr-segment-routing-te-policy has completed, and this draft has been adopted. The authors should submit this as draft-ietf-idr-segment-routing-te-policy. Sue Hares and John Scudder ------=_NextPart_000_0047_01D30062.973E8BD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The WG = Adoption poll on draft-previdi-idr-segment-routing-te-policy has = completed, and this draft has been adopted.  The authors should = submit this as = draft-ietf-idr-segment-routing-te-policy.

 

Sue Hares = and John Scudder

------=_NextPart_000_0047_01D30062.973E8BD0-- From nobody Wed Jul 19 04:54:21 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF613131CCB for ; Wed, 19 Jul 2017 04:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 c96Ydjrh3qEi for ; Wed, 19 Jul 2017 04:54:19 -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 D130E1252BA for ; Wed, 19 Jul 2017 04:54:18 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=31.133.141.64; From: "Susan Hares" To: "'idr@ietf. org'" Date: Wed, 19 Jul 2017 07:48:07 -0400 Message-ID: <005901d30084$e48e2400$adaa6c00$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005A_01D30063.5D7CF930" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdMAhIyt4Lmad5rZSYmB/cdlGhyp0w== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] draft-vandevelde-idr-bgp-ls-segment-routing-rld-03 has been adopted X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 11:54:20 -0000 This is a multipart message in MIME format. ------=_NextPart_000_005A_01D30063.5D7CF930 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The WG Adoption call for draft-vandevelde-idr-bgp-ls-segment-routing-rld has been adopted. The authors should submit this draft as draft-ietf-idr-bgp-ls-segment-routing-rld. Sue Hares and John Scudder ------=_NextPart_000_005A_01D30063.5D7CF930 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The WG = Adoption call for draft-vandevelde-idr-bgp-ls-segment-routing-rld has = been adopted.  The authors should submit this draft as = draft-ietf-idr-bgp-ls-segment-routing-rld.

 

Sue Hares = and John Scudder

------=_NextPart_000_005A_01D30063.5D7CF930-- From nobody Wed Jul 19 09:12:33 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9574124234; Wed, 19 Jul 2017 09:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.398 X-Spam-Level: X-Spam-Status: No, score=-4.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 0UDnGuxm99I0; Wed, 19 Jul 2017 09:12:29 -0700 (PDT) Received: from relais-inet.orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74506127B60; Wed, 19 Jul 2017 09:12:28 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 08BDF20883; Wed, 19 Jul 2017 18:12:27 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.75]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id BD8B31A00D3; Wed, 19 Jul 2017 18:12:26 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe%18]) with mapi id 14.03.0352.000; Wed, 19 Jul 2017 18:12:26 +0200 From: To: li zhenqiang , "draft-li-idr-congestion-status-extended-community@ietf.org" CC: idr Thread-Topic: draft-li-idr-congestion-status-extended-community Thread-Index: AQHS/xR2ZquQmAoAMES5a+pKpEUSQaJbTbkg Date: Wed, 19 Jul 2017 16:12:26 +0000 Message-ID: <14914_1500480746_596F84EA_14914_50_1_53C29892C857584299CBF5D05346208A47814C43@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <12536_1499779219_5964D093_12536_99_1_53C29892C857584299CBF5D05346208A477FE298@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A47814C43OPEXCLILM21corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] draft-li-idr-congestion-status-extended-community X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 16:12:32 -0000 --_000_53C29892C857584299CBF5D05346208A47814C43OPEXCLILM21corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gWmhlbnFpYW5nLA0KDQpUaGFua3MgZm9yIHlvdXIgcmVwbHkuDQpQbGVhc2Ugc2VlIGlu bGluZSBbQnJ1bm9dDQoNCkZyb206IGxpIHpoZW5xaWFuZyBbbWFpbHRvOmxpX3poZW5xaWFuZ0Bo b3RtYWlsLmNvbV0NClNlbnQ6IE1vbmRheSwgSnVseSAxNywgMjAxNyA1OjUxIFBNDQoNCg0KSGVs bG8gQnJ1bm8sDQoNClRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHlvdXIgY29uc3RydWN0aXZlIGNv bW1lbnRzLiBQbGVhc2Ugc2VlIG15IHJlcGx5IGlubGluZSwgYmVnaW5zIHdpdGggUmVwbHkuIFNv cnJ5IGZvciB0aGUgbGF0ZSByZXNwb25zZS4NCg0KQmVzdCBSZWdhcmRzLA0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCmxpX3poZW5xaWFuZ0Bob3RtYWlsLmNvbTxtYWlsdG86bGlf emhlbnFpYW5nQGhvdG1haWwuY29tPg0KDQpGcm9tOiBicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29t PG1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPg0KRGF0ZTogMjAxNy0wNy0xMSAyMToy MA0KVG86IGRyYWZ0LWxpLWlkci1jb25nZXN0aW9uLXN0YXR1cy1leHRlbmRlZC1jb21tdW5pdHlA aWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWxpLWlkci1jb25nZXN0aW9uLXN0YXR1cy1leHRlbmRlZC1j b21tdW5pdHlAaWV0Zi5vcmc+DQpDQzogaWRyQGlldGYub3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBkcmFmdC1saS1pZHItY29uZ2VzdGlvbi1zdGF0dXMtZXh0ZW5kZWQtY29tbXVu aXR5DQpIaSBhdXRob3JzLA0KDQpQbGVhc2UgZmluZCBiZWxvdyBzb21lIG1pbm9yIGNvbW1lbnRz Lg0KDQrCpzIgIENvbmdlc3Rpb24gU3RhdHVzIEV4dGVuZGVkIENvbW11bml0eQ0KDQo+IFRoZSAi VXRpbGl6YXRpb24iIGZpZWxkIGlzIDEgb2N0ZXQuICBJdHMgdmFsdWUgaXMgdGhlIHV0aWxpemF0 aW9uIG9mIHRoZSBleGl0IGxpbmsgaW4gdW5pdCBvZiBwZXJjZW50DQoNCi0gSXMgdGhpcyB0aGUg dXRpbGl6YXRpb24gb24gdGhlIGxpbmsgb3IgYmVmb3JlIHRoZSBsaW5rIChpLmUuIGJlZm9yZSBk cm9wcGluZyB0aGUgdHJhZmZpYyBpbiBleGNlc3MpID8gSU9XLCBjYW4gdGhpcyBiZSBncmVhdGVy IHRoYW4gMTAwJT8gSSB0aGluayBJJ2QgcHJlZmVyIHRoZSBsYXR0ZXIsIGJ1dCBpbiBhbGwgY2Fz ZXMsIEkgbGlrZSB0byBzZWUgYSB0ZXh0IGRldGFpbGluZyB0aGUgaGFuZGxpbmcgb2YgbnVtYmVy cyA+IDEwMCUuDQpSZXBseTogSWYgaXQgaXMgZWFzeSB0byBnZXQgdGhlIHV0aWxpemF0aW9uIGJl Zm9yZSB0aGUgbGluaywgd2UgY2FuIHVzZSBpdC4gQnV0IEkgYW0gbm90IHN1cmUgYWJvdXQgaXQu IElmIHlvdSBjYW4sIHBsZWFzZSBjb250cmlidXRlIHNvbWUgdGV4dCB0aGF0IEkgd2lsbCBpbmNv cnBvcmF0ZSBpbiB0aGUgbmV4dCB2ZXJzaW9uLg0KW0JydW5vXSBUaGFua3MuDQpJIGNvdWxkIHBy b3Bvc2UNCk9MRDogICBJdHMgdmFsdWUgaXMgdGhlIHV0aWxpemF0aW9uIG9mIHRoZSBleGl0IGxp bmsgaW4gdW5pdCBvZiBwZXJjZW50Lg0KTkVXOiAgIEl0cyB2YWx1ZSBpcyB0aGUgdXRpbGl6YXRp b24gb2YgdGhlIGV4aXQgbGluayBpbiB1bml0IG9mIHBlcmNlbnQuIEl0IG1heSBiZSBoaWdoZXIg dGhhbiAxMDAlIGlmIHRoZSBpbmNvbWluZyB0cmFmZmljIGlzIGhpZ2hlciB0aGFuIHRoZSBsaW5r IGNhcGFjaXR5Lg0KDQoNCi0gSW4gb3JkZXIgdG8gb2ZmZXIgbW9yZSBncmFudWxhcml0eSwgc29t ZXRpbWVzIHRoZSB0cmFmZmljIGlzIHJhdGUgbGltaXRlZCB0byBhIGNhcGFjaXR5IHNtYWxsZXIg dGhhbiB0aGUgcGh5c2ljYWwgbGluay4gZS5nLiB0aGUgcGh5c2ljYWwgbGluayBoYXMgMTBHIG9m IHRyYWZmaWMsIGJ1dCBvbmx5IDNHIGlzIGF2YWlsYWJsZSB0byB0aGUgdXNlci4gUGxlYXNlIGV4 cGxpY2l0IHdoZXRoZXIgeW91IGFyZSByZWZlcnJpbmcgdG8gcGh5c2ljYWwgb3IgInJlYWwiLyJv ZmZlcmVkIi8iYXZhaWxhYmxlIiBjYXBhY2l0eS4gT24gbXkgc2lkZSwgSSdkIHByZWZlciB0aGUg bGF0dGVyLg0KUmVwbHk6IEkgYWdyZWUgdGhhdCB0aGUgYmFuZHdpZHRoIHNob3VsZCBiZSB0aGUg Y29uZmlndXJlZCAgYXZhaWxhYmxlIGNhcGFjaXR5IG9mIHRoZSBsaW5rLiBJIHdpbGwgZXhwbGlj aXQgaXQgaW4gdGhlIG5leHQgdmVyc2lvbi4NCiBbQnJ1bm9dIGdyZWF0IHRoYW5rcy4NCj4gVGhl ICJCYW5kd2lkdGgiIGZpZWxkIGlzIDEgb2N0ZXQuICBJdHMgdmFsdWUgaXMgdGhlIGJhbmR3aWR0 aCBvZiB0aGUgZXhpdCBsaW5rIGluIHVuaXQgb2YgMTAgZ2JwcyAoZ2lnYWJpdHMgcGVyIHNlY29u ZCkuDQoNCkkgZG9uJ3Qgc2VlIHRoYXQgdGhpcyBpcyBleHRyZW1lbHkgZnV0dXJlIHByb29mLCBh cyB0aGUgdXNhYmxlIHJhbmdlIGlzIDEtMjU1LiBXaGVuIHRoaXMgcHJvcG9zaXRpb24gZ2V0cyB1 c2VkIChpbiB5ZWFycyBmcm9tIG5vdyksIDEwMEcgbGlua3Mgd291bGQgcHJlc3VtYWJseSBiZSB0 aGUgZGVmYXVsdC4gTWVhbmluZyB3ZSB3b3VsZCBhbHJlYWR5IGhhdmUgY29uc3VtZWQgKjEwIGZy b20gdGhlIGJ1ZGdldC4gT25seSBsZWF2aW5nICoyNSBmb3IgdGhlIGZ1dHVyZS4gSSdkIHByZWZl ciBhIHdpZGVyIHJhbmdlIHdpdGggbGVzcyBwcmVjaXNpb24uIGUuZy4gYmFuZHdpZHRoIGlzIDEw Xl5iYW5kd2lkdGggaW4gZ2Jwcy4gKG9yIDJeXikuDQpSZXBseTogSW5kZWVkIHRoaXMgaXMgb25l IG9mIHRoZSBrZXkgcG9pbnRzIHdlIHNob3VsZCBjb25zaWRlciBkdXJpbmcgdGhlIGRlc2lnbiBv ZiB0aGUgbWVjaGFuaXNtLiBJbiB1bml0IG9mIDEwIGdicHMsIG9uZSBvY3RldCBjYW4gZXhwcmVz cyB0aGUgYmFuZHdpZHRoIGZyb20gMTBnYnBzIHRvIDI1NTBnYnBzLiBJIHRoaW5rIGl0IHNob3Vs ZCBiZSBvayBmb3IgdGhlIGZ1dHVyZS4gWW91ciBzdWdnZXN0aW9uIGlzIGRpZmZpY3VsdCB0byBl eHByZXNzIDQwZ2JwcywgMTAwZ2JwcyBhbmQgNDAwZ2JwcyBldGMuIEFueXdheSB3ZSB3aWxsIHRo aW5rIGFib3V0IHlvdXIgc3VnZ2VzdGlvbiBhbmQgdHJ5IHRvIGZpbmQgYSBiZXR0ZXIgc29sdXRp b24uIFlvdXIgZnVydGhlciBzdWdnZXN0aW9uIGlzIHdlbGNvbWUuDQpbQnJ1bm9dIEkgYWdyZWUg dGhhdCBteSBzdWdnZXN0aW9uIGNhbuKAmXQgZXhwcmVzcyBwcmVjaXNlIHZhbHVlcy4gIEdpdmVu IHRoYXQgdHlwaWNhbGx5IHdlIGhhdmUgbXVsdGlwbGUvbWFueSBpbmdyZXNzIHNlbmRpbmcgdHJh ZmZpYyB0byBvbmUgc2luZ2xlIGludGVyZmFjZSwgSSBkb27igJl0IGZlZWwgdGhhdCBoYXZpbmcg YSBwcmVjaXNlIGJhbmR3aWR0aCB2YWx1ZSBpcyBhbiBhYnNvbHV0ZSByZXF1aXJlbWVudCBhcyBv bmUgc2VuZGVyIGNhbuKAmXQgdXNlIGFsbCB0aGF0IGJhbmR3aWR0aC4gSXQgbmVlZCB0byBzaGFy ZSBpcyB3aXRoIG90aGVyIGluZ3Jlc3MgYW5kIGhhcyBubyB3YXkgb2Yga25vd2luZyBob3cgbXVj aCBvdGhlciBpbmdyZXNzIHdpbGwgYWRhcHQgYW5kIHNlbmQgbW9yZSBvciBsZXNzIHRyYWZmaWMu IEJ1dCBpdOKAmXMgcmVhbGx5IHVwIHRvIHlvdS4NCg0KDQo+IFRoZSBsaW5rIHdpdGggYmFuZHdp ZHRoIGxlc3MgdGhhbiAxMCBnYnBzIGlzIG5vdCBzdWl0YWJsZSB0byB1c2UgdGhpcyBmZWF0dXJl Lg0KDQpXaHkgbm90PyBJdCBsb29rcyB0byBtZSB0aGF0IHRoZSAlVXRpbGl6YXRpb24gY291bGQg YmUgdXNlZnVsIGV2ZW4gaWYgdGhlIGJhbmR3aWR0aCBpcyBub3QgYWR2ZXJ0aXNlZC4gUG9zc2li bHkgYSAiQmFuZHdpZHRoIiByZXNlcnZlZCB2YWx1ZSAoZS5nLiAwKSBjb3VsZCBiZSBzcGVjaWZp ZWQgdG8gaW5kaWNhdGUgdGhhdCB0aGUgYmFuZHdpZHRoIGlzIG5vdCBhZHZlcnRpc2VkLiBUaGlz IHdvdWxkIGFsc28gZml0IHRoZSBjYXNlIHdoZXJlIHNvbWUgQVNlcyBkbyBub3Qgd2FudCB0byBh ZHZlcnRpc2UgdGhlaXIgbGluayBjYXBhY2l0eS4NClJlcGx5OiBBZ3JlZS4gV2Ugd2lsbCByZXZp c2UgdGhlIGRyYWZ0IHRvIHJlZmxlY3QgdGhpcy4NCiBbQnJ1bm9dIG9rLCB0aGFua3MNCsKnMy4g IEFwcGxpY2F0aW9uIENvbnNpZGVyYXRpb25zDQoNCj4gVGhlIFNETiBjb250cm9sbGVyIHVzZXMg dGhlIGV4aXQgbGluayB1dGlsaXphdGlvbiBpbmZvcm1hdGlvbiB0byBzdGVlciB0aGUgSW50ZXJu ZXQgYWNjZXNzIHRyYWZmaWMgYW1vbmcgYWxsIHRoZSBleGl0IGxpbmtzIGZyb20gdGhlIHBlcnNw ZWN0aXZlIG9mIHRoZSB3aG9sZSBuZXR3b3JrLg0KDQpJbmRlZWQsIHByZXN1bWFibHkgdGhpcyBp bmZvcm1hdGlvbiBpcyB1c2VkIHRvIGluZmx1ZW5jZSB0aGUgcm91dGluZyBiZWhhdmlvci4gTWF5 IGJlIHRoZSBkb2N1bWVudCBzaG91bGQgaW5kaWNhdGUgdGhhdCB0aGUgcmVjZXB0aW9uIG9mIHN1 Y2ggY29tbXVuaXR5IG92ZXIgSUJHUCBzZXNzaW9uIHNob3VsZCBub3QgaW5mbHVlbmNlIHJvdXRp bmcgZGVjaXNpb24gdW5sZXNzIHR1bm5lbGluZyBpcyB1c2VkIHRvIHJlYWNoIHRoZSBCR1AgTmV4 dC1Ib3AuICh0byBhdm9pZCBmb3J3YXJkaW5nIGxvb3BzLCBpbmNyZW1lbnRhbCBkZXBsb3ltZW50 IGlzc3VlcywgY29tcGxpY2F0aW9ucyBpbiBlcnJvciBoYW5kbGluZykuDQpSZXBseTogVGhhbmtz IGZvciBwb2ludGluZyBvdXQgdGhpcy4gV2Ugd2lsbCBhZGQgc29tZSBkZXNjcmlwdGlvbiBpbiBu ZXh0IHJldmlzaW9uLg0KIFtCcnVub10gb2ssIHRoYW5rcy4NCkluIGFkZGl0aW9uLCB3aGF0IGFy ZSB0aGUgaW50ZXJhY3Rpb25zIHdpdGggdGhlIEJHUCBMaW5rIEJhbmR3aWR0aCBFeHRlbmRlZCBj b21tdW5pdGllcz8gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaWRyLWxp bmstYmFuZHdpZHRoICAoSSBrbm93IHRoYXQgdGhlIGRyYWZ0IGV4cGlyZWQsIGJ1dCBzdGlsbCBp dCdzIGEgV0cgZG9jdW1lbnQgYW5kIGFuIG9mZmljaWFsIElBTkEgY29kZSBwb2ludCkNClNoaXBz IGluIHRoZSBuaWdodD8NClJlcGx5OiBTbyBmYXIgdGhpcyBkcmFmdCBkaWRu4oCZdCBjb25zaWRl ciB0aGUgaW50ZXJhY3Rpb24gd2l0aCB0aGUgbGluayBiYW5kd2lkdGggRXh0LiBjb21tdW5pdHku IEFzIHRoZSBsaW5rIGJhbmR3aWR0aCBFeHQuIGNvbW11bml0eSBpcyBub24tcmFuc2l0aXZlLCBh bmQgdGhlIGdsb2JhbCBhZG1pbmlzdHJhdG9yIHN1YmZpZWxkIGlzIG9ubHkgMi1vY3RldHMsIGl0 IG1heSBub3QgYmUgYXBwbGljYWJsZSB0byBhbGwgdGhlIHNjZW5hcmlvcyBkZXNjcmliZWQgaW4g dGhpcyBkb2N1bWVudC4NCltCcnVub10gSSB3YXMgbm90IHN1Z2dlc3RpbmcgdG8gcmVwbGFjZSBj b25nZXN0aW9uLXN0YXR1cyB3aXRoIGxpbmstYmFuZHdpZHRoLiBJIHdhcyBhc2tpbmcgZm9yIHRo ZSBleHBlY3RlZCBiZWhhdmlvciBpZiBsaW5rLWJhbmR3aWR0aCBhZHZlcnRpc2UgYSBjYXBhY2l0 eSBvZiA0MEcgd2hpbGUgY29uZ2VzdGlvbi1zdGF0dXMgYWR2ZXJ0aXNlIGEgY2FwYWNpdHkgb2Yg MTAwRy4NCg0KPiAgIFRvIGF2b2lkIHJvdXRlIG9zY2lsbGF0aW9uLCB0aGUgZXhpdCByb3V0ZXIg U0hPVUxEIHNldCBhIHRocmVzaG9sZC4gICBXaGVuIHRoZSB1dGlsaXphdGlvbiBjaGFuZ2UgcmVh Y2hlcyB0aGUgdGhyZXNob2xkLCB0aGUgZXhpdCByb3V0ZXIgIFNIT1VMRCBnZW5lcmF0ZSBhIEJH UCB1cGRhdGUgbWVzc2FnZSB3aXRoIGNvbmdlc3Rpb24gc3RhdHVzIGV4dGVuZGVkICBjb21tdW5p dHkuDQoNCkkgdGhpbmsgdGhhdCB0aGUgZG9jdW1lbnQgc2hvdWxkIGJldHRlciBldmFsdWF0ZSB0 aGUgY2h1cm4gaW50cm9kdWNlZC4gSW4gcGFydGljdWxhciB0aGUgY2h1cm4gaXMgY3VtdWxhdGl2 ZSBhcyB0aGUgbnVtYmVyIG9mIEFTZXMgY3Jvc3NlZCBpbmNyZWFzZS4gZS5nLiBpZiB3ZSBhc3N1 bWUgdGhhdCBlYWNoIEFTIHVzZSB0aGUgY29tbXVuaXR5IHF1aXRlIGNhcmVmdWxseSBieSBub3Qg YWR2ZXJ0aXNpbmcgbW9yZSB0aGFuIDEgdXBkYXRlIHBlciBob3VyLCBpZiB3ZSBoYXZlIDUgQVNl cyBvbiB0aGUgd2F5LCB0aGUgaW5ncmVzcyBBUyBjYW4gcmVjZWl2ZSA1IChhZGRpdGlvbmFsKSB1 cGRhdGVzIHBlciBwcmVmaXggcGVyIGhvdXIuDQpSZXBseTogV2Ugd2lsbCB0aGluayBhYm91dCBp dCBmdXJ0aGVyLiBTb21ldGhpbmcgbGlrZSBUVEwgKHRpbWUgdG8gbGl2ZSkgdG8gYmUgaW50cm9k dWNlZD8gVG8gaGF2ZSBsYXJnZXIgc3BhY2UgdG8gZml0IHRoaXMsIHVzZSBCR1AgY29tbXVuaXR5 IGNvbnRhaW5lciBpbnN0ZWFkPyBPciBkbyAgeW91ICBoYXZlICBzb21lICBzdWdnZXN0aW9ucz8N CiBbQnJ1bm9dIEFzIG9mIHRvZGF5LCBJIHdhcyBvbmx5IGNhbGxpbmcgZm9yIG1vcmUgdGV4dCBo aWdobGlnaHRpbmcgdGhhdCB0aGUgY2h1cm4gaW5jcmVhc2UgbGluZWFybHkgd2l0aCB0aGUgbnVt YmVyIG9mIEFTZXMgYXR0YWNoaW5nIHRoaXMgY29tbXVuaXR5IG9uIGEgZ2l2ZW4gcHJlZml4Lg0K T25lIHN1Z2dlc3Rpb24gdG8gaW1wcm92ZSB0aGUgYmVoYXZpb3I6IOKAnFdoZW4gb25lIEJHUCBy b3V0ZXIgbmVlZHMgdG8gcmUtYWR2ZXJ0aXNlIGEgQkdQIHBhdGggZHVlIHRvIGF0dHJpYnV0ZSBj aGFuZ2VzLCBpdCBTSE9VTEQgdXBkYXRlIGl0cyBjb25nZXN0aW9uLXN0YXR1cy1jb21tdW5pdHkg YXQgdGhlIHNhbWUgdGltZS4gVGhpcyBhbGxvd3MgcmVkdWNpbmcgdGhlIGNodXJuIGFzIG9uZSB0 aGUgZmluYWwgaW5ncmVzcyB3aWxsIHJlY2VpdmUgYSBzaW5nbGUgVVBEQVRFIHJlZnJlc2hpbmcg dGhlIE4gY29tbXVuaXRpZXMsIHJhdGhlciB0aGFuIE4gVVBEQVRFcywgZWFjaCByZWZyZXNoaW5n IG9uZSBjb21tdW5pdHnigJ0uDQo0LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCj4gVGhpcyBu ZXcgZXh0ZW5kZWQgY29tbXVuaXR5IGRvZXMgbm90IGRpcmVjdGx5IGludHJvZHVjZSBhbnkgbmV3 IHNlY3VyaXR5IGlzc3Vlcy4NCg0KV2hhdCBhYm91dCB0cnVzdC9jaGVhdGluZyBjb25zaWRlcmF0 aW9ucz8gRXNwZWNpYWxseSBmcm9tIHJlbW90ZSBBU2VzIHdpdGggd2hpY2ggeW91IGhhdmUgemVy byByZWxhdGlvbnNoaXA/DQplLmcuIGFkdmVydGlzaW5nIGFsbGVnZWQgY29uZ2VzdGlvbiBpbiBv cmRlciB0byBURS9pbmZsdWVuY2Ugcm91dGluZyBvZiBvdGhlcnMgQVNlcywgYWR2ZXJ0aXNpbmcg cGxlbnR5IG9mIGZha2UgY2FwYWNpdHkgdG8gYXR0cmFjdCBtb3JlIHRyYWZmaWMvY3VzdG9tZXJz LCBhZHZlcnRpc2luZyB0aGF0IHRoZXkgYXJlIG5ldmVyIGV4cGVyaWVuY2luZyBhbnkgY29uZ2Vz dGlvbiBmb3IgY29tbWVyY2lhbCByZWFzb25zLCBmYWtlIGFkdmVydGlzZW1lbnQgb24gImJlaGFs ZiIgb2Ygb3RoZXIgQVNlcy4uLg0KUmVwbHk6IFRoZSB0cnVzdC9jaGVhdGluZyBwcm9ibGVtIHlv dSBtZW50aW9uZWQgaXMgYSBnZW5lcmFsIGlzc3VlIGZvciBCR1AuIENhbiB3ZSBtYWtlIHN1cmUg dGhhdCB0aGUgcm91dGVzIGFkdmVydGlzZWQgYnkgYSBCR1AgcGVlciBzaG91bGQgYmUgYWR2ZXJ0 aXNlZCBieSBpdD8gVGhlIEJHUCBwZWVyIGNhbiBnZW5lcmF0ZSBzb21lIHJvdXRlcyBtYWxpY2lv dXNseS4gQW55d2F5LCAgd2Ugd2lsbCBhZGQgc29tZSBhbmFseXNpcyB0byB0aGlzIHByb2JsZW0g aW4gbmV4dCByZXZpc2lvbi4gRm9yIGV4YW1wbGUsICB0aGUgQkdQIHJlY2VpdmVyIG1heSBjaG9v c2UgdG8gb25seSB0cnVzdCB0aGUgY29uZ2VzdGlvbiAgaW5mb3JtYXRpb24gYWR2ZXJ0aXNlZCBi eSBzb21lIHBhcnRpY3VsYXIgQVNlcywgb3IgQVNlcyB3aXRoaW4gcGFydGljdWxhciBob3BzLiBB bnkgc3VnZ2VzdGlvbiBmcm9tIHlvdT8NCiAgW0JydW5vXSBJIGFncmVlIHRoYXQgdGhpcyBpcyBh IGdlbmVyYWwgdHJ1c3QgaXNzdWUgaW4gQkdQLCBidXQgdGhpcyBkb2N1bWVudCBwcm9wb3NlcyB0 byBhZHZlcnRpc2UgbW9yZSBpbmZvcm1hdGlvbiBoZW5jZSBpbnRyb2R1Y2UgbmV3IGNvbnNpZGVy YXRpb24uIFBsdXMgaW4gdGhlIGVuZCwgaWYgeW91IGRvbuKAmXQgdHJ1c3QgdGhlIGRhdGEsIHRo ZXJlIGlzIG5vIG5lZWQgdG8gc2VuZCB0aGVtIGluIHRoZSBmaXJzdCBwbGFjZS4NCk9uZSBwb3Nz aWJsZSBkZXBsb3ltZW50IG1vZGVsIGlzIHRvIGZpbHRlciBjb25nZXN0aW9uLXN0YXR1cyBjb21t dW5pdGllcyBhdCB0aGUgYm9yZGVyIG9mIHlvdSB0cnVzdC9hZG1pbmlzdHJhdGl2ZSBkb21haW4u IEhlbmNlIGFsbCB0aGUgb25lIHlvdSByZWNlaXZlIGFyZSB0cnVzdGVkLg0KT3RoZXIgb3B0aW9u cyBtYXkgYmUgdG8gdHJ5IHRvIHNhbml0aXplIHRoZSByZWNlaXZlZCB2YWx1ZSBiYXNlZCBvbiBh LXByaW9yaSBrbm93bGVkZ2UvZXhwZWN0YXRpb25zLiAoZS5nLiByZWNlaXZpbmcgYSBiYW5kd2lk dGggY2FwYWNpdHkgb2YgNTZrYml0L3MgaXMgaGlnaGx5IHN1c3BpY2lvdXMgaW4gYW4gSW50ZXJu ZXQgYmFja2JvbmUpLiBCdXQgdGhpcyByZXF1aXJlcyBhZGRpdGlvbmFsIGNvbmZpZ3VyYXRpb24g dG8gbWFpbnRhaW4uDQpNb3JlIG1heSBhbHNvIHJlY29yZCB0aGUgY29tbXVuaXRpZXMgcmVjZWl2 ZWQgb3ZlciB0aW1lLCBtb25pdG9yIHRoZSBjb25nZXN0aW9uIGUuZy4gdmlhIHByb2JpbmcsIGRl dGVjdCBpbmNvbnNpc3RlbmN5IGFuZCBjaG9vc2UgdG8gbm90IHRydXN0IGFueW1vcmUgdGhlIEFT ZXMgd2hpY2ggYWR2ZXJ0aXNlIGZha2UgbmV3c+KApg0KLS1CcnVubw0KVGhhbmtzLA0KUmVnYXJk cywNCi0tQnJ1bm8NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRl cyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHBy aXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0 ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNz YWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQphIGwnZXhwZWRpdGV1ciBldCBs ZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxl Y3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KT3JhbmdlIGRlY2xp bmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9y bWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50 cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0 IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVk LCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQpJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRl bGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCkFzIGVtYWlscyBtYXkgYmUg YWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVu IG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NClRoYW5rIHlvdS4NCg0KCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K CkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGlu Zm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQg ZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNh dGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBs ZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBp ZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJs ZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBj ZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlz IG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3Ig cHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5 IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9y aXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNl IG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNo bWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9y IG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4K VGhhbmsgeW91LgoK --_000_53C29892C857584299CBF5D05346208A47814C43OPEXCLILM21corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiTWljcm9zb2Z0IFlhSGVp IjsNCglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OiJcQE1pY3Jvc29mdCBZYUhlaSI7DQoJcGFub3NlLTE6MiAxMSA1IDMgMiAyIDQgMiAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hOw0KCXBhbm9zZS0xOjIgMTEg NiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0w6kg SFRNTCBDYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUs IGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiVGV4dGUgZGUgYnVsbGVzIENhciI7DQoJbWFyZ2luOjBjbTsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLlRleHRlZGVidWxsZXNDYXINCgl7bXNvLXN0eWxl LW5hbWU6IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiVGV4dGUgZGUgYnVsbGVzIjsNCglmb250LWZhbWlseToiVGFob21hIiwi c2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj MUY0OTdEO30NCnNwYW4uUHJmb3JtYXRIVE1MQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJQcsOpZm9y bWF0w6kgSFRNTCBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiUHLDqWZvcm1hdMOpIEhUTUwiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw LjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFy Z2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJGUiIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkhlbGxvIFpoZW5xaWFuZyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MgZm9yIHlvdXIg cmVwbHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5QbGVhc2Ug c2VlIGlubGluZSBbQnJ1bm9dPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItcmlnaHQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0 Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4gbGkgemhlbnFpYW5nIFttYWlsdG86bGlfemhlbnFpYW5nQGhv dG1haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgSnVseSAxNywgMjAxNyA1OjUx IFBNPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O01pY3Jvc29mdCBZYUhlaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj5IZWxsbyBCcnVubyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPlRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHlvdXIgY29uc3RydWN0aXZlIGNv bW1lbnRzLiBQbGVhc2Ugc2VlIG15IHJlcGx5IGlubGluZSwgYmVnaW5zIHdpdGggUmVwbHkuIFNv cnJ5IGZvciB0aGUgbGF0ZSByZXNwb25zZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPkJlc3QgUmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPg0KPGhyIHNpemU9IjEiIHdpZHRoPSIyMTAiIHN0eWxl PSJ3aWR0aDoxNTcuNXB0IiBub3NoYWRlPSIiIHN0eWxlPSJjb2xvcjojQjVDNERGIiBhbGlnbj0i bGVmdCI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6Ny41 cHQ7bWFyZ2luLXRvcDo3LjVwdDttYXJnaW4tcmlnaHQ6Ny41cHQ7bWFyZ2luLWJvdHRvbTo3LjVw dCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj48YSBocmVmPSJtYWlsdG86bGlfemhlbnFpYW5nQGhvdG1haWwuY29t Ij5saV96aGVucWlhbmdAaG90bWFpbC5jb208L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi1sZWZ0OjYuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOiNFRkVGRUYiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8YSBocmVmPSJtYWlsdG86YnJ1bm8uZGVjcmFlbmVA b3JhbmdlLmNvbSI+YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDojRUZFRkVGIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5E YXRlOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5i c3A7MjAxNy0wNy0xMSZuYnNwOzIxOjIwPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6I0VGRUZFRiI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VG86PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8YSBocmVmPSJtYWlsdG86 ZHJhZnQtbGktaWRyLWNvbmdlc3Rpb24tc3RhdHVzLWV4dGVuZGVkLWNvbW11bml0eUBpZXRmLm9y ZyI+ZHJhZnQtbGktaWRyLWNvbmdlc3Rpb24tc3RhdHVzLWV4dGVuZGVkLWNvbW11bml0eUBpZXRm Lm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDojRUZFRkVGIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5DQzo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzxhIGhyZWY9Im1haWx0bzppZHJAaWV0Zi5vcmciPmlk ckBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDojRUZFRkVGIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5TdWJqZWN0Ojwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7ZHJhZnQtbGktaWRyLWNvbmdlc3Rp b24tc3RhdHVzLWV4dGVuZGVkLWNvbW11bml0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlh SGVpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkhpIGF1dGhvcnMs PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9z b2Z0IFlhSGVpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jv c29mdCBZYUhlaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5QbGVh c2UgZmluZCBiZWxvdyBzb21lIG1pbm9yIGNvbW1lbnRzLg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj7CpzImbmJzcDsgQ29uZ2VzdGlvbiBTdGF0 dXMgRXh0ZW5kZWQgQ29tbXVuaXR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj4mZ3Q7IFRoZSAmcXVvdDtVdGlsaXphdGlvbiZxdW90OyBmaWVsZCBp cyAxIG9jdGV0LiZuYnNwOyBJdHMgdmFsdWUgaXMgdGhlIHV0aWxpemF0aW9uIG9mIHRoZSBleGl0 IGxpbmsgaW4gdW5pdCBvZiBwZXJjZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj4tIElzIHRoaXMgdGhlIHV0aWxpemF0aW9uIG9uIHRoZSBsaW5r IG9yIGJlZm9yZSB0aGUgbGluayAoaS5lLiBiZWZvcmUgZHJvcHBpbmcgdGhlIHRyYWZmaWMgaW4g ZXhjZXNzKSA/IElPVywgY2FuIHRoaXMgYmUgZ3JlYXRlciB0aGFuIDEwMCU/IEkgdGhpbmsgSSdk DQogcHJlZmVyIHRoZSBsYXR0ZXIsIGJ1dCBpbiBhbGwgY2FzZXMsIEkgbGlrZSB0byBzZWUgYSB0 ZXh0IGRldGFpbGluZyB0aGUgaGFuZGxpbmcgb2YgbnVtYmVycyAmZ3Q7IDEwMCUuDQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFI ZWkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjaztiYWNrZ3JvdW5kOndo aXRlIj5SZXBseTogSWYgaXQgaXMgZWFzeSB0byBnZXQgdGhlIHV0aWxpemF0aW9uIGJlZm9yZSB0 aGUgbGluaywgd2UgY2FuIHVzZSBpdC4gQnV0IEkgYW0gbm90IHN1cmUgYWJvdXQgaXQuIElmIHlv dSBjYW4sIHBsZWFzZSBjb250cmlidXRlDQogc29tZSB0ZXh0IHRoYXQgSSB3aWxsIGluY29ycG9y YXRlIGluIHRoZSBuZXh0IHZlcnNpb24uJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5bQnJ1bm9dIFRoYW5rcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgY291bGQgcHJvcG9zZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+T0xEOiAmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkl0cyB2YWx1ZQ0KIGlzIHRoZSB1dGlsaXphdGlvbiBvZiB0aGUgZXhpdCBs aW5rIGluIHVuaXQgb2YgcGVyY2VudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPk5FVzogJm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5JdHMgdmFsdWUNCiBpcyB0aGUgdXRpbGl6YXRpb24gb2YgdGhlIGV4aXQgbGluayBpbiB1bml0 IG9mIHBlcmNlbnQuIEl0IG1heSBiZSBoaWdoZXIgdGhhbiAxMDAlIGlmIHRoZSBpbmNvbWluZyB0 cmFmZmljIGlzIGhpZ2hlciB0aGFuIHRoZSBsaW5rIGNhcGFjaXR5LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+LSBJbiBvcmRlciB0byBv ZmZlciBtb3JlIGdyYW51bGFyaXR5LCBzb21ldGltZXMgdGhlIHRyYWZmaWMgaXMgcmF0ZSBsaW1p dGVkIHRvIGEgY2FwYWNpdHkgc21hbGxlciB0aGFuIHRoZSBwaHlzaWNhbCBsaW5rLiBlLmcuIHRo ZSBwaHlzaWNhbCBsaW5rIGhhcyAxMEcNCiBvZiB0cmFmZmljLCBidXQgb25seSAzRyBpcyBhdmFp bGFibGUgdG8gdGhlIHVzZXIuIFBsZWFzZSBleHBsaWNpdCB3aGV0aGVyIHlvdSBhcmUgcmVmZXJy aW5nIHRvIHBoeXNpY2FsIG9yICZxdW90O3JlYWwmcXVvdDsvJnF1b3Q7b2ZmZXJlZCZxdW90Oy8m cXVvdDthdmFpbGFibGUmcXVvdDsgY2FwYWNpdHkuIE9uIG15IHNpZGUsIEknZCBwcmVmZXIgdGhl IGxhdHRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj aztiYWNrZ3JvdW5kOndoaXRlIj5SZXBseTogSSZuYnNwO2FncmVlJm5ic3A7dGhhdCZuYnNwO3Ro ZSZuYnNwO2JhbmR3aWR0aCZuYnNwO3Nob3VsZCZuYnNwO2JlJm5ic3A7dGhlJm5ic3A7Y29uZmln dXJlZCZuYnNwOyZuYnNwO2F2YWlsYWJsZSZuYnNwO2NhcGFjaXR5Jm5ic3A7b2YmbmJzcDt0aGUm bmJzcDtsaW5rLiBJIHdpbGwgZXhwbGljaXQgaXQgaW4gdGhlIG5leHQgdmVyc2lvbi48L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0 IFlhSGVpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhl aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5b QnJ1bm9dIGdyZWF0IHRoYW5rcy48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj4mZ3Q7IFRoZSAmcXVvdDtCYW5kd2lkdGgmcXVvdDsgZmllbGQgaXMgMSBv Y3RldC4mbmJzcDsgSXRzIHZhbHVlIGlzIHRoZSBiYW5kd2lkdGggb2YgdGhlIGV4aXQgbGluayBp biB1bml0IG9mIDEwIGdicHMgKGdpZ2FiaXRzIHBlciBzZWNvbmQpLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SSBkb24ndCBzZWUgdGhhdCB0aGlz IGlzIGV4dHJlbWVseSBmdXR1cmUgcHJvb2YsIGFzIHRoZSB1c2FibGUgcmFuZ2UgaXMgMS0yNTUu IFdoZW4gdGhpcyBwcm9wb3NpdGlvbiBnZXRzIHVzZWQgKGluIHllYXJzIGZyb20gbm93KSwgMTAw RyBsaW5rcyB3b3VsZCBwcmVzdW1hYmx5DQogYmUgdGhlIGRlZmF1bHQuIE1lYW5pbmcgd2Ugd291 bGQgYWxyZWFkeSBoYXZlIGNvbnN1bWVkICoxMCBmcm9tIHRoZSBidWRnZXQuIE9ubHkgbGVhdmlu ZyAqMjUgZm9yIHRoZSBmdXR1cmUuIEknZCBwcmVmZXIgYSB3aWRlciByYW5nZSB3aXRoIGxlc3Mg cHJlY2lzaW9uLiBlLmcuIGJhbmR3aWR0aCBpcyAxMF5eYmFuZHdpZHRoIGluIGdicHMuIChvciAy Xl4pLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01p Y3Jvc29mdCBZYUhlaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrO2Jh Y2tncm91bmQ6d2hpdGUiPlJlcGx5OiZuYnNwO0luZGVlZCZuYnNwO3RoaXMmbmJzcDtpcyBvbmUg b2YgdGhlIGtleSBwb2ludHMgd2UmbmJzcDtzaG91bGQmbmJzcDtjb25zaWRlciZuYnNwO2R1cmlu ZyZuYnNwO3RoZSZuYnNwO2Rlc2lnbiZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVjaGFuaXNtLiBJ biB1bml0IG9mIDEwIGdicHMsIG9uZSBvY3RldCBjYW4NCiBleHByZXNzIHRoZSBiYW5kd2lkdGgg ZnJvbSAxMGdicHMgdG8gMjU1MGdicHMuIEkgdGhpbmsgaXQgc2hvdWxkIGJlIG9rIGZvciB0aGUg ZnV0dXJlLiBZb3VyIHN1Z2dlc3Rpb24gaXMgZGlmZmljdWx0IHRvIGV4cHJlc3MgNDBnYnBzLCAx MDBnYnBzIGFuZCA0MDBnYnBzIGV0Yy4gQW55d2F5IHdlJm5ic3A7d2lsbCZuYnNwO3RoaW5rJm5i c3A7YWJvdXQmbmJzcDt5b3VyJm5ic3A7c3VnZ2VzdGlvbiBhbmQgdHJ5IHRvIGZpbmQgYSBiZXR0 ZXIgc29sdXRpb24uIFlvdXIgZnVydGhlciBzdWdnZXN0aW9uDQogaXMgd2VsY29tZS48L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0 IFlhSGVpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDtiYWNrZ3Jv dW5kOndoaXRlIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLXJpZ2h0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bQnJ1bm9dIEkgYWdyZWUgdGhhdCBteSBzdWdnZXN0 aW9uIGNhbuKAmXQgZXhwcmVzcyBwcmVjaXNlIHZhbHVlcy4gJm5ic3A7R2l2ZW4gdGhhdCB0eXBp Y2FsbHkgd2UgaGF2ZSBtdWx0aXBsZS9tYW55IGluZ3Jlc3MNCiBzZW5kaW5nIHRyYWZmaWMgdG8g b25lIHNpbmdsZSBpbnRlcmZhY2UsIEkgZG9u4oCZdCBmZWVsIHRoYXQgaGF2aW5nIGEgcHJlY2lz ZSBiYW5kd2lkdGggdmFsdWUgaXMgYW4gYWJzb2x1dGUgcmVxdWlyZW1lbnQgYXMgb25lIHNlbmRl ciBjYW7igJl0IHVzZSBhbGwgdGhhdCBiYW5kd2lkdGguIEl0IG5lZWQgdG8gc2hhcmUgaXMgd2l0 aCBvdGhlciBpbmdyZXNzIGFuZCBoYXMgbm8gd2F5IG9mIGtub3dpbmcgaG93IG11Y2ggb3RoZXIg aW5ncmVzcyB3aWxsDQogYWRhcHQgYW5kIHNlbmQgbW9yZSBvciBsZXNzIHRyYWZmaWMuIEJ1dCBp dOKAmXMgcmVhbGx5IHVwIHRvIHlvdS48c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PG86 cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNy b3NvZnQgWWFIZWkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjaztiYWNr Z3JvdW5kOndoaXRlIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mZ3Q7IFRoZSBsaW5rIHdp dGggYmFuZHdpZHRoIGxlc3MgdGhhbiAxMCBnYnBzIGlzIG5vdCBzdWl0YWJsZSB0byB1c2UgdGhp cyBmZWF0dXJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O01pY3Jvc29mdCBZYUhlaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+V2h5IG5vdD8gSXQgbG9va3MgdG8gbWUgdGhhdCB0aGUgJVV0aWxpemF0aW9uIGNvdWxk IGJlIHVzZWZ1bCBldmVuIGlmIHRoZSBiYW5kd2lkdGggaXMgbm90IGFkdmVydGlzZWQuIFBvc3Np Ymx5IGEgJnF1b3Q7QmFuZHdpZHRoJnF1b3Q7IHJlc2VydmVkIHZhbHVlIChlLmcuIDApDQogY291 bGQgYmUgc3BlY2lmaWVkIHRvIGluZGljYXRlIHRoYXQgdGhlIGJhbmR3aWR0aCBpcyBub3QgYWR2 ZXJ0aXNlZC4gVGhpcyB3b3VsZCBhbHNvIGZpdCB0aGUgY2FzZSB3aGVyZSBzb21lIEFTZXMgZG8g bm90IHdhbnQgdG8gYWR2ZXJ0aXNlIHRoZWlyIGxpbmsgY2FwYWNpdHkuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2s7YmFja2dyb3VuZDp3aGl0ZSI+UmVw bHk6Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj5BZ3JlZS4mbmJzcDtXZSZuYnNwO3dpbGwmbmJzcDtyZXZpc2UmbmJzcDt0aGUmbmJz cDtkcmFmdCZuYnNwO3RvJm5ic3A7cmVmbGVjdCZuYnNwO3RoaXMuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltCcnVub10gb2ss IHRoYW5rczwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PsKnMy4mbmJzcDsgQXBwbGljYXRpb24gQ29uc2lkZXJhdGlvbnM8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZndDsgVGhlIFNETiBjb250cm9sbGVy IHVzZXMgdGhlIGV4aXQgbGluayB1dGlsaXphdGlvbiBpbmZvcm1hdGlvbiB0byBzdGVlciB0aGUg SW50ZXJuZXQgYWNjZXNzIHRyYWZmaWMgYW1vbmcgYWxsIHRoZSBleGl0IGxpbmtzIGZyb20gdGhl IHBlcnNwZWN0aXZlIG9mDQogdGhlIHdob2xlIG5ldHdvcmsuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5JbmRlZWQsIHByZXN1bWFibHkgdGhpcyBp bmZvcm1hdGlvbiBpcyB1c2VkIHRvIGluZmx1ZW5jZSB0aGUgcm91dGluZyBiZWhhdmlvci4gTWF5 IGJlIHRoZSBkb2N1bWVudCBzaG91bGQgaW5kaWNhdGUgdGhhdCB0aGUgcmVjZXB0aW9uIG9mIHN1 Y2ggY29tbXVuaXR5DQogb3ZlciBJQkdQIHNlc3Npb24gc2hvdWxkIG5vdCBpbmZsdWVuY2Ugcm91 dGluZyBkZWNpc2lvbiB1bmxlc3MgdHVubmVsaW5nIGlzIHVzZWQgdG8gcmVhY2ggdGhlIEJHUCBO ZXh0LUhvcC4gKHRvIGF2b2lkIGZvcndhcmRpbmcgbG9vcHMsIGluY3JlbWVudGFsIGRlcGxveW1l bnQgaXNzdWVzLCBjb21wbGljYXRpb25zIGluIGVycm9yIGhhbmRsaW5nKS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjaztiYWNrZ3JvdW5kOndoaXRlIj5S ZXBseTombmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPlRoYW5rcyZuYnNwO2ZvciZuYnNwO3BvaW50aW5nJm5ic3A7b3V0Jm5ic3A7dGhp cy4mbmJzcDtXZSZuYnNwO3dpbGwmbmJzcDthZGQmbmJzcDtzb21lJm5ic3A7ZGVzY3JpcHRpb24m bmJzcDtpbiZuYnNwO25leHQmbmJzcDtyZXZpc2lvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W0JydW5vXSBvaywgdGhhbmtz Ljwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtN aWNyb3NvZnQgWWFIZWkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9z b2Z0IFlhSGVpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkluIGFk ZGl0aW9uLCB3aGF0IGFyZSB0aGUgaW50ZXJhY3Rpb25zIHdpdGggdGhlIEJHUCBMaW5rIEJhbmR3 aWR0aCBFeHRlbmRlZCBjb21tdW5pdGllcz8NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLWlkci1saW5rLWJhbmR3aWR0aCI+aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtaWRyLWxpbmstYmFuZHdpZHRoPC9hPiZuYnNwOyAoSSBrbm93 IHRoYXQgdGhlIGRyYWZ0IGV4cGlyZWQsIGJ1dCBzdGlsbCBpdCdzIGEgV0cgZG9jdW1lbnQgYW5k IGFuIG9mZmljaWFsIElBTkEgY29kZSBwb2ludCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+U2hpcHMgaW4gdGhlIG5pZ2h0Pw0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlJlcGx5OiZuYnNwO1NvJm5i c3A7ZmFyJm5ic3A7dGhpcyZuYnNwO2RyYWZ0Jm5ic3A7ZGlkbuKAmXQmbmJzcDtjb25zaWRlciZu YnNwO3RoZSZuYnNwO2ludGVyYWN0aW9uJm5ic3A7d2l0aCZuYnNwO3RoZSZuYnNwO2xpbmsmbmJz cDtiYW5kd2lkdGgmbmJzcDtFeHQuJm5ic3A7Y29tbXVuaXR5LiZuYnNwO0FzJm5ic3A7dGhlJm5i c3A7bGluayZuYnNwO2JhbmR3aWR0aCZuYnNwO0V4dC4mbmJzcDtjb21tdW5pdHkmbmJzcDtpcyZu YnNwO25vbi1yYW5zaXRpdmUsJm5ic3A7YW5kJm5ic3A7dGhlJm5ic3A7Z2xvYmFsJm5ic3A7YWRt aW5pc3RyYXRvciZuYnNwO3N1YmZpZWxkJm5ic3A7aXMmbmJzcDtvbmx5Jm5ic3A7Mi1vY3RldHMs Jm5ic3A7aXQmbmJzcDttYXkmbmJzcDtub3QmbmJzcDtiZSZuYnNwO2FwcGxpY2FibGUmbmJzcDt0 byZuYnNwO2FsbCZuYnNwO3RoZSZuYnNwO3NjZW5hcmlvcyZuYnNwO2Rlc2NyaWJlZCZuYnNwO2lu Jm5ic3A7dGhpcyZuYnNwO2RvY3VtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W0JydW5vXSBJIHdhcyBub3Qgc3VnZ2VzdGluZyB0 byByZXBsYWNlIGNvbmdlc3Rpb24tc3RhdHVzIHdpdGggbGluay1iYW5kd2lkdGguIEkgd2FzIGFz a2luZyBmb3IgdGhlIGV4cGVjdGVkIGJlaGF2aW9yIGlmIGxpbmstYmFuZHdpZHRoIGFkdmVydGlz ZQ0KIGEgY2FwYWNpdHkgb2YgNDBHIHdoaWxlIGNvbmdlc3Rpb24tc3RhdHVzIGFkdmVydGlzZSBh IGNhcGFjaXR5IG9mIDEwMEcuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyBUbyBhdm9p ZCByb3V0ZSBvc2NpbGxhdGlvbiwgdGhlIGV4aXQgcm91dGVyIFNIT1VMRCBzZXQgYSB0aHJlc2hv bGQuJm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPldoZW4gdGhlIHV0aWxpemF0aW9uIGNoYW5nZSByZWFjaGVzIHRoZSB0 aHJlc2hvbGQsIHRoZSBleGl0IHJvdXRlciZuYnNwOyBTSE9VTEQgZ2VuZXJhdGUgYSBCR1AgdXBk YXRlIG1lc3NhZ2Ugd2l0aCBjb25nZXN0aW9uIHN0YXR1cyBleHRlbmRlZCZuYnNwOyBjb21tdW5p dHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWlj cm9zb2Z0IFlhSGVpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01p Y3Jvc29mdCBZYUhlaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5J IHRoaW5rIHRoYXQgdGhlIGRvY3VtZW50IHNob3VsZCBiZXR0ZXIgZXZhbHVhdGUgdGhlIGNodXJu IGludHJvZHVjZWQuIEluIHBhcnRpY3VsYXIgdGhlIGNodXJuIGlzIGN1bXVsYXRpdmUgYXMgdGhl IG51bWJlciBvZiBBU2VzIGNyb3NzZWQgaW5jcmVhc2UuIGUuZy4NCiBpZiB3ZSBhc3N1bWUgdGhh dCBlYWNoIEFTIHVzZSB0aGUgY29tbXVuaXR5IHF1aXRlIGNhcmVmdWxseSBieSBub3QgYWR2ZXJ0 aXNpbmcgbW9yZSB0aGFuIDEgdXBkYXRlIHBlciBob3VyLCBpZiB3ZSBoYXZlIDUgQVNlcyBvbiB0 aGUgd2F5LCB0aGUgaW5ncmVzcyBBUyBjYW4gcmVjZWl2ZSA1IChhZGRpdGlvbmFsKSB1cGRhdGVz IHBlciBwcmVmaXggcGVyIGhvdXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPlJlcGx5OiBXZSB3aWxsJm5ic3A7dGhpbmsmbmJzcDthYm91dCZuYnNw O2l0Jm5ic3A7ZnVydGhlci4gU29tZXRoaW5nIGxpa2UgVFRMICh0aW1lIHRvIGxpdmUpIHRvIGJl IGludHJvZHVjZWQ/IFRvIGhhdmUgbGFyZ2VyIHNwYWNlIHRvIGZpdCB0aGlzLCB1c2UgQkdQIGNv bW11bml0eSBjb250YWluZXINCiBpbnN0ZWFkPyBPciBkbyAmbmJzcDt5b3UgJm5ic3A7aGF2ZSAm bmJzcDtzb21lICZuYnNwO3N1Z2dlc3Rpb25zPzxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij4mbmJzcDsmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bQnJ1bm9dIEFzIG9mIHRv ZGF5LCBJIHdhcyBvbmx5IGNhbGxpbmcNCiBmb3IgbW9yZSB0ZXh0IGhpZ2hsaWdodGluZyB0aGF0 IHRoZSBjaHVybiBpbmNyZWFzZSBsaW5lYXJseSB3aXRoIHRoZSBudW1iZXIgb2YgQVNlcyBhdHRh Y2hpbmcgdGhpcyBjb21tdW5pdHkgb24gYSBnaXZlbiBwcmVmaXguPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T25lIHN1Z2dlc3Rpb24gdG8gaW1wcm92ZSB0 aGUgYmVoYXZpb3I6IOKAnFdoZW4gb25lIEJHUCByb3V0ZXIgbmVlZHMgdG8gcmUtYWR2ZXJ0aXNl IGEgQkdQIHBhdGggZHVlIHRvIGF0dHJpYnV0ZSBjaGFuZ2VzLCBpdCBTSE9VTEQgdXBkYXRlIGl0 cyBjb25nZXN0aW9uLXN0YXR1cy1jb21tdW5pdHkNCiBhdCB0aGUgc2FtZSB0aW1lLiBUaGlzIGFs bG93cyByZWR1Y2luZyB0aGUgY2h1cm4gYXMgb25lIHRoZSBmaW5hbCBpbmdyZXNzIHdpbGwgcmVj ZWl2ZSBhIHNpbmdsZSBVUERBVEUgcmVmcmVzaGluZyB0aGUgTiBjb21tdW5pdGllcywgcmF0aGVy IHRoYW4gTiBVUERBVEVzLCBlYWNoIHJlZnJlc2hpbmcgb25lIGNvbW11bml0eeKAnS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFI ZWkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+NC4mbmJzcDsgU2Vj dXJpdHkgQ29uc2lkZXJhdGlvbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+Jmd0OyBUaGlzIG5ldyBleHRlbmRlZCBjb21tdW5pdHkgZG9lcyBub3Qg ZGlyZWN0bHkgaW50cm9kdWNlIGFueSBuZXcgc2VjdXJpdHkgaXNzdWVzLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+V2hhdCBhYm91dCB0cnVzdC9j aGVhdGluZyBjb25zaWRlcmF0aW9ucz8gRXNwZWNpYWxseSBmcm9tIHJlbW90ZSBBU2VzIHdpdGgg d2hpY2ggeW91IGhhdmUgemVybyByZWxhdGlvbnNoaXA/PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPmUuZy4gYWR2ZXJ0aXNpbmcgYWxsZWdlZCBjb25n ZXN0aW9uIGluIG9yZGVyIHRvIFRFL2luZmx1ZW5jZSByb3V0aW5nIG9mIG90aGVycyBBU2VzLCBh ZHZlcnRpc2luZyBwbGVudHkgb2YgZmFrZSBjYXBhY2l0eSB0byBhdHRyYWN0IG1vcmUgdHJhZmZp Yy9jdXN0b21lcnMsDQogYWR2ZXJ0aXNpbmcgdGhhdCB0aGV5IGFyZSBuZXZlciBleHBlcmllbmNp bmcgYW55IGNvbmdlc3Rpb24gZm9yIGNvbW1lcmNpYWwgcmVhc29ucywgZmFrZSBhZHZlcnRpc2Vt ZW50IG9uICZxdW90O2JlaGFsZiZxdW90OyBvZiBvdGhlciBBU2VzLi4uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlJlcGx5OiZuYnNwO1RoZSZuYnNw O3RydXN0L2NoZWF0aW5nJm5ic3A7cHJvYmxlbSB5b3UmbmJzcDttZW50aW9uZWQmbmJzcDtpcyBh Jm5ic3A7Z2VuZXJhbCZuYnNwO2lzc3VlJm5ic3A7Zm9yJm5ic3A7QkdQLiBDYW4gd2UgbWFrZSBz dXJlIHRoYXQgdGhlIHJvdXRlcyBhZHZlcnRpc2VkIGJ5IGEgQkdQIHBlZXIgc2hvdWxkIGJlIGFk dmVydGlzZWQNCiBieSBpdD8gVGhlIEJHUCBwZWVyIGNhbiBnZW5lcmF0ZSBzb21lIHJvdXRlcyBt YWxpY2lvdXNseS4gQW55d2F5LCZuYnNwOyB3ZSZuYnNwO3dpbGwmbmJzcDthZGQmbmJzcDtzb21l Jm5ic3A7YW5hbHlzaXMmbmJzcDt0byZuYnNwO3RoaXMmbmJzcDtwcm9ibGVtJm5ic3A7aW4mbmJz cDtuZXh0Jm5ic3A7cmV2aXNpb24uJm5ic3A7Rm9yJm5ic3A7ZXhhbXBsZSwgJm5ic3A7dGhlJm5i c3A7QkdQIHJlY2VpdmVyIG1heSZuYnNwO2Nob29zZSZuYnNwO3RvJm5ic3A7b25seSZuYnNwO3Ry dXN0Jm5ic3A7dGhlJm5ic3A7Y29uZ2VzdGlvbiAmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2FkdmVy dGlzZWQmbmJzcDtieSZuYnNwO3NvbWUmbmJzcDtwYXJ0aWN1bGFyJm5ic3A7QVNlcywgb3ImbmJz cDtBU2VzJm5ic3A7d2l0aGluJm5ic3A7cGFydGljdWxhciZuYnNwO2hvcHMuDQogQW55IHN1Z2dl c3Rpb24gZnJvbSB5b3U/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bQnJ1bm9dIEkgYWdyZWUg dGhhdCB0aGlzIGlzIGEgZ2VuZXJhbA0KIHRydXN0IGlzc3VlIGluIEJHUCwgYnV0IHRoaXMgZG9j dW1lbnQgcHJvcG9zZXMgdG8gYWR2ZXJ0aXNlIG1vcmUgaW5mb3JtYXRpb24gaGVuY2UgaW50cm9k dWNlIG5ldyBjb25zaWRlcmF0aW9uLiBQbHVzIGluIHRoZSBlbmQsIGlmIHlvdSBkb27igJl0IHRy dXN0IHRoZSBkYXRhLCB0aGVyZSBpcyBubyBuZWVkIHRvIHNlbmQgdGhlbSBpbiB0aGUgZmlyc3Qg cGxhY2UuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T25l IHBvc3NpYmxlIGRlcGxveW1lbnQgbW9kZWwgaXMgdG8gZmlsdGVyIGNvbmdlc3Rpb24tc3RhdHVz IGNvbW11bml0aWVzIGF0IHRoZSBib3JkZXIgb2YgeW91IHRydXN0L2FkbWluaXN0cmF0aXZlIGRv bWFpbi4gSGVuY2UgYWxsIHRoZSBvbmUgeW91DQogcmVjZWl2ZSBhcmUgdHJ1c3RlZC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk90aGVyIG9wdGlvbnMgbWF5IGJl IHRvIHRyeSB0byBzYW5pdGl6ZSB0aGUgcmVjZWl2ZWQgdmFsdWUgYmFzZWQgb24gYS1wcmlvcmkg a25vd2xlZGdlL2V4cGVjdGF0aW9ucy4gKGUuZy4gcmVjZWl2aW5nIGEgYmFuZHdpZHRoIGNhcGFj aXR5IG9mIDU2a2JpdC9zDQogaXMgaGlnaGx5IHN1c3BpY2lvdXMgaW4gYW4gSW50ZXJuZXQgYmFj a2JvbmUpLiBCdXQgdGhpcyByZXF1aXJlcyBhZGRpdGlvbmFsIGNvbmZpZ3VyYXRpb24gdG8gbWFp bnRhaW4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Nb3JlIG1h eSBhbHNvIHJlY29yZCB0aGUgY29tbXVuaXRpZXMgcmVjZWl2ZWQgb3ZlciB0aW1lLCBtb25pdG9y IHRoZSBjb25nZXN0aW9uIGUuZy4gdmlhIHByb2JpbmcsIGRldGVjdCBpbmNvbnNpc3RlbmN5IGFu ZCBjaG9vc2UgdG8gbm90IHRydXN0DQogYW55bW9yZSB0aGUgQVNlcyB3aGljaCBhZHZlcnRpc2Ug ZmFrZSBuZXdz4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4t LUJydW5vPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFI ZWkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+LS1CcnVubzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNy b3NvZnQgWWFIZWkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+X19f X19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZl bnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdp ZWVzIGV0IG5lIGRvaXZlbnQgZG9uYzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj5wYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBz YW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVy LCB2ZXVpbGxleiBsZSBzaWduYWxlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj5hIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUg bGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNj ZXB0aWJsZXMgZCdhbHRlcmF0aW9uLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj5PcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBj ZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlh SGVpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZ YUhlaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGlzIG1lc3Nh Z2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmls ZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj50aGV5IHNob3VsZCBub3Qg YmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQg WWFIZWkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkFzIGVtYWlscyBtYXkgYmUg YWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVu IG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VGhhbmsgeW91LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxQUkU+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5p ciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUg ZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMg YXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZl dWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1 ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1 c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmls aXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJj aS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVu dGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBs YXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91 dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9y LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0 cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxp YWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFs c2lmaWVkLgpUaGFuayB5b3UuCjwvUFJFPjwvYm9keT4NCjwvaHRtbD4NCg== --_000_53C29892C857584299CBF5D05346208A47814C43OPEXCLILM21corp_-- From nobody Wed Jul 19 17:42:49 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7AD12EC39 for ; Wed, 19 Jul 2017 17:42:48 -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 y6dydNI6EmvT for ; Wed, 19 Jul 2017 17:42:46 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19F7D126D73 for ; Wed, 19 Jul 2017 17:42:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8290; q=dns/txt; s=iport; t=1500511366; x=1501720966; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=DIDr+BBYoRvNmF91ZL+XCSvoFL/gNXUVN/zfYfRtxmE=; b=CFx6nSlL+YaF6v4dXF1ixIH71Whz3RnlMTP1e/atDrKPYZsMmSZp54Il UTscxNljKNcWoXiRVSTTg18euxI71Uy3YLhk4fIgNViCTbvorCxoPPuCp ZTdZo0ratgdgPJlxJ+uwR0xE2YAR1lmKIz0Y3hLnBDPeLKHFoSg0AX6lt I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYAACx+29Z/4ENJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkgRQHjgSRZ5YEghEuhRkCGoNJPxgBAgEBAQEBAQFrKIUYAQE?= =?us-ascii?q?BAQIBIxFFDAQCAQgRAwECAQICJgICAjAVCAgCBA4FiicIELBTgiaLIQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBARgFgQuCHYNNgWErgnmEMBYOgykwgjEFhyOCM4hhjQI?= =?us-ascii?q?Ch0mHE4U7ggyFT4pVlVsBHziBCnUVWwGHA3aGYYEygQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.40,382,1496102400"; d="scan'208";a="261758604" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jul 2017 00:42:45 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v6K0gi86025102 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 20 Jul 2017 00:42:45 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 19 Jul 2017 19:42:44 -0500 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1210.000; Wed, 19 Jul 2017 19:42:44 -0500 From: "Rajiv Asati (rajiva)" To: "John G. Scudder" CC: Jeffrey Haas , Robert Raszuk , idr wg Thread-Topic: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt Thread-Index: AQHSmnRjZQMhW6yq5kum3Hd4lOeZoA== Date: Thu, 20 Jul 2017 00:42:44 +0000 Message-ID: References: <58C6751D.60306@foobar.org> <20170314204212.GD12864@pfrc.org> <815723FC-B143-4410-B0FF-D9FB4F827862@cisco.com> <20170314213607.GH12864@pfrc.org> <579D00D9-D80F-4625-BF16-0D5112C2FA98@cisco.com> <83CF8B1D-A9A2-4845-9FF4-3521B286B21D@juniper.net> In-Reply-To: <83CF8B1D-A9A2-4845-9FF4-3521B286B21D@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.22.0.170515 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.102.161] Content-Type: text/plain; charset="utf-8" Content-ID: <2ECA872A725C224B91AFAD57155861E4@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 00:42:48 -0000 SGkgSm9obiwNCg0KVGhlIHN1Z2dlc3RlZCB0ZXh0IHNlZW1zIHJlYXNvbmFibGUuIA0KDQpJIHdp bGwgZ2xhbmNlIHRocm91Z2ggdGhlIGRyYWZ0IHRvIHNlZSBpZiBhbnkgb3RoZXIgc2VjdGlvbiBu ZWVkcyB1cGRhdGluZyBpbiBsaWV1IG9mIHRoaXMgY2hhbmdlLg0KDQotLSANCkNoZWVycywNClJh aml2ICANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEpvaG4gU2N1ZGRlciA8 amdzQGp1bmlwZXIubmV0Pg0KRGF0ZTogVHVlc2RheSwgSnVseSAxOCwgMjAxNyBhdCA1OjI0IEFN DQpUbzogUmFqaXYgQXNhdGkgPHJhaml2YUBjaXNjby5jb20+DQpDYzogSmVmZnJleSBIYWFzIDxq aGFhc0BwZnJjLm9yZz4sICJyb2JlcnRAcmFzenVrLm5ldCIgPHJvYmVydEByYXN6dWsubmV0Piwg ImlkckBpZXRmLm9yZyIgPGlkckBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbSWRyXSBJLUQgQWN0 aW9uOiBkcmFmdC1pZXRmLWlkci1ycy1iZmQtMDIudHh0DQoNCiAgICBIaSBSYWppdiwNCiAgICAN CiAgICBJbiByZXZpZXdpbmcgZHJhZnQtaWV0Zi1pZHItYmdwLWJlc3RwYXRoLXNlbGVjdGlvbi1j cml0ZXJpYS0wNywgSSBub3RlIHNlY3Rpb24gMyBoYXM6DQogICAgDQogICAgICAgVGhlIG1lY2hh bmlzbShzKSB0byBwZXJmb3JtIHRoZSAicGF0aCBhdmFpbGFiaWxpdHkiIGNoZWNrIGFuZCB0aGUN CiAgICAgICBzZWxlY3Rpb24gb2YgcGFydGljdWxhciBkYXRhIHBsYW5lIGFyZSBhIG1hdHRlciBv ZiBhIHBvbGljeSBhbmQNCiAgICAgICBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50 Lg0KICAgIA0KICAgIFJTLUJGRCByZXByZXNlbnRzIGFuIGluc3RhbmNlIG9mIGEgc3BlY2lmaWMg cGF0aCBhdmFpbGFiaWxpdHkgY2hlY2sgYW5kIHNlbGVjdGlvbiBvZiBkYXRhIHBsYW5lLiBCYXNl ZCBvbiB0aGF0LCBpdCBzZWVtcyB0byBtZSB0aGUgUlMtQkZEIGNvdWxkIGFkZCBzb21ldGhpbmcg bGlrZSB0aGUgZm9sbG93aW5nIGluIHRoZSBpbnRyb2R1Y3Rpb246DQogICAgDQogICAgICAgW0kt RC5pZXRmLWlkci1iZ3AtYmVzdHBhdGgtc2VsZWN0aW9uLWNyaXRlcmlhXSBkaXNjdXNzZXMgZW5o YW5jZW1lbnQNCiAgICAgICBvZiB0aGUgcm91dGUgcmVzb2x2YWJpbGl0eSBjb25kaXRpb24gb2Yg c2VjdGlvbiA5LjEuMi4xIG9mIFtSRkM0MjcxXQ0KICAgICAgIHRvIGluY2x1ZGUgbmV4dCBob3Ag cmVhY2hhYmlsaXR5IGFuZCBwYXRoIGF2YWlsYWJpbGl0eSBjaGVja3MuICBUaGlzDQogICAgICAg c3BlY2lmaWNhdGlvbiByZXByZXNlbnRzIGluIHBhcnQgYW4gaW5zdGFuY2Ugb2Ygc3VjaCwgaW1w bGVtZW50ZWQNCiAgICAgICB1c2luZyBCRkQgYXMgdGhlIE9BTSBtZWNoYW5pc20uDQogICAgDQog ICAgSWYgeW91IGhhdmUgb3RoZXIgc3VnZ2VzdGlvbnMgZm9yIHRleHQsIHBsZWFzZSBzZW5kIHRo ZW0uDQogICAgDQogICAgVGhhbmtzLA0KICAgIA0KICAgIC0tSm9obg0KICAgIA0KICAgID4gT24g SnVsIDYsIDIwMTcsIGF0IDEyOjU0IEFNLCBSYWppdiBBc2F0aSAocmFqaXZhKSA8cmFqaXZhQGNp c2NvLmNvbT4gd3JvdGU6DQogICAgPiANCiAgICA+IEplZmYsIEpvaG4sDQogICAgPiAgDQogICAg PiBJIGRpZG7igJl0IHNlZSB0aGUgbGF0ZXN0IC0wMyBhZGRyZXNzaW5nIHRoZSBiZWxvdy4gQW55 IHBsYW5zPw0KICAgID4gIA0KICAgID4gLS0gDQogICAgPiBDaGVlcnMsDQogICAgPiBSYWppdiAg DQogICAgPiAgDQogICAgPiBGcm9tOiBSYWppdiBBc2F0aSA8cmFqaXZhQGNpc2NvLmNvbT4NCiAg ICA+IERhdGU6IFN1bmRheSwgQXByaWwgMTYsIDIwMTcgYXQgMzo0MiBQTQ0KICAgID4gVG86IEpl ZmZyZXkgSGFhcyA8amhhYXNAcGZyYy5vcmc+DQogICAgPiBDYzogInJvYmVydEByYXN6dWsubmV0 IiA8cm9iZXJ0QHJhc3p1ay5uZXQ+LCAiaWRyQGlldGYub3JnIiA8aWRyQGlldGYub3JnPg0KICAg ID4gU3ViamVjdDogUmU6IFtJZHJdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtaWRyLXJzLWJmZC0w Mi50eHQNCiAgICA+ICANCiAgICA+IEhpIEplZmYsDQogICAgPiAgDQogICAgPiAgDQogICAgPj4g ICAgQnV0IG1vcmUgaW1wb3J0YW50bHksIHlvdSdsbCBzdG9wIHNlbmRpbmcgaXQgdG93YXJkIHlv dXIgb3duIHBlZXJpbmcgYW5kDQogICAgPj4gICAgYXR0cmFjdGluZyBibGFja2hvbGVkIHRyYWZm aWMuDQogICAgPiBJbmRlZWQuIFRoYXTigJlzIGtleS4gDQogICAgPiAgDQogICAgPiBBbmQgaXQg Y291bGQgcmVseSBvbiB0aGUgcm91dGUgcmVzb2x2YWJpbGl0eSBjb25kaXRpb24gdG8gYmUgYXBw cm9wcmlhdGVseSBtb2RpZmllZCwgYXMgZGVzY3JpYmVkIGluICANCiAgICA+IGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlkci1iZ3AtYmVzdHBhdGgtc2VsZWN0aW9uLWNy aXRlcmlhLg0KICAgID4gIA0KICAgID4+ICAgICBSUy1CRkQgYmFzaWNhbGx5IHJlaW52ZW50cyB0 aGUgc2FtZSBwcm9jZWR1cmUgaW4geW91ciBkcmFmdCwgc2ltcGx5IGJlaW5nDQogICAgPj4gICAg IHNwZWNpZmljIGFib3V0IHRoZSB1c2Ugb2YgQkZEIGFzIHRoZSBkYXRhcGxhbmUgbGl2ZW5lc3Mg Y2hlY2sgbWVjaGFuaXNtLg0KICAgID4+ICAgICBIb3dldmVyLCBhcyB5b3Ugbm90ZSBpbiB0aGUg UlMtQkZEIGRyYWZ0LCB3ZSBkbyBsZWF2ZSB0aGUgb3B0aW9uIGZvciBvdGhlcg0KICAgID4+ICAg ICBtZWNoYW5pc21zLg0KICAgID4+ICANCiAgICA+PiAgICAgSSBzdXNwZWN0IHRoZSBvdGhlciBh dXRob3JzIG9mIFJTLUJGRCBhcmVuJ3QgcGFydGljdWxhciB3aGVyZSB3ZSBwaWNrIHVwIG91cg0K ICAgID4+ICAgICB0ZXh0IGZvciB0aGUgcmVzb2x2YWJpbGl0eSBjb25kaXRpb24uICBIb3dldmVy LCBpZiB0aGUgc3VnZ2VzdGlvbiBpcyB0byBtYWtlDQogICAgPj4gICAgYSByZWZlcmVuY2UgdG8g eW91ciBkcmFmdCwgeW91J2xsIG5lZWQgdG8gYnJpbmcgaXQgYmFjayBmcm9tIHpvbWJpZSBzdGF0 ZQ0KICAgID4+ICAgICBhbmQgcHJvZ3Jlc3MgaXQuIDotKQ0KICAgID4gIA0KICAgID4gQWdyZWVk LiBJdCBpcyBhbGl2ZSAoLTA3IHZlcnNpb24pLiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1pZHItYmdwLWJlc3RwYXRoLXNlbGVjdGlvbi1jcml0ZXJpYS0wNw0KICAgID4g SXQgY2FuIGJlIHVzZWQgYXMgYSBub3JtYXRpdmUgcmVmZXJlbmNlIGluIHlvdXIgZHJhZnQuIA0K ICAgID4gIA0KICAgID4gLS0gDQogICAgPiBDaGVlcnMsDQogICAgPiBSYWppdiBBc2F0aQ0KICAg ID4gRGlzdGluZ3Vpc2hlZCBFbmdpbmVlciwgQ2lzY28NCiAgICA+ICANCiAgICA+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQogICAgPiBGcm9tOiBKZWZmcmV5IEhhYXMgPGpoYWFzQHBmcmMu b3JnPg0KICAgID4gRGF0ZTogVHVlc2RheSwgTWFyY2ggMTQsIDIwMTcgYXQgNTozNiBQTQ0KICAg ID4gVG86IFJhaml2IEFzYXRpIDxyYWppdmFAY2lzY28uY29tPg0KICAgID4gQ2M6ICJyb2JlcnRA cmFzenVrLm5ldCIgPHJvYmVydEByYXN6dWsubmV0PiwgImlkckBpZXRmLm9yZyIgPGlkckBpZXRm Lm9yZz4NCiAgICA+IFN1YmplY3Q6IFJlOiBbSWRyXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWlk ci1ycy1iZmQtMDIudHh0DQogICAgPiAgDQogICAgPiAgICAgUmFqaXYsDQogICAgPiAgICAgDQog ICAgPiAgICAgT24gVHVlLCBNYXIgMTQsIDIwMTcgYXQgMDk6MDg6MjRQTSArMDAwMCwgUmFqaXYg QXNhdGkgKHJhaml2YSkgd3JvdGU6DQogICAgPiAgICAgPiBJcyB0aGUgYXNzdW1wdGlvbiBoZXJl IHRoYXQgdGhlIGNsaWVudCByb3V0ZXJzIGhhdmUgcm91dGluZyB2aWV3IGxpbWl0ZWQgdG8gd2hh dOKAmXMgcHJvdmlkZWQgYnkgdGhlIFJvdXRlIFNlcnZlcj8gSWYgbm90LCB0aGVuIHdvdWxkbuKA mXQgQ2xpZW50IFJvdXRlcnMgYmVuZWZpdCBmcm9tIGhhdmluZyB0byBpbnZhbGlkYXRlIHRoZSBw YXRoIGxlYXJuZWQgZnJvbSB0aGUgcmVtb3RlIGNsaWVudCByb3V0ZXIgYXMgc29vbiBhcyB0aGUg Y29ubmVjdGl2aXR5IGNoZWNrIGZhaWxlZD8NCiAgICA+ICAgICANCiAgICA+ICAgICBUaGlzIGlz IHdoYXQgSSBiZWxpZXZlIHRoZSBwcm9jZWR1cmUgc2F5cy4gIFNlZSBzZWN0aW9uIDYuDQogICAg PiAgICAgDQogICAgPiAgICAgPiBPZiBjb3Vyc2UsIENsaWVudCBSb3V0ZXJzIGNvbnZleWluZyB0 aGUgbGFjayBvZiBOTFJJIHJlYWNoYWJpbGl0eSBwZXIgTkggdG8gdGhlIFJvdXRlIFNlcnZlciwg YW5kIGV4cGVjdGluZyBSb3V0ZSBTZXJ2ZXIgdG8gcHJvdmlkZSBhIGRpZmZlcmVudCBOSHMgb2Yg dGhlIE5MUklzLCBhbmQgZXhwZWN0aW5nIGl0IHRvIGJlIGZ1bmN0aW9uYWwsIHdoaWxlIHN0aWxs IGF0dHJhY3RpbmcgdGhlIHRyYWZmaWMgZm9yIHVucmVhY2hhYmxlIGRlc3RpbmF0aW9ucyBzaW5j ZSB0aGUgTG9jLVJJQiBpcyBzdGlsbCBwb2ludGluZyB0byB0aGUgdW5yZWFjaGFibGUgTkggZm9y IHRoZSBhZmZlY3RlZCBOTFJJcy4NCiAgICA+ICAgICANCiAgICA+ICAgICBUaGUgdGhpbmcgdGhh dCBpcyBzb21ld2hhdCBkaWZmZXJlbnQgZm9yIGEgSVhQIGVudmlyb25tZW50IHJ1bm5pbmcgYSBy b3V0ZQ0KICAgID4gICAgIHNlcnZlciB0aGFuIG5vcm1hbCBlQkdQIGlzIHRoZSBsb3cgKHRvIHpl cm8pIGxpa2VsaWhvb2Qgb2YgaGF2aW5nIGEgYmFja3VwDQogICAgPiAgICAgcGF0aC4gIElmIDEw Lzggd2FzIGxlYXJuZWQgZnJvbSB0aGUgcm91dGUgc2VydmVyIGZvciBuZXh0aG9wIDE5Mi4wLjIu MSwgYW5kDQogICAgPiAgICAgeW91IHN0b3AgYmVpbmcgYWJsZSB0byByZWFjaCB0aGF0IG5leHRo b3AsIHJlbW92aW5nIGl0IGZyb20geW91ciBmb3J3YXJkaW5nDQogICAgPiAgICAgKHVucmVhY2hh YmxlKSBpcyB5b3VyIG9ubHkgY2hvaWNlLg0KICAgID4gICAgIA0KICAgID4gICAgIFlvdSAqbWln aHQqIGhhdmUgYSBzb3VyY2Ugb2YgdGhhdCBwYXRoIGludGVybmFsbHkuICBJbiB0aGF0IGNhc2Us IHlvdSBjYW4NCiAgICA+ICAgICB1c2UgaXQuDQogICAgPiAgICAgDQogICAgPiAgICAgQnV0IG1v cmUgaW1wb3J0YW50bHksIHlvdSdsbCBzdG9wIHNlbmRpbmcgaXQgdG93YXJkIHlvdXIgb3duIHBl ZXJpbmcgYW5kDQogICAgPiAgICAgYXR0cmFjdGluZyBibGFja2hvbGVkIHRyYWZmaWMuDQogICAg PiAgICAgDQogICAgPiAgICAgPiBJIHdvbmRlciB3aGV0aGVyICBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1pZHItYmdwLWJlc3RwYXRoLXNlbGVjdGlvbi1jcml0ZXJpYSBi ZSB1c2VmdWwgaGVyZS4NCiAgICA+ICAgICANCiAgICA+ICAgICBJbiBhIHNlbnNlIG9mIGdvb2Qg dGltaW5nLCBKb2huIFNjdWRkZXIgaGFkIGJyb3VnaHQgdGhpcyB0byBteSBhdHRlbnRpb24NCiAg ICA+ICAgICBhYm91dCBhbiBob3VyIGFnby4gDQogICAgPiAgICAgDQogICAgPiAgICAgUlMtQkZE IGJhc2ljYWxseSByZWludmVudHMgdGhlIHNhbWUgcHJvY2VkdXJlIGluIHlvdXIgZHJhZnQsIHNp bXBseSBiZWluZw0KICAgID4gICAgIHNwZWNpZmljIGFib3V0IHRoZSB1c2Ugb2YgQkZEIGFzIHRo ZSBkYXRhcGxhbmUgbGl2ZW5lc3MgY2hlY2sgbWVjaGFuaXNtLg0KICAgID4gICAgIEhvd2V2ZXIs IGFzIHlvdSBub3RlIGluIHRoZSBSUy1CRkQgZHJhZnQsIHdlIGRvIGxlYXZlIHRoZSBvcHRpb24g Zm9yIG90aGVyDQogICAgPiAgICAgbWVjaGFuaXNtcy4NCiAgICA+ICAgICANCiAgICA+ICAgICBJ IHN1c3BlY3QgdGhlIG90aGVyIGF1dGhvcnMgb2YgUlMtQkZEIGFyZW4ndCBwYXJ0aWN1bGFyIHdo ZXJlIHdlIHBpY2sgdXAgb3VyDQogICAgPiAgICAgdGV4dCBmb3IgdGhlIHJlc29sdmFiaWxpdHkg Y29uZGl0aW9uLiAgSG93ZXZlciwgaWYgdGhlIHN1Z2dlc3Rpb24gaXMgdG8gbWFrZQ0KICAgID4g ICAgIGEgcmVmZXJlbmNlIHRvIHlvdXIgZHJhZnQsIHlvdSdsbCBuZWVkIHRvIGJyaW5nIGl0IGJh Y2sgZnJvbSB6b21iaWUgc3RhdGUNCiAgICA+ICAgICBhbmQgcHJvZ3Jlc3MgaXQuIDotKQ0KICAg ID4gICAgIA0KICAgID4gICAgIC0tIEplZmYNCiAgICA+ICAgICANCiAgICA+ICANCiAgICA+ICAN CiAgICANCiAgICANCg0K From nobody Thu Jul 20 01:17:48 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58DBF129B3A for ; Thu, 20 Jul 2017 01:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 SYonncKtGiaj for ; Thu, 20 Jul 2017 01:17:46 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 05FD4126557 for ; Thu, 20 Jul 2017 01:17:46 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 2A5F11E377; Thu, 20 Jul 2017 04:27:25 -0400 (EDT) Date: Thu, 20 Jul 2017 04:27:25 -0400 From: Jeffrey Haas To: idr@ietf.org Message-ID: <20170720082724.GM24942@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: [Idr] IETF 99 - code point management X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:17:47 -0000 For prior reference, and also for Alexander Azimov, please also see presentations given at IETF 97: https://www.ietf.org/proceedings/97/slides/slides-97-idr-code-point-management-02.pdf https://www.ietf.org/proceedings/97/slides/slides-97-idr-extended-experimental-path-attributes-00.pdf -- Jeff From nobody Thu Jul 20 01:18:30 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B63CB129B55 for ; Thu, 20 Jul 2017 01:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 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_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=nokia.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 fvn357kNpMow for ; Thu, 20 Jul 2017 01:18:27 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0111.outbound.protection.outlook.com [104.47.2.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83F00129B3A for ; Thu, 20 Jul 2017 01:18:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vph73kfpU1CwyrdcOGyV+u6pNRcuf+VH2n5ALHvgLFw=; b=U6XZbpxnlDvJtAuEH4aCfJ0z/TRXpF7oIzv82whIBAh10FLdzYgVMp5qwBN//tti8PMEg2hcKRF3nS/+EL0M+j8gRxPu33c2RAJ5z9/6lzX0DXSdkxvqxAbWRnD2V7nMTCtEbJGLKib42kcKQQvn4nCON2fxtJgrcEmb9fcT9qs= Received: from AM2PR07MB0961.eurprd07.prod.outlook.com (10.162.37.144) by AM2PR07MB0900.eurprd07.prod.outlook.com (10.161.71.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Thu, 20 Jul 2017 08:18:24 +0000 Received: from AM2PR07MB0961.eurprd07.prod.outlook.com ([fe80::1da:6fa2:cef6:10c0]) by AM2PR07MB0961.eurprd07.prod.outlook.com ([fe80::1da:6fa2:cef6:10c0%15]) with mapi id 15.01.1282.008; Thu, 20 Jul 2017 08:18:24 +0000 From: "Henderickx, Wim (Nokia - BE/Antwerp)" To: "robert@raszuk.net" CC: "idr@ietf.org" Thread-Topic: ORR implementation report Thread-Index: AQHTATDBBKdAfF70eEe8nJIUaXMVvQ== Date: Thu, 20 Jul 2017 08:18:24 +0000 Message-ID: Accept-Language: nl-BE, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.24.0.170702 authentication-results: raszuk.net; dkim=none (message not signed) header.d=none;raszuk.net; dmarc=none action=none header.from=nokia.com; x-originating-ip: [135.245.212.15] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM2PR07MB0900; 7:hhPrg0lWZREzZ2br/xGxo5KBlOX8fpqdcCVE/4xTAYaGQ/kCZgcDSxLwxGV1Z8GzINRocMZMXaYkKpmzmX0yaZmNVBxG+k7yO7lYQL1adjjg/wEXuNhXrG6/uEnWAYzXAMDIKxc7XaA/KWp9Y6NWKJnMmatO9erNE+MDLn8qnejSxyGGjMA1COyp0Lt+QjXUlGJmKeR/H86pyZ0QLoLzBV31OgSuNjNDL06h81SJHpV9K4lMBzADQkllZ41XmG39QaKR2ylgliPOBgJjxIvUi9IH53bdugbUcRI5pOIyDBec1wVg1AWfUtWqpZ4jg0TKAU9bPZm7NO0LckN+dMH80KEVdsmYbJL/mhOrtbcM5q8vHw+Qy6vjuDrCIzLxlTq2o0YJzNes4UX7qo7qA9WXlt1wzH4YGPmdGG11AW1Vj5llwLXXL0evMPE9zJmu10d5ViWkWL1EJkNjhEv/CZxCqYFnxR5rNmO9veFwBp7ct3RLjq0dWmhbpzCe0dNNJiRce+bzKBiXLmZbElgMsXPlzo3AM0AT1DnI9+W4CTRbIsSSqTrNeU3FKnk619ZDcPBFp909vXpz+jjvSKemb/hyvOBiXOLbrgmS9Xd1tgKombVMGkF5MeenRvy+yASHaJHOTEMe1OmboIKRWErrVSAV/dgWWzeNhJqqVx7ibP8bEIKFVZmkOOQvODqWMRFsFuGcP4g5FRkfZd6P6TjFVtt9IPNb7duD4Fl9Vy6CNYGuSPSt4CzBpvzxWw3cxt0llTkXNbFQdxyl91AjXWRxDffplqYyR9uq0jVrPUnDW2fdc9E= x-ms-office365-filtering-correlation-id: a2ba8dab-8e18-41a0-e437-08d4cf47e42d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM2PR07MB0900; x-ms-traffictypediagnostic: AM2PR07MB0900: x-exchange-antispam-report-test: UriScan:(236129657087228)(167848164394848); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(8121501046)(5005006)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM2PR07MB0900; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM2PR07MB0900; x-forefront-prvs: 0374433C81 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39450400003)(39410400002)(39400400002)(39840400002)(39860400002)(8676002)(305945005)(6436002)(7736002)(99286003)(5640700003)(6512007)(53936002)(6486002)(110136004)(38730400002)(6506006)(4001350100001)(86362001)(83506001)(478600001)(102836003)(54356999)(83716003)(6116002)(50986999)(3846002)(66066001)(82746002)(14454004)(5890100001)(2501003)(5250100002)(33656002)(6916009)(2906002)(2351001)(25786009)(5660300001)(4326008)(2900100001)(189998001)(8936002)(3660700001)(36756003)(1730700003)(3480700004)(3280700002)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:AM2PR07MB0900; H:AM2PR07MB0961.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <6553E4F48E875A4A822B0937350294BA@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2017 08:18:24.2985 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0900 Archived-At: Subject: [Idr] ORR implementation report X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:18:29 -0000 Q2FuIHdlIHVwZGF0ZSB0aGUgT1JSIGltcGxlbWVudGF0aW9uIHJlcG9ydCBvbiB0aGUgSURSIFdp a2k/DQoNCkF0dGFjaGVkIHRoZSB1cGRhdGVkIHRleHQNCg0KPSBJbXBsZW1lbnRhdGlvbnMgb2Yg ZHJhZnQtaWV0Zi1pZHItYmdwLW9wdGltYWwtcm91dGUtcmVmbGVjdGlvbiA9DQoNCj09IEtub3du IEltcGxlbWVudGF0aW9ucyA9PQ0KKiBKVU5PUyAocmVwb3J0ZWQgYnkgS2V2aW4gRi4gV2FuZyBv biBNYXkgMjIgMjAxNykNCiogQ2lzY28gSU9TIFhSIChyZXBvcnRlZCBieSApDQoqIEh1YXdlaSAo cmVwb3J0ZWQgYnkgKQ0KKiBGUlIgKHJlcG9ydGVkIGJ5ICkNCiogQklSRCAocmVwb3J0ZWQgYnkg KQ0KKiBTUk9TIChyZXBvcnRlZCBieSBXaW0gSGVuZGVyaWNreC9BZGFtIFNpbXBzb24gb24gSnVs eSAyMCAyMDE3KQ0KDQo9PSBJbXBsZW1lbnRlZCBGZWF0dXJlcyA9PQ0KDQp8fCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fHwgIEpVTk9TICAgfHwgIElPUyBYUiAgICB8fCBIdWF3ZWkgfHwgU1JPUyB8fA0KfHwgQWxsb3dz IHRvIHNldCBJR1AgbG9jYXRpb24gcGVyIGVudGlyZSBSUiBpbnN0YW5jZSAgICAgICAgICAgICAg ICAgIHx8ICAgWWVzICAgIHx8ICAgIFllcyAgICAgfHwgICAgICAgIHx8IFllcyAgfHwNCnx8IEFs bG93cyB0byBzZXQgSUdQIGxvY2F0aW9uIHBlciB1cGRhdGUvcGVlciBncm91cCAgICAgICAgICAg ICAgICAgICB8fCAgIFllcyAgICB8fCAgIFllcyAgICAgIHx8ICAgICAgICB8fCBZZXMgIHx8DQp8 fCBBbGxvd3MgdG8gc2V0IElHUCBsb2NhdGlvbiBwZXIgaW5kaXZpZHVhbCBwZWVyICAgICAgICAg ICAgICAgICAgICAgfHwgICAoMSkgICAgfHwgICAgWWVzICAgICB8fCAgICAgICAgfHwgWWVzICB8 fA0KfHwgQWxsb3dzIGZvciBwb2xpY3kgY29uZmlndXJhdGlvbiBvbiBhIHBlciBjbGllbnQgYmFz aXMgICAgICAgICAgICAgIHx8ICAgKDEpICAgIHx8ICAgIFllcyAgICAgfHwgICAgICAgIHx8IFll cyAgfHwNCnx8IEFsbG93cyBmb3IgSUdQIGJhc2VkICYgcG9saWN5IGJhc2VkIHBhdGggc2VsZWN0 aW9uICAgICAgICAgICAgICAgICB8fCAgIFllcyAgICB8fCAgICBZZXMgICAgIHx8ICAgICAgICB8 fCBZZXMgIHx8DQp8fCBBbGxvd3MgdG8gY29uZmlndXJlIGJhY2t1cCBJR1AgbG9jYXRpb24gICAg ICAgICAgICAgICAgICAgICAgICAgICAgfHwgICBZZXMgICAgfHwgIFllcyAgICAgICB8fCAgICAg ICAgfHwgWWVzICB8fA0KfHwgU3VwcG9ydHMgY28tZXhpc3RlbmNlIHdpdGggYWRkLXBhdGhzICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHx8ICAgWWVzICAgIHx8ICAgWWVzICAgICAgfHwg ICAgICAgIHx8IFllcyAgfHwNCg0KKDEpIC0gSlVOT1Mgc3VwcG9ydHMgcGVyIHBlZXIgSUdQIGxv Y2F0aW9uIG9yIHBvbGljeSB3aGVuIHBlZXIgaXMgYWxvbmUgaW4gYSBwZWVyIGdyb3VwLg0KDQo= From nobody Thu Jul 20 01:20:34 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92BE8129B55; Thu, 20 Jul 2017 01:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 O9aOtUeZHmPM; Thu, 20 Jul 2017 01:20:26 -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 4A346126557; Thu, 20 Jul 2017 01:20:26 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=31.133.141.64; From: "Susan Hares" To: , Cc: "'Alvaro Retana \(aretana\)'" , "'Warren Kumari'" , , Date: Thu, 20 Jul 2017 03:57:27 -0400 Message-ID: <001c01d3012d$d55f3920$801dab60$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001D_01D3010C.4E4F1FC0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdMBLOaq+/KFSWnRRPS4KR4Vb33hgg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] Are there IDR drafts the Grow WG needs completed quickly? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:20:27 -0000 This is a multipart message in MIME format. ------=_NextPart_000_001D_01D3010C.4E4F1FC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Grow and IDR groups: As the IDR co-chairs sat in the grow meeting, we heard of an IDR draft that was so long in becoming an RFC that the Grow authors took another approach (which was less desired). We would like to know what IDR drafts need to be moved forward quickly. If you would send the name of these drafts to the chairs, it would help us push forward these critical drafts. You can send these names in response to this email or send a private note to the IDR chairs. Sue Hares ------=_NextPart_000_001D_01D3010C.4E4F1FC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Grow and = IDR groups:

 

As the IDR co-chairs sat in the grow meeting, we heard = of an IDR draft that was so long in becoming an RFC that the Grow = authors took another approach (which was less desired).  =

 

We would like to know what IDR drafts need to be moved = forward quickly.  If you would send the name of these drafts to the = chairs, it would help us push forward these critical drafts.  You = can send these names in response to this email or send a private note to = the IDR chairs.

 

Sue = Hares

------=_NextPart_000_001D_01D3010C.4E4F1FC0-- From nobody Thu Jul 20 01:26:16 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34B7F129B3A for ; Thu, 20 Jul 2017 01:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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 AOpxSK2lrvCq for ; Thu, 20 Jul 2017 01:26:12 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8251E131897 for ; Thu, 20 Jul 2017 01:26:06 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id v205so3478604itf.1 for ; Thu, 20 Jul 2017 01:26:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=DSfEzl4C47w71jrSP1HEx9qR8DsbIzJfR3sla010Hxw=; b=jlqpruUbJgRCa1C2eCrUDep3MPZwE1jER78v+V7wxIDjqhNiqqTuJR1LSMdI0gyDSF CNPcNl7kXARaHO7Yq1jh8DqF66jIpFmEbJAUb9bgvkyXKPvm2aZzWYmvOFy++PJNN2s/ rbWTeBLurEgoIS9FYY0T6/+pPus6Gi58O+wkzyejf+lQFw+4/hNbXd2eGsZp2NrhnBwy feD4htEQT+7uTd5clyoI02V69yTHp5QDJr2Zy4wdM8Mki9Loz5EZ2+sLIWdrBDfPKBCK zagIkJklgVvbRF9KbXUCpKQl+/rdp5SZ0kYL9IjAaxPUHMbUEw//LxbHyqf0DGCETzXq t/oA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=DSfEzl4C47w71jrSP1HEx9qR8DsbIzJfR3sla010Hxw=; b=lxyAFbui919q8O8WUl7ZOYVBEphPpUnyYO7LNg20UAwQy1Qm9Tyubf5ulRsqCotoZm Ph1hqFcXOtfP7cNZ9LBspdMSq1AB30boqWXpk7kb3aCKOLNCBC+bV9exYVjFm4MhwNRt Y6GtWcPNaTu1l5qFup12dIuPa8zPO13Q16Dh2deo+wHt/ugf+kDSR5oMA/ocxG24FlEZ pOYdUOythrtRl1i0mMY1/eCudDLA7aMM4/X1UsEoE7CMaF7bKvKWPtTGz6CQ4QmSFYbA h8RGsfnrBRSNFMhtgch5PaunXKgpE87ZJn5hq6oeWLzqj7fvNHnnR3oQr18VHrbi1FQv /tLw== X-Gm-Message-State: AIVw111S/7OO0PahTQd6Q7JWJHPtg7Q1e/3uKv6fgifyuvp026iFf2iw kWzkcqKL7rTCTlXofBJ2krUbP9425P7X X-Received: by 10.36.101.73 with SMTP id u70mr2375378itb.33.1500539165723; Thu, 20 Jul 2017 01:26:05 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.153.21 with HTTP; Thu, 20 Jul 2017 01:26:04 -0700 (PDT) Received: by 10.79.153.21 with HTTP; Thu, 20 Jul 2017 01:26:04 -0700 (PDT) In-Reply-To: <003701d30130$350367f0$9f0a37d0$@ndzh.com> References: <003701d30130$350367f0$9f0a37d0$@ndzh.com> From: Robert Raszuk Date: Thu, 20 Jul 2017 10:26:04 +0200 X-Google-Sender-Auth: zAavvPbZid582ImY6OKeBy15ffY Message-ID: To: Susan Hares Cc: idr wg , wim.henderickx@nokia.com Content-Type: multipart/alternative; boundary="001a1145a88cf1d16c0554bb7fc9" Archived-At: Subject: Re: [Idr] ORR implementation report X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:26:14 -0000 --001a1145a88cf1d16c0554bb7fc9 Content-Type: text/plain; charset="UTF-8" Hi Wim, Send it to me and I will also gladly update the report I created with your data. Btw I also have next version ready (-14) so should post it soon. Cheers, R. On Jul 20, 2017 10:20, "Susan Hares" wrote: > Wim: > > If you have a datatracker account, you can update the wiki. However, I > will be glad to update the wiki for you later in the day. > > Sue > > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Henderickx, Wim > (Nokia > - BE/Antwerp) > Sent: Thursday, July 20, 2017 4:18 AM > To: robert@raszuk.net > Cc: idr@ietf.org > Subject: [Idr] ORR implementation report > > Can we update the ORR implementation report on the IDR Wiki? > > Attached the updated text > > = Implementations of draft-ietf-idr-bgp-optimal-route-reflection = > > == Known Implementations == > * JUNOS (reported by Kevin F. Wang on May 22 2017) > * Cisco IOS XR (reported by ) > * Huawei (reported by ) > * FRR (reported by ) > * BIRD (reported by ) > * SROS (reported by Wim Henderickx/Adam Simpson on July 20 2017) > > == Implemented Features == > > || || > JUNOS || IOS XR || Huawei || SROS || > || Allows to set IGP location per entire RR instance || > Yes || Yes || || Yes || > || Allows to set IGP location per update/peer group || > Yes || Yes || || Yes || > || Allows to set IGP location per individual peer || > (1) || Yes || || Yes || > || Allows for policy configuration on a per client basis || > (1) || Yes || || Yes || > || Allows for IGP based & policy based path selection || > Yes || Yes || || Yes || > || Allows to configure backup IGP location || > Yes || Yes || || Yes || > || Supports co-existence with add-paths || > Yes || Yes || || Yes || > > (1) - JUNOS supports per peer IGP location or policy when peer is alone in > a > peer group. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > --001a1145a88cf1d16c0554bb7fc9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Wim,

Send= it to me and I will also gladly update the report I created with your data= .

Btw I also have next v= ersion ready (-14) so should post it soon.

Cheers,
R.

On Jul 20, 2017 10:20, &quo= t;Susan Hares" <shares@ndzh.com<= /a>> wrote:
Wim:<= br>
If=C2=A0 you have a datatracker account, you can update the wiki.=C2=A0 =C2= =A0However, I
will be glad to update the wiki for you later in the day.

Sue

-----Original Message-----
From: Idr [mailto:idr-bounces@ietf.= org] On Behalf Of Henderickx, Wim (Nokia
- BE/Antwerp)
Sent: Thursday, July 20, 2017 4:18 AM
To: robert@raszuk.net
Cc: idr@ietf.org
Subject: [Idr] ORR implementation report

Can we update the ORR implementation report on the IDR Wiki?

Attached the updated text

=3D Implementations of draft-ietf-idr-bgp-optimal-route-reflection =3D=

=3D=3D Known Implementations =3D=3D
* JUNOS (reported by Kevin F. Wang on May 22 2017)
* Cisco IOS XR (reported by )
* Huawei (reported by )
* FRR (reported by )
* BIRD (reported by )
* SROS (reported by Wim Henderickx/Adam Simpson on July 20 2017)

=3D=3D Implemented Features =3D=3D

||=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 ||
JUNOS=C2=A0 =C2=A0||=C2=A0 IOS XR=C2=A0 =C2=A0 || Huawei || SROS ||
|| Allows to set IGP location per entire RR instance=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ||
Yes=C2=A0 =C2=A0 ||=C2=A0 =C2=A0 Yes=C2=A0 =C2=A0 =C2=A0||=C2=A0 =C2=A0 =C2= =A0 =C2=A0 || Yes=C2=A0 ||
|| Allows to set IGP location per update/peer group=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0||
Yes=C2=A0 =C2=A0 ||=C2=A0 =C2=A0Yes=C2=A0 =C2=A0 =C2=A0 ||=C2=A0 =C2=A0 =C2= =A0 =C2=A0 || Yes=C2=A0 ||
|| Allows to set IGP location per individual peer=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0||
(1)=C2=A0 =C2=A0 ||=C2=A0 =C2=A0 Yes=C2=A0 =C2=A0 =C2=A0||=C2=A0 =C2=A0 =C2= =A0 =C2=A0 || Yes=C2=A0 ||
|| Allows for policy configuration on a per client basis=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ||
(1)=C2=A0 =C2=A0 ||=C2=A0 =C2=A0 Yes=C2=A0 =C2=A0 =C2=A0||=C2=A0 =C2=A0 =C2= =A0 =C2=A0 || Yes=C2=A0 ||
|| Allows for IGP based & policy based path selection=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0||
Yes=C2=A0 =C2=A0 ||=C2=A0 =C2=A0 Yes=C2=A0 =C2=A0 =C2=A0||=C2=A0 =C2=A0 =C2= =A0 =C2=A0 || Yes=C2=A0 ||
|| Allows to configure backup IGP location=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ||
Yes=C2=A0 =C2=A0 ||=C2=A0 Yes=C2=A0 =C2=A0 =C2=A0 =C2=A0||=C2=A0 =C2=A0 =C2= =A0 =C2=A0 || Yes=C2=A0 ||
|| Supports co-existence with add-paths=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0||
Yes=C2=A0 =C2=A0 ||=C2=A0 =C2=A0Yes=C2=A0 =C2=A0 =C2=A0 ||=C2=A0 =C2=A0 =C2= =A0 =C2=A0 || Yes=C2=A0 ||

(1) - JUNOS supports per peer IGP location or policy when peer is alone in = a
peer group.

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

--001a1145a88cf1d16c0554bb7fc9-- From nobody Thu Jul 20 01:27:10 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B113A129B3A for ; Thu, 20 Jul 2017 01:27:09 -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, HEADER_FROM_DIFFERENT_DOMAINS=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=highloadlab-com.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 mdmihSL8zzjF for ; Thu, 20 Jul 2017 01:27:07 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::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 98B94131897 for ; Thu, 20 Jul 2017 01:27:07 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id o88so9703649pfk.3 for ; Thu, 20 Jul 2017 01:27:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=highloadlab-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=jUB4j9687QFaux3GIHfTPuXUMm3bUdpbbWDcVTuSIYc=; b=NLfeo4nVwdSdSWfs6m0wOPj0QR9s01BfDM2vQnVQV2vt9S/ViY+jv+hsy+Ptl+9DR2 dtFX3Cw7qh+chSQF92umWPpNsqweItGSs4NlD68vvWWPem2wr9U3pTZhjBeAthDmNeD6 l/fi/mZ9IYT14UoM+YslaFYePU9PCIVcrX+WxaXstWaIK9W85sWSAFo6aSL+qrOQmsIj fgzENfmW8fPK4pAzaBDwQITWM3UsZlQ3Rfv2w4EvNgCar7bcth+0rZLgGEhWjx89yXjM pXXGAuJNwO8wG8MEmbc6LqArXbggKoGXRzRk7HSYvwlgv3TEeQp0U0wqNbwLCFDv/F9M GBlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=jUB4j9687QFaux3GIHfTPuXUMm3bUdpbbWDcVTuSIYc=; b=j/7EypFQDVL3xheefcj16L8pecx7omIy4BVkMrWUWHgvmjBSqCfgxw7vy358AcGtvf zbA7G3/7CqUx0xYOmfvk2hzlNa+rxnyI96kRlRiMRjI4tKKwj9huZWGnxmbWNDjmMRf4 s2WUlTPq5WTOsrFH1t+Uou1DChJeBVC6gXI3rNEx+zqyxsF6fLn9+JPVshQvYULDPLrf L/1pjjJBSaDe2eJhGSRIAonVcv5mQrAopulnOAMxGOt8h2rSnTYMJ1VWFc87nXQUW8YY WwuBCF96XbEjF/Hu4DNlKlV9L4ivD8FyghJV3vVPty/tlsfzJTxSxNVTCAmwOdVilSed lr7A== X-Gm-Message-State: AIVw113ay9d1gdVVubTZoLOXqArhbCKrqqOwm5Gx/OZTSxhqhbPi6Dtb GeidPspu0siUTCV48O9oTpVGDzhbwIO3 X-Received: by 10.99.111.1 with SMTP id k1mr3000915pgc.225.1500539227131; Thu, 20 Jul 2017 01:27:07 -0700 (PDT) MIME-Version: 1.0 Sender: aa@highloadlab.com Received: by 10.100.163.176 with HTTP; Thu, 20 Jul 2017 01:27:06 -0700 (PDT) X-Originating-IP: [2001:67c:370:128:5ca2:9250:3600:2c09] In-Reply-To: <20170720082724.GM24942@pfrc.org> References: <20170720082724.GM24942@pfrc.org> From: Alexander Azimov Date: Thu, 20 Jul 2017 11:27:06 +0300 X-Google-Sender-Auth: IxTNGlPwmaVO0iC4GQm8UG7t2VI Message-ID: To: Jeffrey Haas Cc: idr wg Content-Type: multipart/alternative; boundary="94eb2c19d22c9ae42c0554bb83ca" Archived-At: Subject: Re: [Idr] IETF 99 - code point management X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:27:10 -0000 --94eb2c19d22c9ae42c0554bb83ca Content-Type: text/plain; charset="UTF-8" Hi Jeff, Thank you for sharing these links. My question was not only about path attributes, what if one need capability/notification codes? 2017-07-20 11:27 GMT+03:00 Jeffrey Haas : > For prior reference, and also for Alexander Azimov, please also see > presentations given at IETF 97: > > https://www.ietf.org/proceedings/97/slides/slides- > 97-idr-code-point-management-02.pdf > https://www.ietf.org/proceedings/97/slides/slides- > 97-idr-extended-experimental-path-attributes-00.pdf > > -- Jeff > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > -- | Alexander Azimov | HLL l QRATOR | tel.: +7 499 241 81 92 | mob.: +7 915 360 08 86 | skype: mitradir | mailto: aa@qrator.net | visit: www.qrator.net --94eb2c19d22c9ae42c0554bb83ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jeff,

Thank you for sharing these li= nks.=C2=A0
My question was not only about path attributes, what i= f one need capability/notification codes?

2017-07-20 11:27 GMT+03:00 Jeffrey Haas= <= jhaas@pfrc.org>:
For prio= r reference, and also for Alexander Azimov, please also see
presentations given at IETF 97:

https://www.iet= f.org/proceedings/97/slides/slides-97-idr-code-point-management-<= wbr>02.pdf
https://www.ietf.org/proceedings/97/slides/slides-97-idr-extende= d-experimental-path-attributes-00.pdf

-- Jeff

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



--
= | Alexander Azimov =C2=A0| HLL l QRATOR
| tel.: +7 499 241 81 92
| mob.: +7 915 360 08 86
| skype: mitradir
| mailto:=C2=A0= aa@qrator.net=
| visit:=C2=A0www.qrator.net
--94eb2c19d22c9ae42c0554bb83ca-- From nobody Thu Jul 20 01:28:20 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4179C13150C for ; Thu, 20 Jul 2017 01:28:16 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.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 k4Ym-sIQvwh9 for ; Thu, 20 Jul 2017 01:28:14 -0700 (PDT) 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 E5983127869 for ; Thu, 20 Jul 2017 01:28:13 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id 12so67714248wrb.1 for ; Thu, 20 Jul 2017 01:28:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MsScB0SRQK4G59ljRnXb/44B9S5YnI+RMHJPHocpKbE=; b=R9BWbCC3HATKhuzt7kmCqxV2okhz7CV4On0SG+m0b3M/B8ZW+tHuJwLNv69u6BQsKD 5iSd/n0oKChJTCDUDnNwgXLqEil092SvVWUKRfhyLcOZZmkzdzMp4wOjP+AhEikumeqM gt7XYEppIM7+JV5Njzsw+ysafgDJO8I64tpRfKSH7tMGBGJis4Hd1fyq1naUHn4my0mt Z+MITfWPrus1/XEFdePNH7sUWPGAXQgQXjJXePRUwrRFl/Wyzisr3T7fWsTKQOAJon0s 5wzO58NRpRzI6jTNYdPzgJioNRBCCUlEv+NbsfsYzj0Z1yOOppT1hBUzdijf3I5xDB0B xACQ== 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=MsScB0SRQK4G59ljRnXb/44B9S5YnI+RMHJPHocpKbE=; b=V8bIFxz85/8A24TV0XVOxa3HOXhBD409oQdh6k8to4GVKf5A+ayUiv8C936IJEVX34 okekKG+VFUyzOCY5U9AmpUBvpELVTKpcvhrtS1y5hrggRml96EsxxJKegotZC32z+OK3 BD5fJmTOFCgbW/7S4lpbcMbgQsutHwyvnnWKGGocVy9kU35e8Svrpv0+pDG6YOQXXDpS JV5vdSxBOZ3zgHzh5XahTDi65VYCZHd0azPpcS8M6Da/2f/ZfBGW/lIcAT1AfGXDU7G/ SSkRwznlHg7aySvSlOhO3rm4KnKfnPeoXi79cK9qQvwX0nWxEyUtThRld5z25mkOxL1T XuUg== X-Gm-Message-State: AIVw113ze3sLKv1/OuvFA4OR0mBJv9qjdXvfE/URaVV/GdKbsCAe8WiK N+MY203+JvzkDrFY5bXUNxCXd2wbN1BK X-Received: by 10.223.171.200 with SMTP id s66mr5277250wrc.38.1500539292320; Thu, 20 Jul 2017 01:28:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.174.10 with HTTP; Thu, 20 Jul 2017 01:28:11 -0700 (PDT) X-Originating-IP: [2001:67c:370:128:454f:4:b926:9a31] In-Reply-To: References: From: Job Snijders Date: Thu, 20 Jul 2017 10:28:11 +0200 Message-ID: To: "Henderickx, Wim (Nokia - BE/Antwerp)" Cc: "robert@raszuk.net" , "idr@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Idr] ORR implementation report X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:28:16 -0000 done! On Thu, Jul 20, 2017 at 10:18 AM, Henderickx, Wim (Nokia - BE/Antwerp) wrote: > Can we update the ORR implementation report on the IDR Wiki? > > Attached the updated text > > = Implementations of draft-ietf-idr-bgp-optimal-route-reflection = > > == Known Implementations == > * JUNOS (reported by Kevin F. Wang on May 22 2017) > * Cisco IOS XR (reported by ) > * Huawei (reported by ) > * FRR (reported by ) > * BIRD (reported by ) > * SROS (reported by Wim Henderickx/Adam Simpson on July 20 2017) > > == Implemented Features == > > || || JUNOS || IOS XR || Huawei || SROS || > || Allows to set IGP location per entire RR instance || Yes || Yes || || Yes || > || Allows to set IGP location per update/peer group || Yes || Yes || || Yes || > || Allows to set IGP location per individual peer || (1) || Yes || || Yes || > || Allows for policy configuration on a per client basis || (1) || Yes || || Yes || > || Allows for IGP based & policy based path selection || Yes || Yes || || Yes || > || Allows to configure backup IGP location || Yes || Yes || || Yes || > || Supports co-existence with add-paths || Yes || Yes || || Yes || > > (1) - JUNOS supports per peer IGP location or policy when peer is alone in a peer group. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Thu Jul 20 01:28:44 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3036129B55 for ; Thu, 20 Jul 2017 01:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 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=-2.8, 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=nokia.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 SiVpW2_PK2QR for ; Thu, 20 Jul 2017 01:28:40 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0119.outbound.protection.outlook.com [104.47.0.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7CC8129B3A for ; Thu, 20 Jul 2017 01:28:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9BvMVbo1nklc3lUPjmkKdR9Eow4s7+GPhuT5zzV3Dfo=; b=FcXBp8W8zp8fSTi4XMTdiFEnGHe/OIr3EEqvBCAneKsDkH7axY61vmNCaPCWvqUsHWPRrYm7I6krp24jNxfrrSYyB0H3G29pC+HReCSxLzRsMKY4tp3wqbkaYVgo7U/1znygFwnDyS4KI+V8+VTXHy00sEnNf4sL4CddRMFwubY= Received: from AM2PR07MB0961.eurprd07.prod.outlook.com (10.162.37.144) by AM2PR07MB0657.eurprd07.prod.outlook.com (10.160.55.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Thu, 20 Jul 2017 08:28:37 +0000 Received: from AM2PR07MB0961.eurprd07.prod.outlook.com ([fe80::1da:6fa2:cef6:10c0]) by AM2PR07MB0961.eurprd07.prod.outlook.com ([fe80::1da:6fa2:cef6:10c0%15]) with mapi id 15.01.1282.008; Thu, 20 Jul 2017 08:28:37 +0000 From: "Henderickx, Wim (Nokia - BE/Antwerp)" To: Robert Raszuk , Susan Hares CC: idr wg Thread-Topic: [Idr] ORR implementation report Thread-Index: AQHTATDBBKdAfF70eEe8nJIUaXMVvaJcXgUAgAADQACAACI9AA== Date: Thu, 20 Jul 2017 08:28:37 +0000 Message-ID: References: <003701d30130$350367f0$9f0a37d0$@ndzh.com> In-Reply-To: Accept-Language: nl-BE, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.24.0.170702 authentication-results: raszuk.net; dkim=none (message not signed) header.d=none;raszuk.net; dmarc=none action=none header.from=nokia.com; x-originating-ip: [135.245.212.15] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM2PR07MB0657; 7:kJPgpNdZ8Igp+h05ehYMNnvLoZX9G3zRWgUH38pzZW11VyQ9Q0jM1ERvGqWwdIwik3ntmJ0u+DovuroxjvaXpLg0D2NU3wy/ZViUJDZ/D0N2wQYc2ANLWzrwIcB1/KJWdQlvw3rx0mhh13vnzfz7OLYfX69RC10PPwSZ/1cdWQm+h41dJSxw92izKZ/SsqFDkdxym2ia1HABLphJlO1oaPTse9XOyRuyuNH8jsJ9J1iMrW15/yPZz2hFJkkpxsYKABFdvFpNUlUmAD63BOEZfDdDDLBYjeh0v+ZE1ExF09oxv/eeGGGG5gVbkOylUec6NMYaPzwHQu7/pfZTKxjDi37k5+phrt6pJ9Fgq3Bv9jsv3PFA/dB983fcI8NOeRJYzzn70gfUHk+Jd2qL+QXsl16xha+JC2uzsKM8y4oOiEYQQelUZlB+eRqXD1dAEE7JEi9/KE/9raHfIFXf8aS7moS+5GJ/D8yZQPohK8LMiMHEI6YjKZ+8BadkVjZpfG2oR4R/PzvubX9h9WRZeUk3F2EOhG+u6LRWnrLDO9FpY0AiznclQbrNRy9Bm6DwG1/wZ4SU/L9ZMuSLe4m/e8WEQWBzaFoCCb/ckr13N9gqluy1KYA3axmQYjFeFWR1Jsfcw2BrIIgsnQO2gVSrHZK8BQBGKLeraGVBSlkFgAHAMeJ5wJ7IIRDjyx4IPmje2+EuVWAejn1/oScFGHC0lL/t6vgfYhHgLcKl6IgQvDlQ9MU/uNxXGNGQaqWyympZDNtSLsL7rfAUCE0i74z7/QkZZFlsFAgstqV+jLaNHK515ro= x-ms-office365-filtering-correlation-id: 3f8cbb1c-1104-4b12-b7c0-08d4cf49519b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM2PR07MB0657; x-ms-traffictypediagnostic: AM2PR07MB0657: x-exchange-antispam-report-test: UriScan:(151999592597050)(133145235818549)(26388249023172)(236129657087228)(82608151540597)(48057245064654)(21748063052155)(167848164394848); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(2017060910075)(8121501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(10201501046)(6055026)(6041248)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM2PR07MB0657; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM2PR07MB0657; x-forefront-prvs: 0374433C81 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400002)(39410400002)(39860400002)(39400400002)(39450400003)(39840400002)(13464003)(377454003)(24454002)(6306002)(76176999)(82746002)(54896002)(6512007)(53936002)(54356999)(5660300001)(236005)(50986999)(2900100001)(6436002)(189998001)(3280700002)(8936002)(36756003)(53546010)(81166006)(606006)(2906002)(8676002)(6246003)(99286003)(2950100002)(966005)(14454004)(33656002)(3660700001)(25786009)(83506001)(5890100001)(6116002)(86362001)(4326008)(5250100002)(66066001)(3846002)(6506006)(7736002)(6486002)(229853002)(102836003)(4001350100001)(83716003)(38730400002)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM2PR07MB0657; H:AM2PR07MB0961.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_C43F534CEEDB41EEB3F7628A64CF6946nokiacom_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2017 08:28:37.3710 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0657 Archived-At: Subject: Re: [Idr] ORR implementation report X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:28:43 -0000 --_000_C43F534CEEDB41EEB3F7628A64CF6946nokiacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGlkIGl0IGluIHRoZSBtZWFud2hpbGUuIFRoeCBmb3Igc3VwcG9ydA0KDQpGcm9tOiA8cnJhc3p1 a0BnbWFpbC5jb20+IG9uIGJlaGFsZiBvZiBSb2JlcnQgUmFzenVrIDxyb2JlcnRAcmFzenVrLm5l dD4NCkRhdGU6IFRodXJzZGF5LCAyMCBKdWx5IDIwMTcgYXQgMTA6MjYNClRvOiBTdXNhbiBIYXJl cyA8c2hhcmVzQG5kemguY29tPg0KQ2M6IElEUiA8aWRyQGlldGYub3JnPiwgIkhlbmRlcmlja3gs IFdpbSAoTm9raWEgLSBCRS9BbnR3ZXJwKSIgPHdpbS5oZW5kZXJpY2t4QG5va2lhLmNvbT4NClN1 YmplY3Q6IFJFOiBbSWRyXSBPUlIgaW1wbGVtZW50YXRpb24gcmVwb3J0DQoNCkhpIFdpbSwNCg0K U2VuZCBpdCB0byBtZSBhbmQgSSB3aWxsIGFsc28gZ2xhZGx5IHVwZGF0ZSB0aGUgcmVwb3J0IEkg Y3JlYXRlZCB3aXRoIHlvdXIgZGF0YS4NCg0KQnR3IEkgYWxzbyBoYXZlIG5leHQgdmVyc2lvbiBy ZWFkeSAoLTE0KSBzbyBzaG91bGQgcG9zdCBpdCBzb29uLg0KDQpDaGVlcnMsDQpSLg0KDQpPbiBK dWwgMjAsIDIwMTcgMTA6MjAsICJTdXNhbiBIYXJlcyIgPHNoYXJlc0BuZHpoLmNvbTxtYWlsdG86 c2hhcmVzQG5kemguY29tPj4gd3JvdGU6DQpXaW06DQoNCklmICB5b3UgaGF2ZSBhIGRhdGF0cmFj a2VyIGFjY291bnQsIHlvdSBjYW4gdXBkYXRlIHRoZSB3aWtpLiAgIEhvd2V2ZXIsIEkNCndpbGwg YmUgZ2xhZCB0byB1cGRhdGUgdGhlIHdpa2kgZm9yIHlvdSBsYXRlciBpbiB0aGUgZGF5Lg0KDQpT dWUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IElkciBbbWFpbHRvOmlkci1i b3VuY2VzQGlldGYub3JnPG1haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBP ZiBIZW5kZXJpY2t4LCBXaW0gKE5va2lhDQotIEJFL0FudHdlcnApDQpTZW50OiBUaHVyc2RheSwg SnVseSAyMCwgMjAxNyA0OjE4IEFNDQpUbzogcm9iZXJ0QHJhc3p1ay5uZXQ8bWFpbHRvOnJvYmVy dEByYXN6dWsubmV0Pg0KQ2M6IGlkckBpZXRmLm9yZzxtYWlsdG86aWRyQGlldGYub3JnPg0KU3Vi amVjdDogW0lkcl0gT1JSIGltcGxlbWVudGF0aW9uIHJlcG9ydA0KDQpDYW4gd2UgdXBkYXRlIHRo ZSBPUlIgaW1wbGVtZW50YXRpb24gcmVwb3J0IG9uIHRoZSBJRFIgV2lraT8NCg0KQXR0YWNoZWQg dGhlIHVwZGF0ZWQgdGV4dA0KDQo9IEltcGxlbWVudGF0aW9ucyBvZiBkcmFmdC1pZXRmLWlkci1i Z3Atb3B0aW1hbC1yb3V0ZS1yZWZsZWN0aW9uID0NCg0KPT0gS25vd24gSW1wbGVtZW50YXRpb25z ID09DQoqIEpVTk9TIChyZXBvcnRlZCBieSBLZXZpbiBGLiBXYW5nIG9uIE1heSAyMiAyMDE3KQ0K KiBDaXNjbyBJT1MgWFIgKHJlcG9ydGVkIGJ5ICkNCiogSHVhd2VpIChyZXBvcnRlZCBieSApDQoq IEZSUiAocmVwb3J0ZWQgYnkgKQ0KKiBCSVJEIChyZXBvcnRlZCBieSApDQoqIFNST1MgKHJlcG9y dGVkIGJ5IFdpbSBIZW5kZXJpY2t4L0FkYW0gU2ltcHNvbiBvbiBKdWx5IDIwIDIwMTcpDQoNCj09 IEltcGxlbWVudGVkIEZlYXR1cmVzID09DQoNCnx8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8fA0KSlVOT1MgICB8fCAg SU9TIFhSICAgIHx8IEh1YXdlaSB8fCBTUk9TIHx8DQp8fCBBbGxvd3MgdG8gc2V0IElHUCBsb2Nh dGlvbiBwZXIgZW50aXJlIFJSIGluc3RhbmNlICAgICAgICAgICAgICAgICAgfHwNClllcyAgICB8 fCAgICBZZXMgICAgIHx8ICAgICAgICB8fCBZZXMgIHx8DQp8fCBBbGxvd3MgdG8gc2V0IElHUCBs b2NhdGlvbiBwZXIgdXBkYXRlL3BlZXIgZ3JvdXAgICAgICAgICAgICAgICAgICAgfHwNClllcyAg ICB8fCAgIFllcyAgICAgIHx8ICAgICAgICB8fCBZZXMgIHx8DQp8fCBBbGxvd3MgdG8gc2V0IElH UCBsb2NhdGlvbiBwZXIgaW5kaXZpZHVhbCBwZWVyICAgICAgICAgICAgICAgICAgICAgfHwNCigx KSAgICB8fCAgICBZZXMgICAgIHx8ICAgICAgICB8fCBZZXMgIHx8DQp8fCBBbGxvd3MgZm9yIHBv bGljeSBjb25maWd1cmF0aW9uIG9uIGEgcGVyIGNsaWVudCBiYXNpcyAgICAgICAgICAgICAgfHwN CigxKSAgICB8fCAgICBZZXMgICAgIHx8ICAgICAgICB8fCBZZXMgIHx8DQp8fCBBbGxvd3MgZm9y IElHUCBiYXNlZCAmIHBvbGljeSBiYXNlZCBwYXRoIHNlbGVjdGlvbiAgICAgICAgICAgICAgICAg fHwNClllcyAgICB8fCAgICBZZXMgICAgIHx8ICAgICAgICB8fCBZZXMgIHx8DQp8fCBBbGxvd3Mg dG8gY29uZmlndXJlIGJhY2t1cCBJR1AgbG9jYXRpb24gICAgICAgICAgICAgICAgICAgICAgICAg ICAgfHwNClllcyAgICB8fCAgWWVzICAgICAgIHx8ICAgICAgICB8fCBZZXMgIHx8DQp8fCBTdXBw b3J0cyBjby1leGlzdGVuY2Ugd2l0aCBhZGQtcGF0aHMgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfHwNClllcyAgICB8fCAgIFllcyAgICAgIHx8ICAgICAgICB8fCBZZXMgIHx8DQoNCigx KSAtIEpVTk9TIHN1cHBvcnRzIHBlciBwZWVyIElHUCBsb2NhdGlvbiBvciBwb2xpY3kgd2hlbiBw ZWVyIGlzIGFsb25lIGluIGENCnBlZXIgZ3JvdXAuDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpJZHIgbWFpbGluZyBsaXN0DQpJZHJAaWV0Zi5vcmc8 bWFpbHRvOklkckBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaWRyDQo= --_000_C43F534CEEDB41EEB3F7628A64CF6946nokiacom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N CnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1u YW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjU5NS4wcHQgODQyLjBwdDsNCgltYXJn aW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9Indo aXRlIiBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5EaWQgaXQgaW4gdGhlIG1lYW53aGlsZS4gVGh4IGZvciBz dXBwb3J0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Y29sb3I6YmxhY2siPiZsdDtycmFzenVrQGdtYWlsLmNvbSZndDsgb24gYmVoYWxmIG9m IFJvYmVydCBSYXN6dWsgJmx0O3JvYmVydEByYXN6dWsubmV0Jmd0Ozxicj4NCjxiPkRhdGU6IDwv Yj5UaHVyc2RheSwgMjAgSnVseSAyMDE3IGF0IDEwOjI2PGJyPg0KPGI+VG86IDwvYj5TdXNhbiBI YXJlcyAmbHQ7c2hhcmVzQG5kemguY29tJmd0Ozxicj4NCjxiPkNjOiA8L2I+SURSICZsdDtpZHJA aWV0Zi5vcmcmZ3Q7LCAmcXVvdDtIZW5kZXJpY2t4LCBXaW0gKE5va2lhIC0gQkUvQW50d2VycCkm cXVvdDsgJmx0O3dpbS5oZW5kZXJpY2t4QG5va2lhLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8 L2I+UkU6IFtJZHJdIE9SUiBpbXBsZW1lbnRhdGlvbiByZXBvcnQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkhpIFdpbSwgPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5TZW5kIGl0IHRvIG1lIGFuZCBJIHdp bGwgYWxzbyBnbGFkbHkgdXBkYXRlIHRoZSByZXBvcnQgSSBjcmVhdGVkIHdpdGggeW91ciBkYXRh LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5CdHcg SSBhbHNvIGhhdmUgbmV4dCB2ZXJzaW9uIHJlYWR5ICgtMTQpIHNvIHNob3VsZCBwb3N0IGl0IHNv b24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkNo ZWVycyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPk9uIEp1bCAyMCwgMjAxNyAxMDoyMCwgJnF1b3Q7U3Vz YW4gSGFyZXMmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzaGFyZXNAbmR6aC5jb20iPnNoYXJl c0BuZHpoLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow Y20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGNtO21hcmdpbi1y aWdodDowY207bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCldpbTo8 YnI+DQo8YnI+DQpJZiZuYnNwOyB5b3UgaGF2ZSBhIGRhdGF0cmFja2VyIGFjY291bnQsIHlvdSBj YW4gdXBkYXRlIHRoZSB3aWtpLiZuYnNwOyAmbmJzcDtIb3dldmVyLCBJPGJyPg0Kd2lsbCBiZSBn bGFkIHRvIHVwZGF0ZSB0aGUgd2lraSBmb3IgeW91IGxhdGVyIGluIHRoZSBkYXkuPGJyPg0KPGJy Pg0KU3VlPGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBJ ZHIgW21haWx0bzo8YSBocmVmPSJtYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmciPmlkci1ib3Vu Y2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIEhlbmRlcmlja3gsIFdpbSAoTm9raWE8YnI+ DQotIEJFL0FudHdlcnApPGJyPg0KU2VudDogVGh1cnNkYXksIEp1bHkgMjAsIDIwMTcgNDoxOCBB TTxicj4NClRvOiA8YSBocmVmPSJtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQiPnJvYmVydEByYXN6 dWsubmV0PC9hPjxicj4NCkNjOiA8YSBocmVmPSJtYWlsdG86aWRyQGlldGYub3JnIj5pZHJAaWV0 Zi5vcmc8L2E+PGJyPg0KU3ViamVjdDogW0lkcl0gT1JSIGltcGxlbWVudGF0aW9uIHJlcG9ydDxi cj4NCjxicj4NCkNhbiB3ZSB1cGRhdGUgdGhlIE9SUiBpbXBsZW1lbnRhdGlvbiByZXBvcnQgb24g dGhlIElEUiBXaWtpPzxicj4NCjxicj4NCkF0dGFjaGVkIHRoZSB1cGRhdGVkIHRleHQ8YnI+DQo8 YnI+DQo9IEltcGxlbWVudGF0aW9ucyBvZiBkcmFmdC1pZXRmLWlkci1iZ3Atb3B0aW1hbC1yb3V0 ZS1yZWZsZWN0aW9uID08YnI+DQo8YnI+DQo9PSBLbm93biBJbXBsZW1lbnRhdGlvbnMgPT08YnI+ DQoqIEpVTk9TIChyZXBvcnRlZCBieSBLZXZpbiBGLiBXYW5nIG9uIE1heSAyMiAyMDE3KTxicj4N CiogQ2lzY28gSU9TIFhSIChyZXBvcnRlZCBieSApPGJyPg0KKiBIdWF3ZWkgKHJlcG9ydGVkIGJ5 ICk8YnI+DQoqIEZSUiAocmVwb3J0ZWQgYnkgKTxicj4NCiogQklSRCAocmVwb3J0ZWQgYnkgKTxi cj4NCiogU1JPUyAocmVwb3J0ZWQgYnkgV2ltIEhlbmRlcmlja3gvQWRhbSBTaW1wc29uIG9uIEp1 bHkgMjAgMjAxNyk8YnI+DQo8YnI+DQo9PSBJbXBsZW1lbnRlZCBGZWF0dXJlcyA9PTxicj4NCjxi cj4NCnx8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IHx8PGJyPg0KSlVOT1MmbmJzcDsgJm5ic3A7fHwmbmJzcDsgSU9TIFhS Jm5ic3A7ICZuYnNwOyB8fCBIdWF3ZWkgfHwgU1JPUyB8fDxicj4NCnx8IEFsbG93cyB0byBzZXQg SUdQIGxvY2F0aW9uIHBlciBlbnRpcmUgUlIgaW5zdGFuY2UmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8fDxicj4NClllcyZuYnNw OyAmbmJzcDsgfHwmbmJzcDsgJm5ic3A7IFllcyZuYnNwOyAmbmJzcDsgJm5ic3A7fHwmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgfHwgWWVzJm5ic3A7IHx8PGJyPg0KfHwgQWxsb3dzIHRvIHNl dCBJR1AgbG9jYXRpb24gcGVyIHVwZGF0ZS9wZWVyIGdyb3VwJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fHw8YnI+DQpZ ZXMmbmJzcDsgJm5ic3A7IHx8Jm5ic3A7ICZuYnNwO1llcyZuYnNwOyAmbmJzcDsgJm5ic3A7IHx8 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHx8IFllcyZuYnNwOyB8fDxicj4NCnx8IEFsbG93 cyB0byBzZXQgSUdQIGxvY2F0aW9uIHBlciBpbmRpdmlkdWFsIHBlZXImbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7fHw8YnI+DQooMSkmbmJzcDsgJm5ic3A7IHx8Jm5ic3A7ICZuYnNwOyBZZXMmbmJzcDsgJm5i c3A7ICZuYnNwO3x8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHx8IFllcyZuYnNwOyB8fDxi cj4NCnx8IEFsbG93cyBmb3IgcG9saWN5IGNvbmZpZ3VyYXRpb24gb24gYSBwZXIgY2xpZW50IGJh c2lzJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHx8PGJy Pg0KKDEpJm5ic3A7ICZuYnNwOyB8fCZuYnNwOyAmbmJzcDsgWWVzJm5ic3A7ICZuYnNwOyAmbmJz cDt8fCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8fCBZZXMmbmJzcDsgfHw8YnI+DQp8fCBB bGxvd3MgZm9yIElHUCBiYXNlZCAmYW1wOyBwb2xpY3kgYmFzZWQgcGF0aCBzZWxlY3Rpb24mbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O3x8PGJyPg0KWWVzJm5ic3A7ICZuYnNwOyB8fCZuYnNwOyAmbmJzcDsgWWVzJm5ic3A7ICZuYnNw OyAmbmJzcDt8fCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8fCBZZXMmbmJzcDsgfHw8YnI+ DQp8fCBBbGxvd3MgdG8gY29uZmlndXJlIGJhY2t1cCBJR1AgbG9jYXRpb24mbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHx8PGJyPg0KWWVzJm5ic3A7ICZuYnNwOyB8fCZu YnNwOyBZZXMmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8fCZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyB8fCBZZXMmbmJzcDsgfHw8YnI+DQp8fCBTdXBwb3J0cyBjby1leGlzdGVuY2Ugd2l0 aCBhZGQtcGF0aHMmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDt8fDxicj4NClllcyZuYnNwOyAmbmJzcDsgfHwmbmJzcDsgJm5ic3A7WWVzJm5ic3A7 ICZuYnNwOyAmbmJzcDsgfHwmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfHwgWWVzJm5ic3A7 IHx8PGJyPg0KPGJyPg0KKDEpIC0gSlVOT1Mgc3VwcG9ydHMgcGVyIHBlZXIgSUdQIGxvY2F0aW9u IG9yIHBvbGljeSB3aGVuIHBlZXIgaXMgYWxvbmUgaW4gYTxicj4NCnBlZXIgZ3JvdXAuPGJyPg0K PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQpJZHIgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOklkckBpZXRmLm9yZyI+SWRy QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaWRyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pZHI8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_C43F534CEEDB41EEB3F7628A64CF6946nokiacom_-- From nobody Thu Jul 20 01:31:07 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB54129A96 for ; Thu, 20 Jul 2017 01:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 IQ03BXXoRbkI for ; Thu, 20 Jul 2017 01:31:03 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id CC347127337 for ; Thu, 20 Jul 2017 01:31:03 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id E344A1E37E; Thu, 20 Jul 2017 04:40:42 -0400 (EDT) Date: Thu, 20 Jul 2017 04:40:42 -0400 From: Jeffrey Haas To: Alexander Azimov Cc: idr wg Message-ID: <20170720084042.GN24942@pfrc.org> References: <20170720082724.GM24942@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Idr] IETF 99 - code point management X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:31:05 -0000 Alexander, On Thu, Jul 20, 2017 at 11:27:06AM +0300, Alexander Azimov wrote: > Thank you for sharing these links. > My question was not only about path attributes, what if one need > capability/notification codes? Capabilities have FCFS defined: https://www.iana.org/assignments/capability-codes/capability-codes.xhtml Notification codes are unfortunately currently standards action: https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-parameters-4 -- Jeff From nobody Thu Jul 20 01:33:09 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2530C1317BB; Thu, 20 Jul 2017 01:33:07 -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, HTML_MESSAGE=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 CVSwSWpAJlHt; Thu, 20 Jul 2017 01:33:05 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87CC613147E; Thu, 20 Jul 2017 01:33:05 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id g6so10938314qkf.5; Thu, 20 Jul 2017 01:33:05 -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=7xoKg7fJ2uScHSd0bgFDbBOCdyAfN4rEjuH3oynE1Jw=; b=DgcCA3gW8UzIRyW5JXa/aWBzwv1foB0Gc4jdflsqWdYOtpo4RSJyhjXKggOX/Ywm6h 1BTjdXeA/odxab0dyevMCicWAVCPVIYzRS5fuqiVXp2ISSnGHfIqibfhGGGkGjdrXFE6 5onSkhIjapA5pbe4RdjtiYdZVP4/suIa56Kg7FwIR7wm24ymvlVKjbHsRqgfm+k2DT3J iIx7fhcd9k3HakyUSHIamUumd8D7eNjk3HByeniyZq5mB2dQAB9apHAsIYOCIMdPWnh9 C3JUQkPvmi36C3yb1YuzdErFWTYd3MtM7591Xd7OINITiMShE2oWt9kJveaWfwaB6UOM SMIw== 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=7xoKg7fJ2uScHSd0bgFDbBOCdyAfN4rEjuH3oynE1Jw=; b=GaveZxFJ5aMBRah7qb2xMYAM43wNAQgYustV1WZRB9g/CYRIn2XlfkVJvIEbsHLY8Y aPfkZFubHtnCLBDYLVxBsB/ObpHgDbJ8sOCeH68bvdKQS+70AfVX0Ll1LugqB3k0O52S 3g4LHM6gul7VbfnQkAswbU52+QJgv59pMWyDSRpbBTw2voFoen9wVPeTVUzmhXvKHLmZ iOu9hvIJIoIT3phUiWgBWzjPvoi/uXUEjrd2QlHTCe+BLqUqGUe8jTUC41/3Kxd3bpRV JLRfYwasNrwmZ88R8PsGtP2CGvCEIIHhhhWBh70u2eRViwBx1Dv/tzRqrI1PEXqXhfCV Nw8w== X-Gm-Message-State: AIVw111Y/RZH+KX8KiYhoc5vfknStfG/4/KfNMuZX2yBJhwtiGEPL4e4 cWyHrtQewH6shDFLbqA+DkYH0AmKcw== X-Received: by 10.55.12.4 with SMTP id 4mr3913292qkm.151.1500539584727; Thu, 20 Jul 2017 01:33:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.86.39 with HTTP; Thu, 20 Jul 2017 01:33:04 -0700 (PDT) In-Reply-To: <001c01d3012d$d55f3920$801dab60$@ndzh.com> References: <001c01d3012d$d55f3920$801dab60$@ndzh.com> From: Christopher Morrow Date: Thu, 20 Jul 2017 10:33:04 +0200 Message-ID: To: Susan Hares Cc: "idr@ietf.org List" , "grow@ietf.org grow@ietf.org" , "Alvaro Retana (aretana)" , Warren Kumari , Peter Schoenmaker Content-Type: multipart/alternative; boundary="001a114c8000eb52010554bb9861" Archived-At: Subject: Re: [Idr] Are there IDR drafts the Grow WG needs completed quickly? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:33:07 -0000 --001a114c8000eb52010554bb9861 Content-Type: text/plain; charset="UTF-8" On Thu, Jul 20, 2017 at 9:57 AM, Susan Hares wrote: > Grow and IDR groups: > > > > As the IDR co-chairs sat in the grow meeting, we heard of an IDR draft > that was so long in becoming an RFC that the Grow authors took another > approach (which was less desired). > > I'm unsure what draft this is? this might be the gshut draft? I don't believe we have other work waiting in a similar state, Peter, do any come to mind for you? > > > We would like to know what IDR drafts need to be moved forward quickly. > If you would send the name of these drafts to the chairs, it would help us > push forward these critical drafts. You can send these names in response > to this email or send a private note to the IDR chairs. > > > > Sue Hares > --001a114c8000eb52010554bb9861 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Thu, Jul 20, 2017 at 9:57 AM, Susan Hares <shares@ndzh.com> wrote:

Grow and IDR groups:

=C2=A0

As the IDR co-chairs sat = in the grow meeting, we heard of an IDR draft that was so long in becoming = an RFC that the Grow authors took another approach (which was less desired)= .=C2=A0


I'm unsure what draft this is? this might= be the gshut draft?
I don't believe we have other work waiti= ng in a similar state, Peter, do any come to mind for you?
=C2=A0=

=C2=A0

We would like to know wha= t IDR drafts need to be moved forward quickly.=C2=A0 If you would send the = name of these drafts to the chairs, it would help us push forward these cri= tical drafts.=C2=A0 You can send these names in response to this email or s= end a private note to the IDR chairs.

=C2=A0

Sue Hares<= /p>


--001a114c8000eb52010554bb9861-- From nobody Thu Jul 20 01:37:03 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C44131BF4 for ; Thu, 20 Jul 2017 01:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] 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 2wJ5xY4WhmZv for ; Thu, 20 Jul 2017 01:37:00 -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 047D713157A for ; Thu, 20 Jul 2017 01:36:59 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=31.133.141.64; From: "Susan Hares" To: "'Henderickx, Wim \(Nokia - BE/Antwerp\)'" , Cc: References: In-Reply-To: Date: Thu, 20 Jul 2017 04:14:26 -0400 Message-ID: <003701d30130$350367f0$9f0a37d0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKI+ngt4huVyWVtssCSe6xoZQFyi6DwawIA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] ORR implementation report X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:37:02 -0000 Wim: If you have a datatracker account, you can update the wiki. However, I will be glad to update the wiki for you later in the day. Sue -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Henderickx, Wim (Nokia - BE/Antwerp) Sent: Thursday, July 20, 2017 4:18 AM To: robert@raszuk.net Cc: idr@ietf.org Subject: [Idr] ORR implementation report Can we update the ORR implementation report on the IDR Wiki? Attached the updated text = Implementations of draft-ietf-idr-bgp-optimal-route-reflection = == Known Implementations == * JUNOS (reported by Kevin F. Wang on May 22 2017) * Cisco IOS XR (reported by ) * Huawei (reported by ) * FRR (reported by ) * BIRD (reported by ) * SROS (reported by Wim Henderickx/Adam Simpson on July 20 2017) == Implemented Features == || || JUNOS || IOS XR || Huawei || SROS || || Allows to set IGP location per entire RR instance || Yes || Yes || || Yes || || Allows to set IGP location per update/peer group || Yes || Yes || || Yes || || Allows to set IGP location per individual peer || (1) || Yes || || Yes || || Allows for policy configuration on a per client basis || (1) || Yes || || Yes || || Allows for IGP based & policy based path selection || Yes || Yes || || Yes || || Allows to configure backup IGP location || Yes || Yes || || Yes || || Supports co-existence with add-paths || Yes || Yes || || Yes || (1) - JUNOS supports per peer IGP location or policy when peer is alone in a peer group. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Thu Jul 20 01:41:09 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F2C312F287; Thu, 20 Jul 2017 01:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 NPhp8YNgalqB; Thu, 20 Jul 2017 01:41:06 -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 88B3112ECC3; Thu, 20 Jul 2017 01:41:06 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=31.133.141.64; From: "Susan Hares" To: "'Christopher Morrow'" Cc: , References: <001c01d3012d$d55f3920$801dab60$@ndzh.com> In-Reply-To: Date: Thu, 20 Jul 2017 04:35:04 -0400 Message-ID: <008001d30133$16b7cae0$442760a0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0081_01D30111.8FA98640" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE1HBtGRW8wMtBhjg9X2oQYXEAYSQKRllTpo4Of9IA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] Are there IDR drafts the Grow WG needs completed quickly? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:41:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0081_01D30111.8FA98640 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Chris:=20 =20 Yes =E2=80=93 it is gshust.=20 Please see slide 3 of the gshut presentation.=20 =20 Waiting for the dependency on a draft=20 - Draft-ietf-idr-reserved-extended-communities - Draft-ietf-idr-as4octet-exztcomm-generic-subtype=20 =20 We will do early allocation of code points for any draft adopted by IDR. = Either the authors or another WG can asked us to do these early code = point allocation.=20 =20 See=20 =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Christopher Morrow Sent: Thursday, July 20, 2017 4:33 AM To: Susan Hares Cc: idr@ietf.org List; grow@ietf.org grow@ietf.org Subject: Re: [Idr] Are there IDR drafts the Grow WG needs completed = quickly? =20 =20 On Thu, Jul 20, 2017 at 9:57 AM, Susan Hares wrote: Grow and IDR groups:=20 =20 As the IDR co-chairs sat in the grow meeting, we heard of an IDR draft = that was so long in becoming an RFC that the Grow authors took another = approach (which was less desired). =20 =20 I'm unsure what draft this is? this might be the gshut draft? I don't believe we have other work waiting in a similar state, Peter, do = any come to mind for you? =20 =20 We would like to know what IDR drafts need to be moved forward quickly. = If you would send the name of these drafts to the chairs, it would help = us push forward these critical drafts. You can send these names in = response to this email or send a private note to the IDR chairs.=20 =20 Sue Hares =20 ------=_NextPart_000_0081_01D30111.8FA98640 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Chris:

 

Yes =E2=80=93 it is gshust.

Please see slide 3 of the gshut presentation. =

=C2=A0=C2=A0

Waiting for the dependency on a draft

-          = Draft-ietf-idr-reserved-extended-communities

-          = Draft-ietf-idr-as4octet-exztcomm-generic-subtype =

 

We will do early allocation of code points for any draft adopted by = IDR.=C2=A0=C2=A0 Either the authors or another WG can asked us to do = these early code point allocation.

 

See

 

From:= = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Christopher = Morrow
Sent: Thursday, July 20, 2017 4:33 AM
To: = Susan Hares
Cc: idr@ietf.org List; grow@ietf.org = grow@ietf.org
Subject: Re: [Idr] Are there IDR drafts the Grow = WG needs completed quickly?

 

 

On Thu, = Jul 20, 2017 at 9:57 AM, Susan Hares <shares@ndzh.com> = wrote:

Grow and = IDR groups:

 <= /o:p>

As the IDR = co-chairs sat in the grow meeting, we heard of an IDR draft that was so = long in becoming an RFC that the Grow authors took another approach = (which was less desired). 

 

I'm unsure what draft this is? this might be the gshut = draft?

I don't believe we = have other work waiting in a similar state, Peter, do any come to mind = for you?

 

 <= /o:p>

We would = like to know what IDR drafts need to be moved forward quickly.  If = you would send the name of these drafts to the chairs, it would help us = push forward these critical drafts.  You can send these names in = response to this email or send a private note to the IDR chairs. =

 <= /o:p>

Sue = Hares

 

------=_NextPart_000_0081_01D30111.8FA98640-- From nobody Thu Jul 20 01:42:20 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9D1C129B7F for ; Thu, 20 Jul 2017 01:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] autolearn=unavailable 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 nVTmMskcwuBK for ; Thu, 20 Jul 2017 01:42:10 -0700 (PDT) Received: from mail-wr0-f173.google.com (mail-wr0-f173.google.com [209.85.128.173]) (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 7FF7B129B40 for ; Thu, 20 Jul 2017 01:42:10 -0700 (PDT) Received: by mail-wr0-f173.google.com with SMTP id f21so11262591wrf.5 for ; Thu, 20 Jul 2017 01:42:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=e5oFQaQX4YvZH7eftwlRZOUZqUwuTYoJahJWnHKpq8Q=; b=LfTVamqtXV3gbfIW8ExCzzlm5H2CTpMpICcWCPG4dAR3Q/uzm6lWIu9ruxSqtXEkb0 V/GtdxgooH9FIZ39S9ANM5psuqSFss20fk1imWirihLjKzoGa1JRZLcpYsPA8WEmP2In FZRGjkvqsuU3UA8YNlp50XlthVZanpqcZq+n3/31zx1tsd4piBbpVPah4vN/J0MPJxUq 4NMEkDS0LFhSMBRXqmzWges0iob87sc9tGYQ61lhjanfOKJZJKwo3WZkX3IQXM2HSdG/ 1OsKClwpCgCKkq5xfErpiN98z4cmJ8/EfmT/m+/xMCdDopNesYd1ljouURDA6lFiSySU SgpQ== X-Gm-Message-State: AIVw111+1X0saJK3X61NVfeDNW2PtH1/JfTXl/SMbXkKbBTmz72eI8mz DWTWnk8XJ7TSI5sQ X-Received: by 10.223.136.212 with SMTP id g20mr6364952wrg.96.1500540128823; Thu, 20 Jul 2017 01:42:08 -0700 (PDT) Received: from localhost ([2001:67c:370:128:454f:4:b926:9a31]) by smtp.gmail.com with ESMTPSA id 93sm3748771wra.82.2017.07.20.01.42.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jul 2017 01:42:07 -0700 (PDT) Date: Thu, 20 Jul 2017 10:42:07 +0200 From: Job Snijders To: Christopher Morrow Cc: Susan Hares , "idr@ietf.org List" , "grow@ietf.org grow@ietf.org" Message-ID: <20170720084207.aprg44zv26y5wo3y@Vurt.local> References: <001c01d3012d$d55f3920$801dab60$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: NeoMutt/20170609 (1.8.3) Archived-At: Subject: Re: [Idr] Are there IDR drafts the Grow WG needs completed quickly? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:42:13 -0000 On Thu, Jul 20, 2017 at 10:33:04AM +0200, Christopher Morrow wrote: > On Thu, Jul 20, 2017 at 9:57 AM, Susan Hares wrote: > > As the IDR co-chairs sat in the grow meeting, we heard of an IDR > > draft that was so long in becoming an RFC that the Grow authors took > > another approach (which was less desired). > > I'm unsure what draft this is? this might be the gshut draft? GROW's draft-ietf-grow-bgp-gshut had a dependency on draft-ietf-idr-reserved-extended-communities which related to draft-ietf-idr-as4octet-extcomm-generic-subtype - eventually this was resolved by just working with RFC 1997 well-known communities. Kind regards, Job From nobody Thu Jul 20 01:59:08 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C13C12ECCB; Thu, 20 Jul 2017 01:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] 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 oQOvP7np7QVw; Thu, 20 Jul 2017 01:59:05 -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 0D92B129B40; Thu, 20 Jul 2017 01:59:04 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=31.133.141.64; From: "Susan Hares" To: "'Job Snijders'" , "'Christopher Morrow'" Cc: , References: <001c01d3012d$d55f3920$801dab60$@ndzh.com> <20170720084207.aprg44zv26y5wo3y@Vurt.local> In-Reply-To: <20170720084207.aprg44zv26y5wo3y@Vurt.local> Date: Thu, 20 Jul 2017 04:52:58 -0400 Message-ID: <008d01d30135$96c3b8a0$c44b29e0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE1HBtGRW8wMtBhjg9X2oQYXEAYSQKRllTpAUp6yWqjeVHoAA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] Are there IDR drafts the Grow WG needs completed quickly? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:59:07 -0000 Job: If this solution was good was the best solution, there is no further work. If this solution was due to the slow progress of IDR, I'd like to know. We've been trying to fast track all operator needs. Sue -----Original Message----- From: Job Snijders [mailto:job@ntt.net] Sent: Thursday, July 20, 2017 4:42 AM To: Christopher Morrow Cc: Susan Hares; idr@ietf.org List; grow@ietf.org grow@ietf.org Subject: Re: [Idr] Are there IDR drafts the Grow WG needs completed quickly? On Thu, Jul 20, 2017 at 10:33:04AM +0200, Christopher Morrow wrote: > On Thu, Jul 20, 2017 at 9:57 AM, Susan Hares wrote: > > As the IDR co-chairs sat in the grow meeting, we heard of an IDR > > draft that was so long in becoming an RFC that the Grow authors took > > another approach (which was less desired). > > I'm unsure what draft this is? this might be the gshut draft? GROW's draft-ietf-grow-bgp-gshut had a dependency on draft-ietf-idr-reserved-extended-communities which related to draft-ietf-idr-as4octet-extcomm-generic-subtype - eventually this was resolved by just working with RFC 1997 well-known communities. Kind regards, Job From nobody Thu Jul 20 02:10:04 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73AC3129562 for ; Thu, 20 Jul 2017 02:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] autolearn=unavailable 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 EpMi56w3bHwM for ; Thu, 20 Jul 2017 02:09:55 -0700 (PDT) Received: from mail-wr0-f175.google.com (mail-wr0-f175.google.com [209.85.128.175]) (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 953DE127735 for ; Thu, 20 Jul 2017 02:09:55 -0700 (PDT) Received: by mail-wr0-f175.google.com with SMTP id k71so14572249wrc.2 for ; Thu, 20 Jul 2017 02:09:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=IclfP/XHbeUE9MFFj7uM+QrLXBNE/qRdn629m0/7VmQ=; b=Hmccl8amBKq738SokW7FLNROYohJoTCZAbpopxfnfLqoKoP9scWCN4C347oyRsfOGa tE0oJ6EXLzGMk1ncQGJw/We56jZYSidx1IjUzXXE5FzYir0U/t3Q9I6ybtP2hXOihaRb RK0QfIX+HeCDWkUlWeE1xhAPjvedQiWp+DgQ6mTU6BhqqXZ5aYBHHlXcP5FOTDksEsvx bGh2HkWjrIJY18p7VZjpqn888GSk3aVEm3u9FsypeSRu5ueOhNtIZAD/EhpCDiMPS8EU nlc5mKKh20zldZrgK33+6y30CDbhjXT4JO8Oakd0kdvHjIG2uYtCI/6XsIgCslxidQ+x 9e+A== X-Gm-Message-State: AIVw111zMq4FTAvTMyA4In6849F0mfdlLDNl9DtJkAjARmPCB1Slxhcx d/T7crIP3QNjQdH8zM2kCg== X-Received: by 10.223.147.99 with SMTP id 90mr6600514wro.70.1500541794061; Thu, 20 Jul 2017 02:09:54 -0700 (PDT) Received: from localhost ([2001:67c:370:128:454f:4:b926:9a31]) by smtp.gmail.com with ESMTPSA id n87sm2045726wmi.47.2017.07.20.02.09.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jul 2017 02:09:53 -0700 (PDT) Date: Thu, 20 Jul 2017 11:09:51 +0200 From: Job Snijders To: Susan Hares Cc: 'Christopher Morrow' , idr@ietf.org, grow@ietf.org Message-ID: <20170720090951.q3cxenjxxbqtq2ms@Vurt.local> References: <001c01d3012d$d55f3920$801dab60$@ndzh.com> <20170720084207.aprg44zv26y5wo3y@Vurt.local> <008d01d30135$96c3b8a0$c44b29e0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <008d01d30135$96c3b8a0$c44b29e0$@ndzh.com> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: NeoMutt/20170609 (1.8.3) Archived-At: Subject: Re: [Idr] Are there IDR drafts the Grow WG needs completed quickly? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 09:09:57 -0000 On Thu, Jul 20, 2017 at 04:52:58AM -0400, Susan Hares wrote: > If this solution was good was the best solution, there is no further > work. Correct. Upon further discussion in GROW, consensus seems to be that the transitive nature of the GRACEFUL_SHUTDOWN signal is a feature, not a bug. There is no IDR blocker for draft-ietf-grow-bgp-gshut to proceed. However, somewhere in the future it might be useful to have the ability to assign functions to well-known non-transitive extended community values. So while we may not need draft-ietf-idr-reserved-extended-communities today, it might be useful tomorrow - moving draft-ietf-idr-reserved-extended-communities forward might be a good thing. > If this solution was due to the slow progress of IDR, I'd like to > know. > We've been trying to fast track all operator needs. I appreciate that - and I think the approach is working. Kind regards, Job From nobody Thu Jul 20 02:14:25 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E308313157A; Thu, 20 Jul 2017 02:14:21 -0700 (PDT) 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, 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 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 YB6ms2uEmWZG; Thu, 20 Jul 2017 02:14:19 -0700 (PDT) Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-oln040092009011.outbound.protection.outlook.com [40.92.9.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B845E126B72; Thu, 20 Jul 2017 02:14:18 -0700 (PDT) Received: from BN3NAM04FT010.eop-NAM04.prod.protection.outlook.com (10.152.92.53) by BN3NAM04HT091.eop-NAM04.prod.protection.outlook.com (10.152.93.232) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1240.9; Thu, 20 Jul 2017 09:14:17 +0000 Received: from DM5PR01MB2313.prod.exchangelabs.com (10.152.92.52) by BN3NAM04FT010.mail.protection.outlook.com (10.152.92.117) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.9 via Frontend Transport; Thu, 20 Jul 2017 09:14:17 +0000 Received: from DM5PR01MB2313.prod.exchangelabs.com ([10.168.103.143]) by DM5PR01MB2313.prod.exchangelabs.com ([10.168.103.143]) with mapi id 15.01.1261.024; Thu, 20 Jul 2017 09:14:17 +0000 From: Peter Schoenmaker To: 'Christopher Morrow' , Susan Hares CC: "idr@ietf.org" , "grow@ietf.org" Thread-Topic: [Idr] Are there IDR drafts the Grow WG needs completed quickly? Thread-Index: AdMBLOaq+/KFSWnRRPS4KR4Vb33hggABedUAAAAR4gAAAV2VAA== Date: Thu, 20 Jul 2017 09:14:16 +0000 Message-ID: References: <001c01d3012d$d55f3920$801dab60$@ndzh.com> <008001d30133$16b7cae0$442760a0$@ndzh.com> In-Reply-To: <008001d30133$16b7cae0$442760a0$@ndzh.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=lugs.com; x-incomingtopheadermarker: OriginalChecksum:98C9A6EE7794FEAC6BC165CC925D05AE5786970F864E6565F98A2D055F71B819; UpperCasedChecksum:74A8E859DC431E686FE15CF75B886376B5548DBD13088109B062ED60843C45F0; SizeAsReceived:7373; Count:46 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [7LtgPRXVGd/wKk0HRqDFZsMNfMCIZAaN] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3NAM04HT091; 7:T4K8kDhZ7S2CIumHPGYRahv05VnjSvmJtf/6A3QL3IkvE9E72kIVF/mWkA6+QCPc/D/0YYaV/m31G6OFWvLacCFgJshcQuY8BwwOcb9221mEStEk5D5x73UyXL9O+wKyB4L/UYBpOASBwpjNxYgD4fY03Ki4uZasvF1m5rgeJb43xDtskUQBfn6aX+o0lfCrId5aVr0V2vbRvMCDQrgadk9VBwRrlgrftWG+e6LNaR7+RzOlIjgng9ljnXyfkDgXKnbAHVLodait4M7dLQZFAZHuDG3AHhUDIO/dKYdVQJt3WLjlzBg53SAgvADnOAao3Zo//ncC2fETC5116Xcp0Rka2y+JghPjCqEe5u7Td3QW1yYLF6xAErCCw6iQEWNQZUsRNJnGuQYjWsROlW3RWMqdcIJtLtO9ox2Z6CGAgnO/b0HjGaygi4q0dHqZppZ8nthpe5BuHacgPaE8lqfsedu6bF1uAYHzJ7IxRL3NhO5qlc5grFT4kHGVp6h1ZxwAVDTFWNfkBIvS1DjBRvTeLPHbgNnasre4SqSN7AyNSO0pFyw/kxLj2yJoJCJXecbVwhEs+RdiWsnVJ4zlRFHrkTEwUk9HNS8hSoL/YvoWqRulZOFXVAQMTyTf5DQEP3QBs+HgBrF+xOYMoByaV5TPg0aIg1QKuT0poe/BB3/KMAW14OBYzPUszCNMvUOfP7sT6XXFpJ6GNERS6sTHysXNFfJE11Fb/nfOp0VWvlgDsfPuLBrm9/TI/mAHqahVXzZeSJxJDkKag1ZdgXTU8HKbdQ== x-incomingheadercount: 46 x-eopattributedmessage: 0 x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:BN3NAM04HT091; H:DM5PR01MB2313.prod.exchangelabs.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: 3d569020-ef2f-48a3-3937-08d4cf4fb202 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322350)(1601125374)(1603101448)(1701031045)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3NAM04HT091; x-ms-traffictypediagnostic: BN3NAM04HT091: x-exchange-antispam-report-test: UriScan:(236129657087228)(148574349560750)(50300203121483); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031); SRVR:BN3NAM04HT091; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3NAM04HT091; x-forefront-prvs: 0374433C81 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR01MB231347D31AF670EE303E2D75DFA70DM5PR01MB2313prod_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2017 09:14:16.9114 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3NAM04HT091 Archived-At: Subject: Re: [Idr] Are there IDR drafts the Grow WG needs completed quickly? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 09:14:22 -0000 --_000_DM5PR01MB231347D31AF670EE303E2D75DFA70DM5PR01MB2313prod_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU3VlLA0KDQpJIGRvbuKAmXQgYmVsaWV2ZSB0aGF0IHRoZXJlIGFyZSBhbnkgbW9yZSBkcmFm dHMgZGVwZW5kYW50IG9uIHdvcmsgcHJvZ3Jlc3NpbmcgdGhyb3VnaCBpZHIuDQoNCmdzaHV0IGhh ZCBhZGRpdGlvbmFsIHJlYXNvbnMgZm9yIG5vdCBwcm9ncmVzc2luZywgd2hpY2ggaGF2ZSBiZWVu IHNvbHZlZCBhbmQgbGFzdCBjYWxsIHdpbGwgYmUgaXNzdWVkLg0KDQpUaGUgZ3NodXQgZHJhZnQg aGFzIGFuIGluZm9ybWF0aXZlIHJlZmVyZW5jZSB0byBkcmFmdC1pZXRmLWlkci1iZXN0LWV4dGVy bmFsLiAgSSBzZWUgZnJvbSB0aGUgbWFpbGluZyBsaXN0IHRoZXJlIHdhcyBhIGxhc3QgY2FsbCwg YnV0IG5vIGNvbmNsdXNpb24sIGFuZCB0aGUgZHJhZnQgc3Vic2VxdWVudGx5IGV4cGlyZWQuICBJ cyB0aGVyZSBhbiBleHBlY3RhdGlvbiB0aGlzIGRyYWZ0IHdpbGwgY29udGludWUgdG8gcHJvZ3Jl c3M/DQoNCnRoYW5rcw0KDQpwZXRlcg0KDQoNCg0KT24gMjAgSnVseSAyMDE3IGF0IDEwOjQxOjIy LCBTdXNhbiBIYXJlcyAoc2hhcmVzQG5kemguY29tPG1haWx0bzpzaGFyZXNAbmR6aC5jb20+KSB3 cm90ZToNCkNocmlzOg0KDQpZZXMg4oCTIGl0IGlzIGdzaHVzdC4NClBsZWFzZSBzZWUgc2xpZGUg MyBvZiB0aGUgZ3NodXQgcHJlc2VudGF0aW9uLg0KDQoNCldhaXRpbmcgZm9yIHRoZSBkZXBlbmRl bmN5IG9uIGEgZHJhZnQNCg0KLSAgICAgICAgICBEcmFmdC1pZXRmLWlkci1yZXNlcnZlZC1leHRl bmRlZC1jb21tdW5pdGllcw0KDQotICAgICAgICAgIERyYWZ0LWlldGYtaWRyLWFzNG9jdGV0LWV4 enRjb21tLWdlbmVyaWMtc3VidHlwZQ0KDQpXZSB3aWxsIGRvIGVhcmx5IGFsbG9jYXRpb24gb2Yg Y29kZSBwb2ludHMgZm9yIGFueSBkcmFmdCBhZG9wdGVkIGJ5IElEUi4gICBFaXRoZXIgdGhlIGF1 dGhvcnMgb3IgYW5vdGhlciBXRyBjYW4gYXNrZWQgdXMgdG8gZG8gdGhlc2UgZWFybHkgY29kZSBw b2ludCBhbGxvY2F0aW9uLg0KDQpTZWUNCg0KRnJvbTogSWRyIFttYWlsdG86aWRyLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBDaHJpc3RvcGhlciBNb3Jyb3cNClNlbnQ6IFRodXJzZGF5 LCBKdWx5IDIwLCAyMDE3IDQ6MzMgQU0NClRvOiBTdXNhbiBIYXJlcw0KQ2M6IGlkckBpZXRmLm9y ZyBMaXN0OyBncm93QGlldGYub3JnIGdyb3dAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbSWRyXSBB cmUgdGhlcmUgSURSIGRyYWZ0cyB0aGUgR3JvdyBXRyBuZWVkcyBjb21wbGV0ZWQgcXVpY2tseT8N Cg0KDQpPbiBUaHUsIEp1bCAyMCwgMjAxNyBhdCA5OjU3IEFNLCBTdXNhbiBIYXJlcyA8c2hhcmVz QG5kemguY29tPG1haWx0bzpzaGFyZXNAbmR6aC5jb20+PiB3cm90ZToNCkdyb3cgYW5kIElEUiBn cm91cHM6DQoNCkFzIHRoZSBJRFIgY28tY2hhaXJzIHNhdCBpbiB0aGUgZ3JvdyBtZWV0aW5nLCB3 ZSBoZWFyZCBvZiBhbiBJRFIgZHJhZnQgdGhhdCB3YXMgc28gbG9uZyBpbiBiZWNvbWluZyBhbiBS RkMgdGhhdCB0aGUgR3JvdyBhdXRob3JzIHRvb2sgYW5vdGhlciBhcHByb2FjaCAod2hpY2ggd2Fz IGxlc3MgZGVzaXJlZCkuDQoNCkknbSB1bnN1cmUgd2hhdCBkcmFmdCB0aGlzIGlzPyB0aGlzIG1p Z2h0IGJlIHRoZSBnc2h1dCBkcmFmdD8NCkkgZG9uJ3QgYmVsaWV2ZSB3ZSBoYXZlIG90aGVyIHdv cmsgd2FpdGluZyBpbiBhIHNpbWlsYXIgc3RhdGUsIFBldGVyLCBkbyBhbnkgY29tZSB0byBtaW5k IGZvciB5b3U/DQoNCg0KV2Ugd291bGQgbGlrZSB0byBrbm93IHdoYXQgSURSIGRyYWZ0cyBuZWVk IHRvIGJlIG1vdmVkIGZvcndhcmQgcXVpY2tseS4gIElmIHlvdSB3b3VsZCBzZW5kIHRoZSBuYW1l IG9mIHRoZXNlIGRyYWZ0cyB0byB0aGUgY2hhaXJzLCBpdCB3b3VsZCBoZWxwIHVzIHB1c2ggZm9y d2FyZCB0aGVzZSBjcml0aWNhbCBkcmFmdHMuICBZb3UgY2FuIHNlbmQgdGhlc2UgbmFtZXMgaW4g cmVzcG9uc2UgdG8gdGhpcyBlbWFpbCBvciBzZW5kIGEgcHJpdmF0ZSBub3RlIHRvIHRoZSBJRFIg Y2hhaXJzLg0KDQpTdWUgSGFyZXMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCklkciBtYWlsaW5nIGxpc3QNCklkckBpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHINCg== --_000_DM5PR01MB231347D31AF670EE303E2D75DFA70DM5PR01MB2313prod_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5ib2R5e2ZvbnQtZmFtaWx5OkhlbHZl dGljYSxBcmlhbDtmb250LXNpemU6MTNweH08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgc3R5bGU9 IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0 LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyI+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21m b250IiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhLEFyaWFsO2ZvbnQtc2l6ZToxM3B4OyBj b2xvcjogcmdiYSgwLDAsMCwxLjApOyBtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IGF1dG87Ij4N CkhpIFN1ZSw8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiIHN0eWxlPSJmb250LWZh bWlseTpIZWx2ZXRpY2EsQXJpYWw7Zm9udC1zaXplOjEzcHg7IGNvbG9yOiByZ2JhKDAsMCwwLDEu MCk7IG1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogYXV0bzsiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2 IGlkPSJibG9vcF9jdXN0b21mb250IiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhLEFyaWFs O2ZvbnQtc2l6ZToxM3B4OyBjb2xvcjogcmdiYSgwLDAsMCwxLjApOyBtYXJnaW46IDBweDsgbGlu ZS1oZWlnaHQ6IGF1dG87Ij4NCkkgZG9u4oCZdCBiZWxpZXZlIHRoYXQgdGhlcmUgYXJlIGFueSBt b3JlIGRyYWZ0cyBkZXBlbmRhbnQgb24gd29yayBwcm9ncmVzc2luZyB0aHJvdWdoIGlkci48L2Rp dj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRp Y2EsQXJpYWw7Zm9udC1zaXplOjEzcHg7IGNvbG9yOiByZ2JhKDAsMCwwLDEuMCk7IG1hcmdpbjog MHB4OyBsaW5lLWhlaWdodDogYXV0bzsiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9j dXN0b21mb250IiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhLEFyaWFsO2ZvbnQtc2l6ZTox M3B4OyBjb2xvcjogcmdiYSgwLDAsMCwxLjApOyBtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IGF1 dG87Ij4NCmdzaHV0IGhhZCBhZGRpdGlvbmFsIHJlYXNvbnMgZm9yIG5vdCBwcm9ncmVzc2luZywg d2hpY2ggaGF2ZSBiZWVuIHNvbHZlZCBhbmQgbGFzdCBjYWxsIHdpbGwgYmUgaXNzdWVkLjwvZGl2 Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCIgc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGlj YSxBcmlhbDtmb250LXNpemU6MTNweDsgY29sb3I6IHJnYmEoMCwwLDAsMS4wKTsgbWFyZ2luOiAw cHg7IGxpbmUtaGVpZ2h0OiBhdXRvOyI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1 c3RvbWZvbnQiIHN0eWxlPSJtYXJnaW46IDBweDsiPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDAs IDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhLCBBcmlhbDsgZm9udC1zaXplOiAxM3B4OyI+ VGhlIGdzaHV0IGRyYWZ0IGhhcyBhbiBpbmZvcm1hdGl2ZSByZWZlcmVuY2UgdG8gZHJhZnQtPC9z cGFuPmlldGYtaWRyLWJlc3QtZXh0ZXJuYWwuICZuYnNwO0kgc2VlIGZyb20gdGhlIG1haWxpbmcg bGlzdCB0aGVyZSB3YXMgYQ0KIGxhc3QgY2FsbCwgYnV0IG5vIGNvbmNsdXNpb24sIGFuZCB0aGUg ZHJhZnQgc3Vic2VxdWVudGx5IGV4cGlyZWQuICZuYnNwO0lzIHRoZXJlIGFuIGV4cGVjdGF0aW9u IHRoaXMgZHJhZnQgd2lsbCBjb250aW51ZSB0byBwcm9ncmVzcz88L2Rpdj4NCjxkaXYgaWQ9ImJs b29wX2N1c3RvbWZvbnQiIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2EsQXJpYWw7Zm9udC1z aXplOjEzcHg7IGNvbG9yOiByZ2JhKDAsMCwwLDEuMCk7IG1hcmdpbjogMHB4OyBsaW5lLWhlaWdo dDogYXV0bzsiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250IiBzdHls ZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhLEFyaWFsO2ZvbnQtc2l6ZToxM3B4OyBjb2xvcjogcmdi YSgwLDAsMCwxLjApOyBtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IGF1dG87Ij4NCnRoYW5rczwv ZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCIgc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZl dGljYSxBcmlhbDtmb250LXNpemU6MTNweDsgY29sb3I6IHJnYmEoMCwwLDAsMS4wKTsgbWFyZ2lu OiAwcHg7IGxpbmUtaGVpZ2h0OiBhdXRvOyI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29w X2N1c3RvbWZvbnQiIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2EsQXJpYWw7Zm9udC1zaXpl OjEzcHg7IGNvbG9yOiByZ2JhKDAsMCwwLDEuMCk7IG1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDog YXV0bzsiPg0KcGV0ZXI8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiIHN0eWxlPSJm b250LWZhbWlseTpIZWx2ZXRpY2EsQXJpYWw7Zm9udC1zaXplOjEzcHg7IGNvbG9yOiByZ2JhKDAs MCwwLDEuMCk7IG1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogYXV0bzsiPg0KPGJyPg0KPC9kaXY+ DQo8ZGl2IGlkPSJibG9vcF9zaWduXzE1MDA1NDEyMDIwMzY0MTI5MjgiIGNsYXNzPSJibG9vcF9z aWduIj48L2Rpdj4NCjxicj4NCjxwIGNsYXNzPSJhaXJtYWlsX29uIj5PbiAyMCBKdWx5IDIwMTcg YXQgMTA6NDE6MjIsIFN1c2FuIEhhcmVzICg8YSBocmVmPSJtYWlsdG86c2hhcmVzQG5kemguY29t Ij5zaGFyZXNAbmR6aC5jb208L2E+KSB3cm90ZTo8L3A+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl IiBjbGFzcz0iY2xlYW5fYnEiPjxzcGFuPg0KPGRpdiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2PjwvZGl2Pg0KPGRpdj48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5DaHJpczoNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WWVzIOKAkyBpdCBpcyBnc2h1c3QuDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+UGxlYXNlIHNlZSBzbGlkZSAzIG9mIHRoZSBnc2h1dCBwcmVz ZW50YXRpb24uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJt YXJnaW4tbGVmdDoyMC4yNXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+V2FpdGluZyBmb3IgdGhlIGRlcGVuZGVuY3kgb24gYSBkcmFmdA0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVm dDoyMC4yNXB0O3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8 IS0tW2lmICFzdXBwb3J0TGlzdHNdLS0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9u dDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+ PCEtLVtlbmRpZl0tLT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ RHJhZnQtaWV0Zi1pZHItcmVzZXJ2ZWQtZXh0ZW5kZWQtY29tbXVuaXRpZXM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjIwLjI1cHQ7dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwh LS1baWYgIXN1cHBvcnRMaXN0c10tLT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250 OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48 IS0tW2VuZGlmXS0tPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5E cmFmdC1pZXRmLWlkci1hczRvY3RldC1leHp0Y29tbS1nZW5lcmljLXN1YnR5cGUNCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+V2Ugd2lsbCBkbyBlYXJseSBhbGxvY2F0aW9uIG9mIGNvZGUgcG9pbnRzIGZvciBhbnkgZHJh ZnQgYWRvcHRlZCBieSBJRFIuJm5ic3A7Jm5ic3A7IEVpdGhlciB0aGUgYXV0aG9ycyBvciBhbm90 aGVyIFdHIGNhbiBhc2tlZCB1cyB0byBkbyB0aGVzZSBlYXJseSBjb2RlIHBvaW50IGFsbG9jYXRp b24uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlNlZQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiBJZHIgW21haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBP ZiA8L2I+Q2hyaXN0b3BoZXIgTW9ycm93PGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKdWx5 IDIwLCAyMDE3IDQ6MzMgQU08YnI+DQo8Yj5Ubzo8L2I+IFN1c2FuIEhhcmVzPGJyPg0KPGI+Q2M6 PC9iPiBpZHJAaWV0Zi5vcmcgTGlzdDsgZ3Jvd0BpZXRmLm9yZyBncm93QGlldGYub3JnPGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbSWRyXSBBcmUgdGhlcmUgSURSIGRyYWZ0cyB0aGUgR3JvdyBX RyBuZWVkcyBjb21wbGV0ZWQgcXVpY2tseT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gVGh1LCBKdWwgMjAsIDIwMTcgYXQgOTo1NyBBTSwgU3VzYW4gSGFyZXMgJmx0 OzxhIGhyZWY9Im1haWx0bzpzaGFyZXNAbmR6aC5jb20iIHRhcmdldD0iX2JsYW5rIj5zaGFyZXNA bmR6aC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5Hcm93IGFuZCBJRFIgZ3JvdXBzOg0KPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5BcyB0aGUgSURSIGNvLWNoYWlycyBzYXQgaW4gdGhlIGdyb3cgbWVldGlu Zywgd2UgaGVhcmQgb2YgYW4gSURSIGRyYWZ0IHRoYXQgd2FzIHNvIGxvbmcgaW4gYmVjb21pbmcg YW4gUkZDIHRoYXQgdGhlIEdyb3cgYXV0aG9ycyB0b29rIGFub3RoZXIgYXBwcm9hY2ggKHdoaWNo IHdhcyBsZXNzIGRlc2lyZWQpLiZuYnNwOw0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdtIHVuc3VyZSB3aGF0IGRyYWZ0IHRo aXMgaXM/IHRoaXMgbWlnaHQgYmUgdGhlIGdzaHV0IGRyYWZ0PzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkb24ndCBiZWxpZXZlIHdlIGhhdmUg b3RoZXIgd29yayB3YWl0aW5nIGluIGEgc2ltaWxhciBzdGF0ZSwgUGV0ZXIsIGRvIGFueSBjb21l IHRvIG1pbmQgZm9yIHlvdT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5XZSB3b3VsZCBsaWtlIHRvIGtub3cgd2hhdCBJRFIg ZHJhZnRzIG5lZWQgdG8gYmUgbW92ZWQgZm9yd2FyZCBxdWlja2x5LiZuYnNwOyBJZiB5b3Ugd291 bGQgc2VuZCB0aGUgbmFtZSBvZiB0aGVzZSBkcmFmdHMgdG8gdGhlIGNoYWlycywgaXQgd291bGQg aGVscCB1cyBwdXNoIGZvcndhcmQgdGhlc2UgY3JpdGljYWwgZHJhZnRzLiZuYnNwOw0KIFlvdSBj YW4gc2VuZCB0aGVzZSBuYW1lcyBpbiByZXNwb25zZSB0byB0aGlzIGVtYWlsIG9yIHNlbmQgYSBw cml2YXRlIG5vdGUgdG8gdGhlIElEUiBjaGFpcnMuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPlN1ZSBIYXJlczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXyA8YnI+DQpJZHIgbWFpbGluZyBsaXN0IDxicj4NCklkckBpZXRmLm9yZyA8 YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkciA8YnI+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9zcGFuPjwvYmxvY2txdW90ZT4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DM5PR01MB231347D31AF670EE303E2D75DFA70DM5PR01MB2313prod_-- From nobody Thu Jul 20 02:24:23 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2178B131B09; Thu, 20 Jul 2017 02:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 hp-CzllfnNDa; Thu, 20 Jul 2017 02:24:13 -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 C45D4131BFF; Thu, 20 Jul 2017 02:24:08 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=31.133.141.64; From: "Susan Hares" To: "'Peter Schoenmaker'" , "'Christopher Morrow'" Cc: , References: <001c01d3012d$d55f3920$801dab60$@ndzh.com> <008001d30133$16b7cae0$442760a0$@ndzh.com> In-Reply-To: Date: Thu, 20 Jul 2017 05:18:03 -0400 Message-ID: <00cb01d30139$18542e10$48fc8a30$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CC_01D30117.91459B50" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE1HBtGRW8wMtBhjg9X2oQYXEAYSQKRllTpAd/8N54BzXbMNqNmQODw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] Are there IDR drafts the Grow WG needs completed quickly? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 09:24:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00CC_01D30117.91459B50 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Peter: =20 After discussion on the WG list, the draft-ietf-idr-best-external = decided to revise their approach. We are awaiting the authors to = indicate: a) draft is now ready for WG LC, and b) there are = implementations.=20 =20 Perhaps the authors could let you on by responding to this email.=20 =20 Sue=20 =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Peter Schoenmaker Sent: Thursday, July 20, 2017 5:14 AM To: 'Christopher Morrow'; Susan Hares Cc: idr@ietf.org; grow@ietf.org Subject: Re: [Idr] Are there IDR drafts the Grow WG needs completed = quickly? =20 Hi Sue, =20 I don=E2=80=99t believe that there are any more drafts dependant on work = progressing through idr. =20 gshut had additional reasons for not progressing, which have been solved = and last call will be issued. =20 The gshut draft has an informative reference to = draft-ietf-idr-best-external. I see from the mailing list there was a = last call, but no conclusion, and the draft subsequently expired. Is = there an expectation this draft will continue to progress? =20 thanks =20 peter =20 =20 On 20 July 2017 at 10:41:22, Susan Hares (shares@ndzh.com) wrote: Chris:=20 =20 Yes =E2=80=93 it is gshust.=20 Please see slide 3 of the gshut presentation.=20 =20 Waiting for the dependency on a draft=20 - Draft-ietf-idr-reserved-extended-communities - Draft-ietf-idr-as4octet-exztcomm-generic-subtype=20 =20 We will do early allocation of code points for any draft adopted by IDR. = Either the authors or another WG can asked us to do these early code = point allocation.=20 =20 See=20 =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Christopher Morrow Sent: Thursday, July 20, 2017 4:33 AM To: Susan Hares Cc: idr@ietf.org List; grow@ietf.org grow@ietf.org Subject: Re: [Idr] Are there IDR drafts the Grow WG needs completed = quickly? =20 =20 On Thu, Jul 20, 2017 at 9:57 AM, Susan Hares wrote: Grow and IDR groups:=20 =20 As the IDR co-chairs sat in the grow meeting, we heard of an IDR draft = that was so long in becoming an RFC that the Grow authors took another = approach (which was less desired). =20 =20 I'm unsure what draft this is? this might be the gshut draft? I don't believe we have other work waiting in a similar state, Peter, do = any come to mind for you? =20 =20 We would like to know what IDR drafts need to be moved forward quickly. = If you would send the name of these drafts to the chairs, it would help = us push forward these critical drafts. You can send these names in = response to this email or send a private note to the IDR chairs.=20 =20 Sue Hares =20 _______________________________________________=20 Idr mailing list=20 Idr@ietf.org=20 https://www.ietf.org/mailman/listinfo/idr=20 ------=_NextPart_000_00CC_01D30117.91459B50 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Peter:

 

After discussion on the WG list, the draft-ietf-idr-best-external = decided to revise their approach.=C2=A0 We are awaiting the authors to = indicate: a) draft is now ready for WG LC, and b) there are = implementations.

 

Perhaps the authors could let you on by responding to this email. =

 

Sue

 

From:= = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Peter = Schoenmaker
Sent: Thursday, July 20, 2017 5:14 = AM
To: 'Christopher Morrow'; Susan Hares
Cc: = idr@ietf.org; grow@ietf.org
Subject: Re: [Idr] Are there IDR = drafts the Grow WG needs completed = quickly?

 

Hi = Sue,

&nbs= p;

I = don=E2=80=99t believe that there are any more drafts dependant on work = progressing through idr.

&nbs= p;

gshut = had additional reasons for not progressing, which have been solved and = last call will be issued.

&nbs= p;

The gshut draft has an informative reference to draft-ietf-idr-= best-external.  I see from the mailing list there was a last call, = but no conclusion, and the draft subsequently expired.  Is there an = expectation this draft will continue to = progress?

&nbs= p;

thanks

&nbs= p;

peter

&nbs= p;

&nbs= p;

On 20 = July 2017 at 10:41:22, Susan Hares (shares@ndzh.com) = wrote:

Chris:

 

Yes =E2=80=93 it is gshust.

Please see slide 3 of the gshut presentation. =

  

Waiting for the dependency on a draft

-     &nb= sp;    Draft-ietf-idr-reserved-extended-communities

-     &nb= sp;    Draft-ietf-idr-as4octet-exztcomm-generic-subtype

 

We will do early allocation of code points for any draft adopted by = IDR.   Either the authors or another WG can asked us to do = these early code point allocation.

 

See

 

From:= = Idr [mailto:idr-bounces@ietf.org] = On Behalf Of Christopher Morrow
Sent: Thursday, July = 20, 2017 4:33 AM
To: Susan Hares
Cc: idr@ietf.org List; grow@ietf.org grow@ietf.org
Subject: Re: = [Idr] Are there IDR drafts the Grow WG needs completed = quickly?

 <= /o:p>

 <= /o:p>

On Thu, Jul = 20, 2017 at 9:57 AM, Susan Hares <shares@ndzh.com> = wrote:

Grow and = IDR groups:

 <= /o:p>

As the IDR = co-chairs sat in the grow meeting, we heard of an IDR draft that was so = long in becoming an RFC that the Grow authors took another approach = (which was less desired). 

 <= /o:p>

I'm unsure = what draft this is? this might be the gshut = draft?

I don't = believe we have other work waiting in a similar state, Peter, do any = come to mind for you?

 <= /o:p>

 <= /o:p>

We would = like to know what IDR drafts need to be moved forward quickly.  If = you would send the name of these drafts to the chairs, it would help us = push forward these critical drafts.  You can send these names in = response to this email or send a private note to the IDR chairs. =

 <= /o:p>

Sue = Hares

 <= /o:p>

_________= ______________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/m= ailman/listinfo/idr =

------=_NextPart_000_00CC_01D30117.91459B50-- From nobody Thu Jul 20 02:40:23 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B487E13157A for ; Thu, 20 Jul 2017 02:40:21 -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, HTML_MESSAGE=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 iEfN1_EcBV5G for ; Thu, 20 Jul 2017 02:40:20 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::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 28ABA12ECC3 for ; Thu, 20 Jul 2017 02:40:20 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id l81so5919608wmg.1 for ; Thu, 20 Jul 2017 02:40:20 -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=fLNFKW1wqhkpyppElB9lChfIYRJkXIPTsETEDdm7CWI=; b=NQ1FyBRWsHpdVAS6ClKeJqAQhXij9hKBopOclZmS9EhO126lMciFZyYXonqy0hAt2p 7I9W873CIcMV1jOHauGgpfLeuvdD8A7D9SOHuinSAJdp5Vaa5jEVoxSQQeN6k50DdFbY 6sZooOuPNi0nz6ohpvVEC9l7OmVuSla73wUWZvku2liIgjLCPCRp/cWiwmyXscRaOC4u JXoCnAvjlxLACHvQhsKj+7wgmY1eFU73Q+Ufb4BEM9kxK8hhGFE7bKIXua1dRNp7hbso ZYtK2bO7x9eq3vu2No07eHy+bwvSCRa0DHpRhDMwVXs0s8bHg06UL2iIjrcry2NmdjhG ALgA== 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=fLNFKW1wqhkpyppElB9lChfIYRJkXIPTsETEDdm7CWI=; b=e5ClKL++609RG2Di14+3vKoFxlq02EDBMlKouT6bBrE36ftr2Puj4avMuvwS/yoUi4 PuiD0OpC8wKFLdX2FlPqpIBLWvfbMx86GzaEDQSCLACJchD39e2ESFALTu8P+7nKiaox qN8qAyVv75x6ZHsFNT80g0NplZcJ58kRAfbnbnoyg5sNrbrROpM93kIoglIQf5v16+vi GEVAlZeGhhfKNvH7P+UcCmyMNxtDz8+cDL0LCHLwIuBUTUZ3MMGQBMwBC5Pk4fsKBTby F3SLxX/pS9UFHEm+fhJiapB87RGfpOd+ZsWiky3ExFcYCaU/gVHu7WrOJ2w87XPaJzr5 S05Q== X-Gm-Message-State: AIVw111CUB45+tPn+aaUiZhi/BmWGBmFINEvxV/Qr3SrV3IaqU5B7Lhb IUHS7NwaBMkwDE+QX6bKyR2CQswAerpn6nk= X-Received: by 10.80.142.27 with SMTP id 27mr2486047edw.104.1500543618577; Thu, 20 Jul 2017 02:40:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.138.99 with HTTP; Thu, 20 Jul 2017 02:39:38 -0700 (PDT) From: Tony Przygienda Date: Thu, 20 Jul 2017 11:39:38 +0200 Message-ID: To: idr wg Content-Type: multipart/alternative; boundary="94eb2c1980a25afae30554bc8953" Archived-At: Subject: [Idr] request for IDR working group adoption of https://tools.ietf.org/html/draft-idr-bgp-route-refresh-options-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 09:40:22 -0000 --94eb2c1980a25afae30554bc8953 Content-Type: text/plain; charset="UTF-8" The authors would like to request the adoption of https://tools.ietf.org/html/draft-idr-bgp-route-refresh-options-02 as WG item. The draft has been presented twice, good amount of work & rev'ing has been put into it and there are no major comments outstanding after presentations. We think that several ongoing BGP extension developments make it a valuable workgroup item at this point in time. All further info can be found in presentation material and the draft itself ... on behalf of other authors --- tony --94eb2c1980a25afae30554bc8953 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

The authors would like to request t= he adoption of=C2=A0


= as WG item. The draft has been presented twice, good amount of work & r= ev'ing has been put into it and there are no major comments outstanding= after presentations.=C2=A0

We think that several = ongoing BGP extension developments make it a valuable workgroup item at thi= s point in time. All further info can be found in presentation material and= the draft itself ...=C2=A0

on behalf of other aut= hors=C2=A0

--- tony=C2=A0


--94eb2c1980a25afae30554bc8953-- From nobody Thu Jul 20 02:41:17 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B77C12ECC3; Thu, 20 Jul 2017 02:41: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, 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 5cvP2Th6widD; Thu, 20 Jul 2017 02:41:13 -0700 (PDT) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::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 B51CB12FB9C; Thu, 20 Jul 2017 02:41:12 -0700 (PDT) Received: by mail-wm0-x243.google.com with SMTP id p204so2885863wmg.1; Thu, 20 Jul 2017 02:41:12 -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; bh=vfVO+W9nFPmM4NJ/ewi6QTqpKd+IV2JiqEfRPY5l/2U=; b=MTx2GgdvoQ7OggLvrs+94p2GG/MbW6isxX508x6BKexVM6Eqif/ekzNqJdTVYTgkqT wgeUX55j/H9ATubRGTu6UM9AqEQkrINSyOfzh3rQGHuOXZYdCQ+ildlZZtDGdv2VhngB i5Epxvj53CdU0Dp0jWwgbUPSGOo1bhY+N9EfIyfyLxejXvOakaZvpsvFqIhVoT9a0YXo 4kJaVOZpVqdFve0tL/dKQvVFebhxrMACbErWcFSuIDafvcvLfopYofTvA13Bor1DnZpW D44EuWbp6BWBd/qbXtws/gf5OxH3tY89tvdjN7Hqb3XT5WGC4ts24KEohCIqWPcEkzz8 B/cw== 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=vfVO+W9nFPmM4NJ/ewi6QTqpKd+IV2JiqEfRPY5l/2U=; b=X3TEWnLqesjHubnKPf/0lRxA81Gl1TdoOKOOgwW54P26cyZVD5vwOlKtMmsEn5e6rX pORY0c8kQKFfngjhdOgjjsg4eJTomnWVv+DL9cnllj61lfDO8aBEEEHE4a9PewaK2Dvj O6OFBZiI9Db+kfXKfldPLOL0LfUcOnocaj7f/ScrabERrG8b4Lx2duY3pb9nXIwh+T5f XEuNMkQjRI4EQEVrPaXxlGugx1D/+sYcraS/QajU4/wa72bPZjbkCtqcM3Xc+5zxRBIc O+kACcaXqag02YGoh8YsACf0dZUeRAMC1mvIv/d1elPP04k5qkkZ2n5RoxhYh/b18d68 VJQg== X-Gm-Message-State: AIVw110MNkgGIP3RZHBgBu+wCu8ZetzMuQDBM4AU9KH69FgyBCEjaWU9 sNfraB9Fwa1o5w== X-Received: by 10.28.4.148 with SMTP id 142mr1813248wme.9.1500543671226; Thu, 20 Jul 2017 02:41:11 -0700 (PDT) Received: from [31.133.131.152] ([2001:67c:370:128:acfb:d024:ad48:24b2]) by smtp.gmail.com with ESMTPSA id j31sm5269180wre.67.2017.07.20.02.41.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jul 2017 02:41:10 -0700 (PDT) User-Agent: Microsoft-MacOutlook/f.24.0.170702 Date: Thu, 20 Jul 2017 11:41:09 +0200 From: Jeff Tantsura To: Susan Hares , 'Peter Schoenmaker' , 'Christopher Morrow' CC: , Message-ID: Thread-Topic: [Idr] Are there IDR drafts the Grow WG needs completed quickly? References: <001c01d3012d$d55f3920$801dab60$@ndzh.com> <008001d30133$16b7cae0$442760a0$@ndzh.com> <00cb01d30139$18542e10$48fc8a30$@ndzh.com> In-Reply-To: <00cb01d30139$18542e10$48fc8a30$@ndzh.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3583395670_1133924982" Archived-At: Subject: Re: [Idr] Are there IDR drafts the Grow WG needs completed quickly? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 09:41:15 -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_3583395670_1133924982 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Sue/ draft-ietf-idr-best-external authors, =20 Don=E2=80=99t recall call for implementations, there=E2=80=99s an implementation in Eri= csson=E2=80=99s SEOS/IPOS=20 =20 Cheers, Jeff From: Idr on behalf of Susan Hares Date: Thursday, July 20, 2017 at 11:24 To: 'Peter Schoenmaker' , 'Christopher Morrow' Cc: , Subject: Re: [Idr] Are there IDR drafts the Grow WG needs completed quickly= ? =20 Peter: =20 After discussion on the WG list, the draft-ietf-idr-best-external decided t= o revise their approach. We are awaiting the authors to indicate: a) draft = is now ready for WG LC, and b) there are implementations.=20 =20 Perhaps the authors could let you on by responding to this email.=20 =20 Sue=20 =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Peter Schoenmaker Sent: Thursday, July 20, 2017 5:14 AM To: 'Christopher Morrow'; Susan Hares Cc: idr@ietf.org; grow@ietf.org Subject: Re: [Idr] Are there IDR drafts the Grow WG needs completed quickly= ? =20 Hi Sue, =20 I don=E2=80=99t believe that there are any more drafts dependant on work progress= ing through idr. =20 gshut had additional reasons for not progressing, which have been solved an= d last call will be issued. =20 The gshut draft has an informative reference to draft-ietf-idr-best-externa= l. I see from the mailing list there was a last call, but no conclusion, an= d the draft subsequently expired. Is there an expectation this draft will c= ontinue to progress? =20 thanks =20 peter =20 =20 On 20 July 2017 at 10:41:22, Susan Hares (shares@ndzh.com) wrote: Chris:=20 =20 Yes =E2=80=93 it is gshust.=20 Please see slide 3 of the gshut presentation.=20 =20 Waiting for the dependency on a draft=20 - Draft-ietf-idr-reserved-extended-communities - Draft-ietf-idr-as4octet-exztcomm-generic-subtype=20 =20 We will do early allocation of code points for any draft adopted by IDR. = Either the authors or another WG can asked us to do these early code point a= llocation.=20 =20 See=20 =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Christopher Morrow Sent: Thursday, July 20, 2017 4:33 AM To: Susan Hares Cc: idr@ietf.org List; grow@ietf.org grow@ietf.org Subject: Re: [Idr] Are there IDR drafts the Grow WG needs completed quickly= ? =20 =20 On Thu, Jul 20, 2017 at 9:57 AM, Susan Hares wrote: Grow and IDR groups:=20 =20 As the IDR co-chairs sat in the grow meeting, we heard of an IDR draft that= was so long in becoming an RFC that the Grow authors took another approach = (which was less desired). =20 =20 I'm unsure what draft this is? this might be the gshut draft? I don't believe we have other work waiting in a similar state, Peter, do an= y come to mind for you? =20 =20 We would like to know what IDR drafts need to be moved forward quickly. If= you would send the name of these drafts to the chairs, it would help us pus= h forward these critical drafts. You can send these names in response to th= is email or send a private note to the IDR chairs.=20 =20 Sue Hares =20 _______________________________________________=20 Idr mailing list=20 Idr@ietf.org=20 https://www.ietf.org/mailman/listinfo/idr=20 _______________________________________________ Idr mailing list Idr@ietf.o= rg https://www.ietf.org/mailman/listinfo/idr=20 --B_3583395670_1133924982 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Sue/ draft-ietf-idr-best-external authors,

<= p class=3DMsoNormal> =

Don=E2=80=99t recall call for implementations, there=E2=80=99s an implementation = in Ericsson=E2=80=99s SEOS/IPOS

 

Cheers,

Jeff

F= rom: Idr <idr-bounces@ietf.org> o= n behalf of Susan Hares <shares@ndzh.com>
Date: Thursday, Ju= ly 20, 2017 at 11:24
To: 'Peter Schoenmaker' <pds@lugs.com>,= 'Christopher Morrow' <christopher.morrow@gmail.com>
Cc: <= ;idr@ietf.org>, <grow@ietf.org>
Subject: Re: [Idr] Are th= ere IDR drafts the Grow WG needs completed quickly?

 

Peter:

 

After discussion on the WG list, the draft-ietf-idr-best-external dec= ided to revise their approach.  We are awaiting the authors to indicate= : a) draft is now ready for WG LC, and b) there are implementations. =

 

Perhaps the autho= rs could let you on by responding to this email.

 

Sue

 

From: Idr [mailto:idr-bounces@ietf.org] On = Behalf Of Peter Schoenmaker
Sent: Thursday, July 20, 2017 5:14= AM
To: 'Christopher Morrow'; Susan Hares
Cc: idr@ietf.o= rg; grow@ietf.org
Subject: Re: [Idr] Are there IDR drafts the Grow= WG needs completed quickly?

 

Hi Sue,

 

I= don=E2=80=99t believe that there are any more drafts dependant on work progressin= g through idr.

 

gshut had additional reasons f= or not progressing, which have been solved and last call will be issued.

 

The gshut draft has an informative r= eference to draft-ietf-idr-best-external.  I see from the mailing list the= re was a last call, but no conclusion, and the draft subsequently expired. &= nbsp;Is there an expectation this draft will continue to progress?

 

thanks

 

<= div id=3D"bloop_customfont">

peter

 

 =

On 20 July 2017 at 1= 0:41:22, Susan Hares (shares@ndzh.com) = wrote:

Chris:

 

Yes =E2=80=93 = it is gshust.

Please see slide 3 = of the gshut presentation.

 =  

Waiting for the dependency on a draft

-<= span style=3D'font-size:7.0pt;color:#1F497D'>     &nb= sp;    Draft-ietf-idr-reserved-extended-communities<= /span>

-&nbs= p;         Draft-ietf-idr-a= s4octet-exztcomm-generic-subtype

=  

We will do early allocation= of code points for any draft adopted by IDR.   Either the authors= or another WG can asked us to do these early code point allocation. =

 

See

 

From: Idr [mailto:idr-b= ounces@ietf.org] On Behalf Of Christopher Morrow
Sent: = Thursday, July 20, 2017 4:33 AM
To: Susan Hares
Cc: idr@ietf.org List; grow@ietf.org grow@ietf.org
Subject: Re: [Idr] Are there IDR drafts the Grow WG needs completed qui= ckly?

 

 

On Thu, Jul= 20, 2017 at 9:57 AM, Susan Hares <shares@ndzh.com> wrote:

Grow and IDR groups:

 <= /o:p>

As the IDR co-chairs sat in the grow meeting, we= heard of an IDR draft that was so long in becoming an RFC that the Grow aut= hors took another approach (which was less desired). 

 

I'm unsure what draft this is? this might be the gshut draft?<= /o:p>

I don't believe we have other work wa= iting in a similar state, Peter, do any come to mind for you?

=

 

 

We would like to= know what IDR drafts need to be moved forward quickly.  If you would s= end the name of these drafts to the chairs, it would help us push forward th= ese critical drafts.  You can send these names in response to this emai= l or send a private note to the IDR chairs.

 

Sue Hares

 

_______________________________________= ________
Idr mailing list
Idr@ietf.org=
https://www.iet= f.org/mailman/listinfo/idr

__________________________________________= _____ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/id= r

--B_3583395670_1133924982-- From nobody Thu Jul 20 02:59:32 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31B2C13157A; Thu, 20 Jul 2017 02:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 VMZHKkc0Y8JH; Thu, 20 Jul 2017 02:59:22 -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 569ED1317AD; Thu, 20 Jul 2017 02:59:22 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=31.133.141.64; From: "Susan Hares" To: "'Jeff Tantsura'" , "'Peter Schoenmaker'" , "'Christopher Morrow'" Cc: , References: <001c01d3012d$d55f3920$801dab60$@ndzh.com> <008001d30133$16b7cae0$442760a0$@ndzh.com> <00cb01d30139$18542e10$48fc8a30$@ndzh.com> In-Reply-To: Date: Thu, 20 Jul 2017 05:53:15 -0400 Message-ID: <011201d3013e$02f2e7f0$08d8b7d0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0113_01D3011C.7BE2F5A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE1HBtGRW8wMtBhjg9X2oQYXEAYSQKRllTpAd/8N54BzXbMNgF23cM+Ae8ULQOjSxsJMA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] Are there IDR drafts the Grow WG needs completed quickly? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 09:59:24 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0113_01D3011C.7BE2F5A0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Thank you for reference to Ericsson=E2=80=99s implementation. Please = send me offline a contact for this implementation.=20 =20 Sue=20 =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jeff Tantsura Sent: Thursday, July 20, 2017 5:41 AM To: Susan Hares; 'Peter Schoenmaker'; 'Christopher Morrow' Cc: idr@ietf.org; grow@ietf.org Subject: Re: [Idr] Are there IDR drafts the Grow WG needs completed = quickly? =20 Sue/ draft-ietf-idr-best-external authors, =20 Don=E2=80=99t recall call for implementations, there=E2=80=99s an = implementation in Ericsson=E2=80=99s SEOS/IPOS=20 =20 Cheers, Jeff From: Idr on behalf of Susan Hares = Date: Thursday, July 20, 2017 at 11:24 To: 'Peter Schoenmaker' , 'Christopher Morrow' = Cc: , Subject: Re: [Idr] Are there IDR drafts the Grow WG needs completed = quickly? =20 Peter: =20 After discussion on the WG list, the draft-ietf-idr-best-external = decided to revise their approach. We are awaiting the authors to = indicate: a) draft is now ready for WG LC, and b) there are = implementations.=20 =20 Perhaps the authors could let you on by responding to this email.=20 =20 Sue=20 =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Peter Schoenmaker Sent: Thursday, July 20, 2017 5:14 AM To: 'Christopher Morrow'; Susan Hares Cc: idr@ietf.org; grow@ietf.org Subject: Re: [Idr] Are there IDR drafts the Grow WG needs completed = quickly? =20 Hi Sue, =20 I don=E2=80=99t believe that there are any more drafts dependant on work = progressing through idr. =20 gshut had additional reasons for not progressing, which have been solved = and last call will be issued. =20 The gshut draft has an informative reference to = draft-ietf-idr-best-external. I see from the mailing list there was a = last call, but no conclusion, and the draft subsequently expired. Is = there an expectation this draft will continue to progress? =20 thanks =20 peter =20 =20 On 20 July 2017 at 10:41:22, Susan Hares (shares@ndzh.com) wrote: Chris:=20 =20 Yes =E2=80=93 it is gshust.=20 Please see slide 3 of the gshut presentation.=20 =20 Waiting for the dependency on a draft=20 - Draft-ietf-idr-reserved-extended-communities - Draft-ietf-idr-as4octet-exztcomm-generic-subtype=20 =20 We will do early allocation of code points for any draft adopted by IDR. = Either the authors or another WG can asked us to do these early code = point allocation.=20 =20 See=20 =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Christopher Morrow Sent: Thursday, July 20, 2017 4:33 AM To: Susan Hares Cc: idr@ietf.org List; grow@ietf.org grow@ietf.org Subject: Re: [Idr] Are there IDR drafts the Grow WG needs completed = quickly? =20 =20 On Thu, Jul 20, 2017 at 9:57 AM, Susan Hares wrote: Grow and IDR groups:=20 =20 As the IDR co-chairs sat in the grow meeting, we heard of an IDR draft = that was so long in becoming an RFC that the Grow authors took another = approach (which was less desired). =20 =20 I'm unsure what draft this is? this might be the gshut draft? I don't believe we have other work waiting in a similar state, Peter, do = any come to mind for you? =20 =20 We would like to know what IDR drafts need to be moved forward quickly. = If you would send the name of these drafts to the chairs, it would help = us push forward these critical drafts. You can send these names in = response to this email or send a private note to the IDR chairs.=20 =20 Sue Hares =20 _______________________________________________=20 Idr mailing list=20 Idr@ietf.org=20 https://www.ietf.org/mailman/listinfo/idr=20 _______________________________________________ Idr mailing list = Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr=20 ------=_NextPart_000_0113_01D3011C.7BE2F5A0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Thank you for reference to Ericsson=E2=80=99s implementation.=C2=A0 = Please send me offline a contact for this implementation. =

 

Sue

 

From:= = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jeff = Tantsura
Sent: Thursday, July 20, 2017 5:41 AM
To: = Susan Hares; 'Peter Schoenmaker'; 'Christopher Morrow'
Cc: = idr@ietf.org; grow@ietf.org
Subject: Re: [Idr] Are there IDR = drafts the Grow WG needs completed = quickly?

 

Sue/ = draft-ietf-idr-best-external authors,

 

=

Don=E2=80=99t recall call = for implementations, there=E2=80=99s an implementation in = Ericsson=E2=80=99s SEOS/IPOS

 

=

Cheers,

Jeff

From: Idr = <idr-bounces@ietf.org> = on behalf of Susan Hares <shares@ndzh.com>
Date: = Thursday, July 20, 2017 at 11:24
To: 'Peter Schoenmaker' = <pds@lugs.com>, 'Christopher = Morrow' <christopher.morrow@gmail.com= >
Cc: <idr@ietf.org>, <grow@ietf.org>
Subject: = Re: [Idr] Are there IDR drafts the Grow WG needs completed = quickly?

 

Peter:

 

After discussion on the WG list, the draft-ietf-idr-best-external = decided to revise their approach.  We are awaiting the authors to = indicate: a) draft is now ready for WG LC, and b) there are = implementations.

 

Perhaps the authors could let you on by responding to this email. =

 

Sue

 

From:= = Idr [mailto:idr-bounces@ietf.org] = On Behalf Of Peter Schoenmaker
Sent: Thursday, July 20, = 2017 5:14 AM
To: 'Christopher Morrow'; Susan = Hares
Cc: idr@ietf.org; grow@ietf.org
Subject: Re: = [Idr] Are there IDR drafts the Grow WG needs completed = quickly?

 

Hi = Sue,

 

I = don=E2=80=99t believe that there are any more drafts dependant on work = progressing through idr.

 

gshut = had additional reasons for not progressing, which have been solved and = last call will be issued.

 

The gshut draft has an informative reference to draft-ietf-idr-= best-external.  I see from the mailing list there was a last call, = but no conclusion, and the draft subsequently expired.  Is there an = expectation this draft will continue to = progress?

 

thanks

 

peter

 

 

On 20 = July 2017 at 10:41:22, Susan Hares (shares@ndzh.com) = wrote:

Chris:

 

Yes =E2=80=93 it is gshust.

Please see slide 3 of the gshut presentation. =

  

Waiting for the dependency on a draft

-     &nb= sp;    Draft-ietf-idr-reserved-extended-communities

-     &nb= sp;    Draft-ietf-idr-as4octet-exztcomm-generic-subtype =

 

We will do early allocation of code points for any draft adopted by = IDR.   Either the authors or another WG can asked us to do = these early code point allocation.

 

See

 

From:= = Idr [mailto:idr-bounces@ietf.org] = On Behalf Of Christopher Morrow
Sent: Thursday, July = 20, 2017 4:33 AM
To: Susan Hares
Cc: idr@ietf.org List; grow@ietf.org grow@ietf.org
Subject: Re: = [Idr] Are there IDR drafts the Grow WG needs completed = quickly?

 

 

On Thu, Jul 20, 2017 at 9:57 AM, Susan Hares <shares@ndzh.com> = wrote:

Grow and IDR groups:

 

As the IDR co-chairs sat in the grow meeting, we heard of an IDR = draft that was so long in becoming an RFC that the Grow authors took = another approach (which was less desired).  =

 

I'm unsure what draft this is? this might be the gshut = draft?

I don't believe we have other work waiting in a similar state, = Peter, do any come to mind for you?

 

 

We would like to know what IDR drafts need to be moved forward = quickly.  If you would send the name of these drafts to the chairs, = it would help us push forward these critical drafts.  You can send = these names in response to this email or send a private note to the IDR = chairs.

 

Sue Hares

 

_________= ______________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/m= ailman/listinfo/idr =

___________= ____________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/m= ailman/listinfo/idr

------=_NextPart_000_0113_01D3011C.7BE2F5A0-- From nobody Thu Jul 20 05:37:02 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF57129AC4; Thu, 20 Jul 2017 05:36:54 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 mP86C7l6O1TC; Thu, 20 Jul 2017 05:36:46 -0700 (PDT) Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 230A3131794; Thu, 20 Jul 2017 05:36:46 -0700 (PDT) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id AB900120838; Thu, 20 Jul 2017 14:36:44 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.72]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 7FF281800E4; Thu, 20 Jul 2017 14:36:44 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541%19]) with mapi id 14.03.0352.000; Thu, 20 Jul 2017 14:36:44 +0200 From: To: Susan Hares CC: "idr@ietf.org" , "grow@ietf.org" , "'Job Snijders'" , 'Christopher Morrow' Thread-Topic: [Idr] Are there IDR drafts the Grow WG needs completed quickly? Thread-Index: AQE1HBtGRW8wMtBhjg9X2oQYXEAYSQKRllTpAUp6yWqjeVHoAIAANEkg Date: Thu, 20 Jul 2017 12:36:43 +0000 Message-ID: <27335_1500554204_5970A3DC_27335_475_1_53C29892C857584299CBF5D05346208A4781707A@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <001c01d3012d$d55f3920$801dab60$@ndzh.com> <20170720084207.aprg44zv26y5wo3y@Vurt.local> <008d01d30135$96c3b8a0$c44b29e0$@ndzh.com> In-Reply-To: <008d01d30135$96c3b8a0$c44b29e0$@ndzh.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] Are there IDR drafts the Grow WG needs completed quickly? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 12:36:54 -0000 Hi Susan, all > From Susan Hares > Sent: Thursday, July 20, 2017 10:53 AM =20 >=20 > Job: >=20 > If this solution was good was the best solution, there is no further wo= rk. =20 This is the case. =20 > If this solution was due to the slow progress of IDR, I'd like to know. > We've been trying to fast track all operator needs. As the author of the offending sentence/slide and co-author of the g-shut d= ocument, I can assure you that I had zero (b) intention to put the responsi= bility on IDR or on an IDR draft (a). I'm sorry if it felt that way. --Bruno (a) Plus being an author of draft-ietf-idr-reserved-extended-communities, I= would have been the one to blame. (b) zero as per https://en.wikipedia.org/wiki/0 not as per https://en.wikip= edia.org/wiki/Zero-point_energy >=20 > Sue >=20 > -----Original Message----- > From: Job Snijders [mailto:job@ntt.net] > Sent: Thursday, July 20, 2017 4:42 AM > To: Christopher Morrow > Cc: Susan Hares; idr@ietf.org List; grow@ietf.org grow@ietf.org > Subject: Re: [Idr] Are there IDR drafts the Grow WG needs completed quic= kly? >=20 > On Thu, Jul 20, 2017 at 10:33:04AM +0200, Christopher Morrow wrote: > > On Thu, Jul 20, 2017 at 9:57 AM, Susan Hares wrote: > > > As the IDR co-chairs sat in the grow meeting, we heard of an IDR > > > draft that was so long in becoming an RFC that the Grow authors took > > > another approach (which was less desired). > > > > I'm unsure what draft this is? this might be the gshut draft? >=20 > GROW's draft-ietf-grow-bgp-gshut had a dependency on > draft-ietf-idr-reserved-extended-communities which related to > draft-ietf-idr-as4octet-extcomm-generic-subtype - eventually this was > resolved by just working with RFC 1997 well-known communities. >=20 > Kind regards, >=20 > Job >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Jul 20 05:50:55 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C29B129B43; Thu, 20 Jul 2017 05:50:53 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 8p-r--pdU8R5; Thu, 20 Jul 2017 05:50:51 -0700 (PDT) Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72707126E3A; Thu, 20 Jul 2017 05:50:51 -0700 (PDT) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 4847EC04E0; Thu, 20 Jul 2017 14:50:50 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.21]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 231B8180097; Thu, 20 Jul 2017 14:50:50 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM6C.corporate.adroot.infra.ftgroup ([fe80::d9f5:9741:7525:a199%18]) with mapi id 14.03.0352.000; Thu, 20 Jul 2017 14:50:49 +0200 From: To: Susan Hares CC: "idr@ietf.org" , "grow@ietf.org" , "Job Snijders" Thread-Topic: [GROW] [Idr] Are there IDR drafts the Grow WG needs completed quickly? Thread-Index: AQHTATf4KB7gxu6ZIkKI9bwZhjpvAKJcp1RA Date: Thu, 20 Jul 2017 12:50:48 +0000 Message-ID: <23449_1500555050_5970A72A_23449_327_1_53C29892C857584299CBF5D05346208A478172D3@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <001c01d3012d$d55f3920$801dab60$@ndzh.com> <20170720084207.aprg44zv26y5wo3y@Vurt.local> <008d01d30135$96c3b8a0$c44b29e0$@ndzh.com> <20170720090951.q3cxenjxxbqtq2ms@Vurt.local> In-Reply-To: <20170720090951.q3cxenjxxbqtq2ms@Vurt.local> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] [GROW] Are there IDR drafts the Grow WG needs completed quickly? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 12:50:53 -0000 Susan, all > From: Job Snijders > Sent: Thursday, July 20, 2017 11:10 AM >=20 > On Thu, Jul 20, 2017 at 04:52:58AM -0400, Susan Hares wrote: > > If this solution was good was the best solution, there is no further > > work. >=20 > Correct. Upon further discussion in GROW, consensus seems to be that the > transitive nature of the GRACEFUL_SHUTDOWN signal is a feature, not a > bug. There is no IDR blocker for draft-ietf-grow-bgp-gshut to proceed. +1 =20 > However, somewhere in the future it might be useful to have the ability > to assign functions to well-known non-transitive extended community > values. +1 I would personally put it a bit more strongly: IMHO it would be useful to h= ave non-transitive (well-known) communities. > So while we may not need > draft-ietf-idr-reserved-extended-communities today, it might be useful > tomorrow - moving draft-ietf-idr-reserved-extended-communities > forward might be a good thing. =20 Or another draft/solution providing the feature. (Note: being a co-author of that draft, this is not a political statement t= o push my/other solution.) =20 > > If this solution was due to the slow progress of IDR, I'd like to > > know. > > We've been trying to fast track all operator needs. >=20 > I appreciate that - and I think the approach is working. =20 +1 Kind regards, --Bruno =20 > Kind regards, >=20 > Job >=20 > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Jul 20 07:13:07 2017 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B22E6120227; Thu, 20 Jul 2017 07:12:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150055997058.22508.16867893224795306888@ietfa.amsl.com> Date: Thu, 20 Jul 2017 07:12:50 -0700 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-segment-routing-te-policy-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 14:12:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing WG of the IETF. Title : Advertising Segment Routing Policies in BGP Authors : Stefano Previdi Clarence Filsfils Paul Mattes Eric Rosen Steven Lin Filename : draft-ietf-idr-segment-routing-te-policy-00.txt Pages : 30 Date : 2017-07-20 Abstract: This document defines a new BGP SAFI with a new NLRI in order to advertise a candidate path of a Segment Routing Policy (SR Policy). An SR Policy is a set of candidate paths consisting of one or more segment lists. The headend of an SR Policy may learn multiple candidate paths for an SR Policy. Candidate paths may be learned via a number of different mechanisms, e.g., CLI, NetConf, PCEP, or BGP. This document specifies the way in which BGP may be used to distribute candidate paths. New sub-TLVs for the Tunnel Encapsulation Attribute are defined. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-segment-routing-te-policy/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-00 https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy-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 Thu Jul 20 07:22:03 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F36C412704A; Thu, 20 Jul 2017 07:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] 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 baxK3DykzGHF; Thu, 20 Jul 2017 07:21: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 3C56C129B62; Thu, 20 Jul 2017 07:21:55 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=31.133.141.64; From: "Susan Hares" To: Cc: , , "'Job Snijders'" , "'Christopher Morrow'" References: <001c01d3012d$d55f3920$801dab60$@ndzh.com> <20170720084207.aprg44zv26y5wo3y@Vurt.local> <008d01d30135$96c3b8a0$c44b29e0$@ndzh.com> <27335_1500554204_5970A3DC_27335_475_1_53C29892C857584299CBF5D05346208A4781707A@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <27335_1500554204_5970A3DC_27335_475_1_53C29892C857584299CBF5D05346208A4781707A@OPEXCLILM21.corporate.adroot.infra.ftgroup> Date: Thu, 20 Jul 2017 10:15:46 -0400 Message-ID: <008601d30162$af792010$0e6b6030$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE1HBtGRW8wMtBhjg9X2oQYXEAYSQKRllTpAUp6yWoC/6l8jwIemnWjo1C6UHA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] Are there IDR drafts the Grow WG needs completed quickly? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 14:21:57 -0000 Bruno: Thank you for letting John and I know you found the best solution. Sue Hares -----Original Message----- From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] Sent: Thursday, July 20, 2017 8:37 AM To: Susan Hares Cc: idr@ietf.org; grow@ietf.org; 'Job Snijders'; 'Christopher Morrow' Subject: RE: [Idr] Are there IDR drafts the Grow WG needs completed quickly? Hi Susan, all > From Susan Hares > Sent: Thursday, July 20, 2017 10:53 AM > > Job: > > If this solution was good was the best solution, there is no further work. This is the case. > If this solution was due to the slow progress of IDR, I'd like to know. > We've been trying to fast track all operator needs. As the author of the offending sentence/slide and co-author of the g-shut document, I can assure you that I had zero (b) intention to put the responsibility on IDR or on an IDR draft (a). I'm sorry if it felt that way. --Bruno (a) Plus being an author of draft-ietf-idr-reserved-extended-communities, I would have been the one to blame. (b) zero as per https://en.wikipedia.org/wiki/0 not as per https://en.wikipedia.org/wiki/Zero-point_energy > > Sue > > -----Original Message----- > From: Job Snijders [mailto:job@ntt.net] > Sent: Thursday, July 20, 2017 4:42 AM > To: Christopher Morrow > Cc: Susan Hares; idr@ietf.org List; grow@ietf.org grow@ietf.org > Subject: Re: [Idr] Are there IDR drafts the Grow WG needs completed quickly? > > On Thu, Jul 20, 2017 at 10:33:04AM +0200, Christopher Morrow wrote: > > On Thu, Jul 20, 2017 at 9:57 AM, Susan Hares wrote: > > > As the IDR co-chairs sat in the grow meeting, we heard of an IDR > > > draft that was so long in becoming an RFC that the Grow authors took > > > another approach (which was less desired). > > > > I'm unsure what draft this is? this might be the gshut draft? > > GROW's draft-ietf-grow-bgp-gshut had a dependency on > draft-ietf-idr-reserved-extended-communities which related to > draft-ietf-idr-as4octet-extcomm-generic-subtype - eventually this was > resolved by just working with RFC 1997 well-known communities. > > Kind regards, > > Job > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr ____________________________________________________________________________ _____________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From nobody Thu Jul 20 07:46:28 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 077EC131C84 for ; Thu, 20 Jul 2017 07:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 jkkTuchVrHjA for ; Thu, 20 Jul 2017 07:46:26 -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 BF516131C81 for ; Thu, 20 Jul 2017 07:46:25 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=31.133.141.64; From: "Susan Hares" To: "'Tony Przygienda'" , "'idr wg'" References: In-Reply-To: Date: Thu, 20 Jul 2017 10:40:21 -0400 Message-ID: <009b01d30166$1e640640$5b2c12c0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009C_01D30144.9754B030" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLfLikE/cE4poE8ZBiJWjramRQao6BEZynw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] request for IDR working group adoption of https://tools.ietf.org/html/draft-idr-bgp-route-refresh-options-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 14:46:27 -0000 This is a multipart message in MIME format. ------=_NextPart_000_009C_01D30144.9754B030 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Tony:=20 =20 Thank you for your request. Since we had a number of WG adoption = calls, I will send out the list later today with a schedule of the WG = adoption calls.=20 =20 Sue=20 =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Tony Przygienda Sent: Thursday, July 20, 2017 5:40 AM To: idr wg Subject: [Idr] request for IDR working group adoption of = https://tools.ietf.org/html/draft-idr-bgp-route-refresh-options-02 =20 The authors would like to request the adoption of=20 =20 https://tools.ietf.org/html/draft-idr-bgp-route-refresh-options-02 =20 as WG item. The draft has been presented twice, good amount of work & = rev'ing has been put into it and there are no major comments outstanding = after presentations.=20 =20 We think that several ongoing BGP extension developments make it a = valuable workgroup item at this point in time. All further info can be = found in presentation material and the draft itself ...=20 =20 on behalf of other authors=20 =20 --- tony=20 =20 =20 ------=_NextPart_000_009C_01D30144.9754B030 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Tony:

 

Thank you for your request.=C2=A0=C2=A0 Since we had a number of WG = adoption calls, I will send out the list later today with a schedule of = the WG adoption calls.

 

Sue

 

From:= = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Tony = Przygienda
Sent: Thursday, July 20, 2017 5:40 AM
To: = idr wg
Subject: [Idr] request for IDR working group adoption = of = https://tools.ietf.org/html/draft-idr-bgp-route-refresh-options-02

 


The authors would like to request the adoption = of 

 

 

as WG item. The draft has been presented twice, good = amount of work & rev'ing has been put into it and there are no major = comments outstanding after = presentations. 

 

We think that several ongoing BGP extension = developments make it a valuable workgroup item at this point in time. = All further info can be found in presentation material and the draft = itself ... 

 

on behalf of other = authors 

 

--- tony 

 

 

------=_NextPart_000_009C_01D30144.9754B030-- From nobody Thu Jul 20 08:16:26 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 977181252BA; Thu, 20 Jul 2017 08:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.126 X-Spam-Level: X-Spam-Status: No, score=-0.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 WWRtwoSdWZuY; Thu, 20 Jul 2017 08:16:22 -0700 (PDT) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-oln040092255032.outbound.protection.outlook.com [40.92.255.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9A131317CC; Thu, 20 Jul 2017 08:16:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=eO5Udlr5tx1rqcRFXegkHNQNsmFFcsZnE/SwYouD9ys=; b=cORo3jB+igfqb7Xhkfr0nYVX8dNlQukZx/vBYRw/msYAWqi8xKHj/OyLZW5bh1PQafgEpVspWIkRpNKWCg5odgtX+FSG1naHzDDOz0N/1bSzQTQ50QEeTeTIi+9gdeCvasqA9dKm5/uVtgryT2v1tWvpClZ2OMvK2inl+DEKLxd5KlmeupG66C1LlNY0UZ3irNvoQRZozQ9St/A03g7aFS5qwvyAqQ6WDRF47tF912dInnGXA+2VzFhpCpJQMvCMAOSmAjPyJkA4U3p4/seKGeJK30CctNr7TcEvavF8FD3B64FsokfEH0zfkvXqqoYfiX9qu65p8Jj/IUoNdw+fwg== Received: from PU1APC01FT046.eop-APC01.prod.protection.outlook.com (10.152.252.54) by PU1APC01HT077.eop-APC01.prod.protection.outlook.com (10.152.253.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1220.9; Thu, 20 Jul 2017 15:16:18 +0000 Received: from HK2PR0601MB1361.apcprd06.prod.outlook.com (10.152.252.59) by PU1APC01FT046.mail.protection.outlook.com (10.152.253.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.9 via Frontend Transport; Thu, 20 Jul 2017 15:16:18 +0000 Received: from HK2PR0601MB1361.apcprd06.prod.outlook.com ([fe80::b591:87c3:a316:be96]) by HK2PR0601MB1361.apcprd06.prod.outlook.com ([fe80::b591:87c3:a316:be96%13]) with mapi id 15.01.1261.024; Thu, 20 Jul 2017 15:16:18 +0000 From: li zhenqiang To: "bruno.decraene@orange.com" , "draft-li-idr-congestion-status-extended-community@ietf.org" CC: idr Thread-Topic: RE: draft-li-idr-congestion-status-extended-community Thread-Index: AQHS/xR2ZquQmAoAMES5a+pKpEUSQQ== Date: Thu, 20 Jul 2017 15:16:18 +0000 Message-ID: References: <12536_1499779219_5964D093_12536_99_1_53C29892C857584299CBF5D05346208A477FE298@OPEXCLILM21.corporate.adroot.infra.ftgroup>, , <14914_1500480746_596F84EA_14914_50_1_53C29892C857584299CBF5D05346208A47814C43@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=hotmail.com; x-incomingtopheadermarker: OriginalChecksum:E6060F2B60921B2CE6CA06F218004345911E584A93A31C275D2399F5A8B5347C; UpperCasedChecksum:7FE1BDDBA0F82E943C532D6663093EE579D69B3F4A10FDD72EA10D6021A203AE; SizeAsReceived:7674; Count:45 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [cNKVcQohmNaXy1lOyDHHuYMbvzB8NUiO] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; PU1APC01HT077; 7:vbdmjKMb8pGFb6USA2pTVeXoikZY9aEhAThZg0pwMlF/3QorYj/e0StyUS7Dh0ZPwK2xxAMq+i9P07VLN75elgG2j91JyJsm1A9fgQsT7pvzVNJbHC9kLUByr2V6TM3mshbNMlqyw/u+RN1krrCY2dcYnZgCF0dji13fOuds3TQquhRCklW7PZyXmMduff75bacC7LuFWIFGp0MoCRximP64he9/pAyKIN8kleSjLX8BnvSOfnhAmie/OkgT8KE76zEJTjNjk0bJSDr3r77MHJ3RmLYHXHks1ENgHPyDoBEx8aFqe8pLJHzLmw3H0BardhcRHM2W62bAFM8bwn06cRo4sJuGVSQgySxRQ/IgjPz0bYn3eymzfOasWeWNxJa2ZKSYuU+upI1izVwWy286HrkoklN9qwc+mHnpF5vqF1a938wl+8DYcYV3WvFXarqoD9TMhdZs8IN2RCqM4ecksK9eFak7F21usJnylJfXLZDHr9GnNCPHdiAov4U6goGZbKa3SJHcP+FE1CMi6iVEiqG0CvUerW6tGfHW6YruFPzkzL4K8bku7ABVvOuXZafGFszGTHv0WqjyQc5ASviSka7D8urm9y9M30DCz/gD8mm5ug6jghu3FenzqSH0oOKN+gybiNpftul6Xi1oEg+usmH41hE70fJ7mmCsHf9g8PlJymCyKDkuxssi/dBeKdDlFjT+yyzdTQapWwTbWe3X70l4kGx3Y8xiECG//efKQooynUQ0NJnzfJPZt5SKgGCKdCq353r/mAm8uOtgJbz0LA== x-incomingheadercount: 45 x-eopattributedmessage: 0 x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:PU1APC01HT077; H:HK2PR0601MB1361.apcprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: 9fca77ee-19ef-416e-c655-08d4cf8244b0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322350)(1603101448)(1601125374)(1701031045)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:PU1APC01HT077; x-ms-traffictypediagnostic: PU1APC01HT077: x-exchange-antispam-report-test: UriScan:(278178393323532)(26388249023172)(236129657087228)(192374486261705)(788757137089)(48057245064654)(281040445377566)(148574349560750)(18271650672692)(194151415913766); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031); SRVR:PU1APC01HT077; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:PU1APC01HT077; x-forefront-prvs: 0374433C81 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HK2PR0601MB13610454A474EDFD049A4212FCA70HK2PR0601MB1361_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2017 15:16:18.5237 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT077 Archived-At: Subject: Re: [Idr] draft-li-idr-congestion-status-extended-community X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 15:16:26 -0000 --_000_HK2PR0601MB13610454A474EDFD049A4212FCA70HK2PR0601MB1361_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gQnJ1bm8sDQoNClRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHlvdXIgZnVydGhlciBjb21t ZW50cyBpbiBzdWNoIGEgYnVzeSB3ZWVrLiBJIHdpbGwgcmV2aXNlIG15IGRyYWZ0IGFjY29yZGlu ZyB0byB5b3VyIHN1Z2dlc3Rpb25zIGFmdGVyIHRoaXMgbWVldGluZy4gVGhlIHJlcXVpcmVtZW50 IGlzIGNsZWFyIGFuZCB3b3J0aHMgYSBzb2x1dGlvbi4gTmV4dCBzdGVwIHdoZW4gaXQgaXMgYWRv cHRlZCBieSB0aGUgV0csIHdlIG1heSBjb25zaWRlciB0byB1c2UgQkdQIGxhcmdlIGNvbW11bml0 eSBvciBjb21tdW5pdHkgY29udGFpbmVyIHRvIGRlbGl2ZXJ5IHRoZSBjb25nZXN0aW9uIHN0YXR1 cyBpbmZvcm1hdGlvbi4gVGhlIHNwYWNlIG9mIEJHUCBleHRlbmRlZCBjb21tdW5pdHkgaXMgYSBs aXR0bGUgYml0IHRvbyBsaW1pdGVkIGZvciB1cy4NCg0KQmVzdCBSZWdhcmRzLA0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KbGlfemhlbnFpYW5nQGhvdG1haWwuY29tDQoNCkZy b206IGJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb208bWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5n ZS5jb20+DQpEYXRlOiAyMDE3LTA3LTIwIDAwOjEyDQpUbzogbGkgemhlbnFpYW5nPG1haWx0bzps aV96aGVucWlhbmdAaG90bWFpbC5jb20+OyBkcmFmdC1saS1pZHItY29uZ2VzdGlvbi1zdGF0dXMt ZXh0ZW5kZWQtY29tbXVuaXR5QGlldGYub3JnPG1haWx0bzpkcmFmdC1saS1pZHItY29uZ2VzdGlv bi1zdGF0dXMtZXh0ZW5kZWQtY29tbXVuaXR5QGlldGYub3JnPg0KQ0M6IGlkcjxtYWlsdG86aWRy QGlldGYub3JnPg0KU3ViamVjdDogUkU6IGRyYWZ0LWxpLWlkci1jb25nZXN0aW9uLXN0YXR1cy1l eHRlbmRlZC1jb21tdW5pdHkNCkhlbGxvIFpoZW5xaWFuZywNCg0KVGhhbmtzIGZvciB5b3VyIHJl cGx5Lg0KUGxlYXNlIHNlZSBpbmxpbmUgW0JydW5vXQ0KDQpGcm9tOiBsaSB6aGVucWlhbmcgW21h aWx0bzpsaV96aGVucWlhbmdAaG90bWFpbC5jb21dDQpTZW50OiBNb25kYXksIEp1bHkgMTcsIDIw MTcgNTo1MSBQTQ0KDQoNCkhlbGxvIEJydW5vLA0KDQpUaGFuayB5b3UgdmVyeSBtdWNoIGZvciB5 b3VyIGNvbnN0cnVjdGl2ZSBjb21tZW50cy4gUGxlYXNlIHNlZSBteSByZXBseSBpbmxpbmUsIGJl Z2lucyB3aXRoIFJlcGx5LiBTb3JyeSBmb3IgdGhlIGxhdGUgcmVzcG9uc2UuDQoNCkJlc3QgUmVn YXJkcywNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpsaV96aGVucWlhbmdAaG90 bWFpbC5jb208bWFpbHRvOmxpX3poZW5xaWFuZ0Bob3RtYWlsLmNvbT4NCg0KRnJvbTogYnJ1bm8u ZGVjcmFlbmVAb3JhbmdlLmNvbTxtYWlsdG86YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbT4NCkRh dGU6IDIwMTctMDctMTEgMjE6MjANClRvOiBkcmFmdC1saS1pZHItY29uZ2VzdGlvbi1zdGF0dXMt ZXh0ZW5kZWQtY29tbXVuaXR5QGlldGYub3JnPG1haWx0bzpkcmFmdC1saS1pZHItY29uZ2VzdGlv bi1zdGF0dXMtZXh0ZW5kZWQtY29tbXVuaXR5QGlldGYub3JnPg0KQ0M6IGlkckBpZXRmLm9yZzxt YWlsdG86aWRyQGlldGYub3JnPg0KU3ViamVjdDogZHJhZnQtbGktaWRyLWNvbmdlc3Rpb24tc3Rh dHVzLWV4dGVuZGVkLWNvbW11bml0eQ0KSGkgYXV0aG9ycywNCg0KUGxlYXNlIGZpbmQgYmVsb3cg c29tZSBtaW5vciBjb21tZW50cy4NCg0KwqcyICBDb25nZXN0aW9uIFN0YXR1cyBFeHRlbmRlZCBD b21tdW5pdHkNCg0KPiBUaGUgIlV0aWxpemF0aW9uIiBmaWVsZCBpcyAxIG9jdGV0LiAgSXRzIHZh bHVlIGlzIHRoZSB1dGlsaXphdGlvbiBvZiB0aGUgZXhpdCBsaW5rIGluIHVuaXQgb2YgcGVyY2Vu dA0KDQotIElzIHRoaXMgdGhlIHV0aWxpemF0aW9uIG9uIHRoZSBsaW5rIG9yIGJlZm9yZSB0aGUg bGluayAoaS5lLiBiZWZvcmUgZHJvcHBpbmcgdGhlIHRyYWZmaWMgaW4gZXhjZXNzKSA/IElPVywg Y2FuIHRoaXMgYmUgZ3JlYXRlciB0aGFuIDEwMCU/IEkgdGhpbmsgSSdkIHByZWZlciB0aGUgbGF0 dGVyLCBidXQgaW4gYWxsIGNhc2VzLCBJIGxpa2UgdG8gc2VlIGEgdGV4dCBkZXRhaWxpbmcgdGhl IGhhbmRsaW5nIG9mIG51bWJlcnMgPiAxMDAlLg0KUmVwbHk6IElmIGl0IGlzIGVhc3kgdG8gZ2V0 IHRoZSB1dGlsaXphdGlvbiBiZWZvcmUgdGhlIGxpbmssIHdlIGNhbiB1c2UgaXQuIEJ1dCBJIGFt IG5vdCBzdXJlIGFib3V0IGl0LiBJZiB5b3UgY2FuLCBwbGVhc2UgY29udHJpYnV0ZSBzb21lIHRl eHQgdGhhdCBJIHdpbGwgaW5jb3Jwb3JhdGUgaW4gdGhlIG5leHQgdmVyc2lvbi4NCltCcnVub10g VGhhbmtzLg0KSSBjb3VsZCBwcm9wb3NlDQpPTEQ6ICAgSXRzIHZhbHVlIGlzIHRoZSB1dGlsaXph dGlvbiBvZiB0aGUgZXhpdCBsaW5rIGluIHVuaXQgb2YgcGVyY2VudC4NCk5FVzogICBJdHMgdmFs dWUgaXMgdGhlIHV0aWxpemF0aW9uIG9mIHRoZSBleGl0IGxpbmsgaW4gdW5pdCBvZiBwZXJjZW50 LiBJdCBtYXkgYmUgaGlnaGVyIHRoYW4gMTAwJSBpZiB0aGUgaW5jb21pbmcgdHJhZmZpYyBpcyBo aWdoZXIgdGhhbiB0aGUgbGluayBjYXBhY2l0eS4NCg0KDQotIEluIG9yZGVyIHRvIG9mZmVyIG1v cmUgZ3JhbnVsYXJpdHksIHNvbWV0aW1lcyB0aGUgdHJhZmZpYyBpcyByYXRlIGxpbWl0ZWQgdG8g YSBjYXBhY2l0eSBzbWFsbGVyIHRoYW4gdGhlIHBoeXNpY2FsIGxpbmsuIGUuZy4gdGhlIHBoeXNp Y2FsIGxpbmsgaGFzIDEwRyBvZiB0cmFmZmljLCBidXQgb25seSAzRyBpcyBhdmFpbGFibGUgdG8g dGhlIHVzZXIuIFBsZWFzZSBleHBsaWNpdCB3aGV0aGVyIHlvdSBhcmUgcmVmZXJyaW5nIHRvIHBo eXNpY2FsIG9yICJyZWFsIi8ib2ZmZXJlZCIvImF2YWlsYWJsZSIgY2FwYWNpdHkuIE9uIG15IHNp ZGUsIEknZCBwcmVmZXIgdGhlIGxhdHRlci4NClJlcGx5OiBJIGFncmVlIHRoYXQgdGhlIGJhbmR3 aWR0aCBzaG91bGQgYmUgdGhlIGNvbmZpZ3VyZWQgIGF2YWlsYWJsZSBjYXBhY2l0eSBvZiB0aGUg bGluay4gSSB3aWxsIGV4cGxpY2l0IGl0IGluIHRoZSBuZXh0IHZlcnNpb24uDQogW0JydW5vXSBn cmVhdCB0aGFua3MuDQo+IFRoZSAiQmFuZHdpZHRoIiBmaWVsZCBpcyAxIG9jdGV0LiAgSXRzIHZh bHVlIGlzIHRoZSBiYW5kd2lkdGggb2YgdGhlIGV4aXQgbGluayBpbiB1bml0IG9mIDEwIGdicHMg KGdpZ2FiaXRzIHBlciBzZWNvbmQpLg0KDQpJIGRvbid0IHNlZSB0aGF0IHRoaXMgaXMgZXh0cmVt ZWx5IGZ1dHVyZSBwcm9vZiwgYXMgdGhlIHVzYWJsZSByYW5nZSBpcyAxLTI1NS4gV2hlbiB0aGlz IHByb3Bvc2l0aW9uIGdldHMgdXNlZCAoaW4geWVhcnMgZnJvbSBub3cpLCAxMDBHIGxpbmtzIHdv dWxkIHByZXN1bWFibHkgYmUgdGhlIGRlZmF1bHQuIE1lYW5pbmcgd2Ugd291bGQgYWxyZWFkeSBo YXZlIGNvbnN1bWVkICoxMCBmcm9tIHRoZSBidWRnZXQuIE9ubHkgbGVhdmluZyAqMjUgZm9yIHRo ZSBmdXR1cmUuIEknZCBwcmVmZXIgYSB3aWRlciByYW5nZSB3aXRoIGxlc3MgcHJlY2lzaW9uLiBl LmcuIGJhbmR3aWR0aCBpcyAxMF5eYmFuZHdpZHRoIGluIGdicHMuIChvciAyXl4pLg0KUmVwbHk6 IEluZGVlZCB0aGlzIGlzIG9uZSBvZiB0aGUga2V5IHBvaW50cyB3ZSBzaG91bGQgY29uc2lkZXIg ZHVyaW5nIHRoZSBkZXNpZ24gb2YgdGhlIG1lY2hhbmlzbS4gSW4gdW5pdCBvZiAxMCBnYnBzLCBv bmUgb2N0ZXQgY2FuIGV4cHJlc3MgdGhlIGJhbmR3aWR0aCBmcm9tIDEwZ2JwcyB0byAyNTUwZ2Jw cy4gSSB0aGluayBpdCBzaG91bGQgYmUgb2sgZm9yIHRoZSBmdXR1cmUuIFlvdXIgc3VnZ2VzdGlv biBpcyBkaWZmaWN1bHQgdG8gZXhwcmVzcyA0MGdicHMsIDEwMGdicHMgYW5kIDQwMGdicHMgZXRj LiBBbnl3YXkgd2Ugd2lsbCB0aGluayBhYm91dCB5b3VyIHN1Z2dlc3Rpb24gYW5kIHRyeSB0byBm aW5kIGEgYmV0dGVyIHNvbHV0aW9uLiBZb3VyIGZ1cnRoZXIgc3VnZ2VzdGlvbiBpcyB3ZWxjb21l Lg0KW0JydW5vXSBJIGFncmVlIHRoYXQgbXkgc3VnZ2VzdGlvbiBjYW7igJl0IGV4cHJlc3MgcHJl Y2lzZSB2YWx1ZXMuICBHaXZlbiB0aGF0IHR5cGljYWxseSB3ZSBoYXZlIG11bHRpcGxlL21hbnkg aW5ncmVzcyBzZW5kaW5nIHRyYWZmaWMgdG8gb25lIHNpbmdsZSBpbnRlcmZhY2UsIEkgZG9u4oCZ dCBmZWVsIHRoYXQgaGF2aW5nIGEgcHJlY2lzZSBiYW5kd2lkdGggdmFsdWUgaXMgYW4gYWJzb2x1 dGUgcmVxdWlyZW1lbnQgYXMgb25lIHNlbmRlciBjYW7igJl0IHVzZSBhbGwgdGhhdCBiYW5kd2lk dGguIEl0IG5lZWQgdG8gc2hhcmUgaXMgd2l0aCBvdGhlciBpbmdyZXNzIGFuZCBoYXMgbm8gd2F5 IG9mIGtub3dpbmcgaG93IG11Y2ggb3RoZXIgaW5ncmVzcyB3aWxsIGFkYXB0IGFuZCBzZW5kIG1v cmUgb3IgbGVzcyB0cmFmZmljLiBCdXQgaXTigJlzIHJlYWxseSB1cCB0byB5b3UuDQoNCg0KPiBU aGUgbGluayB3aXRoIGJhbmR3aWR0aCBsZXNzIHRoYW4gMTAgZ2JwcyBpcyBub3Qgc3VpdGFibGUg dG8gdXNlIHRoaXMgZmVhdHVyZS4NCg0KV2h5IG5vdD8gSXQgbG9va3MgdG8gbWUgdGhhdCB0aGUg JVV0aWxpemF0aW9uIGNvdWxkIGJlIHVzZWZ1bCBldmVuIGlmIHRoZSBiYW5kd2lkdGggaXMgbm90 IGFkdmVydGlzZWQuIFBvc3NpYmx5IGEgIkJhbmR3aWR0aCIgcmVzZXJ2ZWQgdmFsdWUgKGUuZy4g MCkgY291bGQgYmUgc3BlY2lmaWVkIHRvIGluZGljYXRlIHRoYXQgdGhlIGJhbmR3aWR0aCBpcyBu b3QgYWR2ZXJ0aXNlZC4gVGhpcyB3b3VsZCBhbHNvIGZpdCB0aGUgY2FzZSB3aGVyZSBzb21lIEFT ZXMgZG8gbm90IHdhbnQgdG8gYWR2ZXJ0aXNlIHRoZWlyIGxpbmsgY2FwYWNpdHkuDQpSZXBseTog QWdyZWUuIFdlIHdpbGwgcmV2aXNlIHRoZSBkcmFmdCB0byByZWZsZWN0IHRoaXMuDQogW0JydW5v XSBvaywgdGhhbmtzDQrCpzMuICBBcHBsaWNhdGlvbiBDb25zaWRlcmF0aW9ucw0KDQo+IFRoZSBT RE4gY29udHJvbGxlciB1c2VzIHRoZSBleGl0IGxpbmsgdXRpbGl6YXRpb24gaW5mb3JtYXRpb24g dG8gc3RlZXIgdGhlIEludGVybmV0IGFjY2VzcyB0cmFmZmljIGFtb25nIGFsbCB0aGUgZXhpdCBs aW5rcyBmcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiB0aGUgd2hvbGUgbmV0d29yay4NCg0KSW5kZWVk LCBwcmVzdW1hYmx5IHRoaXMgaW5mb3JtYXRpb24gaXMgdXNlZCB0byBpbmZsdWVuY2UgdGhlIHJv dXRpbmcgYmVoYXZpb3IuIE1heSBiZSB0aGUgZG9jdW1lbnQgc2hvdWxkIGluZGljYXRlIHRoYXQg dGhlIHJlY2VwdGlvbiBvZiBzdWNoIGNvbW11bml0eSBvdmVyIElCR1Agc2Vzc2lvbiBzaG91bGQg bm90IGluZmx1ZW5jZSByb3V0aW5nIGRlY2lzaW9uIHVubGVzcyB0dW5uZWxpbmcgaXMgdXNlZCB0 byByZWFjaCB0aGUgQkdQIE5leHQtSG9wLiAodG8gYXZvaWQgZm9yd2FyZGluZyBsb29wcywgaW5j cmVtZW50YWwgZGVwbG95bWVudCBpc3N1ZXMsIGNvbXBsaWNhdGlvbnMgaW4gZXJyb3IgaGFuZGxp bmcpLg0KUmVwbHk6IFRoYW5rcyBmb3IgcG9pbnRpbmcgb3V0IHRoaXMuIFdlIHdpbGwgYWRkIHNv bWUgZGVzY3JpcHRpb24gaW4gbmV4dCByZXZpc2lvbi4NCiBbQnJ1bm9dIG9rLCB0aGFua3MuDQpJ biBhZGRpdGlvbiwgd2hhdCBhcmUgdGhlIGludGVyYWN0aW9ucyB3aXRoIHRoZSBCR1AgTGluayBC YW5kd2lkdGggRXh0ZW5kZWQgY29tbXVuaXRpZXM/IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLWlkci1saW5rLWJhbmR3aWR0aCAgKEkga25vdyB0aGF0IHRoZSBkcmFmdCBl eHBpcmVkLCBidXQgc3RpbGwgaXQncyBhIFdHIGRvY3VtZW50IGFuZCBhbiBvZmZpY2lhbCBJQU5B IGNvZGUgcG9pbnQpDQpTaGlwcyBpbiB0aGUgbmlnaHQ/DQpSZXBseTogU28gZmFyIHRoaXMgZHJh ZnQgZGlkbuKAmXQgY29uc2lkZXIgdGhlIGludGVyYWN0aW9uIHdpdGggdGhlIGxpbmsgYmFuZHdp ZHRoIEV4dC4gY29tbXVuaXR5LiBBcyB0aGUgbGluayBiYW5kd2lkdGggRXh0LiBjb21tdW5pdHkg aXMgbm9uLXJhbnNpdGl2ZSwgYW5kIHRoZSBnbG9iYWwgYWRtaW5pc3RyYXRvciBzdWJmaWVsZCBp cyBvbmx5IDItb2N0ZXRzLCBpdCBtYXkgbm90IGJlIGFwcGxpY2FibGUgdG8gYWxsIHRoZSBzY2Vu YXJpb3MgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQuDQpbQnJ1bm9dIEkgd2FzIG5vdCBzdWdn ZXN0aW5nIHRvIHJlcGxhY2UgY29uZ2VzdGlvbi1zdGF0dXMgd2l0aCBsaW5rLWJhbmR3aWR0aC4g SSB3YXMgYXNraW5nIGZvciB0aGUgZXhwZWN0ZWQgYmVoYXZpb3IgaWYgbGluay1iYW5kd2lkdGgg YWR2ZXJ0aXNlIGEgY2FwYWNpdHkgb2YgNDBHIHdoaWxlIGNvbmdlc3Rpb24tc3RhdHVzIGFkdmVy dGlzZSBhIGNhcGFjaXR5IG9mIDEwMEcuDQoNCj4gICBUbyBhdm9pZCByb3V0ZSBvc2NpbGxhdGlv biwgdGhlIGV4aXQgcm91dGVyIFNIT1VMRCBzZXQgYSB0aHJlc2hvbGQuICAgV2hlbiB0aGUgdXRp bGl6YXRpb24gY2hhbmdlIHJlYWNoZXMgdGhlIHRocmVzaG9sZCwgdGhlIGV4aXQgcm91dGVyICBT SE9VTEQgZ2VuZXJhdGUgYSBCR1AgdXBkYXRlIG1lc3NhZ2Ugd2l0aCBjb25nZXN0aW9uIHN0YXR1 cyBleHRlbmRlZCAgY29tbXVuaXR5Lg0KDQpJIHRoaW5rIHRoYXQgdGhlIGRvY3VtZW50IHNob3Vs ZCBiZXR0ZXIgZXZhbHVhdGUgdGhlIGNodXJuIGludHJvZHVjZWQuIEluIHBhcnRpY3VsYXIgdGhl IGNodXJuIGlzIGN1bXVsYXRpdmUgYXMgdGhlIG51bWJlciBvZiBBU2VzIGNyb3NzZWQgaW5jcmVh c2UuIGUuZy4gaWYgd2UgYXNzdW1lIHRoYXQgZWFjaCBBUyB1c2UgdGhlIGNvbW11bml0eSBxdWl0 ZSBjYXJlZnVsbHkgYnkgbm90IGFkdmVydGlzaW5nIG1vcmUgdGhhbiAxIHVwZGF0ZSBwZXIgaG91 ciwgaWYgd2UgaGF2ZSA1IEFTZXMgb24gdGhlIHdheSwgdGhlIGluZ3Jlc3MgQVMgY2FuIHJlY2Vp dmUgNSAoYWRkaXRpb25hbCkgdXBkYXRlcyBwZXIgcHJlZml4IHBlciBob3VyLg0KUmVwbHk6IFdl IHdpbGwgdGhpbmsgYWJvdXQgaXQgZnVydGhlci4gU29tZXRoaW5nIGxpa2UgVFRMICh0aW1lIHRv IGxpdmUpIHRvIGJlIGludHJvZHVjZWQ/IFRvIGhhdmUgbGFyZ2VyIHNwYWNlIHRvIGZpdCB0aGlz LCB1c2UgQkdQIGNvbW11bml0eSBjb250YWluZXIgaW5zdGVhZD8gT3IgZG8gIHlvdSAgaGF2ZSAg c29tZSAgc3VnZ2VzdGlvbnM/DQogW0JydW5vXSBBcyBvZiB0b2RheSwgSSB3YXMgb25seSBjYWxs aW5nIGZvciBtb3JlIHRleHQgaGlnaGxpZ2h0aW5nIHRoYXQgdGhlIGNodXJuIGluY3JlYXNlIGxp bmVhcmx5IHdpdGggdGhlIG51bWJlciBvZiBBU2VzIGF0dGFjaGluZyB0aGlzIGNvbW11bml0eSBv biBhIGdpdmVuIHByZWZpeC4NCk9uZSBzdWdnZXN0aW9uIHRvIGltcHJvdmUgdGhlIGJlaGF2aW9y OiDigJxXaGVuIG9uZSBCR1Agcm91dGVyIG5lZWRzIHRvIHJlLWFkdmVydGlzZSBhIEJHUCBwYXRo IGR1ZSB0byBhdHRyaWJ1dGUgY2hhbmdlcywgaXQgU0hPVUxEIHVwZGF0ZSBpdHMgY29uZ2VzdGlv bi1zdGF0dXMtY29tbXVuaXR5IGF0IHRoZSBzYW1lIHRpbWUuIFRoaXMgYWxsb3dzIHJlZHVjaW5n IHRoZSBjaHVybiBhcyBvbmUgdGhlIGZpbmFsIGluZ3Jlc3Mgd2lsbCByZWNlaXZlIGEgc2luZ2xl IFVQREFURSByZWZyZXNoaW5nIHRoZSBOIGNvbW11bml0aWVzLCByYXRoZXIgdGhhbiBOIFVQREFU RXMsIGVhY2ggcmVmcmVzaGluZyBvbmUgY29tbXVuaXR54oCdLg0KNC4gIFNlY3VyaXR5IENvbnNp ZGVyYXRpb25zDQo+IFRoaXMgbmV3IGV4dGVuZGVkIGNvbW11bml0eSBkb2VzIG5vdCBkaXJlY3Rs eSBpbnRyb2R1Y2UgYW55IG5ldyBzZWN1cml0eSBpc3N1ZXMuDQoNCldoYXQgYWJvdXQgdHJ1c3Qv Y2hlYXRpbmcgY29uc2lkZXJhdGlvbnM/IEVzcGVjaWFsbHkgZnJvbSByZW1vdGUgQVNlcyB3aXRo IHdoaWNoIHlvdSBoYXZlIHplcm8gcmVsYXRpb25zaGlwPw0KZS5nLiBhZHZlcnRpc2luZyBhbGxl Z2VkIGNvbmdlc3Rpb24gaW4gb3JkZXIgdG8gVEUvaW5mbHVlbmNlIHJvdXRpbmcgb2Ygb3RoZXJz IEFTZXMsIGFkdmVydGlzaW5nIHBsZW50eSBvZiBmYWtlIGNhcGFjaXR5IHRvIGF0dHJhY3QgbW9y ZSB0cmFmZmljL2N1c3RvbWVycywgYWR2ZXJ0aXNpbmcgdGhhdCB0aGV5IGFyZSBuZXZlciBleHBl cmllbmNpbmcgYW55IGNvbmdlc3Rpb24gZm9yIGNvbW1lcmNpYWwgcmVhc29ucywgZmFrZSBhZHZl cnRpc2VtZW50IG9uICJiZWhhbGYiIG9mIG90aGVyIEFTZXMuLi4NClJlcGx5OiBUaGUgdHJ1c3Qv Y2hlYXRpbmcgcHJvYmxlbSB5b3UgbWVudGlvbmVkIGlzIGEgZ2VuZXJhbCBpc3N1ZSBmb3IgQkdQ LiBDYW4gd2UgbWFrZSBzdXJlIHRoYXQgdGhlIHJvdXRlcyBhZHZlcnRpc2VkIGJ5IGEgQkdQIHBl ZXIgc2hvdWxkIGJlIGFkdmVydGlzZWQgYnkgaXQ/IFRoZSBCR1AgcGVlciBjYW4gZ2VuZXJhdGUg c29tZSByb3V0ZXMgbWFsaWNpb3VzbHkuIEFueXdheSwgIHdlIHdpbGwgYWRkIHNvbWUgYW5hbHlz aXMgdG8gdGhpcyBwcm9ibGVtIGluIG5leHQgcmV2aXNpb24uIEZvciBleGFtcGxlLCAgdGhlIEJH UCByZWNlaXZlciBtYXkgY2hvb3NlIHRvIG9ubHkgdHJ1c3QgdGhlIGNvbmdlc3Rpb24gIGluZm9y bWF0aW9uIGFkdmVydGlzZWQgYnkgc29tZSBwYXJ0aWN1bGFyIEFTZXMsIG9yIEFTZXMgd2l0aGlu IHBhcnRpY3VsYXIgaG9wcy4gQW55IHN1Z2dlc3Rpb24gZnJvbSB5b3U/DQogIFtCcnVub10gSSBh Z3JlZSB0aGF0IHRoaXMgaXMgYSBnZW5lcmFsIHRydXN0IGlzc3VlIGluIEJHUCwgYnV0IHRoaXMg ZG9jdW1lbnQgcHJvcG9zZXMgdG8gYWR2ZXJ0aXNlIG1vcmUgaW5mb3JtYXRpb24gaGVuY2UgaW50 cm9kdWNlIG5ldyBjb25zaWRlcmF0aW9uLiBQbHVzIGluIHRoZSBlbmQsIGlmIHlvdSBkb27igJl0 IHRydXN0IHRoZSBkYXRhLCB0aGVyZSBpcyBubyBuZWVkIHRvIHNlbmQgdGhlbSBpbiB0aGUgZmly c3QgcGxhY2UuDQpPbmUgcG9zc2libGUgZGVwbG95bWVudCBtb2RlbCBpcyB0byBmaWx0ZXIgY29u Z2VzdGlvbi1zdGF0dXMgY29tbXVuaXRpZXMgYXQgdGhlIGJvcmRlciBvZiB5b3UgdHJ1c3QvYWRt aW5pc3RyYXRpdmUgZG9tYWluLiBIZW5jZSBhbGwgdGhlIG9uZSB5b3UgcmVjZWl2ZSBhcmUgdHJ1 c3RlZC4NCk90aGVyIG9wdGlvbnMgbWF5IGJlIHRvIHRyeSB0byBzYW5pdGl6ZSB0aGUgcmVjZWl2 ZWQgdmFsdWUgYmFzZWQgb24gYS1wcmlvcmkga25vd2xlZGdlL2V4cGVjdGF0aW9ucy4gKGUuZy4g cmVjZWl2aW5nIGEgYmFuZHdpZHRoIGNhcGFjaXR5IG9mIDU2a2JpdC9zIGlzIGhpZ2hseSBzdXNw aWNpb3VzIGluIGFuIEludGVybmV0IGJhY2tib25lKS4gQnV0IHRoaXMgcmVxdWlyZXMgYWRkaXRp b25hbCBjb25maWd1cmF0aW9uIHRvIG1haW50YWluLg0KTW9yZSBtYXkgYWxzbyByZWNvcmQgdGhl IGNvbW11bml0aWVzIHJlY2VpdmVkIG92ZXIgdGltZSwgbW9uaXRvciB0aGUgY29uZ2VzdGlvbiBl LmcuIHZpYSBwcm9iaW5nLCBkZXRlY3QgaW5jb25zaXN0ZW5jeSBhbmQgY2hvb3NlIHRvIG5vdCB0 cnVzdCBhbnltb3JlIHRoZSBBU2VzIHdoaWNoIGFkdmVydGlzZSBmYWtlIG5ld3PigKYNCi0tQnJ1 bm8NClRoYW5rcywNClJlZ2FyZHMsDQotLUJydW5vDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KQ2UgbWVzc2FnZSBl dCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNv bmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQpwYXMgZXRy ZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91 cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0K YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRl cy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJh dGlvbiwNCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2Ug YSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KVGhpcyBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVn ZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCnRoZXkgc2hvdWxk IG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9u Lg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMu DQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNz YWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQpUaGFu ayB5b3UuDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1 dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxl Z2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91 IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBw YXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0 cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9u aXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCk9yYW5nZSBkZWNsaW5lIHRv dXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91 IGZhbHNpZmllLiBNZXJjaS4NClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBj b250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJl IHByb3RlY3RlZCBieSBsYXc7DQp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQg b3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRo aXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVk LCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZp ZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KVGhhbmsgeW91Lg0KDQo= --_000_HK2PR0601MB13610454A474EDFD049A4212FCA70HK2PR0601MB1361_ Content-Type: text/html; charset="utf-8" Content-ID: <842CBA33CDE9C5468BBEECE170457D1E@apcprd06.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5ib2R5IHsgbGluZS1oZWlnaHQ6IDEu NTsgfWJsb2NrcXVvdGUgeyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgbWFy Z2luLWxlZnQ6IDAuNWVtOyB9cCB7IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4 OyB9ZGl2LmZveGRpdjIwMTcwNzIwMjMxMDE1MjQ3NzE5IHsgfWJvZHkgeyBmb250LXNpemU6IDEw LjVwdDsgZm9udC1mYW1pbHk6IOW+rui9r+mbhem7kTsgY29sb3I6IHJnYigwLCAwLCAwKTsgbGlu ZS1oZWlnaHQ6IDEuNTsgfTwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keT4NCjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPgo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiA+ PC9vOnNoYXBlZGVmYXVsdHM+CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPgo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiA+PC9vOmlkbWFwPgo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 ZGl2PjxzcGFuPjwvc3Bhbj5IZWxsbyBCcnVubyw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2PlRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHlvdXIgZnVydGhlciBjb21tZW50cyBpbiBzdWNo IGEgYnVzeSB3ZWVrLiBJIHdpbGwgcmV2aXNlIG15IGRyYWZ0IGFjY29yZGluZyB0byB5b3VyIHN1 Z2dlc3Rpb25zIGFmdGVyIHRoaXMgbWVldGluZy4gVGhlIHJlcXVpcmVtZW50IGlzIGNsZWFyIGFu ZCB3b3J0aHMgYSBzb2x1dGlvbi4gTmV4dCBzdGVwIHdoZW4gaXQgaXMgYWRvcHRlZCBieSB0aGUg V0csIHdlIG1heSBjb25zaWRlciB0byB1c2UgQkdQDQogbGFyZ2UgY29tbXVuaXR5IG9yIGNvbW11 bml0eSBjb250YWluZXIgdG8gZGVsaXZlcnkgdGhlIGNvbmdlc3Rpb24gc3RhdHVzIGluZm9ybWF0 aW9uLiBUaGUgc3BhY2Ugb2YgQkdQIGV4dGVuZGVkIGNvbW11bml0eSBpcyBhIGxpdHRsZSBiaXQg dG9vIGxpbWl0ZWQgZm9yIHVzLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ QmVzdCBSZWdhcmRzLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxociBzdHlsZT0id2lkdGg6 IDIxMHB4OyBoZWlnaHQ6IDFweDsiIGNvbG9yPSIjYjVjNGRmIiBzaXplPSIxIiBhbGlnbj0ibGVm dCI+DQo8ZGl2PjxzcGFuPg0KPGRpdiBzdHlsZT0iTUFSR0lOOiAxMHB4OyBGT05ULUZBTUlMWTog dmVyZGFuYTsgRk9OVC1TSVpFOiAxMHB0Ij4NCjxkaXY+bGlfemhlbnFpYW5nQGhvdG1haWwuY29t PC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj48L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgbWFyZ2luLWxlZnQ6IDAuNWVtOyI+DQo8ZGl2 PiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPGRpdiBzdHlsZT0iUEFE RElORy1SSUdIVDogOHB4OyBQQURESU5HLUxFRlQ6IDhweDsgRk9OVC1TSVpFOiAxMnB4O0ZPTlQt RkFNSUxZOnRhaG9tYTtDT0xPUjojMDAwMDAwOyBCQUNLR1JPVU5EOiAjZWZlZmVmOyBQQURESU5H LUJPVFRPTTogOHB4OyBQQURESU5HLVRPUDogOHB4Ij4NCjxkaXY+PGI+RnJvbTo8L2I+Jm5ic3A7 PGEgaHJlZj0ibWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20iIHN0eWxlPSJjb2xvcjog Ymx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7Ij5icnVuby5kZWNyYWVuZUBvcmFuZ2Uu Y29tPC9hPjwvZGl2Pg0KPGRpdj48Yj5EYXRlOjwvYj4mbmJzcDsyMDE3LTA3LTIwJm5ic3A7MDA6 MTI8L2Rpdj4NCjxkaXY+PGI+VG86PC9iPiZuYnNwOzxhIGhyZWY9Im1haWx0bzpsaV96aGVucWlh bmdAaG90bWFpbC5jb20iIHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRl cmxpbmU7Ij5saSB6aGVucWlhbmc8L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWxpLWlkci1j b25nZXN0aW9uLXN0YXR1cy1leHRlbmRlZC1jb21tdW5pdHlAaWV0Zi5vcmciIHN0eWxlPSJjb2xv cjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7Ij4NCmRyYWZ0LWxpLWlkci1jb25n ZXN0aW9uLXN0YXR1cy1leHRlbmRlZC1jb21tdW5pdHlAaWV0Zi5vcmc8L2E+PC9kaXY+DQo8ZGl2 PjxiPkNDOjwvYj4mbmJzcDs8YSBocmVmPSJtYWlsdG86aWRyQGlldGYub3JnIiBzdHlsZT0iY29s b3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyI+aWRyPC9hPjwvZGl2Pg0KPGRp dj48Yj5TdWJqZWN0OjwvYj4mbmJzcDtSRTogZHJhZnQtbGktaWRyLWNvbmdlc3Rpb24tc3RhdHVz LWV4dGVuZGVkLWNvbW11bml0eTwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGNs YXNzPSJGb3hEaXYyMDE3MDcyMDIzMTAxNTI0NzcxOSI+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiID48L286c2hhcGVk ZWZhdWx0cz4KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+CjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiID48 L286aWRtYXA+CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSIgc3R5bGU9InBhZ2U6IFdvcmRTZWN0aW9uMTsiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGVsbG8gWmhlbnFpYW5nLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n LCBzZXJpZjsiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdU aW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MgZm9yIHlvdXIgcmVwbHkuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBj bSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21h bicsIHNlcmlmOyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlBsZWFzZSBzZWUgaW5saW5lIFtCcnVub108bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0 OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7 Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXJpZ2h0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gbGkg emhlbnFpYW5nIFttYWlsdG86bGlfemhlbnFpYW5nQGhvdG1haWwuY29tXQ0KPGJyPg0KPGI+U2Vu dDo8L2I+IE1vbmRheSwgSnVseSAxNywgMjAxNyA1OjUxIFBNPGJyPg0KPGJyPg0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiPg0KPG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyI+ DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3Nv ZnQgWWFIZWkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SGVsbG8g QnJ1bm8sPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbicsIHNlcmlmOyI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+VGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgeW91ciBjb25zdHJ1Y3RpdmUg Y29tbWVudHMuIFBsZWFzZSBzZWUgbXkgcmVwbHkgaW5saW5lLCBiZWdpbnMgd2l0aCBSZXBseS4g U29ycnkgZm9yIHRoZSBsYXRlIHJlc3BvbnNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBz ZXJpZjsiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJw dDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkJlc3QgUmVnYXJkcyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbicsIHNlcmlmOyI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+DQo8aHIgc2l6ZT0iMSIgd2lkdGg9IjIxMCIgc3R5bGU9IndpZHRo OjE1Ny41cHQiIG5vc2hhZGU9IiIgYWxpZ249ImxlZnQiPg0KPC9zcGFuPjwvZGl2Pg0KPGRpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjcuNXB0O21hcmdpbi10b3A6Ny41cHQ7bWFyZ2luLXJp Z2h0OjcuNXB0O21hcmdpbi1ib3R0b206Ny41cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YSBocmVmPSJtYWlsdG86bGlfemhlbnFpYW5nQGhvdG1h aWwuY29tIiBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyI+ bGlfemhlbnFpYW5nQGhvdG1haWwuY29tPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tbGVmdDogNnB0OyBt YXJnaW4tdG9wOiAwcHg7Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJywgc2VyaWY7Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYigyMzksIDIzOSwgMjM5KTsgbWFyZ2luOiAw Y20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJywgc2VyaWY7IGJhY2tncm91bmQtcG9zaXRpb246IGluaXRpYWwgaW5pdGlhbDsgYmFj a2dyb3VuZC1yZXBlYXQ6IGluaXRpYWwgaW5pdGlhbDsiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzxhIGhyZWY9Im1haWx0bzpicnVuby5kZWNyYWVuZUBv cmFuZ2UuY29tIiBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5l OyI+YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZC1jb2xv cjogcmdiKDIzOSwgMjM5LCAyMzkpOyBtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgYmFja2dyb3Vu ZC1wb3NpdGlvbjogaW5pdGlhbCBpbml0aWFsOyBiYWNrZ3JvdW5kLXJlcGVhdDogaW5pdGlhbCBp bml0aWFsOyI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5EYXRl Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7 MjAxNy0wNy0xMSZuYnNwOzIxOjIwPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYigyMzks IDIzOSwgMjM5KTsgbWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IGJhY2tncm91bmQtcG9zaXRpb246 IGluaXRpYWwgaW5pdGlhbDsgYmFja2dyb3VuZC1yZXBlYXQ6IGluaXRpYWwgaW5pdGlhbDsiPg0K PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VG86PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8YSBocmVmPSJtYWls dG86ZHJhZnQtbGktaWRyLWNvbmdlc3Rpb24tc3RhdHVzLWV4dGVuZGVkLWNvbW11bml0eUBpZXRm Lm9yZyIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiPmRy YWZ0LWxpLWlkci1jb25nZXN0aW9uLXN0YXR1cy1leHRlbmRlZC1jb21tdW5pdHlAaWV0Zi5vcmc8 L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYigyMzksIDIzOSwgMjM5KTsgbWFyZ2lu OiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7IGJhY2tncm91bmQtcG9zaXRpb246IGluaXRpYWwgaW5pdGlhbDsg YmFja2dyb3VuZC1yZXBlYXQ6IGluaXRpYWwgaW5pdGlhbDsiPg0KPGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Q0M6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8YSBocmVmPSJtYWlsdG86aWRyQGlldGYub3JnIiBz dHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyI+aWRyQGlldGYu b3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjM5LCAyMzksIDIzOSk7IG1h cmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbicsIHNlcmlmOyBiYWNrZ3JvdW5kLXBvc2l0aW9uOiBpbml0aWFsIGluaXRp YWw7IGJhY2tncm91bmQtcmVwZWF0OiBpbml0aWFsIGluaXRpYWw7Ij4NCjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlN1YmplY3Q6PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDtkcmFmdC1saS1pZHItY29uZ2VzdGlv bi1zdGF0dXMtZXh0ZW5kZWQtY29tbXVuaXR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5IaSBhdXRob3JzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAw Y20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlBsZWFzZSBmaW5kIGJl bG93IHNvbWUgbWlub3IgY29tbWVudHMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAw MXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2Vy aWY7Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01p Y3Jvc29mdCBZYUhlaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7Ij4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj7CpzImbmJzcDsgQ29uZ2VzdGlvbiBT dGF0dXMgRXh0ZW5kZWQgQ29tbXVuaXR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFw dDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlm OyI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNy b3NvZnQgWWFIZWkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jmd0OyBUaGUgJnF1b3Q7VXRpbGl6YXRp b24mcXVvdDsgZmllbGQgaXMgMSBvY3RldC4mbmJzcDsgSXRzIHZhbHVlIGlzIHRoZSB1dGlsaXph dGlvbiBvZiB0aGUgZXhpdCBsaW5rIGluIHVuaXQgb2YgcGVyY2VudDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46 IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0 IFlhSGVpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPi0gSXMgdGhp cyB0aGUgdXRpbGl6YXRpb24gb24gdGhlIGxpbmsgb3IgYmVmb3JlIHRoZSBsaW5rIChpLmUuIGJl Zm9yZSBkcm9wcGluZyB0aGUgdHJhZmZpYyBpbiBleGNlc3MpID8gSU9XLCBjYW4gdGhpcyBiZSBn cmVhdGVyIHRoYW4gMTAwJT8gSSB0aGluayBJJ2QgcHJlZmVyIHRoZSBsYXR0ZXIsDQogYnV0IGlu IGFsbCBjYXNlcywgSSBsaWtlIHRvIHNlZSBhIHRleHQgZGV0YWlsaW5nIHRoZSBoYW5kbGluZyBv ZiBudW1iZXJzICZndDsgMTAwJS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9z b2Z0IFlhSGVpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2s7YmFja2dy b3VuZDp3aGl0ZSI+UmVwbHk6IElmIGl0IGlzIGVhc3kgdG8gZ2V0IHRoZSB1dGlsaXphdGlvbiBi ZWZvcmUgdGhlIGxpbmssIHdlIGNhbiB1c2UgaXQuIEJ1dCBJIGFtIG5vdCBzdXJlIGFib3V0IGl0 LiBJZiB5b3UgY2FuLCBwbGVhc2UgY29udHJpYnV0ZSBzb21lIHRleHQgdGhhdCBJIHdpbGwNCiBp bmNvcnBvcmF0ZSBpbiB0aGUgbmV4dCB2ZXJzaW9uLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsi Pg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5bQnJ1bm9dIFRoYW5rcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7Ij4NCjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBjb3VsZCBwcm9wb3NlPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjog MGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5l dyBSb21hbicsIHNlcmlmOyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPk9MRDogJm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5JdHMgdmFsdWUgaXMgdGhlIHV0aWxpemF0aW9uIG9mDQogdGhlIGV4aXQgbGlu ayBpbiB1bml0IG9mIHBlcmNlbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyI+DQo8c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk5FVzogJm5ic3A7PC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JdHMgdmFsdWUgaXMgdGhlIHV0aWxp emF0aW9uIG9mDQogdGhlIGV4aXQgbGluayBpbiB1bml0IG9mIHBlcmNlbnQuIEl0IG1heSBiZSBo aWdoZXIgdGhhbiAxMDAlIGlmIHRoZSBpbmNvbWluZyB0cmFmZmljIGlzIGhpZ2hlciB0aGFuIHRo ZSBsaW5rIGNhcGFjaXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiPg0KPHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJywgc2VyaWY7Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNt IDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+LSBJbiBvcmRlciB0byBvZmZlciBtb3JlIGdyYW51bGFyaXR5LCBzb21ldGltZXMg dGhlIHRyYWZmaWMgaXMgcmF0ZSBsaW1pdGVkIHRvIGEgY2FwYWNpdHkgc21hbGxlciB0aGFuIHRo ZSBwaHlzaWNhbCBsaW5rLiBlLmcuIHRoZSBwaHlzaWNhbCBsaW5rIGhhcyAxMEcgb2YgdHJhZmZp YywgYnV0IG9ubHkNCiAzRyBpcyBhdmFpbGFibGUgdG8gdGhlIHVzZXIuIFBsZWFzZSBleHBsaWNp dCB3aGV0aGVyIHlvdSBhcmUgcmVmZXJyaW5nIHRvIHBoeXNpY2FsIG9yICZxdW90O3JlYWwmcXVv dDsvJnF1b3Q7b2ZmZXJlZCZxdW90Oy8mcXVvdDthdmFpbGFibGUmcXVvdDsgY2FwYWNpdHkuIE9u IG15IHNpZGUsIEknZCBwcmVmZXIgdGhlIGxhdHRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY20gMGNt IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu Jywgc2VyaWY7Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O01pY3Jvc29mdCBZYUhlaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrO2JhY2tncm91bmQ6d2hpdGUiPlJlcGx5OiBJJm5ic3A7YWdyZWUmbmJzcDt0aGF0Jm5ic3A7 dGhlJm5ic3A7YmFuZHdpZHRoJm5ic3A7c2hvdWxkJm5ic3A7YmUmbmJzcDt0aGUmbmJzcDtjb25m aWd1cmVkJm5ic3A7Jm5ic3A7YXZhaWxhYmxlJm5ic3A7Y2FwYWNpdHkmbmJzcDtvZiZuYnNwO3Ro ZSZuYnNwO2xpbmsuIEkgd2lsbCBleHBsaWNpdCBpdCBpbiB0aGUgbmV4dCB2ZXJzaW9uLjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3Nv ZnQgWWFIZWkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls eTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W0JydW5vXSBncmVhdCB0aGFua3Mu PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01p Y3Jvc29mdCBZYUhlaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mZ3Q7IFRoZSAmcXVvdDtCYW5kd2lkdGgmcXVv dDsgZmllbGQgaXMgMSBvY3RldC4mbmJzcDsgSXRzIHZhbHVlIGlzIHRoZSBiYW5kd2lkdGggb2Yg dGhlIGV4aXQgbGluayBpbiB1bml0IG9mIDEwIGdicHMgKGdpZ2FiaXRzIHBlciBzZWNvbmQpLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAw Y20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPkkgZG9uJ3Qgc2VlIHRoYXQgdGhpcyBpcyBleHRyZW1lbHkgZnV0dXJlIHByb29mLCBh cyB0aGUgdXNhYmxlIHJhbmdlIGlzIDEtMjU1LiBXaGVuIHRoaXMgcHJvcG9zaXRpb24gZ2V0cyB1 c2VkIChpbiB5ZWFycyBmcm9tIG5vdyksIDEwMEcgbGlua3Mgd291bGQgcHJlc3VtYWJseSBiZSB0 aGUgZGVmYXVsdC4NCiBNZWFuaW5nIHdlIHdvdWxkIGFscmVhZHkgaGF2ZSBjb25zdW1lZCAqMTAg ZnJvbSB0aGUgYnVkZ2V0LiBPbmx5IGxlYXZpbmcgKjI1IGZvciB0aGUgZnV0dXJlLiBJJ2QgcHJl ZmVyIGEgd2lkZXIgcmFuZ2Ugd2l0aCBsZXNzIHByZWNpc2lvbi4gZS5nLiBiYW5kd2lkdGggaXMg MTBeXmJhbmR3aWR0aCBpbiBnYnBzLiAob3IgMl5eKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY20gMGNt IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu Jywgc2VyaWY7Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O01pY3Jvc29mdCBZYUhlaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrO2JhY2tncm91bmQ6d2hpdGUiPlJlcGx5OiZuYnNwO0luZGVlZCZuYnNwO3RoaXMmbmJzcDtp cyBvbmUgb2YgdGhlIGtleSBwb2ludHMgd2UmbmJzcDtzaG91bGQmbmJzcDtjb25zaWRlciZuYnNw O2R1cmluZyZuYnNwO3RoZSZuYnNwO2Rlc2lnbiZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVjaGFu aXNtLiBJbiB1bml0IG9mIDEwIGdicHMsIG9uZSBvY3RldCBjYW4gZXhwcmVzcyB0aGUgYmFuZHdp ZHRoDQogZnJvbSAxMGdicHMgdG8gMjU1MGdicHMuIEkgdGhpbmsgaXQgc2hvdWxkIGJlIG9rIGZv ciB0aGUgZnV0dXJlLiBZb3VyIHN1Z2dlc3Rpb24gaXMgZGlmZmljdWx0IHRvIGV4cHJlc3MgNDBn YnBzLCAxMDBnYnBzIGFuZCA0MDBnYnBzIGV0Yy4gQW55d2F5IHdlJm5ic3A7d2lsbCZuYnNwO3Ro aW5rJm5ic3A7YWJvdXQmbmJzcDt5b3VyJm5ic3A7c3VnZ2VzdGlvbiBhbmQgdHJ5IHRvIGZpbmQg YSBiZXR0ZXIgc29sdXRpb24uIFlvdXIgZnVydGhlciBzdWdnZXN0aW9uIGlzIHdlbGNvbWUuPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jv c29mdCBZYUhlaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7YmFj a2dyb3VuZDp3aGl0ZSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250 LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltCcnVub10gSSBhZ3JlZSB0aGF0 IG15IHN1Z2dlc3Rpb24gY2Fu4oCZdCBleHByZXNzIHByZWNpc2UgdmFsdWVzLiAmbmJzcDtHaXZl biB0aGF0IHR5cGljYWxseSB3ZSBoYXZlIG11bHRpcGxlL21hbnkgaW5ncmVzcyBzZW5kaW5nIHRy YWZmaWMgdG8gb25lIHNpbmdsZSBpbnRlcmZhY2UsIEkgZG9u4oCZdA0KIGZlZWwgdGhhdCBoYXZp bmcgYSBwcmVjaXNlIGJhbmR3aWR0aCB2YWx1ZSBpcyBhbiBhYnNvbHV0ZSByZXF1aXJlbWVudCBh cyBvbmUgc2VuZGVyIGNhbuKAmXQgdXNlIGFsbCB0aGF0IGJhbmR3aWR0aC4gSXQgbmVlZCB0byBz aGFyZSBpcyB3aXRoIG90aGVyIGluZ3Jlc3MgYW5kIGhhcyBubyB3YXkgb2Yga25vd2luZyBob3cg bXVjaCBvdGhlciBpbmdyZXNzIHdpbGwgYWRhcHQgYW5kIHNlbmQgbW9yZSBvciBsZXNzIHRyYWZm aWMuIEJ1dCBpdOKAmXMgcmVhbGx5DQogdXAgdG8geW91LjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250 LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2s7YmFja2dyb3VuZDp3aGl0 ZSI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyI+ DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZndDsgVGhlIGxpbmsg d2l0aCBiYW5kd2lkdGggbGVzcyB0aGFuIDEwIGdicHMgaXMgbm90IHN1aXRhYmxlIHRvIHVzZSB0 aGlzIGZlYXR1cmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+V2h5IG5vdD8gSXQgbG9va3MgdG8gbWUgdGhhdCB0aGUgJVV0 aWxpemF0aW9uIGNvdWxkIGJlIHVzZWZ1bCBldmVuIGlmIHRoZSBiYW5kd2lkdGggaXMgbm90IGFk dmVydGlzZWQuIFBvc3NpYmx5IGEgJnF1b3Q7QmFuZHdpZHRoJnF1b3Q7IHJlc2VydmVkIHZhbHVl IChlLmcuIDApIGNvdWxkIGJlIHNwZWNpZmllZCB0bw0KIGluZGljYXRlIHRoYXQgdGhlIGJhbmR3 aWR0aCBpcyBub3QgYWR2ZXJ0aXNlZC4gVGhpcyB3b3VsZCBhbHNvIGZpdCB0aGUgY2FzZSB3aGVy ZSBzb21lIEFTZXMgZG8gbm90IHdhbnQgdG8gYWR2ZXJ0aXNlIHRoZWlyIGxpbmsgY2FwYWNpdHku PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250 LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjaztiYWNrZ3JvdW5kOndoaXRlIj5SZXBseTombmJz cDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PkFncmVlLiZuYnNwO1dlJm5ic3A7d2lsbCZuYnNwO3JldmlzZSZuYnNwO3RoZSZuYnNwO2RyYWZ0 Jm5ic3A7dG8mbmJzcDtyZWZsZWN0Jm5ic3A7dGhpcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY20gMGNt IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu Jywgc2VyaWY7Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O01pY3Jvc29mdCBZYUhlaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5bQnJ1bm9dIG9rLCB0aGFua3M8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAw Y20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPsKnMy4mbmJzcDsgQXBwbGljYXRpb24gQ29uc2lkZXJhdGlvbnM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJywgc2VyaWY7Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0 OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7 Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jv c29mdCBZYUhlaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mZ3Q7 IFRoZSBTRE4gY29udHJvbGxlciB1c2VzIHRoZSBleGl0IGxpbmsgdXRpbGl6YXRpb24gaW5mb3Jt YXRpb24gdG8gc3RlZXIgdGhlIEludGVybmV0IGFjY2VzcyB0cmFmZmljIGFtb25nIGFsbCB0aGUg ZXhpdCBsaW5rcyBmcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiB0aGUgd2hvbGUgbmV0d29yay48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY20gMGNt IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu Jywgc2VyaWY7Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O01pY3Jvc29mdCBZYUhlaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj5JbmRlZWQsIHByZXN1bWFibHkgdGhpcyBpbmZvcm1hdGlvbiBpcyB1c2VkIHRvIGluZmx1 ZW5jZSB0aGUgcm91dGluZyBiZWhhdmlvci4gTWF5IGJlIHRoZSBkb2N1bWVudCBzaG91bGQgaW5k aWNhdGUgdGhhdCB0aGUgcmVjZXB0aW9uIG9mIHN1Y2ggY29tbXVuaXR5IG92ZXIgSUJHUCBzZXNz aW9uIHNob3VsZA0KIG5vdCBpbmZsdWVuY2Ugcm91dGluZyBkZWNpc2lvbiB1bmxlc3MgdHVubmVs aW5nIGlzIHVzZWQgdG8gcmVhY2ggdGhlIEJHUCBOZXh0LUhvcC4gKHRvIGF2b2lkIGZvcndhcmRp bmcgbG9vcHMsIGluY3JlbWVudGFsIGRlcGxveW1lbnQgaXNzdWVzLCBjb21wbGljYXRpb25zIGlu IGVycm9yIGhhbmRsaW5nKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7Ij4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZ YUhlaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6 d2hpdGUiPlJlcGx5OiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+VGhhbmtzJm5ic3A7Zm9yJm5ic3A7cG9pbnRpbmcmbmJzcDtvdXQm bmJzcDt0aGlzLiZuYnNwO1dlJm5ic3A7d2lsbCZuYnNwO2FkZCZuYnNwO3NvbWUmbmJzcDtkZXNj cmlwdGlvbiZuYnNwO2luJm5ic3A7bmV4dCZuYnNwO3JldmlzaW9uLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46 IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltCcnVub10gb2ssIHRoYW5rcy48L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPkluIGFkZGl0aW9uLCB3aGF0IGFyZSB0aGUgaW50ZXJhY3Rpb25zIHdp dGggdGhlIEJHUCBMaW5rIEJhbmR3aWR0aCBFeHRlbmRlZCBjb21tdW5pdGllcz8NCjxhIGhyZWY9 Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlkci1saW5rLWJhbmR3aWR0 aCIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiPg0KaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaWRyLWxpbmstYmFuZHdpZHRoPC9h PiZuYnNwOyAoSSBrbm93IHRoYXQgdGhlIGRyYWZ0IGV4cGlyZWQsIGJ1dCBzdGlsbCBpdCdzIGEg V0cgZG9jdW1lbnQgYW5kIGFuIG9mZmljaWFsIElBTkEgY29kZSBwb2ludCk8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJywgc2VyaWY7Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj5TaGlwcyBpbiB0aGUgbmlnaHQ/DQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAw Y20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJywgc2VyaWY7Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj5SZXBseTombmJzcDtTbyZuYnNwO2ZhciZuYnNwO3RoaXMmbmJzcDtkcmFmdCZu YnNwO2RpZG7igJl0Jm5ic3A7Y29uc2lkZXImbmJzcDt0aGUmbmJzcDtpbnRlcmFjdGlvbiZuYnNw O3dpdGgmbmJzcDt0aGUmbmJzcDtsaW5rJm5ic3A7YmFuZHdpZHRoJm5ic3A7RXh0LiZuYnNwO2Nv bW11bml0eS4mbmJzcDtBcyZuYnNwO3RoZSZuYnNwO2xpbmsmbmJzcDtiYW5kd2lkdGgmbmJzcDtF eHQuJm5ic3A7Y29tbXVuaXR5Jm5ic3A7aXMmbmJzcDtub24tcmFuc2l0aXZlLCZuYnNwO2FuZCZu YnNwO3RoZSZuYnNwO2dsb2JhbCZuYnNwO2FkbWluaXN0cmF0b3ImbmJzcDtzdWJmaWVsZCZuYnNw O2lzJm5ic3A7b25seSZuYnNwOzItb2N0ZXRzLCZuYnNwO2l0Jm5ic3A7bWF5Jm5ic3A7bm90Jm5i c3A7YmUmbmJzcDthcHBsaWNhYmxlJm5ic3A7dG8mbmJzcDthbGwmbmJzcDt0aGUmbmJzcDtzY2Vu YXJpb3MmbmJzcDtkZXNjcmliZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDtkb2N1bWVudC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W0JydW5vXSBJIHdhcyBub3Qgc3VnZ2Vz dGluZyB0byByZXBsYWNlIGNvbmdlc3Rpb24tc3RhdHVzIHdpdGggbGluay1iYW5kd2lkdGguIEkg d2FzIGFza2luZyBmb3IgdGhlIGV4cGVjdGVkIGJlaGF2aW9yIGlmIGxpbmstYmFuZHdpZHRoIGFk dmVydGlzZSBhIGNhcGFjaXR5IG9mIDQwRw0KIHdoaWxlIGNvbmdlc3Rpb24tc3RhdHVzIGFkdmVy dGlzZSBhIGNhcGFjaXR5IG9mIDEwMEcuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0 OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7 Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyI+DQo8c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9z b2Z0IFlhSGVpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZndDsm bmJzcDsmbmJzcDsgVG8gYXZvaWQgcm91dGUgb3NjaWxsYXRpb24sIHRoZSBleGl0IHJvdXRlciBT SE9VTEQgc2V0IGEgdGhyZXNob2xkLiZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5XaGVuIHRoZSB1dGlsaXphdGlvbiBj aGFuZ2UgcmVhY2hlcyB0aGUgdGhyZXNob2xkLCB0aGUgZXhpdCByb3V0ZXImbmJzcDsgU0hPVUxE IGdlbmVyYXRlIGEgQkdQIHVwZGF0ZSBtZXNzYWdlIHdpdGggY29uZ2VzdGlvbiBzdGF0dXMgZXh0 ZW5kZWQmbmJzcDsgY29tbXVuaXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9z b2Z0IFlhSGVpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkkgdGhpbmsgdGhhdCB0aGUgZG9jdW1lbnQg c2hvdWxkIGJldHRlciBldmFsdWF0ZSB0aGUgY2h1cm4gaW50cm9kdWNlZC4gSW4gcGFydGljdWxh ciB0aGUgY2h1cm4gaXMgY3VtdWxhdGl2ZSBhcyB0aGUgbnVtYmVyIG9mIEFTZXMgY3Jvc3NlZCBp bmNyZWFzZS4gZS5nLiBpZiB3ZSBhc3N1bWUgdGhhdA0KIGVhY2ggQVMgdXNlIHRoZSBjb21tdW5p dHkgcXVpdGUgY2FyZWZ1bGx5IGJ5IG5vdCBhZHZlcnRpc2luZyBtb3JlIHRoYW4gMSB1cGRhdGUg cGVyIGhvdXIsIGlmIHdlIGhhdmUgNSBBU2VzIG9uIHRoZSB3YXksIHRoZSBpbmdyZXNzIEFTIGNh biByZWNlaXZlIDUgKGFkZGl0aW9uYWwpIHVwZGF0ZXMgcGVyIHByZWZpeCBwZXIgaG91ci48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5SZXBseTogV2Ugd2lsbCZuYnNwO3RoaW5rJm5ic3A7 YWJvdXQmbmJzcDtpdCZuYnNwO2Z1cnRoZXIuIFNvbWV0aGluZyBsaWtlIFRUTCAodGltZSB0byBs aXZlKSB0byBiZSBpbnRyb2R1Y2VkPyBUbyBoYXZlIGxhcmdlciBzcGFjZSB0byBmaXQgdGhpcywg dXNlIEJHUCBjb21tdW5pdHkgY29udGFpbmVyIGluc3RlYWQ/IE9yIGRvICZuYnNwO3lvdQ0KICZu YnNwO2hhdmUgJm5ic3A7c29tZSAmbmJzcDtzdWdnZXN0aW9ucz88c3BhbiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n LCBzZXJpZjsiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bQnJ1bm9dIEFzIG9mIHRvZGF5LCBJIHdhcyBv bmx5IGNhbGxpbmcgZm9yIG1vcmUgdGV4dCBoaWdobGlnaHRpbmcNCiB0aGF0IHRoZSBjaHVybiBp bmNyZWFzZSBsaW5lYXJseSB3aXRoIHRoZSBudW1iZXIgb2YgQVNlcyBhdHRhY2hpbmcgdGhpcyBj b21tdW5pdHkgb24gYSBnaXZlbiBwcmVmaXguPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQt c2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiPg0KPHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PbmUg c3VnZ2VzdGlvbiB0byBpbXByb3ZlIHRoZSBiZWhhdmlvcjog4oCcV2hlbiBvbmUgQkdQIHJvdXRl ciBuZWVkcyB0byByZS1hZHZlcnRpc2UgYSBCR1AgcGF0aCBkdWUgdG8gYXR0cmlidXRlIGNoYW5n ZXMsIGl0IFNIT1VMRCB1cGRhdGUgaXRzIGNvbmdlc3Rpb24tc3RhdHVzLWNvbW11bml0eQ0KIGF0 IHRoZSBzYW1lIHRpbWUuIFRoaXMgYWxsb3dzIHJlZHVjaW5nIHRoZSBjaHVybiBhcyBvbmUgdGhl IGZpbmFsIGluZ3Jlc3Mgd2lsbCByZWNlaXZlIGEgc2luZ2xlIFVQREFURSByZWZyZXNoaW5nIHRo ZSBOIGNvbW11bml0aWVzLCByYXRoZXIgdGhhbiBOIFVQREFURXMsIGVhY2ggcmVmcmVzaGluZyBv bmUgY29tbXVuaXR54oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQt c2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlh SGVpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjQuJm5ic3A7IFNl Y3VyaXR5IENvbnNpZGVyYXRpb25zPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyI+ DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3Nv ZnQgWWFIZWkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jmd0OyBU aGlzIG5ldyBleHRlbmRlZCBjb21tdW5pdHkgZG9lcyBub3QgZGlyZWN0bHkgaW50cm9kdWNlIGFu eSBuZXcgc2VjdXJpdHkgaXNzdWVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9z b2Z0IFlhSGVpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPldoYXQgYWJvdXQgdHJ1c3QvY2hlYXRpbmcg Y29uc2lkZXJhdGlvbnM/IEVzcGVjaWFsbHkgZnJvbSByZW1vdGUgQVNlcyB3aXRoIHdoaWNoIHlv dSBoYXZlIHplcm8gcmVsYXRpb25zaGlwPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp ZjsiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWlj cm9zb2Z0IFlhSGVpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPmUu Zy4gYWR2ZXJ0aXNpbmcgYWxsZWdlZCBjb25nZXN0aW9uIGluIG9yZGVyIHRvIFRFL2luZmx1ZW5j ZSByb3V0aW5nIG9mIG90aGVycyBBU2VzLCBhZHZlcnRpc2luZyBwbGVudHkgb2YgZmFrZSBjYXBh Y2l0eSB0byBhdHRyYWN0IG1vcmUgdHJhZmZpYy9jdXN0b21lcnMsIGFkdmVydGlzaW5nIHRoYXQN CiB0aGV5IGFyZSBuZXZlciBleHBlcmllbmNpbmcgYW55IGNvbmdlc3Rpb24gZm9yIGNvbW1lcmNp YWwgcmVhc29ucywgZmFrZSBhZHZlcnRpc2VtZW50IG9uICZxdW90O2JlaGFsZiZxdW90OyBvZiBv dGhlciBBU2VzLi4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+UmVwbHk6Jm5ic3A7VGhl Jm5ic3A7dHJ1c3QvY2hlYXRpbmcmbmJzcDtwcm9ibGVtIHlvdSZuYnNwO21lbnRpb25lZCZuYnNw O2lzIGEmbmJzcDtnZW5lcmFsJm5ic3A7aXNzdWUmbmJzcDtmb3ImbmJzcDtCR1AuIENhbiB3ZSBt YWtlIHN1cmUgdGhhdCB0aGUgcm91dGVzIGFkdmVydGlzZWQgYnkgYSBCR1AgcGVlciBzaG91bGQg YmUgYWR2ZXJ0aXNlZCBieSBpdD8gVGhlIEJHUCBwZWVyDQogY2FuIGdlbmVyYXRlIHNvbWUgcm91 dGVzIG1hbGljaW91c2x5LiBBbnl3YXksJm5ic3A7IHdlJm5ic3A7d2lsbCZuYnNwO2FkZCZuYnNw O3NvbWUmbmJzcDthbmFseXNpcyZuYnNwO3RvJm5ic3A7dGhpcyZuYnNwO3Byb2JsZW0mbmJzcDtp biZuYnNwO25leHQmbmJzcDtyZXZpc2lvbi4mbmJzcDtGb3ImbmJzcDtleGFtcGxlLCAmbmJzcDt0 aGUmbmJzcDtCR1AgcmVjZWl2ZXIgbWF5Jm5ic3A7Y2hvb3NlJm5ic3A7dG8mbmJzcDtvbmx5Jm5i c3A7dHJ1c3QmbmJzcDt0aGUmbmJzcDtjb25nZXN0aW9uICZuYnNwO2luZm9ybWF0aW9uJm5ic3A7 YWR2ZXJ0aXNlZCZuYnNwO2J5Jm5ic3A7c29tZSZuYnNwO3BhcnRpY3VsYXImbmJzcDtBU2VzLCBv ciZuYnNwO0FTZXMmbmJzcDt3aXRoaW4mbmJzcDtwYXJ0aWN1bGFyJm5ic3A7aG9wcy4NCiBBbnkg c3VnZ2VzdGlvbiBmcm9tIHlvdT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7Ij4N CjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W0JydW5vXSBJIGFncmVlIHRoYXQgdGhpcyBpcyBhIGdl bmVyYWwgdHJ1c3QgaXNzdWUgaW4gQkdQLA0KIGJ1dCB0aGlzIGRvY3VtZW50IHByb3Bvc2VzIHRv IGFkdmVydGlzZSBtb3JlIGluZm9ybWF0aW9uIGhlbmNlIGludHJvZHVjZSBuZXcgY29uc2lkZXJh dGlvbi4gUGx1cyBpbiB0aGUgZW5kLCBpZiB5b3UgZG9u4oCZdCB0cnVzdCB0aGUgZGF0YSwgdGhl cmUgaXMgbm8gbmVlZCB0byBzZW5kIHRoZW0gaW4gdGhlIGZpcnN0IHBsYWNlLjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY20g MGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJv bWFuJywgc2VyaWY7Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+T25lIHBvc3NpYmxlIGRlcGxveW1lbnQgbW9kZWwgaXMgdG8gZmlsdGVy IGNvbmdlc3Rpb24tc3RhdHVzIGNvbW11bml0aWVzIGF0IHRoZSBib3JkZXIgb2YgeW91IHRydXN0 L2FkbWluaXN0cmF0aXZlIGRvbWFpbi4gSGVuY2UgYWxsIHRoZSBvbmUgeW91IHJlY2VpdmUgYXJl IHRydXN0ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls eTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk90aGVyIG9wdGlvbnMgbWF5IGJlIHRvIHRy eSB0byBzYW5pdGl6ZSB0aGUgcmVjZWl2ZWQgdmFsdWUgYmFzZWQgb24gYS1wcmlvcmkga25vd2xl ZGdlL2V4cGVjdGF0aW9ucy4gKGUuZy4gcmVjZWl2aW5nIGEgYmFuZHdpZHRoIGNhcGFjaXR5IG9m IDU2a2JpdC9zIGlzIGhpZ2hseSBzdXNwaWNpb3VzDQogaW4gYW4gSW50ZXJuZXQgYmFja2JvbmUp LiBCdXQgdGhpcyByZXF1aXJlcyBhZGRpdGlvbmFsIGNvbmZpZ3VyYXRpb24gdG8gbWFpbnRhaW4u PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbicsIHNlcmlmOyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1vcmUgbWF5IGFsc28gcmVjb3JkIHRoZSBjb21tdW5pdGll cyByZWNlaXZlZCBvdmVyIHRpbWUsIG1vbml0b3IgdGhlIGNvbmdlc3Rpb24gZS5nLiB2aWEgcHJv YmluZywgZGV0ZWN0IGluY29uc2lzdGVuY3kgYW5kIGNob29zZSB0byBub3QgdHJ1c3QgYW55bW9y ZSB0aGUgQVNlcyB3aGljaA0KIGFkdmVydGlzZSBmYWtlIG5ld3PigKY8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAw MXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2Vy aWY7Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+LS1CcnVubzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiPg0KPHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01p Y3Jvc29mdCBZYUhlaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5U aGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyI+DQo8c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0 IFlhSGVpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlJlZ2FyZHMs PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250 LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPi0tQnJ1bm88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbicsIHNlcmlmOyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj5fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAw Y20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkNlIG1lc3NhZ2UgZXQg c2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25m aWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdU aW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVz IHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJl dXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFw dDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlm OyI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNy b3NvZnQgWWFIZWkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+YSBs J2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4g TGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlv biw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7Ij4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5PcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNw b25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZp ZS4gTWVyY2kuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbicsIHNlcmlmOyI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNv bnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUg cHJvdGVjdGVkIGJ5IGxhdzs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7Ij4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZ YUhlaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj50aGV5IHNob3Vs ZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlv bi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7Ij4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5JZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlz IG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAu MDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg c2VyaWY7Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O01pY3Jvc29mdCBZYUhlaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij5BcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNz YWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls eTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VGhhbmsgeW91LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAw Y20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPHByZSBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAu MDAwMXB0OyBmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyI+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRl cyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2 ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRv cmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxs ZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxl cyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2Vw dGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUg c2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgpU aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwg b3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0 aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0 aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0 YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUg Zm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmll ZC4KVGhhbmsgeW91Lgo8L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_HK2PR0601MB13610454A474EDFD049A4212FCA70HK2PR0601MB1361_-- From nobody Fri Jul 21 01:36:57 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 369EA129AA0 for ; Fri, 21 Jul 2017 01:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 cySCLne8FcJi for ; Fri, 21 Jul 2017 01:36:54 -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 8FD221317A1 for ; Fri, 21 Jul 2017 01:36:54 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=31.133.141.64; From: "Susan Hares" To: "'idr wg'" Date: Fri, 21 Jul 2017 04:30:42 -0400 Message-ID: <007501d301fb$a4caf5a0$ee60e0e0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0076_01D301DA.1DBA8E20" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdMB+eT5JY6g+WeRQAWZjac9QMmkpg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] Summary of IDR Draft action items from IDR meeting X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 08:36:56 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0076_01D301DA.1DBA8E20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit IDR WG: Please review this list of WG LCs and adoptions. Did I miss anyone? Or did you want to ask and forget to? Send me a note if you want to be on one of these lists. Sue Haers WG LC was requested for: 1) draft-ietf-idr-rfc5575bis-04 2) draft-ietf-tunnel-encaps 3) draft-ietf-idr-bgp-optimal-route-reflection WG LC soon was requested by other groups at this IETF ro: 1) draft-ietf-idr-bgp-extended-messages 2) drat-ietf-idr-ls-trill Indication that quick transition from WG Adoption to WG LC 1) draft-idr-bgp-ls-segment-routing-msd Request for WG Adoption call: 1) draft-li-idr-congestion-status 2) draft-li-idr-flowspec-populate-to-fib-01 3) draft-acee-idr-lldp-peer-discovery People are interested in an interim that discusses linking BGP to a link later. Target time: Early September ------=_NextPart_000_0076_01D301DA.1DBA8E20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IDR WG: =

 

Please review this list of WG LCs and adoptions.  = Did I miss anyone? Or did you want to ask and forget to?  Send me a = note if you want to be on one of these lists.

 

Sue Haers =

 

WG LC was requested for:

1)      = draft-ietf-idr-rfc5575bis-04

2)      = draft-ietf-tunnel-encaps

3)      = draft-ietf-idr-bgp-optimal-route-reflection =

 

WG LC soon was requested by other groups at this IETF = ro:

1)      = draft-ietf-idr-bgp-extended-messages  =

2)      = drat-ietf-idr-ls-trill

 

Indication = that quick transition from WG Adoption to WG LC

1)      = draft-idr-bgp-ls-segment-routing-msd =

 

Request for WG Adoption call:

1)      = draft-li-idr-congestion-status

2)      = draft-li-idr-flowspec-populate-to-fib-01

3)      = draft-acee-idr-lldp-peer-discovery

=

 

People = are interested in an interim that discusses linking BGP to a link later. =

Target time:  Early September =

 

 

------=_NextPart_000_0076_01D301DA.1DBA8E20-- From nobody Fri Jul 21 02:07:00 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1A6912EB2B for ; Fri, 21 Jul 2017 02:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 sKr5tHolj7hQ for ; Fri, 21 Jul 2017 02:06:46 -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 E431A129AA0 for ; Fri, 21 Jul 2017 02:06:45 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=31.133.153.78; From: "Susan Hares" To: "'idr wg'" References: <007501d301fb$a4caf5a0$ee60e0e0$@ndzh.com> In-Reply-To: <007501d301fb$a4caf5a0$ee60e0e0$@ndzh.com> Date: Fri, 21 Jul 2017 05:00:42 -0400 Message-ID: <001201d301ff$d5f30c40$81d924c0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01D301DE.4EE2CBD0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJKrhvU8dNCUEvqmLf569eqoaFLFaFuoM5g Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] Summary of IDR Draft action items from IDR meeting X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 09:06:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0013_01D301DE.4EE2CBD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all: John indicated that I did not clearly specify what I meant by a "People are interested in an interim that discusses linking BGP to a link later" This is a typo - another one of my famous and funny typos. What I should have typed was: "People are interest in an interim that discusses drafts that provide a link between BGP and the link layer such as the LLDP draft (draft-acee-idr-lldp-peer-discovery-01) or the draft-ietf-idr-rs-bfd draft." Sue Hares From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Friday, July 21, 2017 4:31 AM To: 'idr wg' Subject: [Idr] Summary of IDR Draft action items from IDR meeting IDR WG: Please review this list of WG LCs and adoptions. Did I miss anyone? Or did you want to ask and forget to? Send me a note if you want to be on one of these lists. Sue Haers WG LC was requested for: 1) draft-ietf-idr-rfc5575bis-04 2) draft-ietf-tunnel-encaps 3) draft-ietf-idr-bgp-optimal-route-reflection WG LC soon was requested by other groups at this IETF ro: 1) draft-ietf-idr-bgp-extended-messages 2) drat-ietf-idr-ls-trill Indication that quick transition from WG Adoption to WG LC 1) draft-idr-bgp-ls-segment-routing-msd Request for WG Adoption call: 1) draft-li-idr-congestion-status 2) draft-li-idr-flowspec-populate-to-fib-01 3) draft-acee-idr-lldp-peer-discovery People are interested in an interim that discusses linking BGP to a link later. Target time: Early September ------=_NextPart_000_0013_01D301DE.4EE2CBD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all:

 

John indicated that I = did not clearly specify what I meant by a

 

“People are = interested in an interim that discusses linking BGP to a link = later”

 

This is a typo – another one of my famous and = funny typos. What I should have typed was:

 

“People are interest in an interim that = discusses drafts that provide a link between BGP and the link layer such = as the LLDP draft (draft-acee-idr-lldp-peer-discovery-01) or the = draft-ietf-idr-rs-bfd draft.”

 

Sue = Hares

 

From:= = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan = Hares
Sent: Friday, July 21, 2017 4:31 AM
To: 'idr = wg'
Subject: [Idr] Summary of IDR Draft action items from IDR = meeting

 

IDR WG: =

 

Please review this list of WG LCs and adoptions.  = Did I miss anyone? Or did you want to ask and forget to?  Send me a = note if you want to be on one of these lists.

 

Sue Haers =

 

WG LC was requested for:

1)      = draft-ietf-idr-rfc5575bis-04

2)      = draft-ietf-tunnel-encaps

3)      = draft-ietf-idr-bgp-optimal-route-reflection =

 

WG LC soon was requested by other groups at this IETF = ro:

1)      = draft-ietf-idr-bgp-extended-messages  =

2)      = drat-ietf-idr-ls-trill

 

Indication = that quick transition from WG Adoption to WG LC

1)      = draft-idr-bgp-ls-segment-routing-msd =

 

Request for WG Adoption call:

1)      = draft-li-idr-congestion-status

2)      = draft-li-idr-flowspec-populate-to-fib-01

3)      = draft-acee-idr-lldp-peer-discovery

=

 

People = are interested in an interim that discusses linking BGP to a link later. =

Target time:  Early September =

 

 

------=_NextPart_000_0013_01D301DE.4EE2CBD0-- From nobody Fri Jul 21 04:50:45 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFCA13157A for ; Fri, 21 Jul 2017 04:50:44 -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 KjzTOMDO_kNE for ; Fri, 21 Jul 2017 04:50:41 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0A46131667 for ; Fri, 21 Jul 2017 04:50:40 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id w191so11872899wmw.1 for ; Fri, 21 Jul 2017 04:50:40 -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=5QP8WHomX2ID/kyx7WoYk6ck6FsKpnx3K9oMCpknifk=; b=rud7SG9v47XEGZQVJyILKrqvGwa49SAlRWx5wAWJxa2RRt+vmWKuebpC4WWFtNXhxa XH8rxjs5XRqPt24IzjbkBbBItvMmG6BL5llLCkBtRn/J9eLXshIx5xqTwWz8meHK1f4G S+AuxEAKe8131ryFZ/PQHs0ct8motaitzlCfkzqHNY/3/keUgJCQJaXO6zhcIukbs5ed vL4+pZ16DmdKI0f8unj20w81oDASTt9pk7nbZ4TpM/UTOdCqai9YuGO2RhaKQqxHB2oM VYvHeOj09ZBS+qoSByAJgCIMgWEPtgpqX8VeNVqXB2FoYZV0fES97SXN5O8/DgBc05z0 Ge9g== 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=5QP8WHomX2ID/kyx7WoYk6ck6FsKpnx3K9oMCpknifk=; b=bqQ4q12HosT+rJKwDmcl+b+UCybXWeHNbMRbOan3mIqTgeLsds5fpbQwDpHtOASroS gXqRCnTX4xZ6YQSABuDPUtgh+dFjXe3WIEc4rR+VOPXPZiDbw2Xr63Kn9IzSTr2OZHnV UyTZI4tfQxvC0W92N/gSAw4Rr3ZO0FRq3TQcFGQssMIZP89M+YdGuZmh+zfmL1ziP3+X MJZ7jj5jy0FdZ28yK0uZ/PGzyaB7BbpQT3wYLQKRykE4P96Hb1Svm0aD8z2b+Xxkap7v wKhLkN3NZdmZIV8XBAUi1aX5fS/TjsoXTIw6VJykKw/8hnYxGmpeT4wKbdGypBaqD3Ij vL2A== X-Gm-Message-State: AIVw111LUUvRMbiGqhn82i7Jaqf0kAqlHmdE+PqkKW2kcLkqxjOq6cYW 0X8j4wWDjQCW99sHgjYu88CVWt44sMlMbAE= X-Received: by 10.80.213.72 with SMTP id f8mr5655523edj.69.1500637839448; Fri, 21 Jul 2017 04:50:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.138.99 with HTTP; Fri, 21 Jul 2017 04:49:59 -0700 (PDT) In-Reply-To: <007501d301fb$a4caf5a0$ee60e0e0$@ndzh.com> References: <007501d301fb$a4caf5a0$ee60e0e0$@ndzh.com> From: Tony Przygienda Date: Fri, 21 Jul 2017 13:49:59 +0200 Message-ID: To: Susan Hares Cc: idr wg Content-Type: multipart/alternative; boundary="f403045dbcec5b60fa0554d2796a" Archived-At: Subject: Re: [Idr] Summary of IDR Draft action items from IDR meeting X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 11:50:44 -0000 --f403045dbcec5b60fa0554d2796a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Probably an oversight. Following draft was also requested by authors for adoption 4) https://datatracker.ietf.org/doc/draft-idr-bgp-route-refresh-options/ On Fri, Jul 21, 2017 at 10:30 AM, Susan Hares wrote: > IDR WG: > > > > Please review this list of WG LCs and adoptions. Did I miss anyone? Or > did you want to ask and forget to? Send me a note if you want to be on o= ne > of these lists. > > > > Sue Haers > > > > WG LC was requested for: > > 1) draft-ietf-idr-rfc5575bis-04 > > 2) draft-ietf-tunnel-encaps > > 3) draft-ietf-idr-bgp-optimal-route-reflection > > > > WG LC soon was requested by other groups at this IETF ro: > > 1) draft-ietf-idr-bgp-extended-messages > > 2) drat-ietf-idr-ls-trill > > > > Indication that quick transition from WG Adoption to WG LC > > 1) draft-idr-bgp-ls-segment-routing-msd > > > > Request for WG Adoption call: > > 1) draft-li-idr-congestion-status > > 2) draft-li-idr-flowspec-populate-to-fib-01 > > 3) draft-acee-idr-lldp-peer-discovery > > > > People are interested in an interim that discusses linking BGP to a link > later. > > Target time: Early September > > > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > --=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 --f403045dbcec5b60fa0554d2796a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Probably an oversight.=C2=A0

Following = draft was also requested by authors for adoption=C2=A0


On Fri, Jul 21, 2017 at 10:30 AM, Susan Hares <shares@ndzh.com<= /a>> wrote:

IDR WG:

=C2=A0

Please review this list = of WG LCs and adoptions.=C2=A0 Did I miss anyone? Or did you want to ask an= d forget to?=C2=A0 Send me a note if you want to be on one of these lists. =

=C2=A0

Sue Haers

= =C2=A0

WG LC was requested for: =

1)= =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 draft-ietf-idr-rfc5575bis-04

2)=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 draft-ietf-tunnel-encaps

3)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= draft-ietf-idr-bgp-optimal-route-reflection <= /u>

=C2=A0

WG LC soon was requested by other groups at this IETF ro: <= u>

= 1)=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 draft-ietf-idr-bgp-extended-messages= =C2=A0

2)=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 drat-ietf-idr-ls-trill<= /u>

=C2=A0

Indication that quick transition from WG Adoption to WG LC =

1)=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 draft-idr-bgp-ls-segment-routing-= msd

=C2=A0

Request for WG Adoption call:

1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 draft-li-idr-congestion-status

2)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 draft-li-idr-flowspec-populate-to-fib-01=

3)=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 draft-acee-idr-lldp-peer-discovery<= u>

=C2=A0

People are interested in an interim that discusses linking BGP to a li= nk later.

Target time:=C2=A0 Early= September

=C2=A0

=C2=A0


___________= ____________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr




--
=
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
--f403045dbcec5b60fa0554d2796a-- From nobody Fri Jul 21 08:31:54 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8C5C131C15 for ; Fri, 21 Jul 2017 08:31:52 -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 Qkg-UFhqrkaH for ; Fri, 21 Jul 2017 08:31:51 -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 806CA131C0E for ; Fri, 21 Jul 2017 08:31:51 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=62.168.35.67; From: "Susan Hares" To: "'Tony Przygienda'" Cc: "'idr wg'" References: <007501d301fb$a4caf5a0$ee60e0e0$@ndzh.com> In-Reply-To: Date: Fri, 21 Jul 2017 11:09:07 -0400 Message-ID: <009b01d30233$4db96660$e92c3320$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009C_01D30211.C6AA1050" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJKrhvU8dNCUEvqmLf569eqoaFLFQKUBckPoVpqF0A= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] Summary of IDR Draft action items from IDR meeting X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 15:31:53 -0000 This is a multipart message in MIME format. ------=_NextPart_000_009C_01D30211.C6AA1050 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Tony P;=20 =20 Yep =E2=80=93 an oversight. I=E2=80=99ll add it to the list.=20 =20 Sue=20 =20 From: Tony Przygienda [mailto:tonysietf@gmail.com]=20 Sent: Friday, July 21, 2017 7:50 AM To: Susan Hares Cc: idr wg Subject: Re: [Idr] Summary of IDR Draft action items from IDR meeting =20 Probably an oversight.=20 =20 Following draft was also requested by authors for adoption=20 =20 4) https://datatracker.ietf.org/doc/draft-idr-bgp-route-refresh-options/ =20 On Fri, Jul 21, 2017 at 10:30 AM, Susan Hares wrote: IDR WG:=20 =20 Please review this list of WG LCs and adoptions. Did I miss anyone? Or = did you want to ask and forget to? Send me a note if you want to be on = one of these lists.=20 =20 Sue Haers=20 =20 WG LC was requested for:=20 1) draft-ietf-idr-rfc5575bis-04 2) draft-ietf-tunnel-encaps 3) draft-ietf-idr-bgp-optimal-route-reflection=20 =20 WG LC soon was requested by other groups at this IETF ro:=20 1) draft-ietf-idr-bgp-extended-messages =20 2) drat-ietf-idr-ls-trill =20 Indication that quick transition from WG Adoption to WG LC=20 1) draft-idr-bgp-ls-segment-routing-msd=20 =20 Request for WG Adoption call:=20 1) draft-li-idr-congestion-status=20 2) draft-li-idr-flowspec-populate-to-fib-01 3) draft-acee-idr-lldp-peer-discovery =20 People are interested in an interim that discusses linking BGP to a link = later.=20 Target time: Early September=20 =20 =20 _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr =20 --=20 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 ------=_NextPart_000_009C_01D30211.C6AA1050 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Tony P;

 

Yep =E2=80=93 an oversight. =C2=A0I=E2=80=99ll add it to the list. =

 

Sue

 

From:= = Tony Przygienda [mailto:tonysietf@gmail.com]
Sent: Friday, = July 21, 2017 7:50 AM
To: Susan Hares
Cc: idr = wg
Subject: Re: [Idr] Summary of IDR Draft action items from = IDR meeting

 

Probably an oversight. 

 

Following draft was also requested by authors for = adoption 

 

 

On Fri, = Jul 21, 2017 at 10:30 AM, Susan Hares <shares@ndzh.com> = wrote:

IDR WG: =

 <= /o:p>

Please = review this list of WG LCs and adoptions.  Did I miss anyone? Or = did you want to ask and forget to?  Send me a note if you want to = be on one of these lists.

 <= /o:p>

Sue Haers =

 <= /o:p>

WG LC was = requested for:

1)      = draft-ietf-idr-rfc5575bis-04

2)      = draft-ietf-tunnel-encaps

3)      = draft-ietf-idr-bgp-optimal-route-reflection

 <= /o:p>

WG LC soon = was requested by other groups at this IETF ro:

1)      = draft-ietf-idr-bgp-extended-messages 

2)      = drat-ietf-idr-ls-trill

 <= /o:p>

Indication = that quick transition from WG Adoption to WG LC

1)      = draft-idr-bgp-ls-segment-routing-msd

 <= /o:p>

Request for = WG Adoption call:

1)      = draft-li-idr-congestion-status

2)      = draft-li-idr-flowspec-populate-to-fib-01

3)      = draft-acee-idr-lldp-peer-discovery

 <= /o:p>

People are = interested in an interim that discusses linking BGP to a link later. =

Target = time:  Early September

 <= /o:p>

 <= /o:p>


______________________________________= _________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr



 

-- =

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

------=_NextPart_000_009C_01D30211.C6AA1050-- From nobody Fri Jul 21 14:20:48 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 843C9129A9F for ; Fri, 21 Jul 2017 14:20:47 -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 P8PEbPyoGwJe for ; Fri, 21 Jul 2017 14:20:46 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D552C1200FC for ; Fri, 21 Jul 2017 14:20:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1809; q=dns/txt; s=iport; t=1500672045; x=1501881645; h=to:cc:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=L3GOqXH75eMrtJx/YZwjwWV2ZB8cR3GcnjyOQiyybyw=; b=aPNzOiQKiWcV1wNdLHBU9JWICkUpiyNTu2ovitbyLz4+L73WKjKWBmJu mCePlHNPqfg4fXm0eGSYhBmv8u45WuHVllG4uwqzn3QSb9EhJtsHIFlUj ljAL2XRt6CN3DsWq2jD9HxnIMMBrs9mkyfuHH+MC1cVQRzVQZi1YKpgfd 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAgBhb3JZ/5xdJa1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1q6AIVHhABCFQECAQEBAQEBAWsohUIPAUYpDAImAl8NCAEBiiuuPYI?= =?us-ascii?q?mixoBAQEBBgEBAQEBI4ELgh2DTYFhK4cpg02CYQWRaY1jgWiSM4IMhVCDVYcFS?= =?us-ascii?q?JUbNSKBCjEhCBsVh38gij0BAQE?= X-IronPort-AV: E=Sophos;i="5.40,392,1496102400"; d="scan'208";a="457246013" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jul 2017 21:20:44 +0000 Received: from [10.155.125.249] (dhcp-10-155-124-4-125-249.cisco.com [10.155.125.249]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v6LLKiMP000597; Fri, 21 Jul 2017 21:20:44 GMT To: Jeff Haas Cc: "idr@ietf.org" From: Enke Chen Message-ID: <441c2f03-e061-726a-4b14-14c452d25f2e@cisco.com> Date: Fri, 21 Jul 2017 14:20:44 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [Idr] Comments on slides-99-idr-03-idr-rs-bfd_ietf99-00.pdf X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 21:20:47 -0000 Hi, Jeff: I have several comments on slides-99-idr-03-idr-rs-bfd_ietf99-00.pdf, Page 10 "Why not add-paths?": •Some IXPs do not want to use add-paths or their customers may not want to use it. >Enke: Do we understand the reasons? Please also note that the add-path can be >Enke: deployed one a per-neighbor basis. • Which backup path? Degenerate case becomes add paths all. >Enke: The RS uses a route selection algorithm for the bestpath calculation. >Enke: Is there an issue with using the same algorithm (with the bestpath >Enke: excluded) for selecting the backup path? • Add-paths is intended for iBGP See non-deployed work in draft - pmohapat-idr-fast-conn-restore for eBGP >Enke: It is true that in general there are potential issues with using add-path >Enke: for EBGP and that is not recommended. >Enke: >Enke: But that is not true for this special RS case. The deployment practice >Enke: recommended by RFC 7947 is to have the clients in "receive-only" mode. That >Enke: is, each client advertises only its bestpath to the RS. Thus all the paths >Enke: advertised by the RS are valid and can be used for forwarding. It is really >Enke: equivalent to having full or partial mesh of EBGP peers. I do not see any >Enke: issue with "protocol correctness" in this special case. It is actually a >Enke: good use case (perhaps the only one) for EBGP add-path. • Example peer scale from DE - CIX at their Frankfort exchange: • 1069 physical ports, 858 logical • This means that in some cases, path diversity may be *very* high. However, connectivity issues may be based on connectivity issues within the exchange. >Enke: Can we get the actual data on "prefix vs path" as a reference for "path >Enke: diversity"? Thanks. -- Enke From nobody Fri Jul 21 16:09:12 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CBBC12F3D0 for ; Fri, 21 Jul 2017 16:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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 CRZZ11u7TTZe for ; Fri, 21 Jul 2017 16:09:09 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45BE6127B57 for ; Fri, 21 Jul 2017 16:09:09 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id q2so27250496ioe.3 for ; Fri, 21 Jul 2017 16:09:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=tGjChGnoYI4gYXLqhXejiyAVdKNAhFxn0gDTDRd96gg=; b=QDDppcrNtbRi3j65nlE7S/QVUpbYcfLLtCno2+ipgE8zmquBMgM/ZuHHMHnGJNO0e8 AHvdXFWzEwoTq2Cqm4iGFjF5HNTeS77lN9nm/g6Cf/ApJUoyy6iyotf95B/Jx5zwwjyl QwQhAnZ9FQ5EZbGl9uyCfsX8e/zqrlYF7cgsiz+h6zwTN+QP4DSF1tQxqUEC8MBTp8mA 908fW/aieGOzSV7sW5xVw2VgHvEpSqvCnf7NGjGDZEH1KokaxJtWM2/uiMiBuxCy7DWh RRjvovS1PVRHeZUic6rZG/IIFUktInGn2jTwI6dOIdnvFIs6tAIbI2rpstDVrgd+932Y 9xyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=tGjChGnoYI4gYXLqhXejiyAVdKNAhFxn0gDTDRd96gg=; b=AMRHlFDJtZDTvE/1uh758qrkzOir6aSWz/H8qJa9pUlmV5k4Kbdhd1+oQycJtk3viH 1RG4ATMjy4iSTflOvAiq/0gn2Tjb9Ychj3gi4IQlPJz2Hoq0g4qpVEBYCB7rwsx2AbDv koRybNehscei0FP9s6k4KDdiPltp1C9ULk7UlaqS3VonEKSYU1+VIP7jc+TgQPtoIPbr 4laFSK9yT2DRCxTfb1mCxODTE/EfLD/8VyTY2YeGKG9F1g9eVrEsMevxfbTFDxnNZKeq SiYoxb516/veGX4OGKo1yedRHa2599ztIad8KpVxWVYr4C+MGYb6t+SMEM2+VA9hVZdk 5KHw== X-Gm-Message-State: AIVw1136EWXtr5mju3xElDZWQ7rV90MJ3D9wADF4wT8VyPBMEYlXey3Q 6owrwqh8Shqe+mToRQZbdyansht56g== X-Received: by 10.107.175.136 with SMTP id p8mr2619033ioo.219.1500678548560; Fri, 21 Jul 2017 16:09:08 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.153.21 with HTTP; Fri, 21 Jul 2017 16:09:07 -0700 (PDT) In-Reply-To: <441c2f03-e061-726a-4b14-14c452d25f2e@cisco.com> References: <441c2f03-e061-726a-4b14-14c452d25f2e@cisco.com> From: Robert Raszuk Date: Sat, 22 Jul 2017 01:09:07 +0200 X-Google-Sender-Auth: 96iCC0ds61WdufnH3WNWWxRpQ5Y Message-ID: To: Enke Chen Cc: Jeff Haas , "idr@ietf.org" Content-Type: multipart/alternative; boundary="001a11447f72cf24b10554dbf396" Archived-At: Subject: Re: [Idr] Comments on slides-99-idr-03-idr-rs-bfd_ietf99-00.pdf X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 23:09:10 -0000 --001a11447f72cf24b10554dbf396 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =E2=80=8BHi Enke,=E2=80=8B > >Enke: Can we get the actual data on "prefix vs path" as a reference for > "path > >Enke: diversity"? > > Thanks. -- Enke > I have written small script to produce actual data you asked for from quoted in the slides IX: 1 path - 174868 prefixes 2 paths - 36877 prefixes No prefixes with 3 or more paths. So to send all paths to all clients in this exchange each client's ASBR will burn extra 4.22 MB of RAM if b_path size is 120 bytes or 7 MB if b_path size is 200 bytes. Kind regards, //RR. --001a11447f72cf24b10554dbf396 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=E2=80=8BHi Enke,=E2=80=8B
=C2=A0
=
>Enke: Can we get the actual data on &quo= t;prefix vs path" as a reference for "path
>Enke: diversity"?

Thanks.=C2=A0 -- Enke

I have written small script to produce actual data you asked for from quo= ted in the slides IX:

= 1 path - 174868 prefixes
2 paths - 36877 prefixes

No prefixes with 3 or m= ore paths. =C2=A0

So t= o send all paths to all clients in this exchange each client's ASBR wil= l burn extra 4.22 MB of RAM if b_path size is 120 bytes or 7 MB if b_path s= ize is 200 bytes.=C2=A0

Kind regards,
//RR.
<= br>
--001a11447f72cf24b10554dbf396-- From nobody Sat Jul 22 00:34:28 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6558E131BB3 for ; Sat, 22 Jul 2017 00:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 XIwfLCwv31Lt for ; Sat, 22 Jul 2017 00:34:25 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FADA126B6E for ; Sat, 22 Jul 2017 00:34:25 -0700 (PDT) X-Original-To: idr@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 2CBF241BFC for ; Sat, 22 Jul 2017 09:34:23 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 0270541BFA; Sat, 22 Jul 2017 09:34:23 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id DDBF035D27; Sat, 22 Jul 2017 09:34:22 +0200 (CEST) Date: Sat, 22 Jul 2017 09:34:22 +0200 From: Gert Doering To: Robert Raszuk Cc: Enke Chen , Jeff Haas , "idr@ietf.org" Message-ID: <20170722073422.GI45648@Space.Net> References: <441c2f03-e061-726a-4b14-14c452d25f2e@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [Idr] Comments on slides-99-idr-03-idr-rs-bfd_ietf99-00.pdf X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 07:34:27 -0000 Hi, On Sat, Jul 22, 2017 at 01:09:07AM +0200, Robert Raszuk wrote: > I have written small script to produce actual data you asked for from > quoted in the slides IX: > > 1 path - 174868 prefixes > 2 paths - 36877 prefixes > > No prefixes with 3 or more paths. Which IX data is this based on? I'm asking because at DECIX, there are peers that have 3 or 4 routers from the same AS on the DECIX fabric, so these peers alone would contribute 3+ paths - same AS path(!), but different next-hops... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Sat Jul 22 03:23:34 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 482D9131DAA for ; Sat, 22 Jul 2017 03:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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 6fTl_0FAvkg4 for ; Sat, 22 Jul 2017 03:23:32 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 D91BA13150C for ; Sat, 22 Jul 2017 03:23:31 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id v205so350147itf.1 for ; Sat, 22 Jul 2017 03:23:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=yctsfN6Ar9iUO1+GhyKl/n83gVeGebwQelVhJ3JE3PE=; b=NGTPuWXQ2VA8ghcNia+Tqc60Jb+lX+XkZl45jZ3e9WbOjZpF5j5BVlgiKxixvxn9vF /vDy2kyZO1vxRR0JJG8agqrzjm3BRqj60j5B+4AZLwL2UWRrjoMIQMwwE9DIVo82olv6 CiSTA9MZhb6dsW4TVN27S2hSoe5XbawX7S9jdxR2qTXrh60UOlYCueSC8SxZ0shf4Bgx 8QdeLSRFKYzHAe1LcWmb9MrcArQFBLGc2kGpv402Yg4oORGYIuej0ayO8avhGmkPVSTH Wa0yi2uizeRvzwnGlwpxX2eM1UvxFsqGzWgBRbHC1gSc92/thM5Gd9PTeQANvf70P2B1 m/OQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=yctsfN6Ar9iUO1+GhyKl/n83gVeGebwQelVhJ3JE3PE=; b=bhGl8VsgARMWZQGpdcHrfULbaiTTp5betosybH5rYwTWCHv4spfmlBneVBL3iJUyRY O4p8cmSvMMyMeNnULTrYr1+Fn9irgdAueM3318F2JhQUu7H/hf296hBa/W50OhqC67yM HTZ7uhGhFmqCubNXZvC30/G2cYE/UBDTrosp+vmNpq5bHnrg3NWhfmT/EZnzdjNIXS/k yG4MbiQMnVE2H+lykvbWZKAWLuR834AQKVL+fYX8juSb4xwtJwj65Rt34GRCCS/rft9W V/z/SPdBL1gowoeivXqPoyMI5+HLHkk0W2MhobgKTotgswHenMSMQEpQnjQeyKSU3k/0 7q2A== X-Gm-Message-State: AIVw112j531JZZLx2zZj2RTFNv0EpkGag50ALMejdx4+T0AIPRwQZvv3 LmqeYFwWtX0COrA/Ecqa+Y8S6VigBA== X-Received: by 10.36.253.71 with SMTP id m68mr1516255ith.16.1500719011009; Sat, 22 Jul 2017 03:23:31 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.153.21 with HTTP; Sat, 22 Jul 2017 03:23:30 -0700 (PDT) In-Reply-To: <20170722073422.GI45648@Space.Net> References: <441c2f03-e061-726a-4b14-14c452d25f2e@cisco.com> <20170722073422.GI45648@Space.Net> From: Robert Raszuk Date: Sat, 22 Jul 2017 12:23:30 +0200 X-Google-Sender-Auth: uDILPDMVlEIxS-WR2njEbDvSH8g Message-ID: To: Gert Doering Cc: Enke Chen , Jeff Haas , "idr@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c11ce4a8f19ba0554e55fb8" Archived-At: Subject: Re: [Idr] Comments on slides-99-idr-03-idr-rs-bfd_ietf99-00.pdf X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 10:23:33 -0000 --94eb2c11ce4a8f19ba0554e55fb8 Content-Type: text/plain; charset="UTF-8" Hi Gert, The data I got and used to calculate number of paths indeed *only* assumes different AS_PATH for each prefix to indicate presence of more then one path. There are no paths with different next hops in the RS dump I received. I assumed that the data is complete. Let me ask them again to get the data which will include same AS_PATH + different next hops and as soon as I get it I will repost the result. Cheers, R. On Sat, Jul 22, 2017 at 9:34 AM, Gert Doering wrote: > Hi, > > On Sat, Jul 22, 2017 at 01:09:07AM +0200, Robert Raszuk wrote: > > I have written small script to produce actual data you asked for from > > quoted in the slides IX: > > > > 1 path - 174868 prefixes > > 2 paths - 36877 prefixes > > > > No prefixes with 3 or more paths. > > Which IX data is this based on? > > I'm asking because at DECIX, there are peers that have 3 or 4 routers > from the same AS on the DECIX fabric, so these peers alone would contribute > 3+ paths - same AS path(!), but different next-hops... > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > --94eb2c11ce4a8f19ba0554e55fb8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Gert,

The data I got and used to calculate number of paths= indeed *only* assumes different AS_PATH for each prefix to indicate presen= ce of more then one path. There are no paths with different next hops in th= e RS dump I received. I assumed that the data is complete.=C2=A0

Let me ask them again to get the= data which will include same AS_PATH + different next hops and as soon as = I get it I will repost the result.=C2=A0

=
Cheers,
R.

On Sat, Jul 22, 2017 at 9:3= 4 AM, Gert Doering <gert@space.net> wrote:
Hi,

On Sat, Jul 22, 2017 at 01:09:07AM +0200, Robert Raszuk wrote:
> I have written small script to produce actual data you asked for from<= br> > quoted in the slides IX:
>
> 1 path - 174868 prefixes
> 2 paths - 36877 prefixes
>
> No prefixes with 3 or more paths.

Which IX data is this based on?

I'm asking because at DECIX, there are peers that have 3 or 4 routers from the same AS on the DECIX fabric, so these peers alone would contribute=
3+ paths - same AS path(!), but different next-hops...

Gert Doering
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Aufsichtsratsvo= rs.: A. Grundner-Culemann
D-80807 Muenchen=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0HRB: 136055 (AG Muenchen)
Tel: = +49 (0)89/32356-444=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0USt-IdNr.: = DE813185279

--94eb2c11ce4a8f19ba0554e55fb8-- From nobody Sat Jul 22 09:01:35 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC04129B55 for ; Sat, 22 Jul 2017 09:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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 1jtykhcWzkLj for ; Sat, 22 Jul 2017 09:01:32 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 D719E12426E for ; Sat, 22 Jul 2017 09:01:31 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id v205so5795167itf.1 for ; Sat, 22 Jul 2017 09:01:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=m6KaSLFjo9Cx3KsnqgKBCz3lHOcTSFaG74CT5OHIAJ0=; b=RtX7EVE6Vkw+9Ruga6nMEZCyDqE/WMmlX5R5cug8UKiTrPLBzE2KXicDzosHABD0IX vOaWufjIb2281RMXW/Y2274lMbsT1cUgP2LUChx22qsKNKqKjCe+nMVvvjNoJM0re6Zo jPnAp2VD5+f/HU3d/PS0E5OviiH6enrgAoDlXIsLaI96S6bNPjpIHkNe0b0MLK4xR4oe t+RPK8sAv0bmk1KKLLbJI84bR9opbMVL7/17tfkZGtIolviMDljweLVeBHVN80srIV83 ePxNcWBnfxD6xA1G1v9f1BEY5nYwggIFyNcctAI++y2awFI3pn2u2Qu+167g/6vjlrm4 xGtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=m6KaSLFjo9Cx3KsnqgKBCz3lHOcTSFaG74CT5OHIAJ0=; b=anNVU9JFHw7b1akKSYBOSN4iu3s1mWWy5MuF9HFsEwC3n/IP2bIk0JoVORsrU/q0mt ItKmym8hqGHB1F41sQMHTHlqKB0ty2XkeN9rGK++/VwL7J+jdP9EATNG9f7Ow4WSZ7uM TrgZntKdU0bsBs2Qk8rcqaBXNSOut+f1BCfkd9rG1jGdyFe+1WXsE/HcKBQqdtg4bV79 XG30aLPKFfSkjLzoUv2Uc29l7SQZ8e7qw0mXEVqddeJ14F7jmfGaLoq9qjQ31tUTKUqp VyDB0jOVYAM86Y0I1beOQVSfCJEMnXtwm9MjKynjSQPRaGcDhWqMrUzOT+xh1NZC/l7o RPCg== X-Gm-Message-State: AIVw111s45dNS9eq0EDpmmp8g5CH59I9CpKJzbmrv7XjqctvuU5EgAQ3 V2iTvzPEY0qcfuocP+3YPRy1Zgn+Cw== X-Received: by 10.36.105.82 with SMTP id e79mr2401858itc.118.1500739290995; Sat, 22 Jul 2017 09:01:30 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.153.21 with HTTP; Sat, 22 Jul 2017 09:01:30 -0700 (PDT) In-Reply-To: References: <441c2f03-e061-726a-4b14-14c452d25f2e@cisco.com> <20170722073422.GI45648@Space.Net> From: Robert Raszuk Date: Sat, 22 Jul 2017 18:01:30 +0200 X-Google-Sender-Auth: bdp6pVFMwrwHuCCqR_Sndxr2dzE Message-ID: To: Gert Doering Cc: Enke Chen , Jeff Haas , "idr@ietf.org" Content-Type: multipart/alternative; boundary="001a1145a6b65720fe0554ea181b" Archived-At: Subject: Re: [Idr] Comments on slides-99-idr-03-idr-rs-bfd_ietf99-00.pdf X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 16:01:33 -0000 --001a1145a6b65720fe0554ea181b Content-Type: text/plain; charset="UTF-8" Hi, Thanks to Gert's comment I now asked for full complete dump which will include *all* paths on the RS in question including those with identical AS_PATH, but different next hops. Here is the distribution from one major RS in Europe: *prefixes paths * 123453 1 48165 2 25069 3 10316 4 6511 5 2347 6 1227 7 556 8 560 9 254 10 17 11 4 12 2 15 1 18 1 19 1 20 1 24 1 29 I also did similar count for one RS in US: 81498 1 11207 2 590 3 71 4 4 5 1 6 1 8 Another RS in US: 27017 1 448 2 52 3 One RS in Japan: 9214 1 518 2 25 3 7 4 If there are other IX operators and would like to send me offline their full BGP dump I can provide more summary data to the list. Hope this helps, Robert. - - - On Sat, Jul 22, 2017 at 12:23 PM, Robert Raszuk wrote: > Hi Gert, > > The data I got and used to calculate number of paths indeed *only* assumes > different AS_PATH for each prefix to indicate presence of more then one > path. There are no paths with different next hops in the RS dump I > received. I assumed that the data is complete. > > Let me ask them again to get the data which will include same AS_PATH + > different next hops and as soon as I get it I will repost the result. > > Cheers, > R. > > On Sat, Jul 22, 2017 at 9:34 AM, Gert Doering wrote: > >> Hi, >> >> On Sat, Jul 22, 2017 at 01:09:07AM +0200, Robert Raszuk wrote: >> > I have written small script to produce actual data you asked for from >> > quoted in the slides IX: >> > >> > 1 path - 174868 prefixes >> > 2 paths - 36877 prefixes >> > >> > No prefixes with 3 or more paths. >> >> Which IX data is this based on? >> >> I'm asking because at DECIX, there are peers that have 3 or 4 routers >> from the same AS on the DECIX fabric, so these peers alone would >> contribute >> 3+ paths - same AS path(!), but different next-hops... >> >> Gert Doering >> -- NetMaster >> -- >> have you enabled IPv6 on something today...? >> >> SpaceNet AG Vorstand: Sebastian v. Bomhard >> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. >> Grundner-Culemann >> D-80807 Muenchen HRB: 136055 (AG Muenchen) >> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 >> > > --001a1145a6b65720fe0554ea181b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small">Thanks to Gert's comment I now asked for full complet= e dump which will include *all* paths on the RS in question including those= with identical AS_PATH, but different next hops.=C2=A0

Here is the distribution from one major R= S in Europe:=C2=A0

= prefixes =C2=A0 =C2=A0paths=C2=A0

=C2=A0123453 1
=C2=A0 48165 2
=C2=A0 25069 3
=C2=A0 10316 4
<= font face=3D"monospace, monospace">=C2=A0 =C2=A06511 5
=C2=A0 =C2=A02347 = 6
=C2=A0 =C2=A01227 7
=C2=A0 =C2=A0 556 8
=C2=A0 =C2=A0 560 9<= /div>
=C2= =A0 =C2=A0 254 10
=C2=A0 =C2=A0 =C2=A017 11
=C2=A0 =C2=A0 =C2=A0 4 12
=C2=A0 =C2=A0 =C2=A0 2 15
=C2=A0 =C2=A0 =C2=A0 1 18
=C2=A0 =C2=A0 =C2= =A0 1 19
=C2=A0 =C2=A0 =C2=A0 1 20
=C2=A0 =C2=A0 =C2=A0 1 24
=C2=A0 = =C2=A0 =C2=A0 1 29

I also did similar count for one RS in US:=C2=A0

=C2=A0 = 81498 1
=C2=A0 11207 2
=C2=A0 =C2=A0 590 3
=C2=A0 =C2=A0 =C2=A071 4
=C2=A0 =C2=A0 =C2=A0 4 5
=C2=A0 =C2=A0 =C2=A0 1 6
=C2=A0 =C2=A0 =C2=A0= 1 8

Anot= her RS in US:=C2=A0

=C2=A0 27017 1
=C2=A0 =C2=A0 448 2
=
=C2=A0 =C2= =A0 =C2=A052 3

One RS in Japan:

=C2=A0 =C2=A09214 1
=C2=A0 =C2=A0 518 2=
=C2= =A0 =C2=A0 =C2=A025 3
=C2=A0 =C2=A0 =C2=A0 7 4

If there are other IX operators a= nd would like to send me offline their full BGP dump I can provide more sum= mary data to the list.=C2=A0

Hope this helps,
Robert.

- - -=C2=A0
<= br>
On Sat, Jul = 22, 2017 at 12:23 PM, Robert Raszuk <robert@raszuk.net> wrot= e:
Hi Gert= ,

The data I got and used to calculate number of paths indeed *only* a= ssumes different AS_PATH for each prefix to indicate presence of more then = one path. There are no paths with different next hops in the RS dump I rece= ived. I assumed that the data is complete.=C2=A0

Let me ask them again= to get the data which will include same AS_PATH + different next hops and = as soon as I get it I will repost the result.=C2=A0

Cheers,
R.

On Sat, Jul 22, 2017 at 9:34 AM, Ger= t Doering <gert@space.net> wrote:
Hi,

On Sat, Jul 22, 2017 at 01:09:07AM +0200, Robert Raszuk wrote:
> I have written small script to produce actual data you asked for from<= br> > quoted in the slides IX:
>
> 1 path - 174868 prefixes
> 2 paths - 36877 prefixes
>
> No prefixes with 3 or more paths.

Which IX data is this based on?

I'm asking because at DECIX, there are peers that have 3 or 4 routers from the same AS on the DECIX fabric, so these peers alone would contribute=
3+ paths - same AS path(!), but different next-hops...
=
Gert Doering
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Aufsichtsratsvo= rs.: A. Grundner-Culemann
D-80807 Muenchen=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0USt-IdNr.: DE813185279


--001a1145a6b65720fe0554ea181b-- From nobody Sat Jul 22 13:12:15 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D533613169C for ; Sat, 22 Jul 2017 13:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.88 X-Spam-Level: X-Spam-Status: No, score=-0.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 zssa4EwtpNVW for ; Sat, 22 Jul 2017 13:12:11 -0700 (PDT) Received: from ex2.workonline.co.za (ex2.workonline.co.za [197.157.92.103]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35BF1127342 for ; Sat, 22 Jul 2017 13:12:09 -0700 (PDT) Received: from EX1.workonline.co.za ([fe80::f84f:93b7:a923:f286]) by ex2.workonline.co.za ([fe80::8572:d946:2c81:17bb%15]) with mapi id 14.02.0387.000; Sat, 22 Jul 2017 22:12:04 +0200 From: Ben Maddison CC: "robert@raszuk.net" , "idr@ietf.org" Thread-Topic: [Idr] Comments on slides-99-idr-03-idr-rs-bfd_ietf99-00.pdf Thread-Index: AQHTAmdNxwbqwqjYhkCnccjQyWPWr6Jexl+AgACNKgCAAC9BAIAAXnAAgABnfe0= Date: Sat, 22 Jul 2017 20:11:56 +0000 Message-ID: <874E439F335FD742B8D1565730E537E0013F1DF24A@ex1.workonline.co.za> References: <441c2f03-e061-726a-4b14-14c452d25f2e@cisco.com> <20170722073422.GI45648@Space.Net> , In-Reply-To: Accept-Language: en-ZA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Hiri/1.1.0.0 x-originating-ip: [87.200.50.51] Content-Type: multipart/alternative; boundary="_000_874E439F335FD742B8D1565730E537E0013F1DF24Aex1workonline_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] Comments on slides-99-idr-03-idr-rs-bfd_ietf99-00.pdf X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 20:12:14 -0000 --_000_874E439F335FD742B8D1565730E537E0013F1DF24Aex1workonline_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Robert, Thanks for the useful and interesting info. I'd point out that the addition of ADD_PATH to the RS at a given IXP would = remove one (of many) of the operational issues present in the use of an RS = by a participant that operates a selective policy, and may therefore increa= se participation. The numbers below should therefore be taken as a baseline from which path d= iversity may grow if implemented. By how much it might grow is of course do= wn to guesswork that I won't get into. Cheers, Ben -- Sent from Hiri On 2017-07-22 18:02:07+02:00 Robert Raszuk wrote: Hi, Thanks to Gert's comment I now asked for full complete dump which will incl= ude *all* paths on the RS in question including those with identical AS_PAT= H, but different next hops. Here is the distribution from one major RS in Europe: prefixes paths 123453 1 48165 2 25069 3 10316 4 6511 5 2347 6 1227 7 556 8 560 9 254 10 17 11 4 12 2 15 1 18 1 19 1 20 1 24 1 29 I also did similar count for one RS in US: 81498 1 11207 2 590 3 71 4 4 5 1 6 1 8 Another RS in US: 27017 1 448 2 52 3 One RS in Japan: 9214 1 518 2 25 3 7 4 If there are other IX operators and would like to send me offline their ful= l BGP dump I can provide more summary data to the list. Hope this helps, Robert. - - - On Sat, Jul 22, 2017 at 12:23 PM, Robert Raszuk > wrote: Hi Gert, The data I got and used to calculate number of paths indeed *only* assumes = different AS_PATH for each prefix to indicate presence of more then one pat= h. There are no paths with different next hops in the RS dump I received. I= assumed that the data is complete. Let me ask them again to get the data which will include same AS_PATH + dif= ferent next hops and as soon as I get it I will repost the result. Cheers, R. On Sat, Jul 22, 2017 at 9:34 AM, Gert Doering > wrote: Hi, On Sat, Jul 22, 2017 at 01:09:07AM +0200, Robert Raszuk wrote: > I have written small script to produce actual data you asked for from > quoted in the slides IX: > > 1 path - 174868 prefixes > 2 paths - 36877 prefixes > > No prefixes with 3 or more paths. Which IX data is this based on? I'm asking because at DECIX, there are peers that have 3 or 4 routers from the same AS on the DECIX fabric, so these peers alone would contribute 3+ paths - same AS path(!), but different next-hops... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-I= dNr.: DE813185279 --_000_874E439F335FD742B8D1565730E537E0013F1DF24Aex1workonline_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Robert,

Thanks for the useful and interesting info.
I'd point out that the addition of ADD_PATH to the RS at a given IXP would = remove one (of many) of the operational issues present in the use of an RS = by a participant that operates a selective policy, and may therefore increa= se participation.
The numbers below should therefore be taken as a baseline from which path d= iversity may grow if implemented. By how much it might grow is of course do= wn to guesswork that I won't get into.

Cheers,

Ben
 
--
Sent from Hiri
 

On 2017-07-22 18:02:07+02:00 Robert Raszuk wrote:

Hi,
Thanks to Gert's comment I now asked for full complete dump which will incl= ude *all* paths on the RS in question including those with identical AS_PAT= H, but different next hops. 
Here is the distribution from one major RS in Europe: 
prefixes    paths 
 1234= 53 1
  481= 65 2
  250= 69 3
  103= 16 4
  &nb= sp;6511 5
  &nb= sp;2347 6
  &nb= sp;1227 7
  &nb= sp; 556 8
  &nb= sp; 560 9
  &nb= sp; 254 10
  &nb= sp;  17 11
  &nb= sp;   4 12
  &nb= sp;   2 15
  &nb= sp;   1 18
  &nb= sp;   1 19
  &nb= sp;   1 20
  &nb= sp;   1 24
  &nb= sp;   1 29
I also did similar count for one RS in US: 
  814= 98 1
  112= 07 2
  &nb= sp; 590 3
  &nb= sp;  71 4
  &nb= sp;   4 5
  &nb= sp;   1 6
  &nb= sp;   1 8
Another RS in US: 
  270= 17 1
  &nb= sp; 448 2
  &nb= sp;  52 3
One RS in Japan:
  &nb= sp;9214 1
  &nb= sp; 518 2
  &nb= sp;  25 3
  &nb= sp;   7 4
If there are other IX operators and would like to send me offline their ful= l BGP dump I can provide more summary data to the list. 
Hope this helps,
Robert.
- - - 
On Sat, Jul 22, 2017 at 12:23 PM, Robert Raszuk = <robert@raszuk.ne= t> wrote:
Hi Ge= rt,
The d= ata I got and used to calculate number of paths indeed *only* assumes diffe= rent AS_PATH for each prefix to indicate presence of more then one path. Th= ere are no paths with different next hops in the RS dump I received. I assumed that the data is complete. =
Let m= e ask them again to get the data which will include same AS_PATH + diff= erent next hops and as soon as I get it I will repost the result. 
Cheer= s,
R.
 
On Sat, Jul 22, 2017 at 9:34 AM, Gert Doering <gert@space.net&= gt; wrote:
Hi,

On Sat, Jul 22, 2017 at 01:09:07AM +0200, Robert Raszuk wrote: > I have written small script to produce actual data you asked for from<= br> > quoted in the slides IX:
>
> 1 path - 174868 prefixes
> 2 paths - 36877 prefixes
>
> No prefixes with 3 or more paths.

Which IX data is this based on?

I'm asking because at DECIX, there are peers that have 3 or 4 routers
from the same AS on the DECIX fabric, so these peers alone would contribute=
3+ paths - same AS path(!), but different next-hops...

= Gert Doering
        -- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG                  &= nbsp;     Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvo= rs.: A. Grundner-Culemann
D-80807 Muenchen                &nb= sp;  HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdN= r.: DE813185279
--_000_874E439F335FD742B8D1565730E537E0013F1DF24Aex1workonline_-- From nobody Sun Jul 23 19:24:14 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E22C1316A1 for ; Sun, 23 Jul 2017 19:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 n7_HPosW7wcV for ; Sun, 23 Jul 2017 19:24:11 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 9D0C8127735 for ; Sun, 23 Jul 2017 19:24:11 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1dZT2X-0002Ob-Kk; Mon, 24 Jul 2017 02:24:09 +0000 Date: Mon, 24 Jul 2017 11:24:08 +0900 Message-ID: From: Randy Bush To: Susan Hares Cc: Interminable Discussion Room In-Reply-To: <007501d301fb$a4caf5a0$ee60e0e0$@ndzh.com> References: <007501d301fb$a4caf5a0$ee60e0e0$@ndzh.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Idr] Summary of IDR Draft action items from IDR meeting X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 02:24:13 -0000 > WG LC soon was requested by other groups at this IETF ro: > 1) draft-ietf-idr-bgp-extended-messages i do not contest your assertion. but the consensus seemed to be that a major revision was needed to allow *all* message types to be extended. this complicates OPEN message processing. i am still pretending to think about how to deal with this simply. did i say simply? randy From nobody Mon Jul 24 03:05:16 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1479131BC8 for ; Mon, 24 Jul 2017 03:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] 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 G1cVyphH-NNy for ; Mon, 24 Jul 2017 03:05:13 -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 4C098120721 for ; Mon, 24 Jul 2017 03:05:13 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=50.36.80.20; From: "Susan Hares" To: "'Randy Bush'" Cc: "'Interminable Discussion Room'" References: <007501d301fb$a4caf5a0$ee60e0e0$@ndzh.com> In-Reply-To: Date: Mon, 24 Jul 2017 05:59:06 -0400 Message-ID: <014401d30463$7d2a3d70$777eb850$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJKrhvU8dNCUEvqmLf569eqoaFLFQKoKlUFoV4hr2A= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] Summary of IDR Draft action items from IDR meeting X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 10:05:15 -0000 +1 consensus. I understand the difficulty to do this simply. I will send suggestions offlist. Sue -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Randy Bush Sent: Sunday, July 23, 2017 10:24 PM To: Susan Hares Cc: Interminable Discussion Room Subject: Re: [Idr] Summary of IDR Draft action items from IDR meeting > WG LC soon was requested by other groups at this IETF ro: > 1) draft-ietf-idr-bgp-extended-messages i do not contest your assertion. but the consensus seemed to be that a major revision was needed to allow *all* message types to be extended. this complicates OPEN message processing. i am still pretending to think about how to deal with this simply. did i say simply? randy _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Mon Jul 24 13:22:18 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB06131F0B for ; Mon, 24 Jul 2017 13:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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 r1TuQrvbwkCv for ; Mon, 24 Jul 2017 13:22:13 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59DF9131F17 for ; Mon, 24 Jul 2017 13:22:13 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id v205so23598779itf.1 for ; Mon, 24 Jul 2017 13:22:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=9WtMcciAnfjcnTgAR5au9Xqi9G1lFBYsDQI73zvCH64=; b=aVZVnDTOPmye0tfHsqzxbzuft4n9ehKvtJGk8wTf00ZX0UQGSsXxepbB4B7rwNGbL0 LbWM0Lpb4eN8ccLr4XSOOwGFMmoaC0Nam4iWGFZMELko+/2LyTh8PT96GEDMDsbtcil7 jQe9YIklt8AG19CDz4GnF+QouaiaMIZ4jpeIAlKMi4JjlfViAYXSDfc8Hb0M7JV1JZZZ hZCtihVsifnauCJgtU9BkOaUrjhXK4Wa9xGVg5Hm2ZBlu8ecUBndbk6jD0Qwl2APSVlJ SM3kih6QMXP5wmeMZ1lLLx+ijHBBKv1FORUnlkRgbMPUEsrSauN8qLPp9D6AeV8xAAqS elhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=9WtMcciAnfjcnTgAR5au9Xqi9G1lFBYsDQI73zvCH64=; b=owXh1LvRmWLOhl4ageoLz8vwUqwbf0XOraoezWRJlG34l/Uviyc0rvyAjbP29Hu3yp tn86/A+bVVFDkrzP8NXxVpDLGpFd0nkZsdD5C9VAIApIjTS2loAySVobuOEJnpli4ENq hRIVsLDYgqnpqHftVq/6UXJ250uVuVbS9sDbYgR5GgtEFVb49/p2jsNG50zEU+7ssFFk Ko91LcSZf5tRZp7CtkDGBsI9G+Xhq7ucsIldrAHwc9ul3GgKk5iPCZ3O6NFPwqHLC+32 yCrwR2as50VnLJFFn4dcvUVLaDJJGiR9MkwMAdUTpQqroQlxkdT0obrqNaK7rKHVjXgH Qysw== X-Gm-Message-State: AIVw112/flBvC22WT9us1lhCo81h5RIGVOw2M4SHf48RYwE/LjGFrDIy ZQtJWHB21Qwuw3FJHoBcNSw6JrJ5IuEjBO4= X-Received: by 10.36.200.5 with SMTP id w5mr8772212itf.118.1500927732124; Mon, 24 Jul 2017 13:22:12 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.153.21 with HTTP; Mon, 24 Jul 2017 13:22:11 -0700 (PDT) In-Reply-To: <874E439F335FD742B8D1565730E537E0013F1DF24A@ex1.workonline.co.za> References: <441c2f03-e061-726a-4b14-14c452d25f2e@cisco.com> <20170722073422.GI45648@Space.Net> <874E439F335FD742B8D1565730E537E0013F1DF24A@ex1.workonline.co.za> From: Robert Raszuk Date: Mon, 24 Jul 2017 22:22:11 +0200 X-Google-Sender-Auth: pGp6cwA3VLMEyNyw18p4JC8VtTc Message-ID: To: "idr@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c05f77a4e91dd055515f837" Archived-At: Subject: Re: [Idr] Comments on slides-99-idr-03-idr-rs-bfd_ietf99-00.pdf X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 20:22:16 -0000 --94eb2c05f77a4e91dd055515f837 Content-Type: text/plain; charset="UTF-8" Adding one more v4 data point from RS BGP table received from friends in Moscown Internet Exchange: * prefixes paths* 31201 1 11613 2 4379 3 3628 4 1900 5 1451 6 816 7 696 8 317 9 101 10 62 11 62 12 4 13 1 16 1 23 //RR. On Sat, Jul 22, 2017 at 10:11 PM, Ben Maddison wrote: > Hi Robert, > > Thanks for the useful and interesting info. > I'd point out that the addition of ADD_PATH to the RS at a given IXP would > remove one (of many) of the operational issues present in the use of an RS > by a participant that operates a selective policy, and may therefore > increase participation. > The numbers below should therefore be taken as a baseline from which path > diversity may grow if implemented. By how much it might grow is of course > down to guesswork that I won't get into. > > Cheers, > > Ben > > -- > Sent from Hiri > > > On 2017-07-22 18:02:07+02:00 Robert Raszuk wrote: > > Hi, > Thanks to Gert's comment I now asked for full complete dump which will > include *all* paths on the RS in question including those with identical > AS_PATH, but different next hops. > Here is the distribution from one major RS in Europe: > *prefixes paths * > 123453 1 > 48165 2 > 25069 3 > 10316 4 > 6511 5 > 2347 6 > 1227 7 > 556 8 > 560 9 > 254 10 > 17 11 > 4 12 > 2 15 > 1 18 > 1 19 > 1 20 > 1 24 > 1 29 > I also did similar count for one RS in US: > 81498 1 > 11207 2 > 590 3 > 71 4 > 4 5 > 1 6 > 1 8 > Another RS in US: > 27017 1 > 448 2 > 52 3 > One RS in Japan: > 9214 1 > 518 2 > 25 3 > 7 4 > If there are other IX operators and would like to send me offline their > full BGP dump I can provide more summary data to the list. > Hope this helps, > Robert. > - - - > On Sat, Jul 22, 2017 at 12:23 PM, Robert Raszuk > wrote: >> >> Hi Gert, >> The data I got and used to calculate number of paths indeed *only* >> assumes different AS_PATH for each prefix to indicate presence of more then >> one path. There are no paths with different next hops in the RS dump I >> received. I assumed that the data is complete. >> Let me ask them again to get the data which will include same AS_PATH + >> different next hops and as soon as I get it I will repost the result. >> Cheers, >> R. >> >> On Sat, Jul 22, 2017 at 9:34 AM, Gert Doering wrote: >>> >>> Hi, >>> >>> On Sat, Jul 22, 2017 at 01:09:07AM +0200, Robert Raszuk wrote: >>> > I have written small script to produce actual data you asked for from >>> > quoted in the slides IX: >>> > >>> > 1 path - 174868 prefixes >>> > 2 paths - 36877 prefixes >>> > >>> > No prefixes with 3 or more paths. >>> >>> Which IX data is this based on? >>> >>> I'm asking because at DECIX, there are peers that have 3 or 4 routers >>> from the same AS on the DECIX fabric, so these peers alone would >>> contribute >>> 3+ paths - same AS path(!), but different next-hops... >>> >>> Gert Doering >>> -- NetMaster >>> -- >>> have you enabled IPv6 on something today...? >>> >>> SpaceNet AG Vorstand: Sebastian v. Bomhard >>> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. >>> Grundner-Culemann >>> D-80807 Muenchen HRB: 136055 (AG Muenchen) >>> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 >> >> --94eb2c05f77a4e91dd055515f837 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Adding one= more v4 data point from RS BGP table received from friends in Moscown Inte= rnet Exchange:

=C2= =A0 prefixes paths

=C2=A0 31201 1
=C2=A0 11613 2
=C2=A0 = =C2=A04379 3
=C2=A0 =C2=A03628 4
=C2=A0 =C2=A01900 5
=C2=A0 =C2=A01451 6
=C2=A0 =C2=A0 816 7
= =C2=A0 =C2=A0 696 8
=C2=A0 =C2=A0 = 317 9
=C2=A0 =C2=A0 101 10<= /div>
=C2=A0 =C2=A0 =C2=A062 11
=C2=A0 =C2=A0 =C2=A062 12
=C2=A0 =C2=A0 =C2=A0 4 13
=C2=A0 =C2=A0 =C2=A0 1 16
=C2=A0 =C2=A0 =C2=A0 1 23

<= /font>
//RR.
=


On Sat, Jul 22, 2017 at 10:11 PM, = Ben Maddison <benm@workonline.co.za> wrote:
Hi Robert,

Thanks for the useful and interesting info.
I'd point out that the addition of ADD_PATH to the RS at a given IXP wo= uld remove one (of many) of the operational issues present in the use of an= RS by a participant that operates a selective policy, and may therefore in= crease participation.
The numbers below should therefore be taken as a baseline from which path d= iversity may grow if implemented. By how much it might grow is of course do= wn to guesswork that I won't get into.

Cheers,

Ben
=C2=A0
--
Sent from Hiri
=C2=A0

On 2017-07-22 18:02:07+02:00 Robert Raszuk wrote:

Hi,
Thanks to Gert's comment I now asked for full complete dump which will = include *all* paths on the RS in question including those with identical AS= _PATH, but different next hops.=C2=A0
Here is the distribution from one major RS in Europe:=C2=A0
prefixes =C2=A0 =C2=A0paths=C2=A0
=C2=A01234= 53 1
=C2=A0 481= 65 2
=C2=A0 250= 69 3
=C2=A0 103= 16 4
=C2=A0 =C2= =A06511 5
=C2=A0 =C2= =A02347 6
=C2=A0 =C2= =A01227 7
=C2=A0 =C2= =A0 556 8
=C2=A0 =C2= =A0 560 9
=C2=A0 =C2= =A0 254 10
=C2=A0 =C2= =A0 =C2=A017 11
=C2=A0 =C2= =A0 =C2=A0 4 12
=C2=A0 =C2= =A0 =C2=A0 2 15
=C2=A0 =C2= =A0 =C2=A0 1 18
=C2=A0 =C2= =A0 =C2=A0 1 19
=C2=A0 =C2= =A0 =C2=A0 1 20
=C2=A0 =C2= =A0 =C2=A0 1 24
=C2=A0 =C2= =A0 =C2=A0 1 29
I also did similar count for one RS in US:=C2=A0
=C2=A0 814= 98 1
=C2=A0 112= 07 2
=C2=A0 =C2= =A0 590 3
=C2=A0 =C2= =A0 =C2=A071 4
=C2=A0 =C2= =A0 =C2=A0 4 5
=C2=A0 =C2= =A0 =C2=A0 1 6
=C2=A0 =C2= =A0 =C2=A0 1 8
Another RS in US:=C2=A0
=C2=A0 270= 17 1
=C2=A0 =C2= =A0 448 2
=C2=A0 =C2= =A0 =C2=A052 3
One RS in Japan:
=C2=A0 =C2= =A09214 1
=C2=A0 =C2= =A0 518 2
=C2=A0 =C2= =A0 =C2=A025 3
=C2=A0 =C2= =A0 =C2=A0 7 4
If there are other IX operators and would like to send me offline their ful= l BGP dump I can provide more summary data to the list.=C2=A0
Hope this helps,
Robert.
- - -=C2=A0
On Sat, Jul 22, 2017 at 12:23 PM, Robert Raszuk = <robert@raszuk.ne= t> wrote:
Hi Ge= rt,
The d= ata I got and used to calculate number of paths indeed *only* assumes diffe= rent AS_PATH for each prefix to indicate presence of more then one path. Th= ere are no paths with different next hops in the RS dump I received. I assumed that the data is complete.=C2=A0=
Let m= e ask them again to get the data which will include same AS_PATH + differen= t next hops and as soon as I get it I will repost the result.=C2=A0
Cheer= s,
R.
=C2=A0
On Sat, Jul 22, 2017 at 9:34 AM, Gert Doering <gert@space.net&= gt; wrote:
Hi,

On Sat, Jul 22, 2017 at 01:09:07AM +0200, Robert Raszuk wrote:
> I have written small script to produce actual data you asked for from<= br> > quoted in the slides IX:
>
> 1 path - 174868 prefixes
> 2 paths - 36877 prefixes
>
> No prefixes with 3 or more paths.

Which IX data is this based on?

I'm asking because at DECIX, there are peers that have 3 or 4 routers from the same AS on the DECIX fabric, so these peers alone would contribute=
3+ paths - same AS path(!), but different next-hops...

Gert Doering
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Aufsichtsratsvo= rs.: A. Grundner-Culemann
D-80807 Muenchen=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0USt-IdNr.: = DE813185279

--94eb2c05f77a4e91dd055515f837-- From nobody Tue Jul 25 06:27:26 2017 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F703131CB6; Tue, 25 Jul 2017 06:27:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150098924546.26151.5394556418694240110@ietfa.amsl.com> Date: Tue, 25 Jul 2017 06:27:25 -0700 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-bgp-ls-node-admin-tag-extension-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 13:27:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing WG of the IETF. Title : Advertising Node Admin Tags in BGP Link-State Advertisements Authors : Pushpasis Sarkar Hannes Gredler Stephane Litkowski Filename : draft-ietf-idr-bgp-ls-node-admin-tag-extension-02.txt Pages : 11 Date : 2017-07-25 Abstract: This document describes the protocol extensions to collect node administrative tags adevertised in IGP Link State advertisements and disseminate the same in BGP Link-State advertisement protocol, to facilitate inter-AS TE applications that may need the same node administrative tags to associate a subset of network devices spanning across more than one AS with a specific functionality. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-node-admin-tag-extension/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-node-admin-tag-extension-02 https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-node-admin-tag-extension-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-ls-node-admin-tag-extension-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 Tue Jul 25 06:31:36 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3684131C33; Tue, 25 Jul 2017 06:31:34 -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 jVdCD590mHqw; Tue, 25 Jul 2017 06:31:32 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23C6B131CB7; Tue, 25 Jul 2017 06:31:32 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id l82so10973204ywc.2; Tue, 25 Jul 2017 06:31:32 -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=7EciIS7eumFKMjHy96Lu7flwsMubWv5AIIoZFgYskW8=; b=GxEhfV+Eov67DMzesFAYWWnSqqxI1GNLt5+84ztMp0gbHwkciVTGAQrJc+8Sh0eOmI c+vkzgZuDrJyaKTWDZ4L6tK22Y7HLgjt4oGQL/IJ3A2UgNycg77vRDvVYov9SJmsdnbY XNH5qMczBGDZ23wmoCS19BFDHqNkBNEVzj/046yvB5IL9kgg+qm57o291HuvXL+YUlhz PAJZWaIsKREK9jb6yMjvdf8p/THTD5HcHFhwt9Uaar1pedijTBrM8wE5SKtthcRYaAx5 w6r8uTAGu3IumHUpqUTBJ2A7i8unTcd1qfOM9+yradlwtwBCLrE+taU8DqbmBNCQ2axf WYbg== 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=7EciIS7eumFKMjHy96Lu7flwsMubWv5AIIoZFgYskW8=; b=iNHUyS+BwGp0j561Pm74UiTv1J0hGf2O8lykZwY+Z85Ge7DxZu+B7yPyt1MjO+PmOq v+e0K4Ch2pds8B2N9/jZ+n7YI4tvSS4pAvYjyXIjEw3CmO/9XD9z4TDKvZs6Anl1RlZ0 bhMBdwLBXmaeJXERO/hxtyztsY/DBFywPwkGgyGs3YRr3HGIALyQ1ZB3dJMcNWsEx8FW jgiwJQVmtOC7spA2BOpPMzTZG9EAmSwA4R7wzPnT4kak1QcUzZgZy7Fu1MgxqmUkXnpT laT+lx3bflu3uUC+YSU99UbY8yaZCqxiyjnWmfsUOiVRsD73yYkEPUww81x3m/vjIWx6 0fzw== X-Gm-Message-State: AIVw110aqaEsJa9ckxrXNKa+z809FtfZzDJUmkQwpa0xo2vwLG56BICZ xvD2Ta2Wbjxu8p1rv1x4FmQ+Vl3JdQ== X-Received: by 10.37.218.71 with SMTP id n68mr11036282ybf.153.1500989491126; Tue, 25 Jul 2017 06:31:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.13.6 with HTTP; Tue, 25 Jul 2017 06:31:30 -0700 (PDT) In-Reply-To: References: From: Pushpasis Sarkar Date: Tue, 25 Jul 2017 06:31:30 -0700 Message-ID: To: "Les Ginsberg (ginsberg)" Cc: "idr-ads@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-idr-bgp-ls-node-admin-tag-extension.all@ietf.org" , "idr@ietf. org" Content-Type: multipart/alternative; boundary="94eb2c07d10c6e277c0555245917" Archived-At: Subject: Re: [Idr] RtgDir review: draft-ietf-idr-bgp-ls-node-admin-tag-extension-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 13:31:35 -0000 --94eb2c07d10c6e277c0555245917 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Les, Thank you once again for helping me out with all the review comments.. I have addressed all your comments and uploaded version 02. Please let me know if you need any more issues to take care of. Thanks and Regards, -Pushpasis On Thu, Jul 13, 2017 at 5:24 PM, Pushpasis Sarkar wrote: > Hi Les, > > Sorry once again for the late response. Please find comments inline... > > > On Sat, Jul 8, 2017 at 1:42 PM, Les Ginsberg (ginsberg) < > ginsberg@cisco.com> wrote: > >> Pushpassis =E2=80=93 >> >> >> >> Sorry for the delay in responding. >> >> You have not addressed all of the editorial comments I provided =E2=80= =93 please >> do a second pass. >> > [Pushpasis] I did a second pass.. But I could not locate which one(s) I > missed out. It will be great if you list them out for me. The htmlized di= ff > you attached earlier does not exactly highlight the diffs.. :( Request yo= ur > help here... > > >> >> >> Also, there is one substantive issue which you did not address: >> >> >> >> ** >> >> *Section 3.1 Last paragraph* >> >> >> >> *I recognize this statement regarding policy being used to filter what i= s* >> >> *advertised is consistent with RFC 7752. But it would also be good to >> include* >> >> *a statement like:* >> >> >> >> *"Definition of such a policy is outside the scope of this document."* >> >> ** >> >> >> >> If you have a concern with what I proposed please let me know what it is= . >> > [Pushpasis] I will be very happy to add the statement. Thanks a lot for > the suggestion. > > Thanks and Regards, > -Pushpasis > >> >> >> Thanx. >> >> >> >> Les >> >> >> >> >> >> >> >> *From:* Pushpasis Sarkar [mailto:pushpasis.ietf@gmail.com] >> *Sent:* Tuesday, July 04, 2017 8:58 PM >> *To:* Les Ginsberg (ginsberg) >> *Cc:* idr-ads@ietf.org; rtg-dir@ietf.org; draft-ietf-idr-bgp-ls-node-adm >> in-tag-extension.all@ietf.org; idr@ietf. org >> *Subject:* Re: RtgDir review: draft-ietf-idr-bgp-ls-node-adm >> in-tag-extension-01 >> >> >> >> Hi Les, >> >> >> >> Thank you once more for the review comments. And sorry for the late >> reply. I have addressed all your comments in the attached draft. Please >> review the same let me know if you have any more comments. If not I will >> upload the draft soon. >> >> >> >> Thanks and regards, >> >> -Pushpasis >> >> >> >> On Wed, Jun 28, 2017 at 10:26 PM, Pushpasis Sarkar < >> pushpasis.ietf@gmail.com> wrote: >> >> Hi Les, >> >> >> >> Thanks a lot for the review comments. I will reply back addressing your >> comments soon. >> >> >> >> Thanks and regards >> >> -Pushpasis >> >> >> >> On Tue, Jun 27, 2017 at 11:37 PM, Les Ginsberg (ginsberg) < >> ginsberg@cisco.com> wrote: >> >> Hello, >> >> I have been selected as the Routing Directorate reviewer for this draft= . >> The Routing Directorate seeks to review all routing or routing-related >> drafts as they pass through IETF last call and IESG review, and sometime= s >> on special request. The purpose of the review is to provide assistance t= o >> the Routing ADs. For more information about the Routing Directorate, ple= ase >> see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir . >> >> Although these comments are primarily for the use of the Routing ADs, it >> would be helpful if you could consider them along with any other IETF >> comments that you receive, and strive to resolve them through discussion= or >> by updating the draft. >> >> >> Document: draft-ietf-idr-bgp-ls-node-admin-tag-extension-01 >> Reviewer: Les Ginsberg >> Review Date: June 27, 2017 >> Intended Status: Standards >> >> Summary: The document is of modest scope - covering definition of BGP-L= S >> codepoints for a relatively new IGP attribute (Node Admin Tags). >> While I found nothing which I would consider a major issue, there are a >> number >> of places where the text lacks clarity. I think addressing these areas >> would >> greatly improve the quality of the draft. >> >> >> Major Issues: None >> >> Minor Issues: >> >> Section 1 Introduction >> >> The acronym LSDB is not defined. >> >> Figure 1 >> >> I have a personal dislike for duplicating text/pictures from another >> spec when that spec could simply be referenced. There are only two >> possible outcomes: >> >> 1)The duplicated text is redundant (best case) >> 2)The text differs somewhat from the original leading to possible >> unintentional misinterpretations. >> >> Suit yourself on this comment - but I would prefer the duplication be >> omitted. >> >> Section 2 First paragraph >> >> You refer to "sub-TLV" but that reference is unclear and ambiguous. >> IS-IS uses a sub-TLV of Router Capability to advertise tags, but OSPF >> uses a TLV of Router Info LSA. >> What seems most relevant here is that you are defining a new Attribute >> TLV for Node NLRI. >> >> Section 3 Second paragraph >> >> I do not know what the paragraph is trying to say, nor do >> I know what the "TBD" in columns 4 and 5 in the following Table 1 is >> meant to reference. If you are simply trying to describe the source >> of the info advertised by the new BGP-LS Node attribute then you should >> rewrite the above paragraph and in the figure below show: >> >> IS-IS 242/21 >> OSPF RI-LSA/10 >> >> Section 3.1 >> >> A description of where in the Node NLRI the area/level information can b= e >> found >> (from RFC 7752) would be helpful. >> >> >> Section 3.1 Penultimate Paragraph >> >> As TAGs with "global" scope will be advertised by the IGP multiple >> times (once per area/level) I assume you are asking BGP-LS advertisement= s >> to reduce these multiple occurrences to a single occurrence? More >> explicit language on that point would be helpful. >> >> Section 3.1 Last paragraph >> >> I recognize this statement regarding policy being used to filter what is >> advertised is consistent with RFC 7752. But it would also be good to >> include >> a statement like: >> >> "Definition of such a policy is outside the scope of this document." >> >> Nits: Please see attached diff file with some editorial corrections. >> >> >> >> >> > > --94eb2c07d10c6e277c0555245917 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Les,

Thank you once again for helpin= g me out with all the review comments.. I have addressed all your comments = and uploaded version 02. Please let me know if you need any more issues to = take care of.

Thanks and Regards,
-Pushp= asis


On Thu, Jul 13, 2017 at 5:24 PM, Pushpasis Sarkar <= pushpasis.ietf@gmail.com> wrote:
Hi Les,

Sorry once again for the = late response. Please find comments inline...


On Sat, J= ul 8, 2017 at 1:42 PM, Les Ginsberg (ginsberg) <ginsberg@cisco.com>= ; wrote:

Pushpassis =E2=80=93

=C2=A0

Sorry for the delay in re= sponding.

You have not addressed al= l of the editorial comments I provided =E2=80=93 please do a second pass.

[Pushpasis] I did a second pa= ss.. But I could not locate which one(s) I missed out. It will be great if = you list them out for me. The htmlized diff you attached earlier does not e= xactly highlight the diffs.. :( Request your help here...=C2=A0
=C2=A0

=C2=A0

Also, there is one substa= ntive issue which you did not address:

=C2=A0

<snip>

Section 3.1 Last paragraph

=C2=A0

I recognize this statement regarding policy being used to filter what = is

advertised is consistent with RFC 7752. But it would also be good to i= nclude

a statement like:

=C2=A0

"Definition of such a policy is outside the scope of this documen= t."

<end snip>

=C2=A0

If you have a concern wit= h what I proposed please let me know what it is.

[Pushpasis] I will be very happy to add the statement.= =C2=A0 Thanks a lot for the suggestion.

Thanks and= Regards,
-Pushpasis

=C2=A0

Thanx.

=C2=A0

=C2=A0=C2=A0 Les

=C2=A0

=C2=A0

=C2=A0

From: Pushpasi= s Sarkar [mailto:pushpasis.ietf@gmail.com]
Sent: Tuesday, July 04, 2017 8:58 PM
To: Les Ginsberg (ginsberg)
Cc: idr-ads@ie= tf.org; rtg-dir@i= etf.org; draft-ietf-idr-bgp-ls-node-admin-ta= g-extension.all@ietf.org; idr@ietf. org
Subject: Re: RtgDir review: draft-ietf-idr-bgp-ls-node-admin-ta= g-extension-01

=C2=A0

Hi Les,

=C2=A0

Thank you once more for the review comments. And sor= ry for the late reply. I have addressed all your comments in the attached d= raft. Please review the same let me know if you have any more comments. If = not I will upload the draft soon.

=C2=A0

Thanks and regards,

-Pushpasis

=C2=A0

On Wed, Jun 28, 2017 at 10:26 PM, Pushpasis Sarkar &= lt;pushpasis.= ietf@gmail.com> wrote:

Hi Les,

=C2=A0

Thanks a lot for the review comments. I will reply b= ack addressing your comments soon.

=C2=A0

Thanks and regards

-Pushpasis

=C2=A0

On Tue, Jun 27, 2017 at 11:37 PM, Les Ginsberg (gins= berg) <ginsberg@= cisco.com> wrote:

Hello,

=C2=A0I have been selected as the Routing Directorate reviewer for this dra= ft. The Routing Directorate seeks to review all routing or routing-related = drafts as they pass through IETF last call and IESG review, and sometimes o= n special request. The purpose of the review is to provide assistance to the Routing ADs. For more information a= bout the Routing Directorate, please see=C2=A0 http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir .

Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF comment= s that you receive, and strive to resolve them through discussion or by upd= ating the draft.


Document: draft-ietf-idr-bgp-ls-node-admin-tag-extension-01
Reviewer: Les Ginsberg
Review Date: June 27, 2017
Intended Status: Standards

Summary:=C2=A0 The document is of modest scope - covering definition of BGP= -LS
codepoints for a relatively new IGP attribute (Node Admin Tags).
While I found nothing which I would consider a major issue, there are a num= ber
of places where the text lacks clarity. I think addressing these areas woul= d
greatly improve the quality of the draft.


Major Issues: None

Minor Issues:

Section 1 Introduction

The acronym LSDB is not defined.

Figure 1

I have a personal dislike for duplicating text/pictures from another
spec when that spec could simply be referenced. There are only two
possible outcomes:

1)The duplicated text is redundant (best case)
2)The text differs somewhat from the original leading to possible
unintentional misinterpretations.

Suit yourself on this comment - but I would prefer the duplication be omitt= ed.

Section 2 First paragraph

You refer to "sub-TLV" but that reference is unclear and ambiguou= s.
IS-IS uses a sub-TLV of Router Capability to advertise tags, but OSPF
uses a TLV of Router Info LSA.
What seems most relevant here is that you are defining a new Attribute
TLV for Node NLRI.

Section 3 Second paragraph

I do not know what the paragraph is trying to say, nor do
I know what the "TBD" in columns 4 and 5 in the following Table 1= is
meant to reference. If you are simply trying to describe the source
of the info advertised by the new BGP-LS Node attribute then you should
rewrite the above paragraph and in the figure below show:

IS-IS 242/21
OSPF RI-LSA/10

Section 3.1

A description of where in the Node NLRI the area/level information can be f= ound
(from RFC 7752) would be helpful.


Section 3.1 Penultimate Paragraph

As TAGs with "global" scope will be advertised by the IGP multipl= e
times (once per area/level) I assume you are asking BGP-LS advertisements to reduce these multiple occurrences to a single occurrence? More
explicit language on that point would be helpful.

Section 3.1 Last paragraph

I recognize this statement regarding policy being used to filter what is advertised is consistent with RFC 7752. But it would also be good to includ= e
a statement like:

"Definition of such a policy is outside the scope of this document.&qu= ot;

Nits: Please see attached diff file with some editorial corrections.=

=C2=A0

=C2=A0



--94eb2c07d10c6e277c0555245917-- From nobody Tue Jul 25 06:33:52 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65789131C76 for ; Tue, 25 Jul 2017 06:33:51 -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 HsDMcm51qyzQ for ; Tue, 25 Jul 2017 06:33:49 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3598C129A96 for ; Tue, 25 Jul 2017 06:33:49 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id u207so7614379ywc.3 for ; Tue, 25 Jul 2017 06:33:49 -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; bh=RSaUa4gdEY8jJWs0w4m5H9vefYEGfOJaxPpm1UzPbzc=; b=QgWkKqzSk1ZH6rZfd75v0ujSdDNPk1KcNwtWuECnbyuWjAGtd0ulIMbUjwp8q2me+z jufFTZtwT6qAKw++DG+2MIf4kjF3qgm/fpSU42JP4Z/PvHeWK26OQdays9Fkij96ME3N thB24Ix58ZopaJJCM154+8UKDcIvFoIZ5IbhpW6yX1t36wCl8qrUteX6ZRlaQY+QDWfk dLXiKOfpuFdMso55g9PZbqpSriJbNqygGq2icWzXT71yHzP6zp9qKFgr7DUhev5jil5v W98hwJ1y+1N+Fsr8OiJbWv7fHDWRTLIBMzt7FlG/FcY4bwmyW/Q1tIgXV3mPI86Cpe9G sjpg== 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=RSaUa4gdEY8jJWs0w4m5H9vefYEGfOJaxPpm1UzPbzc=; b=bhT/nqubwghJU68DC5SYFWdVqS/HffST5dLEwDn+eiKYj10Bop91oqdHb/52kbBS2i OpdsgMA3IEu9xILJwmpgy4Y+H+TITjsKvwbyViQzPIfrljThM7XF1AVTkfc2Kszl9fw/ UY5GW/tgTjC5m7bAtJfpvIoZ8wmieWMug5Y9TkJOTWia1Rwn1DkyK2Ig4O6Ar/fH87it JeiHi8ChoocWmir1MDs+ZgM//WeYyDOWjBfj+BYE/WDdBnrfjT13vJ+DT3g8rPBoouru z8pd2ESVmh9sVfZE7bps09VzYwKKPCaDwH1CzoLyANH1g+5HRQGl+U/jDaEzrXi4Curc Ubjg== X-Gm-Message-State: AIVw113A7CiuKI+koujeebmJ/94FOHfE9PEL4z9jKrb0tyBmmt2RyeAx qF7OR8DASQMkTwTofjZ2LQH44Aq+sw== X-Received: by 10.37.38.12 with SMTP id m12mr17246162ybm.271.1500989628266; Tue, 25 Jul 2017 06:33:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.13.6 with HTTP; Tue, 25 Jul 2017 06:33:47 -0700 (PDT) In-Reply-To: <150098924562.26151.14759841231875179083.idtracker@ietfa.amsl.com> References: <150098924562.26151.14759841231875179083.idtracker@ietfa.amsl.com> From: Pushpasis Sarkar Date: Tue, 25 Jul 2017 06:33:47 -0700 Message-ID: To: idr wg Content-Type: multipart/alternative; boundary="94eb2c1918609abf4e05552461d6" Archived-At: Subject: [Idr] Fwd: New Version Notification for draft-ietf-idr-bgp-ls-node-admin-tag-extension-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 13:33:51 -0000 --94eb2c1918609abf4e05552461d6 Content-Type: text/plain; charset="UTF-8" Hi All, Uploaded the version below addressing all RtgDir review comments. Request you all to review the document and let us know if there are any concerns or issues. Thanks and regards, -Pushpasis ---------- Forwarded message ---------- From: Date: Tue, Jul 25, 2017 at 6:27 AM Subject: New Version Notification for draft-ietf-idr-bgp-ls-node-admin-tag-extension-02.txt To: Pushpasis Sarkar , Hannes Gredler < hannes@rtbrick.com>, Stephane Litkowski A new version of I-D, draft-ietf-idr-bgp-ls-node-admin-tag-extension-02.txt has been successfully submitted by Pushpasis Sarkar and posted to the IETF repository. Name: draft-ietf-idr-bgp-ls-node-admin-tag-extension Revision: 02 Title: Advertising Node Admin Tags in BGP Link-State Advertisements Document date: 2017-07-25 Group: idr Pages: 11 URL: https://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-ls- node-admin-tag-extension-02.txt Status: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls- node-admin-tag-extension/ Htmlized: https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-node- admin-tag-extension-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp- ls-node-admin-tag-extension-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-ls- node-admin-tag-extension-02 Abstract: This document describes the protocol extensions to collect node administrative tags adevertised in IGP Link State advertisements and disseminate the same in BGP Link-State advertisement protocol, to facilitate inter-AS TE applications that may need the same node administrative tags to associate a subset of network devices spanning across more than one AS with a specific functionality. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --94eb2c1918609abf4e05552461d6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

Uploaded the version below addr= essing all RtgDir review comments. Request you all to review the document a= nd let us know if there are any concerns or issues.

Thanks and regards,
-Pushpasis

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Tue, J= ul 25, 2017 at 6:27 AM
Subject: New Version Notification for draft-ietf-= idr-bgp-ls-node-admin-tag-extension-02.txt
To: Pushpasis Sarkar <pushpasis.ietf@gmail.com>, H= annes Gredler <hannes@rtbrick.com<= /a>>, Stephane Litkowski <stephane.litkowski@orange.com>



A new version of I-D, draft-ietf-idr-bgp-ls-node-admin-tag-extension-0= 2.txt
has been successfully submitted by Pushpasis Sarkar and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-idr-bgp-ls-node-admin-tag-extension
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Advertising Node Admin Tags in BGP= Link-State Advertisements
Document date:=C2=A0 2017-07-25
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 idr
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 11
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-draf= ts/draft-ietf-idr-bgp-ls-node-admin-tag-extension-02.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-idr-b= gp-ls-node-admin-tag-extension/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-node-admin-tag-extension-02
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-iet= f-idr-bgp-ls-node-admin-tag-extension-02
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddra= ft-ietf-idr-bgp-ls-node-admin-tag-extension-02

Abstract:
=C2=A0 =C2=A0This document describes the protocol extensions to collect nod= e
=C2=A0 =C2=A0administrative tags adevertised in IGP Link State advertisemen= ts and
=C2=A0 =C2=A0disseminate the same in BGP Link-State advertisement protocol,= to
=C2=A0 =C2=A0facilitate inter-AS TE applications that may need the same nod= e
=C2=A0 =C2=A0administrative tags to associate a subset of network devices s= panning
=C2=A0 =C2=A0across more than one AS with a specific functionality.





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.

The IETF Secretariat


--94eb2c1918609abf4e05552461d6-- From nobody Tue Jul 25 07:39:31 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5CB131CE3; Tue, 25 Jul 2017 07:39:29 -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 PQ5wcF2GLbQW; Tue, 25 Jul 2017 07:39:26 -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 460CE131CE2; Tue, 25 Jul 2017 07:39:25 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=70.194.2.203; From: "Susan Hares" To: "'Pushpasis Sarkar'" , "'Les Ginsberg \(ginsberg\)'" Cc: , , , "'idr@ietf. org'" References: In-Reply-To: Date: Tue, 25 Jul 2017 10:33:18 -0400 Message-ID: <012601d30552$f5f222a0$e1d667e0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0127_01D30531.6EE27E70" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF678UEYhpB7uWlJ88g2Dd2UcXNegHn6TxCAZXf5vMB6gRaoQFg4qIuAUuJKSmi1CRC8A== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-bgp-ls-node-admin-tag-extension-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 14:39:29 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0127_01D30531.6EE27E70 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable IDR:=20 =20 With the completion of the resolution of the RTG-DIR comments, we will = consider the IDR WG last call complete. This document has passed WG LC. = If anyone has additional comments based on version 2 of the text, = please send them to the IDR chairs.=20 =20 Sue Hares=20 =20 From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Pushpasis = Sarkar Sent: Tuesday, July 25, 2017 9:32 AM To: Les Ginsberg (ginsberg) Cc: rtg-dir@ietf.org; idr-ads@ietf.org; = draft-ietf-idr-bgp-ls-node-admin-tag-extension.all@ietf.org; idr@ietf. = org Subject: Re: [RTG-DIR] RtgDir review: = draft-ietf-idr-bgp-ls-node-admin-tag-extension-01 =20 Hi Les, =20 Thank you once again for helping me out with all the review comments.. I = have addressed all your comments and uploaded version 02. Please let me = know if you need any more issues to take care of. =20 Thanks and Regards, -Pushpasis =20 =20 On Thu, Jul 13, 2017 at 5:24 PM, Pushpasis Sarkar = wrote: Hi Les, =20 Sorry once again for the late response. Please find comments inline... =20 =20 On Sat, Jul 8, 2017 at 1:42 PM, Les Ginsberg (ginsberg) = wrote: Pushpassis =E2=80=93 =20 Sorry for the delay in responding. You have not addressed all of the editorial comments I provided = =E2=80=93 please do a second pass. [Pushpasis] I did a second pass.. But I could not locate which one(s) I = missed out. It will be great if you list them out for me. The htmlized = diff you attached earlier does not exactly highlight the diffs.. :( = Request your help here...=20 =20 =20 Also, there is one substantive issue which you did not address: =20 Section 3.1 Last paragraph =20 I recognize this statement regarding policy being used to filter what is advertised is consistent with RFC 7752. But it would also be good to = include a statement like: =20 "Definition of such a policy is outside the scope of this document." =20 If you have a concern with what I proposed please let me know what it = is. [Pushpasis] I will be very happy to add the statement. Thanks a lot for = the suggestion. =20 Thanks and Regards, -Pushpasis =20 Thanx. =20 Les =20 =20 =20 From: Pushpasis Sarkar [mailto:pushpasis.ietf@gmail.com]=20 Sent: Tuesday, July 04, 2017 8:58 PM To: Les Ginsberg (ginsberg) Cc: idr-ads@ietf.org; rtg-dir@ietf.org; = draft-ietf-idr-bgp-ls-node-admin-tag-extension.all@ietf.org; idr@ietf. = org Subject: Re: RtgDir review: = draft-ietf-idr-bgp-ls-node-admin-tag-extension-01 =20 Hi Les, =20 Thank you once more for the review comments. And sorry for the late = reply. I have addressed all your comments in the attached draft. Please = review the same let me know if you have any more comments. If not I will = upload the draft soon. =20 Thanks and regards, -Pushpasis =20 On Wed, Jun 28, 2017 at 10:26 PM, Pushpasis Sarkar = wrote: Hi Les, =20 Thanks a lot for the review comments. I will reply back addressing your = comments soon. =20 Thanks and regards -Pushpasis =20 On Tue, Jun 27, 2017 at 11:37 PM, Les Ginsberg (ginsberg) = wrote: Hello, I have been selected as the Routing Directorate reviewer for this = draft. The Routing Directorate seeks to review all routing or = routing-related drafts as they pass through IETF last call and IESG = review, and sometimes on special request. The purpose of the review is = to provide assistance to the Routing ADs. For more information about the = Routing Directorate, please see = http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir . Although these comments are primarily for the use of the Routing ADs, it = would be helpful if you could consider them along with any other IETF = comments that you receive, and strive to resolve them through discussion = or by updating the draft. Document: draft-ietf-idr-bgp-ls-node-admin-tag-extension-01 Reviewer: Les Ginsberg Review Date: June 27, 2017 Intended Status: Standards Summary: The document is of modest scope - covering definition of = BGP-LS codepoints for a relatively new IGP attribute (Node Admin Tags). While I found nothing which I would consider a major issue, there are a = number of places where the text lacks clarity. I think addressing these areas = would greatly improve the quality of the draft. Major Issues: None Minor Issues: Section 1 Introduction The acronym LSDB is not defined. Figure 1 I have a personal dislike for duplicating text/pictures from another spec when that spec could simply be referenced. There are only two possible outcomes: 1)The duplicated text is redundant (best case) 2)The text differs somewhat from the original leading to possible unintentional misinterpretations. Suit yourself on this comment - but I would prefer the duplication be = omitted. Section 2 First paragraph You refer to "sub-TLV" but that reference is unclear and ambiguous. IS-IS uses a sub-TLV of Router Capability to advertise tags, but OSPF uses a TLV of Router Info LSA. What seems most relevant here is that you are defining a new Attribute TLV for Node NLRI. Section 3 Second paragraph I do not know what the paragraph is trying to say, nor do I know what the "TBD" in columns 4 and 5 in the following Table 1 is meant to reference. If you are simply trying to describe the source of the info advertised by the new BGP-LS Node attribute then you should rewrite the above paragraph and in the figure below show: IS-IS 242/21 OSPF RI-LSA/10 Section 3.1 A description of where in the Node NLRI the area/level information can = be found (from RFC 7752) would be helpful. Section 3.1 Penultimate Paragraph As TAGs with "global" scope will be advertised by the IGP multiple times (once per area/level) I assume you are asking BGP-LS = advertisements to reduce these multiple occurrences to a single occurrence? More explicit language on that point would be helpful. Section 3.1 Last paragraph I recognize this statement regarding policy being used to filter what is advertised is consistent with RFC 7752. But it would also be good to = include a statement like: "Definition of such a policy is outside the scope of this document." Nits: Please see attached diff file with some editorial corrections. =20 =20 =20 =20 ------=_NextPart_000_0127_01D30531.6EE27E70 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

IDR:

 

With the completion of the resolution of the RTG-DIR comments, we = will consider the IDR WG last call complete.=C2=A0 This document has = passed WG LC.=C2=A0 If anyone has additional comments based on version 2 = of the text, please send them to the IDR chairs. =

 

Sue Hares

 

From:= = rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Pushpasis = Sarkar
Sent: Tuesday, July 25, 2017 9:32 AM
To: Les = Ginsberg (ginsberg)
Cc: rtg-dir@ietf.org; idr-ads@ietf.org; = draft-ietf-idr-bgp-ls-node-admin-tag-extension.all@ietf.org; idr@ietf. = org
Subject: Re: [RTG-DIR] RtgDir review: = draft-ietf-idr-bgp-ls-node-admin-tag-extension-01

 

Hi = Les,

 

Thank you once again for helping me out with all the = review comments.. I have addressed all your comments and uploaded = version 02. Please let me know if you need any more issues to take care = of.

 

Thanks and Regards,

-Pushpasis

 

 

On Thu, = Jul 13, 2017 at 5:24 PM, Pushpasis Sarkar <pushpasis.ietf@gmail.com> = wrote:

Hi = Les,

 

Sorry once again for the late response. Please find = comments inline...

 

 

On Sat, = Jul 8, 2017 at 1:42 PM, Les Ginsberg (ginsberg) <ginsberg@cisco.com> = wrote:

Pushpassis =E2=80=93

 

Sorry for the delay in responding.

You have not addressed all of the editorial comments I provided = =E2=80=93 please do a second = pass.

[Pushpasis] I did a second pass.. But I could not = locate which one(s) I missed out. It will be great if you list them out = for me. The htmlized diff you attached earlier does not exactly = highlight the diffs.. :( Request your help = here... 

 

 

Also, there is one substantive issue which you did not = address:

 

<snip>

Section 3.1 Last paragraph

 

I recognize this statement regarding policy being used to filter what = is

advertised is consistent with RFC 7752. But it would also be good to = include

a statement like:

 

"Definition of such a policy is outside the scope of this = document."

<end snip>

 

If you have a concern with what I proposed please let me know what it = is.

[Pushpasis] I will be very happy to add the = statement.  Thanks a lot for the = suggestion.

 

Thanks and Regards,

-Pushpasis

 

Thanx.

 

   Les

 

 

 

From:= = Pushpasis Sarkar [mailto:pushpasis.ietf@gmail.com]
Sent: = Tuesday, July 04, 2017 8:58 PM
To: Les Ginsberg = (ginsberg)
Cc: idr-ads@ietf.org; rtg-dir@ietf.org; = draft-ietf-idr-bgp-ls-node-admin-tag-extension.all@ietf= .org; idr@ietf. org
Subject: Re: RtgDir review: = draft-ietf-idr-bgp-ls-node-admin-tag-extension-01

 <= /o:p>

Hi = Les,

 <= /o:p>

Thank you = once more for the review comments. And sorry for the late reply. I have = addressed all your comments in the attached draft. Please review the = same let me know if you have any more comments. If not I will upload the = draft soon.

 <= /o:p>

Thanks and = regards,

-Pushpasis

 <= /o:p>

On Wed, Jun = 28, 2017 at 10:26 PM, Pushpasis Sarkar <pushpasis.ietf@gmail.com> = wrote:

Hi = Les,

 <= /o:p>

Thanks a = lot for the review comments. I will reply back addressing your comments = soon.

 <= /o:p>

Thanks and = regards

-Pushpasis

=

 <= /o:p>

On Tue, Jun = 27, 2017 at 11:37 PM, Les Ginsberg (ginsberg) <ginsberg@cisco.com> wrote:

Hello,
 I have been selected as the Routing Directorate reviewer for = this draft. The Routing Directorate seeks to review all routing or = routing-related drafts as they pass through IETF last call and IESG = review, and sometimes on special request. The purpose of the review is = to provide assistance to the Routing ADs. For more information about the = Routing Directorate, please see  http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir .

Although these comments are primarily for the use of the = Routing ADs, it would be helpful if you could consider them along with = any other IETF comments that you receive, and strive to resolve them = through discussion or by updating the draft.


Document: = draft-ietf-idr-bgp-ls-node-admin-tag-extension-01
Reviewer: Les = Ginsberg
Review Date: June 27, 2017
Intended Status: = Standards

Summary:  The document is of modest scope - = covering definition of BGP-LS
codepoints for a relatively new IGP = attribute (Node Admin Tags).
While I found nothing which I would = consider a major issue, there are a number
of places where the text = lacks clarity. I think addressing these areas would
greatly improve = the quality of the draft.


Major Issues: None

Minor = Issues:

Section 1 Introduction

The acronym LSDB is not = defined.

Figure 1

I have a personal dislike for = duplicating text/pictures from another
spec when that spec could = simply be referenced. There are only two
possible = outcomes:

1)The duplicated text is redundant (best case)
2)The = text differs somewhat from the original leading to = possible
unintentional misinterpretations.

Suit yourself on = this comment - but I would prefer the duplication be = omitted.

Section 2 First paragraph

You refer to = "sub-TLV" but that reference is unclear and = ambiguous.
IS-IS uses a sub-TLV of Router Capability to advertise = tags, but OSPF
uses a TLV of Router Info LSA.
What seems most = relevant here is that you are defining a new Attribute
TLV for Node = NLRI.

Section 3 Second paragraph

I do not know what the = paragraph is trying to say, nor do
I know what the "TBD" in = columns 4 and 5 in the following Table 1 is
meant to reference. If = you are simply trying to describe the source
of the info advertised = by the new BGP-LS Node attribute then you should
rewrite the above = paragraph and in the figure below show:

IS-IS 242/21
OSPF = RI-LSA/10

Section 3.1

A description of where in the Node = NLRI the area/level information can be found
(from RFC 7752) would be = helpful.


Section 3.1 Penultimate Paragraph

As TAGs = with "global" scope will be advertised by the IGP = multiple
times (once per area/level) I assume you are asking BGP-LS = advertisements
to reduce these multiple occurrences to a single = occurrence? More
explicit language on that point would be = helpful.

Section 3.1 Last paragraph

I recognize this = statement regarding policy being used to filter what is
advertised is = consistent with RFC 7752. But it would also be good to include
a = statement like:

"Definition of such a policy is outside the = scope of this document."

Nits: Please see attached diff file = with some editorial corrections.

 <= /o:p>

 <= /o:p>

 

 

------=_NextPart_000_0127_01D30531.6EE27E70-- From nobody Tue Jul 25 19:20:51 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 903D21321B6; Tue, 25 Jul 2017 19:20:43 -0700 (PDT) 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 NPR2vHSIiE6P; Tue, 25 Jul 2017 19:20:42 -0700 (PDT) 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 AD841124BE8; Tue, 25 Jul 2017 19:20:24 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id CC357B81AC3; Tue, 25 Jul 2017 19:20:14 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, idr@ietf.org Message-Id: <20170726022014.CC357B81AC3@rfc-editor.org> Date: Tue, 25 Jul 2017 19:20:14 -0700 (PDT) Archived-At: Subject: [Idr] RFC 8203 on BGP Administrative Shutdown Communication X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 02:20:44 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8203 Title: BGP Administrative Shutdown Communication Author: J. Snijders, J. Heitz, J. Scudder Status: Standards Track Stream: IETF Date: July 2017 Mailbox: job@ntt.net, jheitz@cisco.com, jgs@juniper.net Pages: 6 Characters: 12532 Updates: RFC 4486 I-D Tag: draft-ietf-idr-shutdown-10.txt URL: https://www.rfc-editor.org/info/rfc8203 DOI: 10.17487/RFC8203 This document enhances the BGP Cease NOTIFICATION message "Administrative Shutdown" and "Administrative Reset" subcodes for operators to transmit a short freeform message to describe why a BGP session was shutdown or reset. This document updates RFC 4486. This document is a product of the Inter-Domain Routing 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 Wed Jul 26 06:00:53 2017 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 54969126C22; Wed, 26 Jul 2017 06:00:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150107405030.26401.10059488186589583905@ietfa.amsl.com> Date: Wed, 26 Jul 2017 06:00:50 -0700 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-bgp-ls-segment-routing-ext-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 13:00:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing WG of the IETF. Title : BGP Link-State extensions for Segment Routing Authors : Stefano Previdi Peter Psenak Clarence Filsfils Hannes Gredler Mach(Guoyi) Chen Filename : draft-ietf-idr-bgp-ls-segment-routing-ext-03.txt Pages : 27 Date : 2017-07-26 Abstract: Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS, OSPF and OSPFv3). This draft defines extensions to the BGP Link-state address-family in order to carry segment information via BGP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-ext/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-ext-03 https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-segment-routing-ext-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-ls-segment-routing-ext-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 Wed Jul 26 16:01:43 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00EE1131EA7 for ; Wed, 26 Jul 2017 16:01:41 -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 mVoH3wig2c4S for ; Wed, 26 Jul 2017 16:01:40 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C94C131EAA for ; Wed, 26 Jul 2017 16:01:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4763; q=dns/txt; s=iport; t=1501110100; x=1502319700; h=from:subject:to:message-id:date:mime-version; bh=YXGl7/r7YlNLjPTXyAKu3GBfJR6SrKyfXAXxXmjKVi8=; b=P+h8XkggQmkzqGacOASZMSInER82u8lGOpgUKSc3oqj7Yvk0TUKknyCh CLbw8LbYchSs2sXZgUnH5Cey57a7OqeEU/vfQZ++7DAnjr3hbXz+iKRaQ oKhnwTbd4Ld/f0G8EKjhLrSfBqrkOD+ouMzoZ4zhao2yvu5Z3AW9jVui7 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CVAgAmHnlZ/4UNJK1dHRgHg06yQoQtg?= =?us-ascii?q?QGCEokYPxgBAgEBAQEBAQFrKIVCdT4CbAgBAReKFKEIkA6CJieLUYMog02BYSu?= =?us-ascii?q?Kf4JhBZ9bAosYiQiLMYcJjQuIZR84P0t3FUmHGz6HKweCOQEBAQ?= X-IronPort-AV: E=Sophos;i="5.40,417,1496102400"; d="scan'208,217";a="460113573" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Jul 2017 23:01:39 +0000 Received: from [10.82.221.134] (rtp-vpn3-1408.cisco.com [10.82.221.134]) (authenticated bits=0) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v6QN1bSt003522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 26 Jul 2017 23:01:39 GMT From: "Juan Alcaide (jalcaide)" To: idr@ietf.org Message-ID: <9fa67eb0-8f99-a46f-aff1-d42a279ab833@cisco.com> Date: Thu, 27 Jul 2017 01:01:37 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------6538608D30E3FAA6789C2BFB" Content-Language: en-US X-Authenticated-User: jalcaide Archived-At: Subject: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT (part 2) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 23:01:42 -0000 This is a multi-part message in MIME format. --------------6538608D30E3FAA6789C2BFB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, From a previous thread, I see from the that using EXTCOMM to carry group-id information the choice. Reason was that every AS could use their own the group-id (perhaps different than another AS). With this choice, ADD-PATHS must be mandatory in order to support multiple group-ids for the same flowspec rule (we assume controller(s) may not want to send multiple ext-communities with same NLRI). But the draft really does not describe how to use ADD-PATHS, and it does not discuss its problems: - Usually, ADD-PATHS is used for path diversity, and implementations typically don't advertise 2 paths with the same next-hop (otherwise, we could have path explosion across multiple levels of RRs) - If ADD-PATHS has to advertise the same NLRI with different ext-communities, one solution would be for ADD-PAHTS not advertise the same set of ext-communities. Unless, I guess, next-hops are different. Otherwise, we would have path explosion. - Assuming the above, we should define a particular set of ADD-PATHS rules for flowspec AF. And, of course, leave the door open for future specific ADD-PATHs rules for other AFs (it would not be about path diversity anymore, but about propagating different information for forwarding purposes -imagine what we could have done with an IPv4 prefix: send the same net part as a NLRI and multiple ext-communities representing different prefix-lengths -). - Since paths in a net are typically implemented as a list, there could be scalability problems if we ever want to support many group-ids. My solution to simplify all these problems would be to add a discriminator on the NLRI (by defining a new dummy type for flowspec). We could still use ext-communities to actually match the NLRIs to interfaces. Similar to RD and RT usage. Thoughts? -J --------------6538608D30E3FAA6789C2BFB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi,

From a previous thread, I see from the that using EXTCOMM to carry group-id information the choice. Reason was that every AS could use their own the group-id (perhaps different than another AS). With this choice, ADD-PATHS must be mandatory in order to support multiple group-ids for the same flowspec rule  (we assume controller(s) may not want to send multiple ext-communities with same NLRI).

But the draft really does not describe how to use ADD-PATHS, and it does not discuss its problems:

- Usually, ADD-PATHS is used for path diversity, and implementations typically don't advertise 2 paths with the same next-hop (otherwise, we could have path explosion across multiple levels of RRs)

- If ADD-PATHS has to advertise the same NLRI with different ext-communities, one solution would be for ADD-PAHTS not advertise the same set of ext-communities. Unless, I guess, next-hops are different. Otherwise, we would have path explosion.

- Assuming the above, we should define a particular set of ADD-PATHS rules for flowspec AF. And, of course, leave the door open for future specific ADD-PATHs rules for other AFs (it would not be about path diversity anymore, but about propagating different information for forwarding purposes -imagine what we could have done with an IPv4 prefix: send the same net part as a NLRI and multiple ext-communities representing different prefix-lengths -).

- Since paths in a net are typically implemented as a list, there could be scalability problems if we ever want to support many group-ids.

My solution to simplify all these problems would be to add a discriminator on the NLRI (by defining a new dummy type for flowspec). We could still use ext-communities to actually match the NLRIs to interfaces. Similar to RD and RT usage.

Thoughts?

-J

--------------6538608D30E3FAA6789C2BFB-- From nobody Wed Jul 26 16:37:55 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 047D1131EE6 for ; Wed, 26 Jul 2017 16:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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 kKGYfohBUnKd for ; Wed, 26 Jul 2017 16:37:50 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C4CA131EDC for ; Wed, 26 Jul 2017 16:37:50 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id c74so73491533iod.4 for ; Wed, 26 Jul 2017 16:37:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Oqdl2yzp8nwy1aTt1k8xMF4vqFWZMyrOh+N2wUQDcNc=; b=bIQWhNeGgcOVvzv2zbg0xWqbuZfQVY9lprhAQc1ON/OiHfLr7J45vj7J0RcgH5YpG/ Dq1JQqvbZXo4tE4d/evKoBgzZJ0ULercNgmgN4ljOQClHla2BWjCm6cOys3yuSDxqtfv 2ktceoyifl+z5TaeFALOyVshS86IuCdqpDE8H2RHnjgrwV7lJn+D/gdZizsX0G4QuKk5 mNFCUN4YV/W3Z4LfPEmqcohTla/ee/LdrK25tqR4kUBmaWe3aoHLxMaIRzdNlxeKt8a3 ZF92PDttECfKTAIVV6LuuuWpMDo+hXAMkMrt6TcKnP9PCoU0175DQLPtb9DVTEPJSg/l TKUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Oqdl2yzp8nwy1aTt1k8xMF4vqFWZMyrOh+N2wUQDcNc=; b=T8tbgUlbfQtlFD6LykcFzMJjm22Hm5a967Tk8jODQeQTbePK5dUWxoPNB7UuLPgvnx 5GtrTKIb1/FB7LwZVbFU2/IFSOfqqmni+VJlMOIb0sZNYx8sjLoClYm7WDpEodQqQkWK UqM1sUOXHumaTeUIPGMx22MWAF3PDjYtZkUEWrbeEsbH+GiexM9Mc2HojyhgAE+y4rfS APJrINvmHpYV2zwX5TftZoymq69EbykeNU1svT3kYnWaefY+knMn9SpPHjJjdJngiNpJ m9nlqTiug2mK7wEfeHwWjKaSpLWPT+R+Fl6azDIUd20H2wvG2gtRRZgNx9gaSeVYmfis qyeA== X-Gm-Message-State: AIVw113kFxE2ah5kdQ7Ykw4Ct52DNYIOMHSMRS1a0uVW1T1QaaYJhlJ+ 8SXjo2KHBhutPsKEFavEanmIMClrog== X-Received: by 10.107.175.136 with SMTP id p8mr3113104ioo.219.1501112269746; Wed, 26 Jul 2017 16:37:49 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.153.21 with HTTP; Wed, 26 Jul 2017 16:37:48 -0700 (PDT) In-Reply-To: <9fa67eb0-8f99-a46f-aff1-d42a279ab833@cisco.com> References: <9fa67eb0-8f99-a46f-aff1-d42a279ab833@cisco.com> From: Robert Raszuk Date: Thu, 27 Jul 2017 01:37:48 +0200 X-Google-Sender-Auth: 9h_AZXpqTBktid38LG7QJDXb-fA Message-ID: To: "Juan Alcaide (jalcaide)" Cc: idr wg Content-Type: multipart/alternative; boundary="001a11447f729b3744055540ef9c" Archived-At: Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT (part 2) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 23:37:53 -0000 --001a11447f729b3744055540ef9c Content-Type: text/plain; charset="UTF-8" Hi Juan, > (we assume controller(s) may not want to send multiple ext-communities with same NLRI). If I recall group-ids are carried in new RT format: "This new BGP Route Target extended community is encoded as follows : 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (TBD) | 0x02 | Autonomous System Number : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : AS Number (cont.) |O|I| Group Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ " So just like an UPDATE message of SAFI 128 may contain many RTs why would you see any issue to carry multiple ext communities of the above format here ? Best, R. On Thu, Jul 27, 2017 at 1:01 AM, Juan Alcaide (jalcaide) wrote: > Hi, > > From a previous thread, I see from the that using EXTCOMM to carry > group-id information the choice. Reason was that every AS could use their > own the group-id (perhaps different than another AS). With this choice, > ADD-PATHS must be mandatory in order to support multiple group-ids for the > same flowspec rule (we assume controller(s) may not want to send multiple > ext-communities with same NLRI). > > But the draft really does not describe how to use ADD-PATHS, and it does > not discuss its problems: > > - Usually, ADD-PATHS is used for path diversity, and implementations > typically don't advertise 2 paths with the same next-hop (otherwise, we > could have path explosion across multiple levels of RRs) > > - If ADD-PATHS has to advertise the same NLRI with different > ext-communities, one solution would be for ADD-PAHTS not advertise the same > set of ext-communities. Unless, I guess, next-hops are different. > Otherwise, we would have path explosion. > > - Assuming the above, we should define a particular set of ADD-PATHS rules > for flowspec AF. And, of course, leave the door open for future specific > ADD-PATHs rules for other AFs (it would not be about path diversity > anymore, but about propagating different information for forwarding > purposes -imagine what we could have done with an IPv4 prefix: send the > same net part as a NLRI and multiple ext-communities representing different > prefix-lengths -). > > - Since paths in a net are typically implemented as a list, there could be > scalability problems if we ever want to support many group-ids. > > My solution to simplify all these problems would be to add a discriminator > on the NLRI (by defining a new dummy type for flowspec). We could still use > ext-communities to actually match the NLRIs to interfaces. Similar to RD > and RT usage. > > Thoughts? > > -J > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > --001a11447f729b3744055540ef9c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Juan,

>=C2=A0=C2=A0(we assume controller(s) may not wan= t to send multiple ext-communities with same NLRI).

If I recall group-ids are carried in new RT f= ormat:=C2=A0

"Thi= s new BGP Route Target extended community is encoded as follows :
=
=C2=A0 =C2=A0 =C2=A0 =C2=A00 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 =C2=A0 =C2=A0 =C2=A00 1 2 3 4 5 6 7 8 9= 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
=C2=A0 =C2=A0 =C2=A0 +-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0 = =C2=A0 | =C2=A0Type (TBD) =C2=A0 | =C2=A0 =C2=A0 =C2=A00x02 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0Autonomous System Number =C2=A0 :
=C2=A0 =C2=A0 =C2=A0 +-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<= div class=3D"gmail_default">=C2=A0 =C2= =A0 =C2=A0 : =C2=A0 =C2=A0 AS Number (cont.) =C2=A0 =C2=A0 =C2=A0 =C2=A0 |O= |I| =C2=A0 =C2=A0 =C2=A0Group Identifier =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 = =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= "

So= just like an UPDATE message of SAFI 128 may contain many RTs why would you= see any=C2=A0
issue to carry multiple ext communit= ies of the above format here ?=C2=A0

=
Best,
R.

On Thu, Jul 27, 2017 at 1:0= 1 AM, Juan Alcaide (jalcaide) <jalcaide@cisco.com> wrote:
=20 =20 =20

Hi,

From a previous thread, I see from the that using EXTCOMM to carry group-id information the choice. Reason was that every AS could use their own the group-id (perhaps different than another AS). With this choice, ADD-PATHS must be mandatory in order to support multiple group-ids for the same flowspec rule=C2=A0 (we assume controller(s) may not want to send multiple ext-communities with same NLRI).

But the draft really does not describe how to use ADD-PATHS, and it does not discuss its problems:

- Usually, ADD-PATHS is used for path diversity, and implementations typically don't advertise 2 paths with the same next-hop (otherwise, we could have path explosion across multiple levels of RRs)

- If ADD-PATHS has to advertise the same NLRI with different ext-communities, one solution would be for ADD-PAHTS not advertise the same set of ext-communities. Unless, I guess, next-hops are different. Otherwise, we would have path explosion.

- Assuming the above, we should define a particular set of ADD-PATHS rules for flowspec AF. And, of course, leave the door open for future specific ADD-PATHs rules for other AFs (it would not be about path diversity anymore, but about propagating different information for forwarding purposes -imagine what we could have done with an IPv4 prefix: send the same net part as a NLRI and multiple ext-communities representing different prefix-lengths -).

- Since paths in a net are typically implemented as a list, there could be scalability problems if we ever want to support many group-ids.

My solution to simplify all these problems would be to add a discriminator on the NLRI (by defining a new dummy type for flowspec). We could still use ext-communities to actually match the NLRIs to interfaces. Similar to RD and RT usage.=

Thoughts?

-J


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


--001a11447f729b3744055540ef9c-- From nobody Wed Jul 26 17:19:39 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6934131F06 for ; Wed, 26 Jul 2017 17:19:37 -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 jDPhhlCnvwKt for ; Wed, 26 Jul 2017 17:19:36 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5B96131EFC for ; Wed, 26 Jul 2017 17:19:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20776; q=dns/txt; s=iport; t=1501114775; x=1502324375; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=eNmJc96QJ2pboH7oPZ8Lz2DA1Dnodukpy4isT7kHHMI=; b=aNVTrJi7aCT1EJ7svdFfNzLpScZLHPBC8faZvKnfTebpnQ+4TICMC5Q7 S3mVshuZXDR+3tDUzA4YofxLE17UGlRDNIzfMJ5EhBe/yEnSszgjf4Ypt xiy/36+Eo4ewaXMQlyazOj59ZvC3nMGruA3PfyAOIm60yMZiM3Kb9RtLP A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CfAAAuMXlZ/5NdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm8+LWSBFAeOBpFjdI9nhS6CEiEBCoUbAhqDNT8YAQIBAQEBAQE?= =?us-ascii?q?BayiFGAEBAQEDAQEhCjoHCxACAQgRBAEBKAMCAgIlCxQJCAIEAQ0FCAwHiTBkE?= =?us-ascii?q?LBygiaLQwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgyiDTYFhgnA0hQofgl2CYQW?= =?us-ascii?q?XWIgDAosYiH+CFZAuiVOMHAEfOD9LdxVJhxl2hnUHgSuBDgEBAQ?= X-IronPort-AV: E=Sophos;i="5.40,417,1496102400"; d="scan'208,217";a="459808117" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jul 2017 00:19:34 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v6R0JYQT007910 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Jul 2017 00:19:34 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 26 Jul 2017 19:19:34 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Wed, 26 Jul 2017 19:19:34 -0500 From: "Jakob Heitz (jheitz)" To: Robert Raszuk , "Juan Alcaide (jalcaide)" CC: idr wg Thread-Topic: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT (part 2) Thread-Index: AQHTBmMsA+kuai771EGHOw9ST46Op6JnF2sA//+2lRA= Date: Thu, 27 Jul 2017 00:19:33 +0000 Message-ID: <8dd3e766b58944a3b176fc743e478137@XCH-ALN-014.cisco.com> References: <9fa67eb0-8f99-a46f-aff1-d42a279ab833@cisco.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.154.161.244] Content-Type: multipart/alternative; boundary="_000_8dd3e766b58944a3b176fc743e478137XCHALN014ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT (part 2) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 00:19:38 -0000 --_000_8dd3e766b58944a3b176fc743e478137XCHALN014ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VHdvIGZsb3dzcGVjIHJvdXRlcyB3aXRoIHRoZSBzYW1lIE5MUkkgbWF5IGJlIG9yaWdpbmF0ZWQg YnkgZGlmZmVyZW50IHNwZWFrZXJzLg0KVGhlIGZpcnN0IHJvdXRlIHdpbGwgaGF2ZSBvbmUgZ3Jv dXAtaWQuIFRoZSBzZWNvbmQgcm91dGUgd2lsbCBoYXZlIGFub3RoZXIgZ3JvdXAtaWQuDQoNClRo YW5rcywNCkpha29iLg0KDQpGcm9tOiBJZHIgW21haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIFJvYmVydCBSYXN6dWsNClNlbnQ6IFdlZG5lc2RheSwgSnVseSAyNiwgMjAx NyA0OjM4IFBNDQpUbzogSnVhbiBBbGNhaWRlIChqYWxjYWlkZSkgPGphbGNhaWRlQGNpc2NvLmNv bT4NCkNjOiBpZHIgd2cgPGlkckBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbSWRyXSBkcmFmdC1s aXRrb3dza2ktaWRyLWZsb3dzcGVjLWludGVyZmFjZXNldCA9PiBOTFJJIHZzIEVYVENUIChwYXJ0 IDIpDQoNCkhpIEp1YW4sDQoNCj4gICh3ZSBhc3N1bWUgY29udHJvbGxlcihzKSBtYXkgbm90IHdh bnQgdG8gc2VuZCBtdWx0aXBsZSBleHQtY29tbXVuaXRpZXMgd2l0aCBzYW1lIE5MUkkpLg0KDQpJ ZiBJIHJlY2FsbCBncm91cC1pZHMgYXJlIGNhcnJpZWQgaW4gbmV3IFJUIGZvcm1hdDoNCg0KIlRo aXMgbmV3IEJHUCBSb3V0ZSBUYXJnZXQgZXh0ZW5kZWQgY29tbXVuaXR5IGlzIGVuY29kZWQgYXMg Zm9sbG93cyA6DQoNCiAgICAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAg ICAgMiAgICAgICAgICAgICAgICAgICAzDQogICAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEg MiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQogICAgICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0K ICAgICAgfCAgVHlwZSAoVEJEKSAgIHwgICAgICAweDAyICAgICB8ICAgIEF1dG9ub21vdXMgU3lz dGVtIE51bWJlciAgIDoNCiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgICA6ICAgICBBUyBOdW1iZXIgKGNv bnQuKSAgICAgICAgIHxPfEl8ICAgICAgR3JvdXAgSWRlbnRpZmllciAgICAgfA0KICAgICAgKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSsNCiINCg0KU28ganVzdCBsaWtlIGFuIFVQREFURSBtZXNzYWdlIG9mIFNBRkkgMTI4IG1h eSBjb250YWluIG1hbnkgUlRzIHdoeSB3b3VsZCB5b3Ugc2VlIGFueQ0KaXNzdWUgdG8gY2Fycnkg bXVsdGlwbGUgZXh0IGNvbW11bml0aWVzIG9mIHRoZSBhYm92ZSBmb3JtYXQgaGVyZSA/DQoNCkJl c3QsDQpSLg0KDQpPbiBUaHUsIEp1bCAyNywgMjAxNyBhdCAxOjAxIEFNLCBKdWFuIEFsY2FpZGUg KGphbGNhaWRlKSA8amFsY2FpZGVAY2lzY28uY29tPG1haWx0bzpqYWxjYWlkZUBjaXNjby5jb20+ PiB3cm90ZToNCg0KSGksDQoNCkZyb20gYSBwcmV2aW91cyB0aHJlYWQsIEkgc2VlIGZyb20gdGhl IHRoYXQgdXNpbmcgRVhUQ09NTSB0byBjYXJyeSBncm91cC1pZCBpbmZvcm1hdGlvbiB0aGUgY2hv aWNlLiBSZWFzb24gd2FzIHRoYXQgZXZlcnkgQVMgY291bGQgdXNlIHRoZWlyIG93biB0aGUgZ3Jv dXAtaWQgKHBlcmhhcHMgZGlmZmVyZW50IHRoYW4gYW5vdGhlciBBUykuIFdpdGggdGhpcyBjaG9p Y2UsIEFERC1QQVRIUyBtdXN0IGJlIG1hbmRhdG9yeSBpbiBvcmRlciB0byBzdXBwb3J0IG11bHRp cGxlIGdyb3VwLWlkcyBmb3IgdGhlIHNhbWUgZmxvd3NwZWMgcnVsZSAgKHdlIGFzc3VtZSBjb250 cm9sbGVyKHMpIG1heSBub3Qgd2FudCB0byBzZW5kIG11bHRpcGxlIGV4dC1jb21tdW5pdGllcyB3 aXRoIHNhbWUgTkxSSSkuDQoNCkJ1dCB0aGUgZHJhZnQgcmVhbGx5IGRvZXMgbm90IGRlc2NyaWJl IGhvdyB0byB1c2UgQURELVBBVEhTLCBhbmQgaXQgZG9lcyBub3QgZGlzY3VzcyBpdHMgcHJvYmxl bXM6DQoNCi0gVXN1YWxseSwgQURELVBBVEhTIGlzIHVzZWQgZm9yIHBhdGggZGl2ZXJzaXR5LCBh bmQgaW1wbGVtZW50YXRpb25zIHR5cGljYWxseSBkb24ndCBhZHZlcnRpc2UgMiBwYXRocyB3aXRo IHRoZSBzYW1lIG5leHQtaG9wIChvdGhlcndpc2UsIHdlIGNvdWxkIGhhdmUgcGF0aCBleHBsb3Np b24gYWNyb3NzIG11bHRpcGxlIGxldmVscyBvZiBSUnMpDQoNCi0gSWYgQURELVBBVEhTIGhhcyB0 byBhZHZlcnRpc2UgdGhlIHNhbWUgTkxSSSB3aXRoIGRpZmZlcmVudCBleHQtY29tbXVuaXRpZXMs IG9uZSBzb2x1dGlvbiB3b3VsZCBiZSBmb3IgQURELVBBSFRTIG5vdCBhZHZlcnRpc2UgdGhlIHNh bWUgc2V0IG9mIGV4dC1jb21tdW5pdGllcy4gVW5sZXNzLCBJIGd1ZXNzLCBuZXh0LWhvcHMgYXJl IGRpZmZlcmVudC4gT3RoZXJ3aXNlLCB3ZSB3b3VsZCBoYXZlIHBhdGggZXhwbG9zaW9uLg0KDQot IEFzc3VtaW5nIHRoZSBhYm92ZSwgd2Ugc2hvdWxkIGRlZmluZSBhIHBhcnRpY3VsYXIgc2V0IG9m IEFERC1QQVRIUyBydWxlcyBmb3IgZmxvd3NwZWMgQUYuIEFuZCwgb2YgY291cnNlLCBsZWF2ZSB0 aGUgZG9vciBvcGVuIGZvciBmdXR1cmUgc3BlY2lmaWMgQURELVBBVEhzIHJ1bGVzIGZvciBvdGhl ciBBRnMgKGl0IHdvdWxkIG5vdCBiZSBhYm91dCBwYXRoIGRpdmVyc2l0eSBhbnltb3JlLCBidXQg YWJvdXQgcHJvcGFnYXRpbmcgZGlmZmVyZW50IGluZm9ybWF0aW9uIGZvciBmb3J3YXJkaW5nIHB1 cnBvc2VzIC1pbWFnaW5lIHdoYXQgd2UgY291bGQgaGF2ZSBkb25lIHdpdGggYW4gSVB2NCBwcmVm aXg6IHNlbmQgdGhlIHNhbWUgbmV0IHBhcnQgYXMgYSBOTFJJIGFuZCBtdWx0aXBsZSBleHQtY29t bXVuaXRpZXMgcmVwcmVzZW50aW5nIGRpZmZlcmVudCBwcmVmaXgtbGVuZ3RocyAtKS4NCg0KLSBT aW5jZSBwYXRocyBpbiBhIG5ldCBhcmUgdHlwaWNhbGx5IGltcGxlbWVudGVkIGFzIGEgbGlzdCwg dGhlcmUgY291bGQgYmUgc2NhbGFiaWxpdHkgcHJvYmxlbXMgaWYgd2UgZXZlciB3YW50IHRvIHN1 cHBvcnQgbWFueSBncm91cC1pZHMuDQoNCk15IHNvbHV0aW9uIHRvIHNpbXBsaWZ5IGFsbCB0aGVz ZSBwcm9ibGVtcyB3b3VsZCBiZSB0byBhZGQgYSBkaXNjcmltaW5hdG9yIG9uIHRoZSBOTFJJIChi eSBkZWZpbmluZyBhIG5ldyBkdW1teSB0eXBlIGZvciBmbG93c3BlYykuIFdlIGNvdWxkIHN0aWxs IHVzZSBleHQtY29tbXVuaXRpZXMgdG8gYWN0dWFsbHkgbWF0Y2ggdGhlIE5MUklzIHRvIGludGVy ZmFjZXMuIFNpbWlsYXIgdG8gUkQgYW5kIFJUIHVzYWdlLg0KDQpUaG91Z2h0cz8NCg0KLUoNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklkciBtYWls aW5nIGxpc3QNCklkckBpZXRmLm9yZzxtYWlsdG86SWRyQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHINCg0K --_000_8dd3e766b58944a3b176fc743e478137XCHALN014ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJMdWNpZGEgQ29uc29s ZSI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNCA1IDQgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseToiXEBTaW1TdW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyog U3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29O b3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmss IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVy bGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnAubXNvbm9ybWFsMCwg bGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFs Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5ob2VuemIN Cgl7bXNvLXN0eWxlLW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29s b3I6IzcwMzBBMDsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7DQoJ dGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOiM3MDMwQTAiPlR3byBmbG93c3BlYyByb3V0ZXMgd2l0aCB0aGUgc2FtZSBO TFJJIG1heSBiZSBvcmlnaW5hdGVkIGJ5IGRpZmZlcmVudCBzcGVha2Vycy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNzAzMEEwIj5U aGUgZmlyc3Qgcm91dGUgd2lsbCBoYXZlIG9uZSBncm91cC1pZC4gVGhlIHNlY29uZCByb3V0ZSB3 aWxsIGhhdmUgYW5vdGhlciBncm91cC1pZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNzAzMEEwIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjgu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0x1Y2lkYSBDb25zb2xlJnF1b3Q7O2NvbG9yOiM3MDMwQTAi PlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0x1Y2lkYSBDb25zb2xl JnF1b3Q7O2NvbG9yOiM3MDMwQTAiPkpha29iLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM3MDMwQTAiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs dWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gSWRyIFttYWlsdG86aWRyLWJvdW5jZXNA aWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJvYmVydCBSYXN6dWs8YnI+DQo8Yj5TZW50 OjwvYj4gV2VkbmVzZGF5LCBKdWx5IDI2LCAyMDE3IDQ6MzggUE08YnI+DQo8Yj5Ubzo8L2I+IEp1 YW4gQWxjYWlkZSAoamFsY2FpZGUpICZsdDtqYWxjYWlkZUBjaXNjby5jb20mZ3Q7PGJyPg0KPGI+ Q2M6PC9iPiBpZHIgd2cgJmx0O2lkckBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFtJZHJdIGRyYWZ0LWxpdGtvd3NraS1pZHItZmxvd3NwZWMtaW50ZXJmYWNlc2V0ID0mZ3Q7 IE5MUkkgdnMgRVhUQ1QgKHBhcnQgMik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5IaSBKdWFuLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZuYnNwOyZuYnNw Oyh3ZSBhc3N1bWUgY29udHJvbGxlcihzKSBtYXkgbm90IHdhbnQgdG8gc2VuZCBtdWx0aXBsZSBl eHQtY29tbXVuaXRpZXMgd2l0aCBzYW1lIE5MUkkpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+SWYgSSByZWNhbGwgZ3JvdXAt aWRzIGFyZSBjYXJyaWVkIGluIG5ldyBSVCBmb3JtYXQ6Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mcXVvdDtUaGlz IG5ldyBCR1AgUm91dGUgVGFyZ2V0IGV4dGVuZGVkIGNvbW11bml0eSBpcyBlbmNvZGVkIGFzIGZv bGxvd3MgOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7MCAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAxICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDIg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgMzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDswIDEgMiAzIDQgNSA2IDcgOCA5IDAg MSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDE8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO1R5cGUg KFRCRCkgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsweDAyICZuYnNwOyAmbmJzcDsgfCAm bmJzcDsgJm5ic3A7QXV0b25vbW91cyBTeXN0ZW0gTnVtYmVyICZuYnNwOyA6PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJm5ic3A7ICZu YnNwOyAmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgOiAmbmJzcDsg Jm5ic3A7IEFTIE51bWJlciAoY29udC4pICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8T3xJ fCAmbmJzcDsgJm5ic3A7ICZuYnNwO0dyb3VwIElkZW50aWZpZXIgJm5ic3A7ICZuYnNwOyB8PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsg Jm5ic3A7ICZuYnNwOyAmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+JnF1b3Q7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYi PlNvIGp1c3QgbGlrZSBhbiBVUERBVEUgbWVzc2FnZSBvZiBTQUZJIDEyOCBtYXkgY29udGFpbiBt YW55IFJUcyB3aHkgd291bGQgeW91IHNlZSBhbnkmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+aXNzdWUgdG8gY2FycnkgbXVsdGlw bGUgZXh0IGNvbW11bml0aWVzIG9mIHRoZSBhYm92ZSBmb3JtYXQgaGVyZSA/Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm Ij5CZXN0LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmIj5SLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gVGh1LCBKdWwgMjcsIDIwMTcgYXQgMTowMSBBTSwgSnVhbiBBbGNh aWRlIChqYWxjYWlkZSkgJmx0OzxhIGhyZWY9Im1haWx0bzpqYWxjYWlkZUBjaXNjby5jb20iIHRh cmdldD0iX2JsYW5rIj5qYWxjYWlkZUBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPkhpLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij5Gcm9tIGEgcHJldmlvdXMgdGhyZWFkLCBJIHNlZSBmcm9tIHRoZSB0aGF0IHVzaW5n IEVYVENPTU0gdG8gY2FycnkgZ3JvdXAtaWQgaW5mb3JtYXRpb24gdGhlIGNob2ljZS4gUmVhc29u IHdhcyB0aGF0IGV2ZXJ5IEFTIGNvdWxkIHVzZSB0aGVpciBvd24gdGhlIGdyb3VwLWlkIChwZXJo YXBzIGRpZmZlcmVudCB0aGFuIGFub3RoZXIgQVMpLiBXaXRoIHRoaXMgY2hvaWNlLCBBREQtUEFU SFMNCiBtdXN0IGJlIG1hbmRhdG9yeSBpbiBvcmRlciB0byBzdXBwb3J0IG11bHRpcGxlIGdyb3Vw LWlkcyBmb3IgdGhlIHNhbWUgZmxvd3NwZWMgcnVsZSZuYnNwOyAod2UgYXNzdW1lIGNvbnRyb2xs ZXIocykgbWF5IG5vdCB3YW50IHRvIHNlbmQgbXVsdGlwbGUgZXh0LWNvbW11bml0aWVzIHdpdGgg c2FtZSBOTFJJKS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdCI+QnV0IHRoZSBkcmFmdCByZWFsbHkgZG9lcyBub3QgZGVzY3JpYmUgaG93IHRv IHVzZSBBREQtUEFUSFMsIGFuZCBpdCBkb2VzIG5vdCBkaXNjdXNzIGl0cyBwcm9ibGVtczo8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+LSBV c3VhbGx5LCBBREQtUEFUSFMgaXMgdXNlZCBmb3IgcGF0aCBkaXZlcnNpdHksIGFuZCBpbXBsZW1l bnRhdGlvbnMgdHlwaWNhbGx5IGRvbid0IGFkdmVydGlzZSAyIHBhdGhzIHdpdGggdGhlIHNhbWUg bmV4dC1ob3AgKG90aGVyd2lzZSwgd2UgY291bGQgaGF2ZSBwYXRoIGV4cGxvc2lvbiBhY3Jvc3Mg bXVsdGlwbGUgbGV2ZWxzIG9mIFJScyk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+LSBJZiBBREQtUEFUSFMgaGFzIHRvIGFkdmVydGlzZSB0 aGUgc2FtZSBOTFJJIHdpdGggZGlmZmVyZW50IGV4dC1jb21tdW5pdGllcywgb25lIHNvbHV0aW9u IHdvdWxkIGJlIGZvciBBREQtUEFIVFMgbm90IGFkdmVydGlzZSB0aGUgc2FtZSBzZXQgb2YgZXh0 LWNvbW11bml0aWVzLiBVbmxlc3MsIEkgZ3Vlc3MsIG5leHQtaG9wcyBhcmUgZGlmZmVyZW50LiBP dGhlcndpc2UsIHdlIHdvdWxkDQogaGF2ZSBwYXRoIGV4cGxvc2lvbi48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+LSBBc3N1bWluZyB0aGUg YWJvdmUsIHdlIHNob3VsZCBkZWZpbmUgYSBwYXJ0aWN1bGFyIHNldCBvZiBBREQtUEFUSFMgcnVs ZXMgZm9yIGZsb3dzcGVjIEFGLiBBbmQsIG9mIGNvdXJzZSwgbGVhdmUgdGhlIGRvb3Igb3BlbiBm b3IgZnV0dXJlIHNwZWNpZmljIEFERC1QQVRIcyBydWxlcyBmb3Igb3RoZXIgQUZzIChpdCB3b3Vs ZCBub3QgYmUgYWJvdXQgcGF0aCBkaXZlcnNpdHkgYW55bW9yZSwNCiBidXQgYWJvdXQgcHJvcGFn YXRpbmcgZGlmZmVyZW50IGluZm9ybWF0aW9uIGZvciBmb3J3YXJkaW5nIHB1cnBvc2VzIC1pbWFn aW5lIHdoYXQgd2UgY291bGQgaGF2ZSBkb25lIHdpdGggYW4gSVB2NCBwcmVmaXg6IHNlbmQgdGhl IHNhbWUgbmV0IHBhcnQgYXMgYSBOTFJJIGFuZCBtdWx0aXBsZSBleHQtY29tbXVuaXRpZXMgcmVw cmVzZW50aW5nIGRpZmZlcmVudCBwcmVmaXgtbGVuZ3RocyAtKS48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+LSBTaW5jZSBwYXRocyBpbiBh IG5ldCBhcmUgdHlwaWNhbGx5IGltcGxlbWVudGVkIGFzIGEgbGlzdCwgdGhlcmUgY291bGQgYmUg c2NhbGFiaWxpdHkgcHJvYmxlbXMgaWYgd2UgZXZlciB3YW50IHRvIHN1cHBvcnQgbWFueSBncm91 cC1pZHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQiPk15IHNvbHV0aW9uIHRvIHNpbXBsaWZ5IGFsbCB0aGVzZSBwcm9ibGVtcyB3b3VsZCBi ZSB0byBhZGQgYSBkaXNjcmltaW5hdG9yIG9uIHRoZSBOTFJJIChieSBkZWZpbmluZyBhIG5ldyBk dW1teSB0eXBlIGZvciBmbG93c3BlYykuIFdlIGNvdWxkIHN0aWxsIHVzZSBleHQtY29tbXVuaXRp ZXMgdG8gYWN0dWFsbHkgbWF0Y2ggdGhlIE5MUklzIHRvIGludGVyZmFjZXMuIFNpbWlsYXIgdG8g UkQNCiBhbmQgUlQgdXNhZ2UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQiPlRob3VnaHRzPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOiM4ODg4ODgiPi1KPC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjojODg4ODg4Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJZHIgbWFp bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOklkckBpZXRmLm9yZyI+SWRyQGlldGYub3Jn PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aWRyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9pZHI8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_8dd3e766b58944a3b176fc743e478137XCHALN014ciscocom_-- From nobody Thu Jul 27 01:51:06 2017 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B7003127136; Thu, 27 Jul 2017 01:50:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150114545663.11628.5593017977711166542@ietfa.amsl.com> Date: Thu, 27 Jul 2017 01:50:56 -0700 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-bgp-ls-segment-routing-rld-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 08:50:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing WG of the IETF. Title : Signalling ERLD using BGP-LS Authors : Gunter Van de Velde Wim Henderickx Matthew Bocci Keyur Patel Filename : draft-ietf-idr-bgp-ls-segment-routing-rld-00.txt Pages : 6 Date : 2017-07-27 Abstract: This document defines the attributes to use for BGP-LS to expose a node or link ERLD "Entropy capable Readable Label Depth" to a centralised controller (PCE/SDN). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-rld/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-rld-00 https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-segment-routing-rld-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 Thu Jul 27 12:44:47 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4210E129562 for ; Thu, 27 Jul 2017 12:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 O-zTI60fZ4gE for ; Thu, 27 Jul 2017 12:44:43 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0BB1126CD6 for ; Thu, 27 Jul 2017 12:44:43 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id m88so74279112iod.2 for ; Thu, 27 Jul 2017 12:44:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=jqAHbAGnPa2RhQ+FDSXc+TXvpup5BS5DDHwC96Px4dM=; b=tb5unLVqy+XVVPKzebOnKYRBNlA3fzH7os6BcoTF71iVbbPi0OSnF4+EOpbmYWUXoE SyHb/Xmlp5PJg/c9SYlPb35pFoP6KwZWeAgYIGAGhr2/kWo3KcNHvqZM57W+0gVLlvsS k2FCdKmkT+uyA6Z98wQI5QAJ9WycBIGPZe+DEjEdJBsJg5ykJ1x9KxNl9kZbcL2oOSMT chVFxpNuYdzlBmXqDwjx6P/Oy5Q5PjVrwyNDFGsKuU+i4LdLh+JElCR+Yz//rDwqSvHe 0Xibdt4xg2KC87wq8uZTOWEFRl+bA8Dbe7YBO4NtRn/vjxVj7vhuzQ8PnK905iRRXgsc u9Gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=jqAHbAGnPa2RhQ+FDSXc+TXvpup5BS5DDHwC96Px4dM=; b=LQqufl/igMLeaUCVGjGN/NPa+QugOBYKqrcKw4bZ8Ia9OTe5UfiuTXkKIRDLIjKKGO Wyx3RmS5ZIV9I2KRNA+pZ5ktqfLbAefAg+QXFhrkuEeakIw0ADNgVdZPygE379O5mGGW GWTNYKtFKNN1rjSPNm3zfSzC77dVF/4wPGzVFBhd5mNVxndArd7L8M16N8g9NwyxDrnv IA2V46MOIqMjUZgbKDe3Z/pPDz1X8PWcH6aMLF0rHVahxu43v/pa2ZtsxCWqVmL7AcuU DcilZr5A9fs/Vqlx/Ihjd0h/YtlPrPQy9+JQpJcAxWeUfzemQuSKOdvS+PBvGPGs1Ig9 DPWg== X-Gm-Message-State: AIVw111U2gnwPUuEP3EDurvMyK8pqjLCCK6pFslzll2zow47Ip36Yxae rWKunZ9f7azTMZuNZ2R3CaChTpMj7r+D X-Received: by 10.107.157.9 with SMTP id g9mr6996798ioe.46.1501184682836; Thu, 27 Jul 2017 12:44:42 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.153.21 with HTTP; Thu, 27 Jul 2017 12:44:42 -0700 (PDT) In-Reply-To: <8dd3e766b58944a3b176fc743e478137@XCH-ALN-014.cisco.com> References: <9fa67eb0-8f99-a46f-aff1-d42a279ab833@cisco.com> <8dd3e766b58944a3b176fc743e478137@XCH-ALN-014.cisco.com> From: Robert Raszuk Date: Thu, 27 Jul 2017 21:44:42 +0200 X-Google-Sender-Auth: TVYCeOmGP9YbcUliK8jzU6k4lTU Message-ID: To: "Jakob Heitz (jheitz)" Cc: "Juan Alcaide (jalcaide)" , idr wg Content-Type: multipart/alternative; boundary="001a1140c5c6c34f9c055551cb96" Archived-At: Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT (part 2) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 19:44:46 -0000 --001a1140c5c6c34f9c055551cb96 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jakob, Two flowspec routes with the same NLRI may be originated by different > speakers. > Group-id (scoped application of specific flow-spec rules) is addressing a special case where it is generated carefully by either controller or provisioning tools. I do not see therefor a practical case where the same such rule would be coming from two or more independent sources and would be applicable =E2=80=8Bto different interface groups. It sounds more like a protocol conflict or provisioning bug and not something we should worry about how to carry it across RRs. Standard protocol behavior would be fine here. Now also notice what would receiver do ... treat the subsequent update with the exactly same NLRI as implicit withdraw or run best path if they come from different peers and still apply single one to local data plane. So really there is no point to give it both such paths with ADD-PATHs. As it is on final receivers the same should be done on RRs ... =E2=80=8BCheers, //RR.=E2=80=8B > The first route will have one group-id. The second route will have anothe= r > group-id. > > > > Thanks, > > Jakob. > > > > *From:* Idr [mailto:idr-bounces@ietf.org] *On Behalf Of *Robert Raszuk > *Sent:* Wednesday, July 26, 2017 4:38 PM > *To:* Juan Alcaide (jalcaide) > *Cc:* idr wg > *Subject:* Re: [Idr] draft-litkowski-idr-flowspec-interfaceset =3D> NLRI = vs > EXTCT (part 2) > > > > Hi Juan, > > > > > (we assume controller(s) may not want to send multiple ext-communities > with same NLRI). > > > > If I recall group-ids are carried in new RT format: > > > > "This new BGP Route Target extended community is encoded as follows : > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type (TBD) | 0x02 | Autonomous System Number : > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > : AS Number (cont.) |O|I| Group Identifier | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > " > > > > So just like an UPDATE message of SAFI 128 may contain many RTs why would > you see any > > issue to carry multiple ext communities of the above format here ? > > > > Best, > > R. > > > > On Thu, Jul 27, 2017 at 1:01 AM, Juan Alcaide (jalcaide) < > jalcaide@cisco.com> wrote: > > Hi, > > From a previous thread, I see from the that using EXTCOMM to carry > group-id information the choice. Reason was that every AS could use their > own the group-id (perhaps different than another AS). With this choice, > ADD-PATHS must be mandatory in order to support multiple group-ids for th= e > same flowspec rule (we assume controller(s) may not want to send multipl= e > ext-communities with same NLRI). > > But the draft really does not describe how to use ADD-PATHS, and it does > not discuss its problems: > > - Usually, ADD-PATHS is used for path diversity, and implementations > typically don't advertise 2 paths with the same next-hop (otherwise, we > could have path explosion across multiple levels of RRs) > > - If ADD-PATHS has to advertise the same NLRI with different > ext-communities, one solution would be for ADD-PAHTS not advertise the sa= me > set of ext-communities. Unless, I guess, next-hops are different. > Otherwise, we would have path explosion. > > - Assuming the above, we should define a particular set of ADD-PATHS rule= s > for flowspec AF. And, of course, leave the door open for future specific > ADD-PATHs rules for other AFs (it would not be about path diversity > anymore, but about propagating different information for forwarding > purposes -imagine what we could have done with an IPv4 prefix: send the > same net part as a NLRI and multiple ext-communities representing differe= nt > prefix-lengths -). > > - Since paths in a net are typically implemented as a list, there could b= e > scalability problems if we ever want to support many group-ids. > > My solution to simplify all these problems would be to add a discriminato= r > on the NLRI (by defining a new dummy type for flowspec). We could still u= se > ext-communities to actually match the NLRIs to interfaces. Similar to RD > and RT usage. > > Thoughts? > > -J > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > > --001a1140c5c6c34f9c055551cb96 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jakob,

Two flowspec routes with the same NLRI may b= e originated by different speakers.


Group-id (scoped application of specific= flow-spec rules) is addressing a special case where it is generated carefu= lly by either controller or provisioning tools. I do not see therefor a pra= ctical case where the same such rule would be coming from two or more indep= endent sources and would be applicable =E2=80=8Bto different interface grou= ps.=C2=A0

It sounds mo= re like a protocol conflict or provisioning bug and not something we should= worry about how to carry it across RRs. Standard protocol behavior would b= e fine here.

Now also = notice what would receiver do ... treat the subsequent update with the exac= tly same NLRI as implicit withdraw or run best path if they come from diffe= rent peers and still apply single one to local data plane. So really there = is no point to give it both such paths with ADD-PATHs. As it is on final re= ceivers the same should be done on RRs ...=C2=A0

=E2=80=8BCheers,
//RR.=E2=80=8B

<= div>=C2=A0

The first route will have one group-id. The = second route will have another group-id.

=C2=A0

Thanks,

Jakob.

=C2=A0

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: Wednesday, July 26, 2017 4:38 PM
To: Juan Alcaide (jalcaide) <jalcaide@cisco.com>
Cc: idr wg <idr= @ietf.org>
Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset = =3D> NLRI vs EXTCT (part 2)

=C2=A0

Hi Juan,

=C2=A0

>=C2=A0=C2=A0(we assume controller(s) may not want to send multiple= ext-communities with same NLRI).

=C2=A0

If I recall group-ids are carried in new RT format:=C2=A0

=C2=A0

"This new BGP Route Target extended community is encoded as follo= ws :

=C2=A0

= =C2=A0 =C2=A0 =C2=A0 =C2=A00 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3<= /span>

= =C2=A0 =C2=A0 =C2=A0 =C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 = 4 5 6 7 8 9 0 1

= =C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+

= =C2=A0 =C2=A0 =C2=A0 | =C2=A0Type (TBD) =C2=A0 | =C2=A0 =C2=A0 =C2=A00x02 = =C2=A0 =C2=A0 | =C2=A0 =C2=A0Autonomous System Number =C2=A0 :

= =C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+

= =C2=A0 =C2=A0 =C2=A0 : =C2=A0 =C2=A0 AS Number (cont.) =C2=A0 =C2=A0 =C2=A0= =C2=A0 |O|I| =C2=A0 =C2=A0 =C2=A0Group Identifier =C2=A0 =C2=A0 |

= =C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+

= "

=C2=A0

So just like an UPDATE message of SAFI 128 may contain many RTs why wo= uld you see any=C2=A0

issue to carry multiple ext communities of the above format here ?=C2= =A0

=C2=A0

Best,

R.

=C2=A0

On Thu, Jul 27, 2017 at 1:01 AM, Juan Alcaide (jalca= ide) <jalcaide@c= isco.com> wrote:

Hi,

From a previous thread, I see from the = that using EXTCOMM to carry group-id information the choice. Reason was tha= t every AS could use their own the group-id (perhaps different than another= AS). With this choice, ADD-PATHS must be mandatory in order to support multiple group-ids for the same flow= spec rule=C2=A0 (we assume controller(s) may not want to send multiple ext-= communities with same NLRI).

But the draft really does not describe = how to use ADD-PATHS, and it does not discuss its problems:

- Usually, ADD-PATHS is used for path d= iversity, and implementations typically don't advertise 2 paths with th= e same next-hop (otherwise, we could have path explosion across multiple le= vels of RRs)

- If ADD-PATHS has to advertise the sam= e NLRI with different ext-communities, one solution would be for ADD-PAHTS = not advertise the same set of ext-communities. Unless, I guess, next-hops a= re different. Otherwise, we would have path explosion.

- Assuming the above, we should define = a particular set of ADD-PATHS rules for flowspec AF. And, of course, leave = the door open for future specific ADD-PATHs rules for other AFs (it would n= ot be about path diversity anymore, but about propagating different information for forwarding purposes -imagi= ne what we could have done with an IPv4 prefix: send the same net part as a= NLRI and multiple ext-communities representing different prefix-lengths -)= .

- Since paths in a net are typically im= plemented as a list, there could be scalability problems if we ever want to= support many group-ids.

My solution to simplify all these probl= ems would be to add a discriminator on the NLRI (by defining a new dummy ty= pe for flowspec). We could still use ext-communities to actually match the = NLRIs to interfaces. Similar to RD and RT usage.

Thoughts?

-J


_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

=C2=A0


--001a1140c5c6c34f9c055551cb96-- From nobody Thu Jul 27 14:37:33 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4343A131C20 for ; Thu, 27 Jul 2017 14:37:31 -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 Lsgso2aFavcz for ; Thu, 27 Jul 2017 14:37:28 -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 C19B213170E for ; Thu, 27 Jul 2017 14:37:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26890; q=dns/txt; s=iport; t=1501191447; x=1502401047; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=DQ6moy7FpHZw5wQV4g5VsgJNCRRvv+iP75XY5+kxQyo=; b=RG0zxo2ciTOtj+EwDCo8C4YjAo6gwLkI+JROhCtUfZYl3flrc28J6ZXT AuOu6nfN/VWbh/kOFmED3DRElF+NxDFHNQWZOJzkpgf1TQ0Ml+zjuIcU5 Kiwe0V/pRo1vlT+f+Csj5Fxz195eDKUq9ohO1eD/S7PXgqvXzbwvbuzmT w=; X-IronPort-AV: E=Sophos;i="5.40,422,1496102400"; d="scan'208,217";a="462546325" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Jul 2017 21:37:27 +0000 Received: from [10.82.221.134] (rtp-vpn3-1408.cisco.com [10.82.221.134]) (authenticated bits=0) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v6RLbO2Q030157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 27 Jul 2017 21:37:26 GMT To: Robert Raszuk , "Jakob Heitz (jheitz)" Cc: idr wg References: <9fa67eb0-8f99-a46f-aff1-d42a279ab833@cisco.com> <8dd3e766b58944a3b176fc743e478137@XCH-ALN-014.cisco.com> From: "Juan Alcaide (jalcaide)" Message-ID: Date: Thu, 27 Jul 2017 23:37:23 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------FA8EF27623FF219BFBBC4E79" Content-Language: en-US X-Authenticated-User: jalcaide Archived-At: Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT (part 2) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 21:37:31 -0000 This is a multi-part message in MIME format. --------------FA8EF27623FF219BFBBC4E79 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Robert, We may support or not support unsynchronized controllers But let's assume for a second we are just using one controller but can a single controller sending NLRI1 + group-id 1 NLRI1 + group-id 2 The RR receives both this routes (must be ADD-PATHS, as mentioned in the draft). The RR needs to use ADD-PATHS itself to send it to the PE (final receiver) -J On 7/27/2017 9:44 PM, Robert Raszuk wrote: > Hi Jakob, > > Two flowspec routes with the same NLRI may be originated by > different speakers. > > > Group-id (scoped application of specific flow-spec rules) is > addressing a special case where it is generated carefully by either > controller or provisioning tools. I do not see therefor a practical > case where the same such rule would be coming from two or more > independent sources and would be applicable ​to different interface > groups. > > It sounds more like a protocol conflict or provisioning bug and not > something we should worry about how to carry it across RRs. Standard > protocol behavior would be fine here. > > Now also notice what would receiver do ... treat the subsequent update > with the exactly same NLRI as implicit withdraw or run best path if > they come from different peers and still apply single one to local > data plane. So really there is no point to give it both such paths > with ADD-PATHs. As it is on final receivers the same should be done on > RRs ... > > ​Cheers, > //RR.​ > > The first route will have one group-id. The second route will have > another group-id. > > Thanks, > > Jakob. > > *From:*Idr [mailto:idr-bounces@ietf.org > ] *On Behalf Of *Robert Raszuk > *Sent:* Wednesday, July 26, 2017 4:38 PM > *To:* Juan Alcaide (jalcaide) > > *Cc:* idr wg > > *Subject:* Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => > NLRI vs EXTCT (part 2) > > Hi Juan, > > > (we assume controller(s) may not want to send multiple > ext-communities with same NLRI). > > If I recall group-ids are carried in new RT format: > > "This new BGP Route Target extended community is encoded as follows : > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type (TBD) | 0x02 | Autonomous System Number : > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > : AS Number (cont.) |O|I| Group Identifier > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > " > > So just like an UPDATE message of SAFI 128 may contain many RTs > why would you see any > > issue to carry multiple ext communities of the above format here ? > > Best, > > R. > > On Thu, Jul 27, 2017 at 1:01 AM, Juan Alcaide (jalcaide) > > wrote: > > Hi, > > From a previous thread, I see from the that using EXTCOMM to > carry group-id information the choice. Reason was that every > AS could use their own the group-id (perhaps different than > another AS). With this choice, ADD-PATHS must be mandatory in > order to support multiple group-ids for the same flowspec > rule (we assume controller(s) may not want to send multiple > ext-communities with same NLRI). > > But the draft really does not describe how to use ADD-PATHS, > and it does not discuss its problems: > > - Usually, ADD-PATHS is used for path diversity, and > implementations typically don't advertise 2 paths with the > same next-hop (otherwise, we could have path explosion across > multiple levels of RRs) > > - If ADD-PATHS has to advertise the same NLRI with different > ext-communities, one solution would be for ADD-PAHTS not > advertise the same set of ext-communities. Unless, I guess, > next-hops are different. Otherwise, we would have path explosion. > > - Assuming the above, we should define a particular set of > ADD-PATHS rules for flowspec AF. And, of course, leave the > door open for future specific ADD-PATHs rules for other AFs > (it would not be about path diversity anymore, but about > propagating different information for forwarding purposes > -imagine what we could have done with an IPv4 prefix: send the > same net part as a NLRI and multiple ext-communities > representing different prefix-lengths -). > > - Since paths in a net are typically implemented as a list, > there could be scalability problems if we ever want to support > many group-ids. > > My solution to simplify all these problems would be to add a > discriminator on the NLRI (by defining a new dummy type for > flowspec). We could still use ext-communities to actually > match the NLRIs to interfaces. Similar to RD and RT usage. > > Thoughts? > > -J > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > > --------------FA8EF27623FF219BFBBC4E79 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Robert,

We may support or not support unsynchronized controllers
But let's assume for a second we are just using one controller
but can a single controller sending

NLRI1 + group-id 1
NLRI1 + group-id 2

The RR receives both this routes (must be ADD-PATHS, as mentioned in the draft). The RR needs to use ADD-PATHS itself to send it to the PE (final receiver)

-J



On 7/27/2017 9:44 PM, Robert Raszuk wrote:
Hi Jakob,

Two flowspec routes with the same NLRI may be originated by different speakers.


Group-id (scoped application of specific flow-spec rules) is addressing a special case where it is generated carefully by either controller or provisioning tools. I do not see therefor a practical case where the same such rule would be coming from two or more independent sources and would be applicable ​to different interface groups. 

It sounds more like a protocol conflict or provisioning bug and not something we should worry about how to carry it across RRs. Standard protocol behavior would be fine here.

Now also notice what would receiver do ... treat the subsequent update with the exactly same NLRI as implicit withdraw or run best path if they come from different peers and still apply single one to local data plane. So really there is no point to give it both such paths with ADD-PATHs. As it is on final receivers the same should be done on RRs ... 

​Cheers,
//RR.​

 

The first route will have one group-id. The second route will have another group-id.

 

Thanks,

Jakob.

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: Wednesday, July 26, 2017 4:38 PM
To: Juan Alcaide (jalcaide) <jalcaide@cisco.com>
Cc: idr wg <idr@ietf.org>
Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT (part 2)

 

Hi Juan,

 

>  (we assume controller(s) may not want to send multiple ext-communities with same NLRI).

 

If I recall group-ids are carried in new RT format: 

 

"This new BGP Route Target extended community is encoded as follows :

 

       0                   1                   2                   3

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |  Type (TBD)   |      0x02     |    Autonomous System Number   :

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      :     AS Number (cont.)         |O|I|      Group Identifier     |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

"

 

So just like an UPDATE message of SAFI 128 may contain many RTs why would you see any 

issue to carry multiple ext communities of the above format here ? 

 

Best,

R.

 

On Thu, Jul 27, 2017 at 1:01 AM, Juan Alcaide (jalcaide) <jalcaide@cisco.com> wrote:

Hi,

From a previous thread, I see from the that using EXTCOMM to carry group-id information the choice. Reason was that every AS could use their own the group-id (perhaps different than another AS). With this choice, ADD-PATHS must be mandatory in order to support multiple group-ids for the same flowspec rule  (we assume controller(s) may not want to send multiple ext-communities with same NLRI).

But the draft really does not describe how to use ADD-PATHS, and it does not discuss its problems:

- Usually, ADD-PATHS is used for path diversity, and implementations typically don't advertise 2 paths with the same next-hop (otherwise, we could have path explosion across multiple levels of RRs)

- If ADD-PATHS has to advertise the same NLRI with different ext-communities, one solution would be for ADD-PAHTS not advertise the same set of ext-communities. Unless, I guess, next-hops are different. Otherwise, we would have path explosion.

- Assuming the above, we should define a particular set of ADD-PATHS rules for flowspec AF. And, of course, leave the door open for future specific ADD-PATHs rules for other AFs (it would not be about path diversity anymore, but about propagating different information for forwarding purposes -imagine what we could have done with an IPv4 prefix: send the same net part as a NLRI and multiple ext-communities representing different prefix-lengths -).

- Since paths in a net are typically implemented as a list, there could be scalability problems if we ever want to support many group-ids.

My solution to simplify all these problems would be to add a discriminator on the NLRI (by defining a new dummy type for flowspec). We could still use ext-communities to actually match the NLRIs to interfaces. Similar to RD and RT usage.

Thoughts?

-J


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

 



--------------FA8EF27623FF219BFBBC4E79-- From nobody Thu Jul 27 14:43:53 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4542131467 for ; Thu, 27 Jul 2017 14:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 1RwH7KWdlMzI for ; Thu, 27 Jul 2017 14:43:49 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4E90131E67 for ; Thu, 27 Jul 2017 14:43:48 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id j32so63354442iod.0 for ; Thu, 27 Jul 2017 14:43:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=tIn40r+QFbvBDgrUUjpL2Gsj/SIF/IpRjFAMQLdz2K8=; b=r1OZJ47k+eqDp27XcVJfAt8HJHxHj9pEfkgMpEct5IGuKwZOoylwgSnEzh8NjImOLJ PWVbSywkt6Ue6+4iniHh+5KE4XI6JW047OaM9f7GietkdL2gj72sX4vWMg2heXrsZoUG lLDCOr7oZe5BuIweX9QJVXayagMtyizVw70saX4e4QI6tKEsAb0GJdqd8iVoXk4hP0aD lKabgY47Y8xdAqQOi75k13cImy+FRyi2UYbIUwEfq69prdKk8sSWKcxec/aKBN6Tp/uC OA/jTF7iBYnoVU2kuatkdnsJHcPx2drVxByJcrxv6s6dV6Ri/InjEX9CfXktn4PuqUkm kjew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=tIn40r+QFbvBDgrUUjpL2Gsj/SIF/IpRjFAMQLdz2K8=; b=t5X3b12AXLA9rB/4WfOlaLldCBo19LxBtYgxspQ+blDbgjrRryvZLkIN/bXYi/vCup uCCzqkQ2dUSSBi08Q2ykzYVu4OpVtplj4rny2cd64ZAyGvhck2jZfNyqdqF2E53UdKcl IMnso/PuW4ZiBxz99J1fz+G3suyXm7sLIQbs2zFASyh+mtW9B7d8VprL6gjzkNpmxowi FS3VTTjKCfM6CIJmPrbeXPEgkrjt8NZFEnSQ3iK96p2q22w29gfVRoivv2ZlE7YGEr5t NseF8WYMdaAGL+tVDp/f30xgjzAhNPAVuo4Nt0mMbcNXA+eiPKDLYa5F6Hx4Hz76zULq kGSw== X-Gm-Message-State: AIVw113o+ml7zf5s/Ug6W9pqa14+Opia/s+kvPJtpJw9FjZV9u3PzUtU B/JxDbxebXUFgW8BmBeCeRmua/7NTZ/k X-Received: by 10.107.175.136 with SMTP id p8mr7040272ioo.219.1501191827984; Thu, 27 Jul 2017 14:43:47 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.153.21 with HTTP; Thu, 27 Jul 2017 14:43:47 -0700 (PDT) In-Reply-To: References: <9fa67eb0-8f99-a46f-aff1-d42a279ab833@cisco.com> <8dd3e766b58944a3b176fc743e478137@XCH-ALN-014.cisco.com> From: Robert Raszuk Date: Thu, 27 Jul 2017 23:43:47 +0200 X-Google-Sender-Auth: XPb7-5B_X5CgYjJ2MLpZSRVTd4E Message-ID: To: "Juan Alcaide (jalcaide)" Cc: "Jakob Heitz (jheitz)" , idr wg Content-Type: multipart/alternative; boundary="001a11447f72a598940555537517" Archived-At: Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT (part 2) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 21:43:52 -0000 --001a11447f72a598940555537517 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Juan, Sending from single controller (single BGP peer) two updates with identical NLRIs is an implicit withdraw. ADD-PATHs has nothing to here. Likewise RR should treat is as implicit withdraw of the previous one too. If you go by your line of thinking what would make controller to change for given NLRI1 group-id 1 to group-id 2 if there is need to do so ? In any case if you decide to add additional text to the current draft or decide to write new draft to address this please do make sure to clearly define two things: 1. How for a given NLRI we change either actions or group-ids 2. What should receiver do when for a given NLRI he received more then one group-id or more then one set of actions ? Thanks, R. On Thu, Jul 27, 2017 at 11:37 PM, Juan Alcaide (jalcaide) < jalcaide@cisco.com> wrote: > Robert, > > We may support or not support unsynchronized controllers > But let's assume for a second we are just using one controller > but can a single controller sending > > NLRI1 + group-id 1 > NLRI1 + group-id 2 > > The RR receives both this routes (must be ADD-PATHS, as mentioned in the > draft). The RR needs to use ADD-PATHS itself to send it to the PE (final > receiver) > > -J > > > > > On 7/27/2017 9:44 PM, Robert Raszuk wrote: > > Hi Jakob, > > Two flowspec routes with the same NLRI may be originated by different >> speakers. >> > > Group-id (scoped application of specific flow-spec rules) is addressing a > special case where it is generated carefully by either controller or > provisioning tools. I do not see therefor a practical case where the same > such rule would be coming from two or more independent sources and would = be > applicable =E2=80=8Bto different interface groups. > > It sounds more like a protocol conflict or provisioning bug and not > something we should worry about how to carry it across RRs. Standard > protocol behavior would be fine here. > > Now also notice what would receiver do ... treat the subsequent update > with the exactly same NLRI as implicit withdraw or run best path if they > come from different peers and still apply single one to local data plane. > So really there is no point to give it both such paths with ADD-PATHs. As > it is on final receivers the same should be done on RRs ... > > =E2=80=8BCheers, > //RR.=E2=80=8B > > > >> The first route will have one group-id. The second route will have >> another group-id. >> >> >> >> Thanks, >> >> Jakob. >> >> >> >> *From:* Idr [mailto:idr-bounces@ietf.org] *On Behalf Of *Robert Raszuk >> *Sent:* Wednesday, July 26, 2017 4:38 PM >> *To:* Juan Alcaide (jalcaide) >> *Cc:* idr wg >> *Subject:* Re: [Idr] draft-litkowski-idr-flowspec-interfaceset =3D> NLRI >> vs EXTCT (part 2) >> >> >> >> Hi Juan, >> >> >> >> > (we assume controller(s) may not want to send multiple ext-communitie= s >> with same NLRI). >> >> >> >> If I recall group-ids are carried in new RT format: >> >> >> >> "This new BGP Route Target extended community is encoded as follows : >> >> >> >> 0 1 2 3 >> >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> | Type (TBD) | 0x02 | Autonomous System Number : >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> : AS Number (cont.) |O|I| Group Identifier | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> " >> >> >> >> So just like an UPDATE message of SAFI 128 may contain many RTs why woul= d >> you see any >> >> issue to carry multiple ext communities of the above format here ? >> >> >> >> Best, >> >> R. >> >> >> >> On Thu, Jul 27, 2017 at 1:01 AM, Juan Alcaide (jalcaide) < >> jalcaide@cisco.com> wrote: >> >> Hi, >> >> From a previous thread, I see from the that using EXTCOMM to carry >> group-id information the choice. Reason was that every AS could use thei= r >> own the group-id (perhaps different than another AS). With this choice, >> ADD-PATHS must be mandatory in order to support multiple group-ids for t= he >> same flowspec rule (we assume controller(s) may not want to send multip= le >> ext-communities with same NLRI). >> >> But the draft really does not describe how to use ADD-PATHS, and it does >> not discuss its problems: >> >> - Usually, ADD-PATHS is used for path diversity, and implementations >> typically don't advertise 2 paths with the same next-hop (otherwise, we >> could have path explosion across multiple levels of RRs) >> >> - If ADD-PATHS has to advertise the same NLRI with different >> ext-communities, one solution would be for ADD-PAHTS not advertise the s= ame >> set of ext-communities. Unless, I guess, next-hops are different. >> Otherwise, we would have path explosion. >> >> - Assuming the above, we should define a particular set of ADD-PATHS >> rules for flowspec AF. And, of course, leave the door open for future >> specific ADD-PATHs rules for other AFs (it would not be about path >> diversity anymore, but about propagating different information for >> forwarding purposes -imagine what we could have done with an IPv4 prefix= : >> send the same net part as a NLRI and multiple ext-communities representi= ng >> different prefix-lengths -). >> >> - Since paths in a net are typically implemented as a list, there could >> be scalability problems if we ever want to support many group-ids. >> >> My solution to simplify all these problems would be to add a >> discriminator on the NLRI (by defining a new dummy type for flowspec). W= e >> could still use ext-communities to actually match the NLRIs to interface= s. >> Similar to RD and RT usage. >> >> Thoughts? >> >> -J >> >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> >> >> > > > --001a11447f72a598940555537517 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Juan,

Sending from single controller (single BGP peer) two up= dates with identical NLRIs is an implicit withdraw. ADD-PATHs has nothing t= o here.=C2=A0

Likewise= RR should treat is as implicit withdraw of the previous one too.=C2=A0

If you go by your line of= thinking what would make controller to change for given NLRI1 group-id 1 t= o group-id 2 if there is need to do so ?=C2=A0

=
In any case if you decide to add additional text t= o the current draft or decide to write new draft to address this please do = make sure to clearly define two things:

<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small">1. How for a given NLRI we change either actions or group= -ids=C2=A0

2. What sho= uld receiver do when for a given NLRI he received more then one group-id or= more then one set of actions ?=C2=A0

Thanks,
R.
=




On Thu, Jul 27, 2017 at 11:37 PM, Juan Alcaide (jalcaide) <j= alcaide@cisco.com> wrote:
=20 =20 =20
Robert,

We may support or not support unsynchronized controllers
But let's assume for a second we are just using one controller but can a single controller sending

NLRI1 + group-id 1
NLRI1 + group-id 2

The RR receives both this routes (must be ADD-PATHS, as mentioned in the draft). The RR needs to use ADD-PATHS itself to send it to the PE (final receiver)

-J




On 7/27/2017 9:44 PM, Robert Raszuk wrote:
=20
Hi Jakob,

Two flowspec routes with the same NLRI may be originated by different speakers.


Group-id (scoped application of specific flow-spec rules) is addressing a special case where it is generated carefully by either controller or provisioning tools. I do not see therefor a practical case where the same such rule would be coming from two or more independent sources and would be applicable =E2=80=8Bto different inter= face groups.=C2=A0

It sounds more like a protocol conflict or provisioning bug and not something we should worry about how to carry it across RRs. Standard protocol behavior would be fine here.

Now also notice what would receiver do ... treat the subsequent update with the exactly same NLRI as implicit withdraw or run best path if they come from different peers and still apply single one to local data plane. So really there is no point to give it both such paths with ADD-PATHs. As it is on final receivers the same should be done on RRs ...=C2=A0

=E2=80=8BCheers,
//RR.=E2=80=8B

=C2=A0

The first route will have one group-id. The second route will have another group-id.

=C2=A0

Thanks,

Jakob.

=C2=A0

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: Wednesday, July 26, 2017 4:38 PM
To: Juan Alcaide (jalcaide) <jalcaide@cisco.com>=
Cc: idr wg <idr@ietf.org>
Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset =3D> NLRI vs EXTCT (part 2)

=C2=A0

Hi Juan,

=C2=A0

>=C2=A0=C2=A0(we assume controller(s) may not want to send multiple ext-communities with same NLRI).

=C2=A0

If I recall group-ids are carried in new RT format:=C2=A0

=C2=A0

"This new BGP Route Target extended community is encoded as follows :

=C2=A0

=C2=A0 =C2=A0 = =C2=A0 =C2=A00 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 3

=C2=A0 =C2=A0 = =C2=A0 =C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

=C2=A0 =C2=A0 = =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=C2=A0 =C2=A0 = =C2=A0 | =C2=A0Type (TBD) =C2=A0 | =C2=A0 =C2=A0 =C2=A00x02 =C2=A0 =C2=A0 | =C2=A0 =C2=A0A= utonomous System Number =C2=A0 :

=C2=A0 =C2=A0 = =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=C2=A0 =C2=A0 = =C2=A0 : =C2=A0 =C2=A0 AS Number (cont.) =C2=A0 =C2=A0 =C2=A0 =C2=A0 |O|I|= =C2=A0 =C2=A0 =C2=A0Group Identifier =C2=A0 =C2=A0 |

=C2=A0 =C2=A0 = =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+

"

=C2=A0

So just like an UPDATE message of SAFI 128 may contain many RTs why would you see any=C2=A0

issue to carry multiple ext communities of the above format here ?=C2=A0

=C2=A0

Best,

R.

=C2=A0

On Thu, Jul 27, 2017 at 1:01 AM, Juan Alcaide (jalcaide) <jalcaide@cisco.com> wrote:

Hi,

From a previous thread, I see from the that using EXTCOMM to carry group-id information the choice. Reason was that every AS could use their own the group-id (perhaps different than another AS). With this choice, ADD-PATHS must be mandatory in order to support multiple group-ids for the same flowspec rule=C2=A0 (we assume controller(s) may not want to send multiple ext-communities with same NLRI).

But the draft really does not describe how to use ADD-PATHS, and it does not discuss its problems:

- Usually, ADD-PATHS is used for path diversity, and implementations typically don't advertise 2 paths with the same next-hop (otherwise, we could have path explosion across multiple levels of RRs)

- If ADD-PATHS has to advertise the same NLRI with different ext-communities, one solution would be for ADD-PAHTS not advertise the same set of ext-communities. Unless, I guess, next-hops are different. Otherwise, we would have path explosion.

- Assuming the above, we should define a particular set of ADD-PATHS rules for flowspec AF. And, of course, leave the door open for future specific ADD-PATHs rules for other AFs (it would not be about path diversity anymore, but about propagating different information for forwarding purposes -imagine what we could have done with an IPv4 prefix: send the same net part as a NLRI and multiple ext-communities representing different prefix-lengths -).

- Since paths in a net are typically implemented as a list, there could be scalability problems if we ever want to support many group-ids.<= /p>

My solution to simplify all these problems would be to add a discriminator on the NLRI (by defining a new dummy type for flowspec). We could still use ext-communities to actually match the NLRIs to interfaces. Similar to RD and RT usage.

Thought= s?

-J


______________________________________= _________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr=

=C2=A0




--001a11447f72a598940555537517-- From nobody Thu Jul 27 14:49:30 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECFDD1321C2 for ; Thu, 27 Jul 2017 14:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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, T_KAM_HTML_FONT_INVALID=0.01, 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 vNadyuqJiKIa for ; Thu, 27 Jul 2017 14:49:25 -0700 (PDT) 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 88049131D0A for ; Thu, 27 Jul 2017 14:49:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34804; q=dns/txt; s=iport; t=1501192165; x=1502401765; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=KH/DkOvbNNyH+cgHRQhRklg9GIYuY0A427qX++LJez8=; b=K9AFvwvYCIhDKqQLVgx5hZtGT9r+eKKI9ZgUrDBPo8m0MfDWVrpbCvea y7IIkip/+Os2jsNo6in2lth1sJLZ6fZEHq3QBm8bZUzj7NJLS5tXiBn5z d324e/vJZdJClA0KM7YuK+7JdfAFG0vg2C4poQ9TzvqdPXEgmlCDjdOY6 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CbAAAzX3pZ/5BdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm8+LWRtJweOBpFidJUWghIhAQqFGwIag0s/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRgBAQEBAwEBIQo6BwsQAgEIEQQBASEHAwICAiULFAkIAgQBDQUIDAeJMGQQr?= =?us-ascii?q?2WCJieLGAEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgyiDTYFhgnA0hQofgl2CYQW?= =?us-ascii?q?XXIgKAosYg06FNIIVGZAXiVOMHgEfOD9LdxVJhxl2h0AHgSuBDgEBAQ?= X-IronPort-AV: E=Sophos;i="5.40,422,1496102400"; d="scan'208,217";a="273640243" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jul 2017 21:49:24 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v6RLnOqo006237 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Jul 2017 21:49:24 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 27 Jul 2017 16:49:23 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Thu, 27 Jul 2017 16:49:23 -0500 From: "Jakob Heitz (jheitz)" To: "Juan Alcaide (jalcaide)" , Robert Raszuk CC: idr wg Thread-Topic: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT (part 2) Thread-Index: AQHTBmMsA+kuai771EGHOw9ST46Op6JnF2sA//+2lRCAAZqgAIAAH3uA//+ujPA= Date: Thu, 27 Jul 2017 21:49:23 +0000 Message-ID: References: <9fa67eb0-8f99-a46f-aff1-d42a279ab833@cisco.com> <8dd3e766b58944a3b176fc743e478137@XCH-ALN-014.cisco.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.24.45] Content-Type: multipart/alternative; boundary="_000_db34ca243ca94b3d9dd60038dcc4b7aeXCHALN014ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT (part 2) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 21:49:28 -0000 --_000_db34ca243ca94b3d9dd60038dcc4b7aeXCHALN014ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SnVhbiwNCg0KanVzdCB0byB5b3UuDQoNCkl0IGNhbiBzZW5kIG9uZSByb3V0ZToNCk5MUkkxICsg Z3JvdXAtaWQgMSArIGdyb3VwLWlkIDINCg0KVGhlIGFyZ3VtZW50IHRoYXQgdGhlcmUgbWF5IGJl IHRvbyBtYW55IGdyb3VwLWlkcyB0byBmaXQgaW50byBhIEJHUCB1cGRhdGUgbWVzc2FnZSBpcyB0 b28gd2Vhay4NCllvdSB3b3VsZCBoYXZlIHRvIGRlbW9uc3RyYXRlIGEgY2FzZSB0aGF0IGFjdHVh bGx5IGhhcHBlbmVkIGFuZCBub3QganVzdCBoeXBvdGhldGljYWwuDQoNClRoYW5rcywNCkpha29i Lg0KDQpGcm9tOiBKdWFuIEFsY2FpZGUgKGphbGNhaWRlKQ0KU2VudDogVGh1cnNkYXksIEp1bHkg MjcsIDIwMTcgMjozNyBQTQ0KVG86IFJvYmVydCBSYXN6dWsgPHJvYmVydEByYXN6dWsubmV0Pjsg SmFrb2IgSGVpdHogKGpoZWl0eikgPGpoZWl0ekBjaXNjby5jb20+DQpDYzogaWRyIHdnIDxpZHJA aWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0lkcl0gZHJhZnQtbGl0a293c2tpLWlkci1mbG93c3Bl Yy1pbnRlcmZhY2VzZXQgPT4gTkxSSSB2cyBFWFRDVCAocGFydCAyKQ0KDQpSb2JlcnQsDQoNCldl IG1heSBzdXBwb3J0IG9yIG5vdCBzdXBwb3J0IHVuc3luY2hyb25pemVkIGNvbnRyb2xsZXJzDQpC dXQgbGV0J3MgYXNzdW1lIGZvciBhIHNlY29uZCB3ZSBhcmUganVzdCB1c2luZyBvbmUgY29udHJv bGxlcg0KYnV0IGNhbiBhIHNpbmdsZSBjb250cm9sbGVyIHNlbmRpbmcNCg0KTkxSSTEgKyBncm91 cC1pZCAxDQpOTFJJMSArIGdyb3VwLWlkIDINCg0KVGhlIFJSIHJlY2VpdmVzIGJvdGggdGhpcyBy b3V0ZXMgKG11c3QgYmUgQURELVBBVEhTLCBhcyBtZW50aW9uZWQgaW4gdGhlIGRyYWZ0KS4gVGhl IFJSIG5lZWRzIHRvIHVzZSBBREQtUEFUSFMgaXRzZWxmIHRvIHNlbmQgaXQgdG8gdGhlIFBFIChm aW5hbCByZWNlaXZlcikNCg0KLUoNCg0KDQoNCk9uIDcvMjcvMjAxNyA5OjQ0IFBNLCBSb2JlcnQg UmFzenVrIHdyb3RlOg0KSGkgSmFrb2IsDQoNClR3byBmbG93c3BlYyByb3V0ZXMgd2l0aCB0aGUg c2FtZSBOTFJJIG1heSBiZSBvcmlnaW5hdGVkIGJ5IGRpZmZlcmVudCBzcGVha2Vycy4NCg0KR3Jv dXAtaWQgKHNjb3BlZCBhcHBsaWNhdGlvbiBvZiBzcGVjaWZpYyBmbG93LXNwZWMgcnVsZXMpIGlz IGFkZHJlc3NpbmcgYSBzcGVjaWFsIGNhc2Ugd2hlcmUgaXQgaXMgZ2VuZXJhdGVkIGNhcmVmdWxs eSBieSBlaXRoZXIgY29udHJvbGxlciBvciBwcm92aXNpb25pbmcgdG9vbHMuIEkgZG8gbm90IHNl ZSB0aGVyZWZvciBhIHByYWN0aWNhbCBjYXNlIHdoZXJlIHRoZSBzYW1lIHN1Y2ggcnVsZSB3b3Vs ZCBiZSBjb21pbmcgZnJvbSB0d28gb3IgbW9yZSBpbmRlcGVuZGVudCBzb3VyY2VzIGFuZCB3b3Vs ZCBiZSBhcHBsaWNhYmxlIOKAi3RvIGRpZmZlcmVudCBpbnRlcmZhY2UgZ3JvdXBzLg0KDQpJdCBz b3VuZHMgbW9yZSBsaWtlIGEgcHJvdG9jb2wgY29uZmxpY3Qgb3IgcHJvdmlzaW9uaW5nIGJ1ZyBh bmQgbm90IHNvbWV0aGluZyB3ZSBzaG91bGQgd29ycnkgYWJvdXQgaG93IHRvIGNhcnJ5IGl0IGFj cm9zcyBSUnMuIFN0YW5kYXJkIHByb3RvY29sIGJlaGF2aW9yIHdvdWxkIGJlIGZpbmUgaGVyZS4N Cg0KTm93IGFsc28gbm90aWNlIHdoYXQgd291bGQgcmVjZWl2ZXIgZG8gLi4uIHRyZWF0IHRoZSBz dWJzZXF1ZW50IHVwZGF0ZSB3aXRoIHRoZSBleGFjdGx5IHNhbWUgTkxSSSBhcyBpbXBsaWNpdCB3 aXRoZHJhdyBvciBydW4gYmVzdCBwYXRoIGlmIHRoZXkgY29tZSBmcm9tIGRpZmZlcmVudCBwZWVy cyBhbmQgc3RpbGwgYXBwbHkgc2luZ2xlIG9uZSB0byBsb2NhbCBkYXRhIHBsYW5lLiBTbyByZWFs bHkgdGhlcmUgaXMgbm8gcG9pbnQgdG8gZ2l2ZSBpdCBib3RoIHN1Y2ggcGF0aHMgd2l0aCBBREQt UEFUSHMuIEFzIGl0IGlzIG9uIGZpbmFsIHJlY2VpdmVycyB0aGUgc2FtZSBzaG91bGQgYmUgZG9u ZSBvbiBSUnMgLi4uDQoNCuKAi0NoZWVycywNCi8vUlIu4oCLDQoNCg0KVGhlIGZpcnN0IHJvdXRl IHdpbGwgaGF2ZSBvbmUgZ3JvdXAtaWQuIFRoZSBzZWNvbmQgcm91dGUgd2lsbCBoYXZlIGFub3Ro ZXIgZ3JvdXAtaWQuDQoNClRoYW5rcywNCkpha29iLg0KDQpGcm9tOiBJZHIgW21haWx0bzppZHIt Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYg T2YgUm9iZXJ0IFJhc3p1aw0KU2VudDogV2VkbmVzZGF5LCBKdWx5IDI2LCAyMDE3IDQ6MzggUE0N ClRvOiBKdWFuIEFsY2FpZGUgKGphbGNhaWRlKSA8amFsY2FpZGVAY2lzY28uY29tPG1haWx0bzpq YWxjYWlkZUBjaXNjby5jb20+Pg0KQ2M6IGlkciB3ZyA8aWRyQGlldGYub3JnPG1haWx0bzppZHJA aWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtJZHJdIGRyYWZ0LWxpdGtvd3NraS1pZHItZmxvd3Nw ZWMtaW50ZXJmYWNlc2V0ID0+IE5MUkkgdnMgRVhUQ1QgKHBhcnQgMikNCg0KSGkgSnVhbiwNCg0K PiAgKHdlIGFzc3VtZSBjb250cm9sbGVyKHMpIG1heSBub3Qgd2FudCB0byBzZW5kIG11bHRpcGxl IGV4dC1jb21tdW5pdGllcyB3aXRoIHNhbWUgTkxSSSkuDQoNCklmIEkgcmVjYWxsIGdyb3VwLWlk cyBhcmUgY2FycmllZCBpbiBuZXcgUlQgZm9ybWF0Og0KDQoiVGhpcyBuZXcgQkdQIFJvdXRlIFRh cmdldCBleHRlbmRlZCBjb21tdW5pdHkgaXMgZW5jb2RlZCBhcyBmb2xsb3dzIDoNCg0KICAgICAg IDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAg ICAgIDMNCiAgICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAx IDIgMyA0IDUgNiA3IDggOSAwIDENCiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgICB8ICBUeXBlIChUQkQp ICAgfCAgICAgIDB4MDIgICAgIHwgICAgQXV0b25vbW91cyBTeXN0ZW0gTnVtYmVyICAgOg0KICAg ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSsNCiAgICAgIDogICAgIEFTIE51bWJlciAoY29udC4pICAgICAgICAgfE98SXwg ICAgICBHcm91cCBJZGVudGlmaWVyICAgICB8DQogICAgICArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KIg0KDQpTbyBqdXN0 IGxpa2UgYW4gVVBEQVRFIG1lc3NhZ2Ugb2YgU0FGSSAxMjggbWF5IGNvbnRhaW4gbWFueSBSVHMg d2h5IHdvdWxkIHlvdSBzZWUgYW55DQppc3N1ZSB0byBjYXJyeSBtdWx0aXBsZSBleHQgY29tbXVu aXRpZXMgb2YgdGhlIGFib3ZlIGZvcm1hdCBoZXJlID8NCg0KQmVzdCwNClIuDQoNCk9uIFRodSwg SnVsIDI3LCAyMDE3IGF0IDE6MDEgQU0sIEp1YW4gQWxjYWlkZSAoamFsY2FpZGUpIDxqYWxjYWlk ZUBjaXNjby5jb208bWFpbHRvOmphbGNhaWRlQGNpc2NvLmNvbT4+IHdyb3RlOg0KDQpIaSwNCg0K RnJvbSBhIHByZXZpb3VzIHRocmVhZCwgSSBzZWUgZnJvbSB0aGUgdGhhdCB1c2luZyBFWFRDT01N IHRvIGNhcnJ5IGdyb3VwLWlkIGluZm9ybWF0aW9uIHRoZSBjaG9pY2UuIFJlYXNvbiB3YXMgdGhh dCBldmVyeSBBUyBjb3VsZCB1c2UgdGhlaXIgb3duIHRoZSBncm91cC1pZCAocGVyaGFwcyBkaWZm ZXJlbnQgdGhhbiBhbm90aGVyIEFTKS4gV2l0aCB0aGlzIGNob2ljZSwgQURELVBBVEhTIG11c3Qg YmUgbWFuZGF0b3J5IGluIG9yZGVyIHRvIHN1cHBvcnQgbXVsdGlwbGUgZ3JvdXAtaWRzIGZvciB0 aGUgc2FtZSBmbG93c3BlYyBydWxlICAod2UgYXNzdW1lIGNvbnRyb2xsZXIocykgbWF5IG5vdCB3 YW50IHRvIHNlbmQgbXVsdGlwbGUgZXh0LWNvbW11bml0aWVzIHdpdGggc2FtZSBOTFJJKS4NCg0K QnV0IHRoZSBkcmFmdCByZWFsbHkgZG9lcyBub3QgZGVzY3JpYmUgaG93IHRvIHVzZSBBREQtUEFU SFMsIGFuZCBpdCBkb2VzIG5vdCBkaXNjdXNzIGl0cyBwcm9ibGVtczoNCg0KLSBVc3VhbGx5LCBB REQtUEFUSFMgaXMgdXNlZCBmb3IgcGF0aCBkaXZlcnNpdHksIGFuZCBpbXBsZW1lbnRhdGlvbnMg dHlwaWNhbGx5IGRvbid0IGFkdmVydGlzZSAyIHBhdGhzIHdpdGggdGhlIHNhbWUgbmV4dC1ob3Ag KG90aGVyd2lzZSwgd2UgY291bGQgaGF2ZSBwYXRoIGV4cGxvc2lvbiBhY3Jvc3MgbXVsdGlwbGUg bGV2ZWxzIG9mIFJScykNCg0KLSBJZiBBREQtUEFUSFMgaGFzIHRvIGFkdmVydGlzZSB0aGUgc2Ft ZSBOTFJJIHdpdGggZGlmZmVyZW50IGV4dC1jb21tdW5pdGllcywgb25lIHNvbHV0aW9uIHdvdWxk IGJlIGZvciBBREQtUEFIVFMgbm90IGFkdmVydGlzZSB0aGUgc2FtZSBzZXQgb2YgZXh0LWNvbW11 bml0aWVzLiBVbmxlc3MsIEkgZ3Vlc3MsIG5leHQtaG9wcyBhcmUgZGlmZmVyZW50LiBPdGhlcndp c2UsIHdlIHdvdWxkIGhhdmUgcGF0aCBleHBsb3Npb24uDQoNCi0gQXNzdW1pbmcgdGhlIGFib3Zl LCB3ZSBzaG91bGQgZGVmaW5lIGEgcGFydGljdWxhciBzZXQgb2YgQURELVBBVEhTIHJ1bGVzIGZv ciBmbG93c3BlYyBBRi4gQW5kLCBvZiBjb3Vyc2UsIGxlYXZlIHRoZSBkb29yIG9wZW4gZm9yIGZ1 dHVyZSBzcGVjaWZpYyBBREQtUEFUSHMgcnVsZXMgZm9yIG90aGVyIEFGcyAoaXQgd291bGQgbm90 IGJlIGFib3V0IHBhdGggZGl2ZXJzaXR5IGFueW1vcmUsIGJ1dCBhYm91dCBwcm9wYWdhdGluZyBk aWZmZXJlbnQgaW5mb3JtYXRpb24gZm9yIGZvcndhcmRpbmcgcHVycG9zZXMgLWltYWdpbmUgd2hh dCB3ZSBjb3VsZCBoYXZlIGRvbmUgd2l0aCBhbiBJUHY0IHByZWZpeDogc2VuZCB0aGUgc2FtZSBu ZXQgcGFydCBhcyBhIE5MUkkgYW5kIG11bHRpcGxlIGV4dC1jb21tdW5pdGllcyByZXByZXNlbnRp bmcgZGlmZmVyZW50IHByZWZpeC1sZW5ndGhzIC0pLg0KDQotIFNpbmNlIHBhdGhzIGluIGEgbmV0 IGFyZSB0eXBpY2FsbHkgaW1wbGVtZW50ZWQgYXMgYSBsaXN0LCB0aGVyZSBjb3VsZCBiZSBzY2Fs YWJpbGl0eSBwcm9ibGVtcyBpZiB3ZSBldmVyIHdhbnQgdG8gc3VwcG9ydCBtYW55IGdyb3VwLWlk cy4NCg0KTXkgc29sdXRpb24gdG8gc2ltcGxpZnkgYWxsIHRoZXNlIHByb2JsZW1zIHdvdWxkIGJl IHRvIGFkZCBhIGRpc2NyaW1pbmF0b3Igb24gdGhlIE5MUkkgKGJ5IGRlZmluaW5nIGEgbmV3IGR1 bW15IHR5cGUgZm9yIGZsb3dzcGVjKS4gV2UgY291bGQgc3RpbGwgdXNlIGV4dC1jb21tdW5pdGll cyB0byBhY3R1YWxseSBtYXRjaCB0aGUgTkxSSXMgdG8gaW50ZXJmYWNlcy4gU2ltaWxhciB0byBS RCBhbmQgUlQgdXNhZ2UuDQoNClRob3VnaHRzPw0KDQotSg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWRyIG1haWxpbmcgbGlzdA0KSWRyQGlldGYu b3JnPG1haWx0bzpJZHJAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2lkcg0KDQoNCg0KDQo= --_000_db34ca243ca94b3d9dd60038dcc4b7aeXCHALN014ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJMdWNpZGEgQ29uc29s ZSI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNCA1IDQgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseToiXEBTaW1TdW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ291cmllciBOZXcgXDtjb2xvclw6XCM3MDMwQTAiO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ikx1Y2lkYSBDb25zb2xlIFw7Y29sb3JcOlwjNzAz MEEwIjt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlm Ow0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1h cmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxl ZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBk aXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWlsU3R5 bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciLHNlcmlmOw0KCWNvbG9yOiM3MDMwQTA7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0K CWZvbnQtc3R5bGU6bm9ybWFsOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZjtjb2xvcjojNzAzMEEwIj5KdWFuLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlm O2NvbG9yOiM3MDMwQTAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMwQTAiPmp1c3QgdG8geW91LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2Nv bG9yOiM3MDMwQTAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMwQTAiPkl0IGNhbiBzZW5kIG9uZSByb3V0 ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oyxz ZXJpZjtjb2xvcjojNzAzMEEwIj5OTFJJMSAmIzQzOyBncm91cC1pZCAxICYjNDM7IGdyb3VwLWlk IDI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oyxz ZXJpZjtjb2xvcjojNzAzMEEwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZjtjb2xvcjojNzAzMEEwIj5UaGUgYXJndW1lbnQg dGhhdCB0aGVyZSBtYXkgYmUgdG9vIG1hbnkgZ3JvdXAtaWRzIHRvIGZpdCBpbnRvIGEgQkdQIHVw ZGF0ZSBtZXNzYWdlIGlzIHRvbyB3ZWFrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMwQTAiPllvdSB3b3VsZCBoYXZl IHRvIGRlbW9uc3RyYXRlIGEgY2FzZSB0aGF0IGFjdHVhbGx5IGhhcHBlbmVkIGFuZCBub3QganVz dCBoeXBvdGhldGljYWwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6IzcwMzBBMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7THVjaWRhIENvbnNvbGUmcXVvdDs7Y29sb3I6IzcwMzBB MCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7THVjaWRhIENvbnNv bGUmcXVvdDs7Y29sb3I6IzcwMzBBMCI+SmFrb2IuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZjtjb2xvcjojNzAzMEEwIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPiBKdWFuIEFsY2FpZGUgKGphbGNhaWRlKQ0KPGJyPg0K PGI+U2VudDo8L2I+IFRodXJzZGF5LCBKdWx5IDI3LCAyMDE3IDI6MzcgUE08YnI+DQo8Yj5Ubzo8 L2I+IFJvYmVydCBSYXN6dWsgJmx0O3JvYmVydEByYXN6dWsubmV0Jmd0OzsgSmFrb2IgSGVpdHog KGpoZWl0eikgJmx0O2poZWl0ekBjaXNjby5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBpZHIgd2cg Jmx0O2lkckBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJZHJdIGRyYWZ0 LWxpdGtvd3NraS1pZHItZmxvd3NwZWMtaW50ZXJmYWNlc2V0ID0mZ3Q7IE5MUkkgdnMgRVhUQ1Qg KHBhcnQgMik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Um9iZXJ0LDxicj4NCjxicj4NCldlIG1heSBzdXBwb3J0IG9yIG5vdCBzdXBwb3J0IHVu c3luY2hyb25pemVkIGNvbnRyb2xsZXJzPGJyPg0KQnV0IGxldCdzIGFzc3VtZSBmb3IgYSBzZWNv bmQgd2UgYXJlIGp1c3QgdXNpbmcgb25lIGNvbnRyb2xsZXI8YnI+DQpidXQgY2FuIGEgc2luZ2xl IGNvbnRyb2xsZXIgc2VuZGluZzxicj4NCjxicj4NCk5MUkkxICYjNDM7IGdyb3VwLWlkIDE8YnI+ DQpOTFJJMSAmIzQzOyBncm91cC1pZCAyPGJyPg0KPGJyPg0KVGhlIFJSIHJlY2VpdmVzIGJvdGgg dGhpcyByb3V0ZXMgKG11c3QgYmUgQURELVBBVEhTLCBhcyBtZW50aW9uZWQgaW4gdGhlIGRyYWZ0 KS4gVGhlIFJSIG5lZWRzIHRvIHVzZSBBREQtUEFUSFMgaXRzZWxmIHRvIHNlbmQgaXQgdG8gdGhl IFBFIChmaW5hbCByZWNlaXZlcik8YnI+DQo8YnI+DQotSjxicj4NCjxicj4NCjxicj4NCjxicj4N Ck9uIDcvMjcvMjAxNyA5OjQ0IFBNLCBSb2JlcnQgUmFzenVrIHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkhpIEpha29iLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgXDtjb2xvclw6XCM3MDMwQTAmcXVvdDsiPlR3byBm bG93c3BlYyByb3V0ZXMgd2l0aCB0aGUgc2FtZSBOTFJJIG1heSBiZSBvcmlnaW5hdGVkIGJ5IGRp ZmZlcmVudCBzcGVha2Vycy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5Hcm91cC1p ZCAoc2NvcGVkIGFwcGxpY2F0aW9uIG9mIHNwZWNpZmljIGZsb3ctc3BlYyBydWxlcykgaXMgYWRk cmVzc2luZyBhIHNwZWNpYWwgY2FzZSB3aGVyZSBpdCBpcyBnZW5lcmF0ZWQgY2FyZWZ1bGx5IGJ5 IGVpdGhlciBjb250cm9sbGVyIG9yIHByb3Zpc2lvbmluZyB0b29scy4gSSBkbyBub3Qgc2VlIHRo ZXJlZm9yIGEgcHJhY3RpY2FsDQogY2FzZSB3aGVyZSB0aGUgc2FtZSBzdWNoIHJ1bGUgd291bGQg YmUgY29taW5nIGZyb20gdHdvIG9yIG1vcmUgaW5kZXBlbmRlbnQgc291cmNlcyBhbmQgd291bGQg YmUgYXBwbGljYWJsZSDigIt0byBkaWZmZXJlbnQgaW50ZXJmYWNlIGdyb3Vwcy4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWYiPkl0IHNvdW5kcyBtb3JlIGxpa2UgYSBwcm90b2NvbCBjb25mbGljdCBvciBwcm92aXNpb25p bmcgYnVnIGFuZCBub3Qgc29tZXRoaW5nIHdlIHNob3VsZCB3b3JyeSBhYm91dCBob3cgdG8gY2Fy cnkgaXQgYWNyb3NzIFJScy4gU3RhbmRhcmQgcHJvdG9jb2wgYmVoYXZpb3Igd291bGQgYmUgZmlu ZSBoZXJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZiI+Tm93IGFsc28gbm90aWNlIHdoYXQgd291bGQgcmVjZWl2ZXIgZG8gLi4u IHRyZWF0IHRoZSBzdWJzZXF1ZW50IHVwZGF0ZSB3aXRoIHRoZSBleGFjdGx5IHNhbWUgTkxSSSBh cyBpbXBsaWNpdCB3aXRoZHJhdyBvciBydW4gYmVzdCBwYXRoIGlmIHRoZXkgY29tZSBmcm9tIGRp ZmZlcmVudCBwZWVycyBhbmQgc3RpbGwgYXBwbHkgc2luZ2xlDQogb25lIHRvIGxvY2FsIGRhdGEg cGxhbmUuIFNvIHJlYWxseSB0aGVyZSBpcyBubyBwb2ludCB0byBnaXZlIGl0IGJvdGggc3VjaCBw YXRocyB3aXRoIEFERC1QQVRIcy4gQXMgaXQgaXMgb24gZmluYWwgcmVjZWl2ZXJzIHRoZSBzYW1l IHNob3VsZCBiZSBkb25lIG9uIFJScyAuLi4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj7igItDaGVlcnMsPGJyPg0KLy9SUi7i gIs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgXDtjb2xvclw6XCM3MDMw QTAmcXVvdDsiPlRoZSBmaXJzdCByb3V0ZSB3aWxsIGhhdmUgb25lIGdyb3VwLWlkLiBUaGUgc2Vj b25kIHJvdXRlIHdpbGwgaGF2ZSBhbm90aGVyIGdyb3VwLWlkLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgXDtjb2xvclw6XCM3MDMwQTAmcXVvdDsiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtMdWNpZGEgQ29uc29sZSBc O2NvbG9yXDpcIzcwMzBBMCZxdW90OyI+VGhhbmtzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZh bWlseTomcXVvdDtMdWNpZGEgQ29uc29sZSBcO2NvbG9yXDpcIzcwMzBBMCZxdW90OyI+SmFrb2Iu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyBcO2NvbG9y XDpcIzcwMzBBMCZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+IElkciBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzppZHItYm91bmNlc0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlkci1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJl aGFsZiBPZiA8L2I+Um9iZXJ0IFJhc3p1azxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEp1 bHkgMjYsIDIwMTcgNDozOCBQTTxicj4NCjxiPlRvOjwvYj4gSnVhbiBBbGNhaWRlIChqYWxjYWlk ZSkgJmx0OzxhIGhyZWY9Im1haWx0bzpqYWxjYWlkZUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5r Ij5qYWxjYWlkZUBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gaWRyIHdnICZsdDs8 YSBocmVmPSJtYWlsdG86aWRyQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aWRyQGlldGYub3Jn PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJZHJdIGRyYWZ0LWxpdGtvd3NraS1p ZHItZmxvd3NwZWMtaW50ZXJmYWNlc2V0ID0mZ3Q7IE5MUkkgdnMgRVhUQ1QgKHBhcnQgMik8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmIj5IaSBKdWFuLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmbmJzcDsmbmJzcDsod2Ug YXNzdW1lIGNvbnRyb2xsZXIocykgbWF5IG5vdCB3YW50IHRvIHNlbmQgbXVsdGlwbGUgZXh0LWNv bW11bml0aWVzIHdpdGggc2FtZSBOTFJJKS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5JZiBJIHJlY2FsbCBncm91cC1p ZHMgYXJlIGNhcnJpZWQgaW4gbmV3IFJUIGZvcm1hdDombmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mcXVvdDtU aGlzIG5ldyBCR1AgUm91dGUgVGFyZ2V0IGV4dGVuZGVkIGNvbW11bml0eSBpcyBlbmNvZGVkIGFz IGZvbGxvd3MgOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzAgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgMSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAyICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IDM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7MCAxIDIg MyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAx PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2Vy aWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZu YnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7VHlwZSAoVEJEKSAmbmJzcDsgfCAmbmJzcDsgJm5i c3A7ICZuYnNwOzB4MDIgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDtBdXRvbm9tb3VzIFN5 c3RlbSBOdW1iZXIgJm5ic3A7IDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0Mzs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgOiAmbmJzcDsgJm5ic3A7IEFT IE51bWJlciAoY29udC4pICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8T3xJfCAmbmJzcDsg Jm5ic3A7ICZuYnNwO0dyb3VwIElkZW50aWZpZXIgJm5ic3A7ICZuYnNwOyB8PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZuYnNwOyAm bmJzcDsgJm5ic3A7ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZxdW90Ozwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp ZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZiI+U28ganVzdCBsaWtlIGFuIFVQREFURSBtZXNzYWdlIG9mIFNBRkkgMTI4IG1h eSBjb250YWluIG1hbnkgUlRzIHdoeSB3b3VsZCB5b3Ugc2VlIGFueSZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPmlzc3VlIHRv IGNhcnJ5IG11bHRpcGxlIGV4dCBjb21tdW5pdGllcyBvZiB0aGUgYWJvdmUgZm9ybWF0IGhlcmUg PyZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWYiPkJlc3QsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Ui48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBUaHUsIEp1bCAyNywgMjAx NyBhdCAxOjAxIEFNLCBKdWFuIEFsY2FpZGUgKGphbGNhaWRlKSAmbHQ7PGEgaHJlZj0ibWFpbHRv OmphbGNhaWRlQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmphbGNhaWRlQGNpc2NvLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQiPkhpLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0Ij5Gcm9tIGEgcHJldmlvdXMgdGhyZWFkLCBJIHNlZSBmcm9tIHRoZSB0aGF0IHVz aW5nIEVYVENPTU0gdG8gY2FycnkgZ3JvdXAtaWQgaW5mb3JtYXRpb24gdGhlIGNob2ljZS4gUmVh c29uIHdhcyB0aGF0IGV2ZXJ5IEFTIGNvdWxkIHVzZSB0aGVpciBvd24gdGhlIGdyb3VwLWlkIChw ZXJoYXBzIGRpZmZlcmVudCB0aGFuIGFub3RoZXIgQVMpLiBXaXRoIHRoaXMgY2hvaWNlLCBBREQt UEFUSFMNCiBtdXN0IGJlIG1hbmRhdG9yeSBpbiBvcmRlciB0byBzdXBwb3J0IG11bHRpcGxlIGdy b3VwLWlkcyBmb3IgdGhlIHNhbWUgZmxvd3NwZWMgcnVsZSZuYnNwOyAod2UgYXNzdW1lIGNvbnRy b2xsZXIocykgbWF5IG5vdCB3YW50IHRvIHNlbmQgbXVsdGlwbGUgZXh0LWNvbW11bml0aWVzIHdp dGggc2FtZSBOTFJJKS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdCI+QnV0IHRoZSBkcmFmdCByZWFsbHkgZG9lcyBub3QgZGVzY3JpYmUgaG93 IHRvIHVzZSBBREQtUEFUSFMsIGFuZCBpdCBkb2VzIG5vdCBkaXNjdXNzIGl0cyBwcm9ibGVtczo8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+ LSBVc3VhbGx5LCBBREQtUEFUSFMgaXMgdXNlZCBmb3IgcGF0aCBkaXZlcnNpdHksIGFuZCBpbXBs ZW1lbnRhdGlvbnMgdHlwaWNhbGx5IGRvbid0IGFkdmVydGlzZSAyIHBhdGhzIHdpdGggdGhlIHNh bWUgbmV4dC1ob3AgKG90aGVyd2lzZSwgd2UgY291bGQgaGF2ZSBwYXRoIGV4cGxvc2lvbiBhY3Jv c3MgbXVsdGlwbGUgbGV2ZWxzIG9mIFJScyk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+LSBJZiBBREQtUEFUSFMgaGFzIHRvIGFkdmVydGlz ZSB0aGUgc2FtZSBOTFJJIHdpdGggZGlmZmVyZW50IGV4dC1jb21tdW5pdGllcywgb25lIHNvbHV0 aW9uIHdvdWxkIGJlIGZvciBBREQtUEFIVFMgbm90IGFkdmVydGlzZSB0aGUgc2FtZSBzZXQgb2Yg ZXh0LWNvbW11bml0aWVzLiBVbmxlc3MsIEkgZ3Vlc3MsIG5leHQtaG9wcyBhcmUgZGlmZmVyZW50 LiBPdGhlcndpc2UsIHdlIHdvdWxkDQogaGF2ZSBwYXRoIGV4cGxvc2lvbi48L3NwYW4+PG86cD48 L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+LSBBc3N1bWluZyB0 aGUgYWJvdmUsIHdlIHNob3VsZCBkZWZpbmUgYSBwYXJ0aWN1bGFyIHNldCBvZiBBREQtUEFUSFMg cnVsZXMgZm9yIGZsb3dzcGVjIEFGLiBBbmQsIG9mIGNvdXJzZSwgbGVhdmUgdGhlIGRvb3Igb3Bl biBmb3IgZnV0dXJlIHNwZWNpZmljIEFERC1QQVRIcyBydWxlcyBmb3Igb3RoZXIgQUZzIChpdCB3 b3VsZCBub3QgYmUgYWJvdXQgcGF0aCBkaXZlcnNpdHkgYW55bW9yZSwNCiBidXQgYWJvdXQgcHJv cGFnYXRpbmcgZGlmZmVyZW50IGluZm9ybWF0aW9uIGZvciBmb3J3YXJkaW5nIHB1cnBvc2VzIC1p bWFnaW5lIHdoYXQgd2UgY291bGQgaGF2ZSBkb25lIHdpdGggYW4gSVB2NCBwcmVmaXg6IHNlbmQg dGhlIHNhbWUgbmV0IHBhcnQgYXMgYSBOTFJJIGFuZCBtdWx0aXBsZSBleHQtY29tbXVuaXRpZXMg cmVwcmVzZW50aW5nIGRpZmZlcmVudCBwcmVmaXgtbGVuZ3RocyAtKS48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+LSBTaW5jZSBwYXRocyBp biBhIG5ldCBhcmUgdHlwaWNhbGx5IGltcGxlbWVudGVkIGFzIGEgbGlzdCwgdGhlcmUgY291bGQg YmUgc2NhbGFiaWxpdHkgcHJvYmxlbXMgaWYgd2UgZXZlciB3YW50IHRvIHN1cHBvcnQgbWFueSBn cm91cC1pZHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQiPk15IHNvbHV0aW9uIHRvIHNpbXBsaWZ5IGFsbCB0aGVzZSBwcm9ibGVtcyB3b3Vs ZCBiZSB0byBhZGQgYSBkaXNjcmltaW5hdG9yIG9uIHRoZSBOTFJJIChieSBkZWZpbmluZyBhIG5l dyBkdW1teSB0eXBlIGZvciBmbG93c3BlYykuIFdlIGNvdWxkIHN0aWxsIHVzZSBleHQtY29tbXVu aXRpZXMgdG8gYWN0dWFsbHkgbWF0Y2ggdGhlIE5MUklzIHRvIGludGVyZmFjZXMuIFNpbWlsYXIg dG8gUkQNCiBhbmQgUlQgdXNhZ2UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQiPlRob3VnaHRzPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOiM4ODg4ODgiPi1KPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KSWRyIG1haWxpbmcgbGlz dDxicj4NCjxhIGhyZWY9Im1haWx0bzpJZHJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5JZHJA aWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9pZHIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2lkcjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHA+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_db34ca243ca94b3d9dd60038dcc4b7aeXCHALN014ciscocom_-- From nobody Fri Jul 28 04:20:42 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8801322CF for ; Fri, 28 Jul 2017 04:20:40 -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 2MNjJ_ih-Nl1 for ; Fri, 28 Jul 2017 04:20:36 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE3DC1322C9 for ; Fri, 28 Jul 2017 04:20:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=42297; q=dns/txt; s=iport; t=1501240836; x=1502450436; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=CcQOzkz+3PU0AlGqXaiueenRRAHlhR0uXARBLVVED6o=; b=cPHlzdzWsy+K3gkpxKlu9x8qO5eMlxOJqmOvdhH1SUYqiAc5z19/sUyl i9BqQIHNGUhbkmDvt+P/Zd6iW1YYx3hwoD6ILj8xgobRh4RCFdgF/owUR Su85gRVzRqiH130eBfMqZontRIBCuVnAE9VXAjFrXgBQx+97B6x30V3RC 4=; X-IronPort-AV: E=Sophos;i="5.40,425,1496102400"; d="scan'208,217";a="462661822" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jul 2017 11:20:35 +0000 Received: from [10.82.221.134] (rtp-vpn3-1408.cisco.com [10.82.221.134]) (authenticated bits=0) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v6SBKXpN004459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 28 Jul 2017 11:20:34 GMT To: Robert Raszuk Cc: "Jakob Heitz (jheitz)" , idr wg References: <9fa67eb0-8f99-a46f-aff1-d42a279ab833@cisco.com> <8dd3e766b58944a3b176fc743e478137@XCH-ALN-014.cisco.com> From: "Juan Alcaide (jalcaide)" Message-ID: Date: Fri, 28 Jul 2017 13:20:32 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D383C413C4535072AC5B5AD6" Content-Language: en-US X-Authenticated-User: jalcaide Archived-At: Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT (part 2) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 11:20:40 -0000 This is a multi-part message in MIME format. --------------D383C413C4535072AC5B5AD6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Robert, (group-id: what to you specify in ext-community; interface-group: what you specify under interface configuration) If you use ADD-PATHS, you can send identical NLRIs and you consider them as valid (no implicit withdraw) There is a requirement that the same flowspec rule, could be used for 2 different interface-groups (let's say interfaces customer-facing and interfaces provider-facing). But also you may want to use different actions based on the group-id (section 8 of the draft) I think we basically need to expand/clarify the ADD-PATHS part. Regarding your points: 1. For a given NLRI, we change group-ids or actions based on what we want to achieve. So it's based on how customer sets the rule in the controller. There may be a need to send same NLRI with 2 different sets of action+group-id 2. If receiver receives more than one group-id, it should apply all the actions specified to *all* the interface-group associated to all the group-ids it received. Draft does explicitly say what to do when you receive a NLRI with multiple group-ids, but I think it should be applied to all interface-groups (probably it should be clarified) -J On 7/27/2017 11:43 PM, Robert Raszuk wrote: > Juan, > > Sending from single controller (single BGP peer) two updates with > identical NLRIs is an implicit withdraw. ADD-PATHs has nothing to here. > > Likewise RR should treat is as implicit withdraw of the previous one too. > > If you go by your line of thinking what would make controller to > change for given NLRI1 group-id 1 to group-id 2 if there is need to do > so ? > > In any case if you decide to add additional text to the current draft > or decide to write new draft to address this please do make sure to > clearly define two things: > > 1. How for a given NLRI we change either actions or group-ids > > 2. What should receiver do when for a given NLRI he received more then > one group-id or more then one set of actions ? > > Thanks, > R. > > > > > > On Thu, Jul 27, 2017 at 11:37 PM, Juan Alcaide (jalcaide) > > wrote: > > Robert, > > We may support or not support unsynchronized controllers > But let's assume for a second we are just using one controller > but can a single controller sending > > NLRI1 + group-id 1 > NLRI1 + group-id 2 > > The RR receives both this routes (must be ADD-PATHS, as mentioned > in the draft). The RR needs to use ADD-PATHS itself to send it to > the PE (final receiver) > > -J > > > > > On 7/27/2017 9:44 PM, Robert Raszuk wrote: >> Hi Jakob, >> >> Two flowspec routes with the same NLRI may be originated by >> different speakers. >> >> >> Group-id (scoped application of specific flow-spec rules) is >> addressing a special case where it is generated carefully by >> either controller or provisioning tools. I do not see therefor a >> practical case where the same such rule would be coming from two >> or more independent sources and would be applicable ​to different >> interface groups. >> >> It sounds more like a protocol conflict or provisioning bug and >> not something we should worry about how to carry it across RRs. >> Standard protocol behavior would be fine here. >> >> Now also notice what would receiver do ... treat the subsequent >> update with the exactly same NLRI as implicit withdraw or run >> best path if they come from different peers and still apply >> single one to local data plane. So really there is no point to >> give it both such paths with ADD-PATHs. As it is on final >> receivers the same should be done on RRs ... >> >> ​Cheers, >> //RR.​ >> >> The first route will have one group-id. The second route will >> have another group-id. >> >> Thanks, >> >> Jakob. >> >> *From:*Idr [mailto:idr-bounces@ietf.org >> ] *On Behalf Of *Robert Raszuk >> *Sent:* Wednesday, July 26, 2017 4:38 PM >> *To:* Juan Alcaide (jalcaide) > > >> *Cc:* idr wg > >> *Subject:* Re: [Idr] >> draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT >> (part 2) >> >> Hi Juan, >> >> > (we assume controller(s) may not want to send multiple >> ext-communities with same NLRI). >> >> If I recall group-ids are carried in new RT format: >> >> "This new BGP Route Target extended community is encoded as >> follows : >> >> 0 1 2 3 >> >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 >> 8 9 0 1 >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> | Type (TBD) | 0x02 | Autonomous System Number : >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> : AS Number (cont.) |O|I| Group Identifier | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> " >> >> So just like an UPDATE message of SAFI 128 may contain many >> RTs why would you see any >> >> issue to carry multiple ext communities of the above format >> here ? >> >> Best, >> >> R. >> >> On Thu, Jul 27, 2017 at 1:01 AM, Juan Alcaide (jalcaide) >> > wrote: >> >> Hi, >> >> From a previous thread, I see from the that using EXTCOMM >> to carry group-id information the choice. Reason was that >> every AS could use their own the group-id (perhaps >> different than another AS). With this choice, ADD-PATHS >> must be mandatory in order to support multiple group-ids >> for the same flowspec rule (we assume controller(s) may >> not want to send multiple ext-communities with same NLRI). >> >> But the draft really does not describe how to use >> ADD-PATHS, and it does not discuss its problems: >> >> - Usually, ADD-PATHS is used for path diversity, and >> implementations typically don't advertise 2 paths with >> the same next-hop (otherwise, we could have path >> explosion across multiple levels of RRs) >> >> - If ADD-PATHS has to advertise the same NLRI with >> different ext-communities, one solution would be for >> ADD-PAHTS not advertise the same set of ext-communities. >> Unless, I guess, next-hops are different. Otherwise, we >> would have path explosion. >> >> - Assuming the above, we should define a particular set >> of ADD-PATHS rules for flowspec AF. And, of course, leave >> the door open for future specific ADD-PATHs rules for >> other AFs (it would not be about path diversity anymore, >> but about propagating different information for >> forwarding purposes -imagine what we could have done with >> an IPv4 prefix: send the same net part as a NLRI and >> multiple ext-communities representing different >> prefix-lengths -). >> >> - Since paths in a net are typically implemented as a >> list, there could be scalability problems if we ever want >> to support many group-ids. >> >> My solution to simplify all these problems would be to >> add a discriminator on the NLRI (by defining a new dummy >> type for flowspec). We could still use ext-communities to >> actually match the NLRIs to interfaces. Similar to RD and >> RT usage. >> >> Thoughts? >> >> -J >> >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> >> >> > > --------------D383C413C4535072AC5B5AD6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Robert,

(group-id: what to you specify in ext-community; interface-group: what you specify under interface configuration)

If you use ADD-PATHS, you can send identical NLRIs and you consider them as valid (no implicit withdraw)
There is a requirement that the same flowspec rule, could be used for 2 different interface-groups (let's say interfaces customer-facing and interfaces provider-facing). But also you may want to use different actions based on the group-id (section 8 of the draft)

I think we basically need to expand/clarify the ADD-PATHS part. Regarding your points:
1. For a given NLRI, we change group-ids or actions based on what we want to achieve. So it's based on how customer sets the rule in the controller. There may be a need to send same NLRI with 2 different sets of action+group-id
2. If receiver receives more than one group-id, it should apply all the actions specified to *all* the interface-group associated to all the group-ids it received. Draft does explicitly say what to do when you receive a NLRI with multiple group-ids, but I think it should be applied to all interface-groups (probably it should be clarified)

-J



On 7/27/2017 11:43 PM, Robert Raszuk wrote:
Juan,

Sending from single controller (single BGP peer) two updates with identical NLRIs is an implicit withdraw. ADD-PATHs has nothing to here. 

Likewise RR should treat is as implicit withdraw of the previous one too. 

If you go by your line of thinking what would make controller to change for given NLRI1 group-id 1 to group-id 2 if there is need to do so ? 

In any case if you decide to add additional text to the current draft or decide to write new draft to address this please do make sure to clearly define two things:

1. How for a given NLRI we change either actions or group-ids 

2. What should receiver do when for a given NLRI he received more then one group-id or more then one set of actions ? 

Thanks,
R.





On Thu, Jul 27, 2017 at 11:37 PM, Juan Alcaide (jalcaide) <jalcaide@cisco.com> wrote:
Robert,

We may support or not support unsynchronized controllers
But let's assume for a second we are just using one controller
but can a single controller sending

NLRI1 + group-id 1
NLRI1 + group-id 2

The RR receives both this routes (must be ADD-PATHS, as mentioned in the draft). The RR needs to use ADD-PATHS itself to send it to the PE (final receiver)

-J




On 7/27/2017 9:44 PM, Robert Raszuk wrote:
Hi Jakob,

Two flowspec routes with the same NLRI may be originated by different speakers.


Group-id (scoped application of specific flow-spec rules) is addressing a special case where it is generated carefully by either controller or provisioning tools. I do not see therefor a practical case where the same such rule would be coming from two or more independent sources and would be applicable ​to different interface groups. 

It sounds more like a protocol conflict or provisioning bug and not something we should worry about how to carry it across RRs. Standard protocol behavior would be fine here.

Now also notice what would receiver do ... treat the subsequent update with the exactly same NLRI as implicit withdraw or run best path if they come from different peers and still apply single one to local data plane. So really there is no point to give it both such paths with ADD-PATHs. As it is on final receivers the same should be done on RRs ... 

​Cheers,
//RR.​

 

The first route will have one group-id. The second route will have another group-id.

 

Thanks,

Jakob.

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: Wednesday, July 26, 2017 4:38 PM
To: Juan Alcaide (jalcaide) <jalcaide@cisco.com>
Cc: idr wg <idr@ietf.org>
Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT (part 2)

 

Hi Juan,

 

>  (we assume controller(s) may not want to send multiple ext-communities with same NLRI).

 

If I recall group-ids are carried in new RT format: 

 

"This new BGP Route Target extended community is encoded as follows :

 

       0                   1                   2                   3

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |  Type (TBD)   |      0x02     |    Autonomous System Number   :

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      :     AS Number (cont.)         |O|I|      Group Identifier     |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

"

 

So just like an UPDATE message of SAFI 128 may contain many RTs why would you see any 

issue to carry multiple ext communities of the above format here ? 

 

Best,

R.

 

On Thu, Jul 27, 2017 at 1:01 AM, Juan Alcaide (jalcaide) <jalcaide@cisco.com> wrote:

Hi,

From a previous thread, I see from the that using EXTCOMM to carry group-id information the choice. Reason was that every AS could use their own the group-id (perhaps different than another AS). With this choice, ADD-PATHS must be mandatory in order to support multiple group-ids for the same flowspec rule  (we assume controller(s) may not want to send multiple ext-communities with same NLRI).

But the draft really does not describe how to use ADD-PATHS, and it does not discuss its problems:

- Usually, ADD-PATHS is used for path diversity, and implementations typically don't advertise 2 paths with the same next-hop (otherwise, we could have path explosion across multiple levels of RRs)

- If ADD-PATHS has to advertise the same NLRI with different ext-communities, one solution would be for ADD-PAHTS not advertise the same set of ext-communities. Unless, I guess, next-hops are different. Otherwise, we would have path explosion.

- Assuming the above, we should define a particular set of ADD-PATHS rules for flowspec AF. And, of course, leave the door open for future specific ADD-PATHs rules for other AFs (it would not be about path diversity anymore, but about propagating different information for forwarding purposes -imagine what we could have done with an IPv4 prefix: send the same net part as a NLRI and multiple ext-communities representing different prefix-lengths -).

- Since paths in a net are typically implemented as a list, there could be scalability problems if we ever want to support many group-ids.

My solution to simplify all these problems would be to add a discriminator on the NLRI (by defining a new dummy type for flowspec). We could still use ext-communities to actually match the NLRIs to interfaces. Similar to RD and RT usage.

Thoughts?

-J


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

 





--------------D383C413C4535072AC5B5AD6-- From nobody Fri Jul 28 04:22:51 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3741322CD for ; Fri, 28 Jul 2017 04:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.512 X-Spam-Level: X-Spam-Status: No, score=-14.512 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, T_KAM_HTML_FONT_INVALID=0.01, 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 rCO64-e_bLG9 for ; Fri, 28 Jul 2017 04:22:46 -0700 (PDT) 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 6B9C01322C6 for ; Fri, 28 Jul 2017 04:22:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=41117; q=dns/txt; s=iport; t=1501240966; x=1502450566; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=v6mHtgRhvObJDo4WJUT5lDH6q0jeyutIX8EfBiPiErI=; b=m+0n/ngKE5ENxi5lvCk7kUcHOozWFQjy7muyR//KfJJiPGcBOVDLwzZt QMN3yjWIDBAZ3q6ShJEGmWtgUv5zVofJpDIm7/umhRevY1sIszzEUbVT0 jF6NuJhFxvrSw+Lyx2jPSMXLf2uzXcxRKyQMepjDBrxb8hAvXuXy2EOkg k=; X-IronPort-AV: E=Sophos;i="5.40,425,1496102400"; d="scan'208,217";a="273860409" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jul 2017 11:22:45 +0000 Received: from [10.82.221.134] (rtp-vpn3-1408.cisco.com [10.82.221.134]) (authenticated bits=0) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v6SBMhv5003990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 28 Jul 2017 11:22:44 GMT To: "Jakob Heitz (jheitz)" , Robert Raszuk Cc: idr wg References: <9fa67eb0-8f99-a46f-aff1-d42a279ab833@cisco.com> <8dd3e766b58944a3b176fc743e478137@XCH-ALN-014.cisco.com> From: "Juan Alcaide (jalcaide)" Message-ID: <13eab622-8879-ca6c-50f9-63e1858709b8@cisco.com> Date: Fri, 28 Jul 2017 13:22:42 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9335A4249556DD5534B2F904" Content-Language: en-US X-Authenticated-User: jalcaide Archived-At: Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT (part 2) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 11:22:49 -0000 This is a multi-part message in MIME format. --------------9335A4249556DD5534B2F904 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Jakob, Yes, this is a solution if you want to send the same flowspec rule to be used to drop packets for interface-group1 and interface-group2 But imagine for interface-group1 you want to drop packets, and for interface-group2 you want to do rate-limit You need to send 2 updates with NLRI (and doing ADD-PATHS if you wan tot send them over the same session). This is section 8 of the draft -J On 7/27/2017 11:49 PM, Jakob Heitz (jheitz) wrote: > > Juan, > > just to you. > > It can send one route: > > NLRI1 + group-id 1 + group-id 2 > > The argument that there may be too many group-ids to fit into a BGP > update message is too weak. > > You would have to demonstrate a case that actually happened and not > just hypothetical. > > Thanks, > > Jakob. > > *From:*Juan Alcaide (jalcaide) > *Sent:* Thursday, July 27, 2017 2:37 PM > *To:* Robert Raszuk ; Jakob Heitz (jheitz) > > *Cc:* idr wg > *Subject:* Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI > vs EXTCT (part 2) > > Robert, > > We may support or not support unsynchronized controllers > But let's assume for a second we are just using one controller > but can a single controller sending > > NLRI1 + group-id 1 > NLRI1 + group-id 2 > > The RR receives both this routes (must be ADD-PATHS, as mentioned in > the draft). The RR needs to use ADD-PATHS itself to send it to the PE > (final receiver) > > -J > > > > On 7/27/2017 9:44 PM, Robert Raszuk wrote: > > Hi Jakob, > > Two flowspec routes with the same NLRI may be originated by > different speakers. > > Group-id (scoped application of specific flow-spec rules) is > addressing a special case where it is generated carefully by > either controller or provisioning tools. I do not see therefor a > practical case where the same such rule would be coming from two > or more independent sources and would be applicable ​to different > interface groups. > > It sounds more like a protocol conflict or provisioning bug and > not something we should worry about how to carry it across RRs. > Standard protocol behavior would be fine here. > > Now also notice what would receiver do ... treat the subsequent > update with the exactly same NLRI as implicit withdraw or run best > path if they come from different peers and still apply single one > to local data plane. So really there is no point to give it both > such paths with ADD-PATHs. As it is on final receivers the same > should be done on RRs ... > > ​Cheers, > //RR.​ > > The first route will have one group-id. The second route will > have another group-id. > > Thanks, > > Jakob. > > *From:*Idr [mailto:idr-bounces@ietf.org > ] *On Behalf Of *Robert Raszuk > *Sent:* Wednesday, July 26, 2017 4:38 PM > *To:* Juan Alcaide (jalcaide) > > *Cc:* idr wg > > *Subject:* Re: [Idr] draft-litkowski-idr-flowspec-interfaceset > => NLRI vs EXTCT (part 2) > > Hi Juan, > > > (we assume controller(s) may not want to send multiple ext-communities > with same NLRI). > > If I recall group-ids are carried in new RT format: > > "This new BGP Route Target extended community is encoded as > follows : > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 > 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type (TBD) | 0x02 | Autonomous System > Number : > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > : AS Number (cont.) |O|I| Group Identifier > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > " > > So just like an UPDATE message of SAFI 128 may contain many > RTs why would you see any > > issue to carry multiple ext communities of the above format > here ? > > Best, > > R. > > On Thu, Jul 27, 2017 at 1:01 AM, Juan Alcaide (jalcaide) > > wrote: > > Hi, > > From a previous thread, I see from the that using EXTCOMM > to carry group-id information the choice. Reason was that > every AS could use their own the group-id (perhaps > different than another AS). With this choice, ADD-PATHS > must be mandatory in order to support multiple group-ids > for the same flowspec rule (we assume controller(s) may > not want to send multiple ext-communities with same NLRI). > > But the draft really does not describe how to use > ADD-PATHS, and it does not discuss its problems: > > - Usually, ADD-PATHS is used for path diversity, and > implementations typically don't advertise 2 paths with the > same next-hop (otherwise, we could have path explosion > across multiple levels of RRs) > > - If ADD-PATHS has to advertise the same NLRI with > different ext-communities, one solution would be for > ADD-PAHTS not advertise the same set of ext-communities. > Unless, I guess, next-hops are different. Otherwise, we > would have path explosion. > > - Assuming the above, we should define a particular set of > ADD-PATHS rules for flowspec AF. And, of course, leave the > door open for future specific ADD-PATHs rules for other > AFs (it would not be about path diversity anymore, but > about propagating different information for forwarding > purposes -imagine what we could have done with an IPv4 > prefix: send the same net part as a NLRI and multiple > ext-communities representing different prefix-lengths -). > > - Since paths in a net are typically implemented as a > list, there could be scalability problems if we ever want > to support many group-ids. > > My solution to simplify all these problems would be to add > a discriminator on the NLRI (by defining a new dummy type > for flowspec). We could still use ext-communities to > actually match the NLRIs to interfaces. Similar to RD and > RT usage. > > Thoughts? > > -J > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --------------9335A4249556DD5534B2F904 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Jakob,

Yes, this is a solution if you want to send the same flowspec rule to be used to drop packets for interface-group1 and interface-group2
But imagine for interface-group1 you want to drop packets, and for interface-group2 you want to do rate-limit

You need to send 2 updates with NLRI (and doing ADD-PATHS if you wan tot send them over the same session). This is section 8 of the draft

-J

On 7/27/2017 11:49 PM, Jakob Heitz (jheitz) wrote:

Juan,

 

just to you.

 

It can send one route:

NLRI1 + group-id 1 + group-id 2

 

The argument that there may be too many group-ids to fit into a BGP update message is too weak.

You would have to demonstrate a case that actually happened and not just hypothetical.

 

Thanks,

Jakob.

 

From: Juan Alcaide (jalcaide)
Sent: Thursday, July 27, 2017 2:37 PM
To: Robert Raszuk <robert@raszuk.net>; Jakob Heitz (jheitz) <jheitz@cisco.com>
Cc: idr wg <idr@ietf.org>
Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT (part 2)

 

Robert,

We may support or not support unsynchronized controllers
But let's assume for a second we are just using one controller
but can a single controller sending

NLRI1 + group-id 1
NLRI1 + group-id 2

The RR receives both this routes (must be ADD-PATHS, as mentioned in the draft). The RR needs to use ADD-PATHS itself to send it to the PE (final receiver)

-J



On 7/27/2017 9:44 PM, Robert Raszuk wrote:

Hi Jakob,

 

Two flowspec routes with the same NLRI may be originated by different speakers.

 

Group-id (scoped application of specific flow-spec rules) is addressing a special case where it is generated carefully by either controller or provisioning tools. I do not see therefor a practical case where the same such rule would be coming from two or more independent sources and would be applicable ​to different interface groups. 

 

It sounds more like a protocol conflict or provisioning bug and not something we should worry about how to carry it across RRs. Standard protocol behavior would be fine here.

 

Now also notice what would receiver do ... treat the subsequent update with the exactly same NLRI as implicit withdraw or run best path if they come from different peers and still apply single one to local data plane. So really there is no point to give it both such paths with ADD-PATHs. As it is on final receivers the same should be done on RRs ... 

 

​Cheers,
//RR.​

 

 

The first route will have one group-id. The second route will have another group-id.

 

Thanks,

Jakob.

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: Wednesday, July 26, 2017 4:38 PM
To: Juan Alcaide (jalcaide) <jalcaide@cisco.com>
Cc: idr wg <idr@ietf.org>
Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT (part 2)

 

Hi Juan,

 

>  (we assume controller(s) may not want to send multiple ext-communities with same NLRI).

 

If I recall group-ids are carried in new RT format: 

 

"This new BGP Route Target extended community is encoded as follows :

 

       0                   1                   2                   3

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |  Type (TBD)   |      0x02     |    Autonomous System Number   :

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      :     AS Number (cont.)         |O|I|      Group Identifier     |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

"

 

So just like an UPDATE message of SAFI 128 may contain many RTs why would you see any 

issue to carry multiple ext communities of the above format here ? 

 

Best,

R.

 

On Thu, Jul 27, 2017 at 1:01 AM, Juan Alcaide (jalcaide) <jalcaide@cisco.com> wrote:

Hi,

From a previous thread, I see from the that using EXTCOMM to carry group-id information the choice. Reason was that every AS could use their own the group-id (perhaps different than another AS). With this choice, ADD-PATHS must be mandatory in order to support multiple group-ids for the same flowspec rule  (we assume controller(s) may not want to send multiple ext-communities with same NLRI).

But the draft really does not describe how to use ADD-PATHS, and it does not discuss its problems:

- Usually, ADD-PATHS is used for path diversity, and implementations typically don't advertise 2 paths with the same next-hop (otherwise, we could have path explosion across multiple levels of RRs)

- If ADD-PATHS has to advertise the same NLRI with different ext-communities, one solution would be for ADD-PAHTS not advertise the same set of ext-communities. Unless, I guess, next-hops are different. Otherwise, we would have path explosion.

- Assuming the above, we should define a particular set of ADD-PATHS rules for flowspec AF. And, of course, leave the door open for future specific ADD-PATHs rules for other AFs (it would not be about path diversity anymore, but about propagating different information for forwarding purposes -imagine what we could have done with an IPv4 prefix: send the same net part as a NLRI and multiple ext-communities representing different prefix-lengths -).

- Since paths in a net are typically implemented as a list, there could be scalability problems if we ever want to support many group-ids.

My solution to simplify all these problems would be to add a discriminator on the NLRI (by defining a new dummy type for flowspec). We could still use ext-communities to actually match the NLRIs to interfaces. Similar to RD and RT usage.

Thoughts?

-J


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

 

 

 


--------------9335A4249556DD5534B2F904-- From nobody Fri Jul 28 04:52:38 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77731131F3C for ; Fri, 28 Jul 2017 04:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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 7u80WZTSrD5m for ; Fri, 28 Jul 2017 04:52:33 -0700 (PDT) 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 100AF131EC1 for ; Fri, 28 Jul 2017 04:52:33 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id v205so79535292itf.1 for ; Fri, 28 Jul 2017 04:52:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=/Y1tnWeXFUvp8ZU09CvUTz4CQ0WJ0vwhiDiDS7e0Kf0=; b=I6BTtH9x8cwMKUUBOvhWry3pT5qGlt1bNKjcYUwa9/xf4rmhuXI8LHcakAoj+qHrpu Xql74jW5C0te4PqBLonjSTtP7QggPZFb4B8R1o57QMOSnqoncFEJPS9CigCMBVT48+x4 pOngqJsPl8DptUkBCYUIiHkdpBcagpAODQL9P9nanR8r8LK69vyjJjsHf/JsFPdGMoV5 B0fFSUhfAv3MEuzFEpy5VNC6n57ByZK/Tyn6eT4q5P32wkwGaBR8y2tJn58fFL+X+7Hp SAEWVRvtuQ3nA6i7NGgVoFG6J3BSwt67AMbkF+sYXV3UGd7wnERVm3tfJQAN+vSixah+ VQIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=/Y1tnWeXFUvp8ZU09CvUTz4CQ0WJ0vwhiDiDS7e0Kf0=; b=ujuCcOtMXy8c58dm0GqCqa+fZRSe3QYPVTNSp/ezhEZxB9fwNZuuwfu2HF/ttnPT6m /ambg+GK9KXUV0Rwwz2xLyePeAZBgEjxPG7geuw4GDsXUkdS+9lFth3xmZlrK1PAPFRX QT+H5e6ivybPIFs6lMFY9c0nL3WK9DMr37Lah8OzMNnklswP0F/geFivsjf88rggoHA/ XUnWofQ6sLaeXroHqSiZ7WRp9FrpIQ25X8q6uJrgT6O1xdw1O9y7wPNfgQnScgx2QMdt fSZGkEp9TkE94+Tn2tMWz4rbeLxpgFDn6DXBl48MXU7FN+l8njWuJMR/JbwdGiijMtxv +Vcw== X-Gm-Message-State: AIVw110X67C3fsnMOs5PZ8KA2uEBtWjyU41vkTwPvwb78WFRTVgpNAmZ JMeLv1d6r7XNKml7MVu1zuu3ot960q+3 X-Received: by 10.36.200.5 with SMTP id w5mr9039860itf.118.1501242752141; Fri, 28 Jul 2017 04:52:32 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.153.21 with HTTP; Fri, 28 Jul 2017 04:52:31 -0700 (PDT) In-Reply-To: References: <9fa67eb0-8f99-a46f-aff1-d42a279ab833@cisco.com> <8dd3e766b58944a3b176fc743e478137@XCH-ALN-014.cisco.com> From: Robert Raszuk Date: Fri, 28 Jul 2017 13:52:31 +0200 X-Google-Sender-Auth: 2GC6SIuu5SUVuQHSNOxVNOG3nKg Message-ID: To: "Juan Alcaide (jalcaide)" Cc: "Jakob Heitz (jheitz)" , idr wg Content-Type: multipart/alternative; boundary="94eb2c05f77af6911305555f50f1" Archived-At: Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT (part 2) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 11:52:37 -0000 --94eb2c05f77af6911305555f50f1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Juan, (group-id: what to you specify in ext-community; interface-group: what you > specify under interface configuration) > =E2=80=8BObvious. =E2=80=8B If you use ADD-PATHS, you can send identical NLRIs and you consider them as > valid (no implicit withdraw) > =E2=80=8BIf your controller or management station does not support ADD-PATH= S this is not the case. Only when you have ADD-PATHS everywhere you may play that game. Remember flow-spec was designed to be a DDoS mitigation tool across ASes. Across ASes last time I checked deployment of ADD-PATHS is zero. Now since some folks turned it into config push =E2=80=8Bis not something original 55= 75 can be blamed for. > There is a requirement that the same flowspec rule, could be used for 2 > different interface-groups (let's say interfaces customer-facing and > interfaces provider-facing). But also you may want to use different actio= ns > based on the group-id (section 8 of the draft) > =E2=80=8BThat is just operational mess. To do that you can use SAFI 134 whe= re 8 octet RD is part of the NLRI what makes NLRI unique. I think we basically need to expand/clarify the ADD-PATHS part. Regarding > your points: > 1. For a given NLRI, we change group-ids or actions based on what we want > to achieve. So it's based on how customer sets the rule in the controller= . > There may be a need to send same NLRI with 2 different sets of > action+group-id > =E2=80=8BI think doing this in such way is very messy. Pushing FS routes wi= th RD as indicated above is much cleaner if there such need to apply different actions or group IDs for the same NLRIs. =E2=80=8B > 2. If receiver receives more than one group-id, it should apply all the > actions specified to *all* the interface-group associated to all the > group-ids it received. Draft does explicitly say what to do when you > receive a NLRI with multiple group-ids, but I think it should be applied = to > all interface-groups (probably it should be clarified) > =E2=80=8Bok. Thx, R.=E2=80=8B > > > -J > > > > > On 7/27/2017 11:43 PM, Robert Raszuk wrote: > > Juan, > > Sending from single controller (single BGP peer) two updates with > identical NLRIs is an implicit withdraw. ADD-PATHs has nothing to here. > > Likewise RR should treat is as implicit withdraw of the previous one too. > > If you go by your line of thinking what would make controller to change > for given NLRI1 group-id 1 to group-id 2 if there is need to do so ? > > In any case if you decide to add additional text to the current draft or > decide to write new draft to address this please do make sure to clearly > define two things: > > 1. How for a given NLRI we change either actions or group-ids > > 2. What should receiver do when for a given NLRI he received more then on= e > group-id or more then one set of actions ? > > Thanks, > R. > > > > > > On Thu, Jul 27, 2017 at 11:37 PM, Juan Alcaide (jalcaide) < > jalcaide@cisco.com> wrote: > >> Robert, >> >> We may support or not support unsynchronized controllers >> But let's assume for a second we are just using one controller >> but can a single controller sending >> >> NLRI1 + group-id 1 >> NLRI1 + group-id 2 >> >> The RR receives both this routes (must be ADD-PATHS, as mentioned in the >> draft). The RR needs to use ADD-PATHS itself to send it to the PE (final >> receiver) >> >> -J >> >> >> >> >> On 7/27/2017 9:44 PM, Robert Raszuk wrote: >> >> Hi Jakob, >> >> Two flowspec routes with the same NLRI may be originated by different >>> speakers. >>> >> >> Group-id (scoped application of specific flow-spec rules) is addressing = a >> special case where it is generated carefully by either controller or >> provisioning tools. I do not see therefor a practical case where the sam= e >> such rule would be coming from two or more independent sources and would= be >> applicable =E2=80=8Bto different interface groups. >> >> It sounds more like a protocol conflict or provisioning bug and not >> something we should worry about how to carry it across RRs. Standard >> protocol behavior would be fine here. >> >> Now also notice what would receiver do ... treat the subsequent update >> with the exactly same NLRI as implicit withdraw or run best path if they >> come from different peers and still apply single one to local data plane= . >> So really there is no point to give it both such paths with ADD-PATHs. A= s >> it is on final receivers the same should be done on RRs ... >> >> =E2=80=8BCheers, >> //RR.=E2=80=8B >> >> >> >>> The first route will have one group-id. The second route will have >>> another group-id. >>> >>> >>> >>> Thanks, >>> >>> Jakob. >>> >>> >>> >>> *From:* Idr [mailto:idr-bounces@ietf.org] *On Behalf Of *Robert Raszuk >>> *Sent:* Wednesday, July 26, 2017 4:38 PM >>> *To:* Juan Alcaide (jalcaide) >>> *Cc:* idr wg >>> *Subject:* Re: [Idr] draft-litkowski-idr-flowspec-interfaceset =3D> NLR= I >>> vs EXTCT (part 2) >>> >>> >>> >>> Hi Juan, >>> >>> >>> >>> > (we assume controller(s) may not want to send multiple >>> ext-communities with same NLRI). >>> >>> >>> >>> If I recall group-ids are carried in new RT format: >>> >>> >>> >>> "This new BGP Route Target extended community is encoded as follows : >>> >>> >>> >>> 0 1 2 3 >>> >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> | Type (TBD) | 0x02 | Autonomous System Number : >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> : AS Number (cont.) |O|I| Group Identifier | >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> " >>> >>> >>> >>> So just like an UPDATE message of SAFI 128 may contain many RTs why >>> would you see any >>> >>> issue to carry multiple ext communities of the above format here ? >>> >>> >>> >>> Best, >>> >>> R. >>> >>> >>> >>> On Thu, Jul 27, 2017 at 1:01 AM, Juan Alcaide (jalcaide) < >>> jalcaide@cisco.com> wrote: >>> >>> Hi, >>> >>> From a previous thread, I see from the that using EXTCOMM to carry >>> group-id information the choice. Reason was that every AS could use the= ir >>> own the group-id (perhaps different than another AS). With this choice, >>> ADD-PATHS must be mandatory in order to support multiple group-ids for = the >>> same flowspec rule (we assume controller(s) may not want to send multi= ple >>> ext-communities with same NLRI). >>> >>> But the draft really does not describe how to use ADD-PATHS, and it doe= s >>> not discuss its problems: >>> >>> - Usually, ADD-PATHS is used for path diversity, and implementations >>> typically don't advertise 2 paths with the same next-hop (otherwise, we >>> could have path explosion across multiple levels of RRs) >>> >>> - If ADD-PATHS has to advertise the same NLRI with different >>> ext-communities, one solution would be for ADD-PAHTS not advertise the = same >>> set of ext-communities. Unless, I guess, next-hops are different. >>> Otherwise, we would have path explosion. >>> >>> - Assuming the above, we should define a particular set of ADD-PATHS >>> rules for flowspec AF. And, of course, leave the door open for future >>> specific ADD-PATHs rules for other AFs (it would not be about path >>> diversity anymore, but about propagating different information for >>> forwarding purposes -imagine what we could have done with an IPv4 prefi= x: >>> send the same net part as a NLRI and multiple ext-communities represent= ing >>> different prefix-lengths -). >>> >>> - Since paths in a net are typically implemented as a list, there could >>> be scalability problems if we ever want to support many group-ids. >>> >>> My solution to simplify all these problems would be to add a >>> discriminator on the NLRI (by defining a new dummy type for flowspec). = We >>> could still use ext-communities to actually match the NLRIs to interfac= es. >>> Similar to RD and RT usage. >>> >>> Thoughts? >>> >>> -J >>> >>> >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www.ietf.org/mailman/listinfo/idr >>> >>> >>> >> >> >> > > --94eb2c05f77af6911305555f50f1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Juan,

(group-id: what to you specify in ext-com= munity; interface-group: what you specify under interface configuration)

=E2=80=8BObvious. =E2=80=8B
If you us= e ADD-PATHS, you can send identical NLRIs and you consider them as valid (no implicit withdraw)

=E2=80=8BIf your controller or = management station does not support ADD-PATHS this is not the case. Only wh= en you have ADD-PATHS everywhere you may play that game.=C2=A0

Remember flow-spec was designed to= be a DDoS mitigation tool across ASes. Across ASes last time I checked dep= loyment of ADD-PATHS is zero. Now since some folks turned it into config pu= sh =E2=80=8Bis not something original 5575 can be blamed for.=C2=A0
=C2=A0
There is a requirement that the same flowspec rule, could be used for 2 different interface-groups (let's say interfaces customer-facing and interfaces provider-facing). But also you may want to use different actions based on the group-id (section 8 of the draft)

=E2=80=8BThat is just operational mess. To do that you can use SAF= I 134 where 8 octet RD is part of the NLRI what makes NLRI unique.=C2=A0
I think w= e basically need to expand/clarify the ADD-PATHS part. Regarding your points:
1. For a given NLRI, we change group-ids or actions based on what we want to achieve. So it's based on how customer sets the rule i= n the controller. There may be a need to send same NLRI with 2 different sets of action+group-id
=E2=80=8BI think doing this in such way is = very messy. Pushing FS routes with RD as indicated above is much cleaner if= there such need to apply different actions or group IDs for the same NLRIs= . =E2=80=8B
=C2=A0
=
2. If receiver receives more than one group-id, it should apply all the actions specified to *all* the interface-group associated to all the group-ids it received. Draft does explicitly say what to do when you receive a NLRI with multiple group-ids, but I think it should be applied to all interface-groups (probably it should be clarified)

=E2=80=8Bok.

= Thx,
R.=E2=80=8B


=C2=A0


-J




On 7/27/2017 11:43 PM, Robert Raszuk wrote:
=20
Juan,

Sending from single controller (single BGP peer) two updates with identical NLRIs is an implicit withdraw. ADD-PATHs has nothing to here.=C2=A0

Likewise RR should treat is as implicit withdraw of the previous one too.=C2=A0

If you go by your line of thinking what would make controller to change for given NLRI1 group-id 1 to group-id 2 if there is need to do so ?=C2=A0

In any case if you decide to add additional text to the current draft or decide to write new draft to address this please do make sure to clearly define two things:

1. How for a given NLRI we change either actions or group-ids=C2=A0<= /div>

2. What should receiver do when for a given NLRI he received more then one group-id or more then one set of actions ?=C2=A0

Thanks,
R.





On Thu, Jul 27, 2017 at 11:37 PM, Juan Alcaide (jalcaide) <jalcaide@cisco.com> wrote:
Robert,

We may support or not support unsynchronized controllers But let's assume for a second we are just using one controller
but can a single controller sending

NLRI1 + group-id 1
NLRI1 + group-id 2

The RR receives both this routes (must be ADD-PATHS, as mentioned in the draft). The RR needs to use ADD-PATHS itself to send it to the PE (final receiver)

-J




On 7/27/2017 9:44 PM, Robert Raszuk wrote:
Hi Jakob,

Two flowspec routes with the same NLRI may be originated by different speakers.


Group-id (scoped application of specific flow-spec rules) is addressing a special case where it is generated carefully by either controller or provisioning tools. I do not see therefor a practical case where the same such rule would be coming from two or more independent sources and would be applicable =E2=80=8Bto different interface groups.=C2=A0

It sounds more like a protocol conflict or provisioning bug and not something we should worry about how to carry it across RRs. Standard protocol behavior would be fine here.

Now also notice what would receiver do ... treat the subsequent update with the exactly same NLRI as implicit withdraw or run best path if they come from different peers and still apply single one to local data plane. So really there is no point to give it both such paths with ADD-PATHs. As it is on final receivers the same should be done on RRs ...=C2=A0

=E2=80=8BCheers,
//RR.=E2=80=8B

=C2=A0

The first route will have one group-id. The second route will have another group-id.

=C2=A0<= /p>

Thanks,=

Jakob.<= /p>

=C2=A0<= /p>

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: Wednesday, July 26, 2017 4:38 PM
To: Juan Alcaide (jalcaide) <jalcaide@cisco.com>
Cc: idr wg <idr@ietf.org>
Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset =3D> NLRI vs EXTCT (part 2)

=C2=A0

Hi Juan,

=C2=A0

>=C2=A0=C2=A0(we assume controller(s) may not want to send multiple ext-communities with same NLRI).

=C2=A0

If I recall group-ids are carried in new RT format:=C2= =A0

=C2=A0

"This new BGP Route Target extended community is encoded as follows :

=C2=A0

= =C2=A0 =C2=A0 =C2=A0 =C2=A00 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 3

= =C2=A0 =C2=A0 =C2=A0 =C2=A00 1 2 3= 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1<= /p>

= =C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

= =C2=A0 =C2=A0 =C2=A0 | =C2=A0Type = (TBD) =C2=A0 | =C2=A0 =C2=A0 =C2=A00x02 =C2=A0 = =C2=A0 | =C2=A0 =C2=A0Autonomous System Number =C2=A0 :

= =C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

= =C2=A0 =C2=A0 =C2=A0 : =C2=A0 =C2= =A0 AS Number (cont.) =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |O|I| =C2=A0 =C2=A0 =C2=A0Group Identifi= er =C2=A0 =C2=A0 |

= =C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

&q= uot;

=C2=A0

So just like an UPDATE message of SAFI 128 may contain many RTs why would you see any=C2=A0

issue to carry multiple ext communities of the above format here ?=C2=A0

=C2=A0

Best,

R.

=C2=A0

On Thu, Jul 27, 2017 at 1:01 AM, Juan Alcaide (jalcaide) <jalcaide@cisco.com= > wrote:

Hi,

From a previous thread, I see from the that using EXTCOMM to carry group-id information the choice. Reason was that every AS could use their own the group-id (perhaps different than another AS). With this choice, ADD-PATHS must be mandatory in order to support multiple group-ids for the same flowspec rule=C2=A0 (we assume controller(s) may not want to send multiple ext-communities with same NLRI).

But the draft really does not describe how to use ADD-PATHS, and it does not discuss its problems:

- Usually, ADD-PATHS is used for path diversity, and implementations typically don't advertise 2 paths with the same next-hop (otherwise, we could have path explosion across multiple levels of RRs)

- If ADD-PATHS has to advertise the same NLRI with different ext-communities, one solution would be for ADD-PAHTS not advertise the same set of ext-communities. Unless, I guess, next-hops are different. Otherwise, we would have path explosion.

- Assuming the above, we should define a particular set of ADD-PATHS rules for flowspec AF. And, of course, leave the door open for future specific ADD-PATHs rules for other AFs (it would not be about path diversity anymore, but about propagating different information for forwarding purposes -imagine what we could have done with an IPv4 prefix: send the same net part as a NLRI and multiple ext-communities representing different prefix-lengths -).=

- Since paths in a net are typically implemented as a list, there could be scalability problems if we ever want to support many group-ids.

My solution to simplify all these problems would be to add a discriminator on the NLRI (by defining a new dummy type for flowspec). We could still use ext-communities to actually match the NLRIs to interfaces. Similar to RD and RT usage.

Thoughts?

-J


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

=C2=A0






--94eb2c05f77af6911305555f50f1-- From nobody Fri Jul 28 05:02:55 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2CB12783A for ; Fri, 28 Jul 2017 05:02:53 -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 VwTYE9TcHhrX for ; Fri, 28 Jul 2017 05:02:49 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D5261322E0 for ; Fri, 28 Jul 2017 05:02:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=41055; q=dns/txt; s=iport; t=1501243364; x=1502452964; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9JtQztToJiaum0fFNu8Twa8sVAXjK/YfjHZaSJ+Rtx4=; b=EvRrOekbzMqTN/4LJJ8DWoX9KnXaTcMA2PUlmv80H1uouVh69ywMqCvy 8c6Vr0ce5MQfqlbw32cxIEOMN6jCZma+0UA3RP3JwS4OT7y4gfUdTquC1 0BugkwZqch9LdcfZQ98a/F3ovz5PLL+sjfJNyKDTKE6PeuX35wozseees U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DGAACcJntZ/5NdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm8+LWSBFAeOBo96gWt1lRaCDwMhAQqFGwIag1Y/GAECAQEBAQE?= =?us-ascii?q?BAWsohRgBAQEBAwEBIUQHCxACAQgRAwEBASEBBgMCAgIlCxQJCAIEAQ0FFAeJM?= =?us-ascii?q?GQQrm+CJieLFwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgyiBJ4QHghtYNIUKCRa?= =?us-ascii?q?CXYJhBZdgiA0CixiDT4U9ggwZhTmKXolTjB4BHzg/S3cVSYRdgjx2h0AHgSuBD?= =?us-ascii?q?gEBAQ?= X-IronPort-AV: E=Sophos;i="5.40,425,1496102400"; d="scan'208,217";a="462684921" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Jul 2017 12:02:43 +0000 Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v6SC2gQV006091 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 28 Jul 2017 12:02:42 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 28 Jul 2017 08:02:41 -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, 28 Jul 2017 08:02:41 -0400 From: "Acee Lindem (acee)" To: Robert Raszuk , "Juan Alcaide (jalcaide)" CC: idr wg Thread-Topic: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT (part 2) Thread-Index: AQHTBmMsoLqrouxoe0ioArBC+Wdvh6JnBqgAgAEOOjaAAGJ2gIAAAcqAgADkMgCAAAjwgP//v8KA Date: Fri, 28 Jul 2017 12:02:41 +0000 Message-ID: References: <9fa67eb0-8f99-a46f-aff1-d42a279ab833@cisco.com> <8dd3e766b58944a3b176fc743e478137@XCH-ALN-014.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: multipart/alternative; boundary="_000_D5A09F0BBA519aceeciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT (part 2) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 12:02:53 -0000 --_000_D5A09F0BBA519aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2hhdCB3YXMgdGhlIHJlYXNvbiBmb3Igbm90IG1ha2luZyB0aGUgaW50ZXJmYWNlLWdyb3VwIHBh cnQgYSBuZXcgY29tcG9uZW50IHR5cGUgaW4gdGhlIE5MUkk/IEl0IHNlZW1zIHRoYXQgbWFraW5n IGl0IGp1c3QgYW5vdGhlciBGbG93IFNwZWMgbWF0Y2ggY29uZGl0aW9uIHdvdWxkICBoYW5kbGUg YWxsIHRoZXNlIHNpdHVhdGlvbnMgbmF0dXJhbGx5Lg0KDQogSSByZW1lbWJlciB0aGF0IHRoaXMg d2FzIGRpc2N1c3NlZCBidXQgZG9u4oCZdCByZWNhbGwgd2hldGhlciBpdCB3YXMgYmFja3dhcmQg Y29tcGF0aWJpbGl0eSBvciB0aGF0IHRoZSBzZW1hbnRpY3Mgb2YgaW50ZXJmYWNlIGdyb3VwLWlk IHdhcyBhIGJldHRlciBmaXQgZm9yIGFuIGV4dGVuZGVkIGNvbW11bml0eS4NCg0KVGhhbmtzLA0K QWNlZQ0KDQpGcm9tOiBJZHIgPGlkci1ib3VuY2VzQGlldGYub3JnPG1haWx0bzppZHItYm91bmNl c0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBSb2JlcnQgUmFzenVrIDxyb2JlcnRAcmFzenVrLm5l dDxtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQ+Pg0KRGF0ZTogRnJpZGF5LCBKdWx5IDI4LCAyMDE3 IGF0IDc6NTIgQU0NClRvOiAiSnVhbiBBbGNhaWRlIChqYWxjYWlkZSkiIDxqYWxjYWlkZUBjaXNj by5jb208bWFpbHRvOmphbGNhaWRlQGNpc2NvLmNvbT4+DQpDYzogSURSIExpc3QgPGlkckBpZXRm Lm9yZzxtYWlsdG86aWRyQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbSWRyXSBkcmFmdC1saXRr b3dza2ktaWRyLWZsb3dzcGVjLWludGVyZmFjZXNldCA9PiBOTFJJIHZzIEVYVENUIChwYXJ0IDIp DQoNCkhpIEp1YW4sDQoNCihncm91cC1pZDogd2hhdCB0byB5b3Ugc3BlY2lmeSBpbiBleHQtY29t bXVuaXR5OyBpbnRlcmZhY2UtZ3JvdXA6IHdoYXQgeW91IHNwZWNpZnkgdW5kZXIgaW50ZXJmYWNl IGNvbmZpZ3VyYXRpb24pDQoNCuKAi09idmlvdXMuIOKAiw0KDQpJZiB5b3UgdXNlIEFERC1QQVRI UywgeW91IGNhbiBzZW5kIGlkZW50aWNhbCBOTFJJcyBhbmQgeW91IGNvbnNpZGVyIHRoZW0gYXMg dmFsaWQgKG5vIGltcGxpY2l0IHdpdGhkcmF3KQ0KDQrigItJZiB5b3VyIGNvbnRyb2xsZXIgb3Ig bWFuYWdlbWVudCBzdGF0aW9uIGRvZXMgbm90IHN1cHBvcnQgQURELVBBVEhTIHRoaXMgaXMgbm90 IHRoZSBjYXNlLiBPbmx5IHdoZW4geW91IGhhdmUgQURELVBBVEhTIGV2ZXJ5d2hlcmUgeW91IG1h eSBwbGF5IHRoYXQgZ2FtZS4NCg0KUmVtZW1iZXIgZmxvdy1zcGVjIHdhcyBkZXNpZ25lZCB0byBi ZSBhIEREb1MgbWl0aWdhdGlvbiB0b29sIGFjcm9zcyBBU2VzLiBBY3Jvc3MgQVNlcyBsYXN0IHRp bWUgSSBjaGVja2VkIGRlcGxveW1lbnQgb2YgQURELVBBVEhTIGlzIHplcm8uIE5vdyBzaW5jZSBz b21lIGZvbGtzIHR1cm5lZCBpdCBpbnRvIGNvbmZpZyBwdXNoIOKAi2lzIG5vdCBzb21ldGhpbmcg b3JpZ2luYWwgNTU3NSBjYW4gYmUgYmxhbWVkIGZvci4NCg0KVGhlcmUgaXMgYSByZXF1aXJlbWVu dCB0aGF0IHRoZSBzYW1lIGZsb3dzcGVjIHJ1bGUsIGNvdWxkIGJlIHVzZWQgZm9yIDIgZGlmZmVy ZW50IGludGVyZmFjZS1ncm91cHMgKGxldCdzIHNheSBpbnRlcmZhY2VzIGN1c3RvbWVyLWZhY2lu ZyBhbmQgaW50ZXJmYWNlcyBwcm92aWRlci1mYWNpbmcpLiBCdXQgYWxzbyB5b3UgbWF5IHdhbnQg dG8gdXNlIGRpZmZlcmVudCBhY3Rpb25zIGJhc2VkIG9uIHRoZSBncm91cC1pZCAoc2VjdGlvbiA4 IG9mIHRoZSBkcmFmdCkNCg0K4oCLVGhhdCBpcyBqdXN0IG9wZXJhdGlvbmFsIG1lc3MuIFRvIGRv IHRoYXQgeW91IGNhbiB1c2UgU0FGSSAxMzQgd2hlcmUgOCBvY3RldCBSRCBpcyBwYXJ0IG9mIHRo ZSBOTFJJIHdoYXQgbWFrZXMgTkxSSSB1bmlxdWUuDQoNCkkgdGhpbmsgd2UgYmFzaWNhbGx5IG5l ZWQgdG8gZXhwYW5kL2NsYXJpZnkgdGhlIEFERC1QQVRIUyBwYXJ0LiBSZWdhcmRpbmcgeW91ciBw b2ludHM6DQoxLiBGb3IgYSBnaXZlbiBOTFJJLCB3ZSBjaGFuZ2UgZ3JvdXAtaWRzIG9yIGFjdGlv bnMgYmFzZWQgb24gd2hhdCB3ZSB3YW50IHRvIGFjaGlldmUuIFNvIGl0J3MgYmFzZWQgb24gaG93 IGN1c3RvbWVyIHNldHMgdGhlIHJ1bGUgaW4gdGhlIGNvbnRyb2xsZXIuIFRoZXJlIG1heSBiZSBh IG5lZWQgdG8gc2VuZCBzYW1lIE5MUkkgd2l0aCAyIGRpZmZlcmVudCBzZXRzIG9mIGFjdGlvbitn cm91cC1pZA0KDQrigItJIHRoaW5rIGRvaW5nIHRoaXMgaW4gc3VjaCB3YXkgaXMgdmVyeSBtZXNz eS4gUHVzaGluZyBGUyByb3V0ZXMgd2l0aCBSRCBhcyBpbmRpY2F0ZWQgYWJvdmUgaXMgbXVjaCBj bGVhbmVyIGlmIHRoZXJlIHN1Y2ggbmVlZCB0byBhcHBseSBkaWZmZXJlbnQgYWN0aW9ucyBvciBn cm91cCBJRHMgZm9yIHRoZSBzYW1lIE5MUklzLiDigIsNCg0KMi4gSWYgcmVjZWl2ZXIgcmVjZWl2 ZXMgbW9yZSB0aGFuIG9uZSBncm91cC1pZCwgaXQgc2hvdWxkIGFwcGx5IGFsbCB0aGUgYWN0aW9u cyBzcGVjaWZpZWQgdG8gKmFsbCogdGhlIGludGVyZmFjZS1ncm91cCBhc3NvY2lhdGVkIHRvIGFs bCB0aGUgZ3JvdXAtaWRzIGl0IHJlY2VpdmVkLiBEcmFmdCBkb2VzIGV4cGxpY2l0bHkgc2F5IHdo YXQgdG8gZG8gd2hlbiB5b3UgcmVjZWl2ZSBhIE5MUkkgd2l0aCBtdWx0aXBsZSBncm91cC1pZHMs IGJ1dCBJIHRoaW5rIGl0IHNob3VsZCBiZSBhcHBsaWVkIHRvIGFsbCBpbnRlcmZhY2UtZ3JvdXBz IChwcm9iYWJseSBpdCBzaG91bGQgYmUgY2xhcmlmaWVkKQ0KDQrigItvay4NCg0KVGh4LA0KUi7i gIsNCg0KDQoNCg0KDQotSg0KDQoNCg0KDQpPbiA3LzI3LzIwMTcgMTE6NDMgUE0sIFJvYmVydCBS YXN6dWsgd3JvdGU6DQpKdWFuLA0KDQpTZW5kaW5nIGZyb20gc2luZ2xlIGNvbnRyb2xsZXIgKHNp bmdsZSBCR1AgcGVlcikgdHdvIHVwZGF0ZXMgd2l0aCBpZGVudGljYWwgTkxSSXMgaXMgYW4gaW1w bGljaXQgd2l0aGRyYXcuIEFERC1QQVRIcyBoYXMgbm90aGluZyB0byBoZXJlLg0KDQpMaWtld2lz ZSBSUiBzaG91bGQgdHJlYXQgaXMgYXMgaW1wbGljaXQgd2l0aGRyYXcgb2YgdGhlIHByZXZpb3Vz IG9uZSB0b28uDQoNCklmIHlvdSBnbyBieSB5b3VyIGxpbmUgb2YgdGhpbmtpbmcgd2hhdCB3b3Vs ZCBtYWtlIGNvbnRyb2xsZXIgdG8gY2hhbmdlIGZvciBnaXZlbiBOTFJJMSBncm91cC1pZCAxIHRv IGdyb3VwLWlkIDIgaWYgdGhlcmUgaXMgbmVlZCB0byBkbyBzbyA/DQoNCkluIGFueSBjYXNlIGlm IHlvdSBkZWNpZGUgdG8gYWRkIGFkZGl0aW9uYWwgdGV4dCB0byB0aGUgY3VycmVudCBkcmFmdCBv ciBkZWNpZGUgdG8gd3JpdGUgbmV3IGRyYWZ0IHRvIGFkZHJlc3MgdGhpcyBwbGVhc2UgZG8gbWFr ZSBzdXJlIHRvIGNsZWFybHkgZGVmaW5lIHR3byB0aGluZ3M6DQoNCjEuIEhvdyBmb3IgYSBnaXZl biBOTFJJIHdlIGNoYW5nZSBlaXRoZXIgYWN0aW9ucyBvciBncm91cC1pZHMNCg0KMi4gV2hhdCBz aG91bGQgcmVjZWl2ZXIgZG8gd2hlbiBmb3IgYSBnaXZlbiBOTFJJIGhlIHJlY2VpdmVkIG1vcmUg dGhlbiBvbmUgZ3JvdXAtaWQgb3IgbW9yZSB0aGVuIG9uZSBzZXQgb2YgYWN0aW9ucyA/DQoNClRo YW5rcywNClIuDQoNCg0KDQoNCg0KT24gVGh1LCBKdWwgMjcsIDIwMTcgYXQgMTE6MzcgUE0sIEp1 YW4gQWxjYWlkZSAoamFsY2FpZGUpIDxqYWxjYWlkZUBjaXNjby5jb208bWFpbHRvOmphbGNhaWRl QGNpc2NvLmNvbT4+IHdyb3RlOg0KUm9iZXJ0LA0KDQpXZSBtYXkgc3VwcG9ydCBvciBub3Qgc3Vw cG9ydCB1bnN5bmNocm9uaXplZCBjb250cm9sbGVycw0KQnV0IGxldCdzIGFzc3VtZSBmb3IgYSBz ZWNvbmQgd2UgYXJlIGp1c3QgdXNpbmcgb25lIGNvbnRyb2xsZXINCmJ1dCBjYW4gYSBzaW5nbGUg Y29udHJvbGxlciBzZW5kaW5nDQoNCk5MUkkxICsgZ3JvdXAtaWQgMQ0KTkxSSTEgKyBncm91cC1p ZCAyDQoNClRoZSBSUiByZWNlaXZlcyBib3RoIHRoaXMgcm91dGVzIChtdXN0IGJlIEFERC1QQVRI UywgYXMgbWVudGlvbmVkIGluIHRoZSBkcmFmdCkuIFRoZSBSUiBuZWVkcyB0byB1c2UgQURELVBB VEhTIGl0c2VsZiB0byBzZW5kIGl0IHRvIHRoZSBQRSAoZmluYWwgcmVjZWl2ZXIpDQoNCi1KDQoN Cg0KDQoNCk9uIDcvMjcvMjAxNyA5OjQ0IFBNLCBSb2JlcnQgUmFzenVrIHdyb3RlOg0KSGkgSmFr b2IsDQoNClR3byBmbG93c3BlYyByb3V0ZXMgd2l0aCB0aGUgc2FtZSBOTFJJIG1heSBiZSBvcmln aW5hdGVkIGJ5IGRpZmZlcmVudCBzcGVha2Vycy4NCg0KR3JvdXAtaWQgKHNjb3BlZCBhcHBsaWNh dGlvbiBvZiBzcGVjaWZpYyBmbG93LXNwZWMgcnVsZXMpIGlzIGFkZHJlc3NpbmcgYSBzcGVjaWFs IGNhc2Ugd2hlcmUgaXQgaXMgZ2VuZXJhdGVkIGNhcmVmdWxseSBieSBlaXRoZXIgY29udHJvbGxl ciBvciBwcm92aXNpb25pbmcgdG9vbHMuIEkgZG8gbm90IHNlZSB0aGVyZWZvciBhIHByYWN0aWNh bCBjYXNlIHdoZXJlIHRoZSBzYW1lIHN1Y2ggcnVsZSB3b3VsZCBiZSBjb21pbmcgZnJvbSB0d28g b3IgbW9yZSBpbmRlcGVuZGVudCBzb3VyY2VzIGFuZCB3b3VsZCBiZSBhcHBsaWNhYmxlIOKAi3Rv IGRpZmZlcmVudCBpbnRlcmZhY2UgZ3JvdXBzLg0KDQpJdCBzb3VuZHMgbW9yZSBsaWtlIGEgcHJv dG9jb2wgY29uZmxpY3Qgb3IgcHJvdmlzaW9uaW5nIGJ1ZyBhbmQgbm90IHNvbWV0aGluZyB3ZSBz aG91bGQgd29ycnkgYWJvdXQgaG93IHRvIGNhcnJ5IGl0IGFjcm9zcyBSUnMuIFN0YW5kYXJkIHBy b3RvY29sIGJlaGF2aW9yIHdvdWxkIGJlIGZpbmUgaGVyZS4NCg0KTm93IGFsc28gbm90aWNlIHdo YXQgd291bGQgcmVjZWl2ZXIgZG8gLi4uIHRyZWF0IHRoZSBzdWJzZXF1ZW50IHVwZGF0ZSB3aXRo IHRoZSBleGFjdGx5IHNhbWUgTkxSSSBhcyBpbXBsaWNpdCB3aXRoZHJhdyBvciBydW4gYmVzdCBw YXRoIGlmIHRoZXkgY29tZSBmcm9tIGRpZmZlcmVudCBwZWVycyBhbmQgc3RpbGwgYXBwbHkgc2lu Z2xlIG9uZSB0byBsb2NhbCBkYXRhIHBsYW5lLiBTbyByZWFsbHkgdGhlcmUgaXMgbm8gcG9pbnQg dG8gZ2l2ZSBpdCBib3RoIHN1Y2ggcGF0aHMgd2l0aCBBREQtUEFUSHMuIEFzIGl0IGlzIG9uIGZp bmFsIHJlY2VpdmVycyB0aGUgc2FtZSBzaG91bGQgYmUgZG9uZSBvbiBSUnMgLi4uDQoNCuKAi0No ZWVycywNCi8vUlIu4oCLDQoNCg0KVGhlIGZpcnN0IHJvdXRlIHdpbGwgaGF2ZSBvbmUgZ3JvdXAt aWQuIFRoZSBzZWNvbmQgcm91dGUgd2lsbCBoYXZlIGFub3RoZXIgZ3JvdXAtaWQuDQoNClRoYW5r cywNCkpha29iLg0KDQpGcm9tOiBJZHIgW21haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZzxtYWls dG86aWRyLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgUm9iZXJ0IFJhc3p1aw0KU2Vu dDogV2VkbmVzZGF5LCBKdWx5IDI2LCAyMDE3IDQ6MzggUE0NClRvOiBKdWFuIEFsY2FpZGUgKGph bGNhaWRlKSA8amFsY2FpZGVAY2lzY28uY29tPG1haWx0bzpqYWxjYWlkZUBjaXNjby5jb20+Pg0K Q2M6IGlkciB3ZyA8aWRyQGlldGYub3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+Pg0KU3ViamVjdDog UmU6IFtJZHJdIGRyYWZ0LWxpdGtvd3NraS1pZHItZmxvd3NwZWMtaW50ZXJmYWNlc2V0ID0+IE5M UkkgdnMgRVhUQ1QgKHBhcnQgMikNCg0KSGkgSnVhbiwNCg0KPiAgKHdlIGFzc3VtZSBjb250cm9s bGVyKHMpIG1heSBub3Qgd2FudCB0byBzZW5kIG11bHRpcGxlIGV4dC1jb21tdW5pdGllcyB3aXRo IHNhbWUgTkxSSSkuDQoNCklmIEkgcmVjYWxsIGdyb3VwLWlkcyBhcmUgY2FycmllZCBpbiBuZXcg UlQgZm9ybWF0Og0KDQoiVGhpcyBuZXcgQkdQIFJvdXRlIFRhcmdldCBleHRlbmRlZCBjb21tdW5p dHkgaXMgZW5jb2RlZCBhcyBmb2xsb3dzIDoNCg0KICAgICAgIDAgICAgICAgICAgICAgICAgICAg MSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMNCiAgICAgICAwIDEgMiAz IDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEN CiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rDQogICAgICB8ICBUeXBlIChUQkQpICAgfCAgICAgIDB4MDIgICAgIHwg ICAgQXV0b25vbW91cyBTeXN0ZW0gTnVtYmVyICAgOg0KICAgICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgIDog ICAgIEFTIE51bWJlciAoY29udC4pICAgICAgICAgfE98SXwgICAgICBHcm91cCBJZGVudGlmaWVy ICAgICB8DQogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKw0KIg0KDQpTbyBqdXN0IGxpa2UgYW4gVVBEQVRFIG1lc3Nh Z2Ugb2YgU0FGSSAxMjggbWF5IGNvbnRhaW4gbWFueSBSVHMgd2h5IHdvdWxkIHlvdSBzZWUgYW55 DQppc3N1ZSB0byBjYXJyeSBtdWx0aXBsZSBleHQgY29tbXVuaXRpZXMgb2YgdGhlIGFib3ZlIGZv cm1hdCBoZXJlID8NCg0KQmVzdCwNClIuDQoNCk9uIFRodSwgSnVsIDI3LCAyMDE3IGF0IDE6MDEg QU0sIEp1YW4gQWxjYWlkZSAoamFsY2FpZGUpIDxqYWxjYWlkZUBjaXNjby5jb208bWFpbHRvOmph bGNhaWRlQGNpc2NvLmNvbT4+IHdyb3RlOg0KDQpIaSwNCg0KRnJvbSBhIHByZXZpb3VzIHRocmVh ZCwgSSBzZWUgZnJvbSB0aGUgdGhhdCB1c2luZyBFWFRDT01NIHRvIGNhcnJ5IGdyb3VwLWlkIGlu Zm9ybWF0aW9uIHRoZSBjaG9pY2UuIFJlYXNvbiB3YXMgdGhhdCBldmVyeSBBUyBjb3VsZCB1c2Ug dGhlaXIgb3duIHRoZSBncm91cC1pZCAocGVyaGFwcyBkaWZmZXJlbnQgdGhhbiBhbm90aGVyIEFT KS4gV2l0aCB0aGlzIGNob2ljZSwgQURELVBBVEhTIG11c3QgYmUgbWFuZGF0b3J5IGluIG9yZGVy IHRvIHN1cHBvcnQgbXVsdGlwbGUgZ3JvdXAtaWRzIGZvciB0aGUgc2FtZSBmbG93c3BlYyBydWxl ICAod2UgYXNzdW1lIGNvbnRyb2xsZXIocykgbWF5IG5vdCB3YW50IHRvIHNlbmQgbXVsdGlwbGUg ZXh0LWNvbW11bml0aWVzIHdpdGggc2FtZSBOTFJJKS4NCg0KQnV0IHRoZSBkcmFmdCByZWFsbHkg ZG9lcyBub3QgZGVzY3JpYmUgaG93IHRvIHVzZSBBREQtUEFUSFMsIGFuZCBpdCBkb2VzIG5vdCBk aXNjdXNzIGl0cyBwcm9ibGVtczoNCg0KLSBVc3VhbGx5LCBBREQtUEFUSFMgaXMgdXNlZCBmb3Ig cGF0aCBkaXZlcnNpdHksIGFuZCBpbXBsZW1lbnRhdGlvbnMgdHlwaWNhbGx5IGRvbid0IGFkdmVy dGlzZSAyIHBhdGhzIHdpdGggdGhlIHNhbWUgbmV4dC1ob3AgKG90aGVyd2lzZSwgd2UgY291bGQg aGF2ZSBwYXRoIGV4cGxvc2lvbiBhY3Jvc3MgbXVsdGlwbGUgbGV2ZWxzIG9mIFJScykNCg0KLSBJ ZiBBREQtUEFUSFMgaGFzIHRvIGFkdmVydGlzZSB0aGUgc2FtZSBOTFJJIHdpdGggZGlmZmVyZW50 IGV4dC1jb21tdW5pdGllcywgb25lIHNvbHV0aW9uIHdvdWxkIGJlIGZvciBBREQtUEFIVFMgbm90 IGFkdmVydGlzZSB0aGUgc2FtZSBzZXQgb2YgZXh0LWNvbW11bml0aWVzLiBVbmxlc3MsIEkgZ3Vl c3MsIG5leHQtaG9wcyBhcmUgZGlmZmVyZW50LiBPdGhlcndpc2UsIHdlIHdvdWxkIGhhdmUgcGF0 aCBleHBsb3Npb24uDQoNCi0gQXNzdW1pbmcgdGhlIGFib3ZlLCB3ZSBzaG91bGQgZGVmaW5lIGEg cGFydGljdWxhciBzZXQgb2YgQURELVBBVEhTIHJ1bGVzIGZvciBmbG93c3BlYyBBRi4gQW5kLCBv ZiBjb3Vyc2UsIGxlYXZlIHRoZSBkb29yIG9wZW4gZm9yIGZ1dHVyZSBzcGVjaWZpYyBBREQtUEFU SHMgcnVsZXMgZm9yIG90aGVyIEFGcyAoaXQgd291bGQgbm90IGJlIGFib3V0IHBhdGggZGl2ZXJz aXR5IGFueW1vcmUsIGJ1dCBhYm91dCBwcm9wYWdhdGluZyBkaWZmZXJlbnQgaW5mb3JtYXRpb24g Zm9yIGZvcndhcmRpbmcgcHVycG9zZXMgLWltYWdpbmUgd2hhdCB3ZSBjb3VsZCBoYXZlIGRvbmUg d2l0aCBhbiBJUHY0IHByZWZpeDogc2VuZCB0aGUgc2FtZSBuZXQgcGFydCBhcyBhIE5MUkkgYW5k IG11bHRpcGxlIGV4dC1jb21tdW5pdGllcyByZXByZXNlbnRpbmcgZGlmZmVyZW50IHByZWZpeC1s ZW5ndGhzIC0pLg0KDQotIFNpbmNlIHBhdGhzIGluIGEgbmV0IGFyZSB0eXBpY2FsbHkgaW1wbGVt ZW50ZWQgYXMgYSBsaXN0LCB0aGVyZSBjb3VsZCBiZSBzY2FsYWJpbGl0eSBwcm9ibGVtcyBpZiB3 ZSBldmVyIHdhbnQgdG8gc3VwcG9ydCBtYW55IGdyb3VwLWlkcy4NCg0KTXkgc29sdXRpb24gdG8g c2ltcGxpZnkgYWxsIHRoZXNlIHByb2JsZW1zIHdvdWxkIGJlIHRvIGFkZCBhIGRpc2NyaW1pbmF0 b3Igb24gdGhlIE5MUkkgKGJ5IGRlZmluaW5nIGEgbmV3IGR1bW15IHR5cGUgZm9yIGZsb3dzcGVj KS4gV2UgY291bGQgc3RpbGwgdXNlIGV4dC1jb21tdW5pdGllcyB0byBhY3R1YWxseSBtYXRjaCB0 aGUgTkxSSXMgdG8gaW50ZXJmYWNlcy4gU2ltaWxhciB0byBSRCBhbmQgUlQgdXNhZ2UuDQoNClRo b3VnaHRzPw0KDQotSg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KSWRyIG1haWxpbmcgbGlzdA0KSWRyQGlldGYub3JnPG1haWx0bzpJZHJAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0KDQoNCg0KDQoN Cg0K --_000_D5A09F0BBA519aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5XaGF0IHdhcyB0 aGUgcmVhc29uIGZvciBub3QgbWFraW5nIHRoZSBpbnRlcmZhY2UtZ3JvdXAgcGFydCBhIG5ldyBj b21wb25lbnQgdHlwZSBpbiB0aGUgTkxSST8gSXQgc2VlbXMgdGhhdCBtYWtpbmcgaXQganVzdCBh bm90aGVyIEZsb3cgU3BlYyBtYXRjaCBjb25kaXRpb24gd291bGQgJm5ic3A7aGFuZGxlIGFsbCB0 aGVzZSBzaXR1YXRpb25zIG5hdHVyYWxseS4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2PiZuYnNwO0kgcmVtZW1iZXIgdGhhdCB0aGlzIHdhcyBkaXNjdXNzZWQgYnV0IGRvbuKA mXQgcmVjYWxsIHdoZXRoZXIgaXQgd2FzIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgb3IgdGhhdCB0 aGUgc2VtYW50aWNzIG9mIGludGVyZmFjZSBncm91cC1pZCB3YXMgYSBiZXR0ZXIgZml0IGZvciBh biBleHRlbmRlZCBjb21tdW5pdHkuJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp dj5UaGFua3MsPC9kaXY+DQo8ZGl2PkFjZWUmbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1p bHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7 IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBB RERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47 IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25l OyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9t OiA8L3NwYW4+SWRyICZsdDs8YSBocmVmPSJtYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmciPmlk ci1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mIFJvYmVydCBSYXN6dWsgJmx0 OzxhIGhyZWY9Im1haWx0bzpyb2JlcnRAcmFzenVrLm5ldCI+cm9iZXJ0QHJhc3p1ay5uZXQ8L2E+ Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+RnJp ZGF5LCBKdWx5IDI4LCAyMDE3IGF0IDc6NTIgQU08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWln aHQ6Ym9sZCI+VG86IDwvc3Bhbj4mcXVvdDtKdWFuIEFsY2FpZGUgKGphbGNhaWRlKSZxdW90OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOmphbGNhaWRlQGNpc2NvLmNvbSI+amFsY2FpZGVAY2lzY28uY29t PC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj5J RFIgTGlzdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlkckBpZXRmLm9yZyI+aWRyQGlldGYub3JnPC9h PiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFu PlJlOiBbSWRyXSBkcmFmdC1saXRrb3dza2ktaWRyLWZsb3dzcGVjLWludGVyZmFjZXNldCA9Jmd0 OyBOTFJJIHZzIEVYVENUIChwYXJ0IDIpPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxl PSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjow IDAgMCA1OyI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdiBjbGFzcz0iZ21h aWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlm O2ZvbnQtc2l6ZTpzbWFsbCI+DQpIaSBKdWFuLDwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVm YXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQt c2l6ZTpzbWFsbCI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCjxk aXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIg c3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRp bmctbGVmdDoxZXgiPg0KPGRpdiB0ZXh0PSIjMDAwMDAwIiBiZ2NvbG9yPSIjRkZGRkZGIj4NCjxk aXYgY2xhc3M9Im1fLTg3MTAwNjE1MjM5MjEzMzUyMTZtb3otY2l0ZS1wcmVmaXgiPihncm91cC1p ZDogd2hhdCB0byB5b3Ugc3BlY2lmeSBpbiBleHQtY29tbXVuaXR5OyBpbnRlcmZhY2UtZ3JvdXA6 IHdoYXQgeW91IHNwZWNpZnkgdW5kZXIgaW50ZXJmYWNlIGNvbmZpZ3VyYXRpb24pPGJyPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp diBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGlj YSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQrigItPYnZpb3VzLiDigIs8L2Rpdj4NCjxi cj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2lu OjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+ DQo8ZGl2IHRleHQ9IiMwMDAwMDAiIGJnY29sb3I9IiNGRkZGRkYiPg0KPGRpdiBjbGFzcz0ibV8t ODcxMDA2MTUyMzkyMTMzNTIxNm1vei1jaXRlLXByZWZpeCI+SWYgeW91IHVzZSBBREQtUEFUSFMs IHlvdSBjYW4gc2VuZCBpZGVudGljYWwgTkxSSXMgYW5kIHlvdSBjb25zaWRlciB0aGVtIGFzIHZh bGlkIChubyBpbXBsaWNpdCB3aXRoZHJhdyk8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0 IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXpl OnNtYWxsIj4NCuKAi0lmIHlvdXIgY29udHJvbGxlciBvciBtYW5hZ2VtZW50IHN0YXRpb24gZG9l cyBub3Qgc3VwcG9ydCBBREQtUEFUSFMgdGhpcyBpcyBub3QgdGhlIGNhc2UuIE9ubHkgd2hlbiB5 b3UgaGF2ZSBBREQtUEFUSFMgZXZlcnl3aGVyZSB5b3UgbWF5IHBsYXkgdGhhdCBnYW1lLiZuYnNw OzwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFy aWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQo8YnI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2 ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KUmVtZW1iZXIgZmxvdy1zcGVjIHdh cyBkZXNpZ25lZCB0byBiZSBhIEREb1MgbWl0aWdhdGlvbiB0b29sIGFjcm9zcyBBU2VzLiBBY3Jv c3MgQVNlcyBsYXN0IHRpbWUgSSBjaGVja2VkIGRlcGxveW1lbnQgb2YgQURELVBBVEhTIGlzIHpl cm8uIE5vdyBzaW5jZSBzb21lIGZvbGtzIHR1cm5lZCBpdCBpbnRvIGNvbmZpZyBwdXNoIOKAi2lz IG5vdCBzb21ldGhpbmcgb3JpZ2luYWwgNTU3NSBjYW4gYmUgYmxhbWVkIGZvci4mbmJzcDs8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4mbmJzcDs8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJn bWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2Nj IHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiB0ZXh0PSIjMDAwMDAwIiBiZ2NvbG9yPSIj RkZGRkZGIj4NCjxkaXYgY2xhc3M9Im1fLTg3MTAwNjE1MjM5MjEzMzUyMTZtb3otY2l0ZS1wcmVm aXgiPlRoZXJlIGlzIGEgcmVxdWlyZW1lbnQgdGhhdCB0aGUgc2FtZSBmbG93c3BlYyBydWxlLCBj b3VsZCBiZSB1c2VkIGZvciAyIGRpZmZlcmVudCBpbnRlcmZhY2UtZ3JvdXBzIChsZXQncyBzYXkg aW50ZXJmYWNlcyBjdXN0b21lci1mYWNpbmcgYW5kIGludGVyZmFjZXMgcHJvdmlkZXItZmFjaW5n KS4gQnV0IGFsc28geW91IG1heSB3YW50IHRvIHVzZSBkaWZmZXJlbnQNCiBhY3Rpb25zIGJhc2Vk IG9uIHRoZSBncm91cC1pZCAoc2VjdGlvbiA4IG9mIHRoZSBkcmFmdCk8YnI+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGNsYXNz PSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMt c2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCuKAi1RoYXQgaXMganVzdCBvcGVyYXRpb25hbCBtZXNz LiBUbyBkbyB0aGF0IHlvdSBjYW4gdXNlIFNBRkkgMTM0IHdoZXJlIDggb2N0ZXQgUkQgaXMgcGFy dCBvZiB0aGUgTkxSSSB3aGF0IG1ha2VzIE5MUkkgdW5pcXVlLiZuYnNwOzwvZGl2Pg0KPGJyPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAw IDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxk aXYgdGV4dD0iIzAwMDAwMCIgYmdjb2xvcj0iI0ZGRkZGRiI+DQo8ZGl2IGNsYXNzPSJtXy04NzEw MDYxNTIzOTIxMzM1MjE2bW96LWNpdGUtcHJlZml4Ij5JIHRoaW5rIHdlIGJhc2ljYWxseSBuZWVk IHRvIGV4cGFuZC9jbGFyaWZ5IHRoZSBBREQtUEFUSFMgcGFydC4gUmVnYXJkaW5nIHlvdXIgcG9p bnRzOjxicj4NCjEuIEZvciBhIGdpdmVuIE5MUkksIHdlIGNoYW5nZSBncm91cC1pZHMgb3IgYWN0 aW9ucyBiYXNlZCBvbiB3aGF0IHdlIHdhbnQgdG8gYWNoaWV2ZS4gU28gaXQncyBiYXNlZCBvbiBo b3cgY3VzdG9tZXIgc2V0cyB0aGUgcnVsZSBpbiB0aGUgY29udHJvbGxlci4gVGhlcmUgbWF5IGJl IGEgbmVlZCB0byBzZW5kIHNhbWUgTkxSSSB3aXRoIDIgZGlmZmVyZW50IHNldHMgb2YgYWN0aW9u JiM0Mztncm91cC1pZDxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250 LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0K4oCL SSB0aGluayBkb2luZyB0aGlzIGluIHN1Y2ggd2F5IGlzIHZlcnkgbWVzc3kuIFB1c2hpbmcgRlMg cm91dGVzIHdpdGggUkQgYXMgaW5kaWNhdGVkIGFib3ZlIGlzIG11Y2ggY2xlYW5lciBpZiB0aGVy ZSBzdWNoIG5lZWQgdG8gYXBwbHkgZGlmZmVyZW50IGFjdGlvbnMgb3IgZ3JvdXAgSURzIGZvciB0 aGUgc2FtZSBOTFJJcy4g4oCLPC9kaXY+DQo8L2Rpdj4NCjxkaXY+Jm5ic3A7PGJyPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhl eDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgdGV4 dD0iIzAwMDAwMCIgYmdjb2xvcj0iI0ZGRkZGRiI+DQo8ZGl2IGNsYXNzPSJtXy04NzEwMDYxNTIz OTIxMzM1MjE2bW96LWNpdGUtcHJlZml4Ij4yLiBJZiByZWNlaXZlciByZWNlaXZlcyBtb3JlIHRo YW4gb25lIGdyb3VwLWlkLCBpdCBzaG91bGQgYXBwbHkgYWxsIHRoZSBhY3Rpb25zIHNwZWNpZmll ZCB0byAqYWxsKiB0aGUgaW50ZXJmYWNlLWdyb3VwIGFzc29jaWF0ZWQgdG8gYWxsIHRoZSBncm91 cC1pZHMgaXQgcmVjZWl2ZWQuIERyYWZ0IGRvZXMgZXhwbGljaXRseSBzYXkgd2hhdCB0byBkbyB3 aGVuDQogeW91IHJlY2VpdmUgYSBOTFJJIHdpdGggbXVsdGlwbGUgZ3JvdXAtaWRzLCBidXQgSSB0 aGluayBpdCBzaG91bGQgYmUgYXBwbGllZCB0byBhbGwgaW50ZXJmYWNlLWdyb3VwcyAocHJvYmFi bHkgaXQgc2hvdWxkIGJlIGNsYXJpZmllZCk8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHls ZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxs Ij4NCuKAi29rLjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQt ZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQo8YnI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTph cmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KVGh4LDwvZGl2Pg0K PGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZl dGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQpSLuKAizwvZGl2Pg0KPGJyPg0KPC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxibG9ja3F1b3RlIGNs YXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFw eCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiB0ZXh0PSIjMDAwMDAwIiBiZ2Nv bG9yPSIjRkZGRkZGIj4NCjxkaXYgY2xhc3M9Im1fLTg3MTAwNjE1MjM5MjEzMzUyMTZtb3otY2l0 ZS1wcmVmaXgiPjxzcGFuIGNsYXNzPSJIT0VuWmIiPjxmb250IGNvbG9yPSIjODg4ODg4Ij48YnI+ DQo8YnI+DQotSjwvZm9udD48L3NwYW4+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iaDUiPjxicj4NCjxi cj4NCjxicj4NCjxicj4NCk9uIDcvMjcvMjAxNyAxMTo0MyBQTSwgUm9iZXJ0IFJhc3p1ayB3cm90 ZTo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iaDUiPg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXYgc3R5bGU9ImZv bnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+SnVh biw8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNl cmlmO2ZvbnQtc2l6ZTpzbWFsbCI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWls eTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPlNlbmRpbmcgZnJv bSBzaW5nbGUgY29udHJvbGxlciAoc2luZ2xlIEJHUCBwZWVyKSB0d28gdXBkYXRlcyB3aXRoIGlk ZW50aWNhbCBOTFJJcyBpcyBhbiBpbXBsaWNpdCB3aXRoZHJhdy4gQURELVBBVEhzIGhhcyBub3Ro aW5nIHRvIGhlcmUuJm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxo ZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPjxicj4NCjwvZGl2Pg0KPGRpdiBz dHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNt YWxsIj5MaWtld2lzZSBSUiBzaG91bGQgdHJlYXQgaXMgYXMgaW1wbGljaXQgd2l0aGRyYXcgb2Yg dGhlIHByZXZpb3VzIG9uZSB0b28uJm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWls eTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPjxicj4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9u dC1zaXplOnNtYWxsIj5JZiB5b3UgZ28gYnkgeW91ciBsaW5lIG9mIHRoaW5raW5nIHdoYXQgd291 bGQgbWFrZSBjb250cm9sbGVyIHRvIGNoYW5nZSBmb3IgZ2l2ZW4gTkxSSTEgZ3JvdXAtaWQgMSB0 byBncm91cC1pZCAyIGlmIHRoZXJlIGlzIG5lZWQgdG8gZG8gc28gPyZuYnNwOzwvZGl2Pg0KPGRp diBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXpl OnNtYWxsIj48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZl dGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+SW4gYW55IGNhc2UgaWYgeW91IGRlY2lk ZSB0byBhZGQgYWRkaXRpb25hbCB0ZXh0IHRvIHRoZSBjdXJyZW50IGRyYWZ0IG9yIGRlY2lkZSB0 byB3cml0ZSBuZXcgZHJhZnQgdG8gYWRkcmVzcyB0aGlzIHBsZWFzZSBkbyBtYWtlIHN1cmUgdG8g Y2xlYXJseSBkZWZpbmUgdHdvIHRoaW5nczo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+PGJyPg0KPC9kaXY+ DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250 LXNpemU6c21hbGwiPjEuIEhvdyBmb3IgYSBnaXZlbiBOTFJJIHdlIGNoYW5nZSBlaXRoZXIgYWN0 aW9ucyBvciBncm91cC1pZHMmbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OmFy aWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+PGJyPg0KPC9kaXY+DQo8 ZGl2IHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNp emU6c21hbGwiPjIuIFdoYXQgc2hvdWxkIHJlY2VpdmVyIGRvIHdoZW4gZm9yIGEgZ2l2ZW4gTkxS SSBoZSByZWNlaXZlZCBtb3JlIHRoZW4gb25lIGdyb3VwLWlkIG9yIG1vcmUgdGhlbiBvbmUgc2V0 IG9mIGFjdGlvbnMgPyZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWws aGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj48YnI+DQo8L2Rpdj4NCjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpz bWFsbCI+VGhhbmtzLDwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0 aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj5SLjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9u dC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj48YnI+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNl cmlmO2ZvbnQtc2l6ZTpzbWFsbCI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWls eTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPjxicj4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9u dC1zaXplOnNtYWxsIj48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0 cmEiPjxicj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBUaHUsIEp1bCAyNywgMjAxNyBh dCAxMTozNyBQTSwgSnVhbiBBbGNhaWRlIChqYWxjYWlkZSkNCjxzcGFuIGRpcj0ibHRyIj4mbHQ7 PGEgaHJlZj0ibWFpbHRvOmphbGNhaWRlQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmphbGNh aWRlQGNpc2NvLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+DQo8YmxvY2txdW90ZSBjbGFz cz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHgg I2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgdGV4dD0iIzAwMDAwMCIgYmdjb2xv cj0iI0ZGRkZGRiI+DQo8ZGl2IGNsYXNzPSJtXy04NzEwMDYxNTIzOTIxMzM1MjE2bV81NDI4MTcy MjI5NzIzNzIwMzA2bW96LWNpdGUtcHJlZml4Ij5Sb2JlcnQsPGJyPg0KPGJyPg0KV2UgbWF5IHN1 cHBvcnQgb3Igbm90IHN1cHBvcnQgdW5zeW5jaHJvbml6ZWQgY29udHJvbGxlcnM8YnI+DQpCdXQg bGV0J3MgYXNzdW1lIGZvciBhIHNlY29uZCB3ZSBhcmUganVzdCB1c2luZyBvbmUgY29udHJvbGxl cjxicj4NCmJ1dCBjYW4gYSBzaW5nbGUgY29udHJvbGxlciBzZW5kaW5nPGJyPg0KPGJyPg0KTkxS STEgJiM0MzsgZ3JvdXAtaWQgMTxicj4NCk5MUkkxICYjNDM7IGdyb3VwLWlkIDI8YnI+DQo8YnI+ DQpUaGUgUlIgcmVjZWl2ZXMgYm90aCB0aGlzIHJvdXRlcyAobXVzdCBiZSBBREQtUEFUSFMsIGFz IG1lbnRpb25lZCBpbiB0aGUgZHJhZnQpLiBUaGUgUlIgbmVlZHMgdG8gdXNlIEFERC1QQVRIUyBp dHNlbGYgdG8gc2VuZCBpdCB0byB0aGUgUEUgKGZpbmFsIHJlY2VpdmVyKTxzcGFuIGNsYXNzPSJt Xy04NzEwMDYxNTIzOTIxMzM1MjE2SE9FblpiIj48Zm9udCBjb2xvcj0iIzg4ODg4OCI+PGJyPg0K PGJyPg0KLUo8L2ZvbnQ+PC9zcGFuPg0KPGRpdj4NCjxkaXYgY2xhc3M9Im1fLTg3MTAwNjE1MjM5 MjEzMzUyMTZoNSI+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KT24gNy8yNy8yMDE3IDk6NDQgUE0s IFJvYmVydCBSYXN6dWsgd3JvdGU6PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXYgY2xhc3M9Im1fLTg3MTAwNjE1MjM5MjEzMzUyMTZoNSI+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWws aGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj5IaSBKYWtvYiw8L2Rpdj4NCjxk aXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj48YnI+DQo8 YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDti b3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSIgbGFuZz0iRU4tVVMiPg0KPGRpdiBjbGFzcz0ibV8tODcxMDA2 MTUyMzkyMTMzNTIxNm1fNTQyODE3MjIyOTcyMzcyMDMwNm1fLTcyNDM4Njk0OTU4MjAwMTkwMTdX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4+VHdvIGZsb3dzcGVjIHJv dXRlcyB3aXRoIHRoZSBzYW1lIE5MUkkgbWF5IGJlIG9yaWdpbmF0ZWQgYnkgZGlmZmVyZW50IHNw ZWFrZXJzLjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRp Y2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPkdyb3VwLWlkIChzY29wZWQgYXBwbGljYXRp b24gb2Ygc3BlY2lmaWMgZmxvdy1zcGVjIHJ1bGVzKSBpcyBhZGRyZXNzaW5nIGEgc3BlY2lhbCBj YXNlIHdoZXJlIGl0IGlzIGdlbmVyYXRlZCBjYXJlZnVsbHkgYnkgZWl0aGVyIGNvbnRyb2xsZXIg b3IgcHJvdmlzaW9uaW5nIHRvb2xzLiBJIGRvIG5vdCBzZWUgdGhlcmVmb3IgYSBwcmFjdGljYWwN CiBjYXNlIHdoZXJlIHRoZSBzYW1lIHN1Y2ggcnVsZSB3b3VsZCBiZSBjb21pbmcgZnJvbSB0d28g b3IgbW9yZSBpbmRlcGVuZGVudCBzb3VyY2VzIGFuZCB3b3VsZCBiZSBhcHBsaWNhYmxlIOKAi3Rv IGRpZmZlcmVudCBpbnRlcmZhY2UgZ3JvdXBzLiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9u dC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj48YnI+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNl cmlmO2ZvbnQtc2l6ZTpzbWFsbCI+SXQgc291bmRzIG1vcmUgbGlrZSBhIHByb3RvY29sIGNvbmZs aWN0IG9yIHByb3Zpc2lvbmluZyBidWcgYW5kIG5vdCBzb21ldGhpbmcgd2Ugc2hvdWxkIHdvcnJ5 IGFib3V0IGhvdyB0byBjYXJyeSBpdCBhY3Jvc3MgUlJzLiBTdGFuZGFyZCBwcm90b2NvbCBiZWhh dmlvciB3b3VsZCBiZSBmaW5lIGhlcmUuPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTph cmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPjxicj4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1z aXplOnNtYWxsIj5Ob3cgYWxzbyBub3RpY2Ugd2hhdCB3b3VsZCByZWNlaXZlciBkbyAuLi4gdHJl YXQgdGhlIHN1YnNlcXVlbnQgdXBkYXRlIHdpdGggdGhlIGV4YWN0bHkgc2FtZSBOTFJJIGFzIGlt cGxpY2l0IHdpdGhkcmF3IG9yIHJ1biBiZXN0IHBhdGggaWYgdGhleSBjb21lIGZyb20gZGlmZmVy ZW50IHBlZXJzIGFuZCBzdGlsbCBhcHBseSBzaW5nbGUNCiBvbmUgdG8gbG9jYWwgZGF0YSBwbGFu ZS4gU28gcmVhbGx5IHRoZXJlIGlzIG5vIHBvaW50IHRvIGdpdmUgaXQgYm90aCBzdWNoIHBhdGhz IHdpdGggQURELVBBVEhzLiBBcyBpdCBpcyBvbiBmaW5hbCByZWNlaXZlcnMgdGhlIHNhbWUgc2hv dWxkIGJlIGRvbmUgb24gUlJzIC4uLiZuYnNwOzwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1z aXplOnNtYWxsIj7igItDaGVlcnMsPGJyPg0KLy9SUi7igIs8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxf cXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xp ZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgbGFu Zz0iRU4tVVMiPg0KPGRpdiBjbGFzcz0ibV8tODcxMDA2MTUyMzkyMTMzNTIxNm1fNTQyODE3MjIy OTcyMzcyMDMwNm1fLTcyNDM4Njk0OTU4MjAwMTkwMTdXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu PlRoZSBmaXJzdCByb3V0ZSB3aWxsIGhhdmUgb25lIGdyb3VwLWlkLiBUaGUgc2Vjb25kIHJvdXRl IHdpbGwgaGF2ZSBhbm90aGVyIGdyb3VwLWlkLjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3Bhbj4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4+ VGhhbmtzLDwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bhbj5KYWtvYi48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4+Jm5ic3A7PC9zcGFuPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjZTFlMWUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4gSWRyIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmlkci1ib3VuY2Vz QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aWRyLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+ T24gQmVoYWxmIE9mIDwvYj5Sb2JlcnQgUmFzenVrPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2Rh eSwgSnVseSAyNiwgMjAxNyA0OjM4IFBNPGJyPg0KPGI+VG86PC9iPiBKdWFuIEFsY2FpZGUgKGph bGNhaWRlKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmphbGNhaWRlQGNpc2NvLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPmphbGNhaWRlQGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBpZHIgd2cg Jmx0OzxhIGhyZWY9Im1haWx0bzppZHJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pZHJAaWV0 Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0lkcl0gZHJhZnQtbGl0a293 c2tpLWlkci1mbG93c3BlYy1pPHdicj5udGVyZmFjZXNldCA9Jmd0OyBOTFJJIHZzIEVYVENUIChw YXJ0IDIpPC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0ibV8t ODcxMDA2MTUyMzkyMTMzNTIxNm1fNTQyODE3MjIyOTcyMzcyMDMwNmg1Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkhp IEp1YW4sPC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mbmJz cDs8L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmbmJz cDsmbmJzcDsod2UgYXNzdW1lIGNvbnRyb2xsZXIocykgbWF5IG5vdCB3YW50IHRvIHNlbmQgbXVs dGlwbGUgZXh0LWNvbW11bml0aWVzIHdpdGggc2FtZSBOTFJJKS48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+SWYgSSByZWNhbGwgZ3JvdXAtaWRzIGFyZSBjYXJyaWVk IGluIG5ldyBSVCBmb3JtYXQ6Jm5ic3A7PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWYiPiZxdW90O1RoaXMgbmV3IEJHUCBSb3V0ZSBUYXJnZXQgZXh0ZW5kZWQgY29tbXVu aXR5IGlzIGVuY29kZWQgYXMgZm9sbG93cyA6PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3Bhbj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDswICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IDEgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgMiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAzPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmIj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7MCAxIDIgMyA0 IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxPC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuPiZuYnNw OyAmbmJzcDsgJm5ic3A7ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LTx3YnI+JiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstPHdicj4mIzQzOy0mIzQzOy0mIzQzOzwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bhbj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyB8ICZuYnNwO1R5cGUgKFRCRCkgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAm bmJzcDsweDAyICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7QXV0b25vbW91cyBTeXN0ZW0g TnVtYmVyICZuYnNwOyA6PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LTx3YnI+JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstPHdicj4mIzQz Oy0mIzQzOy0mIzQzOzwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3Bhbj4mbmJzcDsgJm5ic3A7ICZuYnNwOyA6ICZuYnNwOyAmbmJzcDsgQVMgTnVtYmVy IChjb250LikgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHxPfEl8ICZuYnNwOyAmbmJzcDsg Jm5ic3A7R3JvdXAgSWRlbnRpZmllciAmbmJzcDsgJm5ic3A7IHw8L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstPHdicj4mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy08d2JyPiYjNDM7LSYjNDM7LSYjNDM7PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuPiZxdW90Ozwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlNvIGp1c3QgbGlrZSBhbiBVUERBVEUg bWVzc2FnZSBvZiBTQUZJIDEyOCBtYXkgY29udGFpbiBtYW55IFJUcyB3aHkgd291bGQgeW91IHNl ZSBhbnkmbmJzcDs8L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYi Pmlzc3VlIHRvIGNhcnJ5IG11bHRpcGxlIGV4dCBjb21tdW5pdGllcyBvZiB0aGUgYWJvdmUgZm9y bWF0IGhlcmUgPyZuYnNwOzwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZiI+Jm5ic3A7PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm Ij5CZXN0LDwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Ui48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBKdWwgMjcsIDIw MTcgYXQgMTowMSBBTSwgSnVhbiBBbGNhaWRlIChqYWxjYWlkZSkgJmx0OzxhIGhyZWY9Im1haWx0 bzpqYWxjYWlkZUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5qYWxjYWlkZUBjaXNjby5jb208 L2E+Jmd0OyB3cm90ZTo8L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI2NjY2NjYyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0Ij5IaSw8L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQiPkZyb20gYSBwcmV2aW91cyB0aHJlYWQsIEkgc2VlIGZyb20gdGhlIHRoYXQgdXNp bmcgRVhUQ09NTSB0byBjYXJyeSBncm91cC1pZCBpbmZvcm1hdGlvbiB0aGUgY2hvaWNlLiBSZWFz b24gd2FzIHRoYXQgZXZlcnkgQVMgY291bGQgdXNlIHRoZWlyIG93biB0aGUgZ3JvdXAtaWQgKHBl cmhhcHMgZGlmZmVyZW50IHRoYW4gYW5vdGhlciBBUykuIFdpdGggdGhpcyBjaG9pY2UsIEFERC1Q QVRIUw0KIG11c3QgYmUgbWFuZGF0b3J5IGluIG9yZGVyIHRvIHN1cHBvcnQgbXVsdGlwbGUgZ3Jv dXAtaWRzIGZvciB0aGUgc2FtZSBmbG93c3BlYyBydWxlJm5ic3A7ICh3ZSBhc3N1bWUgY29udHJv bGxlcihzKSBtYXkgbm90IHdhbnQgdG8gc2VuZCBtdWx0aXBsZSBleHQtY29tbXVuaXRpZXMgd2l0 aCBzYW1lIE5MUkkpLjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dCI+QnV0IHRoZSBkcmFmdCByZWFsbHkgZG9lcyBub3QgZGVzY3JpYmUgaG93IHRvIHVzZSBBREQt UEFUSFMsIGFuZCBpdCBkb2VzIG5vdCBkaXNjdXNzIGl0cyBwcm9ibGVtczo8L3NwYW4+PC9wPg0K PHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPi0gVXN1YWxseSwgQURELVBBVEhTIGlz IHVzZWQgZm9yIHBhdGggZGl2ZXJzaXR5LCBhbmQgaW1wbGVtZW50YXRpb25zIHR5cGljYWxseSBk b24ndCBhZHZlcnRpc2UgMiBwYXRocyB3aXRoIHRoZSBzYW1lIG5leHQtaG9wIChvdGhlcndpc2Us IHdlIGNvdWxkIGhhdmUgcGF0aCBleHBsb3Npb24gYWNyb3NzIG11bHRpcGxlIGxldmVscyBvZiBS UnMpPC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4tIElmIEFE RC1QQVRIUyBoYXMgdG8gYWR2ZXJ0aXNlIHRoZSBzYW1lIE5MUkkgd2l0aCBkaWZmZXJlbnQgZXh0 LWNvbW11bml0aWVzLCBvbmUgc29sdXRpb24gd291bGQgYmUgZm9yIEFERC1QQUhUUyBub3QgYWR2 ZXJ0aXNlIHRoZSBzYW1lIHNldCBvZiBleHQtY29tbXVuaXRpZXMuIFVubGVzcywgSSBndWVzcywg bmV4dC1ob3BzIGFyZSBkaWZmZXJlbnQuIE90aGVyd2lzZSwgd2Ugd291bGQNCiBoYXZlIHBhdGgg ZXhwbG9zaW9uLjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+ LSBBc3N1bWluZyB0aGUgYWJvdmUsIHdlIHNob3VsZCBkZWZpbmUgYSBwYXJ0aWN1bGFyIHNldCBv ZiBBREQtUEFUSFMgcnVsZXMgZm9yIGZsb3dzcGVjIEFGLiBBbmQsIG9mIGNvdXJzZSwgbGVhdmUg dGhlIGRvb3Igb3BlbiBmb3IgZnV0dXJlIHNwZWNpZmljIEFERC1QQVRIcyBydWxlcyBmb3Igb3Ro ZXIgQUZzIChpdCB3b3VsZCBub3QgYmUgYWJvdXQgcGF0aCBkaXZlcnNpdHkgYW55bW9yZSwNCiBi dXQgYWJvdXQgcHJvcGFnYXRpbmcgZGlmZmVyZW50IGluZm9ybWF0aW9uIGZvciBmb3J3YXJkaW5n IHB1cnBvc2VzIC1pbWFnaW5lIHdoYXQgd2UgY291bGQgaGF2ZSBkb25lIHdpdGggYW4gSVB2NCBw cmVmaXg6IHNlbmQgdGhlIHNhbWUgbmV0IHBhcnQgYXMgYSBOTFJJIGFuZCBtdWx0aXBsZSBleHQt Y29tbXVuaXRpZXMgcmVwcmVzZW50aW5nIGRpZmZlcmVudCBwcmVmaXgtbGVuZ3RocyAtKS48L3Nw YW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPi0gU2luY2UgcGF0aHMg aW4gYSBuZXQgYXJlIHR5cGljYWxseSBpbXBsZW1lbnRlZCBhcyBhIGxpc3QsIHRoZXJlIGNvdWxk IGJlIHNjYWxhYmlsaXR5IHByb2JsZW1zIGlmIHdlIGV2ZXIgd2FudCB0byBzdXBwb3J0IG1hbnkg Z3JvdXAtaWRzLjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+ TXkgc29sdXRpb24gdG8gc2ltcGxpZnkgYWxsIHRoZXNlIHByb2JsZW1zIHdvdWxkIGJlIHRvIGFk ZCBhIGRpc2NyaW1pbmF0b3Igb24gdGhlIE5MUkkgKGJ5IGRlZmluaW5nIGEgbmV3IGR1bW15IHR5 cGUgZm9yIGZsb3dzcGVjKS4gV2UgY291bGQgc3RpbGwgdXNlIGV4dC1jb21tdW5pdGllcyB0byBh Y3R1YWxseSBtYXRjaCB0aGUgTkxSSXMgdG8gaW50ZXJmYWNlcy4gU2ltaWxhciB0byBSRA0KIGFu ZCBSVCB1c2FnZS48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQi PlRob3VnaHRzPzwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtj b2xvcjojODg4ODg4Ij4tSjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX188d2JyPl9fX19fX19f X19fX19fX19fPGJyPg0KSWRyIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJZHJA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5JZHJAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHIiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2w8d2JyPmlzdGluZm8vaWRyPC9hPjwvcD4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHA+PGJy Pg0KPC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 YnI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwPjxicj4NCjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D5A09F0BBA519aceeciscocom_-- From nobody Fri Jul 28 05:15:39 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42088131FD7 for ; Fri, 28 Jul 2017 05:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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 sFgF5qp-dbWt for ; Fri, 28 Jul 2017 05:15:33 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::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 411DD131FC8 for ; Fri, 28 Jul 2017 05:15:33 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id l7so89787106iof.1 for ; Fri, 28 Jul 2017 05:15:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=jPZNimJgKo4afKW5vqBT6IzDFP/NcM8N7T3U2yQjiUc=; b=Wsxzib0Jg17iD66fEuFSDOcyrV/VRj17nMGMOQD3u/gVwsg7IFde3ar9d1sKi+1yXz Ddh+ejoQ/lMzzoaXUcv0kdBt8yxAPAzvyVLzDRCqmmFhUca9fKGsuMf2v7fi/L+EqtDq K2y9zMF4pQJhnEl/dtwqeTDl+E4OUYgRWamh3ktKqMjzIwBLv7xboO4X7Yo/Obkr+ZEq V454zqhYkQl4KZ0IReh+y+r0kTMx1RBA7j3W1EUnW6rWAQp8tfyf+CEb31O8yhJKO9gE YFfoZ9f8b2fSCen6sLny6dJH/h1xkHrBzS6dfXX053MuA6aI3X/fFmMXf5xOEZwLnCoz V1/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=jPZNimJgKo4afKW5vqBT6IzDFP/NcM8N7T3U2yQjiUc=; b=SzUexYfol9tFyQun6vn6Iw8n322m7a9w1U0tPgf56jQpV/mVXAgUDFrKeZkco27dRQ abnLqPpfcyyRy5uqIw8BU1ACVW0D2i0zqKf4oXcwi/wEFrUjjGeSHXdfQnNxuBeL/BoO epOxif7npm2sIFjDCatpHfIQT/Wfdxda1BQPrOgp9gyhtaIdPMroDPune3wxTfmX8v9C ykm62lqfEJYnBGMZcnN8R0NNstwPkX77NFiHfeSetebMHwlnJJYWeeH6IVhbXJzOeXTn 8RwMsThZcQw2E2TN6/tFtvEK2PobDf7R0s8rfj6YsnJr1fw6ozJ8459CInY8p4CxCQtw Finw== X-Gm-Message-State: AIVw110GtBZk2irzaO4D6NqwJ7nzE++NgAdp1KT6GtBK9hVUnD77oGT3 K3eLm6F72hSxEjEwtCZdjeZtruLE0kn2 X-Received: by 10.107.157.9 with SMTP id g9mr9626558ioe.46.1501244132355; Fri, 28 Jul 2017 05:15:32 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.153.21 with HTTP; Fri, 28 Jul 2017 05:15:31 -0700 (PDT) In-Reply-To: References: <9fa67eb0-8f99-a46f-aff1-d42a279ab833@cisco.com> <8dd3e766b58944a3b176fc743e478137@XCH-ALN-014.cisco.com> From: Robert Raszuk Date: Fri, 28 Jul 2017 14:15:31 +0200 X-Google-Sender-Auth: J-sy5oloAKqLDShGDpMT7e4Uklo Message-ID: To: "Acee Lindem (acee)" Cc: "Juan Alcaide (jalcaide)" , idr wg Content-Type: multipart/alternative; boundary="001a1140c5c63af86905555fa3b9" Archived-At: Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT (part 2) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 12:15:37 -0000 --001a1140c5c63af86905555fa3b9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable To change format of NLRI you need essentially a new SAFI. Clearly an option for this new draft, but I think authors never envisioned that given set of match rules should have different actions depending on the arriving interfaces for traffic matching such rules. If at all I would recommend it to move it to flowspec v2 discussion. It is in fact very wired and quite bad to treat on the same router the same traffic differently based on the direction it arrives ... clearly out of scope of original 5575. The config push part indeed can be interface scoped, but is BGP really a right tool for this ? Cheers, R. On Fri, Jul 28, 2017 at 2:02 PM, Acee Lindem (acee) wrote: > What was the reason for not making the interface-group part a new > component type in the NLRI? It seems that making it just another Flow Spe= c > match condition would handle all these situations naturally. > > I remember that this was discussed but don=E2=80=99t recall whether it w= as > backward compatibility or that the semantics of interface group-id was a > better fit for an extended community. > > Thanks, > Acee > > From: Idr on behalf of Robert Raszuk < > robert@raszuk.net> > Date: Friday, July 28, 2017 at 7:52 AM > To: "Juan Alcaide (jalcaide)" > Cc: IDR List > > Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset =3D> NLRI vs > EXTCT (part 2) > > Hi Juan, > > (group-id: what to you specify in ext-community; interface-group: what yo= u >> specify under interface configuration) >> > > =E2=80=8BObvious. =E2=80=8B > > If you use ADD-PATHS, you can send identical NLRIs and you consider them >> as valid (no implicit withdraw) >> > > =E2=80=8BIf your controller or management station does not support ADD-PA= THS this > is not the case. Only when you have ADD-PATHS everywhere you may play tha= t > game. > > Remember flow-spec was designed to be a DDoS mitigation tool across ASes. > Across ASes last time I checked deployment of ADD-PATHS is zero. Now sinc= e > some folks turned it into config push =E2=80=8Bis not something original = 5575 can > be blamed for. > > >> There is a requirement that the same flowspec rule, could be used for 2 >> different interface-groups (let's say interfaces customer-facing and >> interfaces provider-facing). But also you may want to use different acti= ons >> based on the group-id (section 8 of the draft) >> > > =E2=80=8BThat is just operational mess. To do that you can use SAFI 134 w= here 8 > octet RD is part of the NLRI what makes NLRI unique. > > I think we basically need to expand/clarify the ADD-PATHS part. Regarding >> your points: >> 1. For a given NLRI, we change group-ids or actions based on what we wan= t >> to achieve. So it's based on how customer sets the rule in the controlle= r. >> There may be a need to send same NLRI with 2 different sets of >> action+group-id >> > > =E2=80=8BI think doing this in such way is very messy. Pushing FS routes = with RD > as indicated above is much cleaner if there such need to apply different > actions or group IDs for the same NLRIs. =E2=80=8B > > >> 2. If receiver receives more than one group-id, it should apply all the >> actions specified to *all* the interface-group associated to all the >> group-ids it received. Draft does explicitly say what to do when you >> receive a NLRI with multiple group-ids, but I think it should be applied= to >> all interface-groups (probably it should be clarified) >> > > =E2=80=8Bok. > > Thx, > R.=E2=80=8B > > > > >> >> >> -J >> >> >> >> >> On 7/27/2017 11:43 PM, Robert Raszuk wrote: >> >> Juan, >> >> Sending from single controller (single BGP peer) two updates with >> identical NLRIs is an implicit withdraw. ADD-PATHs has nothing to here. >> >> Likewise RR should treat is as implicit withdraw of the previous one too= . >> >> If you go by your line of thinking what would make controller to change >> for given NLRI1 group-id 1 to group-id 2 if there is need to do so ? >> >> In any case if you decide to add additional text to the current draft or >> decide to write new draft to address this please do make sure to clearly >> define two things: >> >> 1. How for a given NLRI we change either actions or group-ids >> >> 2. What should receiver do when for a given NLRI he received more then >> one group-id or more then one set of actions ? >> >> Thanks, >> R. >> >> >> >> >> >> On Thu, Jul 27, 2017 at 11:37 PM, Juan Alcaide (jalcaide) < >> jalcaide@cisco.com> wrote: >> >>> Robert, >>> >>> We may support or not support unsynchronized controllers >>> But let's assume for a second we are just using one controller >>> but can a single controller sending >>> >>> NLRI1 + group-id 1 >>> NLRI1 + group-id 2 >>> >>> The RR receives both this routes (must be ADD-PATHS, as mentioned in th= e >>> draft). The RR needs to use ADD-PATHS itself to send it to the PE (fina= l >>> receiver) >>> >>> -J >>> >>> >>> >>> >>> On 7/27/2017 9:44 PM, Robert Raszuk wrote: >>> >>> Hi Jakob, >>> >>> Two flowspec routes with the same NLRI may be originated by different >>>> speakers. >>>> >>> >>> Group-id (scoped application of specific flow-spec rules) is addressing >>> a special case where it is generated carefully by either controller or >>> provisioning tools. I do not see therefor a practical case where the sa= me >>> such rule would be coming from two or more independent sources and woul= d be >>> applicable =E2=80=8Bto different interface groups. >>> >>> It sounds more like a protocol conflict or provisioning bug and not >>> something we should worry about how to carry it across RRs. Standard >>> protocol behavior would be fine here. >>> >>> Now also notice what would receiver do ... treat the subsequent update >>> with the exactly same NLRI as implicit withdraw or run best path if the= y >>> come from different peers and still apply single one to local data plan= e. >>> So really there is no point to give it both such paths with ADD-PATHs. = As >>> it is on final receivers the same should be done on RRs ... >>> >>> =E2=80=8BCheers, >>> //RR.=E2=80=8B >>> >>> >>> >>>> The first route will have one group-id. The second route will have >>>> another group-id. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Jakob. >>>> >>>> >>>> >>>> *From:* Idr [mailto:idr-bounces@ietf.org] *On Behalf Of *Robert Raszuk >>>> *Sent:* Wednesday, July 26, 2017 4:38 PM >>>> *To:* Juan Alcaide (jalcaide) >>>> *Cc:* idr wg >>>> *Subject:* Re: [Idr] draft-litkowski-idr-flowspec-interfaceset =3D> NL= RI >>>> vs EXTCT (part 2) >>>> >>>> >>>> >>>> Hi Juan, >>>> >>>> >>>> >>>> > (we assume controller(s) may not want to send multiple >>>> ext-communities with same NLRI). >>>> >>>> >>>> >>>> If I recall group-ids are carried in new RT format: >>>> >>>> >>>> >>>> "This new BGP Route Target extended community is encoded as follows : >>>> >>>> >>>> >>>> 0 1 2 3 >>>> >>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>>> >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= + >>>> >>>> | Type (TBD) | 0x02 | Autonomous System Number = : >>>> >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= + >>>> >>>> : AS Number (cont.) |O|I| Group Identifier = | >>>> >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= + >>>> >>>> " >>>> >>>> >>>> >>>> So just like an UPDATE message of SAFI 128 may contain many RTs why >>>> would you see any >>>> >>>> issue to carry multiple ext communities of the above format here ? >>>> >>>> >>>> >>>> Best, >>>> >>>> R. >>>> >>>> >>>> >>>> On Thu, Jul 27, 2017 at 1:01 AM, Juan Alcaide (jalcaide) < >>>> jalcaide@cisco.com> wrote: >>>> >>>> Hi, >>>> >>>> From a previous thread, I see from the that using EXTCOMM to carry >>>> group-id information the choice. Reason was that every AS could use th= eir >>>> own the group-id (perhaps different than another AS). With this choice= , >>>> ADD-PATHS must be mandatory in order to support multiple group-ids for= the >>>> same flowspec rule (we assume controller(s) may not want to send mult= iple >>>> ext-communities with same NLRI). >>>> >>>> But the draft really does not describe how to use ADD-PATHS, and it >>>> does not discuss its problems: >>>> >>>> - Usually, ADD-PATHS is used for path diversity, and implementations >>>> typically don't advertise 2 paths with the same next-hop (otherwise, w= e >>>> could have path explosion across multiple levels of RRs) >>>> >>>> - If ADD-PATHS has to advertise the same NLRI with different >>>> ext-communities, one solution would be for ADD-PAHTS not advertise the= same >>>> set of ext-communities. Unless, I guess, next-hops are different. >>>> Otherwise, we would have path explosion. >>>> >>>> - Assuming the above, we should define a particular set of ADD-PATHS >>>> rules for flowspec AF. And, of course, leave the door open for future >>>> specific ADD-PATHs rules for other AFs (it would not be about path >>>> diversity anymore, but about propagating different information for >>>> forwarding purposes -imagine what we could have done with an IPv4 pref= ix: >>>> send the same net part as a NLRI and multiple ext-communities represen= ting >>>> different prefix-lengths -). >>>> >>>> - Since paths in a net are typically implemented as a list, there coul= d >>>> be scalability problems if we ever want to support many group-ids. >>>> >>>> My solution to simplify all these problems would be to add a >>>> discriminator on the NLRI (by defining a new dummy type for flowspec).= We >>>> could still use ext-communities to actually match the NLRIs to interfa= ces. >>>> Similar to RD and RT usage. >>>> >>>> Thoughts? >>>> >>>> -J >>>> >>>> >>>> _______________________________________________ >>>> Idr mailing list >>>> Idr@ietf.org >>>> https://www.ietf.org/mailman/listinfo/idr >>>> >>>> >>>> >>> >>> >>> >> >> > --001a1140c5c63af86905555fa3b9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

To change = format of NLRI you need essentially a new SAFI.=C2=A0

Clearly an option for this new draft, but I= think authors never envisioned that given set of match rules should have d= ifferent actions depending on the arriving interfaces for traffic matching = such rules. If at all I would recommend it to move it to flowspec v2 discus= sion.=C2=A0

It is in f= act very wired and quite bad to treat on the same router the same traffic d= ifferently based on the direction it arrives ... clearly out of scope of or= iginal 5575.=C2=A0

The= config push part indeed can be interface scoped, but is BGP really a right= tool for this ?=C2=A0

Cheers,
R.


On Fri, Jul 28, 2017 at 2:02 PM, Acee= Lindem (acee) <acee@cisco.com> wrote:
What was the reason for not making the interface-group part a new comp= onent type in the NLRI? It seems that making it just another Flow Spec matc= h condition would =C2=A0handle all these situations naturally.=C2=A0

=C2=A0I remember that this was discussed but don=E2=80=99t recall whet= her it was backward compatibility or that the semantics of interface group-= id was a better fit for an extended community.=C2=A0

Thanks,
Acee=C2=A0

From: Idr <idr-bounces@ietf.org> on behalf= of Robert Raszuk <robert@raszuk.net>
Date: Friday, July 28, 2017 at 7:52= AM
To: "Juan Alcaide (jalcaide)&q= uot; <jalcaide@c= isco.com>
Cc: IDR List <idr@ietf.org>

Subject: Re: [Idr] draft-litkowski-= idr-flowspec-interfaceset =3D> NLRI vs EXTCT (part 2)

Hi Juan,

= (group-id: what to you specify in ext-community; interface-group: what you = specify under interface configuration)

=E2=80=8BObvious. =E2=80=8B

= If you use ADD-PATHS, you can send identical NLRIs and you consider them as= valid (no implicit withdraw)

=E2=80=8BIf your controller or management station does not support ADD-PATH= S this is not the case. Only when you have ADD-PATHS everywhere you may pla= y that game.=C2=A0

Remember flow-spec was designed to be a DDoS mitigation tool across ASes. A= cross ASes last time I checked deployment of ADD-PATHS is zero. Now since s= ome folks turned it into config push =E2=80=8Bis not something original 557= 5 can be blamed for.=C2=A0
=C2=A0
= There is a requirement that the same flowspec rule, could be used for 2 dif= ferent interface-groups (let's say interfaces customer-facing and inter= faces provider-facing). But also you may want to use different actions based on the group-id (section 8 of the draft)

=E2=80=8BThat is just operational mess. To do that you can use SAFI 134 whe= re 8 octet RD is part of the NLRI what makes NLRI unique.=C2=A0

= I think we basically need to expand/clarify the ADD-PATHS part. Regarding y= our points:
1. For a given NLRI, we change group-ids or actions based on what we want t= o achieve. So it's based on how customer sets the rule in the controlle= r. There may be a need to send same NLRI with 2 different sets of action+gr= oup-id

=E2=80=8BI think doing this in such way is very messy. Pushing FS routes wi= th RD as indicated above is much cleaner if there such need to apply differ= ent actions or group IDs for the same NLRIs. =E2=80=8B
=C2=A0
= 2. If receiver receives more than one group-id, it should apply all the act= ions specified to *all* the interface-group associated to all the group-ids= it received. Draft does explicitly say what to do when you receive a NLRI with multiple group-ids, but I think it should be appli= ed to all interface-groups (probably it should be clarified)

=E2=80=8Bok.

Thx,
R.=E2=80=8B


=C2=A0
=

-J




On 7/27/2017 11:43 PM, Robert Raszuk wrote:
Juan,=

Sendi= ng from single controller (single BGP peer) two updates with identical NLRI= s is an implicit withdraw. ADD-PATHs has nothing to here.=C2=A0

Likew= ise RR should treat is as implicit withdraw of the previous one too.=C2=A0<= /div>

If yo= u go by your line of thinking what would make controller to change for give= n NLRI1 group-id 1 to group-id 2 if there is need to do so ?=C2=A0

In an= y case if you decide to add additional text to the current draft or decide = to write new draft to address this please do make sure to clearly define tw= o things:

1. Ho= w for a given NLRI we change either actions or group-ids=C2=A0

2. Wh= at should receiver do when for a given NLRI he received more then one group= -id or more then one set of actions ?=C2=A0

Thank= s,
R.





On Thu, Jul 27, 2017 at 11:37 PM, Juan Alcaide (= jalcaide) <jalcaide@cisco.com> wrote:
Robert,

We may support or not support unsynchronized controllers
But let's assume for a second we are just using one controller
but can a single controller sending

NLRI1 + group-id 1
NLRI1 + group-id 2

The RR receives both this routes (must be ADD-PATHS, as mentioned in the dr= aft). The RR needs to use ADD-PATHS itself to send it to the PE (final rece= iver)

-J




On 7/27/2017 9:44 PM, Robert Raszuk wrote:
Hi Ja= kob,

Two flowspec routes with the same NLRI may be = originated by different speakers.


Group= -id (scoped application of specific flow-spec rules) is addressing a specia= l case where it is generated carefully by either controller or provisioning= tools. I do not see therefor a practical case where the same such rule would be coming from two or more independent= sources and would be applicable =E2=80=8Bto different interface groups.=C2= =A0

It so= unds more like a protocol conflict or provisioning bug and not something we= should worry about how to carry it across RRs. Standard protocol behavior = would be fine here.

Now a= lso notice what would receiver do ... treat the subsequent update with the = exactly same NLRI as implicit withdraw or run best path if they come from d= ifferent peers and still apply single one to local data plane. So really there is no point to give it both such = paths with ADD-PATHs. As it is on final receivers the same should be done o= n RRs ...=C2=A0

=E2= =80=8BCheers,
//RR.=E2=80=8B

=C2=A0

The first route will have one group-id. The se= cond route will have another group-id.

=C2=A0

Thanks,

Jakob.

=C2=A0

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: Wednesday, July 26, 2017 4:38 PM
To: Juan Alcaide (jalcaide) <jalcaide@cisco.com>
Cc: idr wg <idr= @ietf.org>
Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset = =3D> NLRI vs EXTCT (part 2)

=C2=A0

Hi Juan,

=C2=A0

>=C2=A0=C2=A0(we assume controller(s) may not want to send multiple= ext-communities with same NLRI).

=C2=A0

If I recall group-ids are carried in new RT format:=C2=A0

=C2=A0

"This new BGP Route Target extended community is encoded as follo= ws :

=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A00 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 3

=C2=A0 =C2=A0 =C2=A0 =C2=A00 1 2 3 4 5 6 7 8 9= 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

=C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=C2=A0 =C2=A0 =C2=A0 | =C2=A0Type (TBD) =C2=A0= | =C2=A0 =C2=A0 =C2=A00x02 =C2=A0 =C2=A0 | =C2=A0 =C2=A0Autonomous System = Number =C2=A0 :

=C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=C2=A0 =C2=A0 =C2=A0 : =C2=A0 =C2=A0 AS Number= (cont.) =C2=A0 =C2=A0 =C2=A0 =C2=A0 |O|I| =C2=A0 =C2=A0 =C2=A0Group Identi= fier =C2=A0 =C2=A0 |

=C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

"

=C2=A0

So just like an UPDATE message of SAFI 128 may contain many RTs why wo= uld you see any=C2=A0

issue to carry multiple ext communities of the above format here ?=C2= =A0

=C2=A0

Best,

R.

=C2=A0

On Thu, Jul 27, 2017 at 1:01 AM, Juan Alcaide (jalca= ide) <jalcaide@c= isco.com> wrote:

Hi,

From a previous thread, I see from the = that using EXTCOMM to carry group-id information the choice. Reason was tha= t every AS could use their own the group-id (perhaps different than another= AS). With this choice, ADD-PATHS must be mandatory in order to support multiple group-ids for the same flow= spec rule=C2=A0 (we assume controller(s) may not want to send multiple ext-= communities with same NLRI).

But the draft really does not describe = how to use ADD-PATHS, and it does not discuss its problems:

- Usually, ADD-PATHS is used for path d= iversity, and implementations typically don't advertise 2 paths with th= e same next-hop (otherwise, we could have path explosion across multiple le= vels of RRs)

- If ADD-PATHS has to advertise the sam= e NLRI with different ext-communities, one solution would be for ADD-PAHTS = not advertise the same set of ext-communities. Unless, I guess, next-hops a= re different. Otherwise, we would have path explosion.

- Assuming the above, we should define = a particular set of ADD-PATHS rules for flowspec AF. And, of course, leave = the door open for future specific ADD-PATHs rules for other AFs (it would n= ot be about path diversity anymore, but about propagating different information for forwarding purposes -imagi= ne what we could have done with an IPv4 prefix: send the same net part as a= NLRI and multiple ext-communities representing different prefix-lengths -)= .

- Since paths in a net are typically im= plemented as a list, there could be scalability problems if we ever want to= support many group-ids.

My solution to simplify all these probl= ems would be to add a discriminator on the NLRI (by defining a new dummy ty= pe for flowspec). We could still use ext-communities to actually match the = NLRIs to interfaces. Similar to RD and RT usage.

Thoughts?

-J


_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

=C2=A0







--001a1140c5c63af86905555fa3b9-- From nobody Fri Jul 28 06:08:06 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9E4131C90 for ; Fri, 28 Jul 2017 06:08:05 -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 E9NNvzeiKKv4 for ; Fri, 28 Jul 2017 06:08:00 -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 2028A131BC8 for ; Fri, 28 Jul 2017 06:07:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=64103; q=dns/txt; s=iport; t=1501247278; x=1502456878; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=v+oe59EyMpW8X+25Q3UVGaLqsYt9Si9oUpHxX0omdzo=; b=Awo5Ki4aryVKqU5U0VDbhV7/aED2AsagODoex2fAwf9NtnscscYSAqwh WDJv3bPUVOa6vZj/pVTcQxK4WqQ8Ql+S1XSQOV64hUNWUfnpjC4HxgG1w MFUUJ+ns7/g0YqQQrcyDGGtKhGSLC/5/RiofzE1qLKEGvzsc8AI9Y6X5u 0=; X-IronPort-AV: E=Sophos;i="5.40,425,1496102400"; d="scan'208,217";a="279363699" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Jul 2017 13:07:56 +0000 Received: from [10.82.210.242] (rtp-vpn4-754.cisco.com [10.82.210.242]) (authenticated bits=0) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v6SD7reV011473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 28 Jul 2017 13:07:55 GMT To: Robert Raszuk Cc: "Jakob Heitz (jheitz)" , idr wg References: <9fa67eb0-8f99-a46f-aff1-d42a279ab833@cisco.com> <8dd3e766b58944a3b176fc743e478137@XCH-ALN-014.cisco.com> From: "Juan Alcaide (jalcaide)" Message-ID: Date: Fri, 28 Jul 2017 15:07:53 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------83DA633918BAE3072C00848E" Content-Language: en-US X-Authenticated-User: jalcaide Archived-At: Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT (part 2) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 13:08:05 -0000 This is a multi-part message in MIME format. --------------83DA633918BAE3072C00848E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I agree ADD-PATHS should be supported by controllers and currently most FS implementantions do not support ADD-PATHS I also agree that it's an operational mess (and that we would need draft clarification, just 'use ADD-PATHS' is not enough) But there is the requirement of the example that I mentioned I also agree that use of RD would work. But we cannot use SAFI 134 if all we have is plain IPv4 My idea would be to use something similar to RD for SAFI 133 -J On 7/28/2017 1:52 PM, Robert Raszuk wrote: > Hi Juan, > > (group-id: what to you specify in ext-community; interface-group: > what you specify under interface configuration) > > > ​Obvious. ​ > > If you use ADD-PATHS, you can send identical NLRIs and you > consider them as valid (no implicit withdraw) > > > ​If your controller or management station does not support ADD-PATHS > this is not the case. Only when you have ADD-PATHS everywhere you may > play that game. > > Remember flow-spec was designed to be a DDoS mitigation tool across > ASes. Across ASes last time I checked deployment of ADD-PATHS is zero. > Now since some folks turned it into config push ​is not something > original 5575 can be blamed for. > > There is a requirement that the same flowspec rule, could be used > for 2 different interface-groups (let's say interfaces > customer-facing and interfaces provider-facing). But also you may > want to use different actions based on the group-id (section 8 of > the draft) > > > ​That is just operational mess. To do that you can use SAFI 134 where > 8 octet RD is part of the NLRI what makes NLRI unique. > > I think we basically need to expand/clarify the ADD-PATHS part. > Regarding your points: > 1. For a given NLRI, we change group-ids or actions based on what > we want to achieve. So it's based on how customer sets the rule in > the controller. There may be a need to send same NLRI with 2 > different sets of action+group-id > > > ​I think doing this in such way is very messy. Pushing FS routes with > RD as indicated above is much cleaner if there such need to apply > different actions or group IDs for the same NLRIs. ​ > > 2. If receiver receives more than one group-id, it should apply > all the actions specified to *all* the interface-group associated > to all the group-ids it received. Draft does explicitly say what > to do when you receive a NLRI with multiple group-ids, but I think > it should be applied to all interface-groups (probably it should > be clarified) > > > ​ok. > > Thx, > R.​ > > > > > -J > > > > > On 7/27/2017 11:43 PM, Robert Raszuk wrote: >> Juan, >> >> Sending from single controller (single BGP peer) two updates with >> identical NLRIs is an implicit withdraw. ADD-PATHs has nothing to >> here. >> >> Likewise RR should treat is as implicit withdraw of the previous >> one too. >> >> If you go by your line of thinking what would make controller to >> change for given NLRI1 group-id 1 to group-id 2 if there is need >> to do so ? >> >> In any case if you decide to add additional text to the current >> draft or decide to write new draft to address this please do make >> sure to clearly define two things: >> >> 1. How for a given NLRI we change either actions or group-ids >> >> 2. What should receiver do when for a given NLRI he received more >> then one group-id or more then one set of actions ? >> >> Thanks, >> R. >> >> >> >> >> >> On Thu, Jul 27, 2017 at 11:37 PM, Juan Alcaide (jalcaide) >> > wrote: >> >> Robert, >> >> We may support or not support unsynchronized controllers >> But let's assume for a second we are just using one controller >> but can a single controller sending >> >> NLRI1 + group-id 1 >> NLRI1 + group-id 2 >> >> The RR receives both this routes (must be ADD-PATHS, as >> mentioned in the draft). The RR needs to use ADD-PATHS itself >> to send it to the PE (final receiver) >> >> -J >> >> >> >> >> On 7/27/2017 9:44 PM, Robert Raszuk wrote: >>> Hi Jakob, >>> >>> Two flowspec routes with the same NLRI may be originated >>> by different speakers. >>> >>> >>> Group-id (scoped application of specific flow-spec rules) is >>> addressing a special case where it is generated carefully by >>> either controller or provisioning tools. I do not see >>> therefor a practical case where the same such rule would be >>> coming from two or more independent sources and would be >>> applicable ​to different interface groups. >>> >>> It sounds more like a protocol conflict or provisioning bug >>> and not something we should worry about how to carry it >>> across RRs. Standard protocol behavior would be fine here. >>> >>> Now also notice what would receiver do ... treat the >>> subsequent update with the exactly same NLRI as implicit >>> withdraw or run best path if they come from different peers >>> and still apply single one to local data plane. So really >>> there is no point to give it both such paths with ADD-PATHs. >>> As it is on final receivers the same should be done on RRs ... >>> >>> ​Cheers, >>> //RR.​ >>> >>> The first route will have one group-id. The second route >>> will have another group-id. >>> >>> Thanks, >>> >>> Jakob. >>> >>> *From:*Idr [mailto:idr-bounces@ietf.org >>> ] *On Behalf Of *Robert Raszuk >>> *Sent:* Wednesday, July 26, 2017 4:38 PM >>> *To:* Juan Alcaide (jalcaide) >> > >>> *Cc:* idr wg > >>> *Subject:* Re: [Idr] >>> draft-litkowski-idr-flowspec-interfaceset => NLRI vs >>> EXTCT (part 2) >>> >>> Hi Juan, >>> >>> > (we assume controller(s) may not want to send multiple >>> ext-communities with same NLRI). >>> >>> If I recall group-ids are carried in new RT format: >>> >>> "This new BGP Route Target extended community is encoded >>> as follows : >>> >>> 0 1 2 3 >>> >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 >>> 6 7 8 9 0 1 >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> | Type (TBD) | 0x02 | Autonomous System >>> Number : >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> : AS Number (cont.) |O|I| Group >>> Identifier | >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> " >>> >>> So just like an UPDATE message of SAFI 128 may contain >>> many RTs why would you see any >>> >>> issue to carry multiple ext communities of the above >>> format here ? >>> >>> Best, >>> >>> R. >>> >>> On Thu, Jul 27, 2017 at 1:01 AM, Juan Alcaide (jalcaide) >>> > wrote: >>> >>> Hi, >>> >>> From a previous thread, I see from the that using >>> EXTCOMM to carry group-id information the choice. >>> Reason was that every AS could use their own the >>> group-id (perhaps different than another AS). With >>> this choice, ADD-PATHS must be mandatory in order to >>> support multiple group-ids for the same flowspec >>> rule (we assume controller(s) may not want to send >>> multiple ext-communities with same NLRI). >>> >>> But the draft really does not describe how to use >>> ADD-PATHS, and it does not discuss its problems: >>> >>> - Usually, ADD-PATHS is used for path diversity, and >>> implementations typically don't advertise 2 paths >>> with the same next-hop (otherwise, we could have >>> path explosion across multiple levels of RRs) >>> >>> - If ADD-PATHS has to advertise the same NLRI with >>> different ext-communities, one solution would be for >>> ADD-PAHTS not advertise the same set of >>> ext-communities. Unless, I guess, next-hops are >>> different. Otherwise, we would have path explosion. >>> >>> - Assuming the above, we should define a particular >>> set of ADD-PATHS rules for flowspec AF. And, of >>> course, leave the door open for future specific >>> ADD-PATHs rules for other AFs (it would not be about >>> path diversity anymore, but about propagating >>> different information for forwarding purposes >>> -imagine what we could have done with an IPv4 >>> prefix: send the same net part as a NLRI and >>> multiple ext-communities representing different >>> prefix-lengths -). >>> >>> - Since paths in a net are typically implemented as >>> a list, there could be scalability problems if we >>> ever want to support many group-ids. >>> >>> My solution to simplify all these problems would be >>> to add a discriminator on the NLRI (by defining a >>> new dummy type for flowspec). We could still use >>> ext-communities to actually match the NLRIs to >>> interfaces. Similar to RD and RT usage. >>> >>> Thoughts? >>> >>> -J >>> >>> >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www.ietf.org/mailman/listinfo/idr >>> >>> >>> >> >> > > --------------83DA633918BAE3072C00848E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
I agree ADD-PATHS should be supported by controllers and currently most FS implementantions do not support ADD-PATHS
I also agree that it's an operational mess (and that we would need draft clarification, just 'use ADD-PATHS' is not enough)

But there is the requirement of the example that I mentioned

I also agree that use of RD would work. But we cannot use SAFI 134 if all we have is plain IPv4

My idea would be to use something similar to RD for SAFI 133

-J


On 7/28/2017 1:52 PM, Robert Raszuk wrote:
Hi Juan,

(group-id: what to you specify in ext-community; interface-group: what you specify under interface configuration)

​Obvious. ​

If you use ADD-PATHS, you can send identical NLRIs and you consider them as valid (no implicit withdraw)

​If your controller or management station does not support ADD-PATHS this is not the case. Only when you have ADD-PATHS everywhere you may play that game. 

Remember flow-spec was designed to be a DDoS mitigation tool across ASes. Across ASes last time I checked deployment of ADD-PATHS is zero. Now since some folks turned it into config push ​is not something original 5575 can be blamed for. 
 
There is a requirement that the same flowspec rule, could be used for 2 different interface-groups (let's say interfaces customer-facing and interfaces provider-facing). But also you may want to use different actions based on the group-id (section 8 of the draft)

​That is just operational mess. To do that you can use SAFI 134 where 8 octet RD is part of the NLRI what makes NLRI unique. 

I think we basically need to expand/clarify the ADD-PATHS part. Regarding your points:
1. For a given NLRI, we change group-ids or actions based on what we want to achieve. So it's based on how customer sets the rule in the controller. There may be a need to send same NLRI with 2 different sets of action+group-id

​I think doing this in such way is very messy. Pushing FS routes with RD as indicated above is much cleaner if there such need to apply different actions or group IDs for the same NLRIs. ​
 
2. If receiver receives more than one group-id, it should apply all the actions specified to *all* the interface-group associated to all the group-ids it received. Draft does explicitly say what to do when you receive a NLRI with multiple group-ids, but I think it should be applied to all interface-groups (probably it should be clarified)

​ok.

Thx,
R.​


 


-J




On 7/27/2017 11:43 PM, Robert Raszuk wrote:
Juan,

Sending from single controller (single BGP peer) two updates with identical NLRIs is an implicit withdraw. ADD-PATHs has nothing to here. 

Likewise RR should treat is as implicit withdraw of the previous one too. 

If you go by your line of thinking what would make controller to change for given NLRI1 group-id 1 to group-id 2 if there is need to do so ? 

In any case if you decide to add additional text to the current draft or decide to write new draft to address this please do make sure to clearly define two things:

1. How for a given NLRI we change either actions or group-ids 

2. What should receiver do when for a given NLRI he received more then one group-id or more then one set of actions ? 

Thanks,
R.





On Thu, Jul 27, 2017 at 11:37 PM, Juan Alcaide (jalcaide) <jalcaide@cisco.com> wrote:
Robert,

We may support or not support unsynchronized controllers
But let's assume for a second we are just using one controller
but can a single controller sending

NLRI1 + group-id 1
NLRI1 + group-id 2

The RR receives both this routes (must be ADD-PATHS, as mentioned in the draft). The RR needs to use ADD-PATHS itself to send it to the PE (final receiver)

-J




On 7/27/2017 9:44 PM, Robert Raszuk wrote:
Hi Jakob,

Two flowspec routes with the same NLRI may be originated by different speakers.


Group-id (scoped application of specific flow-spec rules) is addressing a special case where it is generated carefully by either controller or provisioning tools. I do not see therefor a practical case where the same such rule would be coming from two or more independent sources and would be applicable ​to different interface groups. 

It sounds more like a protocol conflict or provisioning bug and not something we should worry about how to carry it across RRs. Standard protocol behavior would be fine here.

Now also notice what would receiver do ... treat the subsequent update with the exactly same NLRI as implicit withdraw or run best path if they come from different peers and still apply single one to local data plane. So really there is no point to give it both such paths with ADD-PATHs. As it is on final receivers the same should be done on RRs ... 

​Cheers,
//RR.​

 

The first route will have one group-id. The second route will have another group-id.

 

Thanks,

Jakob.

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: Wednesday, July 26, 2017 4:38 PM
To: Juan Alcaide (jalcaide) <jalcaide@cisco.com>
Cc: idr wg <idr@ietf.org>
Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT (part 2)

 

Hi Juan,

 

>  (we assume controller(s) may not want to send multiple ext-communities with same NLRI).

 

If I recall group-ids are carried in new RT format: 

 

"This new BGP Route Target extended community is encoded as follows :

 

       0                   1                   2                   3

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |  Type (TBD)   |      0x02     |    Autonomous System Number   :

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      :     AS Number (cont.)         |O|I|      Group Identifier     |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

"

 

So just like an UPDATE message of SAFI 128 may contain many RTs why would you see any 

issue to carry multiple ext communities of the above format here ? 

 

Best,

R.

 

On Thu, Jul 27, 2017 at 1:01 AM, Juan Alcaide (jalcaide) <jalcaide@cisco.com> wrote:

Hi,

From a previous thread, I see from the that using EXTCOMM to carry group-id information the choice. Reason was that every AS could use their own the group-id (perhaps different than another AS). With this choice, ADD-PATHS must be mandatory in order to support multiple group-ids for the same flowspec rule  (we assume controller(s) may not want to send multiple ext-communities with same NLRI).

But the draft really does not describe how to use ADD-PATHS, and it does not discuss its problems:

- Usually, ADD-PATHS is used for path diversity, and implementations typically don't advertise 2 paths with the same next-hop (otherwise, we could have path explosion across multiple levels of RRs)

- If ADD-PATHS has to advertise the same NLRI with different ext-communities, one solution would be for ADD-PAHTS not advertise the same set of ext-communities. Unless, I guess, next-hops are different. Otherwise, we would have path explosion.

- Assuming the above, we should define a particular set of ADD-PATHS rules for flowspec AF. And, of course, leave the door open for future specific ADD-PATHs rules for other AFs (it would not be about path diversity anymore, but about propagating different information for forwarding purposes -imagine what we could have done with an IPv4 prefix: send the same net part as a NLRI and multiple ext-communities representing different prefix-lengths -).

- Since paths in a net are typically implemented as a list, there could be scalability problems if we ever want to support many group-ids.

My solution to simplify all these problems would be to add a discriminator on the NLRI (by defining a new dummy type for flowspec). We could still use ext-communities to actually match the NLRIs to interfaces. Similar to RD and RT usage.

Thoughts?

-J


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

 







--------------83DA633918BAE3072C00848E-- From nobody Fri Jul 28 06:13:30 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73076131C36 for ; Fri, 28 Jul 2017 06:13:29 -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 H8mWoX4fRidK for ; Fri, 28 Jul 2017 06:13:25 -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 3B66F131C35 for ; Fri, 28 Jul 2017 06:13:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=88139; q=dns/txt; s=iport; t=1501247605; x=1502457205; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=EmZAEbMgXWI1ybmTw0ZELHwrveoBqqg+4ubaVXwHK5I=; b=XAbNE8rJu32SN0rkskaan7+phHyZ+gp6iN2Rvi5dUM7l6tkAVbl01mbf x+Y2gz5mGJTrPWznpFi5/SKmemn2MRNhk12pFPHUO8sqHBP/oiu7R3lpI ec6tvqJ2/18kMtuSI9Q/7qKSWCC6vYEx/3nyeVACkjE/EiIBwcXAfALMn E=; X-IronPort-AV: E=Sophos;i="5.40,425,1496102400"; d="scan'208,217";a="279366514" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jul 2017 13:13:24 +0000 Received: from [10.82.210.242] (rtp-vpn4-754.cisco.com [10.82.210.242]) (authenticated bits=0) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v6SDDLTl016159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 28 Jul 2017 13:13:23 GMT To: Robert Raszuk , "Acee Lindem (acee)" Cc: idr wg References: <9fa67eb0-8f99-a46f-aff1-d42a279ab833@cisco.com> <8dd3e766b58944a3b176fc743e478137@XCH-ALN-014.cisco.com> From: "Juan Alcaide (jalcaide)" Message-ID: <5d686b49-9a4d-2610-153a-1e778c9b80af@cisco.com> Date: Fri, 28 Jul 2017 15:13:21 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------418C929DA511825A04988310" Content-Language: en-US X-Authenticated-User: jalcaide Archived-At: Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT (part 2) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 13:13:29 -0000 This is a multi-part message in MIME format. --------------418C929DA511825A04988310 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Authors mention it on section 8, but I don't think the real implications were discussed. Treating traffic differently based the direction it arrives may be out of scope of 5575, but it's the reason of this draft and customer are asking for it. I think in some cases it makes sense not treating all interfaces equally For flowspec in particular, you don't have to use a new SAFI. It's an extensible NLRI, so we can just define a dummy component that doesn't match anything (similar to an RD) Acee, we didn't make the group-id part of the NLRI per inter-AS considerations (imagine AS1 means group-id =1 => customer interfaces, but AS2 means group-id=1 provider interfaces; you want to be able to do the translation). Look for thread "[Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT" a couple years ago (w/o the '(part 2)') -J On 7/28/2017 2:15 PM, Robert Raszuk wrote: > > To change format of NLRI you need essentially a new SAFI. > > Clearly an option for this new draft, but I think authors never > envisioned that given set of match rules should have different actions > depending on the arriving interfaces for traffic matching such rules. > If at all I would recommend it to move it to flowspec v2 discussion. > > It is in fact very wired and quite bad to treat on the same router the > same traffic differently based on the direction it arrives ... clearly > out of scope of original 5575. > > The config push part indeed can be interface scoped, but is BGP really > a right tool for this ? > > Cheers, > R. > > > On Fri, Jul 28, 2017 at 2:02 PM, Acee Lindem (acee) > wrote: > > What was the reason for not making the interface-group part a new > component type in the NLRI? It seems that making it just another > Flow Spec match condition would handle all these situations > naturally. > > I remember that this was discussed but don’t recall whether it > was backward compatibility or that the semantics of interface > group-id was a better fit for an extended community. > > Thanks, > Acee > > From: Idr > on > behalf of Robert Raszuk > > Date: Friday, July 28, 2017 at 7:52 AM > To: "Juan Alcaide (jalcaide)" > > Cc: IDR List > > > Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => > NLRI vs EXTCT (part 2) > > Hi Juan, > > (group-id: what to you specify in ext-community; > interface-group: what you specify under interface > configuration) > > > ​Obvious. ​ > > If you use ADD-PATHS, you can send identical NLRIs and you > consider them as valid (no implicit withdraw) > > > ​If your controller or management station does not support > ADD-PATHS this is not the case. Only when you have ADD-PATHS > everywhere you may play that game. > > Remember flow-spec was designed to be a DDoS mitigation tool > across ASes. Across ASes last time I checked deployment of > ADD-PATHS is zero. Now since some folks turned it into config > push ​is not something original 5575 can be blamed for. > > There is a requirement that the same flowspec rule, could > be used for 2 different interface-groups (let's say > interfaces customer-facing and interfaces > provider-facing). But also you may want to use different > actions based on the group-id (section 8 of the draft) > > > ​That is just operational mess. To do that you can use SAFI > 134 where 8 octet RD is part of the NLRI what makes NLRI unique. > > I think we basically need to expand/clarify the ADD-PATHS > part. Regarding your points: > 1. For a given NLRI, we change group-ids or actions based > on what we want to achieve. So it's based on how customer > sets the rule in the controller. There may be a need to > send same NLRI with 2 different sets of action+group-id > > > ​I think doing this in such way is very messy. Pushing FS > routes with RD as indicated above is much cleaner if there > such need to apply different actions or group IDs for the same > NLRIs. ​ > > 2. If receiver receives more than one group-id, it should > apply all the actions specified to *all* the > interface-group associated to all the group-ids it > received. Draft does explicitly say what to do when you > receive a NLRI with multiple group-ids, but I think it > should be applied to all interface-groups (probably it > should be clarified) > > > ​ok. > > Thx, > R.​ > > > > > -J > > > > > On 7/27/2017 11:43 PM, Robert Raszuk wrote: >> Juan, >> >> Sending from single controller (single BGP peer) two >> updates with identical NLRIs is an implicit withdraw. >> ADD-PATHs has nothing to here. >> >> Likewise RR should treat is as implicit withdraw of the >> previous one too. >> >> If you go by your line of thinking what would make >> controller to change for given NLRI1 group-id 1 to >> group-id 2 if there is need to do so ? >> >> In any case if you decide to add additional text to the >> current draft or decide to write new draft to address >> this please do make sure to clearly define two things: >> >> 1. How for a given NLRI we change either actions or >> group-ids >> >> 2. What should receiver do when for a given NLRI he >> received more then one group-id or more then one set of >> actions ? >> >> Thanks, >> R. >> >> >> >> >> >> On Thu, Jul 27, 2017 at 11:37 PM, Juan Alcaide (jalcaide) >> > wrote: >> >> Robert, >> >> We may support or not support unsynchronized controllers >> But let's assume for a second we are just using one >> controller >> but can a single controller sending >> >> NLRI1 + group-id 1 >> NLRI1 + group-id 2 >> >> The RR receives both this routes (must be ADD-PATHS, >> as mentioned in the draft). The RR needs to use >> ADD-PATHS itself to send it to the PE (final receiver) >> >> -J >> >> >> >> >> On 7/27/2017 9:44 PM, Robert Raszuk wrote: >>> Hi Jakob, >>> >>> Two flowspec routes with the same NLRI may be >>> originated by different speakers. >>> >>> >>> Group-id (scoped application of specific flow-spec >>> rules) is addressing a special case where it is >>> generated carefully by either controller or >>> provisioning tools. I do not see therefor a >>> practical case where the same such rule would be >>> coming from two or more independent sources and >>> would be applicable ​to different interface groups. >>> >>> It sounds more like a protocol conflict or >>> provisioning bug and not something we should worry >>> about how to carry it across RRs. Standard protocol >>> behavior would be fine here. >>> >>> Now also notice what would receiver do ... treat the >>> subsequent update with the exactly same NLRI as >>> implicit withdraw or run best path if they come from >>> different peers and still apply single one to local >>> data plane. So really there is no point to give it >>> both such paths with ADD-PATHs. As it is on final >>> receivers the same should be done on RRs ... >>> >>> ​Cheers, >>> //RR.​ >>> >>> The first route will have one group-id. The >>> second route will have another group-id. >>> >>> Thanks, >>> >>> Jakob. >>> >>> *From:*Idr [mailto:idr-bounces@ietf.org >>> ] *On Behalf Of >>> *Robert Raszuk >>> *Sent:* Wednesday, July 26, 2017 4:38 PM >>> *To:* Juan Alcaide (jalcaide) >>> > >>> *Cc:* idr wg > >>> *Subject:* Re: [Idr] >>> draft-litkowski-idr-flowspec-interfaceset => >>> NLRI vs EXTCT (part 2) >>> >>> Hi Juan, >>> >>> > (we assume controller(s) may not want to send multiple >>> ext-communities with same NLRI). >>> >>> If I recall group-ids are carried in new RT format: >>> >>> "This new BGP Route Target extended community is >>> encoded as follows : >>> >>> 0 1 2 3 >>> >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> 2 3 4 5 6 7 8 9 0 1 >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> | Type (TBD) | 0x02 | Autonomous >>> System Number : >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> : AS Number (cont.) |O|I| >>> Group Identifier | >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> " >>> >>> So just like an UPDATE message of SAFI 128 may >>> contain many RTs why would you see any >>> >>> issue to carry multiple ext communities of the >>> above format here ? >>> >>> Best, >>> >>> R. >>> >>> On Thu, Jul 27, 2017 at 1:01 AM, Juan Alcaide >>> (jalcaide) >> > wrote: >>> >>> Hi, >>> >>> From a previous thread, I see from the that >>> using EXTCOMM to carry group-id information >>> the choice. Reason was that every AS could >>> use their own the group-id (perhaps >>> different than another AS). With this >>> choice, ADD-PATHS must be mandatory in order >>> to support multiple group-ids for the same >>> flowspec rule (we assume controller(s) may >>> not want to send multiple ext-communities >>> with same NLRI). >>> >>> But the draft really does not describe how >>> to use ADD-PATHS, and it does not discuss >>> its problems: >>> >>> - Usually, ADD-PATHS is used for path >>> diversity, and implementations typically >>> don't advertise 2 paths with the same >>> next-hop (otherwise, we could have path >>> explosion across multiple levels of RRs) >>> >>> - If ADD-PATHS has to advertise the same >>> NLRI with different ext-communities, one >>> solution would be for ADD-PAHTS not >>> advertise the same set of ext-communities. >>> Unless, I guess, next-hops are different. >>> Otherwise, we would have path explosion. >>> >>> - Assuming the above, we should define a >>> particular set of ADD-PATHS rules for >>> flowspec AF. And, of course, leave the door >>> open for future specific ADD-PATHs rules for >>> other AFs (it would not be about path >>> diversity anymore, but about propagating >>> different information for forwarding >>> purposes -imagine what we could have done >>> with an IPv4 prefix: send the same net part >>> as a NLRI and multiple ext-communities >>> representing different prefix-lengths -). >>> >>> - Since paths in a net are typically >>> implemented as a list, there could be >>> scalability problems if we ever want to >>> support many group-ids. >>> >>> My solution to simplify all these problems >>> would be to add a discriminator on the NLRI >>> (by defining a new dummy type for flowspec). >>> We could still use ext-communities to >>> actually match the NLRIs to interfaces. >>> Similar to RD and RT usage. >>> >>> Thoughts? >>> >>> -J >>> >>> >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www.ietf.org/mailman/listinfo/idr >>> >>> >>> >> >> > > > --------------418C929DA511825A04988310 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Authors mention it on section 8, but  I don't think the real implications were discussed.
Treating traffic differently based the direction it arrives may be out of scope of 5575, but it's the reason of this draft and customer are asking for it. I think in some cases it makes sense not treating all interfaces equally

For flowspec in particular, you don't have to use a new SAFI. It's an extensible NLRI, so we can just define a dummy component that doesn't match anything (similar to an RD)

Acee, we didn't make the group-id part of the NLRI per inter-AS considerations (imagine AS1 means group-id =1 => customer interfaces, but AS2 means group-id=1 provider interfaces; you want to be able to do the translation). Look for thread "[Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT" a couple years ago (w/o the '(part 2)')

-J

On 7/28/2017 2:15 PM, Robert Raszuk wrote:

To change format of NLRI you need essentially a new SAFI. 

Clearly an option for this new draft, but I think authors never envisioned that given set of match rules should have different actions depending on the arriving interfaces for traffic matching such rules. If at all I would recommend it to move it to flowspec v2 discussion. 

It is in fact very wired and quite bad to treat on the same router the same traffic differently based on the direction it arrives ... clearly out of scope of original 5575. 

The config push part indeed can be interface scoped, but is BGP really a right tool for this ? 

Cheers,
R.


On Fri, Jul 28, 2017 at 2:02 PM, Acee Lindem (acee) <acee@cisco.com> wrote:
What was the reason for not making the interface-group part a new component type in the NLRI? It seems that making it just another Flow Spec match condition would  handle all these situations naturally. 

 I remember that this was discussed but don’t recall whether it was backward compatibility or that the semantics of interface group-id was a better fit for an extended community. 

Thanks,
Acee 

From: Idr <idr-bounces@ietf.org> on behalf of Robert Raszuk <robert@raszuk.net>
Date: Friday, July 28, 2017 at 7:52 AM
To: "Juan Alcaide (jalcaide)" <jalcaide@cisco.com>
Cc: IDR List <idr@ietf.org>

Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT (part 2)

Hi Juan,

(group-id: what to you specify in ext-community; interface-group: what you specify under interface configuration)

​Obvious. ​

If you use ADD-PATHS, you can send identical NLRIs and you consider them as valid (no implicit withdraw)

​If your controller or management station does not support ADD-PATHS this is not the case. Only when you have ADD-PATHS everywhere you may play that game. 

Remember flow-spec was designed to be a DDoS mitigation tool across ASes. Across ASes last time I checked deployment of ADD-PATHS is zero. Now since some folks turned it into config push ​is not something original 5575 can be blamed for. 
 
There is a requirement that the same flowspec rule, could be used for 2 different interface-groups (let's say interfaces customer-facing and interfaces provider-facing). But also you may want to use different actions based on the group-id (section 8 of the draft)

​That is just operational mess. To do that you can use SAFI 134 where 8 octet RD is part of the NLRI what makes NLRI unique. 

I think we basically need to expand/clarify the ADD-PATHS part. Regarding your points:
1. For a given NLRI, we change group-ids or actions based on what we want to achieve. So it's based on how customer sets the rule in the controller. There may be a need to send same NLRI with 2 different sets of action+group-id

​I think doing this in such way is very messy. Pushing FS routes with RD as indicated above is much cleaner if there such need to apply different actions or group IDs for the same NLRIs. ​
 
2. If receiver receives more than one group-id, it should apply all the actions specified to *all* the interface-group associated to all the group-ids it received. Draft does explicitly say what to do when you receive a NLRI with multiple group-ids, but I think it should be applied to all interface-groups (probably it should be clarified)

​ok.

Thx,
R.​


 


-J




On 7/27/2017 11:43 PM, Robert Raszuk wrote:
Juan,

Sending from single controller (single BGP peer) two updates with identical NLRIs is an implicit withdraw. ADD-PATHs has nothing to here. 

Likewise RR should treat is as implicit withdraw of the previous one too. 

If you go by your line of thinking what would make controller to change for given NLRI1 group-id 1 to group-id 2 if there is need to do so ? 

In any case if you decide to add additional text to the current draft or decide to write new draft to address this please do make sure to clearly define two things:

1. How for a given NLRI we change either actions or group-ids 

2. What should receiver do when for a given NLRI he received more then one group-id or more then one set of actions ? 

Thanks,
R.





On Thu, Jul 27, 2017 at 11:37 PM, Juan Alcaide (jalcaide) <jalcaide@cisco.com> wrote:
Robert,

We may support or not support unsynchronized controllers
But let's assume for a second we are just using one controller
but can a single controller sending

NLRI1 + group-id 1
NLRI1 + group-id 2

The RR receives both this routes (must be ADD-PATHS, as mentioned in the draft). The RR needs to use ADD-PATHS itself to send it to the PE (final receiver)

-J




On 7/27/2017 9:44 PM, Robert Raszuk wrote:
Hi Jakob,

Two flowspec routes with the same NLRI may be originated by different speakers.


Group-id (scoped application of specific flow-spec rules) is addressing a special case where it is generated carefully by either controller or provisioning tools. I do not see therefor a practical case where the same such rule would be coming from two or more independent sources and would be applicable ​to different interface groups. 

It sounds more like a protocol conflict or provisioning bug and not something we should worry about how to carry it across RRs. Standard protocol behavior would be fine here.

Now also notice what would receiver do ... treat the subsequent update with the exactly same NLRI as implicit withdraw or run best path if they come from different peers and still apply single one to local data plane. So really there is no point to give it both such paths with ADD-PATHs. As it is on final receivers the same should be done on RRs ... 

​Cheers,
//RR.​

 

The first route will have one group-id. The second route will have another group-id.

 

Thanks,

Jakob.

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: Wednesday, July 26, 2017 4:38 PM
To: Juan Alcaide (jalcaide) <jalcaide@cisco.com>
Cc: idr wg <idr@ietf.org>
Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT (part 2)

 

Hi Juan,

 

>  (we assume controller(s) may not want to send multiple ext-communities with same NLRI).

 

If I recall group-ids are carried in new RT format: 

 

"This new BGP Route Target extended community is encoded as follows :

 

       0                   1                   2                   3

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |  Type (TBD)   |      0x02     |    Autonomous System Number   :

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      :     AS Number (cont.)         |O|I|      Group Identifier     |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

"

 

So just like an UPDATE message of SAFI 128 may contain many RTs why would you see any 

issue to carry multiple ext communities of the above format here ? 

 

Best,

R.

 

On Thu, Jul 27, 2017 at 1:01 AM, Juan Alcaide (jalcaide) <jalcaide@cisco.com> wrote:

Hi,

From a previous thread, I see from the that using EXTCOMM to carry group-id information the choice. Reason was that every AS could use their own the group-id (perhaps different than another AS). With this choice, ADD-PATHS must be mandatory in order to support multiple group-ids for the same flowspec rule  (we assume controller(s) may not want to send multiple ext-communities with same NLRI).

But the draft really does not describe how to use ADD-PATHS, and it does not discuss its problems:

- Usually, ADD-PATHS is used for path diversity, and implementations typically don't advertise 2 paths with the same next-hop (otherwise, we could have path explosion across multiple levels of RRs)

- If ADD-PATHS has to advertise the same NLRI with different ext-communities, one solution would be for ADD-PAHTS not advertise the same set of ext-communities. Unless, I guess, next-hops are different. Otherwise, we would have path explosion.

- Assuming the above, we should define a particular set of ADD-PATHS rules for flowspec AF. And, of course, leave the door open for future specific ADD-PATHs rules for other AFs (it would not be about path diversity anymore, but about propagating different information for forwarding purposes -imagine what we could have done with an IPv4 prefix: send the same net part as a NLRI and multiple ext-communities representing different prefix-lengths -).

- Since paths in a net are typically implemented as a list, there could be scalability problems if we ever want to support many group-ids.

My solution to simplify all these problems would be to add a discriminator on the NLRI (by defining a new dummy type for flowspec). We could still use ext-communities to actually match the NLRIs to interfaces. Similar to RD and RT usage.

Thoughts?

-J


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

 


--------------418C929DA511825A04988310-- From nobody Fri Jul 28 06:20:48 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B0D131FF3 for ; Fri, 28 Jul 2017 06:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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 EfUdIb3ytrUY for ; Fri, 28 Jul 2017 06:20:44 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47D3F131C90 for ; Fri, 28 Jul 2017 06:20:44 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id g13so89596105ioj.5 for ; Fri, 28 Jul 2017 06:20:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=HzV0ATq1sX4NKMZftCJ40advYZIb+cPetvQ4FZJ71iY=; b=Irq9HYk/y7/IFRpqDH627T9AsMOWLfu5hJrkhd+uIb8FkT7Whxb8XKEA94cD1KE49i qWF27o7b8PKPu2jvXblpi47hdKTojg8Gap6KyMi6y/b8ZtSMC6mIPGIbKqReboEX4Rmh ioi3prxWhO7xHfHzbJvDbKQRNHU4sCGMfmzlz1rECCDCcudx+NZ2d3psVhfKCU6GEij7 uS5v4Qom19yDKr4bEX023TAssrtzpRD8dMeYnf5ltPlkmAgjnzYKsA030GpeerDyGlNH PZYLLipp00p0yHOL1GNgmx3MYSZCRoJkzMGAgyaGYJwiK76goW6yZKq9RhgGDpejkMxw tovQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=HzV0ATq1sX4NKMZftCJ40advYZIb+cPetvQ4FZJ71iY=; b=nOj5XJsnWA52UJ/pIdcnBk/KzoATajNRXSE/zY+y6lKjdwmzI1pUarCxvS35cmc0iU hFkr3ybaNNdde7ghOSpZcurxaZMU9S/zlja7LAR92W7HnVMvx+loOMbBSLP0qFk4fwok ZDT6CH0qxPQ381mYE0CRHzScIhU7w68cwxHPU5N8H6RTCK8otqleW0bvXM9lxlPtAfim Jo5fPJrNadPLFqXioI1pyP3xlwDjTA5uEaQAAK8kOZJ7uGMJhjKz8CNsNvzxdQNSpoi0 6Ar12gADOsfKl3L9IMQurK8smW7fVZoUKV+jRzuSS4f4wsLmFtW5PmkUhg3CuZLakfpB aE3g== X-Gm-Message-State: AIVw111QBJuveWnlvfIA5JUpiwCR+XmTirB1zvhhZolx84yuhXKWrpzG JuOZZDHMZSkFobQhA+0NONpVJXQLpw== X-Received: by 10.107.16.101 with SMTP id y98mr8823303ioi.196.1501248043539; Fri, 28 Jul 2017 06:20:43 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.153.21 with HTTP; Fri, 28 Jul 2017 06:20:42 -0700 (PDT) In-Reply-To: References: <9fa67eb0-8f99-a46f-aff1-d42a279ab833@cisco.com> <8dd3e766b58944a3b176fc743e478137@XCH-ALN-014.cisco.com> From: Robert Raszuk Date: Fri, 28 Jul 2017 15:20:42 +0200 X-Google-Sender-Auth: zvNVssLPtOgW570unFQMrUs14o0 Message-ID: To: "Juan Alcaide (jalcaide)" Cc: idr wg Content-Type: multipart/alternative; boundary="001a113e9f625ae1980555608ccd" Archived-At: Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT (part 2) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 13:20:47 -0000 --001a113e9f625ae1980555608ccd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > I also agree that use of RD would work. But we cannot use SAFI 134 if all > we have is plain IPv4 > =E2=80=8BWhy not ? While original intention of SAFI 134 was to be used with= VPNs there is nothing which prevents to use it for "global" table. Just import the filters with RT corresponding to global VRF :) Thx, R. --001a113e9f625ae1980555608ccd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=C2=A0
I also agr= ee that use of RD would work. But we cannot use SAFI 134 if all we have is plain IPv4

=E2=80=8BWhy not ? While original intention of SAFI 1= 34 was to be used with VPNs there is nothing which prevents to use it for &= quot;global" table. Just import the filters with RT corresponding to g= lobal VRF :)=C2=A0

Thx= ,
R.
--001a113e9f625ae1980555608ccd-- From nobody Fri Jul 28 07:16:49 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF561204DA for ; Fri, 28 Jul 2017 07:16:48 -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 YTYrjBIzvwFF for ; Fri, 28 Jul 2017 07:16:46 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EBD2131C8B for ; Fri, 28 Jul 2017 07:16:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6047; q=dns/txt; s=iport; t=1501251406; x=1502461006; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ZfyPIo3yh6RAiiF0q9n7UlatPRBALQ4HUPmmeMisotE=; b=HGokQhAXkSRhPmYNZFFmWd/sZSmR+pa1toRotQaSIpEqlLmKMzHWZ5Q/ cCxcCahsoTahUMaB7Gfv0NDLXJy2ACaGjfjRtBH3pbQG7yN79UnmZZsXw VT+oPMj4f3v3YH3hYJeu8GRwkJ1sYckc5yfN0KNnoIJTN45i1CDepcrzi E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BgAQDtRntZ/5ldJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9rgVEnB44Gj3qBa5BchS+CEoVHAhqDVj8YAQIBAQEBAQEBayi?= =?us-ascii?q?FGAEBAQEDI1YQAgEIBA0DAQIoAwICAjAUCQgCBAENBYlLZK4/giYnixYBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEdgyiFLoMnhROCc4JhBZ9tApQkkjyVcQEfOIEKdxV?= =?us-ascii?q?Jhxl2iHKBDgEBAQ?= X-IronPort-AV: E=Sophos;i="5.40,425,1496102400"; d="scan'208,217";a="460775784" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Jul 2017 14:16:45 +0000 Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v6SEGjc4005348 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 28 Jul 2017 14:16:45 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 28 Jul 2017 10:16:44 -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, 28 Jul 2017 10:16:44 -0400 From: "Acee Lindem (acee)" To: Robert Raszuk , "Juan Alcaide (jalcaide)" CC: idr wg Thread-Topic: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT (part 2) Thread-Index: AQHTBmMsoLqrouxoe0ioArBC+Wdvh6JnBqgAgAEOOjaAAGJ2gIAAAcqAgADkMgCAAAjwgIAAFQ6AgAADlQD//8yTAA== Date: Fri, 28 Jul 2017 14:16:44 +0000 Message-ID: References: <9fa67eb0-8f99-a46f-aff1-d42a279ab833@cisco.com> <8dd3e766b58944a3b176fc743e478137@XCH-ALN-014.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: multipart/alternative; boundary="_000_D5A0BE1BBA569aceeciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT (part 2) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 14:16:48 -0000 --_000_D5A0BE1BBA569aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KDQpJZiB3ZSBhZ3JlZSB0aGF0IEp1YW7igJlzIHN1Z2dlc3Rpb24gdG8gdXNl IGFuIFJEIHRvIGRpZmZlcmVudGlhdGUgaWRlbnRpY2FsIEZsb3cgU3BlYyBOTFJJcyB3aXRoIGRp ZmZlcmVudCBncm91cCBpbnRlcmZhY2UtaWRzLCBpdCB3b3VsZCBiZSBzb21ldGhpbmcgeW91IGFu ZCB5b3VyIGNvLWF1dGhvcnMgc2hvdWxkIGRpc2N1c3MgaW4gZHJhZnQtaWV0Zi1pZHItcmZjNTU3 NWJpcy4gRXZlbiB0aG91Z2ggdGhlIGRyYWZ0IGlzIG11Y2ggY2xvc2VyIHRvIHB1YmxpY2F0aW9u LCB5b3UgY291bGQgYWRkcmVzcyB0aGUgIHVzZSBjYXNlIGdlbmVyaWNhbGx5IHdpdGggYW4gaW5m b3JtYXRpdmUgcmVmZXJlbmNlLg0KDQpUaGFua3MsDQpBY2VlDQoNCkZyb206IElkciA8aWRyLWJv dW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9m IFJvYmVydCBSYXN6dWsgPHJvYmVydEByYXN6dWsubmV0PG1haWx0bzpyb2JlcnRAcmFzenVrLm5l dD4+DQpEYXRlOiBGcmlkYXksIEp1bHkgMjgsIDIwMTcgYXQgOToyMCBBTQ0KVG86ICJKdWFuIEFs Y2FpZGUgKGphbGNhaWRlKSIgPGphbGNhaWRlQGNpc2NvLmNvbTxtYWlsdG86amFsY2FpZGVAY2lz Y28uY29tPj4NCkNjOiBJRFIgTGlzdCA8aWRyQGlldGYub3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+ Pg0KU3ViamVjdDogUmU6IFtJZHJdIGRyYWZ0LWxpdGtvd3NraS1pZHItZmxvd3NwZWMtaW50ZXJm YWNlc2V0ID0+IE5MUkkgdnMgRVhUQ1QgKHBhcnQgMikNCg0KDQpJIGFsc28gYWdyZWUgdGhhdCB1 c2Ugb2YgUkQgd291bGQgd29yay4gQnV0IHdlIGNhbm5vdCB1c2UgU0FGSSAxMzQgaWYgYWxsIHdl IGhhdmUgaXMgcGxhaW4gSVB2NA0KDQrigItXaHkgbm90ID8gV2hpbGUgb3JpZ2luYWwgaW50ZW50 aW9uIG9mIFNBRkkgMTM0IHdhcyB0byBiZSB1c2VkIHdpdGggVlBOcyB0aGVyZSBpcyBub3RoaW5n IHdoaWNoIHByZXZlbnRzIHRvIHVzZSBpdCBmb3IgImdsb2JhbCIgdGFibGUuIEp1c3QgaW1wb3J0 IHRoZSBmaWx0ZXJzIHdpdGggUlQgY29ycmVzcG9uZGluZyB0byBnbG9iYWwgVlJGIDopDQoNClRo eCwNClIuDQo= --_000_D5A0BE1BBA569aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaSBSb2JlcnQs Jm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JZiB3ZSBhZ3JlZSB0aGF0IEp1 YW7igJlzIHN1Z2dlc3Rpb24gdG8gdXNlIGFuIFJEIHRvIGRpZmZlcmVudGlhdGUgaWRlbnRpY2Fs IEZsb3cgU3BlYyBOTFJJcyB3aXRoIGRpZmZlcmVudCBncm91cCBpbnRlcmZhY2UtaWRzLCBpdCB3 b3VsZCBiZSBzb21ldGhpbmcgeW91IGFuZCB5b3VyIGNvLWF1dGhvcnMgc2hvdWxkIGRpc2N1c3Mg aW4gZHJhZnQtaWV0Zi1pZHItcmZjNTU3NWJpcy4gRXZlbiB0aG91Z2ggdGhlIGRyYWZ0IGlzIG11 Y2ggY2xvc2VyDQogdG8gcHVibGljYXRpb24sIHlvdSBjb3VsZCBhZGRyZXNzIHRoZSAmbmJzcDt1 c2UgY2FzZSBnZW5lcmljYWxseSB3aXRoIGFuIGluZm9ybWF0aXZlIHJlZmVyZW5jZS4mbmJzcDs8 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoYW5rcyw8L2Rpdj4NCjxkaXY+QWNlZSZu YnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VD VElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsg dGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7 IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1M RUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29s aWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4g c3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5JZHIgJmx0OzxhIGhyZWY9Im1h aWx0bzppZHItYm91bmNlc0BpZXRmLm9yZyI+aWRyLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBv biBiZWhhbGYgb2YgUm9iZXJ0IFJhc3p1ayAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvYmVydEByYXN6 dWsubmV0Ij5yb2JlcnRAcmFzenVrLm5ldDwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQt d2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5GcmlkYXksIEp1bHkgMjgsIDIwMTcgYXQgOToyMCBB TTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPiZxdW90O0p1 YW4gQWxjYWlkZSAoamFsY2FpZGUpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86amFsY2FpZGVA Y2lzY28uY29tIj5qYWxjYWlkZUBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJm b250LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPklEUiBMaXN0ICZsdDs8YSBocmVmPSJtYWlsdG86 aWRyQGlldGYub3JnIj5pZHJAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250 LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFtJZHJdIGRyYWZ0LWxpdGtvd3NraS1p ZHItZmxvd3NwZWMtaW50ZXJmYWNlc2V0ID0mZ3Q7IE5MUkkgdnMgRVhUQ1QgKHBhcnQgMik8YnI+ DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tf QVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29s aWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRp diBkaXI9Imx0ciI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQo8ZGl2IGNsYXNzPSJnbWFp bF9xdW90ZSI+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1 b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7 cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IHRleHQ9IiMwMDAwMDAiIGJnY29sb3I9IiNGRkZGRkYi Pg0KPGRpdiBjbGFzcz0ibV8xOTcyOTU2MTI0MTgyNTI3MDc0bW96LWNpdGUtcHJlZml4Ij5JIGFs c28gYWdyZWUgdGhhdCB1c2Ugb2YgUkQgd291bGQgd29yay4gQnV0IHdlIGNhbm5vdCB1c2UgU0FG SSAxMzQgaWYgYWxsIHdlIGhhdmUgaXMgcGxhaW4gSVB2NDxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVs dCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6 ZTpzbWFsbCI+DQrigItXaHkgbm90ID8gV2hpbGUgb3JpZ2luYWwgaW50ZW50aW9uIG9mIFNBRkkg MTM0IHdhcyB0byBiZSB1c2VkIHdpdGggVlBOcyB0aGVyZSBpcyBub3RoaW5nIHdoaWNoIHByZXZl bnRzIHRvIHVzZSBpdCBmb3IgJnF1b3Q7Z2xvYmFsJnF1b3Q7IHRhYmxlLiBKdXN0IGltcG9ydCB0 aGUgZmlsdGVycyB3aXRoIFJUIGNvcnJlc3BvbmRpbmcgdG8gZ2xvYmFsIFZSRiA6KSZuYnNwOzwv ZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFs LGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQo8YnI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRp Y2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KVGh4LDwvZGl2Pg0KPGRpdiBjbGFzcz0i Z21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNl cmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQpSLjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_D5A0BE1BBA569aceeciscocom_-- From nobody Fri Jul 28 07:20:24 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82404131D32 for ; Fri, 28 Jul 2017 07:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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 exyCHJZyOUD4 for ; Fri, 28 Jul 2017 07:20:21 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 600FF131FC1 for ; Fri, 28 Jul 2017 07:20:21 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id h199so97891513ith.0 for ; Fri, 28 Jul 2017 07:20:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=EBXYSTiUzIrDEhpXWDRxwd4fFCnd5Zr5TWzU8laUtEQ=; b=hDfHkc0v5BkmsVTmi+AVmWetnFZ3SEuZBHCxWzXVMNufmzvy0ApZ94YAGS7UMYkz9E LcvYEKtBZcRKRhfcfrVrTIz9XD6pQj5xKolAjATbaIbXle5VMYqRv97pmAJsDfE8iR/+ yNRwYiL1uSe+OaPz2vhxfkU+RXendq+R9Ao8Vzw/ZxcvpKDCHBJ5a/lxy2EE5+sScvij w2ggHBV4dWuQmI4ggmD6mV6snmdRsJ0YGZ1OIsfWzV4eB7MXncWyDcqn3qyjrJmnAC6p XBK3xCEuayBre3DhxhnuiwiNEZPFFT9RRN6OLCzwmPymy1k1es0QoTvT4iBJKGgRLW20 YBZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=EBXYSTiUzIrDEhpXWDRxwd4fFCnd5Zr5TWzU8laUtEQ=; b=rtGtAspI5q9Wwqipder4VFAyYe+ofB8sG6QD4VMRB377TzI6FKxxBJc0Vqn+dlZRV1 Tj0Wkdv6ztKhYPGb9IhVqFL4BGuDLwMD88JUdJ+cx/MFnPIOJedqAkjpi9UW5qqVJPT6 MgezTMtIXe4zs6jhcAaEnHrcCuC3V9mu6t1DLnxdYDwF9nTrb32xz9L3rtgGKxxHAqPH II7SZMB5JPB5Mel9eWoODY4EjfR1u8DTgByvjvkxqfGzoZ8Hy0EiD6afKmj+I2yvyinZ gmE07mlkbHX7birq881AOudP7Kvfg3BvCu7fvLJqqv7uh1Ke98VrbtTYPnAV81IxZCwZ 3l1g== X-Gm-Message-State: AIVw113LsKD3yF9p5kzzxz46b09WSg3P/MPNlyqRm9DQCWjFQRLO7KuH 6TxpFHJg+aEbz1vNklg1NMo65zkVm41F X-Received: by 10.36.200.5 with SMTP id w5mr9630331itf.118.1501251620501; Fri, 28 Jul 2017 07:20:20 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.153.21 with HTTP; Fri, 28 Jul 2017 07:20:19 -0700 (PDT) In-Reply-To: References: <9fa67eb0-8f99-a46f-aff1-d42a279ab833@cisco.com> <8dd3e766b58944a3b176fc743e478137@XCH-ALN-014.cisco.com> From: Robert Raszuk Date: Fri, 28 Jul 2017 16:20:19 +0200 X-Google-Sender-Auth: WFsLsmuSI0kRpuRiDNCpNuHOEhI Message-ID: To: "Acee Lindem (acee)" Cc: "Juan Alcaide (jalcaide)" , idr wg Content-Type: multipart/alternative; boundary="94eb2c05f77a8f0215055561619c" Archived-At: Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT (part 2) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 14:20:23 -0000 --94eb2c05f77a8f0215055561619c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Acee, Not really :( RFC5575bis goal is to *only* provide minimum changes to existing running code and just clarify text of original RFC5575 in few paragraphs. We had this discussion already and we all agreed among authors that all major changes should happen either in Flow-Spec-v2 or separate drafts. Kind regards, Robert. On Fri, Jul 28, 2017 at 4:16 PM, Acee Lindem (acee) wrote: > Hi Robert, > > If we agree that Juan=E2=80=99s suggestion to use an RD to differentiate = identical > Flow Spec NLRIs with different group interface-ids, it would be something > you and your co-authors should discuss in draft-ietf-idr-rfc5575bis. Even > though the draft is much closer to publication, you could address the us= e > case generically with an informative reference. > > Thanks, > Acee > > From: Idr on behalf of Robert Raszuk < > robert@raszuk.net> > Date: Friday, July 28, 2017 at 9:20 AM > To: "Juan Alcaide (jalcaide)" > Cc: IDR List > Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset =3D> NLRI vs > EXTCT (part 2) > > > >> I also agree that use of RD would work. But we cannot use SAFI 134 if al= l >> we have is plain IPv4 >> > > =E2=80=8BWhy not ? While original intention of SAFI 134 was to be used wi= th VPNs > there is nothing which prevents to use it for "global" table. Just import > the filters with RT corresponding to global VRF :) > > Thx, > R. > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > --94eb2c05f77a8f0215055561619c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Acee,

Not really :(=C2=A0

RFC5575bis goal is to *only* provide minimum changes t= o existing running code and just clarify text of original RFC5575 in few pa= ragraphs.=C2=A0

We had= this discussion already and we all agreed among authors that all major cha= nges should happen either in Flow-Spec-v2 or separate drafts.=C2=A0

Kind regards,
Robert.

=C2= =A0

On= Fri, Jul 28, 2017 at 4:16 PM, Acee Lindem (acee) <acee@cisco.com> wrote:
Hi Robert,=C2=A0

If we agree that Juan=E2=80=99s suggestion to use an RD to differentia= te identical Flow Spec NLRIs with different group interface-ids, it would b= e something you and your co-authors should discuss in draft-ietf-idr-rfc557= 5bis. Even though the draft is much closer to publication, you could address the =C2=A0use case generically with an i= nformative reference.=C2=A0

Thanks,
Acee=C2=A0

From: Idr <idr-bounces@ietf.org> on behalf= of Robert Raszuk <robert@raszuk.net>
Date: Friday, July 28, 2017 = at 9:20 AM
To: "Juan Alcaide (jalcaide)&q= uot; <jalcaide@c= isco.com>
Cc: IDR List <idr@ietf.org>
Subject: Re: [Idr] draft-litkowski-= idr-flowspec-interfaceset =3D> NLRI vs EXTCT (part 2)

=C2=A0
I= also agree that use of RD would work. But we cannot use SAFI 134 if all we= have is plain IPv4

=E2=80=8BWhy not ? While original intention of SAFI 134 was to be used with= VPNs there is nothing which prevents to use it for "global" tabl= e. Just import the filters with RT corresponding to global VRF :)=C2=A0

Thx,
R.

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


--94eb2c05f77a8f0215055561619c-- From nobody Fri Jul 28 07:47:48 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0B4E129AAD for ; Fri, 28 Jul 2017 07:47: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, 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 UnwGc4CjKKt1 for ; Fri, 28 Jul 2017 07:47:45 -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 57718129417 for ; Fri, 28 Jul 2017 07:47:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3337; q=dns/txt; s=iport; t=1501253265; x=1502462865; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=FR/8nirYadBBpQ/p54/IMVA0bJF+cv4iP/6Ll2kI5zs=; b=XdQwILV+QBYR/h/lvZKqtFQnh/ei4laE+XTCMv6slesBRntXqq1nHmyp mvFQaD1BYCPGWX5MqYVkUPQli0C+8ftTJQJQx0EiaICsmHmz+JTJtk3ra UMKLTQ1/8BqqUPMrf4Yiqxisn0OyMzkm3qMVCI6AG/1I79TzmloLa9n0E s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAQB8TXtZ/49dJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1qBUY40j3qBa5BchS+CEoVHAoNwPxgBAgEBAQEBAQFrKIUZAQUjVhA?= =?us-ascii?q?LBBQqAgJXBg0IAQGKK65sgiYnixgBAQEBAQEBAQEBAQEBAQEBAQEBAQEdgyiDT?= =?us-ascii?q?YFhK4J8iAaCYQEEn20ClCSLM4cJjQ2IZR84gQp3FYdkPoo2AQEB?= X-IronPort-AV: E=Sophos;i="5.40,425,1496102400"; d="scan'208,217";a="275824719" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Jul 2017 14:47:44 +0000 Received: from [10.82.210.242] (rtp-vpn4-754.cisco.com [10.82.210.242]) (authenticated bits=0) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v6SElgcq027031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 28 Jul 2017 14:47:44 GMT To: Robert Raszuk Cc: idr wg References: <9fa67eb0-8f99-a46f-aff1-d42a279ab833@cisco.com> <8dd3e766b58944a3b176fc743e478137@XCH-ALN-014.cisco.com> From: "Juan Alcaide (jalcaide)" Message-ID: Date: Fri, 28 Jul 2017 16:47:42 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E6E17F4E7854CEB79BB90F72" Content-Language: en-US X-Authenticated-User: jalcaide Archived-At: Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT (part 2) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 14:47:47 -0000 This is a multi-part message in MIME format. --------------E6E17F4E7854CEB79BB90F72 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Not that it cannot be done. We could deprecate SAFI 133 ;-) But you would have to reserve a particular set of RDs for a set of group-ids, and repeat this for every VRF Isn't much simpler to just add an extra discriminator for interface-set (let's call it IFD) ? -J On 7/28/2017 3:20 PM, Robert Raszuk wrote: > > I also agree that use of RD would work. But we cannot use SAFI 134 > if all we have is plain IPv4 > > > ​Why not ? While original intention of SAFI 134 was to be used with > VPNs there is nothing which prevents to use it for "global" table. > Just import the filters with RT corresponding to global VRF :) > > Thx, > R. --------------E6E17F4E7854CEB79BB90F72 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Not that it cannot be done. We could deprecate SAFI 133 ;-)

But you would have to reserve a particular set of RDs for a set of group-ids, and repeat this for every VRF

Isn't much simpler to just add an extra discriminator for interface-set (let's call it IFD) ?

-J

On 7/28/2017 3:20 PM, Robert Raszuk wrote:
 
I also agree that use of RD would work. But we cannot use SAFI 134 if all we have is plain IPv4

​Why not ? While original intention of SAFI 134 was to be used with VPNs there is nothing which prevents to use it for "global" table. Just import the filters with RT corresponding to global VRF :) 

Thx,
R.


--------------E6E17F4E7854CEB79BB90F72-- From nobody Fri Jul 28 09:41:29 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0983A132170 for ; Fri, 28 Jul 2017 09:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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 MmddyNCjW2Tr for ; Fri, 28 Jul 2017 09:41:26 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::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 940AF13216F for ; Fri, 28 Jul 2017 09:41:26 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id e75so19574510pfj.2 for ; Fri, 28 Jul 2017 09:41:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ttCu3KHXC08mW6dedAz0z1hvOLPbJarHZHF2Ca4y+ns=; b=Sm0wkIU7LYYRMWnbiq6v77W3+fL96ey+zq6oZeOCTZTHLCJk34FR1Ux8Yff9UbTWRs VXYRvXM15qFo45pJVWjrX9cC56W6mOPxfLijske/Hg6Ky/LEiYETbtDj1ksvm1/WqIYq mcIUrQ9G8E2dpgrq3fP12+xOx4Qnz/0+4UR5eZEWUSuNCrStlr+L3rJdLqO8pYiFK01l sx8qSgFlQ1CVwZ/GmsWWMkkI1O72z/wD4GpqKxPU4XDYXbvUt4rqorRHU6yNa7Z7yPPo AlI2fpZaHUuRPB9L+WKtZfefAPFJmtghGlOu8B8CrWWqNyfOA2oDuxDxUBtnIt1vZJAz GZDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ttCu3KHXC08mW6dedAz0z1hvOLPbJarHZHF2Ca4y+ns=; b=WIDdl9apGCIhqrNzX4kT/QN1rBJS6Dj/jGmNdr2pRbM0RLFSyv4Pu9ad9Ebr4y7QyB qpJMPACZj1YouBGWfb0e1Az4gUtptoWkO002oPGHq+doPxl+qM2/6m67Mf5AJD9PSfHT dhgFdudYJIEeB2vyrrMW3ihof1Psa8/aLu2RVif8Lm+7uEJz2GgfQ0R02dCamj59X9e7 dweNWnQDCP/GgdoimpAT0KizauCpm3oJodyU+K9uOXY8ACl+LAKWDE4eC0ORlBrvkCxV cc2MGKCt8rWP5JOsykRrC8CIhTeRkqhVUkjNft0wsXDte2nyoj0oCbt4eFv8naijsqlK ktrg== X-Gm-Message-State: AIVw111LwN1NCxm7EDBdnjhAfklLRpdKvxbXLmox1tUwtu62VeJqpG0n gYUjKvEFO2KjviltktQIYuaj6dOXhA== X-Received: by 10.84.130.46 with SMTP id 43mr8429596plc.101.1501260085985; Fri, 28 Jul 2017 09:41:25 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.100.237.70 with HTTP; Fri, 28 Jul 2017 09:41:25 -0700 (PDT) In-Reply-To: References: <9fa67eb0-8f99-a46f-aff1-d42a279ab833@cisco.com> <8dd3e766b58944a3b176fc743e478137@XCH-ALN-014.cisco.com> From: Robert Raszuk Date: Fri, 28 Jul 2017 18:41:25 +0200 X-Google-Sender-Auth: VBC8vbz61gzXN_qJeGDLtJsH26k Message-ID: To: "Juan Alcaide (jalcaide)" Cc: idr wg Content-Type: multipart/alternative; boundary="94eb2c12f9522407dc0555635a71" Archived-At: Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT (part 2) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 16:41:28 -0000 --94eb2c12f9522407dc0555635a71 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > Not that it cannot be done. We could deprecate SAFI 133 ;-) > =E2=80=8BThat's not needed. =E2=80=8B > But you would have to reserve a particular set of RDs for a set of > group-ids, and repeat this for every VRF > =E2=80=8BRDs can contain router_id =E2=80=8Bwhat makes then unique within d= omain. And this is their only use - to make NLRI unique. You do not need to reserve anything. On any box you have 2^32 values to use - should be more then enough. And there is no need to have any VRFs either !!! Think of global table with table_id 0 as the only "VRF" needed here. A lot of folks think that VPNs must equal MPLS or must equal VRFs ... Here we can use control plane and SAFI 134 to accomodate needs of global table. =E2=80=8B//RR. --94eb2c12f9522407dc0555635a71 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Not that it cannot be done. = We could deprecate SAFI 133 ;-)

=E2=80=8BThat's not needed. =E2=80=8B

=C2=A0
But = you would have to reserve a particular set of RDs for a set of group-ids, and repeat this for every VRF
=


=E2=80=8BRDs can cont= ain router_id =E2=80=8Bwhat makes then unique within domain. And this is th= eir only use - to make NLRI unique. You do not need to reserve anything. On= any box you have 2^32 values to use - should be more then enough.=C2=A0

And there is no need to = have any VRFs either !!! =C2=A0

Think of global table with table_id 0 as the only "VRF"= needed here.=C2=A0

A = lot of folks think that VPNs must equal MPLS or must equal VRFs ... Here we= can use control plane and SAFI 134 to accomodate needs of global table.=C2= =A0

=E2=80=8B//RR.
<= br>

--94eb2c12f9522407dc0555635a71-- From nobody Fri Jul 28 09:54:43 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42AC012EE45 for ; Fri, 28 Jul 2017 09:54:41 -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 jmlmx2TZDz07 for ; Fri, 28 Jul 2017 09:54:39 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72A5D12EB5D for ; Fri, 28 Jul 2017 09:54:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6994; q=dns/txt; s=iport; t=1501260879; x=1502470479; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=j45EnLb5PdcfnOU6hVIKyRL/c7hTQWDBOzf/Jhbb5bw=; b=baSVRmZH/TjF/gMIiwpM2k+6jO78PrYERkv2i5TTcODAUh76c6l5CxTw HhjhxbLAabhOJDfSOQaz2BBPUulpohJZD5vWixekzO+H6tDlr5vCEiiDS RatWGxu8RgvRVRIN4EGyo1BiZR9EtFaymJki306VUciaEjS41oOgMixz/ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CxBAD5a3tZ/5RdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1qBUZ4ugWuQXIdBhUcCg3JDFAECAQEBAQEBAWsohRkBBSNWEAsYKgI?= =?us-ascii?q?CVwYNCAEBiiuwJYImJ4sYAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYMog02BYSuCf?= =?us-ascii?q?IgGgmEFn20ClCSLM4cJjQ2IZTYhgQp3FYVkF4FpPoo2AQEB?= X-IronPort-AV: E=Sophos;i="5.40,425,1496102400"; d="scan'208,217";a="278854482" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Jul 2017 16:54:24 +0000 Received: from [10.82.226.238] (rtp-vpn1-750.cisco.com [10.82.226.238]) (authenticated bits=0) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v6SGsMxW000625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 28 Jul 2017 16:54:23 GMT To: Robert Raszuk Cc: idr wg References: <9fa67eb0-8f99-a46f-aff1-d42a279ab833@cisco.com> <8dd3e766b58944a3b176fc743e478137@XCH-ALN-014.cisco.com> From: "Juan Alcaide (jalcaide)" Message-ID: <806a82b2-36bd-70d2-a37f-8377fd37f4c9@cisco.com> Date: Fri, 28 Jul 2017 18:54:21 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------935424DB41B381DC90A21019" Content-Language: en-US X-Authenticated-User: jalcaide Archived-At: Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT (part 2) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 16:54:41 -0000 This is a multi-part message in MIME format. --------------935424DB41B381DC90A21019 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit You mean we don't need to deprecate SAFI 133 or that SAFI 133 is not needed? Yes.. RD makes them unique in the domain, but my point is that now you need them for more than for VPN discrimination. You need grou-id discrimination Imagine a PE has reserved RD:1.1.1.1:1, RD:1.1.1.1:2, RD, 1.1.1.1:3 for regular VPN configuration. I assume you would use those RDs for FS rules not associated to any interfaces (SAFI 134) Then you want to use SAFI 134 for rules in the global table with group-id info (let's say you have just 2 different group-ids). You need RD:1.1.1.1:101, RD:1.1.1.102. If you also want group-ids for the VPNs, you would needRD:1.1.1.1:211, RD:1.1.1.1:212, RD:1.1.1.1:221, RD:1.1.1.1:222, RD:1.1.1.1:231, RD:1.1.1.1:232. It's a provisioning nightmare I just think we should use one discriminator for each function. -J On 7/28/2017 6:41 PM, Robert Raszuk wrote: > > Not that it cannot be done. We could deprecate SAFI 133 ;-) > > > ​That's not needed. ​ > > But you would have to reserve a particular set of RDs for a set of > group-ids, and repeat this for every VRF > > > > ​RDs can contain router_id ​what makes then unique within domain. And > this is their only use - to make NLRI unique. You do not need to > reserve anything. On any box you have 2^32 values to use - should be > more then enough. > > And there is no need to have any VRFs either !!! > > Think of global table with table_id 0 as the only "VRF" needed here. > > A lot of folks think that VPNs must equal MPLS or must equal VRFs ... > Here we can use control plane and SAFI 134 to accomodate needs of > global table. > > ​//RR. > > --------------935424DB41B381DC90A21019 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
You mean we don't need to deprecate SAFI 133 or that SAFI 133 is not needed?

Yes.. RD makes them unique in the domain, but my point is that now you need them for more than for VPN discrimination.   You need grou-id discrimination

Imagine a PE has reserved RD:1.1.1.1:1,  RD:1.1.1.1:2, RD, 1.1.1.1:3  for regular VPN configuration. I assume you would use those RDs for FS rules not associated to any interfaces (SAFI 134)
Then you want to use SAFI 134 for rules in the global table with group-id info (let's say you have just 2 different group-ids). You need RD:1.1.1.1:101, RD:1.1.1.102. If you also want group-ids for the VPNs, you would needRD:1.1.1.1:211, RD:1.1.1.1:212, RD:1.1.1.1:221, RD:1.1.1.1:222, RD:1.1.1.1:231, RD:1.1.1.1:232. It's a provisioning nightmare

I just think we should use one discriminator for each function.

-J




On 7/28/2017 6:41 PM, Robert Raszuk wrote:
Not that it cannot be done. We could deprecate SAFI 133 ;-)

​That's not needed. ​

 
But you would have to reserve a particular set of RDs for a set of group-ids, and repeat this for every VRF


​RDs can contain router_id ​what makes then unique within domain. And this is their only use - to make NLRI unique. You do not need to reserve anything. On any box you have 2^32 values to use - should be more then enough. 

And there is no need to have any VRFs either !!!  

Think of global table with table_id 0 as the only "VRF" needed here. 

A lot of folks think that VPNs must equal MPLS or must equal VRFs ... Here we can use control plane and SAFI 134 to accomodate needs of global table. 

​//RR.



--------------935424DB41B381DC90A21019-- From nobody Fri Jul 28 10:07:22 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54CD813217E for ; Fri, 28 Jul 2017 10:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.397 X-Spam-Level: X-Spam-Status: No, score=-2.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, WEIRD_PORT=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 8Rvj6j28IEO5 for ; Fri, 28 Jul 2017 10:07:19 -0700 (PDT) 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 0925F131748 for ; Fri, 28 Jul 2017 10:07:18 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id h199so100157011ith.0 for ; Fri, 28 Jul 2017 10:07:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=huR6KeS79bBJ7dTRsbLr71YGw8fwX+nEZ9PiTxtOQao=; b=pTxZBQ3P5qpxMWiYrq2rClyxfRWjBV0mWEO75+w/pr/Tx6ntU2OczYm3xIuEKUEumq KE+Pr+iwM8cgz+1RS/ZTsEsoMWwz5dGaio+p/6KERvmllRfKHIm7Ky4ibFA+A2o0xHoR P9bjOHODNbI5iDQSQKNSkJUc7T+FoLvo7y8+ioGbvQExoaCoy8Pi43Y6yzk5ae+oWXq7 da3UTZvj2M3JaA4OpKIpAFIcg1Nqr7p9ULWf7smqj6fEJZUf7FKtnZCT7APbkrLI+ivQ X05S11D9u6Ofq5I/47pvkYYfKqzZ5fDQwrQA7KRwv+eOClhh3ltC0J5t1R1WQGVsUSS1 5jww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=huR6KeS79bBJ7dTRsbLr71YGw8fwX+nEZ9PiTxtOQao=; b=imVI6wcgNvjZSJ8to0tFS/Gk++vpbnCKsT66dAMdTvqHcULqevVzamPH2f8Dy+CRO2 gnv/JUHRGrIhuih2F+W8zfXXHHe5pPjWrRKRik0kQsgZ3esFn6TUP8f9WbUeJgQ62+ZP NhYAH5KAfJ7j9PvqoEixdthHBSjTinDj6Vy1RbJx2GD+OBNI4fWl4riUgraeQz079bMy V1ZtOAHBYTTZbB1aanJ58uG01X9uMEQODmlEm/kH9JV4UtGN8AbtyUj47tON3H7V3eOz e4E7i0FcMfiG/LIWwwCf9T1Aw73v4UlDkqyLYhFu4bsJv+7VdvsXEOpiiJt7zAtqpqpB pqfA== X-Gm-Message-State: AIVw110umOa2effS08TW6MuU5uttaEA+J6qzKgHPavhgEn5as4/iKFM2 V4nHELzHWRlmPUxJ2ww3HTuZBgnJ6dUY X-Received: by 10.36.105.82 with SMTP id e79mr10406447itc.118.1501261637240; Fri, 28 Jul 2017 10:07:17 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.153.21 with HTTP; Fri, 28 Jul 2017 10:07:16 -0700 (PDT) In-Reply-To: <806a82b2-36bd-70d2-a37f-8377fd37f4c9@cisco.com> References: <9fa67eb0-8f99-a46f-aff1-d42a279ab833@cisco.com> <8dd3e766b58944a3b176fc743e478137@XCH-ALN-014.cisco.com> <806a82b2-36bd-70d2-a37f-8377fd37f4c9@cisco.com> From: Robert Raszuk Date: Fri, 28 Jul 2017 19:07:16 +0200 X-Google-Sender-Auth: c-H9q93DvjvN1nvrphSFG-COiKA Message-ID: To: "Juan Alcaide (jalcaide)" Cc: idr wg Content-Type: multipart/alternative; boundary="001a1145a6b69a4f66055563b6f2" Archived-At: Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT (part 2) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 17:07:21 -0000 --001a1145a6b69a4f66055563b6f2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =E2=80=8BJuan, =E2=80=8B > You mean we don't need to deprecate SAFI 133 > =E2=80=8BYes.=E2=80=8B > Yes.. RD makes them unique in the domain, but my point is that now you > need them for more than for VPN discrimination. You need grou-id > discrimination > > Imagine a PE has reserved RD:1.1.1.1:1, RD:1.1.1.1:2, RD, 1.1.1.1:3 for > regular VPN configuration. I assume you would use those RDs for FS rules > not associated to any interfaces (SAFI 134) > Then you want to use SAFI 134 for rules in the global table with group-id > info (let's say you have just 2 different group-ids). You need RD: > 1.1.1.1:101, RD:1.1.1.102. If you also want group-ids for the VPNs, you > would needRD:1.1.1.1:211, RD:1.1.1.1:212, RD:1.1.1.1:221, RD:1.1.1.1:222, > RD:1.1.1.1:231, RD:1.1.1.1:232. It's a provisioning nightmare > > I just think we should use one discriminator for each function. > It's not the way I look at it. Imagine you are on the controller =E2=80=8Band want to inject for the same = FS NLRI different functions which will apply to different interfaces. So for the second occurrence of same NLRI you auto-assign different local RD to make it unique. Problem solved. Remember "D" in RD stands for distinguisher not discriminator. It plays no role in choosing a VPN nor choosing a group-id at the destinations. RT is used for that. =E2=80=8BThx, R.=E2=80=8B --001a1145a6b69a4f66055563b6f2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=E2=80=8BJuan,
=E2=80=8B
You mean we don't need to d= eprecate SAFI 133

=E2=80=8BYes.=E2=80=8B
=C2=A0
Yes.. RD makes them unique in the domain, = but my point is that now you need them for more than for VPN discrimination.=C2=A0=C2=A0 You n= eed grou-id discrimination

Imagine a PE has reserved RD:1.1.1.1:1,=C2=A0 RD:1.1.1.1:2, RD, 1.1.1.1:3=C2=A0 fo= r regular VPN configuration. I assume you would use those RDs for FS rules not associated to any interfaces (SAFI 134) Then you want to use SAFI 134 for rules in the global table with group-id info (let's say you have just 2 different group-ids). Yo= u need RD:1.1.1.1:101<= /a>, RD:1.1.1.102. If you also want group-ids for the VPNs, you would needRD:1.1.1.1:211, RD:1.1.1.1:212, RD:1.1.1.1:221, = RD:1.1.1.1:222, RD:1.1.1.1:231, RD:1.1.1.1:232. It's a provisioning nightmare

I just think we should use one discriminator for each function.
=

It's not th= e way I look at it.=C2=A0

Imagine you are on the controller =E2=80=8Band want to inject for the s= ame FS NLRI different functions which will apply to different interfaces. S= o for the second occurrence of same NLRI you auto-assign different local RD= to make it unique.=C2=A0

Problem solved.=C2=A0

Remember "D" in RD stands for distinguisher not discriminator= . It plays no role in choosing a VPN nor choosing a group-id at the destina= tions. RT is used for that.=C2=A0

= =E2=80=8BThx,
R.=E2=80=8B

--001a1145a6b69a4f66055563b6f2-- From nobody Fri Jul 28 10:47:34 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20CA71322F5 for ; Fri, 28 Jul 2017 10:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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, NORMAL_HTTP_TO_IP=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, WEIRD_PORT=0.001] 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 HDqgY0jsDwz0 for ; Fri, 28 Jul 2017 10:47:31 -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 113241322F1 for ; Fri, 28 Jul 2017 10:47:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10028; q=dns/txt; s=iport; t=1501264043; x=1502473643; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=XrQszbtGFOmxAWzO4ceTM2hp8q83a288Z14alEA3CZo=; b=Nr3imQh+3nD863XSyUB/0mtqWpRQGA1jJ/c4ISR3CvBJ7r5nNvNhLwMT osSK5QfTAD0/ZGRu/1++yvop4DtBXZuyJF3Om69/v91JpI58S9cpGGqFA gPdHkF3r2M15KnHVHWmj4UOvYgtb1Byx0SjNb5n0zYCwaLXax7RPkD1Ed 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DEAQDQd3tZ/5RdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1pkgRSODY95gUkigmONeYUvghIkg2pVZAJCgzA/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRkBBSMoAS0QCxMFKgICJTIGDQgBAYorsDCCJieDZwGHMAEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAR2DKINNgWErC4JxhD+DR4JhAQSfbQKUJIszhwmNDYhlDxA4gQp?= =?us-ascii?q?3FYVkF4FpPjeJfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.40,427,1496102400"; d="scan'208,217";a="275896640" 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; 28 Jul 2017 17:47:22 +0000 Received: from [10.82.226.238] (rtp-vpn1-750.cisco.com [10.82.226.238]) (authenticated bits=0) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v6SHlJ1X013015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 28 Jul 2017 17:47:21 GMT To: Robert Raszuk Cc: idr wg References: <9fa67eb0-8f99-a46f-aff1-d42a279ab833@cisco.com> <8dd3e766b58944a3b176fc743e478137@XCH-ALN-014.cisco.com> <806a82b2-36bd-70d2-a37f-8377fd37f4c9@cisco.com> From: "Juan Alcaide (jalcaide)" Message-ID: <69816cff-d7ff-3714-c3e7-c504bfe1997c@cisco.com> Date: Fri, 28 Jul 2017 19:47:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------39A9D8EB81057B2F4552F78A" Content-Language: en-US X-Authenticated-User: jalcaide Archived-At: Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT (part 2) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 17:47:33 -0000 This is a multi-part message in MIME format. --------------39A9D8EB81057B2F4552F78A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit This is certainly a possibility. - When any group-id is used, use *always* SAFI 134 - Controller keeps track of all RD it has used and makes sure it uses a different one for each new route it sends Drawbacks - When VPNs are actually used, RD of ipv4 route and RD of FS rule may not be the same of the one of the vpnv4 route. - We have to configure VPN-SAFI in all the routers in the middle (like RR) - If a router acts as controller (via configuration), we have to add auto-assignment of RDs. GR in case the controller/router reboots becomes a challenge I still think that an interface discriminator would make more sense. We would have to change fewer things But this needs to be specified in drafts. Whaever approach, the way draft-litkowski-idr-flowspec-interfaceset is described today is incorrect -J On 7/28/2017 7:07 PM, Robert Raszuk wrote: > ​Juan, > ​ > > You mean we don't need to deprecate SAFI 133 > > > ​Yes.​ > > Yes.. RD makes them unique in the domain, but my point is that now > you need them for more than for VPN discrimination. You need > grou-id discrimination > > Imagine a PE has reserved RD:1.1.1.1:1 , > RD:1.1.1.1:2 , RD, 1.1.1.1:3 > for regular VPN configuration. I assume you would use those RDs > for FS rules not associated to any interfaces (SAFI 134) > Then you want to use SAFI 134 for rules in the global table with > group-id info (let's say you have just 2 different group-ids). You > need RD:1.1.1.1:101 , RD:1.1.1.102. If you > also want group-ids for the VPNs, you would needRD:1.1.1.1:211 > , RD:1.1.1.1:212 , > RD:1.1.1.1:221 , RD:1.1.1.1:222 > , RD:1.1.1.1:231 , > RD:1.1.1.1:232 . It's a provisioning nightmare > > I just think we should use one discriminator for each function. > > > It's not the way I look at it. > > Imagine you are on the controller ​and want to inject for the same FS > NLRI different functions which will apply to different interfaces. So > for the second occurrence of same NLRI you auto-assign different local > RD to make it unique. > > Problem solved. > > Remember "D" in RD stands for distinguisher not discriminator. It > plays no role in choosing a VPN nor choosing a group-id at the > destinations. RT is used for that. > > ​Thx, > R.​ > --------------39A9D8EB81057B2F4552F78A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
This is certainly a possibility.

- When any group-id is used, use *always* SAFI 134
-  Controller keeps track of all RD it has used and makes sure it uses a different one for each new route it sends

Drawbacks
- When VPNs are actually used, RD of ipv4 route and RD of FS rule may not be the same of the one of the vpnv4 route.
- We have to configure VPN-SAFI in all the routers in the middle (like RR)
- If a router acts as controller (via configuration), we have to add auto-assignment of RDs. GR in case the controller/router reboots becomes a challenge

I still think that an interface discriminator would make more sense. We would have to change fewer things
But this needs to be specified  in drafts. Whaever approach, the way draft-litkowski-idr-flowspec-interfaceset is described today is incorrect

-J


On 7/28/2017 7:07 PM, Robert Raszuk wrote:
​Juan,
​
You mean we don't need to deprecate SAFI 133

​Yes.​
 
Yes.. RD makes them unique in the domain, but my point is that now you need them for more than for VPN discrimination.   You need grou-id discrimination

Imagine a PE has reserved RD:1.1.1.1:1,  RD:1.1.1.1:2, RD, 1.1.1.1:3  for regular VPN configuration. I assume you would use those RDs for FS rules not associated to any interfaces (SAFI 134)
Then you want to use SAFI 134 for rules in the global table with group-id info (let's say you have just 2 different group-ids). You need RD:1.1.1.1:101, RD:1.1.1.102. If you also want group-ids for the VPNs, you would needRD:1.1.1.1:211, RD:1.1.1.1:212, RD:1.1.1.1:221, RD:1.1.1.1:222, RD:1.1.1.1:231, RD:1.1.1.1:232. It's a provisioning nightmare

I just think we should use one discriminator for each function.

It's not the way I look at it. 

Imagine you are on the controller ​and want to inject for the same FS NLRI different functions which will apply to different interfaces. So for the second occurrence of same NLRI you auto-assign different local RD to make it unique. 

Problem solved. 

Remember "D" in RD stands for distinguisher not discriminator. It plays no role in choosing a VPN nor choosing a group-id at the destinations. RT is used for that. 

​Thx,
R.​


--------------39A9D8EB81057B2F4552F78A-- From nobody Fri Jul 28 10:58:32 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B20D1322EC for ; Fri, 28 Jul 2017 10:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.697 X-Spam-Level: X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, WEIRD_PORT=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 RjsODPfH2Xh4 for ; Fri, 28 Jul 2017 10:58:29 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::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 00754131D10 for ; Fri, 28 Jul 2017 10:58:28 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id h199so100601567ith.1 for ; Fri, 28 Jul 2017 10:58:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=xSxAxNevw+GRoPilIx4OLuQBip/ueBZA2WaqWf6itik=; b=HkhWmIOy6E3xI9Gr4+2UCILtSNLrBvLKfNvt1X/gu3EVTXIdKG/FO2QxuFHiOVM5UL r7iHZ6sw7UkZP6+MxZPKgCjQjFpf6mZS5RJGd1Dge7kaSy18wQ03oRlyMxTEleRBknYW qnBmoCsooFoV+UbYRAAL5KS0/6ndOPjVm4z6tbYLWII/tNssrqxQNfExb10VpZqpQWGD NPgEHaZWhpWWY7P6Cud35LEnxTBmdheWMh/U30yJGhrOTSRd8ISwlr7aEgnXFvqa33RE J8oSY/Rsd/XyVcEVOhgX283nNjzR1BIrgB92hIMMFWZlsrfGzZd8fS1OmTSzbOyDgC51 3s8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=xSxAxNevw+GRoPilIx4OLuQBip/ueBZA2WaqWf6itik=; b=K/LxSKw+g4VEFTX5Z4Ic9WWuDUPyQVWNj/abCwo2P0g1KkthoxbHyr2vU51baBcp+9 A5jnraHxeWQ1STv7a6jM4nN7XazsbK6rp/C9Rm7i36VqyMD1lLGT4kH+5ISVHKvWkVpi AO+FRnjzGZEoSNu59tVLSFIkVP5s4di4oWHt0LIA+6Z4U+d//iWm67c24LkFTlbE2/Ej 524q8fTluqt1QMxM8TeslyyklvzvAdDZNOkF8Jlif0KSy8CZRn/ye4p2ECSFMDVHjM44 LTlUJsRO7OwQ9UtWhfuM6R02OasElFFmTwgHmbnG42q5NRpSaNUdm7FJX5QsbvGvfcMg ixyQ== X-Gm-Message-State: AIVw112VvqA368BtEZgy91l+8DunrU3WI6/Sny+aNUTD01bk0kwRSdyU CfvjwU6OqFLDZeXzdQeYj91C6UBbPw== X-Received: by 10.36.253.71 with SMTP id m68mr9669921ith.16.1501264707706; Fri, 28 Jul 2017 10:58:27 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.153.21 with HTTP; Fri, 28 Jul 2017 10:58:26 -0700 (PDT) In-Reply-To: <69816cff-d7ff-3714-c3e7-c504bfe1997c@cisco.com> References: <9fa67eb0-8f99-a46f-aff1-d42a279ab833@cisco.com> <8dd3e766b58944a3b176fc743e478137@XCH-ALN-014.cisco.com> <806a82b2-36bd-70d2-a37f-8377fd37f4c9@cisco.com> <69816cff-d7ff-3714-c3e7-c504bfe1997c@cisco.com> From: Robert Raszuk Date: Fri, 28 Jul 2017 19:58:26 +0200 X-Google-Sender-Auth: ZrLRmS_FShc5_58fBQSBOJLjnKU Message-ID: To: "Juan Alcaide (jalcaide)" Cc: idr wg Content-Type: multipart/alternative; boundary="94eb2c11ce4a9de6b50555646d29" Archived-At: Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT (part 2) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 17:58:31 -0000 --94eb2c11ce4a9de6b50555646d29 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Juan, Looks like we have reached the point of some agreement :) Two last comments from me. You can discuss choice of solutions with authors of draft-litkowski. > - Controller keeps track of all RD it has used and makes sure it uses a different one for each new route it sends It should use different one for each new duplicated route it sends - not for each new route as such. Those all can be used with the same RD. > Whaever approach, the way draft-litkowski-idr-flowspec-interfaceset is described today is incorrect I would not go that far. It is correct if you *only* assume that group-id is *only* used to limit the scope of application of global flow-spec route. IMHO it was specifically written with that assumption in mind and with such assumption in mind the draft is still correct. The draft may explicitly state that given NLRI can be used only once and that subsequent update has the normal semantics of being an implicit withdraw. If you have customers who require different actions for the same match criteria perhaps you can provide solution in a different draft or just use SAFI 134 as already discussed. Cheers, Robert. On Fri, Jul 28, 2017 at 7:47 PM, Juan Alcaide (jalcaide) wrote: > This is certainly a possibility. > > - When any group-id is used, use *always* SAFI 134 > - Controller keeps track of all RD it has used and makes sure it uses a > different one for each new route it sends > > Drawbacks > - When VPNs are actually used, RD of ipv4 route and RD of FS rule may not > be the same of the one of the vpnv4 route. > - We have to configure VPN-SAFI in all the routers in the middle (like RR= ) > - If a router acts as controller (via configuration), we have to add > auto-assignment of RDs. GR in case the controller/router reboots becomes = a > challenge > > I still think that an interface discriminator would make more sense. We > would have to change fewer things > But this needs to be specified in drafts. Whaever approach, the way > draft-litkowski-idr-flowspec-interfaceset is described today is incorrect > > -J > > > > On 7/28/2017 7:07 PM, Robert Raszuk wrote: > > =E2=80=8BJuan, > =E2=80=8B > >> You mean we don't need to deprecate SAFI 133 >> > > =E2=80=8BYes.=E2=80=8B > > >> Yes.. RD makes them unique in the domain, but my point is that now you >> need them for more than for VPN discrimination. You need grou-id >> discrimination >> >> Imagine a PE has reserved RD:1.1.1.1:1, RD:1.1.1.1:2, RD, 1.1.1.1:3 >> for regular VPN configuration. I assume you would use those RDs for FS >> rules not associated to any interfaces (SAFI 134) >> Then you want to use SAFI 134 for rules in the global table with group-i= d >> info (let's say you have just 2 different group-ids). You need RD: >> 1.1.1.1:101, RD:1.1.1.102. If you also want group-ids for the VPNs, you >> would needRD:1.1.1.1:211, RD:1.1.1.1:212, RD:1.1.1.1:221, RD:1.1.1.1:222= , >> RD:1.1.1.1:231, RD:1.1.1.1:232. It's a provisioning nightmare >> >> I just think we should use one discriminator for each function. >> > > It's not the way I look at it. > > Imagine you are on the controller =E2=80=8Band want to inject for the sam= e FS NLRI > different functions which will apply to different interfaces. So for the > second occurrence of same NLRI you auto-assign different local RD to make > it unique. > > Problem solved. > > Remember "D" in RD stands for distinguisher not discriminator. It plays n= o > role in choosing a VPN nor choosing a group-id at the destinations. RT is > used for that. > > =E2=80=8BThx, > R.=E2=80=8B > > > --94eb2c11ce4a9de6b50555646d29 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Juan,

Looks like we have reached the point of some agreeme= nt :)=C2=A0

Two last c= omments from me. You can discuss choice of solutions with authors of draft-= litkowski.=C2=A0


<= /div>
>=C2=A0-=C2=A0 Controller keeps track of all RD it has used a= nd makes sure it uses a different one for each new route it sends

It should use different one for each new du= plicated route it sends - not for each new route as such. Those all can be = used with the same RD.=C2=A0


>=C2=A0Whaever approach, the way draft-litkowski-idr-f= lowspec-interfaceset= is described today is incorrect

<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small">I would not go that far. It is correct if you *only* assu= me that group-id is *only* used to limit the scope of application of global= flow-spec route. IMHO it was specifically written with that assumption in = mind and with such assumption in mind the draft is still correct.=C2=A0

The draft may explicitly = state that given NLRI can be used only once and that subsequent update has = the normal semantics of being an implicit withdraw. If you have customers w= ho require different actions for the same match criteria perhaps you can pr= ovide solution in a different draft or just use SAFI 134 as already discuss= ed.=C2=A0

Cheers,
R= obert.

<= br>
On Fri, Jul 28, 2017 at 7:47 PM, Juan Alcaide= (jalcaide) <jalcaide@cisco.com> wrote:
=20 =20 =20
This is certainly a= possibility.

- When any group-id is used, use *always* SAFI 134
-=C2=A0 Controller keeps track of all RD it has used and makes sure i= t uses a different one for each new route it sends

Drawbacks
- When VPNs are actually used, RD of ipv4 route and RD of FS rule may not be the same of the one of the vpnv4 route.
- We have to configure VPN-SAFI in all the routers in the middle (like RR)
- If a router acts as controller (via configuration), we have to add auto-assignment of RDs. GR in case the controller/router reboots becomes a challenge

I still think that an interface discriminator would make more sense. We would have to change fewer things
But this needs to be specified=C2=A0 in drafts. Whaever approach, the way draft-litkowski-idr-flowspec-interfaceset is described today is incorrect

-J



On 7/28/2017 7:07 PM, Robert Raszuk wrote:
=20
=E2=80=8BJuan,
=E2=80=8B
You mean we don't need to deprecate SAFI 133

=E2=80=8BYes.=E2=80=8B
=C2=A0
Yes.. RD makes them unique in the domain, but my point is that now you need them for more than for VPN discrimination.=C2=A0=C2=A0 You need grou-id discriminati= on

Imagine a PE has reserved RD:1.1.1.1:1,=C2=A0 RD:1.1.1.1:2, RD, 1.1.1.1:3=C2=A0 for regular VPN configuration. I assume you would use those RDs for FS rules not associated to any interfaces (SAFI 134)
Then you want to use SAFI 134 for rules in the global table with group-id info (let's say you have just 2 different group-ids). You need RD:1.1.1.1:101, RD:1.1.1.102. If you also want group-ids for the VPNs, you would needRD:1.1.1.1:211, RD:1.1.1= .1:212, RD:1.1.1.1:221= , RD:1.1.1.1:222, = RD:1.1.1.1:231, RD:1.1.1.1:232. It's a provisioning nightmare

I just think we should use one discriminator for each function.

It's not the way I look at it.=C2=A0

Imagine you are on the controller =E2=80=8Band want to inject for t= he same FS NLRI different functions which will apply to different interfaces. So for the second occurrence of same NLRI you auto-assign different local RD to make it unique.=C2=A0

Problem solved.=C2=A0

Remember "D" in RD stands for distinguisher not discrimina= tor. It plays no role in choosing a VPN nor choosing a group-id at the destinations. RT is used for that.=C2=A0

=E2=80=8BThx,
R.=E2=80=8B



--94eb2c11ce4a9de6b50555646d29-- From nobody Fri Jul 28 11:23:02 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 928A7131CAD for ; Fri, 28 Jul 2017 11:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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, NORMAL_HTTP_TO_IP=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, WEIRD_PORT=0.001] 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 5fMIbfVSM23d for ; Fri, 28 Jul 2017 11:22:58 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0671F1318A2 for ; Fri, 28 Jul 2017 11:22:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20682; q=dns/txt; s=iport; t=1501266177; x=1502475777; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=YcMwMw0D/ddPeP2qGcmUF1QHvR4O/zlSApCs/3Q97Lw=; b=JFfZxku4JCgrNoYAr8Jr6eHRev0hWZlvFGXzzjy1h/CRQF6TJreFClb4 bZ3rtH5Kdnky49y2VSRr0/GW5gUaAotOTeUciYyLZDlMj7uX9tiULIz0e EJki9RFvM6vKj3s6XHvvKA0UTxrECj1cwfNYGgktm3W3ZaRjnvAhJw7eP s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B+AQA6gHtZ/4UNJK1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgm9rZIEUjg2PeYFJIoJjkyiCEiSDalVkAkKDMD8YAQIBAQEBAQEBayi?= =?us-ascii?q?FGQEFIygBLRALEwUgBwMCAiUhEQYNBgIBAReKFLA2giYng2cBhy8BAQEBAQEBA?= =?us-ascii?q?wEBAQEBAQEBAQEegyiDTYFhKwuCcYQ/DoM5gmEBBJ9tApQkggyJJ4cJiVODOoh?= =?us-ascii?q?lDxA4gQp3FYVkF4FpPjYBh0CCPwEBAQ?= X-IronPort-AV: E=Sophos;i="5.40,427,1496102400"; d="scan'208,217";a="275856486" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jul 2017 18:22:56 +0000 Received: from [10.82.226.238] (rtp-vpn1-750.cisco.com [10.82.226.238]) (authenticated bits=0) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v6SIMrjk028728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 28 Jul 2017 18:22:55 GMT To: Robert Raszuk Cc: idr wg , stephane.litkowski@orange.com, adam.simpson@alcatel-lucent.com, jhaas@juniper.net, keyur@arrcus.com References: <9fa67eb0-8f99-a46f-aff1-d42a279ab833@cisco.com> <8dd3e766b58944a3b176fc743e478137@XCH-ALN-014.cisco.com> <806a82b2-36bd-70d2-a37f-8377fd37f4c9@cisco.com> <69816cff-d7ff-3714-c3e7-c504bfe1997c@cisco.com> From: "Juan Alcaide (jalcaide)" Message-ID: <819b4a1d-9631-2bfe-caed-59a47aa223c8@cisco.com> Date: Fri, 28 Jul 2017 20:22:53 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------60F69976E15EF89DB8B53D72" Content-Language: en-US X-Authenticated-User: jalcaide Archived-At: Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT (part 2) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 18:23:01 -0000 This is a multi-part message in MIME format. --------------60F69976E15EF89DB8B53D72 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Robert, I'm just saying your approach will work, but I'm not convinced it's the best one ;-)... I'm ccing the authors of the draft to see what's their take per section 8 of the draft, group-ids it limits scope of application, but it can limit it in multiple subsets, so spec is not really complete So your choice is: - Use SAFI=134 whenever there are group-ids - Make sure RD is different if NLRI is the same but group-id is different -J On 7/28/2017 7:58 PM, Robert Raszuk wrote: > Hi Juan, > > Looks like we have reached the point of some agreement :) > > Two last comments from me. You can discuss choice of solutions with > authors of draft-litkowski. > > > > - Controller keeps track of all RD it has used and makes sure it > uses a different one for each new route it sends > > It should use different one for each new duplicated route it sends - > not for each new route as such. Those all can be used with the same RD. > > > > Whaever approach, the way draft-litkowski-idr-flowspec-interfaceset is > described today is incorrect > > I would not go that far. It is correct if you *only* assume that > group-id is *only* used to limit the scope of application of global > flow-spec route. IMHO it was specifically written with that assumption > in mind and with such assumption in mind the draft is still correct. > > The draft may explicitly state that given NLRI can be used only once > and that subsequent update has the normal semantics of being an > implicit withdraw. If you have customers who require different actions > for the same match criteria perhaps you can provide solution in a > different draft or just use SAFI 134 as already discussed. > > Cheers, > Robert. > > > On Fri, Jul 28, 2017 at 7:47 PM, Juan Alcaide (jalcaide) > > wrote: > > This is certainly a possibility. > > - When any group-id is used, use *always* SAFI 134 > - Controller keeps track of all RD it has used and makes sure it > uses a different one for each new route it sends > > Drawbacks > - When VPNs are actually used, RD of ipv4 route and RD of FS rule > may not be the same of the one of the vpnv4 route. > - We have to configure VPN-SAFI in all the routers in the middle > (like RR) > - If a router acts as controller (via configuration), we have to > add auto-assignment of RDs. GR in case the controller/router > reboots becomes a challenge > > I still think that an interface discriminator would make more > sense. We would have to change fewer things > But this needs to be specified in drafts. Whaever approach, the > way draft-litkowski-idr-flowspec-interfaceset is described today > is incorrect > > -J > > > > On 7/28/2017 7:07 PM, Robert Raszuk wrote: >> ​Juan, >> ​ >> >> You mean we don't need to deprecate SAFI 133 >> >> >> ​Yes.​ >> >> Yes.. RD makes them unique in the domain, but my point is >> that now you need them for more than for VPN >> discrimination. You need grou-id discrimination >> >> Imagine a PE has reserved RD:1.1.1.1:1 , >> RD:1.1.1.1:2 , RD, 1.1.1.1:3 >> for regular VPN configuration. I assume >> you would use those RDs for FS rules not associated to any >> interfaces (SAFI 134) >> Then you want to use SAFI 134 for rules in the global table >> with group-id info (let's say you have just 2 different >> group-ids). You need RD:1.1.1.1:101 , >> RD:1.1.1.102. If you also want group-ids for the VPNs, you >> would needRD:1.1.1.1:211 , RD:1.1.1.1:212 >> , RD:1.1.1.1:221 , >> RD:1.1.1.1:222 , RD:1.1.1.1:231 >> , RD:1.1.1.1:232 . >> It's a provisioning nightmare >> >> I just think we should use one discriminator for each function. >> >> >> It's not the way I look at it. >> >> Imagine you are on the controller ​and want to inject for the >> same FS NLRI different functions which will apply to different >> interfaces. So for the second occurrence of same NLRI you >> auto-assign different local RD to make it unique. >> >> Problem solved. >> >> Remember "D" in RD stands for distinguisher not discriminator. It >> plays no role in choosing a VPN nor choosing a group-id at the >> destinations. RT is used for that. >> >> ​Thx, >> R.​ >> > > --------------60F69976E15EF89DB8B53D72 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Robert,

I'm just saying your approach will work, but I'm not convinced it's the best one ;-)... I'm ccing the authors of the draft to see what's their take
per section 8 of the draft, group-ids it limits scope of application, but it can limit it in multiple subsets, so spec is not really complete

So your choice is:
- Use SAFI=134 whenever there are group-ids
- Make sure RD is different if NLRI is the same but group-id is different

-J



On 7/28/2017 7:58 PM, Robert Raszuk wrote:
Hi Juan,

Looks like we have reached the point of some agreement :) 

Two last comments from me. You can discuss choice of solutions with authors of draft-litkowski. 


> -  Controller keeps track of all RD it has used and makes sure it uses a different one for each new route it sends

It should use different one for each new duplicated route it sends - not for each new route as such. Those all can be used with the same RD. 


> Whaever approach, the way draft-litkowski-idr-flowspec-interfaceset is described today is incorrect

I would not go that far. It is correct if you *only* assume that group-id is *only* used to limit the scope of application of global flow-spec route. IMHO it was specifically written with that assumption in mind and with such assumption in mind the draft is still correct. 

The draft may explicitly state that given NLRI can be used only once and that subsequent update has the normal semantics of being an implicit withdraw. If you have customers who require different actions for the same match criteria perhaps you can provide solution in a different draft or just use SAFI 134 as already discussed. 

Cheers,
Robert.


On Fri, Jul 28, 2017 at 7:47 PM, Juan Alcaide (jalcaide) <jalcaide@cisco.com> wrote:
This is certainly a possibility.

- When any group-id is used, use *always* SAFI 134
-  Controller keeps track of all RD it has used and makes sure it uses a different one for each new route it sends

Drawbacks
- When VPNs are actually used, RD of ipv4 route and RD of FS rule may not be the same of the one of the vpnv4 route.
- We have to configure VPN-SAFI in all the routers in the middle (like RR)
- If a router acts as controller (via configuration), we have to add auto-assignment of RDs. GR in case the controller/router reboots becomes a challenge

I still think that an interface discriminator would make more sense. We would have to change fewer things
But this needs to be specified  in drafts. Whaever approach, the way draft-litkowski-idr-flowspec-interfaceset is described today is incorrect

-J



On 7/28/2017 7:07 PM, Robert Raszuk wrote:
​Juan,
​
You mean we don't need to deprecate SAFI 133

​Yes.​
 
Yes.. RD makes them unique in the domain, but my point is that now you need them for more than for VPN discrimination.   You need grou-id discrimination

Imagine a PE has reserved RD:1.1.1.1:1,  RD:1.1.1.1:2, RD, 1.1.1.1:3  for regular VPN configuration. I assume you would use those RDs for FS rules not associated to any interfaces (SAFI 134)
Then you want to use SAFI 134 for rules in the global table with group-id info (let's say you have just 2 different group-ids). You need RD:1.1.1.1:101, RD:1.1.1.102. If you also want group-ids for the VPNs, you would needRD:1.1.1.1:211, RD:1.1.1.1:212, RD:1.1.1.1:221, RD:1.1.1.1:222, RD:1.1.1.1:231, RD:1.1.1.1:232. It's a provisioning nightmare

I just think we should use one discriminator for each function.

It's not the way I look at it. 

Imagine you are on the controller ​and want to inject for the same FS NLRI different functions which will apply to different interfaces. So for the second occurrence of same NLRI you auto-assign different local RD to make it unique. 

Problem solved. 

Remember "D" in RD stands for distinguisher not discriminator. It plays no role in choosing a VPN nor choosing a group-id at the destinations. RT is used for that. 

​Thx,
R.​




--------------60F69976E15EF89DB8B53D72-- From nobody Fri Jul 28 11:28:50 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52CBF131D1B for ; Fri, 28 Jul 2017 11:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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 TANCVnxUxROX for ; Fri, 28 Jul 2017 11:28:47 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAB3A129B43 for ; Fri, 28 Jul 2017 11:28:47 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id v205so84683117itf.1 for ; Fri, 28 Jul 2017 11:28:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=GAwXGFtHVDZF49Yysu7M/eN8MgiOoWZZdI1Y0IlIJ/A=; b=Vx6+GjZrA7QkpYgEnSjZFM2MliFPO0JZ9D5bEnpVx19FoSr8ZKAAGSELL89Xz6TSrk U1BS+fZ2pJdHXIhiFIe1jZeW+eNWAJlMFg3dUqPDb61I4QUlnIin/YDmxUpBbvmcCk2b x0LJTfU/Gs3VM5qg3HNHu3j3urCcD/6m2rShHdP1vmsH+cUfKiJLAX50cNS/8nhKRAN7 KBSRFCAAvrqTBbD0uJnyQ2cCR41QQLF+sDHV3GaMNgDER291G5pG+t5qvS9oCUqfTuWd Y7Sb1Wu7ntNL73oBQfRnC0eTrCBSuTX128uL6+2k0DzDz5Y4V4iuC2qSXdh7isEGru/y KmHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=GAwXGFtHVDZF49Yysu7M/eN8MgiOoWZZdI1Y0IlIJ/A=; b=noPsjG33CWu52r5ou6yotNgKYTMFI9QZ25sRhzSkJH3kd5jNB2HzhO1XOBBNs1EU0e AOxrjS/yh3fdhWpvV5s2uzQvCmNlVMPe0QzErvpCZ8n+cuOwuOuQqLgQgL3pLG+lMuHf +hFqTpA1542X50B6+i9YaoVou4ARRyaNAiQvCh4721ikkogWjdPpnYcI/wWrXI1Cl4SI yBiQQeDt8yJCzxILH6vo2d0le1ISDo0PuiB87iqPEEqxYX41RNK5AHarFYq+wlGHXoBT QuCWjPlqV/tPA0QcWcOmXobqk+8akPBi+blfFNh0caFZcMsHB8B9a/3cKXQaOhOUKbWa 2qeg== X-Gm-Message-State: AIVw110kr0k+tPmwzRsYR7n2OmxWuoSzMaDhSfBAG4EGpSC6c/ssRC20 wUVp8uOSa+xWfdhfBlgY88dab4n6uaeL X-Received: by 10.36.107.214 with SMTP id v205mr9907636itc.33.1501266526832; Fri, 28 Jul 2017 11:28:46 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.153.21 with HTTP; Fri, 28 Jul 2017 11:28:45 -0700 (PDT) In-Reply-To: <819b4a1d-9631-2bfe-caed-59a47aa223c8@cisco.com> References: <9fa67eb0-8f99-a46f-aff1-d42a279ab833@cisco.com> <8dd3e766b58944a3b176fc743e478137@XCH-ALN-014.cisco.com> <806a82b2-36bd-70d2-a37f-8377fd37f4c9@cisco.com> <69816cff-d7ff-3714-c3e7-c504bfe1997c@cisco.com> <819b4a1d-9631-2bfe-caed-59a47aa223c8@cisco.com> From: Robert Raszuk Date: Fri, 28 Jul 2017 20:28:45 +0200 X-Google-Sender-Auth: X-1UsVMpad7R0okvvmDWf19_YUA Message-ID: To: "Juan Alcaide (jalcaide)" Cc: idr wg , "" , "Simpson, Adam (Adam)" , Jeffrey Haas , Keyur Patel Content-Type: multipart/alternative; boundary="001a114ac8f60b9080055564da7e" Archived-At: Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT (part 2) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 18:28:49 -0000 --001a114ac8f60b9080055564da7e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =E2=80=8BJuan,=E2=80=8B > So your choice is: > - Use SAFI=3D134 whenever there are group-ids > =E2=80=8BNot always. I can see number of real use cases for group-ids witho= ut =E2=80=8Boverlapping NLRIs. In those cases there is no need to use RD nor S= AFI 134. Normal SAFI 133 will work just fine there. - Make sure RD is different if NLRI is the same but group-id is different > =E2=80=8BYes, but only if you have =E2=80=8Ba local deployment case of diff= erent actions for the identical FlowSpec NLRIs and different group-ids. =E2=80=8B//RR.=E2=80=8B > > > -J > > > > > On 7/28/2017 7:58 PM, Robert Raszuk wrote: > > Hi Juan, > > Looks like we have reached the point of some agreement :) > > Two last comments from me. You can discuss choice of solutions with > authors of draft-litkowski. > > > > - Controller keeps track of all RD it has used and makes sure it uses > a different one for each new route it sends > > It should use different one for each new duplicated route it sends - not > for each new route as such. Those all can be used with the same RD. > > > > Whaever approach, the way draft-litkowski-idr-flowspec-interfaceset is > described today is incorrect > > I would not go that far. It is correct if you *only* assume that group-id > is *only* used to limit the scope of application of global flow-spec rout= e. > IMHO it was specifically written with that assumption in mind and with su= ch > assumption in mind the draft is still correct. > > The draft may explicitly state that given NLRI can be used only once and > that subsequent update has the normal semantics of being an implicit > withdraw. If you have customers who require different actions for the sam= e > match criteria perhaps you can provide solution in a different draft or > just use SAFI 134 as already discussed. > > Cheers, > Robert. > > --001a114ac8f60b9080055564da7e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=E2=80=8BJuan,=E2=80=8B
=C2=A0
So your choice is:
- Use SAFI=3D134 whenever there are group-ids

=E2=80=8BNot always. I can see = number of real use cases for group-ids without =E2=80=8Boverlapping NLRIs. = In those cases there is no need to use RD nor SAFI 134. Normal SAFI 133 wil= l work just fine there.=C2=A0
=C2=A0

- Make sure RD is different if NLRI is the same but group-id is different

=E2=80=8BYes, but only if you have =E2=80=8Ba local deployment case of = different actions for the identical FlowSpec NLRIs and different group-ids.= =C2=A0


=E2=80=8B//RR.= =E2=80=8B



=C2=A0


-J




On 7/28/2017 7:58 PM, Robert Raszuk wrote:
=20
Hi Juan,

Looks like we have reached the point of some agreement :)=C2=A0

Two last comments from me. You can discuss choice of solutions with authors of draft-litkowski.=C2=A0


>=C2=A0= -=C2=A0 Controller keeps track of all RD it has used and makes sure it uses a different one for each new route it sends

It should use different one for each new duplicated route it sends - not for each new route as such. Those all can be used with the same RD.=C2=A0


>=C2=A0= Whaeve= r approach, the way draft-litkowski-idr-flowspec-interfaceset is described today is incorrect

I would not go that far. It is correct if you *only* assume that group-id is *only* used to limit the scope of application of global flow-spec route. IMHO it was specifically written with that assumption in mind and with such assumption in mind the draft is still correct.=C2=A0

The draft may explicitly state that given NLRI can be used only once and that subsequent update has the normal semantics of being an implicit withdraw. If you have customers who require different actions for the same match criteria perhaps you can provide solution in a different draft or just use SAFI 134 as already discussed.=C2=A0

Cheers,
Robert.

<= /div> --001a114ac8f60b9080055564da7e-- From nobody Fri Jul 28 12:12:56 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EADA7131C8D for ; Fri, 28 Jul 2017 12:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_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=juniper.net 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 RP3pCVe1HStE for ; Fri, 28 Jul 2017 12:12:52 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0101.outbound.protection.outlook.com [104.47.37.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DD1B12714F for ; Fri, 28 Jul 2017 12:12:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cpX13A+TDcpm+MFJCM8x1/QilexTbAnUNTWk0zC3qzc=; b=kK6uokW2xrB3KXJZwfQXaEi2NMF6isskmcX76SJjxChtpD5NYpV7DFvVJ7ro4sbVE/T0YXwDtuRW2jZNkozc+wHKlq+DAFg5KVgWmhb39GCAbobwq3BTMlzhx+/NLl64UhuxK5KaYdefN1R2EvuHs9BDQOgTqq04Yh1Lbnfh5tg= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from kschorr-sslvpn-nc.jnpr.net (66.129.241.12) by BN3PR05MB2498.namprd05.prod.outlook.com (10.167.3.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1304.10; Fri, 28 Jul 2017 19:12:50 +0000 From: John Scudder Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Fri, 28 Jul 2017 15:12:44 -0400 To: idr@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: MWHPR19CA0075.namprd19.prod.outlook.com (10.175.0.141) To BN3PR05MB2498.namprd05.prod.outlook.com (10.167.3.27) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: e0c68746-c333-4b68-f8f6-08d4d5eca433 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(48565401081)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR05MB2498; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 3:2iKpQdRsIEYYfKyJmB0JQJmzew7fuqQAB717WbdRMxuuFQE6UR/KA5bmu/Y5xTGoool1FN/oURGOdo7V9ykXyTXyTEVpfvJ+3P2YqBH3Spi5m90jSlhjIrgBGQjV/o2RxmSh0D5S3g6pID9THrnx59/no1lY9pAP2KdgX5zjRng4sBQu/2fF28lho2AXkJCa/RPtIaYkfQlPo09EcqPPsXFsBlMH1BjF8flxBPQdOkw577PhPqdKrnV1X8e5iLgFYejonzS4j+n+g7Cfu0Sg6UM1RKxdShHTXpL29JLnOvewRVwxNySu7g9uz3XqQx00WOYMoN1NIx45wDrdGnscy7vQl1iYQv50zExhNUbQz7reBTbPKadxtKbDECTftMywBCqdgJxKoBsjkRjTZijEplALc+t5HBMpl3gX18zdhxt5S3rYk09KL5Eq4lISpOwkEgsthj4c8ZsrvTQNrQIywexrmtV1wVNV+fHrmsCgPFhZslgVwOFKpXfIMXfJgJ5dpCk5QtBZJXQT78shwUnMxu1+CuSHuTNBlfenXSHAZ4nWmO3iSwAlglkvj2Ha5/DQwG4GVd3vaO1q3Cskwk85YxawdvydeAEXLweC6cGdxnKvoTLhH/VNZT3/3hMHiH8Y0T+EyRgL4xSle2cfQ8dfVTn/8ALPFKlA4xVDoY5kMANFVXs13EXdhT1sx6rp8jg1dS2eRoL/rm8gRm1qWVaIjB/PU8QDfGa/DO8GAtNwO7ld4cV0cq9vXyxS8GPv5f7ygWIC3o5OQqolMRbBgwzcbA== X-MS-TrafficTypeDiagnostic: BN3PR05MB2498: X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 25:ALIRknc9fpEqCWpOcCqZqMjMGsnYnILze3K4ig2znE3lTeEEV28O6OenK5YRoLdKG+KVuylFkIzOV1s76Wwg6ZdyRqImfLwH4s+mssCP/PHH3cG4Gpp9u8oKovIh6vpW9M8EIHv58Lio/HEP2DvQNx00HvsUC0SFfgEMnV2xLBpx0ZbUrRMfq+5kE+DNu23Uxi5X7Bzl9OEKAJXoOORmPB7Trf4f9gDURAaLDCK/hTcE42bH/ZJnZDWb/sz4UD0xrUzsE7nuUkGvV6UJRJcL4ECcTPDTVtf0itm/YWlf0csnnsLdzbyRDEsgbsmK3SLhInIiAcMYGZE0pNmJSbi0XaSX4c7Z/VnGibQ98UmnpuZhGZvpk6skvqbHVvAJBOLr3BxfrAb8B5558+r8ZadOShLmQ8Iq2BDGRO44kFEMBGakqk1q40rau7buVkzXr3IrPLmo4LPTUd/RaPCW9Hi+jIAbHGBCLDMqZKli02fPNpmhx+FNi9sAaRFytOP0SwyUAvOzfQXu394IwFENqmqS5QKjeHudTYUfdKEJP0CYsbTiq+qmbYRdijALzQHh8iaFh+Gkpuq0DzDxz9NX1srH1W/4H8VtwMqv4QDzp0O2p2joF9gnsoK/UBH0WLDCJHXtisdTB049pvwXLWS5cwiAnI23tstb4c5PJpoCTYMnRY9t0YdKMI5fACpCqrs9PFJa/YwnpdHTu4LbKTOLiy/aa6GN7TWZTOZGGGJkJnVfIB9z7MSgFl5e67EALy9rYtedoLLLzYOp+nARw7L1uYgniYBJx4YLEh3szS1wX7OMDrNgLg6wrlWOH8kPxzGiC+QoWcZUq1i4sJxJwNFjShnivf+GqNsb+qHOXqjJxHtkWqJVQM481w6+2+SgJoWDcrk3TfYsXi8zM+m5gGc+qaMg6YyXn3eK803g5phobYHbioc= X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 31:m4ZmseRXeMNRn1wWNFm6tXSW5P+OpE3dsAiPWZomgrBJ1qmQgfmHYwCFM1igwcWQePieAp3kXwvJSf1nJCzrqxxXtnzjGOO+BblEmXTE3LAKESgHqQIGLCyxFJs6A3adgLlnUIXI9BNB6J0DvjjHBuaQR7l4g2gHlpN5DPXtdGMiaGHS3tugJCZ2nIcDnKmStmRRMk6Vax8FSrIisPiIGmEnHttY6rfQ9Q1LoiNfNuIsyb39KDIJU9p/3KdmTfjiv1CHvQNoR30gyJrjUNSWhNcLecFG14CRB9E9gWBn++A5tDCa+CTCio0Nq1TEXblbfVFkm+X2Ds2zFfmgCxYv76zaIHjFUSgHHqEI/giNlkJpMbRzYqSLT+Jec5DPNGSYHO3BWketRNzGw0nvGlttT2LuqZwhnHPxnTMjKmmEtAk1WSgfYBeM+CktXmm1fBBnv7oJiLuoJtAaz8LiIrwtA6Cv9QY3453mONvxRrGHuXviYoX3f3+ZPzYbxMbdh4F0YKjGerQw/SesDOq6fBuA4bb/AViWV3T6lLY/FpAc5TvWFDNnFZv40b8c1JeFDILtQPh8jdw2ljWX6mcoBXVUuJTHh4xPsirps3u5ftOxvwfbt3gmZibKxuAM1BArTcFWxkdKFBvACBBLTl26w6/mHw8f+rb7ZFxLzLg3kAUbtHAer8LzAwJXgPH7XYIdO5bbVh/eyv+/Dehsox9jG94Ikg== X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 20:csFC9H8srIDxPOp8SgOTSvJ0hAKPDoou7ejA10ET2PSzG5XnmSO1Xmkt9WlVFNPw59sceXRBy1psz77sxqcLTELF95Xi+QgSMe4wVJO6ig4oXnpmkCkMefGcgPYTjTNaV7ryOGl4yAh/u3y6SWbYk25tkkuuoyU7RE6rk4B/Qm4oLBJ2hYbhW9RYLj/LaYSZf5hOsgk3LnvEBOLGKzV9Mtx8f5BviezJwSNFrNzUjXeDlZvIyCMAWzbEajuzLwZ/VxbEFHW6NZucZJ+FoSHJ4jPOo3d3k/3g88UlQ32S34AmGc6k8KChTDnVw6lMx5uo6oyYS9OLo/F9f7FYLeRy1RzbDrs1+vX63GTktRKdcD0FWxTk8BOFxLAKSfcBesumMrJbfSa+Nyx2FV5ujfJH4BtG0ED3BcTzH62X5MD1nkRih3TmtQJd5FOsGCLdx0KuX+3ttQabr4N9VMxaud1lImaDp8rUj3Vnlm+vyyL34FGaZAFc3zJPvZu855IdOZN8lzJPnnQ6YhEcS5PxU+BWDCHzHvcDYQuuoMU9douX06889sBKa2FV1TiZNb3QVoKbRY+1+ZKQkAFl3fOZTFYPr4TNhXkYcTomRpOVJi2Mt/A= X-Exchange-Antispam-Report-Test: UriScan:(209352067349851); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR05MB2498; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR05MB2498; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR05MB2498; 4:Dk/S3O2McFFmEbkjpOX32XevY9F0ed0E2PbXcLz02V?= =?us-ascii?Q?4THE66ZvNxbRwqZtbHuCyBwzB0B9DZX9FdHf8rNwh+xzD87UfKruLVUifrQ7?= =?us-ascii?Q?PnLeNqGo1fG/PRn3p2MzDxg1fhlWG57oXpmMBfmGu4iSajMmrUEqVcq6H3VC?= =?us-ascii?Q?XOWE1ukQT7NlVuqMupmgF99pY+2PoPkhhNuJbfRZ1I/v6ctFoJlY649ZY/UG?= =?us-ascii?Q?ILhlFzsuo+V9tm/jn6ClPT28/x3wgnFZixfojjZqrrbADpy6FSgg2OWMlmCt?= =?us-ascii?Q?pKU1irjUuPv6DZ0ezc9MFVNbCCrnzWU1k4WAiVI9fW8nMze2X6996PxzfQ69?= =?us-ascii?Q?6vjkazbQKt0NqK87Pf+QPxJk9saonD0/Y0senEnOa1BlyxjtQha/lsW6FgTf?= =?us-ascii?Q?LaLkWV5Zf2WAvTQP/B5/qKwnm3Cixj8z9Npev9esFa9kyZ4x+P/fuPBjgRRo?= =?us-ascii?Q?G/qxqmOkoX3cH09S+hZ+P/JgzOu03CUUWePuIile0hpOS6OuicuBOudwsnfj?= =?us-ascii?Q?jdl+rmcAbbZMvN8Ls1YrmOpziMpPOiiDJdHv90FfL0h607qQ/Pf3HwkVgTuA?= =?us-ascii?Q?xllJ+iI/uui/v51UVkUWweY+Ya8lrZlGBl9L0M5DiTR7cT+DgrKv8qABn5wh?= =?us-ascii?Q?OE4oNFOyY7Q3KtJPuuBiyOuXFjIaSdUPqk8P/C608I40jhRI1fgSbgjhgi0y?= =?us-ascii?Q?RMdRbY5P/8oWFiQmmLLkbNbhSMvwf5SPLyCm6SPO5/dYKy95uZ+CEnamNxhq?= =?us-ascii?Q?IzV7TZ/bYrXADum8kBTLwgBlbzis81J+cQSsX7+4izsvZPfjDLE+GgKifJmt?= =?us-ascii?Q?s40U3XKwZNftKAeOsBdMG0nSG55Q447c5uo9xNmPrh1dCtctEnOTr6/MEjyv?= =?us-ascii?Q?8j5w6Jjfdwmj2zRQ5uyANZ0bK9j5tV8HAbkDpsMa513DlMD4lOp5eAP3qnHu?= =?us-ascii?Q?pGFPNpQBaqC0Q8tUiJ+7v+PU7+MRNNrP9XzHF32nM6IlbZ7sK3A92DG98MAX?= =?us-ascii?Q?ERaaqLMW8B80Z/TH1aHzyiyLubyrLzEYEbWEM0/lw0JDLSy4RDddpnGcf+AK?= =?us-ascii?Q?oLu73Swf3kOTowZ2W8nRx+CIYa+R4JKjNQBATR8N32pKseGHTk4i/9AS33ji?= =?us-ascii?Q?gQfzjLXlwOCX5E4LJIW/yQwztinvKXH53dCAsoBH5DmPdqKITHcy+ntgawrH?= =?us-ascii?Q?Ur9bg6/JSSqMCRpqAztsyRkdwNHIgJWca6?= X-Forefront-PRVS: 03827AF76E X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(7370300001)(6009001)(39410400002)(39840400002)(39860400002)(39450400003)(39400400002)(39850400002)(189002)(199003)(66654002)(5660300001)(6116002)(25786009)(3846002)(33656002)(36756003)(50226002)(105586002)(68736007)(2906002)(69596002)(106356001)(57306001)(50466002)(110136004)(23726003)(38730400002)(82746002)(97736004)(558084003)(6916009)(478600001)(47776003)(50986999)(6666003)(53416004)(966005)(189998001)(42186005)(101416001)(83716003)(81156014)(86362001)(81166006)(305945005)(8676002)(7736002)(2351001)(7350300001)(53936002)(8746002)(2361001)(6512007)(6486002)(6306002)(66066001)(6506006)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR05MB2498; H:kschorr-sslvpn-nc.jnpr.net; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR05MB2498; 23:U0VsS1j610bFK2N7qIohyMVy35o4x8RvDIxPB5l7z?= =?us-ascii?Q?9ZjsxS/H8oEk3YivGlbPG/jPXXkNHSgtggY3i4mmWbLjrzoPANgMfpyC18g+?= =?us-ascii?Q?QMj81z9I1c5hiIm6Kj1sZgKzNdu8dxdS59d+5/A9tAFZLGITaGAWJigVl3Vt?= =?us-ascii?Q?MwjTtFZlcjQEM+kVlEKXNVRxnZOsbTuEGTgtt6ZgYzCCV1RuvnjDI+5r3bcv?= =?us-ascii?Q?E5tzFWHxT1cakXvva0uPaQIShp3d4X19XFTrjP9TITafnnhROA7gt5Z8zSJ4?= =?us-ascii?Q?yqGBQ3MtN+gxToFR/ADjoFgH+6wrrUqF//W/DQtMlXvfhtcrLsT/9wngnfNu?= =?us-ascii?Q?B8Qrp/7b4+PVStiFXd7R10DK9lemrKOijWYL/xbXJSiLH273Dh3c7DDt98Gm?= =?us-ascii?Q?YWCmkFgBYBiKvsxqVpcTSy7HU7MiXQFhWN6wYswiGU5gBJVuLykrLp+KdbH2?= =?us-ascii?Q?i4dyjz9hoxa2ld1BDcKf+C8msTh2qH3d1WxqZDxasXB9qPJYB0nCyzwj/lLO?= =?us-ascii?Q?9AIV5WRzv5Ihn0cabGaA0SiFsocHd+90pH4rUXwIhzmoUzswF3idr/eSYmvn?= =?us-ascii?Q?QrTmlNvrzS6Lobr5C8xe+Q7pkrMs3Cb+UDUBpsiuJvTtOnSrbmHMnyyRaNWE?= =?us-ascii?Q?lq3iHnCqZVrRopB3EPYO0b6RjGnWOg9TPSQSVyvxHNXwiwuvfaFc0cZUfeHs?= =?us-ascii?Q?XR9Ei667Y1p1pOLkuss9XVZ8Llu3wLkqtFDf4JJ+57IujiIEw0kaZ9n13/WX?= =?us-ascii?Q?2oRyuZlPYoS7coYGy+H0XI47nn6EdWTtVLTbkYWystEoxw8s0aQFCWajTNAS?= =?us-ascii?Q?HmGaZrgYBQQpXQM5Dp/QmVRH6LZmrmDEG8ZUwX9YZeI4KWjqWT7NrWErNPdc?= =?us-ascii?Q?X5Lv8lUhFYaooyoEAqUBfFEw8vT//Lna6RS7vyEUD1qy4eB9xyVgUHzbGCAm?= =?us-ascii?Q?QjVrBQx2lgnU6sB0e4OtPjEiR946zABetgRw4sBvlRPf/Ck2c218ozXM8esC?= =?us-ascii?Q?MYF+aFa5/rnY+l/2HwVmgdiu/DKpc/acSgNJsKBicsg2roSv2MlhJ6asUQBR?= =?us-ascii?Q?chsaY43pa5gdBkFv026aV86Lm3HJ68QYn/I9/xQua22B3YsV/0TtnbrfAuaq?= =?us-ascii?Q?32OLiGLH2EEvmb+Honk1AC75+yuT+uR0sFEPjIQMenSfqble5s+sgTo8Hvc7?= =?us-ascii?Q?B+1pbfmr/vo9+Vq7EYoWAvwbcKmkw3rbsoQ8JG9vrKpAzi2iOf6DTGbEReQd?= =?us-ascii?Q?OASjkKaB7T3zI8TRvusFEIeI1/dsH0id2ShwBHrjpP8S5MqyOqMHhU/of76Z?= =?us-ascii?Q?rGLuiSw0+d5WTafwlocBBs9mhpcrSw0j5Mu+KCEASMOb8aNInEotUXc4iwXd?= =?us-ascii?Q?knYb/VqMV2Y4c0AUoIsAuv6p1AtShduhW6m12Q7aAMwTZz7vn33aR5JsdasI?= =?us-ascii?Q?4w7/2GyCD2usEl4j8HAxcbefgFLmt0=3D?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR05MB2498; 6:hapXUf93iz2NwsODO37wwnzDbV8l0yc5c3Dbz8do10?= =?us-ascii?Q?ItRt2Lgb2oMVFJKrAdCt9BdViYwnUThw/wyGQbtHES3Z4k4umyu9rDiTdM1/?= =?us-ascii?Q?J7A+VceI1fZd+C7OpFsAe6kHjvqZN21ZXNktyqHkfFnTbaYDAN3eubTqPPXi?= =?us-ascii?Q?XfUiSd5+wCXUf/6G40l1p0JBuTRWMyfiMyctyZcURplajfm7AOBmGqX+NHWa?= =?us-ascii?Q?oLePan/m1mSLIz7F0Dvonb5ji8HNog3Zel8KtbK39qrpDzKQ9KVHtrS/JoN5?= =?us-ascii?Q?atQT9ey3bWzO05HzayDFaspqXgFp/Z66o3FnhPmcXI4t00536AqIrtGKx/ru?= =?us-ascii?Q?BC4538k5aFFbouJMmvQn42WnftAnCmMXqE8lTk720JH+SWC1T6tbOCAndwho?= =?us-ascii?Q?z2gDCMxkzKRJXd1f09/QZTBx3dsoYrbkPftd4T2S7U4b7Y2PA+7SBkzXdKnT?= =?us-ascii?Q?QX9hvi7jTw14F3VbkM/Zymzlg2RfH3CFVuyxu/rE+JKz0G5+bhnjB2AIjNjz?= =?us-ascii?Q?v2m/o7Z4ShtG2fIkrFv/m1fLSYIJflZ2csjfDV1KtoayI5RZ947gRGd/OirC?= =?us-ascii?Q?pFf8tJlYpTzCAmX3cwauP/yQ8nAS2xSKnKQnYERu6xuzHBh9cxmXx5YRbmG4?= =?us-ascii?Q?pUYwTnz/LDtlGyVmjcQZnYQD/oC2AyiemV++BMWkSN8DVrDQadO84rZL/f6g?= =?us-ascii?Q?6QrqOx8hQtG5hQvjuxyGsLCnRpsNSBgiswRlPCPKyhv3QxAvAllEuiL1uwwI?= =?us-ascii?Q?7cY/By3xBJIkGvEiUlzh6F/cEaXVcLQRGfsqDKuJ8dUhlKWY5fgWfE/HHGDr?= =?us-ascii?Q?9DEQ7Vj9jG6qwnb3GZ9VtkqH60CPWgim6mUENdfJ+RE1NIAA7bAX3DF9a0z+?= =?us-ascii?Q?XiofNVgRBNg9vcD0suK/3u4RlguvL9Ww4UmEOJRzdI2q+KfUI9LJTYmg1Cva?= =?us-ascii?Q?5L2K0E1mKmrX3+WfVs6F7x9lHCPvdAFQl4COyuQqEtb9QNkWpja6gLB3ZNq7?= =?us-ascii?Q?q0CLsUbOdqIhPPlntPCkno?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 5:X8u1jWzkGug28tx8kl1FjZC9jWDIHGiREDpzMGj2GssWTKBaCXWM/mHvb0TuhWWluuwMO+37p9YNpQd6RD6iAPxoZNUC25feAtkutqUnxFa6JoyU5lymwSBEvXmzberwAnFwvy3IuVRXFHb1khtwsCIUpGTn5PzxAPyKHbYWb7MsJzRf1qOP612/1GioNYkOhmCzmQ0V7KO44sG2oH3lCwZkjNBIQUo8H/BhlDJ+64MZFyJip0p7nIolBcDmnESNMJaanxXzklPlDJXEs3xMe/ZwHC5n3CntomxBpk53s/bBg0m2QhDWw+YXrQ7IYDLcL5JpjV+bUnLBeB00p8vXh2RULjYyU+y5FsZuyEvC2GDKEZzrDJEOV1bYscFO6wZo4xnfOTdJr24Iz+Q0sofUdhUG86hM4Jc2VXG7stLZAgFVDtIrs76zY0HSqDvHNq1lnRU2twdqbz6jrxnc63mnlV4loHJRa2uRgaHNpSqURM2BL+DoH78Nwf9+a1Kjz+T2; 24:yp372joHUoGHtI0+7nsoIikEN1+/RtGMiDOaln9NHQ/d2HbVmIWGY9GBMrsDTT8VCy+vbTCQnYBejcyPyZC7Ie58bwpIM0dHRkcM92qIm+k= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 7:6Y1nta2ZY3qyvDM9qKV/B+qmq2atmj6QC2Fk/fZ5ZET2vYBW7rq/tUPH174yOiB3AE2y3JSaQThaZVay2PiT951bynL4Ex4o5H/sDX18C8/UQUsjtfEpAoqQFwKIoEoadJwevsJ9oUbY0HUd4W7ca9/wKCXvFBYiCO6NVbwG4l6Pfjn1uDrlGqOCDt+xn3vhz01O6pIRGnpLzobBlKyXu87CX8uHCuDWB/3u7nmN6xwMQDDNgy14RKGv3U3YKrZXiN4s2/v2P8wQMMMV3ZWcMYpJTc1z8NOZBf9DRyy1BSoBZUASPDR8OggM5Sbsl/3+Ru2uV30H6bjy0vU7YhQw0xqordThbjuCKjS3wJSEa2c8sMh9kChpn+aAN8BW6kDJFCZtj9Q3B/nQqjV68+9x/+xJ0WOMr6BFq/Ap7Xlh8ztGj5382GrdaD8Ymj8EIyScJUBIA09Qq7CgoWXjCACR86xLU2ZLzjyDBUwTbsK6JToNxPkG8WU1vnXACOBdmgpf8FjnoU8Xc40ArSAjgMLLTyUHpR560YF2DnkKyK7aOk3kAt5xjlZSsu5bqMi2b7kjWxtFufBzA28HxuCNsWfpGFlkd8MsJ4qdiGX13qT1SducVvDdggTekx/jY87PkCnIr3WV4UWQEVUDC5lCHKi1rXLh7xzPRnDghzSYzug7vlsT1hoOMnYrDCy+JShvhFhinbOZ1wspOfJC/nHGjx0CT+zl6qo5gjfna6Lbh/wFGIvA8hg0u55B0gVqNcHDJcKwzm1unP/zDfcblyMhNdmJeLoVv//XJi6Y7HaasXGmu8U= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jul 2017 19:12:50.4012 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR05MB2498 Archived-At: Subject: [Idr] Draft IDR minutes for IETF-99 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 19:12:55 -0000 Draft minutes for our last meeting are online at = https://www.ietf.org/proceedings/99/minutes/minutes-99-idr-01.txt. Many = thanks to Ignas Bagdonas! Please send any corrections. There are a few places that could use to be = filled in, marked with empty square brackets ("[]").=20 Thanks, --John= From nobody Fri Jul 28 12:36:18 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFAA1320E4; Fri, 28 Jul 2017 12:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-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=juniper.net 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 Sn2oTMnhWPGk; Fri, 28 Jul 2017 12:36:07 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0121.outbound.protection.outlook.com [104.47.33.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FAD4132307; Fri, 28 Jul 2017 12:35:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=3haZFUa2+Zuu4VZGeyqo+RyVk12duHoLEeF1xEjpIhA=; b=HLW1MgX51GhuMqeWFWXdGtyCxEabF4y+rSp8arUtkVuGLlroGfv73GPD2JtFu7BaUIDO5dBU5tECGSTGSnZtc5u/R7BmBSkku/AedJg2fJH+twatJrbJccIE8YhBM0migbPbpzx1cFfFAB7zqLbjDyEnHbhveEHSBjD/9c0CL9k= Received: from CY1PR05MB2507.namprd05.prod.outlook.com (10.167.10.134) by CY1PR05MB2233.namprd05.prod.outlook.com (10.166.192.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.10; Fri, 28 Jul 2017 19:35:48 +0000 Received: from CY1PR05MB2507.namprd05.prod.outlook.com ([10.167.10.134]) by CY1PR05MB2507.namprd05.prod.outlook.com ([10.167.10.134]) with mapi id 15.01.1304.021; Fri, 28 Jul 2017 19:35:48 +0000 From: John Scudder To: "idr@ietf. org" CC: "draft-ietf-idr-wide-bgp-communities@ietf.org" Thread-Topic: [IANA #977101] Early allocation for draft-ietf-idr-wide-bgp-communities-04 Thread-Index: AQHTBjIvW7+StTp2Iky2M13/Lx5vt6JpmKuAgAAL/BM= Date: Fri, 28 Jul 2017 19:35:47 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR05MB2233; 7:xt2L9aFGAmqoQe0WEt8zAgyLqrVEGtTsKadfN9vl9GqauuiY70VQlBVK2HmllRwz0I5Feqo00Gk3bczm+U4hxTMfkUBRNKwPcF9WAVpS8VYYugxIcplvXNgDTypuTWHHRkiasdPIzysEnPK75tgi6gQEhKru8Iz1leE+f8VA3Pwh1fPUDJpeyUGK1kp+foNJAHYMVRYmps6N5XvH++m7D1aD+jm234a4pihMA6vYFovC1oLy1dGfA00pPPIWi56w4F7yYi0vhDjjDYCAAm3Pb25ndwe9GYqhtHe13LGItkgu1LGKuBPU4rFjkge3QZBGH8AW56/uJDbnjzFYIteNAnJIDqTHVN6eF9AgV/FErB+YPlZvy5RTQUPuzMdo6NIdVXztsyIx4Cap9srHSXHBQbNk8WZcqEMe/8aQEa8dh9xAWczEYVBfMCuXh0mb3x4AQfj/d8Fno41FwbAJRYjUKXLA+bsRnu5+xTVSo8PASBaATp5GQ4rI0oi29uDwIEScsBpaRieZklbdc4EJnekuY4Z01pEKehGXWckJQYkEF6cLkLo9dmIZwDFnAG1XCcBJ1AHrsRQsv+oC0/U+fIxvEdfiEGGzzEfjjgsAmPVVfMk3K41X9XsfKFf83N70KBcurhthnFi2utdGBejK+EjgJm7iE2AB2OXPhUZx0kI4fVaVeeXg0n90NOsBJ8BRgziDLb/JdRXZ0S7od58kM4JKgNNzvHg0eET58PrB34bstdjwdAqjNsCpZenEDJctODLiQPdauwBMoHhDCSH/Ew9CRCcq6g0t5fIUKfEiV90NRGg= x-ms-office365-filtering-correlation-id: 3140bc70-78dc-4c5f-bc98-08d4d5efd906 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254130)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY1PR05MB2233; x-ms-traffictypediagnostic: CY1PR05MB2233: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; x-exchange-antispam-report-test: UriScan:(1591387915157); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR05MB2233; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR05MB2233; x-forefront-prvs: 03827AF76E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39400400002)(39850400002)(39840400002)(39450400003)(39410400002)(39860400002)(377454003)(189002)(377424004)(69234005)(199003)(110136004)(4326008)(189998001)(53546010)(66066001)(19627405001)(97736004)(478600001)(7736002)(81166006)(101416001)(81156014)(105586002)(606006)(33656002)(8676002)(2900100001)(50986999)(8936002)(106356001)(54356999)(9686003)(74316002)(14454004)(230783001)(102836003)(236005)(3846002)(38730400002)(6916009)(6306002)(966005)(76176999)(53936002)(6606003)(2950100002)(54896002)(25786009)(6436002)(2473003)(6116002)(99286003)(55016002)(6506006)(77096006)(7696004)(450100002)(3660700001)(229853002)(2906002)(5660300001)(86362001)(3280700002)(68736007)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2233; H:CY1PR05MB2507.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR05MB25075DDA2E3E5C30466F6AD1AABF0CY1PR05MB2507namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2017 19:35:47.9999 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2233 Archived-At: Subject: [Idr] Fw: [IANA #977101] Early allocation for draft-ietf-idr-wide-bgp-communities-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 19:36:16 -0000 --_000_CY1PR05MB25075DDA2E3E5C30466F6AD1AABF0CY1PR05MB2507namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FYI. --John ________________________________ From: Sabrina Tanamal via RT Sent: Friday, July 28, 2017 2:51 PM To: John Scudder Subject: [IANA #977101] Early allocation for draft-ietf-idr-wide-bgp-commun= ities-04 Hi John, We've made the following early allocation in https://www.iana.org/assignmen= ts/bgp-parameters: 34 BGP Community Container Attribute (TEMPORARY - registered 2017-07-2= 8, expires 2018-07-28) [draft-ietf-idr-wide-bgp-communities] [...] Best regards, Sabrina Tanamal IANA Services Specialist PTI [...] --_000_CY1PR05MB25075DDA2E3E5C30466F6AD1AABF0CY1PR05MB2507namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

FYI.


--John



From: Sabrina Tanamal via= RT <iana-prot-param@iana.org>
Sent: Friday, July 28, 2017 2:51 PM
To: John Scudder
Subject: [IANA #977101] Early allocation for draft-ietf-idr-wide-bgp= -communities-04
 
Hi John,

We've made the following early allocation in https://www.iana.org/assignments/bgp-parameters:

34      BGP Community Container Attribute (TEMPORA= RY - registered 2017-07-28, expires 2018-07-28)    &nbs= p;  [draft-ietf-idr-wide-bgp-communities]

[...]

Best regards,

Sabrina Tanamal
IANA Services Specialist
PTI

[...]
--_000_CY1PR05MB25075DDA2E3E5C30466F6AD1AABF0CY1PR05MB2507namp_-- From nobody Fri Jul 28 12:42:47 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF001320DC for ; Fri, 28 Jul 2017 12:42: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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.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 hCa767b7OpQM for ; Fri, 28 Jul 2017 12:42:43 -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 A83A21320D8 for ; Fri, 28 Jul 2017 12:42:43 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id y43so158570097wrd.3 for ; Fri, 28 Jul 2017 12:42:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LM6nnyHI8xEzMgA5E/uMIAcCJsx5dbn3Ne5T3bB9JuI=; b=M0Nc7aeN/ubCmP2yCuFvyNdMi+YB7+rB9ZJ5/KFrLJFBX6f4/3tIoC0D3AMXK+pFgw +byIxVgt5azk11iYooRtZzzVOkmmtAz2VZX0xcIitwlG39UgRPW2fpU2PDL6z1g4osf3 fX+QKCSw/UL5nnaNzPwSCehGi/IVgsT1R+RPZcVxWPTuEzdnYHKf9WuR5Na86bBdJfzt qtq15qshPWesYZeea+7P+J+ft5XMMoRf/W/tuzgJ4sXdYXPY7DbZI4UBVbPvK9D1EFIa CIEB1x+oUc6RHiZMLIJDMm4fBs4In8Rbf6zAqCdXcZr1/T3tnDEpo1AzcX0P3bexiU5n F5iA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LM6nnyHI8xEzMgA5E/uMIAcCJsx5dbn3Ne5T3bB9JuI=; b=IhuIMo0IGmY4l4q5bFlRn7OOyfdGs4M73OVhkl0CzdaTN7i7ABGVVaWBCnZ32OPmBy mKhRA583F92UBUMBBlA6gmV2zckzjyp3SA0+/vtmynPezv00ZJxsWSkbGvwgB8Btbj9G k6YJrUIYMjqGQMyCpAH21ngJ/4ERoo0RwLQxjOhvohGmko+dVlJ9DcEvXCJ3V0Q5Ctso kMRTtUleHubd6XLSwx1IVNcHkehToY8ja1zZoLRqZc5w/doK7XshJoKkX0uDjC80HaJ9 tBg5t6zHkmJUpvLJ5oTyAGNZIw8s5WjZvFsbo+kRUJF5Z3/zcDBBNGYoPbmQN1ZxWihj TAzA== X-Gm-Message-State: AIVw112pyBSQGnc57HifnGhdNjPiJfQzP3xcZ0K3BI9zdY+mklG64nfo oBbsReqqZGdynF+mPjkxqIvdlCS2odPWGrc= X-Received: by 10.223.130.102 with SMTP id 93mr6505121wrb.253.1501270961968; Fri, 28 Jul 2017 12:42:41 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Job Snijders Date: Fri, 28 Jul 2017 19:42:30 +0000 Message-ID: To: John Scudder , "idr@ietf. org" Cc: "draft-ietf-idr-wide-bgp-communities@ietf.org" Content-Type: multipart/alternative; boundary="001a114b3c44667849055565e259" Archived-At: Subject: Re: [Idr] Fw: [IANA #977101] Early allocation for draft-ietf-idr-wide-bgp-communities-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 19:42:46 -0000 --001a114b3c44667849055565e259 Content-Type: text/plain; charset="UTF-8" Hi all, I can perform a reachability test / beacon BGP announcement with attribute 34 if there is interest to do so. Kind regards, Job On Fri, 28 Jul 2017 at 21:37, John Scudder wrote: > FYI. > > --John > ------------------------------ > *From:* Sabrina Tanamal via RT > *Sent:* Friday, July 28, 2017 2:51 PM > *To:* John Scudder > *Subject:* [IANA #977101] Early allocation for > draft-ietf-idr-wide-bgp-communities-04 > > Hi John, > > We've made the following early allocation in > https://www.iana.org/assignments/bgp-parameters: > > 34 BGP Community Container Attribute (TEMPORARY - registered > 2017-07-28, expires 2018-07-28) [draft-ietf-idr-wide-bgp-communities] > > [...] > > Best regards, > > Sabrina Tanamal > IANA Services Specialist > PTI > > [...] > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --001a114b3c44667849055565e259 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

I can perform a reachability test / beacon BGP announcement with att= ribute 34 if there is interest to do so.=C2=A0

<= /div>
Kind regards,

Job

On Fri, 28 Jul 20= 17 at 21:37, John Scudder <jgs@junipe= r.net> wrote:

FYI.

--John

From: Sabrina T= anamal via RT <iana-prot-param@iana.org>
Sent: Friday, July 28, 2017 2:51 PM
To: John Scudder
Subject: [IANA #977101] Early allocation for draft-ietf-idr-wide-bgp= -communities-04
=C2=A0
Hi John,

We've made the following early allocation in https://www.iana.org/assignments/bgp-parameters:

34=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 BGP Community Container Attribute (TEMPORA= RY - registered 2017-07-28, expires 2018-07-28)=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 [draft-ietf-idr-wide-bgp-communities]

[...]

Best regards,

Sabrina Tanamal
IANA Services Specialist
PTI

[...]
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr
--001a114b3c44667849055565e259-- From nobody Mon Jul 31 01:42:29 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60B37131F13 for ; Mon, 31 Jul 2017 01:42:27 -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 nY6ojgSYqbig for ; Mon, 31 Jul 2017 01:42:26 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29773131F0A for ; Mon, 31 Jul 2017 01:42:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12753; q=dns/txt; s=iport; t=1501490546; x=1502700146; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=3+wq6vqarxmoH0tBFFw7NQaM5etPO+lLlCV17XmWuoc=; b=IfjpjkYMZv1gmBFBbDoWcoChRLHAg64k/WzEytW4M/hlAxwI4UqnCH9d Xb31R6Z9mXkMS437OS4A32bi0S84tg+rwwUyJi9rhh1HKdmsQwurnARJt XIw3nmZsIN48OLM4Ueq7wV+rebnW53A9mFRO0aRyIkDbyK1she0//6qT+ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DxAACO7H5Z/4ENJK1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgm9rgVGONI94gWuQXIUvghKFRwKDeD8YAQIBAQEBAQEBayiFGQEFI1Y?= =?us-ascii?q?QCxgqAgJXBg0IAQEXihSwAoImJ4sUAQEBAQEBAQEBAQEBAQEBAQEBAQEegyiDT?= =?us-ascii?q?YFhK4J8hE6DOYJhBZ9vApQlggyJJ4cKiVODOohlHziBCncVh2Q+iCaCPwEBAQ?= X-IronPort-AV: E=Sophos;i="5.40,441,1496102400"; d="scan'208,217";a="276657817" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Jul 2017 08:42:25 +0000 Received: from [10.82.174.66] ([10.82.174.66]) (authenticated bits=0) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v6V8gLwq014535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 31 Jul 2017 08:42:23 GMT To: Robert Raszuk Cc: idr wg , "" , "Simpson, Adam (Adam)" , Jeffrey Haas , Keyur Patel References: <9fa67eb0-8f99-a46f-aff1-d42a279ab833@cisco.com> <806a82b2-36bd-70d2-a37f-8377fd37f4c9@cisco.com> <69816cff-d7ff-3714-c3e7-c504bfe1997c@cisco.com> <819b4a1d-9631-2bfe-caed-59a47aa223c8@cisco.com> From: "Juan Alcaide (jalcaide)" Message-ID: <3f97df97-5d79-cad5-1e7c-b028d73b1724@cisco.com> Date: Mon, 31 Jul 2017 10:42:21 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------683931C311841118BFFAEBC9" Content-Language: en-US X-Authenticated-User: jalcaide Archived-At: Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT (part 2) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 08:42:27 -0000 This is a multi-part message in MIME format. --------------683931C311841118BFFAEBC9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hmm So basically the receiver (PE) would have to expect update in any SAFI (133 or 134) for a flowspec rule with group-id info And we would not support synchronized controllers or controllers coming from different ASes (one controller may have only one group-id+action for that NLRI, but the other controller could send a different group-id+action) -J On 7/28/2017 8:28 PM, Robert Raszuk wrote: > ​Juan,​ > > So your choice is: > > - Use SAFI=134 whenever there are group-ids > > > ​Not always. I can see number of real use cases for group-ids without > ​overlapping NLRIs. In those cases there is no need to use RD nor SAFI > 134. Normal SAFI 133 will work just fine there. > > - Make sure RD is different if NLRI is the same but group-id is > different > > > ​Yes, but only if you have ​a local deployment case of different > actions for the identical FlowSpec NLRIs and different group-ids. > > > ​//RR.​ > > > > > > -J > > > > > On 7/28/2017 7:58 PM, Robert Raszuk wrote: >> Hi Juan, >> >> Looks like we have reached the point of some agreement :) >> >> Two last comments from me. You can discuss choice of solutions >> with authors of draft-litkowski. >> >> >> > - Controller keeps track of all RD it has used and makes sure >> it uses a different one for each new route it sends >> >> It should use different one for each new duplicated route it >> sends - not for each new route as such. Those all can be used >> with the same RD. >> >> >> > Whaever approach, the way >> draft-litkowski-idr-flowspec-interfaceset is described today is >> incorrect >> >> I would not go that far. It is correct if you *only* assume that >> group-id is *only* used to limit the scope of application of >> global flow-spec route. IMHO it was specifically written with >> that assumption in mind and with such assumption in mind the >> draft is still correct. >> >> The draft may explicitly state that given NLRI can be used only >> once and that subsequent update has the normal semantics of being >> an implicit withdraw. If you have customers who require different >> actions for the same match criteria perhaps you can provide >> solution in a different draft or just use SAFI 134 as already >> discussed. >> >> Cheers, >> Robert. > > --------------683931C311841118BFFAEBC9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hmm

So basically the receiver (PE) would have to expect update in any SAFI (133 or 134) for a flowspec rule with group-id info
And we would not support synchronized controllers or controllers coming from different ASes (one controller may have only one group-id+action for that NLRI, but the other controller could send a different group-id+action)

-J

On 7/28/2017 8:28 PM, Robert Raszuk wrote:
​Juan,​
 
So your choice is:
- Use SAFI=134 whenever there are group-ids

​Not always. I can see number of real use cases for group-ids without ​overlapping NLRIs. In those cases there is no need to use RD nor SAFI 134. Normal SAFI 133 will work just fine there. 
 

- Make sure RD is different if NLRI is the same but group-id is different

​Yes, but only if you have ​a local deployment case of different actions for the identical FlowSpec NLRIs and different group-ids. 


​//RR.​



 


-J




On 7/28/2017 7:58 PM, Robert Raszuk wrote:
Hi Juan,

Looks like we have reached the point of some agreement :) 

Two last comments from me. You can discuss choice of solutions with authors of draft-litkowski. 


> -  Controller keeps track of all RD it has used and makes sure it uses a different one for each new route it sends

It should use different one for each new duplicated route it sends - not for each new route as such. Those all can be used with the same RD. 


> Whaever approach, the way draft-litkowski-idr-flowspec-interfaceset is described today is incorrect

I would not go that far. It is correct if you *only* assume that group-id is *only* used to limit the scope of application of global flow-spec route. IMHO it was specifically written with that assumption in mind and with such assumption in mind the draft is still correct. 

The draft may explicitly state that given NLRI can be used only once and that subsequent update has the normal semantics of being an implicit withdraw. If you have customers who require different actions for the same match criteria perhaps you can provide solution in a different draft or just use SAFI 134 as already discussed. 

Cheers,
Robert.


--------------683931C311841118BFFAEBC9-- From nobody Mon Jul 31 11:39:33 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3BE1132780 for ; Mon, 31 Jul 2017 11:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 zNfV1PKfITO0 for ; Mon, 31 Jul 2017 11:39:29 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id B009613277F for ; Mon, 31 Jul 2017 11:39:29 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 078A61E380; Mon, 31 Jul 2017 14:39:41 -0400 (EDT) Date: Mon, 31 Jul 2017 14:39:41 -0400 From: Jeffrey Haas To: "John G. Scudder" Cc: idr@ietf.org, hannes@rtbrick.com Message-ID: <20170731183941.GV24942@pfrc.org> References: <5436099D-D57A-4D29-A744-0E8A3572845F@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5436099D-D57A-4D29-A744-0E8A3572845F@juniper.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Idr] allocation policy for BGP-LS registries X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 18:39:32 -0000 John, Answering your original question: On Sat, Jul 15, 2017 at 06:41:49PM +0300, John G. Scudder wrote: > You may have noticed that I just sent out a few emails scolding authors for squatting on code points in the "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs" registry. This is one of the things I least enjoy doing. > > I notice that all of the BGP-LS registries have the "Specification Required" policy. Experience shows this tends to invite such behavior. I further notice that three of these registries are for 16-bit spaces (BGP-LS Protocol-IDs is an 8-bit space). > > I'd like to invite discussion about whether the WG thinks we should convert the three 16-bit registries to First Come First Served (FCFS). In keeping with prior discussions on the topic, I think these three registries should be converted to FCFS. One thing this thread has shown yet again is that long time participants are confused over how easy it is to get a FCFS code point. Or even an early allocation for that matter. Really, whatever it takes to stop the foolishness. Including some XML2RFC markup that says "I'm squatting on this code point" that lets the tools actually pick it up. -- Jeff From nobody Mon Jul 31 12:12:54 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EBCF1322F6 for ; Mon, 31 Jul 2017 12:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 0AJUTtl2wC2E for ; Mon, 31 Jul 2017 12:12:52 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 45186131945 for ; Mon, 31 Jul 2017 12:12:52 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id A51F11E380; Mon, 31 Jul 2017 15:13:04 -0400 (EDT) Date: Mon, 31 Jul 2017 15:13:04 -0400 From: Jeffrey Haas To: Enke Chen Cc: "idr@ietf.org" Message-ID: <20170731191304.GW24942@pfrc.org> References: <441c2f03-e061-726a-4b14-14c452d25f2e@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <441c2f03-e061-726a-4b14-14c452d25f2e@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Idr] Comments on slides-99-idr-03-idr-rs-bfd_ietf99-00.pdf X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 19:12:53 -0000 Enke, On Fri, Jul 21, 2017 at 02:20:44PM -0700, Enke Chen wrote: > I have several comments on slides-99-idr-03-idr-rs-bfd_ietf99-00.pdf, > Page 10 "Why not add-paths?": > > •Some IXPs do not want to use add-paths or their customers may not want to use it. > > >Enke: Do we understand the reasons? Please also note that the add-path can be > >Enke: deployed one a per-neighbor basis. I'll have to leave this motivation to the coauthors, who also are associated with IXP. Resource consumption has been offered as an example consideration by others. > > • Which backup path? Degenerate case becomes add paths all. > > >Enke: The RS uses a route selection algorithm for the bestpath calculation. > >Enke: Is there an issue with using the same algorithm (with the bestpath > >Enke: excluded) for selecting the backup path? The point was intended to address the case where N paths are available and you send a fixed number, say 2. So, if 3 paths are available and paths 1 and 2 are not reachable, you're missing the third path that is. My general experience with customers deploying add-paths is that they select a number of paths that both matches their resource consumption and their use case. This is particularly important since it's not possible to usefully constrain the paths on *receipt*. The IXP case is somewhat unusual. The number of total paths is often low enough that add-paths might be acceptable to some situations. However, it used to be the case that in per-view cases that some customers may choose what IXP routes are present in their view based not only on policy but also on resource constraints. > • Add-paths is intended for iBGP See non-deployed work in draft - > pmohapat-idr-fast-conn-restore for eBGP > > >Enke: It is true that in general there are potential issues with using add-path > >Enke: for EBGP and that is not recommended. > >Enke: > >Enke: But that is not true for this special RS case. The deployment practice > >Enke: recommended by RFC 7947 is to have the clients in "receive-only" mode. That > >Enke: is, each client advertises only its bestpath to the RS. Thus all the paths > >Enke: advertised by the RS are valid and can be used for forwarding. It is really > >Enke: equivalent to having full or partial mesh of EBGP peers. I do not see any > >Enke: issue with "protocol correctness" in this special case. It is actually a > >Enke: good use case (perhaps the only one) for EBGP add-path. I agree that the IXP case, again being unusual, does remove a portion of the motivations. It does mean, however, that routes would solely tie-break in many cases on age per RFC 5004. This is presuming equal length paths. This thought makes my brain itch. Given third party nexthops and inconsistent tie-breaking based on the rib-out dissemination from the RS to a particular peer... is that safe? Possibly so. I'm not up for determinism Sudokku at this part fo the day. > >Enke: Can we get the actual data on "prefix vs path" as a reference for "path > >Enke: diversity"? Robert was kind enough to supply some stats. -- Jeff From nobody Mon Jul 31 12:38:14 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 602401327A3 for ; Mon, 31 Jul 2017 12:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 dkg2yLClOm0A for ; Mon, 31 Jul 2017 12:38:11 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 550081327A0 for ; Mon, 31 Jul 2017 12:38:10 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id DF3DC1E380; Mon, 31 Jul 2017 15:38:22 -0400 (EDT) Date: Mon, 31 Jul 2017 15:38:22 -0400 From: Jeffrey Haas To: Robert Raszuk Cc: "Juan Alcaide (jalcaide)" , idr wg Message-ID: <20170731193822.GX24942@pfrc.org> References: <806a82b2-36bd-70d2-a37f-8377fd37f4c9@cisco.com> <69816cff-d7ff-3714-c3e7-c504bfe1997c@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT (part 2) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 19:38:12 -0000 Robert, On Fri, Jul 28, 2017 at 07:58:26PM +0200, Robert Raszuk wrote: > > Whaever approach, the way draft-litkowski-idr-flowspec-interfaceset is > described today is incorrect > > I would not go that far. It is correct if you *only* assume that group-id > is *only* used to limit the scope of application of global flow-spec route. > IMHO it was specifically written with that assumption in mind and with such > assumption in mind the draft is still correct. You should bear in mind that with the redirect functionality, particularly the redirect-ip draft, that we may want very different group ids on the same filter (NLRI). The point about the additional paths is well taken. The RD hack is potentially reasonable; however, it'd require the additional spec work discussed. -- Jeff From nobody Mon Jul 31 12:43:59 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDDBA13278C for ; Mon, 31 Jul 2017 12:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 xufnRAaSk0pH for ; Mon, 31 Jul 2017 12:43:57 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0C71A13170E for ; Mon, 31 Jul 2017 12:43:57 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 8FE911E380; Mon, 31 Jul 2017 15:44:09 -0400 (EDT) Date: Mon, 31 Jul 2017 15:44:09 -0400 From: Jeffrey Haas To: "Acee Lindem (acee)" Cc: Robert Raszuk , "Juan Alcaide (jalcaide)" , idr wg Message-ID: <20170731194409.GY24942@pfrc.org> References: <9fa67eb0-8f99-a46f-aff1-d42a279ab833@cisco.com> <8dd3e766b58944a3b176fc743e478137@XCH-ALN-014.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT (part 2) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 19:43:58 -0000 Acee, On Fri, Jul 28, 2017 at 12:02:41PM +0000, Acee Lindem (acee) wrote: > What was the reason for not making the interface-group part a new component type in the NLRI? It seems that making it just another Flow Spec match condition would handle all these situations naturally. > > I remember that this was discussed but don’t recall whether it was backward compatibility or that the semantics of interface group-id was a better fit for an extended community. A few motivations: - Unknown components in the filter cannot match. - The match elements in the filter (NLRI) might be as-transitive, but policy engines don't interact with such filters transitively very well in implementations we're familiar with. However, pretty much everything can manipulate extended communities. The first consideration is partially about incremental deployment. You either have the choice of shipping a filter across your network that may be selectively restrictive per the intent of the group-id or completely ignored. The best answer, of course, is consistent deployment of the updated feature. However, this is the course we'd chosen as part of the second consideration. -- Jeff From nobody Mon Jul 31 15:04:34 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3231B12EC57 for ; Mon, 31 Jul 2017 15:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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 BOMj077_Wxw8 for ; Mon, 31 Jul 2017 15:04:29 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::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 A04D7127010 for ; Mon, 31 Jul 2017 15:04:29 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id h199so1845590ith.0 for ; Mon, 31 Jul 2017 15:04:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=LSRrfpHzcNh8tBrJsXoVyU/2fPgplIP3fv7GfTEZu/s=; b=mLXETL1xn2E05uIYhudQo/twj/UGRq6rRSW+dA7CKzC7fK9nZQC4Al01vtQdwh3xdB WlSJWaHDmII4M/haTRK1wwDfOFgXlGxPCLsAnf5oJdMY5L+zGZgQujNj9mxrM33UPzQ7 j3MkL6F/hXxOgUCGiF6wD1K97HTsT3/HX5Fn9sHKkmnc51D7jlRSEh0khdqNI7mzp3kq JgBvlHAraoKuK433bRyJpgijgoWa/ViAiGd1J0XzYftAJKh+jKI0+u0YoC8stTqKfJlM mZuuW4ZFAvDKj2pNONB7CRSmgbDnB9ukf9/L9EOzzrzGshJamQvtlHcl6YPlkHqdomvs tGfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=LSRrfpHzcNh8tBrJsXoVyU/2fPgplIP3fv7GfTEZu/s=; b=MVy9YkWeUSzgpfpU3XEYv564lW/W1SWo7HPFllwppoiFQo5Km0YKk0liF4Nnoib0+w Trihhwfa/x+cgCu4VXXrAop5Uv10fqylm5vazzGzsENgZ8yXxavvlHvszKOHhzsTsxl/ S1cp41meG0MceivBeI9HlOGlG4u+ljBC1q1zWjV9rnawmPLZGkY+2rwz+3wSTIACuVHs dFT7ZmNMSwBi6TDU1lWHVn9JU3jjJFIEEPpgVP+b7NUxmeWSg64zyX/eJdWtP6yrJjAH R722GXL0f31iMRtqazlsB0vucDQViqQYisedjY+jDJkpu6KOpQd8vnUowRmC6kqE4b63 LQMg== X-Gm-Message-State: AIVw110Z+G3qYzjeGfjR+t+9wWN6/n7kZyceQkBbczPQkakUoEYhA4qX iPMjQjV2oBMdnb4Ud/YtMYCKn7iOrg== X-Received: by 10.36.105.82 with SMTP id e79mr21079391itc.118.1501538668685; Mon, 31 Jul 2017 15:04:28 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.153.21 with HTTP; Mon, 31 Jul 2017 15:04:27 -0700 (PDT) In-Reply-To: <20170731191304.GW24942@pfrc.org> References: <441c2f03-e061-726a-4b14-14c452d25f2e@cisco.com> <20170731191304.GW24942@pfrc.org> From: Robert Raszuk Date: Tue, 1 Aug 2017 00:04:27 +0200 X-Google-Sender-Auth: 1SLh495YJf_2Fv0yZFEdvjrRfHQ Message-ID: To: Jeffrey Haas Cc: Enke Chen , "idr@ietf.org" Content-Type: multipart/alternative; boundary="001a1145a6b6f6ae3e0555a43623" Archived-At: Subject: Re: [Idr] Comments on slides-99-idr-03-idr-rs-bfd_ietf99-00.pdf X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 22:04:32 -0000 --001a1145a6b6f6ae3e0555a43623 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > > >Enke: Do we understand the reasons? Please also note that the add-pat= h > can be > > >Enke: deployed one a per-neighbor basis. > > I'll have to leave this motivation to the coauthors, who also are > associated > with IXP. Resource consumption has been offered as an example > consideration > by others. > =E2=80=8BSo if resource of ADD-PATHS ALL is a major concern here how does n= ew SAFI solves this as compared with just sending all eligible next hops from RS to clients in a new attribute ? After all client must establish all BFD sessions (or other probing) to detect liveness of next hops, but client would not need to report back who is up or down and would not need to wait for RS computing and distributing new best path. He can simply switch locally forwarding to go to those next hops which are up. Likewise RS would not need to become super powerful controller ... Thx, R. --001a1145a6b6f6ae3e0555a43623 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> >Enke: Do we understand= the reasons?=C2=A0 Please also note that the add-path can be
> >Enke: deployed one a per-neighbor basis.

I'll have to leave this motivation to the coauthors, who also ar= e associated
with IXP.=C2=A0 Resource consumption has been offered as an example conside= ration
by others.

=E2=80=8B= So if resource of ADD-PATHS ALL is a major concern here how does new SAFI s= olves this as compared with just sending all eligible next hops from RS to = clients in a new attribute ?

After all client must establish all BFD sessions (or other probing= ) to detect liveness of next hops, but client would not need to report back= who is up or down and would not need to wait for RS computing and distribu= ting new best path. He can simply switch locally forwarding to go to those = next hops which are up.=C2=A0

Likewise RS would not need to become super powerful controller ...=

Thx,
R.


--001a1145a6b6f6ae3e0555a43623-- From nobody Mon Jul 31 15:55:41 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F907129ADD for ; Mon, 31 Jul 2017 15:55:39 -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 zkN8LFl_XzNf for ; Mon, 31 Jul 2017 15:55:37 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6767C129B4C for ; Mon, 31 Jul 2017 15:55:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1520; q=dns/txt; s=iport; t=1501541737; x=1502751337; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=f8lruFGfHFpHW5DDKtGn/5A4kHdyrjThf9RR6Jf5Fbw=; b=lrwVH53jB2B1er4KY4dQd9lvVYvsZw9LsEPfKJ9gEg/6kUEgMoMsZAJq h2pdCEriFcxxv0xvIsaLpvPvvKWWXKn+soqKrQzpP25NkoV2tL8neFWUX eAsr9isu8m2o15c/emQZxHmNe5kK+T2Uvcve/Z8BQyBMGvXYXsaAuef2g A=; X-IronPort-AV: E=Sophos;i="5.41,304,1498521600"; d="scan'208";a="274834706" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Jul 2017 22:55:36 +0000 Received: from [10.82.174.66] ([10.82.174.66]) (authenticated bits=0) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v6VMtYk4005349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 31 Jul 2017 22:55:35 GMT To: Jeffrey Haas , "Acee Lindem (acee)" Cc: Robert Raszuk , idr wg References: <9fa67eb0-8f99-a46f-aff1-d42a279ab833@cisco.com> <8dd3e766b58944a3b176fc743e478137@XCH-ALN-014.cisco.com> <20170731194409.GY24942@pfrc.org> From: "Juan Alcaide (jalcaide)" Message-ID: Date: Tue, 1 Aug 2017 00:55:33 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170731194409.GY24942@pfrc.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Authenticated-User: jalcaide Archived-At: Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT (part 2) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 22:55:39 -0000 My 2c on top of that: A policy engine able to filter and modify parts of the NLRI (group-id) is not something trivial. It's not in any AF. We would have to rethink how to do something as trivial as a route-refresh -J On 7/31/2017 9:44 PM, Jeffrey Haas wrote: > Acee, > > On Fri, Jul 28, 2017 at 12:02:41PM +0000, Acee Lindem (acee) wrote: >> What was the reason for not making the interface-group part a new component type in the NLRI? It seems that making it just another Flow Spec match condition would handle all these situations naturally. >> >> I remember that this was discussed but don’t recall whether it was backward compatibility or that the semantics of interface group-id was a better fit for an extended community. > A few motivations: > - Unknown components in the filter cannot match. > - The match elements in the filter (NLRI) might be as-transitive, but policy > engines don't interact with such filters transitively very well in > implementations we're familiar with. However, pretty much everything can > manipulate extended communities. > > The first consideration is partially about incremental deployment. You > either have the choice of shipping a filter across your network that may be > selectively restrictive per the intent of the group-id or completely > ignored. > > The best answer, of course, is consistent deployment of the updated feature. > However, this is the course we'd chosen as part of the second consideration. > > -- Jeff