From nobody Wed Feb 1 08: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 9B72F1294D4 for ; Wed, 1 Feb 2017 08:42:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.057 X-Spam-Level: X-Spam-Status: No, score=-3.057 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_H2=-1.156, 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=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kOh5NlSVXJW for ; Wed, 1 Feb 2017 08:41:59 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0091.outbound.protection.outlook.com [104.47.37.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9616B12941D for ; Wed, 1 Feb 2017 08:41:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=stKNGeG42hK3lwAII3/JQ+sxuwFHNJcl9rvmHDTdFS0=; b=fGHkFselwhq8GO0NQgkIJWKPknkmLcobCz6PZUaVtHpvFCmlLdbnwr3Q/gkg/qjN0FUJ0tHxb9+Q5VHsFYrzVgqK7QxlHTVT3Iy1lHMRAV6xxu2YWnK6jFBbBjwzVKijjwQUa7k7/725Bz+57V/WgmhZ2TVcIdefbtxBZzq3uLQ= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from [172.29.99.117] (66.129.239.13) by CY1PR05MB2506.namprd05.prod.outlook.com (10.167.10.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.5; Wed, 1 Feb 2017 16:41:57 +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: <36E285C0-C716-437A-806D-A453273146DD@juniper.net> Date: Wed, 1 Feb 2017 11:41:50 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <1D651738-BCED-4F25-88B5-5257871697DA@juniper.net> References: <36E285C0-C716-437A-806D-A453273146DD@juniper.net> To: idr wg X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.239.13] X-ClientProxiedBy: MWHPR02CA0003.namprd02.prod.outlook.com (10.168.209.141) To CY1PR05MB2506.namprd05.prod.outlook.com (10.167.10.27) X-MS-Office365-Filtering-Correlation-Id: 2fc741db-7917-4171-2041-08d44ac13d2a X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR05MB2506; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 3:+J7/Rg+x8gC7xziE0ko6fl4cuq3wqhls5Fv9Ra7jJezZuxfldgHtDG/nNAOdXzER6KXUnN+TWrKDOPimQ6abc7KKD7tGty7Q9vv3NIlPVhHUGDnWbvBc66MqvYfpxfjN5AGyvbPFhs9FvQgTpM0Hwx9yrArRqlImo7bQxTNoAF3E7Lwt1EljGaKrJ9K3VTrjO6+s0VYosxcmpF8+Oi+272J66gsyk6cF97QqHLbT4Q3e9kebAhFVmBgbK4wY1Y7JRIEmclWXGHEyjyolM6UMjTP2EWTqm7s3Qi3+Vvdh5jc=; 25:Tqqoia3r38/S/ztIAbzkDWLoCefbqJPHljwKfuyczXBFRme170Z2bwXokEr0/SW9hiZaZidYUEUcp8Sgf1FMeh9gjutHSySrJjitR1XCXBfZiiZsde42YYD9iAD+msETTupJe0ZKnfWXIkRzPw0qIYCpsrr/RX4HWJPtEJw6OwumgTBr2GDIQFGG13YQ7iYgaUAwdb144FMgJelJ7Ft8lRtt3OZlz0XGSy65AZWeiLvSbzjfFUAYLVTtjTnilancRK2k4uIvLN02VMh+Yz3ofnh6yt061OAz0sTolqoK+c0tPREnVRfMEuygZsyykb9v+eVPquNRy6v4vV7hwKCFm0qqa/eQIBAmihkux9uiUdk978aqHPnYZCMQxhY735+6AisMW8IePWD2eN8en+74Xd6JJLhqJSbnqRJeRBIEwhOO6VJOXU2DeQIh8yUz1qSvdQwlIV9KPSlq1oMmmXW3Og== X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 31:SQA6SR8d86kNrpD5XHjWCos6PJkUsS6Zz/peNnf3r3ZBw3m0Tnccd8TeZXB2WSWV3fDgcQerES7Qi/Jx9znHl057TIlX81DLpr9G/3jxfXXCpsJbqYIyvsCV0OWHmDiXmtStynlgCMgBkD+72ClDIbwoE2eUOhRPW00Lqt1TNBfCGA5P1IzgrterT444vdmRxd7eE/zdhTaxNgCnLLNV6UlHK2k9OqCdmoiaY4tXgBwoNKzY110zmojayDiq4Le0l7910UsbuSc7R3rjIgQzqjE7QIX+ukD4vOxyBmVpABgZY+k8nVMVsePOZ9Qc8nFJ; 20:K6ufEqs1o0MnNG2yt72sxah4vBSyWqMck0wpCJ0oFBahmNarGPb66LFFdts5dVGGhOQPVBJ+W0r8KBpQPzXO7YWzhXseWr1Vq2PRlXXEJX9CViAfuGWCNsSDyILrICckDHwg2jrKf+Y9DaaeViAoKFq1Kp1WBxbtNBTecRKRqWutDaJVfLXwQSo4ycUZLBuWkwM2DMC3dtexI47++FUYGFnR5T/l06tiEke2kQGZJYWLEg/EVnI/4gUdLJsy+4trt9U1BzUBh/qwNxWM/AQAENw6yww8YQbjqG+bgMW1vE6apu2iQl892+rpIU9AIYZ8hobeQJrgDuh/xIquZORlYMvVgFkw5b2N3cJ/xQtHmNHFptMKBzMGh98leKQFm3UC5ilHqcuYIST8ZXZXczi1iANuWUJK0Fuck7qSLAiDB0JvJJeD6+C3zOwrF06+OP+DNRI5eOtxwzqIUlucNZ94/rwgobrFXW1WpoMv2cGvxw8YoYf9NXE8bq0ZUdmxtxLr X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008)(100405760836317); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(20161123558025)(6072148); SRVR:CY1PR05MB2506; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2506; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 4:MguZ8fKvd3EXfY2BUwW702JNyhMwOeeQLUzJomwDPvSqGBvjRFS8rxn1aa0LBb+lfnTvkLun77+dtpAfsVkFCUiNzkNj5wBHZ12vu6dsfdJkK7I/h4bUVs1b21DQZOmISc0729IMZX2w2EgWqsv78qHeopmlJvifJUf6lbdFRZHrr5z/2pK+86HPEzEye+FA3BaZzvu6kncCUW72bwp961qlCDXZo/FZWZc/KbDszfyHHiwcrJN4O/YFp6PAP/GFzhNw5kTNwNBWjtUJ+TNaOZ9cXGlD60s1GqV7bi1G0N/jgLqnWsJpK9+V8YhdyrAFQoh+tGz/zezcaRN21pg5BDXCyge8LTvddgJgmMcvj/3BUKlTY/DmqRjkeGfwtl7hEkfeZygRgYq6hfLzz9qJIJWYsAqzYBMbcgL2gSHA3BnKTU65N0HIBpvC8XL/TM3ajZiRYqUhErsbvR+KQJ9YokiRYVkKFINeY+Ss08pxhSe2SLWQTlUejUCAN0oF7596y/sKoO9SIJ0d3wa5aP5A0DTbY8thhBnFSJEVF4P6FJBP7nhEGmqOx/1rajUcrEjfk2DSIVQsiQ1zMyPs+HE5IDBDLlplrvWm6OqyMMh7ZfJkBGYcQ7lXfqShz7Qu4GpM1n29YiO21fwWPiIMXqjOC5tK0kd1sMtdEZ1tX0jwwN60Jt3aOzv55hZSIcSM1MHglS0FG4TzHPFpthEWAzfI9g== X-Forefront-PRVS: 0205EDCD76 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(39450400003)(39860400002)(39410400002)(39840400002)(39850400002)(377454003)(24454002)(189002)(199003)(53754006)(25786008)(189998001)(229853002)(86362001)(23676002)(77096006)(68736007)(82746002)(107886002)(90366009)(6486002)(8676002)(50466002)(305945005)(42186005)(105586002)(6306002)(81156014)(7736002)(106356001)(38730400001)(81166006)(97736004)(83716003)(47776003)(110136003)(33656002)(50226002)(230783001)(53936002)(8746002)(92566002)(57306001)(66066001)(6916009)(6116002)(2906002)(50986999)(6666003)(3846002)(36756003)(2950100002)(450100001)(5660300001)(76176999)(101416001)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2506; H:[172.29.99.117]; 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: =?utf-8?B?MTtDWTFQUjA1TUIyNTA2OzIzOk1PeHJJZmpsTU1pTzg5cWVqNTBzbytiZUhy?= =?utf-8?B?UlBibnJlemRnT2F1OThpc1FPSFczNUV6MzVDSVRBVG9NNGVuOWZEWW1sWjhI?= =?utf-8?B?ZU0vL1VPdnpIcDgvUlZEWGFhMHd6VncwMys4WkppMWsrbEdkTHM1c1p3S3NN?= =?utf-8?B?YUtOUmViRFoxQmRIYTEwYmk4VndPaUNGTmE2SWpvK0IwaVJ6RUx5QWN6T2Nv?= =?utf-8?B?aXRhNHVBUmRmc2VSMDd4OGRnaGZsb2RBSnpRR1ljZkNKSFNaWDk3Vlk4RGR6?= =?utf-8?B?UThsUHpNdE5Ca0MraTdaRHBxUGtoUTB5QlZYU29tRVExWldSMS8xYXdRVDFN?= =?utf-8?B?a3lNTWdIWlptZGFLZXhReW5XcmtyUEY1dEd0ZXhaTm9oODl4eHczSXM0cWE2?= =?utf-8?B?MmEwaHZCVE1LL1RtTmFsbExsZFBhUjZRcllqTzNNRGtFVDJEdjNnVjIvU0FH?= =?utf-8?B?eVh6QWwzOFNIejZNU1VqbElRdkd3WElUMG5RYld4NzBtdTg4UGJIQWtoWTl3?= =?utf-8?B?M2hvNml0ZDRCRHN4bUsvNjZ6ai9MRXUxeEFFVTZDQlNlZGQwTkQ5dHZpaXpC?= =?utf-8?B?M1B6UG9wSGQ5MTkzUVJxSUFId2ZUdkRrWU5uUW5YazY1UG9UYUdqR3h3RUZO?= =?utf-8?B?NXdXOHhpVHF4YTF4dWZPMHMrM2paVGJaV05NVXYxQjZmSjMxZ0poNDQ2NmxH?= =?utf-8?B?cXEzR1ptZ1BORGdJTGZJTW5EdHRhSWNXdTFnRjRTeUd6RUVYK3o1YVhTT21B?= =?utf-8?B?WWVKa29raC9KYTRFaEVtcHRSU1lSK3dzelZucmU4NUU1TlJSYnRlNTdKQVNk?= =?utf-8?B?TkVvaEUyTTl2UHkxUTNUeWF3SU8vZTZzQTNYMFJVcUczdTR5MllhS1gwdkI0?= =?utf-8?B?RnJGSHFQYlBLWGYzMS9yc2pPM0ZybnNBRjVIOGdNR244M01naDNnbTN0b2pt?= =?utf-8?B?Rk9EUUR2WWo2TFNWZWp2YnQ3ZGw1SmFqL3ZEM1R4T0lNN05BcVhPWEowKzZi?= =?utf-8?B?T2dydFBVOE54R1BuUHhNZmQvdUk2eFZaYUtZUWJsaTZrQk81SGxVZzFWMFlW?= =?utf-8?B?cmcxbE14eWFUSFBVczF4MzROQVRmdGZrUSsvQjFBYzZUdE5GOEFuYlpiVFdU?= =?utf-8?B?TEt6ckJIVHNyOEYxQWdQWEVBdFdKbWZsbHFYRTB5anNXQjh5dFp1cnlLSWVO?= =?utf-8?B?ODhWTlVyc0VrM09YRXEzYi80Wm1GcWtPaWxCeCsxeXE5V0ZBV1dpSVVBWVpL?= =?utf-8?B?SVpqMmVIR3dNQXN6YWo3eERMcHhEclB1OXRXZ0ZSUDJXMTFjNHpRcjlIUks0?= =?utf-8?B?eHdhQUhlQlF0Mnl4R2pJVUdRL3B6YkllZDV3dkVyUUF4blNHOE02eFprMjdC?= =?utf-8?B?OGZwbThTWGw1dHRTOTdiYkRpcXg5d1JoTFpYZXJEU1E4MGpyc2JqMXZVcFlE?= =?utf-8?B?SHF0SS9ySUdGYlMvem0zWFBMWm1SUXNKM08wUzJqWmtCZElPdHZ0aEliaHFq?= =?utf-8?B?WFg4NE5sbXRjb0U0UWRJNmFLeTRZSUV0dFZvZlkwbEFBaUxaL0RTWlYxN25R?= =?utf-8?B?ODYrSFZTMU1TVHhkUEJZQjlobXdxYUtjMXdXd2wwTWFORzh1d0xlUjI5bzlT?= =?utf-8?B?dlhBQU56ajhQUG1qbDFZRStrNlZvOXF2cUJDem9ReXNKVERqdm81Nm9HSWVE?= =?utf-8?B?ZUlIblFEZ2dTaXlZb3JqeldxZVF5NHZKckF2RytSQTNtSkllZmNUNFJYZ0Rk?= =?utf-8?B?NDRpOTNSQXdhZmNrenNBbGxNNTkvSDAvcHJxelQ1Z09FSHRaMGtXMVY4QzJ0?= =?utf-8?B?SWp4bUR5NzBMN2ZQSUQwUFF2QklxS0JiOGQxT2pzMElmYjh2UGRkM2R2K3pC?= =?utf-8?B?UE5zUDJpVWROdnFSblJTc0dpb3lrUHltRlk1emVXamVKT1NhM1ZXamVvWENO?= =?utf-8?B?SkpKZERyRE5mU05CNEJ1UjR1dW96Ris2WnBTd05CdnZxcExqaGgvdk9SSG9K?= =?utf-8?B?SlY5eTNVb0x2MHRQamt2OXpVNHpYemJ4R2dwdz09?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 6:PIFqjvBFV0lezM91D1kVa6RiMS4jChTiQmCHRIPjpIlvhBneOgUe/vdM/azxJ5vuZbD/z2GJm6nh49/9mhh86dqK561Lw1OmGMw/b8vdbIGEObAKG9oMADSFT0LoE4HOaGujtshMUIByNWya1ukZ4SJvNrk9JICAqlz3bFw9ZVG58Co6xPJ8y9ZwZeWmNeaifvfN1jHPa3Aw+QOurTx0MIbc+apCASnOYJerZd35uAA9lj9SRU+yLY3dgIPoAw2ygozWd1/SvycKYyjfueFv3z817mJpiFw4NHEAAsc+FAr3H7ru1APOYV+FL0VmMiZxnNv4mReqi2du2gYKHZUACpqMJVCvE4ACsPmjTmKYFgZdm3pr9tjbckCpwzaLZ34E1Clf8oTCuXEnXt8h5mhwmmhpdEZh0xZwbjE7QyZyLzk=; 5:6GVA9P4Eer+U5hI3VkpIbprRdpQ+iPQUj2eut3dBKQxZhXns7YhgXmrOpQc3fUk01Ku0SQjFJeY0j9epjYhxHAmpTLfO+asXnehGcjBgY4OwHcTszwxqgi2qOq27iCsR3XRE6CdUlcRO7MTvNyK03Q==; 24:SyrKoGMGFoasYtfFv7llDHX7hfDJaZTIwpiVvyCQtY1BIbI2gVnnDOfV1RSeTLOKbgk/rxE7frqxR0O1LfvFlmz0l05LdlIX2P8Pvb2yois= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 7:r6GfDZa+fYDdKxYrWQsYhv3nwx2+0YrW121z4tyoobFvlgGFDdh2fHPmcCh3xYQImHsZt3a63jgJ1u3RKhxXsu5Ht4eGjpxWg2PLBwUjWwjRshElhJNFP4+hRyksBytExFAqtdhj6V34ZOr+4aTYENUVPur931f5QSDc0ox54A81Y/wrwW1Z9aHxnM0cKNjkrEpsyExJ/KpG7YLx70TmbjA1lIlDs2wZeUx6MMjjHWe9JXmtub1BbZjdMzLvxY1QfJV4FPc0Fo5I7ez0wHTpjVARKKTZ1VLi3yuQi4ACPCvXSay+SSeknpH4jmzNpmjNvwc3pQUeuiWU4jyhiyWbMeubVQPTxs2oMkWM6g28m5b431tjeyDnRCRkMnTpXc2K66ILlgclOaMN3dHnptFM1PDHkCSDbgXMMYfelAb/YcIObOAlm3u1+lmzgD25rFikUtlAonfBoW8ieFO/0W6xUxYjAd/Fd7imcntzxxtzJWsVC/g5c0vQHQtW3R0B3s6GMG1N8dV8QuZtaFRVyjrLeQ== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Feb 2017 16:41:57.6713 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2506 Archived-At: Subject: Re: [Idr] WG adoption call for draft-hr-idr-rfc5575bis-02 "Dissemination of Flow Specification Rules" X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 16:42:01 -0000 Hi All, Reminder, this call for adoption is going on and will end in five days. = So far, the only reply has been from Christoph (thanks!) with a pointer = to his paper "BGP Flow Specification Multi Vendor and Inter AS = Interoperability". The paper is long, but I encourage you to look at it. = To encourage you, here are a few excerpts from the conclusion: "we think that what we listed as bugs sometimes is a result of unclear = sections and definitions in RFC 5575" "With this update we think that a proper interoperable implementation = should be possible and unambiguous sections have been improved" and perhaps most motivational to the WG: "Given the current bugs, interoperability issues and missing features we = do not recommend flow specification BGP sessions between different = carriers [=E2=80=A6] Invalid flow specification NLRIs or action filters = have the potential to remotely trigger a complete network failure." If you do NOT support adopting this work, it would be interesting to = hear why. For example, do you think RFC 5575 is fine as it is, and if = so, why (considering the issues raised in the paper and on the list). Of = course, it is not IDR's job to document and fix implementation bugs. But = it is *exactly* our job to fix the spec if it's ambiguous and that = ambiguity leads to interoperability issues. If you do support adopting the work, please remember to say so on the = list =E2=80=94 we can't declare consensus based on silence. Thanks, =E2=80=94John > On Jan 21, 2017, at 10:03 AM, John G. Scudder wrote: >=20 > Hi All, >=20 > The authors have requested IDR working group adoption of = draft-hr-idr-rfc5575bis-02 "Dissemination of Flow Specification Rules". = Please send your comments to the list. >=20 > This adoption call will conclude on Monday, February 6. >=20 > Thanks, >=20 > =E2=80=94John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Wed Feb 1 10:07: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 68FEC1294D2 for ; Wed, 1 Feb 2017 10:07:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 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_H5=-1, 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=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbB6QPuPVSop for ; Wed, 1 Feb 2017 10:07:13 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0104.outbound.protection.outlook.com [104.47.41.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A036E12948C for ; Wed, 1 Feb 2017 10:07:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rn7Z9LakDuZw9WEuGYp9SHBodm1xfISKoSShgz2QSE4=; b=MTRgdro8FH8zyp80K07oHEtJ2rtFxF7J7AK9sg1D6iCuSzuLRBaMjphQ3JMe92XlEsJ+AhLBAXx5rvv7ZsWBnigmzHj6xdC7vV8mvFBXqT2/VcDw3qFN51WNOuCYV80DBSKiy2Y2DAPhIQWg4lefiS+etmBcV1WRx2JnNhmUjHE= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from [172.29.99.117] (66.129.239.13) by CO2PR05MB2504.namprd05.prod.outlook.com (10.166.95.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.5; Wed, 1 Feb 2017 18:07:10 +0000 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: Date: Wed, 1 Feb 2017 13:07:05 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <2C63EEF7-3227-447B-AC6B-65C15699DB9B@juniper.net> References: <01fa01d27677$3c54c560$b4fe5020$@ndzh.com> To: Robert Varga X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.239.13] X-ClientProxiedBy: MWHPR02CA0001.namprd02.prod.outlook.com (10.168.209.139) To CO2PR05MB2504.namprd05.prod.outlook.com (10.166.95.150) X-MS-Office365-Filtering-Correlation-Id: f0877fc6-32d3-44d2-fd1c-08d44acd24e2 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CO2PR05MB2504; X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2504; 3:ShJ7tcCzK6TSiMjSxFv0ffNcPEnYoC5yCyeXOY1DhX4l33G+BDJDn+/WOcYRWqhIZN0z1U4ZgIdbO+aY25gE0T3N5zMmquc25fUKhBtP9s67JeqNl9eigW7ccfXq+mXgtviyNPaHNIPA1OPV/Vk4+fWSWLQQt/fPFgLI4DpjXC1lEp/7/B9msTa0mQQQaWXRaOtdgFe5aUNt18GkPHPSJlXOY+TpSi1B9qcC2a/zoCbIx/FUILm0pOPbIQH2ejPlksY0IXBQsEKQ93ffSEnf8gSxJx66Ha2Or7aVQtRFCuo= X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2504; 25:9faTb2MU3yQRN3hi59c5VUZUYhsGRHV9D7tu9P34fp4Irmb5RytGGvEmmp5Imxn6uRMa8k5iW8SAbW5n7Nytfad4zanET1qhVXrTiQekMJkYw2wfio46z7WOnbhUzhgbCw3U5BO0MGFdwE4uUEfW7WPmKHEhJ7ePcaDlUaKSuuGyoVDZYYksW1vTRMPZ3tUC+zctNgfTBPFRH2OdF4TZjELb3+AckJeRuNQy1ZKqHSABCfJZaBHOw/v7rorzbhVCHe6Ka9lipWZ+8oFZ8+J23cF8Pe0ewwDyejzipdQOGmBi0KeJShDIUV/S1V4T4s3fjEpE5Gf3BqYio1lqPih+8RJ8FVJkX49H9NhNgKm6c/5GNZvGj8DtLC8pGwJk+I56K+a4xByqc/8MFY9eWt3DDB8P/pzhDqSbh0Yg1T1H7zyInLDwf5mJsx4JLZJoNc/x9CSscP5rWFC8O1l/a7Om3YI3pOdGLAYlH/9+UA0jnc0PYpmUInKvk15FmcOs3mfjs2OYdAG4a1d5u3ticOMqBFZelpOP95u7ZPC614NuYs7WtSBDUcyAxz8FduEAbgYIbkrDorVKuO16PUJkeGh/M1K8sgVutHbRaONyJ2TqysVmgoFmEG8vJJNryZfMl0FL2b1tukVHiT1cKkcD/jnjFtJ0Xgx2CJdnlHhtPbz5u5AbXzMmP3mc9Rp3OQmZ5UYfkUS9/A0a/pl6JPUyFgvJu0EFzynQjdHvhcvJNSCJTeSKfq4Bqm+fObja2kGQ9Rvb2jVwgPkrmUxMIZoaG94L+4ygVamxcWID2bCYEZxI5NQ= X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2504; 31:w67wfckbBsSzTrllvDmnz8r5ujbA/jvCbygQZm3mz1PSgliapmevN42SfKNEZzmXlIajBOcXdnLykZkMZsoZLeZA/gET6h7bJH3OcM7hiqS2N+qlZNgtBjdMgxJQUCzCmUy2kcf4vn6wGZ+tg5vENrRf/qrDKJY3918eF95ypO1NsZ/k9k3fCAcyLlami/s+EnEEoYiuJqUH91hffUhd/KDvShGFazkHDb0wpiXZlu1WyYot74gZR96UkUgmGgchkBrIrMZTzHmxvqeIdPMctGbUiwKBdgyG6k/i1/PZ1CI=; 20:6Ji034vLUR0IjFF4lVoSmDbH1Kx/CRbDz6QK9nMWOkx4ZMf11SBtgyEWChPAOgL/9rjmg5k764p4i7MgfWX1xe+HHfHiUmnTQvSj/rqX7kvM+4960OXTtBTMrW05RY7X4DwROeZr5jGoykJlHXiS7ppOTu+DRsv94VPCnwoGNJgZiYuHt7PBheh8z4J9XZNwg/ONAPdSdu+LWG7DrBYU7qhqgmZva1fGEJe2dElgRWFxYSUVXdM6OjB8vKKVoE5tmg3DzVJqQKxl9IjzPDNaj/58kHeODHjQL8K5MQ4luXqzc4FsTaMNGVPXvHUyRE9F0pBaDZ400RxzI5ITqmCN68v+cM6w9zDe87c5F2NLDZKOy4dp6nnoKKkkL5s5y6jaiwXOSMOW/HByvNoPdRzOuRs0hgoxRy0M7sfw2KaslcwNs+GJDtrsT2h6sZO3nhqc8AZKalFQKnKXHr0RRpwlhYlfOb9xk9SSFx7gjxwuUBkwhXlsVmGpfkS15FKwcAhX X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(20161123558025)(6072148); SRVR:CO2PR05MB2504; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB2504; X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2504; 4:ro3q6ea995Brl2cDKAr55maX8O/wb1D5n9PG0Uyw7JxfiUg+PqKyMkZv9812hlJTXM1L0fdFY/qfgv7HGZK/Tma5ejG8D84DCbOXAt/WiVHlSRXWVbUleO7TUBTugES6BdmqbDUdRrFTpbr46S9nIjAmzdE+mPx1nj2kMnKxKJx3rD1F9bwyuQXm5LD39P6aESJ824xnvcr9H/vEySz6S1UKQC9qNV2HRK7cIEqRFca6z0ul2PgXvWM2SqENexf6BPP99fs0PhSCsPibY+wDZhKp0PG1vL+7+Zi189KReycAlk2yQYNPMaEOfps1t+r5Gaf6b+pGjfZMwRNC3MbYPMRZ2bc5YqAm18jXEGNXBZv4cfC0Ll98TKaXx4kMrRhLsf8G7rhlo2cgxTFsVCp0Pz3yGcrJg5u22d70RihLLicE1HpKrketC8dyVJE2Xr3/ND7DUGZZZLdEthNE0/R7QdXBUFg24vKqy2MiACFEIzBx3AxbWZGn+iltCoKpLGSvopB60bYqmHCrb3eiIUzyulEJD0+16KOEF50EURvz5BxBt2Pxv7JV6smK3wQSfS8ibO0ET9Cv6+VzQQ3rl2gAhiWGEBp0Iw5w6clhJGKXOT889MqUM6u8jnNc6kWF5bZA X-Forefront-PRVS: 0205EDCD76 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(39860400002)(39850400002)(39840400002)(39450400003)(39410400002)(189002)(377454003)(24454002)(199003)(5423002)(77096006)(6666003)(15650500001)(2950100002)(189998001)(83716003)(54906002)(6306002)(25786008)(36756003)(33656002)(66066001)(38730400001)(90366009)(82746002)(229853002)(8746002)(86362001)(6486002)(50466002)(6916009)(68736007)(101416001)(305945005)(230783001)(50986999)(23746002)(42186005)(81166006)(2906002)(92566002)(4326007)(106356001)(57306001)(97736004)(5660300001)(76176999)(50226002)(47776003)(8676002)(6116002)(105586002)(7736002)(110136003)(81156014)(3846002)(53936002)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2504; H:[172.29.99.117]; 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: =?Windows-1252?Q?1; CO2PR05MB2504; 23:pMAGxAmLUvztzQxReU/JbGkWcbkAjlqgyYx5d?= =?Windows-1252?Q?dxPdaLhWYd4KYWg1h5i0yiyAuM33Gpwbof8l7mPotaBTlfkiLS1COu7/?= =?Windows-1252?Q?y4gmHV/ypHTsoIKfK9sZLU7Z5LhEzky+bRbFSEDeCE9h4KC29PYk/Eyt?= =?Windows-1252?Q?SzvSsD6KYcmi/QWZJtwuc5CxTZ72ix9aB0K435HQZvpbqGAngFF77zZc?= =?Windows-1252?Q?8Qsmoxp+8ctFNzZPmCMnumqj7p8Ig79WI0+P69ylo+PxrU01eU6FbR8b?= =?Windows-1252?Q?JJTYqhYUsiZAX8v6RSXWm2nbleUPvEqoSwnk4zaXnTVeRtJ6P6a6Leui?= =?Windows-1252?Q?l1nstiMicx+8iwlMtro+0rLQNAI1mUpn5ac+MvzBu7DQeCmS49iV6Yho?= =?Windows-1252?Q?DYQCTvPZeBHxncnbbAKjMMdGihC4RNvhdieAnUJaIAKlixJ77g1Dv9xH?= =?Windows-1252?Q?MAUfI8zsMHNqtXO5Jj2xo97aZ75ckwyHcvNVx5BRhx9lEbTi7gsCLCii?= =?Windows-1252?Q?htjNnJ1Dp0DRn4aFPOuN9sMfIP9iEzcE7eQe2OVO3Fv39dpdlpErWuyp?= =?Windows-1252?Q?1Q9OnHIbEgwABBpUgULBM3hAwIHbUShBfKSQu9qdMgS89pr/Qjqn8JuH?= =?Windows-1252?Q?ca69SjJyDcYyQegK96ijxVYnKXqiCs+bwYcJYSHpLmiZ6JBDKr9Y5TlU?= =?Windows-1252?Q?jRbKLfRaOlKeJvIadNzI+TfmHF0GEHF/k4vLGz1srz4Hv5cG4/bAp1VM?= =?Windows-1252?Q?NmUenbP9WqYDMYSHpEMZOBZXi3lnhcl/cAOI79AcXCp+HJfcLl518eLh?= =?Windows-1252?Q?znD8RHhFyFnU/iSHgheKquL6jO931YgDdEdwqf2+Q5VTeUviaQsRxVh1?= =?Windows-1252?Q?NOjLyMDMD9iZWXgd4LqcXSOXmR5ZFa2/orhdeYSyVhC9gKCutZtnZacc?= =?Windows-1252?Q?GEzW/TY/i/hYiRyFE2bH8DhqkDMZ+3ANaNtEihmO7M8aoLH2WbY0K6gG?= =?Windows-1252?Q?tIJMSg6dx0GMNY6ESDZDNxFEjsXS9s1EzuZRup4MrfxpKTD1SinG3efX?= =?Windows-1252?Q?3oLDCCBteJa/R0Xtay8F2Gs0xGFrw9ouKpa/pv5VolE7iIlvnzURU3ib?= =?Windows-1252?Q?ODwrT6nDSjUjFgfr8O7tMTGVgFRH2+uYLDTtyNBooyAFIUn8Gke7y6G7?= =?Windows-1252?Q?ENOk4N7EFD7is01mD2iD6dN1/RUK7cPsQflfSsrYpCGbS/TCQfGXe5Fe?= =?Windows-1252?Q?/T/YRw5Y7JI9FrHq6O5e/6sOjlNSYgXUVHA+QIZ7tlWkaeKqm7MjaqUq?= =?Windows-1252?Q?UNB5+7jib6PA5gAIMMDkn9TdVO/FWDKhuCqajM4IcYlLTZ+3Q4cMuHEy?= =?Windows-1252?Q?FVYURy8CmhVmmX/vKXI8jxSvuxdVEA9xETnqxkhx1MreKko2VuGcfMJW?= =?Windows-1252?Q?Ov2i0UYERJcSj3M89g+/uPImg1f4o1EP8M9AHAz7tLFHfK4FL5rp1ajw?= =?Windows-1252?Q?pknZ/sbAbAndM0fp+R/rwf7wA5p6G+5NL4uRevyijDs1hk6dYTPU+XH1?= =?Windows-1252?Q?4h89kETECA168RXIGxeqKt2pXg2QKgQIB/A3+ncC1Pt2XXBlM4DkSUBb?= =?Windows-1252?Q?s5OXVgUQ5M+Gz3KFjtkb2o=3D?= X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2504; 6:N3TKvDUxI0ehpqAxDypFfCVdhZelluekq2n/S3H6ika9qKDhXw/U75xK8fomLeCDyOAm2tLFnaVgqJe3KfLWIkfLiat7zpMHSQTFlKZDayJ7VsnUclLPDu5IrhTK1F95vgH9BiDJ9McMbi7sv71l1Tiz3+xQQHD0S5bHEXNJ1SISHvvRCPi7KldSuHGdtms7DJj1aEFGJBhe5QWmh/PovQld2vCzS73AoYw9XJuL/euc8iQNybWNas5vOphd2KiIKvu0EleeJEWLGh6Kok1CRj2T3eRPpi18O1LXIgRhuZ4QIU7PwdeBhxWkRYu3CIOq4efKjrJ5J2UkhyUy42rH/U4ZGwf1Qse4VrzDPvzWq+q80JqTRhxa7nb9gINpehL3I/z38qBdHlx+jf8j/p6xwFpbBjKwkeHsPsYF5ffO4/fcuXB+p4lQbD1zTcfeVJVV; 5:Y2zGyfOMK084bkDNpnZHeYRIlwSGrF2nAtgyyrK4CwlZM14KEw6m2DOt3+Bb7pn7JJ+QcAIJukrUF6zfPkloIZS/d+hskKzsV0iMr5kV1earww1IJYPdVM+IXz96+Tp3pjfMpRMJc7YGpSlkwz6i7A==; 24:Sp5tEz0iVlZR+CJo0tjAig0RvrmscgJUp1q4AmAk5JbViJOaOJ933FxQ9r0V3xpSXsiwCWh8ZRS0uokbolSij19tLU3Ec1g5xpYXxX2mJFQ= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2504; 7:anga2DYnECEl2Zeud4J2Pq6wDyIRhCBU85xnB9KnsN9/CXWkuKM4uU49sqMbD6WpH8RMgirn5Tz8M4ZCLQazr3hX/vqTSsT2j6iFed+SrSESUXmKuw0yUZy2LeM9oQdEUCPzt8Nb6tW9rXSFbPq8Lic/eEN7qYTCshiO0wAWExnhbtzIDLxlBd7mhEqIqTaoDOzfPHLc5mHXVf9bYZRBlS0XIuRF1mt3sZKksi9+cTiqOOXcGbPSYKAcpiUZrU/e6d4C4aJiw/+uWJTrZhrnTtJNXBx7dKUIG/8BUOUvZZyvXX8SzsTxwA4O5syj4xUbFIqC6uggSnroneje2YMEjcng3Z7V9XFU8zQtT7N8KdndI6QS4lOyS8EWBjd0ciyJwrsUw0PeYJVTIAYHTyc7ii02Uf1voaJ4kJuH0ExJwVNFEwUSSOF1hhXJbexAQ0eThHiM1nXxkcjTN7LbXo5ps02mGF00hxsttE3uI1POK0C/V+1gh6kYGM+b/r+dloAqAngc9W66K5J0GtdHvIwX4ImC0kiuH/e6hBZSyHeyqsXF/Z7mUe+Yzcy+8Vwnh0Yg X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Feb 2017 18:07:10.6083 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2504 Archived-At: Cc: idr@ietf.org, Susan Hares Subject: Re: [Idr] Implementation call for draft-ietf-idr-bgp-extended-messages (1/24/2017 to 1/31/2017) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 18:07:15 -0000 On Jan 27, 2017, at 4:38 AM, Robert Varga wrote: >=20 > On 01/24/2017 08:22 PM, Susan Hares wrote: >> The document draft-ietf-idr-bgp-extended-messages has past WG LC, but = it >> is awaiting implementations. Do you know of any implementations =96 >> partial or full? If so, please respond with an note to this email or >> send the chairs a note privately. >=20 > Hello, >=20 > OpenDaylight implements this draft since its Boron release. Cool. It would be great if you or someone else with knowledge of the = implementation could fill in the relevant wiki page = (https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implement= ations) although if there are any problems with doing that, don't let = that hold you back =97 just put similar info into an email. Thanks, =97John= From nobody Thu Feb 2 08:52:55 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 651C9129487; Thu, 2 Feb 2017 08:52:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148605437441.13892.13980838157861725188.idtracker@ietfa.amsl.com> Date: Thu, 02 Feb 2017 08:52:54 -0800 Archived-At: Cc: idr-chairs@ietf.org, idr@ietf.org Subject: [Idr] idr - New Meeting Session Request for IETF 98 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 16:52:54 -0000 A new meeting session request has just been submitted by Susan Hares, a Chair of the idr working group. --------------------------------------------------------- Working Group Name: Inter-Domain Routing Area Name: Routing Area Session Requester: Susan Hares Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: i2rs i2nsf trill spring netmod netconf rtgwg Second Priority: bess sidrops Third Priority: detnet dots nfvrg mpls People who must be present: Susan Hares John Scudder Alvaro Retana Resources Requested: Special Requests: --------------------------------------------------------- From nobody Thu Feb 2 10:33: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 49F581298C1 for ; Thu, 2 Feb 2017 10:33:38 -0800 (PST) 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 CwN9p6cyrDoX for ; Thu, 2 Feb 2017 10:33:36 -0800 (PST) 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 AF916129509 for ; Thu, 2 Feb 2017 10:33:36 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.162.137; From: "Susan Hares" To: "'John G. Scudder'" , "'idr wg'" References: <36E285C0-C716-437A-806D-A453273146DD@juniper.net> <1D651738-BCED-4F25-88B5-5257871697DA@juniper.net> In-Reply-To: <1D651738-BCED-4F25-88B5-5257871697DA@juniper.net> Date: Thu, 2 Feb 2017 13:29:19 -0500 Message-ID: <01a401d27d82$44f25b80$ced71280$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIgMsv1YXbB2Jqp0eajZl6T0Qh3WQII4s4woKpXndA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] WG adoption call for draft-hr-idr-rfc5575bis-02 "Dissemination of Flow Specification Rules" X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 18:33:38 -0000 =20 =20 I support adoption of this work as a co-author. =20 Sue Hares=20 -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G. Scudder Sent: Wednesday, February 1, 2017 11:42 AM To: idr wg Subject: Re: [Idr] WG adoption call for draft-hr-idr-rfc5575bis-02 = "Dissemination of Flow Specification Rules" Hi All, Reminder, this call for adoption is going on and will end in five days. = So far, the only reply has been from Christoph (thanks!) with a pointer = to his paper "BGP Flow Specification Multi Vendor and Inter AS = Interoperability". The paper is long, but I encourage you to look at it. = To encourage you, here are a few excerpts from the conclusion: "we think that what we listed as bugs sometimes is a result of unclear = sections and definitions in RFC 5575" "With this update we think that a proper interoperable implementation = should be possible and unambiguous sections have been improved" and perhaps most motivational to the WG: "Given the current bugs, interoperability issues and missing features we = do not recommend flow specification BGP sessions between different = carriers [=E2=80=A6] Invalid flow specification NLRIs or action filters = have the potential to remotely trigger a complete network failure." If you do NOT support adopting this work, it would be interesting to = hear why. For example, do you think RFC 5575 is fine as it is, and if = so, why (considering the issues raised in the paper and on the list). Of = course, it is not IDR's job to document and fix implementation bugs. But = it is *exactly* our job to fix the spec if it's ambiguous and that = ambiguity leads to interoperability issues. If you do support adopting the work, please remember to say so on the = list =E2=80=94 we can't declare consensus based on silence. Thanks, =E2=80=94John > On Jan 21, 2017, at 10:03 AM, John G. Scudder wrote: >=20 > Hi All, >=20 > The authors have requested IDR working group adoption of = draft-hr-idr-rfc5575bis-02 "Dissemination of Flow Specification Rules". = Please send your comments to the list. >=20 > This adoption call will conclude on Monday, February 6. >=20 > Thanks, >=20 > =E2=80=94John > _______________________________________________ > 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 From nobody Thu Feb 2 11:49: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 741F3129982 for ; Thu, 2 Feb 2017 11:49:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.058 X-Spam-Level: X-Spam-Status: No, score=-3.058 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_H2=-1.156, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZuDpNgy1a2E for ; Thu, 2 Feb 2017 11:49:36 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0098.outbound.protection.outlook.com [104.47.33.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 41D921294E3 for ; Thu, 2 Feb 2017 11:49:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GdERnJC7SRNvVs8Ep0O6ntQ6QUUkfe3vLFl7/D2Fvt0=; b=NR0TVWNxzJB4I710iQZfzBf9Bw5/rIuGkzOv6Yk4paNHKRdQ1V+kgAV/KmJ8TNZpDqijv5rXX2E9ONY5BP/NlFUgxOQgpPvS9W/wq3ndq8pvVYywFwa2jC2O/xA26Xv2VHLeJqb0VuTyTRBGYMxiHBti/aGyh54a32lzkFZILgM= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from mscherbring-sslvpn-nc.jnpr.net (66.129.241.11) by CY1PR05MB2505.namprd05.prod.outlook.com (10.167.10.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.5; Thu, 2 Feb 2017 19:49:34 +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: <36E285C0-C716-437A-806D-A453273146DD@juniper.net> Date: Thu, 2 Feb 2017 14:49:29 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <4ADCDBDD-934C-4EE6-8069-CB8A60B39A66@juniper.net> References: <36E285C0-C716-437A-806D-A453273146DD@juniper.net> To: X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: BN6PR12CA0002.namprd12.prod.outlook.com (10.168.222.12) To CY1PR05MB2505.namprd05.prod.outlook.com (10.167.10.26) X-MS-Office365-Filtering-Correlation-Id: 3fc679c3-7bd8-455d-a162-08d44ba49d26 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR05MB2505; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2505; 3:35Bzak1JHvZZjL0Fgttz8muBtqi4Bzi5r4MDxbktEcZmfqB9rsaKTPpDUGyvd7ZnvqRX+ZsxnlG0heE09ZckrEOrfEDTfll6r5YmqVwh2E10yRnF4+5Jt2zOETVPb8i2Tu57h9lccxoRfzKQmv9FIIrTCy8OaIhmIq4U7DrJtaoy+Lwj9Jb9ZnKQOgM0F4BFEktIntm1UQBUGfhmdShH9IbV8/b25cm5wS0pVdaRDdw/8Z+qlA9wL6Aeycvf2i+NC4GOSUS8gkCmmzVl9hsIOCp3drbR/6djTzC2KU1R7UA=; 25:kDSfZtM0iHyAVfuRwqJHY+CXcohKiIO/+Hrm1f2Ll6fHF55junnwnoJ6w5wizNHN1p+19nKYe/GmXKSje5vJ4CLIhXH6uc/OfUin8Sl6LHSn1VyZ9SdQK9i48s63/YxTJy6sd0yH10/TkNd0yfaGrdi58NVxwcKmxE4+79Zs8oBb6Hy4Xo12EBQEUGovMCQdAx+NvYO2KUkf9QA9unynLbElEFRC/SZjhFBFgvhLRkE20sVLtO/KYnoCAJvEEJ3uxdI/A3o4DpOX//MiagDJiBml5hIs5ajmNVfyg+TNm95LXfh7Grq2d7aQ9PKOWM4U87XNTMpSRpnEFyi/6pOQF1YpGfah9dyunipMY/07rP+ZDkz9sG2ttHTeFullY8qdgdvuQ1TzpWMCkPX+Zl2Z7Kzh/yomW7a3yAeugQjTDEq01UWS2ag4nzeYLGYp0I12 X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2505; 31:BEhSojodmAo94xO8EP2S9WPGOI37PItZjjOLf84JqoaS+pmq1VgTGIT+wgEa5bgUUXsj4c05BlE1xHclMDjaCg4Wvv2MKmfqkzHAzAe4XheGy5/EenkW+X4K3SpYIGeNcuI1RhciB8aaRj9l5za294oXba8AKeghq48Eur/1IIZrczP5WVN6SMuhCSnP+smp0GVph6TAi8qvDcKK3QgYUDsGIuzUc6kQOMlCCaRAlHsgKU+zrP0Fi+X4Re0bPnetiUw5tVfwa/ULBpdpD9glgA==; 20:m6QjXbSKYvjvEkjJVs5BYD06G1GLjqOUJSETvV8/4oKCKwv4sMk+AaQsWJA+fvAzkEaDqVT8SYQQ06gXzKQ0wjimb8PG3fzj/qgA/xu8QFca+Nn0eHrWkbcy+xu8leo/J0kVw9XuOFvsB0Lwx3sANRn0iLp3DapRTEYUh86DPzPY2jXfHbIugHHLeEbGnPC8V3dwnR/wnQDeedpxKqDyC5m1GQmcmvZjLp42XVUqbZFmHzP4IkPID/QugmrZPJl0ITQKUT1hxcWhxLKW7OwBHcxC4DKjVeuuAW1u6hJ6vvdFn8yl0BdnK6fG6CmvRtcVxAovdC4LG8NcH+9FTs61mRl7F3BF2UzZhSzL7P/f7ZQcGL9qE89fdDf4ftPZMywaVFoEfOVJRnANn9gBdV9wv3QIIqWb4EFndmC6WSMcAxZXn2LIZ/Tx4p7qaznn1Pfa8pHb5+vleOnIe57/LTsx/UPKacpBpIy22RpZhmWAHi9+58na5Jb/MU1OIqWVZKEHen0/r/oft4PFCDP0mdAtaGEeOC1UhHzqKxd4KPdVgjIdUVqtvsdVb43YS/PJ+Nnr/zahGa81lwV1JH041yXOQEfLOYJ5aRGURtTdB6QCIh8= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123562025)(20161123558025)(20161123564025)(20161123555025)(6072148); SRVR:CY1PR05MB2505; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2505; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2505; 4:USu3aLr/hT4k51fI6/HuONibEXLYCWSJbyo1SKvqwJXE2VusQ1whIQ9cXdjufFqeCqljjtY0QTJwKoHomBDsxT/t+ZW7lHUdlIPG1o01vOuViTivbiRSfk35XQVP1XH1tMgCMCCOF/GZ3cBK9Yh4ymoAB6Z0QdjMA4hxvaVMvoCDFGLthQl/bW0AwnM8LxhQnTGQiD7H87JulqAPIEVdtU3JTjz9QzV3Vxp8sVvEkqBFCO0SmlZAhY8BCN6x+y87nVFXDZGvmlSMbRi1bd6Qsvob93OfI2N6kN4dYvL0plvKf6KsKf7SI/PFQUtd+6RmqmkSNGH7AattcNHEAnIx53/PbmZ4MCh1k05Qn4lS7OM/ds1QedeIpc5TRkd5iqm2hFpbiGIkau0fNyzRQCzVYHho62XF6rzi0L2MC5yOLJwRBnoXs/PPJiqPrWt2gCZpIWPbT1foehkddKqmoG6Y6jpOiG0v9hKWR+KbrTfT8rC97Qd8duzCGkjstzbC2rWwKGsCfq7zW3LuRFrIJ/wf+OE7kUJP1CrCkfhsy4iWuWuKggrcKJ2tCCiUZUzjDHHL4F8snk4LBzfV/KydvVR7IgL9nriNtUL7fPXrLHc9zfydVn1Xmw1RbY547gIS1soY5YnYLIPAbGbB1cUYBrU+85agEAlxTfck/S+4p2CGa1c= X-Forefront-PRVS: 02065A9E77 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(39850400002)(39410400002)(39860400002)(39840400002)(39450400003)(24454002)(377454003)(53754006)(189002)(199003)(7736002)(53416004)(25786008)(82746002)(50466002)(6916009)(305945005)(53936002)(68736007)(2950100002)(50226002)(66066001)(47776003)(23676002)(69596002)(2906002)(8746002)(81166006)(110136003)(81156014)(8676002)(450100001)(92566002)(83716003)(5660300001)(6666003)(36756003)(33656002)(6506006)(6512007)(6306002)(42186005)(2351001)(229853002)(6486002)(38730400001)(101416001)(107886002)(105586002)(189998001)(76176999)(230783001)(97736004)(57306001)(86362001)(6116002)(50986999)(106356001)(3846002)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2505; H:mscherbring-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: =?utf-8?B?MTtDWTFQUjA1TUIyNTA1OzIzOjc1RFN5MzdyU0tnUjQ3UHArbFpWbmZIYVBt?= =?utf-8?B?NVZ5MzRiRWNkMmd2Z0VFSE84dGU5MFB6RFdSVEpUZmFzVk9LOW1XaUZhRjFJ?= =?utf-8?B?YUhMc2tjUTBqRHV6MHBJSW15NUd6cWVmdjBZQ3FzSGxSc2RZeFdFNVNqeVox?= =?utf-8?B?Z3hsb2RkREdydFAxM0tUNkFnUHZIc3JzTG00OVVkMUVESWRoT0J2elJ4Nm9Y?= =?utf-8?B?bXhZVzh0MGw1WHQ0OUJDMkNPRHJrYkJ1N1AwN1YrQjJjRnpnTmNTY04zS3ow?= =?utf-8?B?Qm5OUXlXRWtDTEMwQnF3N2hwNnp3L3lZQTJKcHI3VERlUS9NclduUUVCN09x?= =?utf-8?B?Ykx4aDVaUDVpYVViZGxnTGdLajZ2c29CWmZyZWY4T3hVZXl5ajZHL2NLMWM0?= =?utf-8?B?a3lFYVFCMW84aitDZGZFSjJuaW1YYmhVM0JrYU5wUU55cXB2bUNiN29sWGEz?= =?utf-8?B?VWhGRnE5SmtnTEhobkd5Vk5qT1E4dEI5aWQwcndWUWhJeXplY1JFMmNRdXBN?= =?utf-8?B?WGl4K0tQSTRZRFJKRVl1WWJIUWY1NmpTSzhFMXZ3a21Yb0ptR09qWWxCUy9D?= =?utf-8?B?bWUyK3lTdmpiQzhucWFXSUIzTmE1Uy9OakpjdzgzMUo4TStrdFBuL1l0TWZw?= =?utf-8?B?bFdScmh2VW9abmlzQ2cyd3hQajJKWGJKQVJmeDljUjRuWXRSNnV4YVAwUjN3?= =?utf-8?B?cjdNMS92MHpqZHpSVURGd3lIQzhlQnFvTzVqWGFiUi9ESVRwSjZKUFRObmZU?= =?utf-8?B?QXYrN2FpdERXeDQ3aWU3UFpOQU10cmtPSC90cENPcHArUE93SjFuNW14ZFIv?= =?utf-8?B?TDBCTzNYWjBjSG5QNnFnUkpiRWZaeEE1TFhaUXJ4cDd0YWRBRXgrRkI5UkhP?= =?utf-8?B?YjZCQTZGZnVWRTRxUFp5YjNoclY2ZzBpZ2VJeU50elNUb0sxWlB5UjZrWmpx?= =?utf-8?B?ZFBDZXVKU2J4OGJFOWgwNHRrenkyMFAzZ2lQeXZxNDJwVkRraEhndlJlT1F1?= =?utf-8?B?ei9nUndPNFByOGNaZkQwUzVUUjhBVzJ0NEFEaWNDc1l3K0huNUM3cHFvTlNE?= =?utf-8?B?REo0dnlkeEQ3QXBnaHRacGtPVmJwRjhleUZBZWVJN1BXL1phTXR2NVp6TUxU?= =?utf-8?B?dkpDTTVxTURPZ0MzY3poTngrYjhuTGVDUFo3QUo4NVhjUU44YlJVc1hDQVV6?= =?utf-8?B?djR0QUxGQXpPMHpweUIzTzVDOXpmdmUxMURaRTVXbHF2dGV3K0pIYVBjeHd0?= =?utf-8?B?dVVYdlRxRTArODhVL3ZqdUczZnJ0ZnNSNDU2dldpU2xzQ0kvazBpMitqdkt4?= =?utf-8?B?UFh3eHZ3Y0dVMXhWWkFiREZ3azNUVjhVQlBPOERrWkRFWWNJSHRRMzNHMmlF?= =?utf-8?B?SmNaVGhXSVIyVW1neW5xMXl4Yldra1gwYmIzMWoySURnTGd3VDArTVNzRjgz?= =?utf-8?B?eC9WN09WZGRKejIvNnNuSFpUd0VUekF6djMzcHl4OUVOdVhiZEtCKzRRR2FV?= =?utf-8?B?azVjMEdkSFlVaXo0bHhHdHB5dDVJZjUybmhJT1ZuTkdrOFhRbGpZelZjbm5S?= =?utf-8?B?TVFUcHR2Y1lBWHVmcmxDeWJkSmp1QVc3MEhTV0w5OS9rek9RSTV2SEFxN1BR?= =?utf-8?B?cXh4SnlnUFU4U1Q4RlpHUFRZMU4yU0dETmZ6eWkzdnNzUVk1OWc4ek1VYmY2?= =?utf-8?B?cFZ2V1FRcXdtekNNMDBwV0hnZzdQY3k3QWxET1hvRHhUa1c5MDROZXd5Q0hI?= =?utf-8?B?eHB3MlkrcHd4U3F6LzNDRVVKSktySDZiODRGRytoSGRXNjFqY2pod2E5MTVn?= =?utf-8?B?NERpYjRldlF0aE1WU09jcEV0TnZFS0h3aXFrQ3dFdDcxcXBnTlBMUXRNWDli?= =?utf-8?B?ZzU2SXpPVjBJLzFMbUxLelZJWGsra2FPSW5oREk1bHQrL1I3YkszOUNSMEU4?= =?utf-8?B?RVNwU3lZQkIzV2p6VFY1TkQrZjFNY25kanIwWkdsK3l3ZXpWWFNkenlMM1VV?= =?utf-8?B?UldrZ1FGemY1Zk12Qklad25pbzU3cnQ0eVBuWFRYdkQ1RTBUa0doNGlGTFVo?= =?utf-8?Q?tIzjNm5UiYuXd5DZzRZaDRwZf?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2505; 6:feWDxZFTNNfrOlQgHKlCvh6sCc2bPd+3PwnObUZKqaVw0N43e1k7p9GdXOsUFfvr/EC+sa4J+0zgs+pkX70TeA5/YVRj9ojIELUEiYGfsiC+YDcuEciKHw6soRwDk0fDBewbqVTnCDpLs68A7jRDTwIdz5N2fq13SGnMctDl0qcpefk2Avh3H4npB8lvXXvSj4G5gaUgYFEcxFAYJGB+mAlQNi/BPA5vFux75ENF4SEbQek7xMBgqdjBLea541xHvVZXiCnw+oTLXFMI55dRiB74TEK8WnMjB4FkFISboNv0/xlTuBOfDQvC6iI/MgrU5miU0/8M0XhqRjdNAUgThOzZGwBH4h1uP5DenAIbnKG6JZ96UiubF3Y7XMbRzJQWF3vSXkbLPtTVlXEJ305AYSfRW7PJnVZvNNcRctmwmxs=; 5:oadiC7vOJSh00Mvxaifv51RH3A6Vo39ONsbUgWOdfLv2ZQODRTNQGIagus/yMC2dgE1S70q4WBRje35h0BbN1Lp9ZxlHvwqTEgQMxClRMh0Gf0YarvspcMcIhHlpRMzc5ODlaVRYbI6tiF5tHf+1Mg==; 24:BG/igTJuK13HvPs3ylIiyyBeVO6nw7JUqjMT+Ag3xde1T0SlJScXqr1cdxmqV3OsmSGWmNEV7whjqdtZsS9JRKjmz07y3W6q/vks/P1QgLU= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2505; 7:o6waAhIYUiksn14Htpx/gZHhAaB3aWEH9XsxvpCCEEmJ0B+6Vzc0PHi+Zv6qFXrCvRDuwCNy4ZSsBCw3mCQ0VZz/6Q4AXcS8HtBbJPfry481arUfHjiBbeJeyR5bEUv2LJwJWGvi85Cy/0DjMoijIlrdXF00ZG+S7qEE4roK2zx+lE/aGPGQqDwOWyVFWpgOXVMzg1GPMYtgzmPg/P/BAKmOMsWkihGUZGLujRo1XNHC5KOvAPK6qeMj2KwGQASD+pGLnXOawYwcJYXrNxW+ZxxtzluSwrn2hLzyVHjanX8LfZB6ljC/8nF6MPJfW6EXkk0w8Vpga0q8LkO1Bm3mpZbUWlv45ozt4WRfX+7mxOqqua+ZAQMbrj2FUzvUME9eB7q3oSgBaxNKX/tSuyvD7ibgbwx7Vh831xQoIQGfrMRAVQAUXn+sh8xmrpjLq0kZTzPtfJlj//sHauTJLBRxfXddU35loR+nWtd/6qYGDK7WbCsNhugpEz7rIbGvGhZK/ykhTr8tBajtJyHhhaxAEw== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Feb 2017 19:49:34.5783 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2505 Archived-At: Subject: Re: [Idr] WG adoption call for draft-hr-idr-rfc5575bis-02 "Dissemination of Flow Specification Rules" X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 19:49:38 -0000 Folks,=20 It was pointed out to me that due to Chinese New Year, a significant = number of WG members may not have had the opportunity to respond (I = don't know what everyone else's excuse is...). We will extend the = adoption call until February 13 unless there are objections. (If there = are objections feel free to unicast them to me, or send them to the = list, as you prefer.) Thanks, =E2=80=94John > On Jan 21, 2017, at 10:03 AM, John G. Scudder wrote: >=20 > Hi All, >=20 > The authors have requested IDR working group adoption of = draft-hr-idr-rfc5575bis-02 "Dissemination of Flow Specification Rules". = Please send your comments to the list. >=20 > This adoption call will conclude on Monday, February 6. >=20 > Thanks, >=20 > =E2=80=94John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Thu Feb 2 11:56: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 CC76C1294AE for ; Thu, 2 Feb 2017 11:56:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 eDBtprY6TTMI for ; Thu, 2 Feb 2017 11:56:25 -0800 (PST) Received: from shmail04.t-systems.at (shmail04.t-systems.at [212.31.86.92]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ED8D129474 for ; Thu, 2 Feb 2017 11:56:24 -0800 (PST) X-IronPort-RemoteIP: 213.162.65.68 X-IronPort-MID: 5104267 X-IronPort-Reputation: None X-IronPort-Listener: DefaultListener X-IronPort-SenderGroup: TMA_Relay X-IronPort-MailFlowPolicy: $RELAY X-HAT: Sender Group TMA_Relay, Policy $RELAY applied. X-ExtLoop1: 1 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EBAgAyjpNY/0RBotVHFhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBARQBAQEBAQEBAQEBAQcBAQEBAYJlQ1EQgQmDV4oIkguVNYINHwu?= =?us-ascii?q?FeAIagjw/GAEBAQEBAQEBAQEBAl8ogjMZDyYXEAEBAQEBAU8CPiwBAQEDAQEBG?= =?us-ascii?q?wYRKwgHEAsCASACAg8QBAMCAgIlCxQBEAEBBAESCIlhCQMKrC2CJYsqAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBARoFgQuFQYkFOBUVglougjEFlUWGEgYBgmqKPIRqgXEYh?= =?us-ascii?q?H+JcIgoil8fOTpVgQyERB0ZgUl0iQMBAQE?= X-IronPort-AV: E=Sophos;i="5.33,326,1477954800"; d="scan'208";a="5104267" X-Spam-Processed: mailint1.t-mobile.at, Thu, 02 Feb 2017 20:56:44 +0100 (not processed: spam filter heuristic analysis disabled) X-MDHelo: ATWIREHUBV0001.sv.ad.tmo X-MDArrival-Date: Thu, 02 Feb 2017 20:56:44 +0100 X-Return-Path: Martin.Bacher@t-mobile.at X-Envelope-From: Martin.Bacher@t-mobile.at From: "Bacher, Martin" To: "John G. Scudder" , idr wg Date: Thu, 2 Feb 2017 20:56:15 +0100 Thread-Topic: [Idr] WG adoption call for draft-hr-idr-rfc5575bis-02 "Dissemination of Flow Specification Rules" Thread-Index: AdJ8qik1kqtVr82MS2WR0YPHLJN5eAA4/nMw Message-ID: References: <36E285C0-C716-437A-806D-A453273146DD@juniper.net> <1D651738-BCED-4F25-88B5-5257871697DA@juniper.net> In-Reply-To: <1D651738-BCED-4F25-88B5-5257871697DA@juniper.net> Accept-Language: en-US, de-AT Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-AT Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TMADISCLAIMER: MAILINT1 Archived-At: Subject: Re: [Idr] WG adoption call for draft-hr-idr-rfc5575bis-02 "Dissemination of Flow Specification Rules" X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 19:56:28 -0000 SGksDQoNCkkgc3VwcG9ydCB0aGUgYWRvcHRpb24gb2YgdGhpcyBkcmFmdCBhcyBhbiBjby1hdXRo b3IuICANCg0KTWFydGluIEJhY2hlcg0KDQotLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0t LS0tDQpWb246IElkciBbbWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnXSBJbSBBdWZ0cmFnIHZv biBKb2huIEcuIFNjdWRkZXINCkdlc2VuZGV0OiBNaXR0d29jaCwgMDEuIEZlYnJ1YXIgMjAxNyAx Nzo0Mg0KQW46IGlkciB3ZyA8aWRyQGlldGYub3JnPg0KQmV0cmVmZjogUmU6IFtJZHJdIFdHIGFk b3B0aW9uIGNhbGwgZm9yIGRyYWZ0LWhyLWlkci1yZmM1NTc1YmlzLTAyICJEaXNzZW1pbmF0aW9u IG9mIEZsb3cgU3BlY2lmaWNhdGlvbiBSdWxlcyINCg0KSGkgQWxsLA0KDQpSZW1pbmRlciwgdGhp cyBjYWxsIGZvciBhZG9wdGlvbiBpcyBnb2luZyBvbiBhbmQgd2lsbCBlbmQgaW4gZml2ZSBkYXlz LiBTbyBmYXIsIHRoZSBvbmx5IHJlcGx5IGhhcyBiZWVuIGZyb20gQ2hyaXN0b3BoICh0aGFua3Mh KSB3aXRoIGEgcG9pbnRlciB0byBoaXMgcGFwZXIgIkJHUCBGbG93IFNwZWNpZmljYXRpb24gTXVs dGkgVmVuZG9yIGFuZCBJbnRlciBBUyBJbnRlcm9wZXJhYmlsaXR5Ii4gVGhlIHBhcGVyIGlzIGxv bmcsIGJ1dCBJIGVuY291cmFnZSB5b3UgdG8gbG9vayBhdCBpdC4gVG8gZW5jb3VyYWdlIHlvdSwg aGVyZSBhcmUgYSBmZXcgZXhjZXJwdHMgZnJvbSB0aGUgY29uY2x1c2lvbjoNCg0KIndlIHRoaW5r IHRoYXQgd2hhdCB3ZSBsaXN0ZWQgYXMgYnVncyBzb21ldGltZXMgaXMgYSByZXN1bHQgb2YgdW5j bGVhciBzZWN0aW9ucyBhbmQgZGVmaW5pdGlvbnMgaW4gUkZDIDU1NzUiDQoNCiJXaXRoIHRoaXMg dXBkYXRlIHdlIHRoaW5rIHRoYXQgYSBwcm9wZXIgaW50ZXJvcGVyYWJsZSBpbXBsZW1lbnRhdGlv biBzaG91bGQgYmUgcG9zc2libGUgYW5kIHVuYW1iaWd1b3VzIHNlY3Rpb25zIGhhdmUgYmVlbiBp bXByb3ZlZCINCg0KYW5kIHBlcmhhcHMgbW9zdCBtb3RpdmF0aW9uYWwgdG8gdGhlIFdHOg0KDQoi R2l2ZW4gdGhlIGN1cnJlbnQgYnVncywgaW50ZXJvcGVyYWJpbGl0eSBpc3N1ZXMgYW5kIG1pc3Np bmcgZmVhdHVyZXMgd2UgZG8gbm90IHJlY29tbWVuZCBmbG93IHNwZWNpZmljYXRpb24gQkdQIHNl c3Npb25zIGJldHdlZW4gZGlmZmVyZW50IGNhcnJpZXJzIFvigKZdIEludmFsaWQgZmxvdyBzcGVj aWZpY2F0aW9uIE5MUklzIG9yIGFjdGlvbiBmaWx0ZXJzIGhhdmUgdGhlIHBvdGVudGlhbCB0byBy ZW1vdGVseSB0cmlnZ2VyIGEgY29tcGxldGUgbmV0d29yayBmYWlsdXJlLiINCg0KSWYgeW91IGRv IE5PVCBzdXBwb3J0IGFkb3B0aW5nIHRoaXMgd29yaywgaXQgd291bGQgYmUgaW50ZXJlc3Rpbmcg dG8gaGVhciB3aHkuIEZvciBleGFtcGxlLCBkbyB5b3UgdGhpbmsgUkZDIDU1NzUgaXMgZmluZSBh cyBpdCBpcywgYW5kIGlmIHNvLCB3aHkgKGNvbnNpZGVyaW5nIHRoZSBpc3N1ZXMgcmFpc2VkIGlu IHRoZSBwYXBlciBhbmQgb24gdGhlIGxpc3QpLiBPZiBjb3Vyc2UsIGl0IGlzIG5vdCBJRFIncyBq b2IgdG8gZG9jdW1lbnQgYW5kIGZpeCBpbXBsZW1lbnRhdGlvbiBidWdzLiBCdXQgaXQgaXMgKmV4 YWN0bHkqIG91ciBqb2IgdG8gZml4IHRoZSBzcGVjIGlmIGl0J3MgYW1iaWd1b3VzIGFuZCB0aGF0 IGFtYmlndWl0eSBsZWFkcyB0byBpbnRlcm9wZXJhYmlsaXR5IGlzc3Vlcy4NCg0KSWYgeW91IGRv IHN1cHBvcnQgYWRvcHRpbmcgdGhlIHdvcmssIHBsZWFzZSByZW1lbWJlciB0byBzYXkgc28gb24g dGhlIGxpc3Qg4oCUIHdlIGNhbid0IGRlY2xhcmUgY29uc2Vuc3VzIGJhc2VkIG9uIHNpbGVuY2Uu DQoNClRoYW5rcywNCg0K4oCUSm9obg0KDQo+IE9uIEphbiAyMSwgMjAxNywgYXQgMTA6MDMgQU0s IEpvaG4gRy4gU2N1ZGRlciA8amdzQGp1bmlwZXIubmV0PiB3cm90ZToNCj4gDQo+IEhpIEFsbCwN Cj4gDQo+IFRoZSBhdXRob3JzIGhhdmUgcmVxdWVzdGVkIElEUiB3b3JraW5nIGdyb3VwIGFkb3B0 aW9uIG9mIGRyYWZ0LWhyLWlkci1yZmM1NTc1YmlzLTAyICJEaXNzZW1pbmF0aW9uIG9mIEZsb3cg U3BlY2lmaWNhdGlvbiBSdWxlcyIuIFBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIGxp c3QuDQo+IA0KPiBUaGlzIGFkb3B0aW9uIGNhbGwgd2lsbCBjb25jbHVkZSBvbiBNb25kYXksIEZl YnJ1YXJ5IDYuDQo+IA0KPiBUaGFua3MsDQo+IA0KPiDigJRKb2huDQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IElkciBtYWlsaW5nIGxpc3QNCj4g SWRyQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRy DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJZHIg bWFpbGluZyBsaXN0DQpJZHJAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaWRyDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTm90aWNl OiBUaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1h eSBiZSBwcml2aWxlZ2VkLg0KSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwg bm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHksIGRlc3Ryb3kgYWxsDQpjb3BpZXMgZnJvbSB5 b3VyIHN5c3RlbSBhbmQgZG8gbm90IGRpc2Nsb3NlIG9yIHVzZSB0aGUgaW5mb3JtYXRpb24gZm9y IGFueSBwdXJwb3NlLg0KRGllc2UgRS1NYWlsIGlua2x1c2l2ZSBhbGxlciBBbmhhZW5nZSBpc3Qg dmVydHJhdWxpY2ggdW5kIGtvZW5udGUgYmV2b3JyZWNodGlndGVtDQpTY2h1dHogdW50ZXJsaWVn ZW4uIFdlbm4gU2llIG5pY2h0IGRlciBiZWFic2ljaHRpZ3RlIEFkcmVzc2F0IHNpbmQsIGluZm9y bWllcmVuIFNpZQ0KYml0dGUgZGVuIEFic2VuZGVyIHVudmVyenVlZ2xpY2gsIGxvZXNjaGVuIFNp ZSBhbGxlIEtvcGllbiB2b24gSWhyZW0gU3lzdGVtIHVuZA0KdmVyb2VmZmVudGxpY2hlbiBTaWUg b2RlciBudXR6ZW4gU2llIGRpZSBJbmZvcm1hdGlvbiBrZWluZXNmYWxscywgZ2xlaWNoIHp1IHdl bGNoZW0gWndlY2suDQoNClRoaW5rIGJlZm9yZSB5b3UgcHJpbnQhDQoNClQtTW9iaWxlIEF1c3Ry aWEgR21iSA0KR2VzY2hhZWZ0c2Z1ZWhydW5nOiBEci4gQW5kcmVhcyBCaWVyd2lydGggKFZvcnNp dHplbmRlciksIEF1ZnNpY2h0c3JhdDogQnJhbmthIFNrYXJhbXVjYSAoVm9yc2l0emVuZGUpDQpG aXJtZW5idWNoOiBIYW5kZWxzZ2VyaWNodCBXaWVuLCBTaXR6IFdpZW4sIEZOIDE3MTExMmssIFVJ RCBBVFUgNDUwMTE3MDMsIERWUiAwODk4Mjk1DQpLb250bzogVW5pQ3JlZGl0IEJhbmsgQXVzdHJp YSBBRyBJQkFOOiBBVDkzIDEyMDAgMDUyOCA0NDA3IDIzMDEsIEJJQzogQktBVUFUV1cNCg0KVC1N b2JpbGUg4oCTIERhcyB2ZXJiaW5kZXQgdW5zLg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQp= From nobody Thu Feb 2 12:06: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 533F81299BD for ; Thu, 2 Feb 2017 12:06:22 -0800 (PST) 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 2eLFryH2pFsA for ; Thu, 2 Feb 2017 12:06:12 -0800 (PST) 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 CE8CE1299A9 for ; Thu, 2 Feb 2017 12:06:11 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=50.36.162.137; From: "Susan Hares" To: "'idr wg'" Date: Thu, 2 Feb 2017 15:01:53 -0500 Message-ID: <022b01d27d8f$338ba1f0$9aa2e5d0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdJ9jnMZ3CLjzDOERd6cEzkNxsDlNg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] Movement of draft-ietf-idr-operational-00.txt message to DEAD Status (2/1 to 2/15) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 20:06:22 -0000 On November 20th, 2016 Job ask the WG chairs to change the status of = draft-ietf-idr-operational-00.txt to DEAD. This begins a 2 week WG = action call for the action of moving draft-ietf-idr-operational-00.txt = to dead (2/1 to 2/15). In your comments, please indicate any benefits = or problems with moving this IDR draft to dead.=20 At IETF 97, John Scudder indicate that the chairs would be querying the = WG regarding Zombie drafts - that is drafts with no substantial action = for over 3 years. While draft-ietf-operational-message-00.txt fits the = Zombie status, this call to move the draft to dead is being handled = separately from other Zombie drafts. =20 If you have any questions about what it means to move an IDR draft to = "DEAD", you may either ask on the list or send the WG chairs a message. = Sue Hares=20 =20 -----Original Message----- From: John G. Scudder [mailto:jgs@juniper.net]=20 Sent: Tuesday, January 31, 2017 10:52 AM To: Hares Susan Subject: Fwd: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line = in the peer's syslog at shutdown Here's one more thing for us to think about: "I'd like to ask the chairs to move = 'draft-ietf-idr-operational-message-00' to 'Dead' status" (Near bottom of message). When he asked, IIRC I told him "we'll attend = to that in the new year". I suppose we should attend to it at some = point. =E2=80=94John > Begin forwarded message: >=20 > From: Job Snijders > Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line=20 > in the peer's syslog at shutdown > Date: November 20, 2016 at 5:09:15 AM EST > To: Robert Raszuk > Cc: idr@ietf.org, grow@ietf.org >=20 > On Sat, Nov 19, 2016 at 03:57:06PM +0100, Robert Raszuk wrote: >> I am not going to argue with few of you here who want free form text=20 >> and do not accept any suggestions. >=20 > No, we are just selective in which suggestions we accept. Suggestions=20 > falling short of the mark are countered and discarded. >=20 >> But if you can not parse few defined keywords in any free form text=20 >> to enable better automated interpretation of the message I think=20 >> there is more problems here. >=20 > This proposal aims to accomplish a simple thing, which is to enrich an = > event with additional contextual information and assist in triaging=20 > ("This is unexpected, is this a problem?" "Should we embark on a=20 > specific procedure?") in an operator-centric workflow. By keeping it=20 > free form, it allows enough space to experiment with structured=20 > inter-domain signaling, and if operators find this useful a dictionary = > of messages can be offered at a later date as an extension based on=20 > operational experience. >=20 > It is absolutely is not aiming to act as a generic inter-domain=20 > signaling protocol for operations orchestration. >=20 >> TLV within current NOTIFICATION MSG is an overkill so do not count of = >> new proposal from me on it. >=20 > Hence this is not TLV, this is LV, already explained here: > https://www.ietf.org/mail-archive/web/idr/current/msg17127.html >=20 >> Operational message solved that already. >=20 > Operational message expired in September 2012, and as such I do not=20 > consider it an active working group document anymore. >=20 > The Operational message does not provide a strong correlation between=20 > a Cease event and some type of additional meta-data. Same reason why=20 > 'advisory' and 'shutdown' do not preclude each other. >=20 > I'd like to ask the chairs to move = 'draft-ietf-idr-operational-message-00' to 'Dead' status. >=20 >> Btw how are you going to handle it in IX ? I assume RS peers will not = >> get any info if one of the parties they used to get routes from goes=20 >> down and sends free form msg to RS ? Routes will be get withdrawn and = >> that's it. >=20 > Correct. This is the expected behaviour. >=20 > Kind regards, >=20 > Job >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Fri Feb 3 12:16:03 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 CB8791298B9; Fri, 3 Feb 2017 12:15:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148615295782.4097.3036228818736815866.idtracker@ietfa.amsl.com> Date: Fri, 03 Feb 2017 12:15:57 -0800 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-custom-decision-08.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 20:15:58 -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 : BGP Custom Decision Process Authors : Alvaro Retana Russ White Filename : draft-ietf-idr-custom-decision-08.txt Pages : 11 Date : 2017-02-03 Abstract: The BGP specification describes a Decision Process for selecting the best route. This process uses a series of steps, made up of path attributes and other values, to first determine the Degree of Preference of a route and later as tie breakers. While existing mechanisms may achieve some of the same results described in this document, they can only do so through extensive configuration such as matching communities to explicit policy and/or route preference configurations present on each BGP speaker within their administrative domain (autonomous system). Implementing some specific fine grained policies through such mechanisms is cumbersome, if even possible. This document defines a new Extended Community, called the Cost Community, which may be used as part of the Decision Process. The end result is a local Custom Decision Process. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-custom-decision/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-custom-decision-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-custom-decision-08 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 Fri Feb 3 12:17: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 6D39F1298B2 for ; Fri, 3 Feb 2017 12:17:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.719 X-Spam-Level: X-Spam-Status: No, score=-17.719 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=-3.199, 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 syHeUeZr2X-5 for ; Fri, 3 Feb 2017 12:17:41 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34BC1129456 for ; Fri, 3 Feb 2017 12:17:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18870; q=dns/txt; s=iport; t=1486153061; x=1487362661; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6PkJh6eisDInNp0pOAChyVt/lNPpSWqHKXFjlux8B5Q=; b=ZNdL+Fsd3Nuc8XlOiAHJk/8sYMvCpcgWn3SvuS8Izk7pD6CepaQQbxmi W1u6U7fKEoJ9dTUJhPBso7JnwFo8Y1DhghXzyaN4c94h/UuELGtONgQBU n32KO0dDeIRPwBFLwNZrhjZK5hV09rBR/CcRvydMHD/JQpuddxIfvqoZt I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BpAQA05JRY/5NdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9kYYEJB4MLRooIkW2QL4Urgg0uhXQCGoJFPxgBAgEBAQEBAQF?= =?us-ascii?q?iHQuEagYMF1YQAgEGAj8DAgICMBQRAgQOBRSJXQ6QfJ1OgiUrixABAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEYBYZLggUIgmKDEIRDLoIxBZVKhhkBkgeBe4UXiXCIKIp?= =?us-ascii?q?hAR84gUsVTAGELYIDdYgVgQwBAQE?= X-IronPort-AV: E=Sophos;i="5.33,330,1477958400"; d="scan'208,217";a="381093730" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Feb 2017 20:16:39 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v13KGdph014043 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 3 Feb 2017 20:16:39 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 3 Feb 2017 14:16:39 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Fri, 3 Feb 2017 14:16:39 -0600 From: "Alvaro Retana (aretana)" To: "bruno.decraene@orange.com" Thread-Topic: [Idr] 2 week WG LC for draft-ietf-custom-decision (4/20 to 5/4/2015) Thread-Index: AQHQfOJEbzqBqbwli0WLinaFdrSzRp5/NkAAgCBzp+CAALACAIAAziXggrqjygA= Date: Fri, 3 Feb 2017 20:16:38 +0000 Message-ID: References: <015e01d07ba1$0042bff0$00c83fd0$@ndzh.com> <25797_1429696420_55376FA4_25797_3139_1_53C29892C857584299CBF5D05346208A0EBAA545@PEXCVZYM11.corporate.adroot.infra.ftgroup> <30646_1447691076_564A0344_30646_2291_1_53C29892C857584299CBF5D05346208A0F6BC240@OPEXCLILM21.corporate.adroot.infra.ftgroup> <9781_1447749309_564AE6BD_9781_1504_1_53C29892C857584299CBF5D05346208A0F6BD227@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <9781_1447749309_564AE6BD_9781_1504_1_53C29892C857584299CBF5D05346208A0F6BD227@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.3] Content-Type: multipart/alternative; boundary="_000_CFE790352FFA4B7A957480D46137E3DFciscocom_" MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" , Susan Hares Subject: Re: [Idr] 2 week WG LC for draft-ietf-custom-decision (4/20 to 5/4/2015) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 20:17:43 -0000 --_000_CFE790352FFA4B7A957480D46137E3DFciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QnJ1bm86DQoNCkhpIQ0KDQpXZSBqdXN0IHJlZnJlc2hlZCB0aGUgZHJhZnTigKZhbmQgKEkgdGhp bmspIGNsYXJpZmllZCB5b3VyIHBvaW50IGJlbG93IGluIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0 aW9uczoNCg0KU2VjdGlvbiA2LiwgcGFyYWdyYXBoIDI6DQpPTEQ6DQoNCiAgICBUbyBtaW5pbWl6 ZSB0aGUgcG90ZW50aWFsIG9mIGNyZWF0aW5nIHJvdXRpbmcgbG9vcHMgKFNlY3Rpb24gNSkgb3IN CiAgICBvdGhlcndpc2UgYWZmZWN0aW5nIHRoZSBEZWNpc2lvbiBQcm9jZXNzIGluIHVuaW50ZW5k ZWQgd2F5cywgdGhlDQogICAgcHJvcGFnYXRpb24gb2YgQ29zdCBDb21tdW5pdGllcyBNVVNUIGJl IGRpc2FibGVkIGJ5IGRlZmF1bHQgYW5kIE1VU1QNCiAgICBiZSBleHBsaWNpdGx5IGVuYWJsZWQg YnkgdGhlIG5ldHdvcmsgYWRtaW5pc3RyYXRvci4gIEZ1cnRoZXJtb3JlLCBhbGwNCiAgICB0cmFu c2l0aXZlIENvc3QgQ29tbXVuaXRpZXMgcmVjZWl2ZWQgYWNyb3NzIGFuIEF1dG9ub21vdXMgU3lz dGVtDQogICAgYm91bmRhcnkgd2l0aG91dCBleHBsaWNpdCBjb25maWd1cmF0aW9uIE1VU1QgYmUg c3RyaXBwZWQgb2ZmIHRoZSBCR1ANCiAgICB1cGRhdGUsIGFuZCBpZ25vcmVkIGR1cmluZyB0aGUg RGVjaXNpb24gUHJvY2Vzcy4NCg0KTkVXOg0KDQogICAgVG8gbWluaW1pemUgdGhlIHBvdGVudGlh bCBvZiBjcmVhdGluZyByb3V0aW5nIGxvb3BzIChTZWN0aW9uIDUpIG9yDQogICAgb3RoZXJ3aXNl IGFmZmVjdGluZyB0aGUgRGVjaXNpb24gUHJvY2VzcyBpbiB1bmludGVuZGVkIHdheXMsIHRoZQ0K ICAgIHByb3BhZ2F0aW9uIG9mIENvc3QgQ29tbXVuaXRpZXMgTVVTVCBiZSBkaXNhYmxlZCBieSBk ZWZhdWx0IGFuZCBNVVNUDQogICAgYmUgZXhwbGljaXRseSBlbmFibGVkIGJ5IHRoZSBuZXR3b3Jr IGFkbWluaXN0cmF0b3IuICBGdXJ0aGVybW9yZSwgYWxsDQogICAgQ29zdCBDb21tdW5pdGllcyBy ZWNlaXZlZCBhY3Jvc3MgYW4gQXV0b25vbW91cyBTeXN0ZW0gYm91bmRhcnkNCiAgICB3aXRob3V0 IGV4cGxpY2l0bHkgYmVpbmcgZW5hYmxlZCBNVVNUIGJlIHN0cmlwcGVkIG9mZiB0aGUgQkdQIHVw ZGF0ZSwNCiAgICBhbmQgaWdub3JlZCBkdXJpbmcgdGhlIERlY2lzaW9uIFByb2Nlc3MuDQoNCg0K VGhhdCBpcyBwcm9iYWJseSB0aGUgbWFpbiBwYXJ0LCBidXQgdGhlcmUgYXJlIG90aGVyIGNoYW5n ZXMgcmVzdWx0aW5nIGZyb20geW91ciBjb21tZW50cy4gIFBsZWFzZSB0YWtlIGEgbG9vayBhdCB0 aGUgY29tcGxldGUgZGlmZjogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwxPWRyYWZ0 LWlldGYtaWRyLWN1c3RvbS1kZWNpc2lvbi0wNyZ1cmwyPWRyYWZ0LWlldGYtaWRyLWN1c3RvbS1k ZWNpc2lvbi0wOA0KDQoNClRoYW5rcyENCg0KQWx2YXJvLg0KDQpPbiAxMS8xNy8xNSwgMzozNSBB TSwgImJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb208bWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5n ZS5jb20+IiA8YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTxtYWlsdG86YnJ1bm8uZGVjcmFlbmVA b3JhbmdlLmNvbT4+IHdyb3RlOg0KDQpNeSBjb25jZXJuIGlzIGZvciBhbiBBUyBub3QgdXNpbmcg dGhpcyBjb3N0IGNvbW11bml0eToNCmEpIGNvbXBsaWFudCByb3V0ZXJzIHdpbGwsIGJ5IGRlZmF1 bHQsIG1vZGlmeSByb3V0ZSBwcmVmZXJlbmNlIGJhc2VkIG9uIHRoZSBjb21tdW5pdHkNCmIpIG5v biBjb21wbGlhbnQgcm91dGVycyB3aWxsLCBieSBkZWZhdWx0LCBhY2NlcHQgdGhpcyBjb21tdW5p dHkgb3ZlciBlQkdQIHNlc3Npb25zLg0KDQphK2I6IHdlIGhhdmUgYW4gaXNzdWUgYXMgdW50cnVz dGVkIEFTIG1heSBpbmZsdWVuY2UgbXkgcm91dGluZyBwb2xpY3kgb3IgY3JlYXRlIGxvb3BzLg0K DQpXZSBhZ3JlZSB0aGF0IHdlIGNhbuKAmXQgZG8gYW55dGhpbmcgYWJvdXQg4oCcYuKAnS4NClNv IEkgYW0gYXNraW5nIHRvIGFkZHJlc3Mg4oCcYeKAnSBieSBoYXZpbmcgY29tcGxpYW50IHJvdXRl cnMgdG8gX25vdF8gY2hhbmdlIHJvdXRlIHByZWZlcmVuY2UgYnkgZGVmYXVsdC4gaS5lLiBNVVNU IGJlIGV4cGxpY2l0bHkgY29uZmlndXJlZCB0byBjaGFuZ2UgdGhlaXIgcm91dGUgcHJlZmVyZW5j ZSBiYXNlZCBvbiB0aGlzIGNvbW11bml0eS4NCg0K --_000_CFE790352FFA4B7A957480D46137E3DFciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <55EF4D3C47CF7045935089AAF9DDF181@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252 ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5ncmFtZQ0KCXttc28tc3R5bGUtbmFtZTpncmFtZTt9DQpzcGFu LnNwZWxsZQ0KCXttc28tc3R5bGUtbmFtZTpzcGVsbGU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCglj b2xvcjp3aW5kb3d0ZXh0Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1h bDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5 bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRl IiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+QnJ1bm86PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2Fs aWJyaSI+SGkhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+V2UganVzdCByZWZyZXNoZWQgdGhl IGRyYWZ04oCmYW5kIChJIHRoaW5rKSBjbGFyaWZpZWQgeW91ciBwb2ludCBiZWxvdyBpbiB0aGUg U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2Fs aWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+U2VjdGlv biA2LiwgcGFyYWdyYXBoIDI6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+ T0xEOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZuYnNwOyZuYnNwOyBUbyBtaW5p bWl6ZSB0aGUgcG90ZW50aWFsIG9mIGNyZWF0aW5nIHJvdXRpbmcgbG9vcHMgKFNlY3Rpb24gNSkg b3I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsmbmJz cDsgb3RoZXJ3aXNlIGFmZmVjdGluZyB0aGUgRGVjaXNpb24gUHJvY2VzcyBpbiB1bmludGVuZGVk IHdheXMsIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZu YnNwOyZuYnNwOyBwcm9wYWdhdGlvbiBvZiBDb3N0IENvbW11bml0aWVzIE1VU1QgYmUgZGlzYWJs ZWQgYnkgZGVmYXVsdCBhbmQgTVVTVDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGli cmkiPiZuYnNwOyZuYnNwOyZuYnNwOyBiZSBleHBsaWNpdGx5IGVuYWJsZWQgYnkgdGhlIG5ldHdv cmsgYWRtaW5pc3RyYXRvci4mbmJzcDsgRnVydGhlcm1vcmUsIGFsbDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZuYnNwOyZuYnNwOyB0cmFuc2l0aXZlIENvc3Qg Q29tbXVuaXRpZXMgcmVjZWl2ZWQgYWNyb3NzIGFuIEF1dG9ub21vdXMgU3lzdGVtPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJvdW5kYXJ5 IHdpdGhvdXQgZXhwbGljaXQgY29uZmlndXJhdGlvbiBNVVNUIGJlIHN0cmlwcGVkIG9mZiB0aGUg QkdQPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7Jm5i c3A7IHVwZGF0ZSwgYW5kIGlnbm9yZWQgZHVyaW5nIHRoZSBEZWNpc2lvbiBQcm9jZXNzLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkNhbGlicmkiPk5FVzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD YWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJz cDsmbmJzcDsmbmJzcDsgVG8gbWluaW1pemUgdGhlIHBvdGVudGlhbCBvZiBjcmVhdGluZyByb3V0 aW5nIGxvb3BzIChTZWN0aW9uIDUpIG9yPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2Fs aWJyaSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IG90aGVyd2lzZSBhZmZlY3RpbmcgdGhlIERlY2lzaW9u IFByb2Nlc3MgaW4gdW5pbnRlbmRlZCB3YXlzLCB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsmbmJzcDsgcHJvcGFnYXRpb24gb2YgQ29zdCBDb21t dW5pdGllcyBNVVNUIGJlIGRpc2FibGVkIGJ5IGRlZmF1bHQgYW5kIE1VU1Q8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsmbmJzcDsgYmUgZXhwbGljaXRs eSBlbmFibGVkIGJ5IHRoZSBuZXR3b3JrIGFkbWluaXN0cmF0b3IuJm5ic3A7IEZ1cnRoZXJtb3Jl LCBhbGw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsm bmJzcDsgQ29zdCBDb21tdW5pdGllcyByZWNlaXZlZCBhY3Jvc3MgYW4gQXV0b25vbW91cyBTeXN0 ZW0gYm91bmRhcnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsm bmJzcDsmbmJzcDsgd2l0aG91dCBleHBsaWNpdGx5IGJlaW5nIGVuYWJsZWQgTVVTVCBiZSBzdHJp cHBlZCBvZmYgdGhlIEJHUCB1cGRhdGUsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2Fs aWJyaSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFuZCBpZ25vcmVkIGR1cmluZyB0aGUgRGVjaXNpb24g UHJvY2Vzcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpDYWxpYnJpIj5UaGF0IGlzIHByb2JhYmx5IHRoZSBtYWluIHBhcnQsIGJ1 dCB0aGVyZSBhcmUgb3RoZXIgY2hhbmdlcyByZXN1bHRpbmcgZnJvbSB5b3VyIGNvbW1lbnRzLiZu YnNwOyBQbGVhc2UgdGFrZSBhIGxvb2sgYXQgdGhlIGNvbXBsZXRlIGRpZmY6DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDE9ZHJhZnQtaWV0Zi1pZHItY3VzdG9tLWRl Y2lzaW9uLTA3JmFtcDt1cmwyPWRyYWZ0LWlldGYtaWRyLWN1c3RvbS1kZWNpc2lvbi0wOCI+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDE9ZHJhZnQtaWV0Zi1pZHItY3VzdG9tLWRl Y2lzaW9uLTA3JmFtcDt1cmwyPWRyYWZ0LWlldGYtaWRyLWN1c3RvbS1kZWNpc2lvbi0wODwvYT4N CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OkNhbGlicmkiPlRoYW5rcyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxp YnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5BbHZhcm8u PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNCNUM0REYgNC41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDoz Ljc1cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIDExLzE3LzE1LCAzOjM1IEFNLCAmcXVvdDs8YSBocmVmPSJtYWlsdG86YnJ1bm8uZGVj cmFlbmVAb3JhbmdlLmNvbSI+YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTwvYT4mcXVvdDsgJmx0 OzxhIGhyZWY9Im1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tIj5icnVuby5kZWNyYWVu ZUBvcmFuZ2UuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6IG5vcm1h bDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6IzFGNDk3RCI+TXkgY29uY2Vy biBpcyBmb3IgYW4gQVMgbm90IHVzaW5nIHRoaXMgY29zdCBjb21tdW5pdHk6PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2si PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJmb250 LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRv d3M6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xv cjojMUY0OTdEIj5hKTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48c3BhbiBjbGFzcz0iZ3JhbWUiPmNvbXBsaWFudDwvc3Bhbj48c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+cm91dGVycyB3aWxsLCBieSBkZWZhdWx0 LCBtb2RpZnkgcm91dGUgcHJlZmVyZW5jZSBiYXNlZCBvbiB0aGUgY29tbXVuaXR5PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJm b250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3 aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzow cHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtj b2xvcjojMUY0OTdEIj5iKTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48c3BhbiBjbGFzcz0iZ3JhbWUiPm5vbjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9InNwZWxsZSI+Y29tcGxp YW50PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj5yb3V0ZXJzDQogd2lsbCwgYnkgZGVmYXVsdCwgYWNjZXB0IHRoaXMgY29tbXVuaXR5IG92ZXI8 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PHNwYW4gY2xh c3M9InNwZWxsZSI+ZUJHUDwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+c2Vzc2lvbnMuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs O29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0 YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFj aW5nOjBweCI+DQo8c3BhbiBjbGFzcz0iZ3JhbWUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6IzFGNDk3RCI+YSYjNDM7PC9zcGFuPjwvc3Bh bj48c3BhbiBjbGFzcz0ic3BlbGxlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0QiPmI8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6IzFGNDk3RCI+Og0K IHdlIGhhdmUgYW4gaXNzdWUgYXMgdW50cnVzdGVkIEFTIG1heSBpbmZsdWVuY2UgbXkgcm91dGlu ZyBwb2xpY3kgb3IgY3JlYXRlIGxvb3BzLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6IG5vcm1h bDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpz dGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3Bh Y2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2Fs aWJyaTtjb2xvcjojMUY0OTdEIj5XZSBhZ3JlZSB0aGF0IHdlIGNhbuKAmXQgZG8gYW55dGhpbmcg YWJvdXQg4oCcYuKAnS48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczog YXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0QiPlNvIEkgYW0gYXNraW5nIHRvIGFk ZHJlc3Mg4oCcYeKAnSBieSBoYXZpbmcgY29tcGxpYW50IHJvdXRlcnMgdG8gXzxpPm5vdDwvaT5f IGNoYW5nZSByb3V0ZSBwcmVmZXJlbmNlIGJ5IGRlZmF1bHQuPHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxzcGFuIGNsYXNzPSJncmFtZSI+aS5lPC9zcGFu Pi4gTVVTVCBiZQ0KIGV4cGxpY2l0bHkgY29uZmlndXJlZCB0byBjaGFuZ2UgdGhlaXIgcm91dGUg cHJlZmVyZW5jZSBiYXNlZCBvbiB0aGlzIGNvbW11bml0eS48L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImZvbnQtdmFyaWFudC1j YXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzst d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD YWxpYnJpO2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CFE790352FFA4B7A957480D46137E3DFciscocom_-- From nobody Fri Feb 3 16:44: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 5196B129470; Fri, 3 Feb 2017 16:44:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=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 8MzDqvcVW_fj; Fri, 3 Feb 2017 16:44:10 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0129.outbound.protection.outlook.com [23.103.200.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7890D129411; Fri, 3 Feb 2017 16:44:10 -0800 (PST) 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=ZZRgjYi0LQoklJgWZrtf+v1F6GCwLhxopBq679pKDxI=; b=GADSJry8YR9t6HsUMkj/9KNrRrinpwGGNsXbEvOpoy+RO+c6mqPSHdmlqy2ZWKlykw3nzirf84RX4F3dydj2UXWf90oG5jUfgM/uOUpynUArTYgXLxxhmtHn4y54qBGWAg5Th3vhR1XSdvvu1EYB31hYZ3z7EvjC55BI+epg+Fc= Received: from SN1PR09MB1007.namprd09.prod.outlook.com (10.166.69.13) by SN1PR09MB1006.namprd09.prod.outlook.com (10.166.69.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Sat, 4 Feb 2017 00:44:04 +0000 Received: from SN1PR09MB1007.namprd09.prod.outlook.com ([10.166.69.13]) by SN1PR09MB1007.namprd09.prod.outlook.com ([10.166.69.13]) with mapi id 15.01.0888.019; Sat, 4 Feb 2017 00:44:03 +0000 From: "Borchert, Oliver (Fed)" To: Susan Hares , "John Scudder (jgs@juniper.net)" Thread-Topic: Implementation call for draft-ietf-idr-bgp-extended-messages (1/24/2017 to 1/31/2017) Thread-Index: AdJ8sBDDhskHW5f6TcW8KGLFsDty8QBpc3kA Date: Sat, 4 Feb 2017 00:44:03 +0000 Message-ID: <24581E62-94D7-4D2E-8157-21ADF1CE7AF1@nist.gov> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 authentication-results: spf=none (sender IP is ) smtp.mailfrom=oliver.borchert@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.140.59] x-microsoft-exchange-diagnostics: 1; SN1PR09MB1006; 7:IJ4rHaJQD8tSNenKZJ2IjFe+kkUZAFZIYQr0gi+v6++fROftqRT23fO+WF2+kPGSOB179d9EDYK2dCIgvzI9u3vdkospWB/jUfL3x6t10wSJhAi4VGZXH5TRF8T2cnlKUo31aWRgIAgUIHbyS3i1fkY/PpmruTckAMlIZMV8VI9ukAg9vpeELFf1hjcpvjQOPB0OGLW6sdDvbDLMBjzDB41tFJKFL0UNcYfQXmAB0eYR314V+0PAlYep/73l3Zpu2f5ggKJoXoLHcyd6zzieF+0wfOyIAgsIPP+zruV9if+R5MSNY5QmXUUVBIMfnpY8zvW3p9LmkyLanbnTRcCabgPiVrwcV5QCSKrKVrcInkuIx9N7GoYUti6uLbvbeKa5VX++8RvrLQw0Srvjk/prnpuR6UumCnAjeuZU3QZnvN2K5+Bryuih8jqQ8NDY5xDzkFDGcLt6GJ77q+R0AdJEzyISCj76zFEMN014ZQQL5aWMuWiP9vnxu198ae+nUZueRkmMQtUK5Wmo5ABP45DOVw== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39830400002)(39450400003)(199003)(5423002)(189002)(30584003)(305945005)(8936002)(68736007)(66066001)(15650500001)(230783001)(1941001)(54906002)(53936002)(99286003)(122556002)(106356001)(6512007)(105586002)(8676002)(81156014)(81166006)(3660700001)(2906002)(6506006)(8666007)(83506001)(3280700002)(7736002)(229853002)(4326007)(50986999)(76176999)(36756003)(54356999)(38730400001)(25786008)(82746002)(83716003)(189998001)(4001350100001)(101416001)(6246003)(6436002)(97736004)(2950100002)(5660300001)(6116002)(86362001)(3846002)(2900100001)(77096006)(6486002)(5001770100001)(92566002)(33656002)(102836003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR09MB1006; H:SN1PR09MB1007.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: 0dce7d40-1a40-40a9-a7d2-08d44c96eabb x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:SN1PR09MB1006; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123558025)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(6072148); SRVR:SN1PR09MB1006; BCL:0; PCL:0; RULEID:; SRVR:SN1PR09MB1006; x-forefront-prvs: 020877E0CB received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <20F7BFCDC34AE847B5198F3F6C03F862@namprd09.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Feb 2017 00:44:03.0392 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR09MB1006 Archived-At: Cc: "idr-chairs@ietf.org" , "idr@ietf.org" Subject: Re: [Idr] Implementation call for draft-ietf-idr-bgp-extended-messages (1/24/2017 to 1/31/2017) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 00:44:12 -0000 QXQgTklTVCB3ZSBoYXZlIHR3byBpbmRlcGVuZGVudCBpbXBsZW1lbnRhdGlvbnMgb2YgdGhlIEJH UHNlYyBQcm90b2NvbCBpbmNsdWRpbmcgDQp0aGUgZXh0ZW5kZWQgbWVzc2FnZSBjYXBhYmlsaXR5 IGFzIHNwZWNpZmllZCBpbiDigJxkcmFmdC1pZXRmLWlkci1iZ3AtZXh0ZW5kZWQtbWVzc2FnZXMt MTTigJ0uDQoNClRoZXkgYXJlOg0KKDEpIFF1YWdnYVNSeCwgYW4gZXh0ZW5zaW9uIHRvIHRoZSBR dWFnZ2Egcm91dGVyIGltcGxlbWVudGF0aW9uDQooMikgQkdQU0VDLUlPLCBhIEJHUHNlYyB0cmFm ZmljIGdlbmVyYXRvciB0aGF0IGFsbG93cyBnZW5lcmF0aW5nIG11bHRpaG9wIEJHUHNlYyB1cGRh dGVzLg0KDQpRdWFnZ2FTUlg6DQo9PT09PT09PT09PT09PQ0KVGhlIGltcGxlbWVudGF0aW9uIGlu Y2x1ZGVzIHRoZSBmb2xsb3dpbmcgZmVhdHVyZXMgaW4gYWNjb3JkYW5jZSB3aXRoIHRoZSBkcmFm dDoNCjEuIEFubm91bmNlIHZpYSBCR1AgQ2FwYWJpbGl0eSBhZHZlcnRpc2VtZW50IChSRkM1NDky KSBhcyBCR1AgRXh0ZW5kZWQgQ2FwYWJpbGl0eTogWWVzDQoyLiBJZiBCR1AgRXh0ZW5kZWQgQ2Fw YWJpbGl0eSBuZWdvdGlhdGVkLCB0aGVuIE1VU1QgcmVjZWl2ZSBhbmQgcHJvY2VzcyBtZXNzYWdl IGxhcmdlciB0aGFuIDQwOTYgYnl0ZXM6IFllcw0KMy4gSWYgQkdQIEV4dGVuZGVkIENhcGFiaWxp dHkgbm90IG5lZ290aWF0ZWQsIHRoZW4gTVVTVCBOT1Qgc2VuZCBtZXNzYWdlIGxhcmdlciB0aGFu IDQwOTYgYnl0ZXM6IFllcyAgDQo0LiBNQVkgYWNjZXB0IEVYVEVOREVEIE1FU1NBR0UgZnJvbSBw ZWVyIGlmIG5vdCBhZHZlcnRpc2VkIEJHUCBFeHRlbmRlZCBDYXBhYmlsaXR5OiBZZXMNCg0KQkdQ U0VDLUlPOg0KPT09PT09PT09PQ0KVGhlIGltcGxlbWVudGF0aW9uIGluY2x1ZGVzIHRoZSBmb2xs b3dpbmcgZmVhdHVyZXMgaW4gYWNjb3JkYW5jZSB3aXRoIHRoZSBkcmFmdDoNCjEuIEFubm91bmNl IHZpYSBCR1AgQ2FwYWJpbGl0eSBhZHZlcnRpc2VtZW50IChSRkM1NDkyKSBhcyBCR1AgRXh0ZW5k ZWQgQ2FwYWJpbGl0eTogWWVzDQoyLiBJZiBCR1AgRXh0ZW5kZWQgQ2FwYWJpbGl0eSBuZWdvdGlh dGVkLCB0aGVuIE1VU1QgcmVjZWl2ZSBhbmQgcHJvY2VzcyBtZXNzYWdlIGxhcmdlciB0aGFuIDQw OTYgYnl0ZXM6IFllcw0KMy4gSWYgQkdQIEV4dGVuZGVkIENhcGFiaWxpdHkgbm90IG5lZ290aWF0 ZWQsIHRoZW4gTVVTVCBOT1Qgc2VuZCBtZXNzYWdlIGxhcmdlciB0aGFuIDQwOTYgYnl0ZXM6IFll cyAgDQo0LiBNQVkgYWNjZXB0IEVYVEVOREVEIE1FU1NBR0UgZnJvbSBwZWVyIGlmIG5vdCBhZHZl cnRpc2VkIEJHUCBFeHRlbmRlZCBDYXBhYmlsaXR5OiBZZXMNCg0KDQpUaGFua3MsDQpPbGl2ZXIN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCk9saXZlciBCb3JjaGVydCwgQ29tcHV0ZXIgU2NpZW50aXN0DQpOYXRpb25hbCBJbnN0 aXR1dGUgb2YgU3RhbmRhcmRzIGFuZCBUZWNobm9sb2d5DQooUGhvbmUpIDMwMS45NzUuNDg1NiAs IChGYXgpIDMwMS45NzUuNjIzOA0KDQoNCg== From nobody Sun Feb 5 14:03: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 D4F811299BC for ; Sun, 5 Feb 2017 14:03:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdk4hbtIPnbZ for ; Sun, 5 Feb 2017 14:03:20 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0092.outbound.protection.outlook.com [104.47.37.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 792831294DD for ; Sun, 5 Feb 2017 14:03:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=dVepuAF2t4kYFg5A9ZXaJ2+sNnYIZwM36jU889g8Ekg=; b=c+9dEssYS+w9/oPi5fUKGbf5WKXDrvavsxxvXmNm6oZOeT/OB8NJPs949ReRF6cIPeaUPielH76EJ7hq8/+EyzWmxs5FL9cy/dYyr1dLJ6lCJgHSy0FXZvrT5+L7167W2ts8kTeMVj1TdFsVKu9z0PEBRWPEky9AOLbNvdgi55U= Received: from BLUPR05MB771.namprd05.prod.outlook.com (10.141.209.26) by BN3PR05MB2497.namprd05.prod.outlook.com (10.167.3.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.5; Sun, 5 Feb 2017 22:03:18 +0000 Received: from BLUPR05MB771.namprd05.prod.outlook.com ([10.141.209.26]) by BLUPR05MB771.namprd05.prod.outlook.com ([10.141.209.26]) with mapi id 15.01.0888.025; Sun, 5 Feb 2017 22:03:16 +0000 From: Justin Ryburn To: John Scudder Thread-Topic: [Idr] WG adoption call for draft-hr-idr-rfc5575bis-02 "Dissemination of Flow Specification Rules" Thread-Index: AQHSc/eM8ikplIvppkSPWd5dkQtapKFbD12A Date: Sun, 5 Feb 2017 22:03:16 +0000 Message-ID: <6C09A2CC-CEF5-490F-AB0D-204866C5897D@juniper.net> References: <36E285C0-C716-437A-806D-A453273146DD@juniper.net> In-Reply-To: <36E285C0-C716-437A-806D-A453273146DD@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) authentication-results: spf=none (sender IP is ) smtp.mailfrom=jryburn@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-microsoft-exchange-diagnostics: 1; BN3PR05MB2497; 7:nqqEdtX6qVqw09xHDxPz9nIlUHWiyZpDhFsW76KKelQvgVEyOGOEGIVezGI2NvrtEVKpCVjgBdUGc6sdRz752aQG5pltfYUmlof5QZJz3Zae7lGiSrG5NrRtC29+nHC7UvV5E9GVHkDbFGzPoYBjYn6STjU0tDla3jKRqnG6x+PsjugyeTHhc57gLf0NyZn95j5PA9Rr7tVQK5gCNS5OV2U1kog/H+fhfDhXw6AWV057jTAVYTRRr43V7QolQ9R73C3nmzCoHlEt1vabONngI/2nDl3icKVYejdN4pXkInehiiTTNwVU4jtxbniU6LZ1qXTDWR5fnoOrKOqW0EFyLpfV95sGEOghLaCkofS5wGoHmvzi8JKxTxHKasW/9ezllWHjYsd9NkN/wjFleXrWljPmHxWt1zKa+xvk4EpYlDr178OpXtdd0G0hM3RJ/3oNtwWthY9u9Px/vehg0see9IWjT8rMi+m+T5i/q3x0EqKymGNfQ7d6PLyfGwIrs2KCVfuogpwEjFAabT63nqdn9w== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39850400002)(39410400002)(39840400002)(39860400002)(39450400003)(53754006)(199003)(377454003)(24454002)(189002)(6636002)(81166006)(3660700001)(8676002)(81156014)(38730400001)(2950100002)(77096006)(6486002)(6436002)(5660300001)(6862003)(110136003)(33656002)(92566002)(8936002)(50226002)(305945005)(7736002)(57306001)(122556002)(6506006)(66066001)(82746002)(86362001)(83716003)(450100001)(1941001)(229853002)(68736007)(53936002)(2906002)(6306002)(230783001)(106356001)(106116001)(3280700002)(25786008)(4326007)(99286003)(6512007)(102836003)(3846002)(6116002)(105586002)(36756003)(189998001)(2900100001)(97736004)(6246003)(76176999)(50986999)(101416001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR05MB2497; H:BLUPR05MB771.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: 11dec676-4449-4759-079a-08d44e12c997 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR05MB2497; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(20170203043)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123555025)(20161123558025)(20161123564025)(20161123560025)(6072148); SRVR:BN3PR05MB2497; BCL:0; PCL:0; RULEID:; SRVR:BN3PR05MB2497; x-forefront-prvs: 0209425D0A received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <2F613F21E9A5AF44AC8AAA8293D5EA1E@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2017 22:03:16.2887 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR05MB2497 Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] WG adoption call for draft-hr-idr-rfc5575bis-02 "Dissemination of Flow Specification Rules" X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2017 22:03:22 -0000 SSBzdXBwb3J0ZWQgdGhpcyBkcmFmdC4gRGVmaW5pdGVseSBuZWVkZWQgYnkgdGhlIGluZHVzdHJ5 Lg0KDQotSnVzdGluDQoNCk9uIEphbiAyMSwgMjAxNywgYXQgOTowMyBBTSwgSm9obiBHLiBTY3Vk ZGVyIDxqZ3NAanVuaXBlci5uZXQ+IHdyb3RlOg0KDQpIaSBBbGwsDQoNClRoZSBhdXRob3JzIGhh dmUgcmVxdWVzdGVkIElEUiB3b3JraW5nIGdyb3VwIGFkb3B0aW9uIG9mIGRyYWZ0LWhyLWlkci1y ZmM1NTc1YmlzLTAyICJEaXNzZW1pbmF0aW9uIG9mIEZsb3cgU3BlY2lmaWNhdGlvbiBSdWxlcyIu IFBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIGxpc3QuDQoNClRoaXMgYWRvcHRpb24g Y2FsbCB3aWxsIGNvbmNsdWRlIG9uIE1vbmRheSwgRmVicnVhcnkgNi4NCg0KVGhhbmtzLA0KDQri gJRKb2huDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K SWRyIG1haWxpbmcgbGlzdA0KSWRyQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2lkcg0KDQo= From nobody Sun Feb 5 14:10: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 E90DD1299DB for ; Sun, 5 Feb 2017 14:10:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 dTcsA6egUxYC for ; Sun, 5 Feb 2017 14:10:26 -0800 (PST) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 587C51299C3 for ; Sun, 5 Feb 2017 14:10:26 -0800 (PST) Received: by mail-wr0-x22a.google.com with SMTP id 89so14570938wrr.2 for ; Sun, 05 Feb 2017 14:10:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aZTTzrlHcp5+vDjeNxzKWKwoD/8lo3ZbM1zshDgxWqc=; b=DerWUHd/yqQYSWCgfVw46k1sdpBhzoEYFSAHBmlvZdMThSr/7tpa0j0BgZkRfa9y/5 lisUU0Mrl/obvrX1ATStlj+4Dr1buEajvAJjv3GOu2v1pz2zyhS4p4qknGJxJBAdTSD+ UDBY5iMRAcqrGpS8GdtuvOMo8K89vHPdVXd/FCnng1JCnsriahNDmwSAN5Nd3vtsUZ1g SlW0/rsWS4bmAYgXlM7XYabdthkYvNw61o7P0C835mGYDGz0dceP5QNF6QefNIIZss20 4ORj12qZcdwr5WD02opt/KyGksedvbnQqtyXmEQh1XeZnTTknA6iY7YTSouK+YwLBXjJ FRaQ== 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=aZTTzrlHcp5+vDjeNxzKWKwoD/8lo3ZbM1zshDgxWqc=; b=QVc3vwvVk8UAxkc+1wKkUGfR3PxfAbxIlpwnHOQdlWYPutz6RuTlwuFWzeuh9W6sDF tp5jhOnef7dzBfhQkR/OvME5goEjnzQSICpTQgOQ2TRLhm/JcInUb0/qgAlpJZ/CsThE LtS2SAFEizG8jM23FIjitiJRc+9iVbYD+60XInvbahzMaJ/N+4IWxUYpf124d9XfFgp0 nEUT4vfo0VYACe2M6DuIQkpoRhQLoAg7yrXvoeijAGYlXPdFYe6HpjniquVgx49fuPnf VO+nnTHw6/yIWEIU1DwZNJmmPMN4tw6YPeWfGmXXwANp9fiR80Ml3Wnwp5cDD+Zy+XOI GFfQ== X-Gm-Message-State: AIkVDXLtz8etD7wsJcERFM+yMdJDgDtvEpjFaTP6sGZ1heEIKtrtkRmvkgRJuAySjVg2yKKaSYHNV2K1NHJgFA== X-Received: by 10.223.170.70 with SMTP id q6mr6657155wrd.103.1486332624757; Sun, 05 Feb 2017 14:10:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.137.82 with HTTP; Sun, 5 Feb 2017 14:10:24 -0800 (PST) In-Reply-To: <6C09A2CC-CEF5-490F-AB0D-204866C5897D@juniper.net> References: <36E285C0-C716-437A-806D-A453273146DD@juniper.net> <6C09A2CC-CEF5-490F-AB0D-204866C5897D@juniper.net> From: pete Date: Sun, 5 Feb 2017 14:10:24 -0800 Message-ID: To: Justin Ryburn Content-Type: multipart/alternative; boundary=94eb2c1cc94c1de9040547cfc8d2 Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] WG adoption call for draft-hr-idr-rfc5575bis-02 "Dissemination of Flow Specification Rules" X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2017 22:10:28 -0000 --94eb2c1cc94c1de9040547cfc8d2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 Thanks. pete On Sun, Feb 5, 2017 at 2:03 PM, Justin Ryburn wrote: > I supported this draft. Definitely needed by the industry. > > -Justin > > On Jan 21, 2017, at 9:03 AM, John G. Scudder wrote: > > Hi All, > > The authors have requested IDR working group adoption of > draft-hr-idr-rfc5575bis-02 "Dissemination of Flow Specification Rules". > Please send your comments to the list. > > This adoption call will conclude on Monday, February 6. > > Thanks, > > =E2=80=94John > _______________________________________________ > 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 > --94eb2c1cc94c1de9040547cfc8d2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

Thanks.
pete

On Sun, Feb 5, 2017= at 2:03 PM, Justin Ryburn <jryburn@juniper.net> wrote:
I supported this draft. Definitely needed b= y the industry.

-Justin

On Jan 21, 2017, at 9:03 AM, John G. Scudder <jgs@juniper.net> wrote:

Hi All,

The authors have requested IDR working group adoption of draft-hr-idr-rfc55= 75bis-02 "Dissemination of Flow Specification Rules". Please send= your comments to the list.

This adoption call will conclude on Monday, February 6.

Thanks,

=E2=80=94John
_______________________________________________
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

--94eb2c1cc94c1de9040547cfc8d2-- From nobody Sun Feb 5 16:10:31 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 228C1129550; Sun, 5 Feb 2017 16:10:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148633983010.31577.17646699074658727347.idtracker@ietfa.amsl.com> Date: Sun, 05 Feb 2017 16:10:30 -0800 Archived-At: Cc: idr-chairs@ietf.org, idr@ietf.org Subject: [Idr] idr - Update to a Meeting Session Request for IETF 98 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 00:10:30 -0000 An update to a meeting session request has just been submitted by Susan Hares, a Chair of the idr working group. --------------------------------------------------------- Working Group Name: Inter-Domain Routing Area Name: Routing Area Session Requester: Susan Hares Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: i2rs i2nsf trill spring netmod netconf rtgwg grow Second Priority: bess sidrops Third Priority: detnet dots nfvrg mpls People who must be present: Susan Hares John Scudder Alvaro Retana Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sun Feb 5 18:38: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 50E01129A83 for ; Sun, 5 Feb 2017 18:38:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 2iebaeDoNSRr for ; Sun, 5 Feb 2017 18:38:32 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 287AE1294AD for ; Sun, 5 Feb 2017 18:38:32 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DFV86313; Mon, 06 Feb 2017 02:38:30 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 6 Feb 2017 02:38:29 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Mon, 6 Feb 2017 10:38:25 +0800 From: "Dongjie (Jimmy)" To: "John G. Scudder" , "idr@ietf.org" Thread-Topic: [Idr] WG adoption call for draft-hr-idr-rfc5575bis-02 "Dissemination of Flow Specification Rules" Thread-Index: AQHSc/edJJrBnWLn8UKwaad8mVlF4KFbWRDw Date: Mon, 6 Feb 2017 02:39:38 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C92793579ECE@NKGEML515-MBX.china.huawei.com> References: <36E285C0-C716-437A-806D-A453273146DD@juniper.net> In-Reply-To: <36E285C0-C716-437A-806D-A453273146DD@juniper.net> 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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.5897E1A6.00DC, 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: 90e1abc951d55526ffa833a89d40f955 Archived-At: Subject: Re: [Idr] WG adoption call for draft-hr-idr-rfc5575bis-02 "Dissemination of Flow Specification Rules" X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 02:38:34 -0000 U3VwcG9ydCB0aGUgYWRvcHRpb24uIA0KDQpJdCBpcyBxdWl0ZSB1c2VmdWwgdG8gY2xhcmlmeSB0 aGUgb3JkZXJpbmcgb2YgdHJhZmZpYyBmaWx0ZXJpbmcgYW5kIHRoZSBydWxlcyBvZiB0cmFmZmlj IGFjdGlvbiBjb25mbGljdHMgZm9yIGJldHRlciBpbnRlcm9wZXJhYmlsaXR5Lg0KDQpCZXN0IHJl Z2FyZHMsDQpKaWUNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBJZHIg W21haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpvaG4gRy4gU2N1ZGRl cg0KPiBTZW50OiBTYXR1cmRheSwgSmFudWFyeSAyMSwgMjAxNyAxMTowMyBQTQ0KPiBUbzogaWRy QGlldGYub3JnDQo+IFN1YmplY3Q6IFtJZHJdIFdHIGFkb3B0aW9uIGNhbGwgZm9yIGRyYWZ0LWhy LWlkci1yZmM1NTc1YmlzLTAyICJEaXNzZW1pbmF0aW9uIG9mDQo+IEZsb3cgU3BlY2lmaWNhdGlv biBSdWxlcyINCj4gDQo+IEhpIEFsbCwNCj4gDQo+IFRoZSBhdXRob3JzIGhhdmUgcmVxdWVzdGVk IElEUiB3b3JraW5nIGdyb3VwIGFkb3B0aW9uIG9mDQo+IGRyYWZ0LWhyLWlkci1yZmM1NTc1Ymlz LTAyICJEaXNzZW1pbmF0aW9uIG9mIEZsb3cgU3BlY2lmaWNhdGlvbiBSdWxlcyIuIFBsZWFzZQ0K PiBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIGxpc3QuDQo+IA0KPiBUaGlzIGFkb3B0aW9uIGNh bGwgd2lsbCBjb25jbHVkZSBvbiBNb25kYXksIEZlYnJ1YXJ5IDYuDQo+IA0KPiBUaGFua3MsDQo+ IA0KPiDigJRKb2huDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IElkciBtYWlsaW5nIGxpc3QNCj4gSWRyQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQo= From nobody Sun Feb 5 23:40:11 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 83848129C90 for ; Sun, 5 Feb 2017 23:40:09 -0800 (PST) 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, FREEMAIL_FROM=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 0CJGsKHT6XpW for ; Sun, 5 Feb 2017 23:40:08 -0800 (PST) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::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 47D26129565 for ; Sun, 5 Feb 2017 23:40:08 -0800 (PST) Received: by mail-pg0-x241.google.com with SMTP id v184so8403760pgv.1 for ; Sun, 05 Feb 2017 23:40:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=M+nfH5AlUQwy5AIeiz6bDSO83bCB7IIetgeYuFZHLkg=; b=KjrBz7ZGf0RYbFLgg6en/YX8KGIR+3x3tYO7DiNU5WTEkmX+8Pqy4fdq5AXZS/85U0 Rl6HCQCm2gyTU4wW4ReeUySK+vA7hMGnHhruSuzpJ5JYvN8JVl2ZH8bUwS6BgbjpV15F t1XchmTvT7hdYI3jhGS2iqSVrtP2OvRs8cIW70wlfluNdmhSZKjGtbW2r0AHFQekRe1o BStgp2/8FeTALxCEnAyKX2F6lg6qy/PWPzOau6nMAa/5gz4JloiTcqCDgge5Y3+89BuZ FiFPtD4pvV9bU5vydALnXY44lHsxXT7lWnTGT1mrXVT3gbRfLEsCGYbnK/+U6A67GqPr 5ylA== 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=M+nfH5AlUQwy5AIeiz6bDSO83bCB7IIetgeYuFZHLkg=; b=jmv7E9FVN2+XOzdkylUxtinuc3YHpEJsaryX4uuNLgoLeMB2Rn/Hwy2vsGZD9b2H1+ ukV/btVHXZ2gIkfWJdKrCPRcxpKBI5a8DLSey+erP4X1GQcLIS9AZZWugXELLIpFGZWh 1MdYuBbphTjJnWwR3/7GNskUpJbTkOs7JvvaW0ZV4UuvsrcZ0Xd7lX3qWDyu7DUI30e5 VHGTyatQDdx3+cZqrE9x9TUwxf0s7822QoorOfHccgLs4YaQvG3UjavXX6GueCpYQueX DpBPKxEB12qzqRKq8VFgIs8EyhQrTFlETIgIs0rUSC7u95iTyIHaaHb0HNvKB9pyqIq4 EYww== X-Gm-Message-State: AIkVDXJI75nJuJdninm6Lw8WOYRfr8sJbf6WVTLNXGGNStL0ClpclbIYOjmAHsAdUj+ADQ== X-Received: by 10.99.42.78 with SMTP id q75mr11668682pgq.144.1486366807874; Sun, 05 Feb 2017 23:40:07 -0800 (PST) Received: from [192.168.1.4] ([76.126.247.72]) by smtp.gmail.com with ESMTPSA id c64sm86189860pfa.45.2017.02.05.23.40.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Feb 2017 23:40:06 -0800 (PST) User-Agent: Microsoft-MacOutlook/f.1e.0.170107 Date: Sun, 05 Feb 2017 23:40:03 -0800 From: Jeff Tantsura To: John Scudder Message-ID: Thread-Topic: [Idr] WG adoption call for draft-hr-idr-rfc5575bis-02 "Dissemination of Flow Specification Rules" References: <36E285C0-C716-437A-806D-A453273146DD@juniper.net> <6C09A2CC-CEF5-490F-AB0D-204866C5897D@juniper.net> In-Reply-To: <6C09A2CC-CEF5-490F-AB0D-204866C5897D@juniper.net> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] WG adoption call for draft-hr-idr-rfc5575bis-02 "Dissemination of Flow Specification Rules" X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 07:40:09 -0000 yes/support =20 Cheers, Jeff =20 On Jan 21, 2017, at 9:03 AM, John G. Scudder wrote: =20 Hi All, =20 The authors have requested IDR working group adoption of draft-hr-idr-r= fc5575bis-02 "Dissemination of Flow Specification Rules". Please send your c= omments to the list. =20 This adoption call will conclude on Monday, February 6. =20 Thanks, =20 =E2=80=94John _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr =20 From nobody Mon Feb 6 00:52: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 1B734129CB1 for ; Mon, 6 Feb 2017 00:52:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 PEs2DdgHELdq for ; Mon, 6 Feb 2017 00:52:03 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id B481F12945C for ; Mon, 6 Feb 2017 00:52:01 -0800 (PST) X-MAILFROM: X-RCPTTO: X-FROMIP: 192.168.168.120 X-SEG-Scaned: 1 X-Received: unknown,192.168.168.120,20170206164332 Received: from unknown (HELO out1.zte.com.cn) (192.168.168.120) by localhost with SMTP; 6 Feb 2017 08:43:32 -0000 X-MAILFROM: X-RCPTTO: X-FROMIP: 10.30.3.20 X-SEG-Scaned: 1 X-Received: unknown,10.30.3.20,20170206164010 Received: from unknown (HELO mse01.zte.com.cn) (10.30.3.20) by localhost with (AES256-SHA encrypted) SMTP; 6 Feb 2017 08:40:10 -0000 Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id v168pcZ4058564; Mon, 6 Feb 2017 16:51:38 +0800 (GMT-8) (envelope-from zhang.zheng@zte.com.cn) Received: from njxapp02.zte.com.cn ([10.41.132.201]) by notes_svr37.zte.com.cn (IBM Domino Release 9.0.1FP6) with SMTP id 2017020616513629-868549 ; Mon, 6 Feb 2017 16:51:36 +0800 Received: from mapi (njxapp04[null]) by mapi (Zmail) with MAPI id mid203; Mon, 6 Feb 2017 16:51:39 +0800 (CST) Date: Mon, 6 Feb 2017 16:51:39 +0800 (CST) X-Zmail-TransId: 2afc5898391b600-be146 X-Mailer: Zmail v1.0 Message-ID: <201702061651394752150@zte.com.cn> X-Priority: 3 (Normal) References: 36E285C0-C716-437A-806D-A453273146DD@juniper.net, 1D651738-BCED-4F25-88B5-5257871697DA@juniper.net Mime-Version: 1.0 From: To: X-MIMETrack: Itemize by SMTP Server on notes_svr37/zte_ltd(Release 9.0.1FP6|April 20, 2016) at 2017/02/06 16:51:36, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2017-02-06 16:51:26, Serialize complete at 2017-02-06 16:51:26 X-TNEFEvaluated: 1 Content-Type: multipart/mixed; boundary="=====_001_next=====" X-MAIL: mse01.zte.com.cn v168pcZ4058564 X-HQIP: 127.0.0.1 X-HQIP: 127.0.0.1 Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] =?utf-8?q?WG_adoption_call_for_draft-hr-idr-rfc5575bis-02_?= =?utf-8?q?=22Dissemination_of_Flow_Specification_Rules=22?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 08:52:05 -0000 --=====_001_next===== Content-Type: multipart/related; boundary="=====_002_next=====" --=====_002_next===== Content-Type: multipart/alternative; boundary="=====_003_next=====" --=====_003_next===== Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="UTF-8" U3VwcG9ydC4NCg0KDQoNCg0KVGhhbmtzLA0KDQpTYW5keQ0KDQoNCg0KDQoNCg0KDQoNCg0KDQrl jp/lp4vpgq7ku7YNCg0KDQoNCuWPkeS7tuS6uu+8miDvvJxqZ3NAanVuaXBlci5uZXTvvJ4NCuaU tuS7tuS6uu+8miDvvJxpZHJAaWV0Zi5vcmfvvJ4NCuaXpSDmnJ8g77yaMjAxN+W5tDAy5pyIMDLm l6UgMDA6NDENCuS4uyDpopgg77yaUmU6IFtJZHJdIFdHIGFkb3B0aW9uIGNhbGwgZm9yIGRyYWZ0 LWhyLWlkci1yZmM1NTc1YmlzLTAyICJEaXNzZW1pbmF0aW9uIG9mIEZsb3cgU3BlY2lmaWNhdGlv biBSdWxlcyINCg0KDQoNCg0KDQpIaSBBbGwsDQoNClJlbWluZGVyLCB0aGlzIGNhbGwgZm9yIGFk b3B0aW9uIGlzIGdvaW5nIG9uIGFuZCB3aWxsIGVuZCBpbiBmaXZlIGRheXMuIFNvIGZhciwgdGhl IG9ubHkgcmVwbHkgaGFzIGJlZW4gZnJvbSBDaHJpc3RvcGggKHRoYW5rcyEpIHdpdGggYSBwb2lu dGVyIHRvIGhpcyBwYXBlciAiQkdQIEZsb3cgU3BlY2lmaWNhdGlvbiBNdWx0aSBWZW5kb3IgYW5k IEludGVyIEFTIEludGVyb3BlcmFiaWxpdHkiLiBUaGUgcGFwZXIgaXMgbG9uZywgYnV0IEkgZW5j b3VyYWdlIHlvdSB0byBsb29rIGF0IGl0LiBUbyBlbmNvdXJhZ2UgeW91LCBoZXJlIGFyZSBhIGZl dyBleGNlcnB0cyBmcm9tIHRoZSBjb25jbHVzaW9uOg0KDQoid2UgdGhpbmsgdGhhdCB3aGF0IHdl IGxpc3RlZCBhcyBidWdzIHNvbWV0aW1lcyBpcyBhIHJlc3VsdCBvZiB1bmNsZWFyIHNlY3Rpb25z IGFuZCBkZWZpbml0aW9ucyBpbiBSRkMgNTU3NSINCg0KIldpdGggdGhpcyB1cGRhdGUgd2UgdGhp bmsgdGhhdCBhIHByb3BlciBpbnRlcm9wZXJhYmxlIGltcGxlbWVudGF0aW9uIHNob3VsZCBiZSBw b3NzaWJsZSBhbmQgdW5hbWJpZ3VvdXMgc2VjdGlvbnMgaGF2ZSBiZWVuIGltcHJvdmVkIg0KDQph bmQgcGVyaGFwcyBtb3N0IG1vdGl2YXRpb25hbCB0byB0aGUgV0c6DQoNCiJHaXZlbiB0aGUgY3Vy cmVudCBidWdzLCBpbnRlcm9wZXJhYmlsaXR5IGlzc3VlcyBhbmQgbWlzc2luZyBmZWF0dXJlcyB3 ZSBkbyBub3QgcmVjb21tZW5kIGZsb3cgc3BlY2lmaWNhdGlvbiBCR1Agc2Vzc2lvbnMgYmV0d2Vl biBkaWZmZXJlbnQgY2FycmllcnMgW+KApl0gSW52YWxpZCBmbG93IHNwZWNpZmljYXRpb24gTkxS SXMgb3IgYWN0aW9uIGZpbHRlcnMgaGF2ZSB0aGUgcG90ZW50aWFsIHRvIHJlbW90ZWx5IHRyaWdn ZXIgYSBjb21wbGV0ZSBuZXR3b3JrIGZhaWx1cmUuIg0KDQpJZiB5b3UgZG8gTk9UIHN1cHBvcnQg YWRvcHRpbmcgdGhpcyB3b3JrLCBpdCB3b3VsZCBiZSBpbnRlcmVzdGluZyB0byBoZWFyIHdoeS4g Rm9yIGV4YW1wbGUsIGRvIHlvdSB0aGluayBSRkMgNTU3NSBpcyBmaW5lIGFzIGl0IGlzLCBhbmQg aWYgc28sIHdoeSAoY29uc2lkZXJpbmcgdGhlIGlzc3VlcyByYWlzZWQgaW4gdGhlIHBhcGVyIGFu ZCBvbiB0aGUgbGlzdCkuIE9mIGNvdXJzZSwgaXQgaXMgbm90IElEUidzIGpvYiB0byBkb2N1bWVu dCBhbmQgZml4IGltcGxlbWVudGF0aW9uIGJ1Z3MuIEJ1dCBpdCBpcyAqZXhhY3RseSogb3VyIGpv YiB0byBmaXggdGhlIHNwZWMgaWYgaXQncyBhbWJpZ3VvdXMgYW5kIHRoYXQgYW1iaWd1aXR5IGxl YWRzIHRvIGludGVyb3BlcmFiaWxpdHkgaXNzdWVzLg0KDQpJZiB5b3UgZG8gc3VwcG9ydCBhZG9w dGluZyB0aGUgd29yaywgcGxlYXNlIHJlbWVtYmVyIHRvIHNheSBzbyBvbiB0aGUgbGlzdCDigJQg d2UgY2FuJ3QgZGVjbGFyZSBjb25zZW5zdXMgYmFzZWQgb24gc2lsZW5jZS4NCg0KVGhhbmtzLA0K DQrigJRKb2huDQoNCu+8niBPbiBKYW4gMjEsIDIwMTcsIGF0IDEwOjAzIEFNLCBKb2huIEcuIFNj dWRkZXIg77ycamdzQGp1bmlwZXIubmV077yeIHdyb3RlOg0K77yeIA0K77yeIEhpIEFsbCwNCu+8 niANCu+8niBUaGUgYXV0aG9ycyBoYXZlIHJlcXVlc3RlZCBJRFIgd29ya2luZyBncm91cCBhZG9w dGlvbiBvZiBkcmFmdC1oci1pZHItcmZjNTU3NWJpcy0wMiAiRGlzc2VtaW5hdGlvbiBvZiBGbG93 IFNwZWNpZmljYXRpb24gUnVsZXMiLiBQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBs aXN0Lg0K77yeIA0K77yeIFRoaXMgYWRvcHRpb24gY2FsbCB3aWxsIGNvbmNsdWRlIG9uIE1vbmRh eSwgRmVicnVhcnkgNi4NCu+8niANCu+8niBUaGFua3MsDQrvvJ4gDQrvvJ4g4oCUSm9obg0K77ye IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQrvvJ4gSWRy IG1haWxpbmcgbGlzdA0K77yeIElkckBpZXRmLm9yZw0K77yeIGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaWRyDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpJZHIgbWFpbGluZyBsaXN0DQpJZHJAaWV0Zi5vcmcNCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRy --=====_003_next===== Content-Transfer-Encoding: base64 Content-Type: text/html ; charset="UTF-8" PGRpdiBjbGFzcz0iemNvbnRlbnRSb3ciPiA8cD5TdXBwb3J0LjwvcD48cD48YnI+PC9wPjxwPlRo YW5rcyw8L3A+PHA+U2FuZHk8L3A+PHA+PGJyPjwvcD48ZGl2IGNsYXNzPSJ6TWFpbFNpZ24iPjwv ZGl2PjxkaXYgY2xhc3M9InpNYWlsRnJvbSI+PC9kaXY+PGRpdj48ZGl2IGNsYXNzPSJ6aGlzdG9y eVJvdyIgc3R5bGU9ImRpc3BsYXk6YmxvY2siPjxkaXYgY2xhc3M9InpoaXN0b3J5RGVzIiBzdHls ZT0id2lkdGg6IDEwMCU7IGhlaWdodDogMjhweDsgbGluZS1oZWlnaHQ6IDI4cHg7IGJhY2tncm91 bmQtY29sb3I6ICNFMEU1RTk7IGNvbG9yOiAjMTM4OEZGOyB0ZXh0LWFsaWduOiBjZW50ZXI7IiBs YW5ndWFnZS1kYXRhPSJIaXN0b3J5T3JnVHh0Ij7ljp/lp4vpgq7ku7Y8L2Rpdj48ZGl2IGlkPSJ6 d3JpdGVIaXN0b3J5Q29udGFpbmVyIj48ZGl2IGNsYXNzPSJjb250cm9sLWdyb3VwIHpoaXN0b3J5 UGFuZWwiPjxkaXYgY2xhc3M9InpoaXN0b3J5SGVhZGVyIiBzdHlsZT0icGFkZGluZzogOHB4OyBi YWNrZ3JvdW5kLWNvbG9yOiAjRjVGNkY4OyI+PGRpdj48c3Ryb25nIGxhbmd1YWdlLWRhdGE9Ikhp c3RvcnlTZW5kZXJUeHQiPuWPkeS7tuS6uu+8mjwvc3Ryb25nPjxzcGFuIGNsYXNzPSJ6cmVhZFVz ZXJOYW1lIj4g77ycamdzQGp1bmlwZXIubmV077yeOzwvc3Bhbj48L2Rpdj48ZGl2PjxzdHJvbmcg bGFuZ3VhZ2UtZGF0YT0iSGlzdG9yeVRPVHh0Ij7mlLbku7bkurrvvJo8L3N0cm9uZz48c3BhbiBj bGFzcz0ienJlYWRVc2VyTmFtZSIgc3R5bGU9ImRpc3BsYXk6IGlubGluZS1ibG9jazsiPiDvvJxp ZHJAaWV0Zi5vcmfvvJ47PC9zcGFuPjwvZGl2PjxkaXY+PHN0cm9uZyBsYW5ndWFnZS1kYXRhPSJI aXN0b3J5RGF0ZVR4dCI+5pelIOacnyDvvJo8L3N0cm9uZz48c3BhbiBjbGFzcz0iIj4yMDE35bm0 MDLmnIgwMuaXpSAwMDo0MTwvc3Bhbj48L2Rpdj48ZGl2PjxzdHJvbmcgbGFuZ3VhZ2UtZGF0YT0i SGlzdG9yeVN1YmplY3RUeHQiPuS4uyDpopgg77yaPC9zdHJvbmc+PHNwYW4gY2xhc3M9InpyZWFk VGl0bGUiPjxzdHJvbmc+UmU6IFtJZHJdIFdHIGFkb3B0aW9uIGNhbGwgZm9yIGRyYWZ0LWhyLWlk ci1yZmM1NTc1YmlzLTAyICJEaXNzZW1pbmF0aW9uIG9mIEZsb3cgU3BlY2lmaWNhdGlvbiBSdWxl cyI8L3N0cm9uZz48L3NwYW4+PC9kaXY+PC9kaXY+PHAgY2xhc3M9InpoaXN0b3J5Q29udGVudCI+ PGJyPjwvcD48ZGl2PkhpJm5ic3A7QWxsLDxicj48YnI+UmVtaW5kZXIsJm5ic3A7dGhpcyZuYnNw O2NhbGwmbmJzcDtmb3ImbmJzcDthZG9wdGlvbiZuYnNwO2lzJm5ic3A7Z29pbmcmbmJzcDtvbiZu YnNwO2FuZCZuYnNwO3dpbGwmbmJzcDtlbmQmbmJzcDtpbiZuYnNwO2ZpdmUmbmJzcDtkYXlzLiZu YnNwO1NvJm5ic3A7ZmFyLCZuYnNwO3RoZSZuYnNwO29ubHkmbmJzcDtyZXBseSZuYnNwO2hhcyZu YnNwO2JlZW4mbmJzcDtmcm9tJm5ic3A7Q2hyaXN0b3BoJm5ic3A7KHRoYW5rcyEpJm5ic3A7d2l0 aCZuYnNwO2EmbmJzcDtwb2ludGVyJm5ic3A7dG8mbmJzcDtoaXMmbmJzcDtwYXBlciZuYnNwOyJC R1AmbmJzcDtGbG93Jm5ic3A7U3BlY2lmaWNhdGlvbiZuYnNwO011bHRpJm5ic3A7VmVuZG9yJm5i c3A7YW5kJm5ic3A7SW50ZXImbmJzcDtBUyZuYnNwO0ludGVyb3BlcmFiaWxpdHkiLiZuYnNwO1Ro ZSZuYnNwO3BhcGVyJm5ic3A7aXMmbmJzcDtsb25nLCZuYnNwO2J1dCZuYnNwO0kmbmJzcDtlbmNv dXJhZ2UmbmJzcDt5b3UmbmJzcDt0byZuYnNwO2xvb2smbmJzcDthdCZuYnNwO2l0LiZuYnNwO1Rv Jm5ic3A7ZW5jb3VyYWdlJm5ic3A7eW91LCZuYnNwO2hlcmUmbmJzcDthcmUmbmJzcDthJm5ic3A7 ZmV3Jm5ic3A7ZXhjZXJwdHMmbmJzcDtmcm9tJm5ic3A7dGhlJm5ic3A7Y29uY2x1c2lvbjo8YnI+ PGJyPiJ3ZSZuYnNwO3RoaW5rJm5ic3A7dGhhdCZuYnNwO3doYXQmbmJzcDt3ZSZuYnNwO2xpc3Rl ZCZuYnNwO2FzJm5ic3A7YnVncyZuYnNwO3NvbWV0aW1lcyZuYnNwO2lzJm5ic3A7YSZuYnNwO3Jl c3VsdCZuYnNwO29mJm5ic3A7dW5jbGVhciZuYnNwO3NlY3Rpb25zJm5ic3A7YW5kJm5ic3A7ZGVm aW5pdGlvbnMmbmJzcDtpbiZuYnNwO1JGQyZuYnNwOzU1NzUiPGJyPjxicj4iV2l0aCZuYnNwO3Ro aXMmbmJzcDt1cGRhdGUmbmJzcDt3ZSZuYnNwO3RoaW5rJm5ic3A7dGhhdCZuYnNwO2EmbmJzcDtw cm9wZXImbmJzcDtpbnRlcm9wZXJhYmxlJm5ic3A7aW1wbGVtZW50YXRpb24mbmJzcDtzaG91bGQm bmJzcDtiZSZuYnNwO3Bvc3NpYmxlJm5ic3A7YW5kJm5ic3A7dW5hbWJpZ3VvdXMmbmJzcDtzZWN0 aW9ucyZuYnNwO2hhdmUmbmJzcDtiZWVuJm5ic3A7aW1wcm92ZWQiPGJyPjxicj5hbmQmbmJzcDtw ZXJoYXBzJm5ic3A7bW9zdCZuYnNwO21vdGl2YXRpb25hbCZuYnNwO3RvJm5ic3A7dGhlJm5ic3A7 V0c6PGJyPjxicj4iR2l2ZW4mbmJzcDt0aGUmbmJzcDtjdXJyZW50Jm5ic3A7YnVncywmbmJzcDtp bnRlcm9wZXJhYmlsaXR5Jm5ic3A7aXNzdWVzJm5ic3A7YW5kJm5ic3A7bWlzc2luZyZuYnNwO2Zl YXR1cmVzJm5ic3A7d2UmbmJzcDtkbyZuYnNwO25vdCZuYnNwO3JlY29tbWVuZCZuYnNwO2Zsb3cm bmJzcDtzcGVjaWZpY2F0aW9uJm5ic3A7QkdQJm5ic3A7c2Vzc2lvbnMmbmJzcDtiZXR3ZWVuJm5i c3A7ZGlmZmVyZW50Jm5ic3A7Y2FycmllcnMmbmJzcDtb4oCmXSZuYnNwO0ludmFsaWQmbmJzcDtm bG93Jm5ic3A7c3BlY2lmaWNhdGlvbiZuYnNwO05MUklzJm5ic3A7b3ImbmJzcDthY3Rpb24mbmJz cDtmaWx0ZXJzJm5ic3A7aGF2ZSZuYnNwO3RoZSZuYnNwO3BvdGVudGlhbCZuYnNwO3RvJm5ic3A7 cmVtb3RlbHkmbmJzcDt0cmlnZ2VyJm5ic3A7YSZuYnNwO2NvbXBsZXRlJm5ic3A7bmV0d29yayZu YnNwO2ZhaWx1cmUuIjxicj48YnI+SWYmbmJzcDt5b3UmbmJzcDtkbyZuYnNwO05PVCZuYnNwO3N1 cHBvcnQmbmJzcDthZG9wdGluZyZuYnNwO3RoaXMmbmJzcDt3b3JrLCZuYnNwO2l0Jm5ic3A7d291 bGQmbmJzcDtiZSZuYnNwO2ludGVyZXN0aW5nJm5ic3A7dG8mbmJzcDtoZWFyJm5ic3A7d2h5LiZu YnNwO0ZvciZuYnNwO2V4YW1wbGUsJm5ic3A7ZG8mbmJzcDt5b3UmbmJzcDt0aGluayZuYnNwO1JG QyZuYnNwOzU1NzUmbmJzcDtpcyZuYnNwO2ZpbmUmbmJzcDthcyZuYnNwO2l0Jm5ic3A7aXMsJm5i c3A7YW5kJm5ic3A7aWYmbmJzcDtzbywmbmJzcDt3aHkmbmJzcDsoY29uc2lkZXJpbmcmbmJzcDt0 aGUmbmJzcDtpc3N1ZXMmbmJzcDtyYWlzZWQmbmJzcDtpbiZuYnNwO3RoZSZuYnNwO3BhcGVyJm5i c3A7YW5kJm5ic3A7b24mbmJzcDt0aGUmbmJzcDtsaXN0KS4mbmJzcDtPZiZuYnNwO2NvdXJzZSwm bmJzcDtpdCZuYnNwO2lzJm5ic3A7bm90Jm5ic3A7SURSJ3MmbmJzcDtqb2ImbmJzcDt0byZuYnNw O2RvY3VtZW50Jm5ic3A7YW5kJm5ic3A7Zml4Jm5ic3A7aW1wbGVtZW50YXRpb24mbmJzcDtidWdz LiZuYnNwO0J1dCZuYnNwO2l0Jm5ic3A7aXMmbmJzcDsqZXhhY3RseSombmJzcDtvdXImbmJzcDtq b2ImbmJzcDt0byZuYnNwO2ZpeCZuYnNwO3RoZSZuYnNwO3NwZWMmbmJzcDtpZiZuYnNwO2l0J3Mm bmJzcDthbWJpZ3VvdXMmbmJzcDthbmQmbmJzcDt0aGF0Jm5ic3A7YW1iaWd1aXR5Jm5ic3A7bGVh ZHMmbmJzcDt0byZuYnNwO2ludGVyb3BlcmFiaWxpdHkmbmJzcDtpc3N1ZXMuPGJyPjxicj5JZiZu YnNwO3lvdSZuYnNwO2RvJm5ic3A7c3VwcG9ydCZuYnNwO2Fkb3B0aW5nJm5ic3A7dGhlJm5ic3A7 d29yaywmbmJzcDtwbGVhc2UmbmJzcDtyZW1lbWJlciZuYnNwO3RvJm5ic3A7c2F5Jm5ic3A7c28m bmJzcDtvbiZuYnNwO3RoZSZuYnNwO2xpc3QmbmJzcDvigJQmbmJzcDt3ZSZuYnNwO2Nhbid0Jm5i c3A7ZGVjbGFyZSZuYnNwO2NvbnNlbnN1cyZuYnNwO2Jhc2VkJm5ic3A7b24mbmJzcDtzaWxlbmNl Ljxicj48YnI+VGhhbmtzLDxicj48YnI+4oCUSm9objxicj48YnI+77yeJm5ic3A7T24mbmJzcDtK YW4mbmJzcDsyMSwmbmJzcDsyMDE3LCZuYnNwO2F0Jm5ic3A7MTA6MDMmbmJzcDtBTSwmbmJzcDtK b2huJm5ic3A7Ry4mbmJzcDtTY3VkZGVyJm5ic3A777ycamdzQGp1bmlwZXIubmV077yeJm5ic3A7 d3JvdGU6PGJyPu+8niZuYnNwOzxicj7vvJ4mbmJzcDtIaSZuYnNwO0FsbCw8YnI+77yeJm5ic3A7 PGJyPu+8niZuYnNwO1RoZSZuYnNwO2F1dGhvcnMmbmJzcDtoYXZlJm5ic3A7cmVxdWVzdGVkJm5i c3A7SURSJm5ic3A7d29ya2luZyZuYnNwO2dyb3VwJm5ic3A7YWRvcHRpb24mbmJzcDtvZiZuYnNw O2RyYWZ0LWhyLWlkci1yZmM1NTc1YmlzLTAyJm5ic3A7IkRpc3NlbWluYXRpb24mbmJzcDtvZiZu YnNwO0Zsb3cmbmJzcDtTcGVjaWZpY2F0aW9uJm5ic3A7UnVsZXMiLiZuYnNwO1BsZWFzZSZuYnNw O3NlbmQmbmJzcDt5b3VyJm5ic3A7Y29tbWVudHMmbmJzcDt0byZuYnNwO3RoZSZuYnNwO2xpc3Qu PGJyPu+8niZuYnNwOzxicj7vvJ4mbmJzcDtUaGlzJm5ic3A7YWRvcHRpb24mbmJzcDtjYWxsJm5i c3A7d2lsbCZuYnNwO2NvbmNsdWRlJm5ic3A7b24mbmJzcDtNb25kYXksJm5ic3A7RmVicnVhcnkm bmJzcDs2Ljxicj7vvJ4mbmJzcDs8YnI+77yeJm5ic3A7VGhhbmtzLDxicj7vvJ4mbmJzcDs8YnI+ 77yeJm5ic3A74oCUSm9objxicj7vvJ4mbmJzcDtfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj7vvJ4mbmJzcDtJZHImbmJzcDttYWlsaW5nJm5ic3A7bGlz dDxicj7vvJ4mbmJzcDtJZHJAaWV0Zi5vcmc8YnI+77yeJm5ic3A7aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pZHI8YnI+PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPklkciZuYnNwO21haWxpbmcmbmJzcDtsaXN0PGJyPklk ckBpZXRmLm9yZzxicj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcjxi cj48L2Rpdj48cD48YnI+PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjxwPjxicj48L3A+IDwv ZGl2Pg== --=====_003_next=====-- --=====_002_next=====-- --=====_001_next=====-- From nobody Mon Feb 6 07:06:11 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 5426C129E1E for ; Mon, 6 Feb 2017 07:06:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, 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] 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 fonJgfzt8OZL for ; Mon, 6 Feb 2017 07:06:07 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 345E7129421 for ; Mon, 6 Feb 2017 07:06:06 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DFX81724; Mon, 06 Feb 2017 15:06:03 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 6 Feb 2017 15:06:01 +0000 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.133]) by SJCEML701-CHM.china.huawei.com ([169.254.3.132]) with mapi id 14.03.0235.001; Mon, 6 Feb 2017 07:06:00 -0800 From: Linda Dunbar To: "zhang.zheng@zte.com.cn" , "jgs@juniper.net" Thread-Topic: [Idr] WG adoption call for draft-hr-idr-rfc5575bis-02 "Dissemination of Flow Specification Rules" Thread-Index: AQHSgFZebRk7H2o63kWVakGmNML5RaFcFE6g Date: Mon, 6 Feb 2017 15:05:59 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F65923E00E@SJCEML702-CHM.china.huawei.com> References: 36E285C0-C716-437A-806D-A453273146DD@juniper.net, 1D651738-BCED-4F25-88B5-5257871697DA@juniper.net <201702061651394752150@zte.com.cn> In-Reply-To: <201702061651394752150@zte.com.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.158.164] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F65923E00ESJCEML702CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.589890DC.0068, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.133, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 02f50d24253fb5940cb5358b8724cdb0 Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] WG adoption call for draft-hr-idr-rfc5575bis-02 "Dissemination of Flow Specification Rules" X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 15:06:10 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F65923E00ESJCEML702CHMchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VwcG9ydCwNCg0KDQoNCkxpbmRhIER1bmJhcg0KDQoNCuWOn+Wni+mCruS7tg0K5Y+R5Lu25Lq6 77yaIO+8nGpnc0BqdW5pcGVyLm5ldO+8njsNCuaUtuS7tuS6uu+8miDvvJxpZHJAaWV0Zi5vcmfv vJ47DQrml6Ug5pyfIO+8mjIwMTflubQwMuaciDAy5pelIDAwOjQxDQrkuLsg6aKYIO+8mlJlOiBb SWRyXSBXRyBhZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1oci1pZHItcmZjNTU3NWJpcy0wMiAiRGlz c2VtaW5hdGlvbiBvZiBGbG93IFNwZWNpZmljYXRpb24gUnVsZXMiDQoNCg0KSGkgQWxsLA0KDQpS ZW1pbmRlciwgdGhpcyBjYWxsIGZvciBhZG9wdGlvbiBpcyBnb2luZyBvbiBhbmQgd2lsbCBlbmQg aW4gZml2ZSBkYXlzLiBTbyBmYXIsIHRoZSBvbmx5IHJlcGx5IGhhcyBiZWVuIGZyb20gQ2hyaXN0 b3BoICh0aGFua3MhKSB3aXRoIGEgcG9pbnRlciB0byBoaXMgcGFwZXIgIkJHUCBGbG93IFNwZWNp ZmljYXRpb24gTXVsdGkgVmVuZG9yIGFuZCBJbnRlciBBUyBJbnRlcm9wZXJhYmlsaXR5Ii4gVGhl IHBhcGVyIGlzIGxvbmcsIGJ1dCBJIGVuY291cmFnZSB5b3UgdG8gbG9vayBhdCBpdC4gVG8gZW5j b3VyYWdlIHlvdSwgaGVyZSBhcmUgYSBmZXcgZXhjZXJwdHMgZnJvbSB0aGUgY29uY2x1c2lvbjoN Cg0KIndlIHRoaW5rIHRoYXQgd2hhdCB3ZSBsaXN0ZWQgYXMgYnVncyBzb21ldGltZXMgaXMgYSBy ZXN1bHQgb2YgdW5jbGVhciBzZWN0aW9ucyBhbmQgZGVmaW5pdGlvbnMgaW4gUkZDIDU1NzUiDQoN CiJXaXRoIHRoaXMgdXBkYXRlIHdlIHRoaW5rIHRoYXQgYSBwcm9wZXIgaW50ZXJvcGVyYWJsZSBp bXBsZW1lbnRhdGlvbiBzaG91bGQgYmUgcG9zc2libGUgYW5kIHVuYW1iaWd1b3VzIHNlY3Rpb25z IGhhdmUgYmVlbiBpbXByb3ZlZCINCg0KYW5kIHBlcmhhcHMgbW9zdCBtb3RpdmF0aW9uYWwgdG8g dGhlIFdHOg0KDQoiR2l2ZW4gdGhlIGN1cnJlbnQgYnVncywgaW50ZXJvcGVyYWJpbGl0eSBpc3N1 ZXMgYW5kIG1pc3NpbmcgZmVhdHVyZXMgd2UgZG8gbm90IHJlY29tbWVuZCBmbG93IHNwZWNpZmlj YXRpb24gQkdQIHNlc3Npb25zIGJldHdlZW4gZGlmZmVyZW50IGNhcnJpZXJzIFvigKZdIEludmFs aWQgZmxvdyBzcGVjaWZpY2F0aW9uIE5MUklzIG9yIGFjdGlvbiBmaWx0ZXJzIGhhdmUgdGhlIHBv dGVudGlhbCB0byByZW1vdGVseSB0cmlnZ2VyIGEgY29tcGxldGUgbmV0d29yayBmYWlsdXJlLiIN Cg0KSWYgeW91IGRvIE5PVCBzdXBwb3J0IGFkb3B0aW5nIHRoaXMgd29yaywgaXQgd291bGQgYmUg aW50ZXJlc3RpbmcgdG8gaGVhciB3aHkuIEZvciBleGFtcGxlLCBkbyB5b3UgdGhpbmsgUkZDIDU1 NzUgaXMgZmluZSBhcyBpdCBpcywgYW5kIGlmIHNvLCB3aHkgKGNvbnNpZGVyaW5nIHRoZSBpc3N1 ZXMgcmFpc2VkIGluIHRoZSBwYXBlciBhbmQgb24gdGhlIGxpc3QpLiBPZiBjb3Vyc2UsIGl0IGlz IG5vdCBJRFIncyBqb2IgdG8gZG9jdW1lbnQgYW5kIGZpeCBpbXBsZW1lbnRhdGlvbiBidWdzLiBC dXQgaXQgaXMgKmV4YWN0bHkqIG91ciBqb2IgdG8gZml4IHRoZSBzcGVjIGlmIGl0J3MgYW1iaWd1 b3VzIGFuZCB0aGF0IGFtYmlndWl0eSBsZWFkcyB0byBpbnRlcm9wZXJhYmlsaXR5IGlzc3Vlcy4N Cg0KSWYgeW91IGRvIHN1cHBvcnQgYWRvcHRpbmcgdGhlIHdvcmssIHBsZWFzZSByZW1lbWJlciB0 byBzYXkgc28gb24gdGhlIGxpc3Qg4oCUIHdlIGNhbid0IGRlY2xhcmUgY29uc2Vuc3VzIGJhc2Vk IG9uIHNpbGVuY2UuDQoNClRoYW5rcywNCg0K4oCUSm9obg0KDQrvvJ4gT24gSmFuIDIxLCAyMDE3 LCBhdCAxMDowMyBBTSwgSm9obiBHLiBTY3VkZGVyIO+8nGpnc0BqdW5pcGVyLm5ldO+8niB3cm90 ZToNCu+8ng0K77yeIEhpIEFsbCwNCu+8ng0K77yeIFRoZSBhdXRob3JzIGhhdmUgcmVxdWVzdGVk IElEUiB3b3JraW5nIGdyb3VwIGFkb3B0aW9uIG9mIGRyYWZ0LWhyLWlkci1yZmM1NTc1YmlzLTAy ICJEaXNzZW1pbmF0aW9uIG9mIEZsb3cgU3BlY2lmaWNhdGlvbiBSdWxlcyIuIFBsZWFzZSBzZW5k IHlvdXIgY29tbWVudHMgdG8gdGhlIGxpc3QuDQrvvJ4NCu+8niBUaGlzIGFkb3B0aW9uIGNhbGwg d2lsbCBjb25jbHVkZSBvbiBNb25kYXksIEZlYnJ1YXJ5IDYuDQrvvJ4NCu+8niBUaGFua3MsDQrv vJ4NCu+8niDigJRKb2huDQrvvJ4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCu+8niBJZHIgbWFpbGluZyBsaXN0DQrvvJ4gSWRyQGlldGYub3JnPG1haWx0 bzpJZHJAaWV0Zi5vcmc+DQrvvJ4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9pZHINCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CklkciBtYWlsaW5nIGxpc3QNCklkckBpZXRmLm9yZzxtYWlsdG86SWRyQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHINCg0KDQoNCg0K --_000_4A95BA014132FF49AE685FAB4B9F17F65923E00ESJCEML702CHMchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ow0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uenJlYWR1c2VybmFtZQ0KCXttc28tc3R5bGUt bmFtZTp6cmVhZHVzZXJuYW1lO30NCnNwYW4uenJlYWR0aXRsZQ0KCXttc28tc3R5bGUtbmFtZTp6 cmVhZHRpdGxlO30NCnAuemhpc3Rvcnljb250ZW50LCBsaS56aGlzdG9yeWNvbnRlbnQsIGRpdi56 aGlzdG9yeWNvbnRlbnQNCgl7bXNvLXN0eWxlLW5hbWU6emhpc3Rvcnljb250ZW50Ow0KCW1zby1t YXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBw dCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2 bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPGRpdj4NCjxwPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5TdXBwb3J0LCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkxpbmRhIER1bmJhcjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGln bjpjZW50ZXI7bGluZS1oZWlnaHQ6MjEuMHB0O2JhY2tncm91bmQ6I0UwRTVFOSI+DQo8c3BhbiBs YW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjojMTM4OEZGIj7ljp/l p4vpgq7ku7Y8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMxMzg4RkYiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXYgaWQ9Inp3cml0ZUhpc3RvcnlDb250YWluZXIiPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6I0Y1RjZGOCI+ PHN0cm9uZz48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+5Y+R 5Lu25Lq677yaPC9zcGFuPjwvc3Ryb25nPjxzcGFuIGNsYXNzPSJ6cmVhZHVzZXJuYW1lIj48c3Bh biBsYW5nPSJaSC1DTiI+DQo8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJ6cmVhZHVzZXJuYW1l Ij48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+77ycPC9zcGFu Pmpnc0BqdW5pcGVyLm5ldDwvc3Bhbj48c3BhbiBjbGFzcz0ienJlYWR1c2VybmFtZSI+PHNwYW4g bGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPu+8njwvc3Bhbj47PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6I0Y1RjZGOCI+PHN0cm9uZz48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9 ImZvbnQtZmFtaWx5OlNpbVN1biI+5pS25Lu25Lq677yaPC9zcGFuPjwvc3Ryb25nPjxzcGFuIGNs YXNzPSJ6cmVhZHVzZXJuYW1lIj48c3BhbiBsYW5nPSJaSC1DTiI+DQo8L3NwYW4+PC9zcGFuPjxz cGFuIGNsYXNzPSJ6cmVhZHVzZXJuYW1lIj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQt ZmFtaWx5OlNpbVN1biI+77ycPC9zcGFuPmlkckBpZXRmLm9yZzwvc3Bhbj48c3BhbiBjbGFzcz0i enJlYWR1c2VybmFtZSI+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LWZhbWlseTpTaW1T dW4iPu+8njwvc3Bhbj47PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6I0Y1RjZGOCI+PHN0cm9uZz48c3Bh biBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+5pelPC9zcGFuPjxzcGFu IGxhbmc9IlpILUNOIj4NCjwvc3Bhbj48L3N0cm9uZz48c3Ryb25nPjxzcGFuIGxhbmc9IlpILUNO IiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj7mnJ88L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04i Pg0KPC9zcGFuPjwvc3Ryb25nPjxzdHJvbmc+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250 LWZhbWlseTpTaW1TdW4iPu+8mjwvc3Bhbj48L3N0cm9uZz4yMDE3PHNwYW4gbGFuZz0iWkgtQ04i IHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPuW5tDwvc3Bhbj4wMjxzcGFuIGxhbmc9IlpILUNO IiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj7mnIg8L3NwYW4+MDI8c3BhbiBsYW5nPSJaSC1D TiIgc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+5pelPC9zcGFuPg0KIDAwOjQxPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDojRjVGNkY4Ij48c3Ryb25nPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1mYW1p bHk6U2ltU3VuIj7kuLs8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iPg0KPC9zcGFuPjwvc3Ryb25n PjxzdHJvbmc+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPumi mDwvc3Bhbj48c3BhbiBsYW5nPSJaSC1DTiI+DQo8L3NwYW4+PC9zdHJvbmc+PHN0cm9uZz48c3Bh biBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+77yaPC9zcGFuPlJlOiBb SWRyXSBXRyBhZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1oci1pZHItcmZjNTU3NWJpcy0wMiAmcXVv dDtEaXNzZW1pbmF0aW9uIG9mIEZsb3cgU3BlY2lmaWNhdGlvbiBSdWxlcyZxdW90Ozwvc3Ryb25n PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJ6aGlzdG9yeWNvbnRl bnQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhp Jm5ic3A7QWxsLDxicj4NCjxicj4NClJlbWluZGVyLCZuYnNwO3RoaXMmbmJzcDtjYWxsJm5ic3A7 Zm9yJm5ic3A7YWRvcHRpb24mbmJzcDtpcyZuYnNwO2dvaW5nJm5ic3A7b24mbmJzcDthbmQmbmJz cDt3aWxsJm5ic3A7ZW5kJm5ic3A7aW4mbmJzcDtmaXZlJm5ic3A7ZGF5cy4mbmJzcDtTbyZuYnNw O2ZhciwmbmJzcDt0aGUmbmJzcDtvbmx5Jm5ic3A7cmVwbHkmbmJzcDtoYXMmbmJzcDtiZWVuJm5i c3A7ZnJvbSZuYnNwO0NocmlzdG9waCZuYnNwOyh0aGFua3MhKSZuYnNwO3dpdGgmbmJzcDthJm5i c3A7cG9pbnRlciZuYnNwO3RvJm5ic3A7aGlzJm5ic3A7cGFwZXImbmJzcDsmcXVvdDtCR1AmbmJz cDtGbG93Jm5ic3A7U3BlY2lmaWNhdGlvbiZuYnNwO011bHRpJm5ic3A7VmVuZG9yJm5ic3A7YW5k Jm5ic3A7SW50ZXImbmJzcDtBUyZuYnNwO0ludGVyb3BlcmFiaWxpdHkmcXVvdDsuJm5ic3A7VGhl Jm5ic3A7cGFwZXImbmJzcDtpcyZuYnNwO2xvbmcsJm5ic3A7YnV0Jm5ic3A7SSZuYnNwO2VuY291 cmFnZSZuYnNwO3lvdSZuYnNwO3RvJm5ic3A7bG9vayZuYnNwO2F0Jm5ic3A7aXQuJm5ic3A7VG8m bmJzcDtlbmNvdXJhZ2UmbmJzcDt5b3UsJm5ic3A7aGVyZSZuYnNwO2FyZSZuYnNwO2EmbmJzcDtm ZXcmbmJzcDtleGNlcnB0cyZuYnNwO2Zyb20mbmJzcDt0aGUmbmJzcDtjb25jbHVzaW9uOjxicj4N Cjxicj4NCiZxdW90O3dlJm5ic3A7dGhpbmsmbmJzcDt0aGF0Jm5ic3A7d2hhdCZuYnNwO3dlJm5i c3A7bGlzdGVkJm5ic3A7YXMmbmJzcDtidWdzJm5ic3A7c29tZXRpbWVzJm5ic3A7aXMmbmJzcDth Jm5ic3A7cmVzdWx0Jm5ic3A7b2YmbmJzcDt1bmNsZWFyJm5ic3A7c2VjdGlvbnMmbmJzcDthbmQm bmJzcDtkZWZpbml0aW9ucyZuYnNwO2luJm5ic3A7UkZDJm5ic3A7NTU3NSZxdW90Ozxicj4NCjxi cj4NCiZxdW90O1dpdGgmbmJzcDt0aGlzJm5ic3A7dXBkYXRlJm5ic3A7d2UmbmJzcDt0aGluayZu YnNwO3RoYXQmbmJzcDthJm5ic3A7cHJvcGVyJm5ic3A7aW50ZXJvcGVyYWJsZSZuYnNwO2ltcGxl bWVudGF0aW9uJm5ic3A7c2hvdWxkJm5ic3A7YmUmbmJzcDtwb3NzaWJsZSZuYnNwO2FuZCZuYnNw O3VuYW1iaWd1b3VzJm5ic3A7c2VjdGlvbnMmbmJzcDtoYXZlJm5ic3A7YmVlbiZuYnNwO2ltcHJv dmVkJnF1b3Q7PGJyPg0KPGJyPg0KYW5kJm5ic3A7cGVyaGFwcyZuYnNwO21vc3QmbmJzcDttb3Rp dmF0aW9uYWwmbmJzcDt0byZuYnNwO3RoZSZuYnNwO1dHOjxicj4NCjxicj4NCiZxdW90O0dpdmVu Jm5ic3A7dGhlJm5ic3A7Y3VycmVudCZuYnNwO2J1Z3MsJm5ic3A7aW50ZXJvcGVyYWJpbGl0eSZu YnNwO2lzc3VlcyZuYnNwO2FuZCZuYnNwO21pc3NpbmcmbmJzcDtmZWF0dXJlcyZuYnNwO3dlJm5i c3A7ZG8mbmJzcDtub3QmbmJzcDtyZWNvbW1lbmQmbmJzcDtmbG93Jm5ic3A7c3BlY2lmaWNhdGlv biZuYnNwO0JHUCZuYnNwO3Nlc3Npb25zJm5ic3A7YmV0d2VlbiZuYnNwO2RpZmZlcmVudCZuYnNw O2NhcnJpZXJzJm5ic3A7W+KApl0mbmJzcDtJbnZhbGlkJm5ic3A7ZmxvdyZuYnNwO3NwZWNpZmlj YXRpb24mbmJzcDtOTFJJcyZuYnNwO29yJm5ic3A7YWN0aW9uJm5ic3A7ZmlsdGVycyZuYnNwO2hh dmUmbmJzcDt0aGUmbmJzcDtwb3RlbnRpYWwmbmJzcDt0byZuYnNwO3JlbW90ZWx5Jm5ic3A7dHJp Z2dlciZuYnNwO2EmbmJzcDtjb21wbGV0ZSZuYnNwO25ldHdvcmsmbmJzcDtmYWlsdXJlLiZxdW90 Ozxicj4NCjxicj4NCklmJm5ic3A7eW91Jm5ic3A7ZG8mbmJzcDtOT1QmbmJzcDtzdXBwb3J0Jm5i c3A7YWRvcHRpbmcmbmJzcDt0aGlzJm5ic3A7d29yaywmbmJzcDtpdCZuYnNwO3dvdWxkJm5ic3A7 YmUmbmJzcDtpbnRlcmVzdGluZyZuYnNwO3RvJm5ic3A7aGVhciZuYnNwO3doeS4mbmJzcDtGb3Im bmJzcDtleGFtcGxlLCZuYnNwO2RvJm5ic3A7eW91Jm5ic3A7dGhpbmsmbmJzcDtSRkMmbmJzcDs1 NTc1Jm5ic3A7aXMmbmJzcDtmaW5lJm5ic3A7YXMmbmJzcDtpdCZuYnNwO2lzLCZuYnNwO2FuZCZu YnNwO2lmJm5ic3A7c28sJm5ic3A7d2h5Jm5ic3A7KGNvbnNpZGVyaW5nJm5ic3A7dGhlJm5ic3A7 aXNzdWVzJm5ic3A7cmFpc2VkJm5ic3A7aW4mbmJzcDt0aGUmbmJzcDtwYXBlciZuYnNwO2FuZCZu YnNwO29uJm5ic3A7dGhlJm5ic3A7bGlzdCkuJm5ic3A7T2YmbmJzcDtjb3Vyc2UsJm5ic3A7aXQm bmJzcDtpcyZuYnNwO25vdCZuYnNwO0lEUidzJm5ic3A7am9iJm5ic3A7dG8mbmJzcDtkb2N1bWVu dCZuYnNwO2FuZCZuYnNwO2ZpeCZuYnNwO2ltcGxlbWVudGF0aW9uJm5ic3A7YnVncy4mbmJzcDtC dXQmbmJzcDtpdCZuYnNwO2lzJm5ic3A7KmV4YWN0bHkqJm5ic3A7b3VyJm5ic3A7am9iJm5ic3A7 dG8mbmJzcDtmaXgmbmJzcDt0aGUmbmJzcDtzcGVjJm5ic3A7aWYmbmJzcDtpdCdzJm5ic3A7YW1i aWd1b3VzJm5ic3A7YW5kJm5ic3A7dGhhdCZuYnNwO2FtYmlndWl0eSZuYnNwO2xlYWRzJm5ic3A7 dG8mbmJzcDtpbnRlcm9wZXJhYmlsaXR5Jm5ic3A7aXNzdWVzLjxicj4NCjxicj4NCklmJm5ic3A7 eW91Jm5ic3A7ZG8mbmJzcDtzdXBwb3J0Jm5ic3A7YWRvcHRpbmcmbmJzcDt0aGUmbmJzcDt3b3Jr LCZuYnNwO3BsZWFzZSZuYnNwO3JlbWVtYmVyJm5ic3A7dG8mbmJzcDtzYXkmbmJzcDtzbyZuYnNw O29uJm5ic3A7dGhlJm5ic3A7bGlzdCZuYnNwO+KAlCZuYnNwO3dlJm5ic3A7Y2FuJ3QmbmJzcDtk ZWNsYXJlJm5ic3A7Y29uc2Vuc3VzJm5ic3A7YmFzZWQmbmJzcDtvbiZuYnNwO3NpbGVuY2UuPGJy Pg0KPGJyPg0KVGhhbmtzLDxicj4NCjxicj4NCuKAlEpvaG48YnI+DQo8YnI+DQo8c3BhbiBsYW5n PSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+77yePC9zcGFuPiZuYnNwO09uJm5i c3A7SmFuJm5ic3A7MjEsJm5ic3A7MjAxNywmbmJzcDthdCZuYnNwOzEwOjAzJm5ic3A7QU0sJm5i c3A7Sm9obiZuYnNwO0cuJm5ic3A7U2N1ZGRlciZuYnNwOzxzcGFuIGxhbmc9IlpILUNOIiBzdHls ZT0iZm9udC1mYW1pbHk6U2ltU3VuIj7vvJw8L3NwYW4+amdzQGp1bmlwZXIubmV0PHNwYW4gbGFu Zz0iWkgtQ04iIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPu+8njwvc3Bhbj4mbmJzcDt3cm90 ZTo8YnI+DQo8c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+77ye PC9zcGFuPiZuYnNwOzxicj4NCjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6 U2ltU3VuIj7vvJ48L3NwYW4+Jm5ic3A7SGkmbmJzcDtBbGwsPGJyPg0KPHNwYW4gbGFuZz0iWkgt Q04iIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPu+8njwvc3Bhbj4mbmJzcDs8YnI+DQo8c3Bh biBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+77yePC9zcGFuPiZuYnNw O1RoZSZuYnNwO2F1dGhvcnMmbmJzcDtoYXZlJm5ic3A7cmVxdWVzdGVkJm5ic3A7SURSJm5ic3A7 d29ya2luZyZuYnNwO2dyb3VwJm5ic3A7YWRvcHRpb24mbmJzcDtvZiZuYnNwO2RyYWZ0LWhyLWlk ci1yZmM1NTc1YmlzLTAyJm5ic3A7JnF1b3Q7RGlzc2VtaW5hdGlvbiZuYnNwO29mJm5ic3A7Rmxv dyZuYnNwO1NwZWNpZmljYXRpb24mbmJzcDtSdWxlcyZxdW90Oy4mbmJzcDtQbGVhc2UmbmJzcDtz ZW5kJm5ic3A7eW91ciZuYnNwO2NvbW1lbnRzJm5ic3A7dG8mbmJzcDt0aGUmbmJzcDtsaXN0Ljxi cj4NCjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj7vvJ48L3Nw YW4+Jm5ic3A7PGJyPg0KPHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LWZhbWlseTpTaW1T dW4iPu+8njwvc3Bhbj4mbmJzcDtUaGlzJm5ic3A7YWRvcHRpb24mbmJzcDtjYWxsJm5ic3A7d2ls bCZuYnNwO2NvbmNsdWRlJm5ic3A7b24mbmJzcDtNb25kYXksJm5ic3A7RmVicnVhcnkmbmJzcDs2 Ljxicj4NCjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj7vvJ48 L3NwYW4+Jm5ic3A7PGJyPg0KPHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LWZhbWlseTpT aW1TdW4iPu+8njwvc3Bhbj4mbmJzcDtUaGFua3MsPGJyPg0KPHNwYW4gbGFuZz0iWkgtQ04iIHN0 eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPu+8njwvc3Bhbj4mbmJzcDs8YnI+DQo8c3BhbiBsYW5n PSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+77yePC9zcGFuPiZuYnNwO+KAlEpv aG48YnI+DQo8c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+77ye PC9zcGFuPiZuYnNwO19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KPHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPu+8 njwvc3Bhbj4mbmJzcDtJZHImbmJzcDttYWlsaW5nJm5ic3A7bGlzdDxicj4NCjxzcGFuIGxhbmc9 IlpILUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj7vvJ48L3NwYW4+Jm5ic3A7PGEgaHJl Zj0ibWFpbHRvOklkckBpZXRmLm9yZyI+SWRyQGlldGYub3JnPC9hPjxicj4NCjxzcGFuIGxhbmc9 IlpILUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj7vvJ48L3NwYW4+Jm5ic3A7PGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHIiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyPC9hPjxicj4NCjxicj4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KSWRyJm5ic3A7bWFpbGlu ZyZuYnNwO2xpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SWRyQGlldGYub3JnIj5JZHJAaWV0Zi5v cmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9pZHIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyPC9hPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHA+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_4A95BA014132FF49AE685FAB4B9F17F65923E00ESJCEML702CHMchi_-- From nobody Mon Feb 6 07:07: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 535BF129E2A for ; Mon, 6 Feb 2017 07:07:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 BjtQGE18k6e8 for ; Mon, 6 Feb 2017 07:07:00 -0800 (PST) Received: from relais-inet.orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E69EC129E28 for ; Mon, 6 Feb 2017 07:06:59 -0800 (PST) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 6B7C960444; Mon, 6 Feb 2017 16:06:58 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.32]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 514A6180066; Mon, 6 Feb 2017 16:06:58 +0100 (CET) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM32.corporate.adroot.infra.ftgroup ([fe80::8924:188:2124:a046%19]) with mapi id 14.03.0319.002; Mon, 6 Feb 2017 16:06:57 +0100 From: To: "Alvaro Retana (aretana)" Thread-Topic: [Idr] 2 week WG LC for draft-ietf-custom-decision (4/20 to 5/4/2015) Thread-Index: AQHQfOJEbzqBqbwli0WLinaFdrSzRp5/NkAAgCBzp+CAALACAIAAziXggrqjygCABEjCYA== Date: Mon, 6 Feb 2017 15:06:57 +0000 Message-ID: <9107_1486393618_58989112_9107_17700_1_53C29892C857584299CBF5D05346208A1ED3A87C@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <015e01d07ba1$0042bff0$00c83fd0$@ndzh.com> <25797_1429696420_55376FA4_25797_3139_1_53C29892C857584299CBF5D05346208A0EBAA545@PEXCVZYM11.corporate.adroot.infra.ftgroup> <30646_1447691076_564A0344_30646_2291_1_53C29892C857584299CBF5D05346208A0F6BC240@OPEXCLILM21.corporate.adroot.infra.ftgroup> <9781_1447749309_564AE6BD_9781_1504_1_53C29892C857584299CBF5D05346208A0F6BD227@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.3] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A1ED3A87COPEXCLILM21corp_" MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" , Susan Hares Subject: Re: [Idr] 2 week WG LC for draft-ietf-custom-decision (4/20 to 5/4/2015) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 15:07:02 -0000 --_000_53C29892C857584299CBF5D05346208A1ED3A87COPEXCLILM21corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWx2YXJvLA0KDQpUaGFua3MgZm9yIHlvdXIgYW5zd2VyIGFuZCBmb3IgdGhlIHVwZGF0ZWQg ZHJhZnQuDQoNCkkgY2FuIGxpdmUgd2l0aCB0aGUgY3VycmVudCB0ZXh0LiBZZXQsIHN0cmljdG8g c2Vuc3VzOg0KLSB0aGUgc2Vjb25kIHNlbnRlbmNlIG9ubHkgYXBwbGllcyB0byBjb21tdW5pdGll cyByZWNlaXZlZCBvdmVyIEVCR1AsIHdoaWNoIGRvZXMgbm90IGFkZHJlc3MgdGhlIGNhc2Ugd2hl cmUgdGhpcyBBU0JSIGRvIG5vdCBzdXBwb3J0IENvc3QgIENvbW11bml0aWVzDQotIHRoZSBmaXJz dCBzZW50ZW5jZSBvbmx5IHRhbGtzIGFib3V0IOKAnHByb3BhZ2F0aW9u4oCdLCBub3Qg4oCcdXNl IGR1cmluZyB0aGUgRGVjaXNpb24gUHJvY2Vzc+KAnS4NCg0KT24gbXkgc2lkZSwgSeKAmWQgcHJv cG9zZQ0KT0xEOiB0aGUgcHJvcGFnYXRpb24gb2YgQ29zdCBDb21tdW5pdGllcyBNVVNUIGJlIGRp c2FibGVkIGJ5IGRlZmF1bHQNCk5FVzogdGhlIHVzZSBvZiBDb3N0IENvbW11bml0aWVzIE1VU1Qg YmUgZGlzYWJsZWQgYnkgZGVmYXVsdA0KDQpOb3RlIHRoYXQgSSByZW1vdmVkIOKAnHByb3BhZ2F0 aW9u4oCdIGFzLCBpZiB0aGUgZ29hbCBpcyB0byBtaW5pbWl6ZSB0aGUgcm91dGluZyBsb29wcywg cmVtb3ZpbmcgQ29zdCBDb21tdW5pdHkgZHVyaW5nIGlCR1AgcHJvcGFnYXRpb24gaXMgZGViYXRh YmxlLCBhcyBzb21lIHVwc3RyZWFtIChyZWxhdGVkIHRvIEJHUCBtZXNzYWdlIHByb3BhZ2F0aW9u KSBCR1Agc3BlYWtlciBtYXkgaGF2ZSBhbHJlYWR5IHVzZWQgdGhlIGNvc3QgY29tbXVuaXR5OyBo ZW5jZSByZW1vdmluZyBpdCBtYXkgYWxzbyBjcmVhdGUgbG9vcHMuIEhvd2V2ZXIsIGZlZWwgZnJl ZSB0byBhZGQgaXQgYmFjayBhcyBpbiBib3RoIGNhc2VzLCB3ZSByZWFsbHkgY2Fu4oCZdCBmaXgg dGhpcyBpc3N1ZSBvZiBpbmNvbnNpc3RlbnQgY29uZmlndXJhdGlvbi4NCg0KRllJIGEgdHlwbyAg IDpzLyBpdHMgb2VuIGZpZWxkLyBpdHMgb3duIGZpZWxkDQoNClRoYW5rcw0KLS1CcnVubw0KDQpG cm9tOiBBbHZhcm8gUmV0YW5hIChhcmV0YW5hKSBbbWFpbHRvOmFyZXRhbmFAY2lzY28uY29tXQ0K U2VudDogRnJpZGF5LCBGZWJydWFyeSAwMywgMjAxNyA5OjE3IFBNDQpUbzogREVDUkFFTkUgQnJ1 bm8gSU1UL09MTg0KQ2M6IGlkckBpZXRmLm9yZzsgU3VzYW4gSGFyZXMNClN1YmplY3Q6IFJlOiBb SWRyXSAyIHdlZWsgV0cgTEMgZm9yIGRyYWZ0LWlldGYtY3VzdG9tLWRlY2lzaW9uICg0LzIwIHRv IDUvNC8yMDE1KQ0KDQpCcnVubzoNCg0KSGkhDQoNCldlIGp1c3QgcmVmcmVzaGVkIHRoZSBkcmFm dOKApmFuZCAoSSB0aGluaykgY2xhcmlmaWVkIHlvdXIgcG9pbnQgYmVsb3cgaW4gdGhlIFNlY3Vy aXR5IENvbnNpZGVyYXRpb25zOg0KDQpTZWN0aW9uIDYuLCBwYXJhZ3JhcGggMjoNCk9MRDoNCg0K ICAgIFRvIG1pbmltaXplIHRoZSBwb3RlbnRpYWwgb2YgY3JlYXRpbmcgcm91dGluZyBsb29wcyAo U2VjdGlvbiA1KSBvcg0KICAgIG90aGVyd2lzZSBhZmZlY3RpbmcgdGhlIERlY2lzaW9uIFByb2Nl c3MgaW4gdW5pbnRlbmRlZCB3YXlzLCB0aGUNCiAgICBwcm9wYWdhdGlvbiBvZiBDb3N0IENvbW11 bml0aWVzIE1VU1QgYmUgZGlzYWJsZWQgYnkgZGVmYXVsdCBhbmQgTVVTVA0KICAgIGJlIGV4cGxp Y2l0bHkgZW5hYmxlZCBieSB0aGUgbmV0d29yayBhZG1pbmlzdHJhdG9yLiAgRnVydGhlcm1vcmUs IGFsbA0KICAgIHRyYW5zaXRpdmUgQ29zdCBDb21tdW5pdGllcyByZWNlaXZlZCBhY3Jvc3MgYW4g QXV0b25vbW91cyBTeXN0ZW0NCiAgICBib3VuZGFyeSB3aXRob3V0IGV4cGxpY2l0IGNvbmZpZ3Vy YXRpb24gTVVTVCBiZSBzdHJpcHBlZCBvZmYgdGhlIEJHUA0KICAgIHVwZGF0ZSwgYW5kIGlnbm9y ZWQgZHVyaW5nIHRoZSBEZWNpc2lvbiBQcm9jZXNzLg0KDQpORVc6DQoNCiAgICBUbyBtaW5pbWl6 ZSB0aGUgcG90ZW50aWFsIG9mIGNyZWF0aW5nIHJvdXRpbmcgbG9vcHMgKFNlY3Rpb24gNSkgb3IN CiAgICBvdGhlcndpc2UgYWZmZWN0aW5nIHRoZSBEZWNpc2lvbiBQcm9jZXNzIGluIHVuaW50ZW5k ZWQgd2F5cywgdGhlDQogICAgcHJvcGFnYXRpb24gb2YgQ29zdCBDb21tdW5pdGllcyBNVVNUIGJl IGRpc2FibGVkIGJ5IGRlZmF1bHQgYW5kIE1VU1QNCiAgICBiZSBleHBsaWNpdGx5IGVuYWJsZWQg YnkgdGhlIG5ldHdvcmsgYWRtaW5pc3RyYXRvci4gIEZ1cnRoZXJtb3JlLCBhbGwNCiAgICBDb3N0 IENvbW11bml0aWVzIHJlY2VpdmVkIGFjcm9zcyBhbiBBdXRvbm9tb3VzIFN5c3RlbSBib3VuZGFy eQ0KICAgIHdpdGhvdXQgZXhwbGljaXRseSBiZWluZyBlbmFibGVkIE1VU1QgYmUgc3RyaXBwZWQg b2ZmIHRoZSBCR1AgdXBkYXRlLA0KICAgIGFuZCBpZ25vcmVkIGR1cmluZyB0aGUgRGVjaXNpb24g UHJvY2Vzcy4NCg0KDQpUaGF0IGlzIHByb2JhYmx5IHRoZSBtYWluIHBhcnQsIGJ1dCB0aGVyZSBh cmUgb3RoZXIgY2hhbmdlcyByZXN1bHRpbmcgZnJvbSB5b3VyIGNvbW1lbnRzLiAgUGxlYXNlIHRh a2UgYSBsb29rIGF0IHRoZSBjb21wbGV0ZSBkaWZmOiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNk aWZmP3VybDE9ZHJhZnQtaWV0Zi1pZHItY3VzdG9tLWRlY2lzaW9uLTA3JnVybDI9ZHJhZnQtaWV0 Zi1pZHItY3VzdG9tLWRlY2lzaW9uLTA4DQoNCg0KVGhhbmtzIQ0KDQpBbHZhcm8uDQoNCk9uIDEx LzE3LzE1LCAzOjM1IEFNLCAiYnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTxtYWlsdG86YnJ1bm8u ZGVjcmFlbmVAb3JhbmdlLmNvbT4iIDxicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPG1haWx0bzpi cnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPj4gd3JvdGU6DQoNCk15IGNvbmNlcm4gaXMgZm9yIGFu IEFTIG5vdCB1c2luZyB0aGlzIGNvc3QgY29tbXVuaXR5Og0KYSkgY29tcGxpYW50IHJvdXRlcnMg d2lsbCwgYnkgZGVmYXVsdCwgbW9kaWZ5IHJvdXRlIHByZWZlcmVuY2UgYmFzZWQgb24gdGhlIGNv bW11bml0eQ0KYikgbm9uIGNvbXBsaWFudCByb3V0ZXJzIHdpbGwsIGJ5IGRlZmF1bHQsIGFjY2Vw dCB0aGlzIGNvbW11bml0eSBvdmVyIGVCR1Agc2Vzc2lvbnMuDQoNCmErYjogd2UgaGF2ZSBhbiBp c3N1ZSBhcyB1bnRydXN0ZWQgQVMgbWF5IGluZmx1ZW5jZSBteSByb3V0aW5nIHBvbGljeSBvciBj cmVhdGUgbG9vcHMuDQoNCldlIGFncmVlIHRoYXQgd2UgY2Fu4oCZdCBkbyBhbnl0aGluZyBhYm91 dCDigJxi4oCdLg0KU28gSSBhbSBhc2tpbmcgdG8gYWRkcmVzcyDigJxh4oCdIGJ5IGhhdmluZyBj b21wbGlhbnQgcm91dGVycyB0byBfbm90XyBjaGFuZ2Ugcm91dGUgcHJlZmVyZW5jZSBieSBkZWZh dWx0LiBpLmUuIE1VU1QgYmUgZXhwbGljaXRseSBjb25maWd1cmVkIHRvIGNoYW5nZSB0aGVpciBy b3V0ZSBwcmVmZXJlbmNlIGJhc2VkIG9uIHRoaXMgY29tbXVuaXR5Lg0KDQoKX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2Ug bWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3Jt YXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25j CnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9u LiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNp Z25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2Vz IGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBk J2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1l c3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVz c2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2 aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hv dWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0 aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90 aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50 cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVz c2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFu ayB5b3UuCgo= --_000_53C29892C857584299CBF5D05346208A1ED3A87COPEXCLILM21corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltYXJnaW46 MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNv LXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uZ3JhbWUNCgl7bXNvLXN0 eWxlLW5hbWU6Z3JhbWU7fQ0Kc3Bhbi5zcGVsbGUNCgl7bXNvLXN0eWxlLW5hbWU6c3BlbGxlO30N CnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDsNCglmb250LXdl aWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uUHJmb3JtYXRIVE1MQ2FyDQoJe21z by1zdHlsZS1uYW1lOiJQcsOpZm9ybWF0w6kgSFRNTCBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLDqWZvcm1hdMOpIEhUTUwiOw0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2 MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGJnY29sb3I9IndoaXRlIiBsYW5nPSJGUiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIEFsdmFybyw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5UaGFua3MgZm9yIHlvdXIgYW5zd2VyIGFuZCBmb3IgdGhlIHVwZGF0ZWQgZHJh ZnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgY2FuIGxpdmUgd2l0aCB0 aGUgY3VycmVudCB0ZXh0LiBZZXQsIHN0cmljdG8gc2Vuc3VzOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LSB0aGUgc2Vjb25kIHNlbnRlbmNlIG9ubHkgYXBwbGll cyB0byBjb21tdW5pdGllcyByZWNlaXZlZCBvdmVyIEVCR1AsIHdoaWNoIGRvZXMgbm90IGFkZHJl c3MgdGhlIGNhc2Ugd2hlcmUgdGhpcyBBU0JSIGRvIG5vdCBzdXBwb3J0IENvc3QgJm5ic3A7Q29t bXVuaXRpZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi0gdGhl IGZpcnN0IHNlbnRlbmNlIG9ubHkgdGFsa3MgYWJvdXQg4oCccHJvcGFnYXRpb27igJ0sIG5vdCDi gJx1c2UgZHVyaW5nIHRoZSBEZWNpc2lvbiBQcm9jZXNz4oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5PbiBteSBzaWRlLCBJ4oCZZCBwcm9wb3NlPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PTEQ6PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPnRoZSBwcm9wYWdhdGlvbiBvZiBDb3N0IENvbW11bml0aWVzIE1VU1QgYmUgZGlz YWJsZWQgYnkgZGVmYXVsdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+TkVXOiB0aGUgdXNlIG9mIENvc3QgQ29tbXVuaXRpZXMgTVVTVCBiZSBkaXNhYmxlZCBieSBk ZWZhdWx0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk5vdGUgdGhhdCBJIHJl bW92ZWQg4oCccHJvcGFnYXRpb27igJ0gYXMsIGlmIHRoZSBnb2FsIGlzIHRvIG1pbmltaXplIHRo ZSByb3V0aW5nIGxvb3BzLCByZW1vdmluZyBDb3N0IENvbW11bml0eSBkdXJpbmcgaUJHUCBwcm9w YWdhdGlvbiBpcyBkZWJhdGFibGUsDQogYXMgc29tZSB1cHN0cmVhbSAocmVsYXRlZCB0byBCR1Ag bWVzc2FnZSBwcm9wYWdhdGlvbikgQkdQIHNwZWFrZXIgbWF5IGhhdmUgYWxyZWFkeSB1c2VkIHRo ZSBjb3N0IGNvbW11bml0eTsgaGVuY2UgcmVtb3ZpbmcgaXQgbWF5IGFsc28gY3JlYXRlIGxvb3Bz LiBIb3dldmVyLCBmZWVsIGZyZWUgdG8gYWRkIGl0IGJhY2sgYXMgaW4gYm90aCBjYXNlcywgd2Ug cmVhbGx5IGNhbuKAmXQgZml4IHRoaXMgaXNzdWUgb2YgaW5jb25zaXN0ZW50IGNvbmZpZ3VyYXRp b24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZZSSBhIHR5cG8mbmJzcDsm bmJzcDsgOnMvPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4gaXRzIG9lbjwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiBmaWVsZDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+Lw0KIGl0cyBv d24gZmllbGQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tLUJydW5vPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBBbHZhcm8gUmV0 YW5hIChhcmV0YW5hKSBbbWFpbHRvOmFyZXRhbmFAY2lzY28uY29tXQ0KPGJyPg0KPGI+U2VudDo8 L2I+IEZyaWRheSwgRmVicnVhcnkgMDMsIDIwMTcgOToxNyBQTTxicj4NCjxiPlRvOjwvYj4gREVD UkFFTkUgQnJ1bm8gSU1UL09MTjxicj4NCjxiPkNjOjwvYj4gaWRyQGlldGYub3JnOyBTdXNhbiBI YXJlczxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0lkcl0gMiB3ZWVrIFdHIExDIGZvciBkcmFm dC1pZXRmLWN1c3RvbS1kZWNpc2lvbiAoNC8yMCB0byA1LzQvMjAxNSk8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5CcnVubzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5IaSE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5XZSBqdXN0IHJlZnJl c2hlZCB0aGUgZHJhZnTigKZhbmQgKEkgdGhpbmspIGNsYXJpZmllZCB5b3VyIHBvaW50IGJlbG93 IGluIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9uczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TZWN0aW9uIDYuLCBwYXJh Z3JhcGggMjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5PTEQ6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7IFRvIG1pbmltaXplIHRoZSBwb3RlbnRpYWwgb2YgY3JlYXRpbmcgcm91dGlu ZyBsb29wcyAoU2VjdGlvbiA1KSBvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyBvdGhlcndpc2UgYWZmZWN0aW5nIHRoZSBEZWNpc2lvbiBQcm9jZXNzIGlu IHVuaW50ZW5kZWQgd2F5cywgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHByb3BhZ2F0aW9uIG9mIENvc3QgQ29tbXVuaXRpZXMgTVVTVCBiZSBkaXNh YmxlZCBieSBkZWZhdWx0IGFuZCBNVVNUPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7IGJlIGV4cGxpY2l0bHkgZW5hYmxlZCBieSB0aGUgbmV0d29yayBhZG1p bmlzdHJhdG9yLiZuYnNwOyBGdXJ0aGVybW9yZSwgYWxsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRyYW5zaXRpdmUgQ29zdCBDb21tdW5pdGllcyByZWNl aXZlZCBhY3Jvc3MgYW4gQXV0b25vbW91cyBTeXN0ZW08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsgYm91bmRhcnkgd2l0aG91dCBleHBsaWNpdCBjb25maWd1 cmF0aW9uIE1VU1QgYmUgc3RyaXBwZWQgb2ZmIHRoZSBCR1A8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsgdXBkYXRlLCBhbmQgaWdub3JlZCBkdXJpbmcgdGhl IERlY2lzaW9uIFByb2Nlc3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+TkVXOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyBUbyBtaW5pbWl6ZSB0aGUgcG90ZW50aWFsIG9mIGNyZWF0aW5nIHJvdXRpbmcgbG9vcHMgKFNl Y3Rpb24gNSkgb3I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsgb3RoZXJ3aXNlIGFmZmVjdGluZyB0aGUgRGVjaXNpb24gUHJvY2VzcyBpbiB1bmludGVuZGVk IHdheXMsIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyBwcm9wYWdhdGlvbiBvZiBDb3N0IENvbW11bml0aWVzIE1VU1QgYmUgZGlzYWJsZWQgYnkgZGVm YXVsdCBhbmQgTVVTVDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOyBiZSBleHBsaWNpdGx5IGVuYWJsZWQgYnkgdGhlIG5ldHdvcmsgYWRtaW5pc3RyYXRvci4m bmJzcDsgRnVydGhlcm1vcmUsIGFsbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyBDb3N0IENvbW11bml0aWVzIHJlY2VpdmVkIGFjcm9zcyBhbiBBdXRvbm9t b3VzIFN5c3RlbSBib3VuZGFyeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyB3aXRob3V0IGV4cGxpY2l0bHkgYmVpbmcgZW5hYmxlZCBNVVNUIGJlIHN0cmlw cGVkIG9mZiB0aGUgQkdQIHVwZGF0ZSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsgYW5kIGlnbm9yZWQgZHVyaW5nIHRoZSBEZWNpc2lvbiBQcm9jZXNzLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoYXQgaXMgcHJvYmFi bHkgdGhlIG1haW4gcGFydCwgYnV0IHRoZXJlIGFyZSBvdGhlciBjaGFuZ2VzIHJlc3VsdGluZyBm cm9tIHlvdXIgY29tbWVudHMuJm5ic3A7IFBsZWFzZSB0YWtlIGEgbG9vayBhdCB0aGUgY29tcGxl dGUgZGlmZjoNCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMT1kcmFm dC1pZXRmLWlkci1jdXN0b20tZGVjaXNpb24tMDcmYW1wO3VybDI9ZHJhZnQtaWV0Zi1pZHItY3Vz dG9tLWRlY2lzaW9uLTA4Ij4NCmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMT1kcmFm dC1pZXRmLWlkci1jdXN0b20tZGVjaXNpb24tMDcmYW1wO3VybDI9ZHJhZnQtaWV0Zi1pZHItY3Vz dG9tLWRlY2lzaW9uLTA4PC9hPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+VGhhbmtzITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkFsdmFyby48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBjbSAwY20g MGNtIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdo dDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiAxMS8xNy8xNSwgMzozNSBBTSwgJnF1b3Q7PGEg aHJlZj0ibWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20iPmJydW5vLmRlY3JhZW5lQG9y YW5nZS5jb208L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YnJ1bm8uZGVjcmFlbmVAb3Jh bmdlLmNvbSI+YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7 b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk15IGNvbmNlcm4gaXMgZm9yIGFu IEFTIG5vdCB1c2luZyB0aGlzIGNvc3QgY29tbXVuaXR5Ojwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6IG5vcm1h bDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+YSk8c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9ImdyYW1lIj5jb21w bGlhbnQ8L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPnJvdXRlcnMgd2lsbCwgYnkgZGVmYXVsdCwgbW9kaWZ5IHJvdXRlDQogcHJlZmVyZW5jZSBi YXNlZCBvbiB0aGUgY29tbXVuaXR5PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1 dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5iKTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48c3BhbiBjbGFzcz0iZ3JhbWUiPm5vbjwvc3Bhbj48c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9InNw ZWxsZSI+Y29tcGxpYW50PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj5yb3V0ZXJzDQogd2lsbCwgYnkgZGVmYXVsdCwgYWNjZXB0IHRoaXMgY29t bXVuaXR5IG92ZXI8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PHNwYW4gY2xhc3M9InNwZWxsZSI+ZUJHUDwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+c2Vzc2lvbnMuPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczogbm9y bWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImZvbnQtdmFyaWFu dC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0 bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3Bh biBjbGFzcz0iZ3JhbWUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+YSYjNDM7PC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0ic3BlbGxlIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmI8 L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Og0KIHdlIGhhdmUgYW4gaXNzdWUgYXMgdW50cnVzdGVkIEFTIG1heSBpbmZs dWVuY2UgbXkgcm91dGluZyBwb2xpY3kgb3IgY3JlYXRlIGxvb3BzLjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6 IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJmb250LXZh cmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6 IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0K PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5X ZSBhZ3JlZSB0aGF0IHdlIGNhbuKAmXQgZG8gYW55dGhpbmcgYWJvdXQg4oCcYuKAnS48L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImZvbnQtdmFy aWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czog YXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNv IEkgYW0gYXNraW5nIHRvIGFkZHJlc3Mg4oCcYeKAnSBieSBoYXZpbmcgY29tcGxpYW50IHJvdXRl cnMgdG8gXzxpPm5vdDwvaT5fIGNoYW5nZSByb3V0ZSBwcmVmZXJlbmNlIGJ5IGRlZmF1bHQuPHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxzcGFuIGNsYXNz PSJncmFtZSI+aS5lPC9zcGFuPi4NCiBNVVNUIGJlIGV4cGxpY2l0bHkgY29uZmlndXJlZCB0byBj aGFuZ2UgdGhlaXIgcm91dGUgcHJlZmVyZW5jZSBiYXNlZCBvbiB0aGlzIGNvbW11bml0eS48L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93 czogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+ DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjwvZGl2Pg0KPFBSRT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBw ZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZp bGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBv dSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2Ug cGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0 cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9u aXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91 dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3Ug ZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNv bnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUg cHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9y IGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg ZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMg bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9y YW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwg Y2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KPC9QUkU+PC9ib2R5Pg0KPC9odG1sPg0K --_000_53C29892C857584299CBF5D05346208A1ED3A87COPEXCLILM21corp_-- From nobody Mon Feb 6 07:20: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 9F914129E52 for ; Mon, 6 Feb 2017 07:20:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, 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 jNsUjPnUtUm3 for ; Mon, 6 Feb 2017 07:20:20 -0800 (PST) Received: from mail-qk0-x243.google.com (mail-qk0-x243.google.com [IPv6:2607:f8b0:400d: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 35173129E2F for ; Mon, 6 Feb 2017 07:20:20 -0800 (PST) Received: by mail-qk0-x243.google.com with SMTP id e1so8914095qkh.1 for ; Mon, 06 Feb 2017 07:20:20 -0800 (PST) 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=CbrGahaloJ9zKyF7ed/PHPPev/EyUKFoqGcB8L5Ctgk=; b=kg8vOHffSqkiLkcOhsfSICsKoY0HcJfKfO8w6ALEyiXh8XyTUEnDMIN/l1xLkN1a/O I5sT7N6gfCPr/faLGvK6hygJ3Ny9hSJ5NV3tnmUU6GvQMt0fVNfBn2fPORlk7p6a4t/F rcnr1sod3Q1bg8VF6bmv+NcLN3OKM/7GPr//Pq9gvqNNHZvhMR0Uvj6we+6tj1519JR/ Ndc/Wagj2DKKsKUrkeQpZHVkzf6w30VPaLxKL+n2foaWQoiEPt0b/+KuhhjhBAgqDgcm ue+/MTxC6cejH9FswIuqbaFR9rLlfUo2twnxbCqQa7fSYDoln8F3WvoqcpWRSpIHQlyt np5Q== 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=CbrGahaloJ9zKyF7ed/PHPPev/EyUKFoqGcB8L5Ctgk=; b=KZg+uGrRVZ4QqpliG/a69BjuErTQSRr/iYDn1GQFtHPAj6bN8mud792ElAtRr/Yy3l ik7DiWX26vYkh/6RzOp4GHdDD4I0P63M/8IAJ9t0XSGbbqVusOnMaAZe01jivzmG+okQ jLd3KgJTrg8fdzMlNkcrsoXlU45VtkyX/hd2+sy/C1elKYm+elo5ipv/vqC7ffn42eEA bD/VnpW7pZzPHNCtrTiNromMPuMn1S5WLRyBjxSkHl3U77qNaUVcXU3igmQtQsFr7iMS he3Kt7/nQyVfFBwCX81/fx7UiNudMMW0tPsA3oNLwcC0XzqDCkAj4nkjktubiRDP6sLC insg== X-Gm-Message-State: AMke39lQtBCmcTlzQrBy3prL6TS/XEFIQcP6jSXcNd+Nn2fBo4qfJET9h2qcnEbd57HGwnQXKrQDFOh5ytGnTg== X-Received: by 10.55.43.149 with SMTP id r21mr10701564qkr.123.1486394419303; Mon, 06 Feb 2017 07:20:19 -0800 (PST) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.140.28.69 with HTTP; Mon, 6 Feb 2017 07:20:18 -0800 (PST) In-Reply-To: <9107_1486393618_58989112_9107_17700_1_53C29892C857584299CBF5D05346208A1ED3A87C@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <015e01d07ba1$0042bff0$00c83fd0$@ndzh.com> <25797_1429696420_55376FA4_25797_3139_1_53C29892C857584299CBF5D05346208A0EBAA545@PEXCVZYM11.corporate.adroot.infra.ftgroup> <30646_1447691076_564A0344_30646_2291_1_53C29892C857584299CBF5D05346208A0F6BC240@OPEXCLILM21.corporate.adroot.infra.ftgroup> <9781_1447749309_564AE6BD_9781_1504_1_53C29892C857584299CBF5D05346208A0F6BD227@OPEXCLILM21.corporate.adroot.infra.ftgroup> <9107_1486393618_58989112_9107_17700_1_53C29892C857584299CBF5D05346208A1ED3A87C@OPEXCLILM21.corporate.adroot.infra.ftgroup> From: Robert Raszuk Date: Mon, 6 Feb 2017 16:20:18 +0100 X-Google-Sender-Auth: XYFDOXFWkcPxeyN65pruwmbrhOU Message-ID: To: "bruno.decraene@orange.com" Content-Type: multipart/alternative; boundary=001a1146d1465bdd7c0547de2bae Archived-At: Cc: Susan Hares , "idr@ietf.org" Subject: Re: [Idr] 2 week WG LC for draft-ietf-custom-decision (4/20 to 5/4/2015) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 15:20:24 -0000 --001a1146d1465bdd7c0547de2bae Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Bruno, On my side, I=E2=80=99d propose > > OLD: the propagation of Cost Communities MUST be disabled by default > > NEW: the use of Cost Communities MUST be disabled by default > =E2=80=8BDo you really think it is safe to propagate =E2=80=8Binformation w= hich can completely overwrite Best Path without applying it locally ? If we are really to change this text how about this: NEW: The use of Cost Communities MUST be disabled by default. The propagation may occur by default only on those BGP speakers which do not set next hop self. =E2=80=8BCheers, R. =E2=80=8B --001a1146d1465bdd7c0547de2bae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Bruno,
<= br>

On my side= , I=E2=80=99d propose

OLD: the propagation of Cost Co= mmunities MUST be disabled by default

NEW: the u= se of Cost Communities MUST be disabled by default


=E2=80=8BDo you really th= ink it is safe to propagate =E2=80=8Binformation which can completely overw= rite Best Path without applying it locally ?=C2=A0
=
If we are really to change this text how about= this:=C2=A0

NEW: The = use of Cost Communities MUST be disabled by default. The propagation may oc= cur by default only on those BGP speakers which do not set next hop self.= =C2=A0

=E2=80=8BCheers,
R.
=E2=80=8B

--001a1146d1465bdd7c0547de2bae-- From nobody Mon Feb 6 07:51: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 ED5EB129E9A for ; Mon, 6 Feb 2017 07:51:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.619 X-Spam-Level: X-Spam-Status: No, score=-1.619 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 QqZD8N3y3eDv for ; Mon, 6 Feb 2017 07:51:12 -0800 (PST) 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 BE6A9129E89 for ; Mon, 6 Feb 2017 07:51:11 -0800 (PST) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 5928FC062E; Mon, 6 Feb 2017 16:51:10 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.58]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 1C852120055; Mon, 6 Feb 2017 16:51:10 +0100 (CET) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0319.002; Mon, 6 Feb 2017 16:51:09 +0100 From: To: Robert Raszuk Thread-Topic: [Idr] 2 week WG LC for draft-ietf-custom-decision (4/20 to 5/4/2015) Thread-Index: AQHSgIyGbzqBqbwli0WLinaFdrSzRqFcHl7g Date: Mon, 6 Feb 2017 15:51:09 +0000 Message-ID: <25903_1486396270_58989B6E_25903_18304_1_53C29892C857584299CBF5D05346208A1ED3AA24@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <015e01d07ba1$0042bff0$00c83fd0$@ndzh.com> <25797_1429696420_55376FA4_25797_3139_1_53C29892C857584299CBF5D05346208A0EBAA545@PEXCVZYM11.corporate.adroot.infra.ftgroup> <30646_1447691076_564A0344_30646_2291_1_53C29892C857584299CBF5D05346208A0F6BC240@OPEXCLILM21.corporate.adroot.infra.ftgroup> <9781_1447749309_564AE6BD_9781_1504_1_53C29892C857584299CBF5D05346208A0F6BD227@OPEXCLILM21.corporate.adroot.infra.ftgroup> <9107_1486393618_58989112_9107_17700_1_53C29892C857584299CBF5D05346208A1ED3A87C@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.3] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A1ED3AA24OPEXCLILM21corp_" MIME-Version: 1.0 Archived-At: Cc: Susan Hares , "idr@ietf.org" Subject: Re: [Idr] 2 week WG LC for draft-ietf-custom-decision (4/20 to 5/4/2015) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 15:51:13 -0000 --_000_53C29892C857584299CBF5D05346208A1ED3AA24OPEXCLILM21corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KDQpQbGVhc2Ugc2VlIGlubGluZSBbQnJ1bm9dDQoNCkZyb206IHJyYXN6dWtA Z21haWwuY29tIFttYWlsdG86cnJhc3p1a0BnbWFpbC5jb21dIE9uIEJlaGFsZiBPZiBSb2JlcnQg UmFzenVrDQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDA2LCAyMDE3IDQ6MjAgUE0NClRvOiBERUNS QUVORSBCcnVubyBJTVQvT0xODQpDYzogQWx2YXJvIFJldGFuYSAoYXJldGFuYSk7IGlkckBpZXRm Lm9yZzsgU3VzYW4gSGFyZXMNClN1YmplY3Q6IFJlOiBbSWRyXSAyIHdlZWsgV0cgTEMgZm9yIGRy YWZ0LWlldGYtY3VzdG9tLWRlY2lzaW9uICg0LzIwIHRvIDUvNC8yMDE1KQ0KDQpIaSBCcnVubywN Cg0KT24gbXkgc2lkZSwgSeKAmWQgcHJvcG9zZQ0KT0xEOiB0aGUgcHJvcGFnYXRpb24gb2YgQ29z dCBDb21tdW5pdGllcyBNVVNUIGJlIGRpc2FibGVkIGJ5IGRlZmF1bHQNCk5FVzogdGhlIHVzZSBv ZiBDb3N0IENvbW11bml0aWVzIE1VU1QgYmUgZGlzYWJsZWQgYnkgZGVmYXVsdA0KDQrigItEbyB5 b3UgcmVhbGx5IHRoaW5rIGl0IGlzIHNhZmUgdG8gcHJvcGFnYXRlIOKAi2luZm9ybWF0aW9uIHdo aWNoIGNhbiBjb21wbGV0ZWx5IG92ZXJ3cml0ZSBCZXN0IFBhdGggd2l0aG91dCBhcHBseWluZyBp dCBsb2NhbGx5ID8NCg0KW0JydW5vXQ0KMSkgSUlSQywgdGhpcyBpcyBleGFjdGx5IHdoYXQgdGhp cyBkb2N1bWVudCBkb2VzLCBmb3IgYWxsIEJHUCBzcGVha2VycyB3aGljaCBkbyBub3Qgc3VwcG9y dCB0aGUgY29zdC1jb21tdW5pdHkuDQoyKSBJ4oCZdmUgc2FpZCB0aGF0IGJvdGggY2hvaWNlcyBj YW4gbGVhZCB0byBmb3J3YXJkaW5nIGxvb3BzLiBXaGVyZSBkbyB5b3Ugc2VlIHRoYXQgSSBzYWlk IGl0IHdhcyBzYWZlPw0KDQoNCklmIHdlIGFyZSByZWFsbHkgdG8gY2hhbmdlIHRoaXMgdGV4dCBo b3cgYWJvdXQgdGhpczoNCg0KTkVXOiBUaGUgdXNlIG9mIENvc3QgQ29tbXVuaXRpZXMgTVVTVCBi ZSBkaXNhYmxlZCBieSBkZWZhdWx0LiBUaGUgcHJvcGFnYXRpb24gbWF5IG9jY3VyIGJ5IGRlZmF1 bHQgb25seSBvbiB0aG9zZSBCR1Agc3BlYWtlcnMgd2hpY2ggZG8gbm90IHNldCBuZXh0IGhvcCBz ZWxmLg0KW0JydW5vXSBJ4oCZbSBmaW5lIHdpdGggdGhlIGZpcnN0IHNlbnRlbmNlLg0KVGhlIHNl Y29uZCBzZW50ZW5jZSBpbnRyb2R1Y2VzIGEgYmVoYXZpb3Igd2hpY2ggaXMgcGVyIHJvdXRlIChy YXRoZXIgdGhhbiBwZXIgbm9kZSBjdXJyZW50bHkpLiBJIGRvbuKAmXQgcmVhbGx5IHNlZSBhIHN0 cm9uZyBlbm91Z2ggcmVhc29uIGZvciB0aGlzIGFkZGl0aW9uYWwgY29tcGxleGl0eS4gRXNwZWNp YWxseSBnaXZlbiB0aGF0IGFsbCBub24tY29tcGxpYW50IHJvdXRlciB3aWxsIHByb3BhZ2F0ZSBp dCBpbiBhbGwgY2FzZXMuDQoNCkNoZWVycywNCkJydW5vDQoNCg0K4oCLQ2hlZXJzLA0KUi4NCuKA iw0KDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBj b250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMg ZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVz IHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJl dXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFp bnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0 YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3Bv bnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmll LiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNv bmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3Rl ZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQg d2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGlu IGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2Ug YW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMg bm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQg b3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= --_000_53C29892C857584299CBF5D05346208A1ED3AA24OPEXCLILM21corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0 O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRlIiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBSb2JlcnQsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5QbGVhc2Ugc2VlIGlu bGluZSBbQnJ1bm9dPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IHJyYXN6dWtAZ21haWwuY29tIFttYWlsdG86cnJhc3p1a0BnbWFpbC5jb21dDQo8Yj5PbiBCZWhh bGYgT2YgPC9iPlJvYmVydCBSYXN6dWs8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBGZWJydWFy eSAwNiwgMjAxNyA0OjIwIFBNPGJyPg0KPGI+VG86PC9iPiBERUNSQUVORSBCcnVubyBJTVQvT0xO PGJyPg0KPGI+Q2M6PC9iPiBBbHZhcm8gUmV0YW5hIChhcmV0YW5hKTsgaWRyQGlldGYub3JnOyBT dXNhbiBIYXJlczxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0lkcl0gMiB3ZWVrIFdHIExDIGZv ciBkcmFmdC1pZXRmLWN1c3RvbS1kZWNpc2lvbiAoNC8yMCB0byA1LzQvMjAxNSk8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5IaSBCcnVubyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5PbiBteSBzaWRlLCBJ4oCZZCBwcm9wb3NlPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk9MRDo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi Pg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+dGhlIHByb3BhZ2F0aW9uIG9mIENvc3QgQ29tbXVuaXRpZXMgTVVTVCBiZSBkaXNh YmxlZCBieSBkZWZhdWx0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPk5FVzogdGhlIHVzZSBvZiBDb3N0IENvbW11bml0aWVzIE1VU1QgYmUgZGlzYWJsZWQgYnkg ZGVmYXVsdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPuKAi0Rv IHlvdSByZWFsbHkgdGhpbmsgaXQgaXMgc2FmZSB0byBwcm9wYWdhdGUg4oCLaW5mb3JtYXRpb24g d2hpY2ggY2FuIGNvbXBsZXRlbHkgb3ZlcndyaXRlIEJlc3QgUGF0aCB3aXRob3V0IGFwcGx5aW5n IGl0IGxvY2FsbHkgPyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltCcnVub108bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjEpIElJUkMsIHRoaXMgaXMgZXhh Y3RseSB3aGF0IHRoaXMgZG9jdW1lbnQgZG9lcywgZm9yIGFsbCBCR1Agc3BlYWtlcnMgd2hpY2gg ZG8gbm90IHN1cHBvcnQgdGhlIGNvc3QtY29tbXVuaXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+MikgSeKAmXZlIHNhaWQgdGhhdCBib3RoIGNob2ljZXMgY2Fu IGxlYWQgdG8gZm9yd2FyZGluZyBsb29wcy4gV2hlcmUgZG8geW91IHNlZSB0aGF0IEkgc2FpZCBp dCB3YXMgc2FmZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPklmIHdlIGFy ZSByZWFsbHkgdG8gY2hhbmdlIHRoaXMgdGV4dCBob3cgYWJvdXQgdGhpczombmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk5FVzogVGhlIHVzZSBvZiBDb3N0IENvbW11bml0aWVz IE1VU1QgYmUgZGlzYWJsZWQgYnkgZGVmYXVsdC4gVGhlIHByb3BhZ2F0aW9uIG1heSBvY2N1ciBi eSBkZWZhdWx0IG9ubHkgb24gdGhvc2UgQkdQIHNwZWFrZXJzIHdoaWNoIGRvIG5vdCBzZXQgbmV4 dCBob3Agc2VsZi4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPltCcnVub10gSeKAmW0gZmluZSB3aXRoIHRoZSBmaXJzdCBzZW50ZW5jZS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBzZWNvbmQgc2VudGVuY2UgaW50 cm9kdWNlcyBhIGJlaGF2aW9yIHdoaWNoIGlzIHBlciByb3V0ZSAocmF0aGVyIHRoYW4gcGVyIG5v ZGUgY3VycmVudGx5KS4gSSBkb27igJl0IHJlYWxseSBzZWUgYSBzdHJvbmcgZW5vdWdoIHJlYXNv biBmb3IgdGhpcw0KIGFkZGl0aW9uYWwgY29tcGxleGl0eS4gRXNwZWNpYWxseSBnaXZlbiB0aGF0 IGFsbCBub24tY29tcGxpYW50IHJvdXRlciB3aWxsIHByb3BhZ2F0ZSBpdCBpbiBhbGwgY2FzZXMu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNoZWVycyw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJydW5vPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPuKAi0NoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Ui48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+4oCLPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxQUkU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1 dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxl Z2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3Ug Y29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBh ciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1 aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlx dWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRl IHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZh bHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250 YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHBy b3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBj b3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVt YWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1l c3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFu Z2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNo YW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCjwvUFJFPjwvYm9keT4NCjwvaHRtbD4NCg== --_000_53C29892C857584299CBF5D05346208A1ED3AA24OPEXCLILM21corp_-- From nobody Mon Feb 6 12:01: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 E689D1295D5; Mon, 6 Feb 2017 12:01:51 -0800 (PST) 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 bv19Oe8gVd4m; Mon, 6 Feb 2017 12:01:50 -0800 (PST) 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 99BF31295F9; Mon, 6 Feb 2017 12:01:38 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.124.247.135; From: "Susan Hares" To: "'Borchert, Oliver \(Fed\)'" , "'John Scudder'" References: <24581E62-94D7-4D2E-8157-21ADF1CE7AF1@nist.gov> In-Reply-To: <24581E62-94D7-4D2E-8157-21ADF1CE7AF1@nist.gov> Date: Mon, 6 Feb 2017 14:57:08 -0500 Message-ID: <00ff01d280b3$33771830$9a654890$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFa04UJGQxVwyjfrfL4tU0zb1CHYAIFmXkSojuOasA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: idr-chairs@ietf.org, idr@ietf.org Subject: Re: [Idr] Implementation call for draft-ietf-idr-bgp-extended-messages (1/24/2017 to 1/31/2017) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 20:01:52 -0000 Oliver would you fill review the form at: =20 https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implement= ations Please suggest changes to the way the implementation report is worded. =20 Could you provide information on what happens if a peer:=20 4a) SHOULD NOT Accept EXTENDED MESSAGE from peer if has not advertised = BGP Extended Capability , and=20 4b) It is not configured to the "MAY" that allows receiving the message = Extended Messages=20 Does it follows RFC4221 handling sending Bad Message Length Notification = and resets session?=20 Sue=20 -----Original Message----- From: Borchert, Oliver (Fed) [mailto:oliver.borchert@nist.gov]=20 Sent: Friday, February 3, 2017 7:44 PM To: Susan Hares; John Scudder (jgs@juniper.net) Cc: idr-chairs@ietf.org; idr@ietf.org Subject: Re: Implementation call for = draft-ietf-idr-bgp-extended-messages (1/24/2017 to 1/31/2017) At NIST we have two independent implementations of the BGPsec Protocol = including the extended message capability as specified in = =E2=80=9Cdraft-ietf-idr-bgp-extended-messages-14=E2=80=9D. They are: (1) QuaggaSRx, an extension to the Quagga router implementation (2) BGPSEC-IO, a BGPsec traffic generator that allows generating = multihop BGPsec updates. QuaggaSRX: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The implementation includes the following features in accordance with = the draft: 1. Announce via BGP Capability advertisement (RFC5492) as BGP Extended = Capability: Yes 2. If BGP Extended Capability negotiated, then MUST = receive and process message larger than 4096 bytes: Yes 3. If BGP = Extended Capability not negotiated, then MUST NOT send message larger = than 4096 bytes: Yes 4. MAY accept EXTENDED MESSAGE from peer if not = advertised BGP Extended Capability: Yes BGPSEC-IO: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The implementation includes the following features in accordance with = the draft: 1. Announce via BGP Capability advertisement (RFC5492) as BGP Extended = Capability: Yes 2. If BGP Extended Capability negotiated, then MUST = receive and process message larger than 4096 bytes: Yes 3. If BGP = Extended Capability not negotiated, then MUST NOT send message larger = than 4096 bytes: Yes 4. MAY accept EXTENDED MESSAGE from peer if not = advertised BGP Extended Capability: Yes Thanks, Oliver ------------------------------------------------------------- Oliver Borchert, Computer Scientist National Institute of Standards and Technology (Phone) 301.975.4856 , (Fax) 301.975.6238 From nobody Tue Feb 7 03:27: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 2FD79129B56 for ; Tue, 7 Feb 2017 03:27:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 70_iq1a8zHoe for ; Tue, 7 Feb 2017 03:27:42 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FA56129B51 for ; Tue, 7 Feb 2017 03:27:39 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAD93983; Tue, 07 Feb 2017 11:27:37 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 7 Feb 2017 11:27:24 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Tue, 7 Feb 2017 19:27:14 +0800 From: Zhuangshunwan To: "John G. Scudder" , "idr@ietf.org" Thread-Topic: [Idr] WG adoption call for draft-hr-idr-rfc5575bis-02 "Dissemination of Flow Specification Rules" Thread-Index: AQHSfY13NB5Ls8RgpkyhSEewZk1bKKFda/MQ Date: Tue, 7 Feb 2017 11:28:25 +0000 Message-ID: <19AB2A007F56DB4E8257F949A2FB9858C88485E5@NKGEML515-MBX.china.huawei.com> References: <36E285C0-C716-437A-806D-A453273146DD@juniper.net> <4ADCDBDD-934C-4EE6-8069-CB8A60B39A66@juniper.net> In-Reply-To: <4ADCDBDD-934C-4EE6-8069-CB8A60B39A66@juniper.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.86.254] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.5899AF29.0105, 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: c22d12dabb9126dfde5a54daeb838fac Archived-At: Subject: Re: [Idr] WG adoption call for draft-hr-idr-rfc5575bis-02 "Dissemination of Flow Specification Rules" X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 11:27:44 -0000 U3VwcG9ydC4gSXQgaXMgYSBxdWl0ZSB1c2VmdWwgd29yayB0byBpbXByb3ZlIGJldHRlciBpbnRl cm9wZXJhYmlsaXR5Lg0KDQpDaGVlcnMsDQpTaHVud2FuDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0t LS0NCuWPkeS7tuS6ujogSWRyIFttYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBK b2huIEcuIFNjdWRkZXINCuWPkemAgeaXtumXtDogMjAxN+W5tDLmnIgz5pelIDM6NDkNCuaUtuS7 tuS6ujogaWRyQGlldGYub3JnDQrkuLvpopg6IFJlOiBbSWRyXSBXRyBhZG9wdGlvbiBjYWxsIGZv ciBkcmFmdC1oci1pZHItcmZjNTU3NWJpcy0wMiAiRGlzc2VtaW5hdGlvbiBvZiBGbG93IFNwZWNp ZmljYXRpb24gUnVsZXMiDQoNCkZvbGtzLCANCg0KSXQgd2FzIHBvaW50ZWQgb3V0IHRvIG1lIHRo YXQgZHVlIHRvIENoaW5lc2UgTmV3IFllYXIsIGEgc2lnbmlmaWNhbnQgbnVtYmVyIG9mIFdHIG1l bWJlcnMgbWF5IG5vdCBoYXZlIGhhZCB0aGUgb3Bwb3J0dW5pdHkgdG8gcmVzcG9uZCAoSSBkb24n dCBrbm93IHdoYXQgZXZlcnlvbmUgZWxzZSdzIGV4Y3VzZSBpcy4uLikuIFdlIHdpbGwgZXh0ZW5k IHRoZSBhZG9wdGlvbiBjYWxsIHVudGlsIEZlYnJ1YXJ5IDEzIHVubGVzcyB0aGVyZSBhcmUgb2Jq ZWN0aW9ucy4gKElmIHRoZXJlIGFyZSBvYmplY3Rpb25zIGZlZWwgZnJlZSB0byB1bmljYXN0IHRo ZW0gdG8gbWUsIG9yIHNlbmQgdGhlbSB0byB0aGUgbGlzdCwgYXMgeW91IHByZWZlci4pDQoNClRo YW5rcywNCg0K4oCUSm9obg0KDQo+IE9uIEphbiAyMSwgMjAxNywgYXQgMTA6MDMgQU0sIEpvaG4g Ry4gU2N1ZGRlciA8amdzQGp1bmlwZXIubmV0PiB3cm90ZToNCj4gDQo+IEhpIEFsbCwNCj4gDQo+ IFRoZSBhdXRob3JzIGhhdmUgcmVxdWVzdGVkIElEUiB3b3JraW5nIGdyb3VwIGFkb3B0aW9uIG9m IGRyYWZ0LWhyLWlkci1yZmM1NTc1YmlzLTAyICJEaXNzZW1pbmF0aW9uIG9mIEZsb3cgU3BlY2lm aWNhdGlvbiBSdWxlcyIuIFBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIGxpc3QuDQo+ IA0KPiBUaGlzIGFkb3B0aW9uIGNhbGwgd2lsbCBjb25jbHVkZSBvbiBNb25kYXksIEZlYnJ1YXJ5 IDYuDQo+IA0KPiBUaGFua3MsDQo+IA0KPiDigJRKb2huDQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IElkciBtYWlsaW5nIGxpc3QNCj4gSWRyQGll dGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJZHIgbWFpbGlu ZyBsaXN0DQpJZHJAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaWRyDQo= From nobody Tue Feb 7 03:35: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 30E3C129AD7 for ; Tue, 7 Feb 2017 03:35:14 -0800 (PST) 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 kGcmIC2u4dnn for ; Tue, 7 Feb 2017 03:35:12 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C284129B81 for ; Tue, 7 Feb 2017 03:35:07 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DFZ25805; Tue, 07 Feb 2017 11:35:03 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 7 Feb 2017 11:34:59 +0000 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, 7 Feb 2017 19:34:53 +0800 From: Zhuangshunwan To: Christoph Loibl , "John G. Scudder" Thread-Topic: [Idr] WG adoption call for draft-hr-idr-rfc5575bis-02 "Dissemination of Flow Specification Rules" Thread-Index: AQHSemrqNB5Ls8RgpkyhSEewZk1bKKFddjQQ Date: Tue, 7 Feb 2017 11:36:05 +0000 Message-ID: <19AB2A007F56DB4E8257F949A2FB9858C8848605@NKGEML515-MBX.china.huawei.com> References: <36E285C0-C716-437A-806D-A453273146DD@juniper.net> <5695B5BA-D452-49BB-974B-172ADDDD1C1E@tix.at> In-Reply-To: <5695B5BA-D452-49BB-974B-172ADDDD1C1E@tix.at> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.86.254] Content-Type: multipart/alternative; boundary="_000_19AB2A007F56DB4E8257F949A2FB9858C8848605NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.5899B0E9.024C, 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: f1f110bc4537f61551ae35ea099b86bf Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] WG adoption call for draft-hr-idr-rfc5575bis-02 "Dissemination of Flow Specification Rules" X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 11:35:14 -0000 --_000_19AB2A007F56DB4E8257F949A2FB9858C8848605NKGEML515MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgIENocmlzdG9waCwNCg0KSSBoYXZlIHJlYWQgeW91ciBwYXBlciwgdGhlIHBhcGVyIGdpdmVz IG1lIGEgZGVlcCBpbXByZXNzaW9uIGFuZCBhIG1vcmUgcHJvZm91bmQgdW5kZXJzdGFuZGluZyBv biB0aGUgcHJpbmNpcGxlIG9mIGZsb3dzcGVjLg0KSXQgbWFrZXMgbWUgYmVsaWV2ZSB0aGF0IHRo ZSB3b3JrIHRvIGltcHJvdmUgdGhlIGZsb3dzcGVjIGludGVyb3BlcmFiaWxpdHkgaXMgdmVyeSBu ZWNlc3NhcnkuDQpUaGFua3MgZm9yIHlvdXIgZ3JlYXQgd29yayENCg0KUmVnYXJkcywNClNodW53 YW4NCg0K5Y+R5Lu25Lq6OiBJZHIgW21haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGo IENocmlzdG9waCBMb2libA0K5Y+R6YCB5pe26Ze0OiAyMDE35bm0MeaciDMw5pelIDQ6MDQNCuaU tuS7tuS6ujogSm9obiBHLiBTY3VkZGVyDQrmioTpgIE6IGlkckBpZXRmLm9yZw0K5Li76aKYOiBS ZTogW0lkcl0gV0cgYWRvcHRpb24gY2FsbCBmb3IgZHJhZnQtaHItaWRyLXJmYzU1NzViaXMtMDIg IkRpc3NlbWluYXRpb24gb2YgRmxvdyBTcGVjaWZpY2F0aW9uIFJ1bGVzIg0KDQpIaSBBbGwsDQoN CkFzIGFuIGNvLWF1dGhvciBvZiB0aGUgZHJhZnQgSSBzdXBwb3J0IHRoZSBhZG9wdGlvbi4NCg0K SG93ZXZlciwgSSBub3RpY2VkIHRoYXQgSSBtaXNzZWQgdG8gcG9zdCBvdXIgcmVjZW50IHBhcGVy IG9uIEZsb3dzcGVjIGludGVyb3AgdG8gdGhlIElEUiBsaXN0LiBUaGlzIHBhcGVyIGlsbHVzdHJh dGVzIChiYXNlZCBvbiBvdXIgbGFiIHNldHVwKSB0aGUgY3VycmVudCBzdGF0ZSBvZiBGbG93c3Bl YyBpbXBsZW1lbnRhdGlvbnMuIEJlY2F1c2Ugb2YgdGhlIGluY29tcGF0aWJpbGl0aWVzIG9ic2Vy dmVkIHdlIHdlcmUgaW5zcGlyZWQgdG8gY28tYXV0aG9yIHRoZSBkcmFmdC1oci1pZHItcmZjNTU3 NWJpcyB0byBpbXByb3ZlIGludGVyb3BlcmFiaWxpdHkgYW5kIHN0YWJpbGl0eS4NCg0KWW91IG1h eSBkb3dubG9hZCBvdXIgcGFwZXIgYXQ6DQoNCmh0dHA6Ly9wNC50aXguYXQvfmNsL2ZzL2xvaWJs LWJhY2hlci1iZ3AtZmxvd3NwZWMtaW50ZXJvcC0wMTIwMTcucGRmDQoNClJlZ2FyZHMNCkNocmlz dG9waA0KDQoNCk9uIDIxIEphbiAyMDE3LCBhdCAxNjowMywgSm9obiBHLiBTY3VkZGVyIDxqZ3NA anVuaXBlci5uZXQ8bWFpbHRvOmpnc0BqdW5pcGVyLm5ldD4+IHdyb3RlOg0KDQpIaSBBbGwsDQoN ClRoZSBhdXRob3JzIGhhdmUgcmVxdWVzdGVkIElEUiB3b3JraW5nIGdyb3VwIGFkb3B0aW9uIG9m IGRyYWZ0LWhyLWlkci1yZmM1NTc1YmlzLTAyICJEaXNzZW1pbmF0aW9uIG9mIEZsb3cgU3BlY2lm aWNhdGlvbiBSdWxlcyIuIFBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIGxpc3QuDQoN ClRoaXMgYWRvcHRpb24gY2FsbCB3aWxsIGNvbmNsdWRlIG9uIE1vbmRheSwgRmVicnVhcnkgNi4N Cg0KVGhhbmtzLA0KDQrigJRKb2huDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KSWRyIG1haWxpbmcgbGlzdA0KSWRyQGlldGYub3JnPG1haWx0bzpJZHJA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0KDQot LQ0KQ2hyaXN0b3BoIExvaWJsDQpjQHRpeC5hdDxtYWlsdG86Y0B0aXguYXQ+IHwgQ0w4LVJJUEUg fCBQR1AtS2V5LUlEOiAweDRCMkMwMDU1IHwgaHR0cDovL3d3dy5uZXh0bGF5ZXIuYXQNCg0K --_000_19AB2A007F56DB4E8257F949A2FB9858C8848605NKGEML515MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWls U3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5 MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkhpJm5ic3A7IENocmlzdG9waCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ SSBoYXZlIHJlYWQgeW91ciBwYXBlciwgdGhlIHBhcGVyIGdpdmVzIG1lIGEgZGVlcCBpbXByZXNz aW9uIGFuZCBhIG1vcmUgcHJvZm91bmQgdW5kZXJzdGFuZGluZyBvbiB0aGUgcHJpbmNpcGxlIG9m IGZsb3dzcGVjLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SXQg bWFrZXMgbWUgYmVsaWV2ZSB0aGF0IHRoZSB3b3JrIHRvIGltcHJvdmUgdGhlIGZsb3dzcGVjIGlu dGVyb3BlcmFiaWxpdHkgaXMgdmVyeSBuZWNlc3NhcnkuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MgZm9yIHlvdXIgZ3JlYXQgd29yayE8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNodW53YW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdCI+5Y+R5Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+ PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiBJ ZHIgW21haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZ10NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdCI+5Luj6KGoIDwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0Ij5DaHJpc3RvcGggTG9pYmw8YnI+DQo8L3NwYW4+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuWPkemAgeaXtumXtDxzcGFuIGxhbmc9IkVOLVVT Ij46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij4gMjAxNzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5bm0PHNw YW4gbGFuZz0iRU4tVVMiPjE8L3NwYW4+5pyIPHNwYW4gbGFuZz0iRU4tVVMiPjMwPC9zcGFuPuaX pTxzcGFuIGxhbmc9IkVOLVVTIj4gNDowNDxicj4NCjwvc3Bhbj48Yj7mlLbku7bkuro8c3BhbiBs YW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBKb2huIEcuIFNjdWRk ZXI8YnI+DQo8L3NwYW4+PGI+5oqE6YCBPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkVOLVVTIj4gaWRyQGlldGYub3JnPGJyPg0KPC9zcGFuPjxiPuS4u+mimDxzcGFu IGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFJlOiBbSWRyXSBX RyBhZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1oci1pZHItcmZjNTU3NWJpcy0wMiAmcXVvdDtEaXNz ZW1pbmF0aW9uIG9mIEZsb3cgU3BlY2lmaWNhdGlvbiBSdWxlcyZxdW90OzxvOnA+PC9vOnA+PC9z cGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSBBbGwsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+QXMgYW4gY28tYXV0aG9yIG9mIHRoZSBkcmFmdCBJIHN1cHBv cnQgdGhlIGFkb3B0aW9uLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+SG93ZXZlciwgSSBub3RpY2VkIHRoYXQgSSBtaXNzZWQgdG8gcG9zdCBv dXIgcmVjZW50IHBhcGVyIG9uIEZsb3dzcGVjIGludGVyb3AgdG8gdGhlIElEUiBsaXN0LiBUaGlz IHBhcGVyIGlsbHVzdHJhdGVzIChiYXNlZCBvbiBvdXIgbGFiIHNldHVwKSB0aGUgY3VycmVudCBz dGF0ZSBvZiBGbG93c3BlYyBpbXBsZW1lbnRhdGlvbnMuIEJlY2F1c2Ugb2YgdGhlIGluY29tcGF0 aWJpbGl0aWVzDQogb2JzZXJ2ZWQgd2Ugd2VyZSBpbnNwaXJlZCB0byBjby1hdXRob3IgdGhlJm5i c3A7ZHJhZnQtaHItaWRyLXJmYzU1NzViaXMgdG8gaW1wcm92ZSBpbnRlcm9wZXJhYmlsaXR5IGFu ZCBzdGFiaWxpdHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5Zb3UgbWF5IGRvd25sb2FkIG91ciBwYXBlciBhdDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0dHA6Ly9wNC50aXguYXQvfmNs L2ZzL2xvaWJsLWJhY2hlci1iZ3AtZmxvd3NwZWMtaW50ZXJvcC0wMTIwMTcucGRmIj5odHRwOi8v cDQudGl4LmF0L35jbC9mcy9sb2libC1iYWNoZXItYmdwLWZsb3dzcGVjLWludGVyb3AtMDEyMDE3 LnBkZjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PlJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Q2hyaXN0b3BoPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPk9uIDIxIEphbiAyMDE3LCBhdCAxNjowMywgSm9obiBHLiBTY3VkZGVyICZsdDs8YSBocmVm PSJtYWlsdG86amdzQGp1bmlwZXIubmV0Ij5qZ3NAanVuaXBlci5uZXQ8L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSBBbGwsPGJyPg0KPGJy Pg0KVGhlIGF1dGhvcnMgaGF2ZSByZXF1ZXN0ZWQgSURSIHdvcmtpbmcgZ3JvdXAgYWRvcHRpb24g b2YgZHJhZnQtaHItaWRyLXJmYzU1NzViaXMtMDIgJnF1b3Q7RGlzc2VtaW5hdGlvbiBvZiBGbG93 IFNwZWNpZmljYXRpb24gUnVsZXMmcXVvdDsuIFBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgdG8g dGhlIGxpc3QuPGJyPg0KPGJyPg0KVGhpcyBhZG9wdGlvbiBjYWxsIHdpbGwgY29uY2x1ZGUgb24g TW9uZGF5LCBGZWJydWFyeSA2Ljxicj4NCjxicj4NClRoYW5rcyw8YnI+DQo8YnI+DQrigJRKb2hu PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQpJZHIgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOklkckBpZXRmLm9yZyI+SWRy QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaWRyIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcjwv YT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+LS0mbmJzcDs8YnI+DQpDaHJpc3RvcGggTG9pYmw8YnI+DQo8YSBo cmVmPSJtYWlsdG86Y0B0aXguYXQiPmNAdGl4LmF0PC9hPiZuYnNwO3wgQ0w4LVJJUEUgfCBQR1At S2V5LUlEOiAweDRCMkMwMDU1IHwmbmJzcDs8YSBocmVmPSJodHRwOi8vd3d3Lm5leHRsYXllci5h dCI+aHR0cDovL3d3dy5uZXh0bGF5ZXIuYXQ8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_19AB2A007F56DB4E8257F949A2FB9858C8848605NKGEML515MBXchi_-- From nobody Tue Feb 7 22:19: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 6308A1294FE for ; Tue, 7 Feb 2017 22:18:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 E0ENsDSOyYfA for ; Tue, 7 Feb 2017 22:18:57 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 264C9129440 for ; Tue, 7 Feb 2017 22:18:57 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DGA51741; Wed, 08 Feb 2017 06:18:52 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 8 Feb 2017 06:18:31 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.116]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0235.001; Wed, 8 Feb 2017 14:18:22 +0800 From: Mach Chen To: "John G. Scudder" , "idr@ietf.org" Thread-Topic: [Idr] WG adoption call for draft-hr-idr-rfc5575bis-02 "Dissemination of Flow Specification Rules" Thread-Index: AQHSc/eOk3UHg2UyC0ag4FKconf/IqFevfCw Date: Wed, 8 Feb 2017 06:18:22 +0000 Message-ID: References: <36E285C0-C716-437A-806D-A453273146DD@juniper.net> In-Reply-To: <36E285C0-C716-437A-806D-A453273146DD@juniper.net> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.194.201] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.589AB84D.0029, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.116, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 90e1abc951d55526ffa833a89d40f955 Archived-At: Subject: Re: [Idr] WG adoption call for draft-hr-idr-rfc5575bis-02 "Dissemination of Flow Specification Rules" X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 06:18:59 -0000 SGksDQoNCkkgaGF2ZSByZWFkIHRoZSBkcmFmdCBhbmQgdGhpbmsgaXQncyB1c2VmdWwsIHNvIEkg c3VwcG9ydCB0aGUgYWRvcHRpb24hDQoNCkJlc3QgcmVnYXJkcywNCk1hY2gNCg0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBJZHIgW21haWx0bzppZHItYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIEpvaG4gRy4gU2N1ZGRlcg0KPiBTZW50OiBTYXR1cmRheSwgSmFu dWFyeSAyMSwgMjAxNyAxMTowMyBQTQ0KPiBUbzogaWRyQGlldGYub3JnDQo+IFN1YmplY3Q6IFtJ ZHJdIFdHIGFkb3B0aW9uIGNhbGwgZm9yIGRyYWZ0LWhyLWlkci1yZmM1NTc1YmlzLTAyICJEaXNz ZW1pbmF0aW9uIG9mDQo+IEZsb3cgU3BlY2lmaWNhdGlvbiBSdWxlcyINCj4gDQo+IEhpIEFsbCwN Cj4gDQo+IFRoZSBhdXRob3JzIGhhdmUgcmVxdWVzdGVkIElEUiB3b3JraW5nIGdyb3VwIGFkb3B0 aW9uIG9mDQo+IGRyYWZ0LWhyLWlkci1yZmM1NTc1YmlzLTAyICJEaXNzZW1pbmF0aW9uIG9mIEZs b3cgU3BlY2lmaWNhdGlvbiBSdWxlcyIuIFBsZWFzZQ0KPiBzZW5kIHlvdXIgY29tbWVudHMgdG8g dGhlIGxpc3QuDQo+IA0KPiBUaGlzIGFkb3B0aW9uIGNhbGwgd2lsbCBjb25jbHVkZSBvbiBNb25k YXksIEZlYnJ1YXJ5IDYuDQo+IA0KPiBUaGFua3MsDQo+IA0KPiDigJRKb2huDQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IElkciBtYWlsaW5nIGxp c3QNCj4gSWRyQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaWRyDQo= From nobody Thu Feb 9 00:44:55 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 765331295DA; Thu, 9 Feb 2017 00:44:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148662988947.20537.9725627303133048833.idtracker@ietfa.amsl.com> Date: Thu, 09 Feb 2017 00:44:49 -0800 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgpls-segment-routing-epe-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 08:44:49 -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 : Segment Routing BGP Egress Peer Engineering BGP-LS Extensions Authors : Stefano Previdi Clarence Filsfils Saikat Ray Keyur Patel Jie Dong Mach (Guoyi) Chen Filename : draft-ietf-idr-bgpls-segment-routing-epe-07.txt Pages : 21 Date : 2017-02-09 Abstract: Segment Routing (SR) leverages source routing. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service-based. SR allows to enforce a flow through any topological path and service chain while maintaining per-flow state only at the ingress node of the SR domain. The Segment Routing architecture can be directly applied to the MPLS dataplane with no change on the forwarding plane. It requires minor extension to the existing link-state routing protocols. This document outline a BGP-LS extension for exporting BGP peering node topology information (including its peers, interfaces and peering ASs) in a way that is exploitable in order to compute efficient BGP Peering Engineering policies and strategies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-bgpls-segment-routing-epe-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgpls-segment-routing-epe-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 Thu Feb 9 00:49: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 00C3D1293D6; Thu, 9 Feb 2017 00:49:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148663018999.20618.7767851401874338498.idtracker@ietfa.amsl.com> Date: Thu, 09 Feb 2017 00:49:49 -0800 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-ls-segment-routing-ext-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 08:49: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 of the IETF. Title : BGP Link-State extensions for Segment Routing Authors : Stefano Previdi Peter Psenak Clarence Filsfils Hannes Gredler Mach(Guoyi) Chen Jeff Tantsura Filename : draft-ietf-idr-bgp-ls-segment-routing-ext-01.txt Pages : 36 Date : 2017-02-09 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's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-ext-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-ls-segment-routing-ext-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 Thu Feb 9 09:41: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 AB133129C1C for ; Thu, 9 Feb 2017 09:41:51 -0800 (PST) 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 AiSEX8MRIv0W for ; Thu, 9 Feb 2017 09:41:50 -0800 (PST) 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 75F65129C0D for ; Thu, 9 Feb 2017 09:41:50 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=70.194.20.38; From: "Susan Hares" To: Date: Thu, 9 Feb 2017 12:37:09 -0500 Message-ID: <010401d282fb$24526ef0$6cf74cd0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0105_01D282D1.3B7D0330" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdKC+h4H7GLH2LS0Qk2T+f30sVQnPg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] Welcome to Jie Dong as IDR WG Secretary X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 17:41:51 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0105_01D282D1.3B7D0330 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit IDR WG: During the last half of 2016, members of the WG have indicated IDR needs to increase the pace of standardization for certain drafts. As part of this effort, the IDR co-chairs determined that a WG secretary would help move administrative actions along. A few examples of WG Administrative actions is calling for IPR, implementations reports, draft shepherds, or starting a WG adoption/WG Last Call on behalf of the chairs. Jie Dong has agreed to be the IDR WG secretary. Please welcome Jie Dong to this new position. Sue Hares and John Scudder ------=_NextPart_000_0105_01D282D1.3B7D0330 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IDR WG: =

 

During the last half of 2016, members of the WG have = indicated IDR needs to increase the pace of standardization for certain = drafts.  As part of this effort, the IDR co-chairs determined that = a WG secretary would help move administrative actions along.  =  A few examples of WG Administrative actions is calling for IPR, = implementations reports, draft shepherds, or starting a WG adoption/WG = Last Call on behalf of the chairs.   

 

Jie Dong has = agreed to be the IDR WG secretary.  Please welcome Jie Dong to this = new position.

 

Sue Hares =  and John Scudder

------=_NextPart_000_0105_01D282D1.3B7D0330-- From nobody Thu Feb 9 10:27: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 B03DB129C48 for ; Thu, 9 Feb 2017 10:27:41 -0800 (PST) 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, 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 u5Hp-dwHkZ62 for ; Thu, 9 Feb 2017 10:27:40 -0800 (PST) Received: from mail-pg0-x243.google.com (mail-pg0-x243.google.com [IPv6:2607:f8b0:400e:c05::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D44612958B for ; Thu, 9 Feb 2017 10:27:40 -0800 (PST) Received: by mail-pg0-x243.google.com with SMTP id 204so929335pge.2 for ; Thu, 09 Feb 2017 10:27:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version; bh=ftBUcTd9+Bl7ZKDaxZbxjcw665J0599d8fGdntKs/hI=; b=AbxrJLP+7ypNKYVpoJAYEZMgrgn5dCv6XUI50xjIx42HV6EjJipHXrOcNe1DvId94n ytIHbemNuT66CMFXZoIo0bl/s4HHNPc7v3ybBGxCvh+jYQks0M4R7MfFZmMgPxzBGxwP OqXKyypVQmpBeoMB6myTkCVBw5ItxhB3qUmI1zU73amRncvQyllTMbATautiBankIsQB CK8r2w4R+ADdTHatf0vzeWtU1CcR4TzIN6ulOl/vU/K9MrhLu3TMM9YdMWJ09LotD/5t pecZIaod7s3qSzsfaQj7tDnAnB4TdiiZy2p5W68jOCbEqhXyQyuVrMGlh6uiW6Ijblxh QuVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version; bh=ftBUcTd9+Bl7ZKDaxZbxjcw665J0599d8fGdntKs/hI=; b=aECuNDxqbrhL5aod6ApoAazex2K15MtrRa3eBlVSnJEUS4FOcuNPht7qw2T7uiDnkA I7rNNXGIpNjqUjplD75sq0R/YERJ+wG40BsMHQUOXWy32UDi1MR7liRTX+DyOcmyCRvn pdE9W/ZwUc7RLx6ipy0lMdnlq3e6D3oXYkfC2ExToJJqusCForlLZgPfXa3RmQbwdgik xSj27v4V2OeO+L/vM3UQuUls2/U2KLVvPika8m0clzjQpHuFMjoAwVIHNMw4x92V0UKV tnwA+y+eXpPKkxXbzoSJU/pzhACJFPdiCt+76X+m+b+FCQETejkuJ2dmZCZkaynd4cVA PAhg== X-Gm-Message-State: AMke39kUvFIrOBq3oJcj9oVrLjNYlHQg4ipCEPMblXeRexjgHlhIQRrjYZQ5CyncrvvLog== X-Received: by 10.99.223.5 with SMTP id u5mr5593949pgg.58.1486664859709; Thu, 09 Feb 2017 10:27:39 -0800 (PST) Received: from [192.168.253.79] (107-1-141-74-ip-static.hfc.comcastbusiness.net. [107.1.141.74]) by smtp.gmail.com with ESMTPSA id x81sm30705256pff.69.2017.02.09.10.27.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Feb 2017 10:27:38 -0800 (PST) User-Agent: Microsoft-MacOutlook/f.1e.0.170107 Date: Thu, 09 Feb 2017 10:27:36 -0800 From: Jeff Tantsura To: Susan Hares , Message-ID: <24E59CDF-2225-4F3B-A09F-43471DCF0A0D@gmail.com> Thread-Topic: [Idr] Welcome to Jie Dong as IDR WG Secretary References: <010401d282fb$24526ef0$6cf74cd0$@ndzh.com> In-Reply-To: <010401d282fb$24526ef0$6cf74cd0$@ndzh.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3569480857_465652939" Archived-At: Subject: Re: [Idr] Welcome to Jie Dong as IDR WG Secretary X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 18:27:42 -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_3569480857_465652939 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Welcome Jie! Cheers, Jeff From: Idr on behalf of Susan Hares Date: Thursday, February 9, 2017 at 09:37 To: Subject: [Idr] Welcome to Jie Dong as IDR WG Secretary IDR WG: During the last half of 2016, members of the WG have indicated IDR needs to increase the pace of standardization for certain drafts. As part of this effort, the IDR co-chairs determined that a WG secretary would help move administrative actions along. A few examples of WG Administrative actions is calling for IPR, implementations reports, draft shepherds, or starting a WG adoption/WG Last Call on behalf of the chairs. Jie Dong has agreed to be the IDR WG secretary. Please welcome Jie Dong to this new position. Sue Hares and John Scudder _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --B_3569480857_465652939 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Welcome Jie!

 <= /span>

Chee= rs,

Jeff

From: Idr <idr-= bounces@ietf.org> on behalf of Susan Hares <shares@ndzh.com>
= Date: Thursday, February 9, 2017 at 09:37
To: <idr@ietf.org= >
Subject: [Idr] Welcome to Jie Dong as IDR WG Secretary=

=

 

IDR WG:

 

During the last half of 2016, = members of the WG have indicated IDR needs to increase the pace of standardi= zation for certain drafts.  As part of this effort, the IDR co-chairs d= etermined that a WG secretary would help move administrative actions along.&= nbsp;  A few examples of WG Administrative actions is calling for IPR, = implementations reports, draft shepherds, or starting a WG adoption/WG Last = Call on behalf of the chairs.   

=  

Jie Dong has agreed to be the IDR WG= secretary.  Please welcome Jie Dong to this new position. <= /p>

 

Sue Hares &nbs= p;and John Scudder

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

--B_3569480857_465652939-- From nobody Thu Feb 9 16:27: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 5D1251294F9 for ; Thu, 9 Feb 2017 16:27:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.846 X-Spam-Level: ** X-Spam-Status: No, score=2.846 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 j6_5XTfseD4L for ; Thu, 9 Feb 2017 16:27:51 -0800 (PST) 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 1F5711294EE for ; Thu, 9 Feb 2017 16:27:50 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=50.36.172.15; From: "Susan Hares" To: References: <014701d28301$34ed0440$9ec70cc0$@ndzh.com> <2920996B-9EF2-4274-A50C-86B99F45489A@cisco.com> In-Reply-To: <2920996B-9EF2-4274-A50C-86B99F45489A@cisco.com> Date: Thu, 9 Feb 2017 19:23:02 -0500 Message-ID: <008501d28333$d831d180$88957480$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0086_01D28309.EF5C17A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJiWKsGq/V1IoBWBbf2tN20mADO+wGeEjU5AJ6CrY4CWUnlqKAdBxZQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: wardd@cisco.com Subject: [Idr] FW: IPR statement missing for draft-ietf-extended-messages X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 00:27:52 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0086_01D28309.EF5C17A0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Forwarding IPR statement Sue On 2/9/17, 5:10 PM, "David Ward (wardd)" wrote: I know of no IPR ------=_NextPart_000_0086_01D28309.EF5C17A0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Forwarding IPR statement

 

Sue

=C2=A0=

On 2/9/17, 5:10 PM, "David = Ward (wardd)" <wardd@cisco.com> = wrote:

 

I know = of no IPR

 

------=_NextPart_000_0086_01D28309.EF5C17A0-- From nobody Thu Feb 9 17:01: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 4347E129E02 for ; Thu, 9 Feb 2017 17:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.388 X-Spam-Level: X-Spam-Status: No, score=-3.388 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=-1.887, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.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 oezV5nrz7hEU for ; Thu, 9 Feb 2017 17:01:26 -0800 (PST) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 93461129DFB for ; Thu, 9 Feb 2017 17:01:26 -0800 (PST) Received: (qmail 31192 invoked by uid 0); 10 Feb 2017 01:01:24 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy5.mail.unifiedlayer.com with SMTP; 10 Feb 2017 01:01:24 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id ip1H1u0212SSUrH01p1LzW; Thu, 09 Feb 2017 18:01:21 -0700 X-Authority-Analysis: v=2.1 cv=U+QBU4bu c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=n2v9WMKugxEA:10 a=48vgC7mUAAAA:8 a=fDOeviFNIXX-aRIJdMgA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Subject:From:Cc:To:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=52A8Ev5WamD0a+j23wd6KpMhnIatjMmSde94fLHemAk=; b=rXqlXWMxBuX7DiBtsTmOHpgWhv A6+DyRZ56lTPwAkbHZ7IDgcsGClyYK0aC0E1GHCobiBpUZDsb1nesx5CLh+LRJMPfQgdRYRBngeWy x94s4PY5klUu7YSbjESvgpa3D; Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:53728 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cbzaP-0003w4-KM; Thu, 09 Feb 2017 18:01:17 -0700 To: rtg-ads@ietf.org From: Lou Berger Message-ID: Date: Thu, 9 Feb 2017 20:01:13 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.85.191 X-Exim-ID: 1cbzaP-0003w4-KM X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([IPv6:::1]) [100.15.85.191]:53728 X-Source-Auth: lberger@labn.net X-Email-Count: 3 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Cc: idr@ietf.org, draft-ietf-idr-shutdown.all@ietf.org, rtg-dir@ietf.org Subject: [Idr] RtgDir review: draft-ietf-idr-shutdown-05 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 01:01:34 -0000 Reviewer: Lou Berger Review Date: 2/9/17 Review requested by: 2/13 Intended Status: Standards track Summary: I have one minor comment about this document that I think should be resolved before publication. Comments: Draft is short and easy to understand. I see the need for one minor clarification that can be resolved based on implementation experience. Major Issues: No major issues found. Minor Issues: In reading the document it's unclear if Shutdown Communication field must include a trailing zero or not. (I authored something similar once and had an interop problem where one implementation assumed null termination was required and included in length, while the other didn't. Our intent was no null required, but the spec wasn't explicit.) Either are fine, and given there are implementations you might just want to have the spec match the implementation. Nits: https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-idr-shutdown-05.txt reports nits that should be fixed. That's it! Cheers, Lou From nobody Thu Feb 9 17:40: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 23FBA1294C8; Thu, 9 Feb 2017 17:40:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 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_SOFTFAIL=0.665] 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 pV_DZhUvl4dE; Thu, 9 Feb 2017 17:40:13 -0800 (PST) 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 EDF01129464; Thu, 9 Feb 2017 17:40:12 -0800 (PST) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88) (envelope-from ) id 1cc0C2-000BKR-2r (job@us.ntt.net); Fri, 10 Feb 2017 01:40:12 +0000 Date: Thu, 9 Feb 2017 20:38:50 -0500 From: Job Snijders To: rtg-ads@ietf.org, Lou Berger Message-ID: <1c3216b3-31a2-43a0-a003-6571fe133fbb@Spark> In-Reply-To: References: X-Readdle-Message-ID: 1c3216b3-31a2-43a0-a003-6571fe133fbb@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="589d19c2_66334873_74b" Archived-At: Cc: idr@ietf.org, draft-ietf-idr-shutdown.all@ietf.org, rtg-dir@ietf.org Subject: Re: [Idr] RtgDir review: draft-ietf-idr-shutdown-05 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 01:40:14 -0000 --589d19c2_66334873_74b Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear Lou, Thank you for your review. We will add a clarification that NUL termination is not expected. The question actually came up during one of the implementations so you are right that there is value in being specific. Kind regards, Job On 9 Feb 2017, 20:01 -0500, Lou Berger , wrote: > Reviewer: Lou Berger > Review Date: 2/9/17 > Review requested by: 2/13 > Intended Status: Standards track > > Summary: > I have one minor comment about this document that I think should be > resolved before publication. > > Comments: > > Draft is short and easy to understand. I see the need for one minor > clarification that can be resolved based on implementation experience. > > Major Issues: > > No major issues found. > > Minor Issues: > In reading the document it's unclear if Shutdown Communication field > must include a trailing zero or not. (I authored something similar once > and had an interop problem where one implementation assumed null > termination was required and included in length, while the other didn't. > Our intent was no null required, but the spec wasn't explicit.) Either > are fine, and given there are implementations you might just want to > have the spec match the implementation. > > Nits: > > https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-idr-shutdown-05.txt > reports nits that should be fixed. > > That's it! > Cheers, > Lou > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --589d19c2_66334873_74b Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Dear Lou,

Thank you for your review.

We will add a clarification that NUL termination is not expected.

The question actually came up during one of the implementations so you ar= e right that there is value in being specific.

Kind regards,

Job


On 9 =46eb 2017, 20:01 -0500, Lou Berger <lberger=40labn.net>, wrot= e:
Reviewer: Lou Berger
Review Date: 2/9/17
Review requested by: 2/13
Intended Status: Standards track

Summary:
I have one minor comment about this document that I think should be
= resolved before publication.

Comments:

Draft is short and easy to understand. I see the need for one minor
= clarification that can be resolved based on implementation experience.
Major Issues:

No major issues found.

Minor Issues:
In reading the document it's unclear if Shutdown Communication field
must include a trailing zero or not. (I authored something similar once and had an interop problem where one implementation assumed null
termination was required and included in length, while the other didn't.<= br /> Our intent was no null required, but the spec wasn't explicit.) Either are fine, and given there are implementations you might just want to
have the spec match the implementation.

Nits:

https://tools.ietf.org/idnits=3Furl=3Dhttps://tools.ietf.org/id/draft-iet= f-idr-shutdown-05.txt
reports nits that should be fixed.

That's it=21
Cheers,
Lou

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Idr mailing list
Idr=40ietf.org
https://www.ietf.org/mailman/listinfo/idr
--589d19c2_66334873_74b-- From nobody Thu Feb 9 20:15:10 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 D19221294FF; Thu, 9 Feb 2017 20:15:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148670010885.8126.10319875616685937817.idtracker@ietfa.amsl.com> Date: Thu, 09 Feb 2017 20:15:08 -0800 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-15.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 04:15:09 -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 : Extended Message support for BGP Authors : Randy Bush Keyur Patel Dave Ward Filename : draft-ietf-idr-bgp-extended-messages-15.txt Pages : 5 Date : 2017-02-09 Abstract: The BGP specification mandates a maximum BGP message size of 4096 octets. As BGP is extended to support newer AFI/SAFIs, there is a need to extend the maximum message size beyond 4096 octets. This document updates the BGP specification [RFC4271] by providing an extension to BGP to extend its current message size from 4096 octets to 65535 octets. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-extended-messages-15 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 Feb 9 23:32: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 70A881298AD for ; Thu, 9 Feb 2017 23:32:22 -0800 (PST) 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] 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 0uCfNO7h_fn2 for ; Thu, 9 Feb 2017 23:32:20 -0800 (PST) Received: from cmccmta1.chinamobile.com (cmccmta1.chinamobile.com [221.176.66.79]) by ietfa.amsl.com (Postfix) with ESMTP id C1DC81298AA for ; Thu, 9 Feb 2017 23:32:18 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.121.9]) by rmmx-syy-dmz-app02-12002 (RichMail) with SMTP id 2ee2589d6c7e648-409e5; Fri, 10 Feb 2017 15:32:16 +0800 (CST) X-RM-TRANSID: 2ee2589d6c7e648-409e5 X-RM-SPAM-FLAG: 00000000 Received: from cmcc-PC (unknown[221.130.253.135]) by rmsmtp-syy-appsvr05-12005 (RichMail) with SMTP id 2ee5589d6c7df56-ed90e; Fri, 10 Feb 2017 15:32:16 +0800 (CST) X-RM-TRANSID: 2ee5589d6c7df56-ed90e Date: Fri, 10 Feb 2017 15:33:41 +0800 From: "lizhenqiang@chinamobile.com" To: "Jeff Tantsura" , shares , idr References: <010401d282fb$24526ef0$6cf74cd0$@ndzh.com>, <24E59CDF-2225-4F3B-A09F-43471DCF0A0D@gmail.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 7, 164[cn] Mime-Version: 1.0 Message-ID: <201702101533404320041@chinamobile.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart133787445833_=----" Archived-At: Subject: Re: [Idr] Welcome to Jie Dong as IDR WG Secretary X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 07:32:22 -0000 This is a multi-part message in MIME format. ------=_001_NextPart133787445833_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 V2VsY29tZSBhbmQgY29uZ3JhdHVsYXRpb25zLCBKaWUhDQoNCg0KDQpsaXpoZW5xaWFuZ0BjaGlu YW1vYmlsZS5jb20NCiANCkZyb206IEplZmYgVGFudHN1cmENCkRhdGU6IDIwMTctMDItMTAgMDI6 MjcNClRvOiBTdXNhbiBIYXJlczsgaWRyQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0lkcl0gV2Vs Y29tZSB0byBKaWUgRG9uZyBhcyBJRFIgV0cgU2VjcmV0YXJ5DQpXZWxjb21lIEppZSENCiANCkNo ZWVycywNCkplZmYNCkZyb206IElkciA8aWRyLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBv ZiBTdXNhbiBIYXJlcyA8c2hhcmVzQG5kemguY29tPg0KRGF0ZTogVGh1cnNkYXksIEZlYnJ1YXJ5 IDksIDIwMTcgYXQgMDk6MzcNClRvOiA8aWRyQGlldGYub3JnPg0KU3ViamVjdDogW0lkcl0gV2Vs Y29tZSB0byBKaWUgRG9uZyBhcyBJRFIgV0cgU2VjcmV0YXJ5DQogDQpJRFIgV0c6IA0KIA0KRHVy aW5nIHRoZSBsYXN0IGhhbGYgb2YgMjAxNiwgbWVtYmVycyBvZiB0aGUgV0cgaGF2ZSBpbmRpY2F0 ZWQgSURSIG5lZWRzIHRvIGluY3JlYXNlIHRoZSBwYWNlIG9mIHN0YW5kYXJkaXphdGlvbiBmb3Ig Y2VydGFpbiBkcmFmdHMuICBBcyBwYXJ0IG9mIHRoaXMgZWZmb3J0LCB0aGUgSURSIGNvLWNoYWly cyBkZXRlcm1pbmVkIHRoYXQgYSBXRyBzZWNyZXRhcnkgd291bGQgaGVscCBtb3ZlIGFkbWluaXN0 cmF0aXZlIGFjdGlvbnMgYWxvbmcuICAgQSBmZXcgZXhhbXBsZXMgb2YgV0cgQWRtaW5pc3RyYXRp dmUgYWN0aW9ucyBpcyBjYWxsaW5nIGZvciBJUFIsIGltcGxlbWVudGF0aW9ucyByZXBvcnRzLCBk cmFmdCBzaGVwaGVyZHMsIG9yIHN0YXJ0aW5nIGEgV0cgYWRvcHRpb24vV0cgTGFzdCBDYWxsIG9u IGJlaGFsZiBvZiB0aGUgY2hhaXJzLiAgIA0KIA0KSmllIERvbmcgaGFzIGFncmVlZCB0byBiZSB0 aGUgSURSIFdHIHNlY3JldGFyeS4gIFBsZWFzZSB3ZWxjb21lIEppZSBEb25nIHRvIHRoaXMgbmV3 IHBvc2l0aW9uLiANCiANClN1ZSBIYXJlcyAgYW5kIEpvaG4gU2N1ZGRlciANCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIElkciBtYWlsaW5nIGxpc3QgSWRy QGlldGYub3JnIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyIA0K ------=_001_NextPart133787445833_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A
Welcome and congratu= lations, Jie!
=0A

=0A
lizhenqiang@= chinamobile.com
=0A
 
S= ubject: Re: [Idr] Welcome to Jie Dong as IDR WG Secretary
=0A
=0A

Wel= come Jie!

=0A
=0A

 

=0A

Cheers,=

=0A

Jeff

=0A
=0A
=0A

From: Idr <idr-bounces@ietf.org> on behalf of Susan Hares <= shares@ndzh.com>
=0ADate: Thursday, February 9, 2017 at 09:37=
=0ATo: <idr@ietf.org>
=0ASubject: [Idr] Welcome= to Jie Dong as IDR WG Secretary

=0A
=0A
=0A

 

=0A
=0A

IDR WG:

=0A=

 

=0A

Du= ring the last half of 2016, members of the WG have indicated IDR needs to = increase the pace of standardization for certain drafts.  As part of = this effort, the IDR co-chairs determined that a WG secretary would help m= ove administrative=0A actions along.   A few examples of WG Admi= nistrative actions is calling for IPR, implementations reports, draft shep= herds, or starting a WG adoption/WG Last Call on behalf of the chairs.&nbs= p;  

=0A

 

= =0A

Jie Dong has agreed to be the IDR WG secretary.=  Please welcome Jie Dong to this new position.=0A

=0A<= p class=3D"MsoNormal" style=3D"margin: 0in 0in 0.0001pt; font-size: 11pt; = font-family: Calibri;"> 

=0A

Sue= Hares  and John Scudder

=0A

___= ____________________________________________ Idr mailing list Idr@ietf.org= https://www.ietf.org/mailman/listinfo/idr=0A

=0A=0A
=0A ------=_001_NextPart133787445833_=------ From nobody Thu Feb 9 23:38: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 AFEE812A01D for ; Thu, 9 Feb 2017 23:38:57 -0800 (PST) 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] 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 mguvUuouhmif for ; Thu, 9 Feb 2017 23:38:56 -0800 (PST) Received: from cmccmta2.chinamobile.com (cmccmta2.chinamobile.com [221.176.66.80]) by ietfa.amsl.com (Postfix) with ESMTP id A35A112A01C for ; Thu, 9 Feb 2017 23:38:55 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.121.9]) by rmmx-syy-dmz-app08-12008 (RichMail) with SMTP id 2ee8589d6e0e7f5-40be1; Fri, 10 Feb 2017 15:38:54 +0800 (CST) X-RM-TRANSID: 2ee8589d6e0e7f5-40be1 X-RM-SPAM-FLAG: 00000000 Received: from cmcc-PC (unknown[221.130.253.135]) by rmsmtp-syy-appsvr05-12005 (RichMail) with SMTP id 2ee5589d6e0c3b9-edd99; Fri, 10 Feb 2017 15:38:54 +0800 (CST) X-RM-TRANSID: 2ee5589d6e0c3b9-edd99 Date: Fri, 10 Feb 2017 15:40:21 +0800 From: "lizhenqiang@chinamobile.com" To: "John Scudder" , idr References: <36E285C0-C716-437A-806D-A453273146DD@juniper.net>, <4ADCDBDD-934C-4EE6-8069-CB8A60B39A66@juniper.net> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 7, 164[cn] Mime-Version: 1.0 Message-ID: <201702101540202437802@chinamobile.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart270112303285_=----" Archived-At: Subject: Re: [Idr] WG adoption call for draft-hr-idr-rfc5575bis-02 "Dissemination of Flow Specification Rules" X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 07:38:57 -0000 This is a multi-part message in MIME format. ------=_001_NextPart270112303285_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGVsbG8gQWxsLA0KDQpJIHN1cHBvcnQgdGhlIGFkb3B0aW9uIG9mIHlvdXIgZHJhZnQuIEJ1dCBJ IHdhbnQgdG8gYXNrIGEgcXVlc3Rpb24uIHJmYzU1NzViaXMgaXMgZm9yIElQdjQsIGFzIHN0YXRl ZCBpbiB0aGUgYWJzdHJhY3QuIEhvd2V2ZXIsIElQdjQgaXMgZGVjbGFyZWQgdG8gYmUgaGlzdG9y aWMuIERvIHdlIHN0aWxsIG5lZWQgYSBSRkMgc3BlY2lmaWNhbGx5IGRlc2lnbmVkIGZvciBJUHY0 PyANCg0KQmVzdCBSZWdhcmRzLA0KDQoNCg0KbGl6aGVucWlhbmdAY2hpbmFtb2JpbGUuY29tDQog DQpGcm9tOiBKb2huIEcuIFNjdWRkZXINCkRhdGU6IDIwMTctMDItMDMgMDM6NDkNClRvOiBpZHJA aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbSWRyXSBXRyBhZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1o ci1pZHItcmZjNTU3NWJpcy0wMiAiRGlzc2VtaW5hdGlvbiBvZiBGbG93IFNwZWNpZmljYXRpb24g UnVsZXMiDQpGb2xrcywgDQogDQpJdCB3YXMgcG9pbnRlZCBvdXQgdG8gbWUgdGhhdCBkdWUgdG8g Q2hpbmVzZSBOZXcgWWVhciwgYSBzaWduaWZpY2FudCBudW1iZXIgb2YgV0cgbWVtYmVycyBtYXkg bm90IGhhdmUgaGFkIHRoZSBvcHBvcnR1bml0eSB0byByZXNwb25kIChJIGRvbid0IGtub3cgd2hh dCBldmVyeW9uZSBlbHNlJ3MgZXhjdXNlIGlzLi4uKS4gV2Ugd2lsbCBleHRlbmQgdGhlIGFkb3B0 aW9uIGNhbGwgdW50aWwgRmVicnVhcnkgMTMgdW5sZXNzIHRoZXJlIGFyZSBvYmplY3Rpb25zLiAo SWYgdGhlcmUgYXJlIG9iamVjdGlvbnMgZmVlbCBmcmVlIHRvIHVuaWNhc3QgdGhlbSB0byBtZSwg b3Igc2VuZCB0aGVtIHRvIHRoZSBsaXN0LCBhcyB5b3UgcHJlZmVyLikNCiANClRoYW5rcywNCiAN CuKAlEpvaG4NCiANCj4gT24gSmFuIDIxLCAyMDE3LCBhdCAxMDowMyBBTSwgSm9obiBHLiBTY3Vk ZGVyIDxqZ3NAanVuaXBlci5uZXQ+IHdyb3RlOg0KPiANCj4gSGkgQWxsLA0KPiANCj4gVGhlIGF1 dGhvcnMgaGF2ZSByZXF1ZXN0ZWQgSURSIHdvcmtpbmcgZ3JvdXAgYWRvcHRpb24gb2YgZHJhZnQt aHItaWRyLXJmYzU1NzViaXMtMDIgIkRpc3NlbWluYXRpb24gb2YgRmxvdyBTcGVjaWZpY2F0aW9u IFJ1bGVzIi4gUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgbGlzdC4NCj4gDQo+IFRo aXMgYWRvcHRpb24gY2FsbCB3aWxsIGNvbmNsdWRlIG9uIE1vbmRheSwgRmVicnVhcnkgNi4NCj4g DQo+IFRoYW5rcywNCj4gDQo+IOKAlEpvaG4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gSWRyIG1haWxpbmcgbGlzdA0KPiBJZHJAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHINCiANCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJZHIgbWFpbGluZyBsaXN0 DQpJZHJAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRy DQo= ------=_001_NextPart270112303285_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A
Hello All,
<= div>
I support the adoption of your draft. But I want to ask= a question. rfc5575bis is for IPv4, as stated in the abstract. However, I= Pv4 is declared to be historic. Do we still need a RFC specifically design= ed for IPv4? 

Best Regards,
=0A
=0A
lizhenqiang@chinamobile.com
=0A
 
<= div>Date: 2017-02-03 03:49
Subject:&nbs= p;Re: [Idr] WG adoption call for draft-hr-idr-rfc5575bis-02 "Dissemination= of Flow Specification Rules"
Folks,
=0A<= div> 
=0A
It was pointed out to me that due to Chinese New Y= ear, a significant number of WG members may not have had the opportunity t= o respond (I don't know what everyone else's excuse is...). We will extend= the adoption call until February 13 unless there are objections. (If ther= e are objections feel free to unicast them to me, or send them to the list= , as you prefer.)
=0A
 
=0A
Thanks,
=0A
&n= bsp;
=0A
=E2=80=94John
=0A
 
=0A
> On J= an 21, 2017, at 10:03 AM, John G. Scudder <jgs@juniper.net> wrote:=0A
>
=0A
> Hi All,
=0A
>
=0A> The authors have requested IDR working group adoption of draft-hr-i= dr-rfc5575bis-02 "Dissemination of Flow Specification Rules". Please send = your comments to the list.
=0A
>
=0A
> This adopt= ion call will conclude on Monday, February 6.
=0A
>
=0A<= div>> Thanks,=0A
>
=0A
> =E2=80=94John
= =0A
> _______________________________________________
=0A
= > Idr mailing list
=0A
> Idr@ietf.org
=0A
> htt= ps://www.ietf.org/mailman/listinfo/idr
=0A
 
=0A
__= _____________________________________________
=0A
Idr mailing lis= t
=0A
Idr@ietf.org
=0A
https://www.ietf.org/mailman/list= info/idr
=0A=0A ------=_001_NextPart270112303285_=------ From nobody Fri Feb 10 09:49:54 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 DC62D129A15; Fri, 10 Feb 2017 09:49:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148674897689.29316.898334166768442244.idtracker@ietfa.amsl.com> Date: Fri, 10 Feb 2017 09:49:36 -0800 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-16.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 17:49:44 -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 : Extended Message support for BGP Authors : Randy Bush Keyur Patel Dave Ward Filename : draft-ietf-idr-bgp-extended-messages-16.txt Pages : 5 Date : 2017-02-10 Abstract: The BGP specification mandates a maximum BGP message size of 4096 octets. As BGP is extended to support newer AFI/SAFIs, there is a need to extend the maximum message size beyond 4096 octets. This document updates the BGP specification RFC 4271 by providing an extension to BGP to extend its current message size from 4096 octets to 65535 octets. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-extended-messages-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 10 10:27: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 9C5CD129A81 for ; Fri, 10 Feb 2017 10:27:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eaaldXwftKR6 for ; Fri, 10 Feb 2017 10:27:49 -0800 (PST) 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 BE6D2129A80 for ; Fri, 10 Feb 2017 10:27:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20816; q=dns/txt; s=iport; t=1486751268; x=1487960868; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=kFxn2njuxBFMGqkRvLkhHM/AVJOMY3XpYJoYFdzACKw=; b=NGKXbtMDh5G1AA38dfepWSqqB9bRadEfuO17tt07AcyjkIzNWN2fiD/6 tn5T/5sNJSU0YweNxVB3I7vijynarREsn8dEieRIBoxqXk4HrUuYSRhKZ RLKZadGEGJfSV39XsMH16AwmTgA+aOxGNi+paQ3/AbK8vWH1gT020XAYD A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BYAQDMBZ5Y/4cNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9jYYEJB4NSigiSC5U2gg0fAQqFeAIagmE/GAECAQEBAQEBAWI?= =?us-ascii?q?ohGkBAQEDAQEBGwYKQRALAgEIEQMBAQEBIwQDAgICJQsUCQgCBAESCIloCA6wG?= =?us-ascii?q?oIli0kBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYZMhG+EawkWglCCXwWJdItghh4?= =?us-ascii?q?BkgqCBIUXiXOTFAEfOH5PFTyEeoFIdYkSgQwBAQE?= X-IronPort-AV: E=Sophos;i="5.35,142,1484006400"; d="scan'208,217";a="196844246" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Feb 2017 18:27:47 +0000 Received: from xch-rcd-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v1AIRlJD026301 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 10 Feb 2017 18:27:47 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; Fri, 10 Feb 2017 12:27:47 -0600 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; Fri, 10 Feb 2017 12:27:46 -0600 From: "Jakob Heitz (jheitz)" To: "lizhenqiang@chinamobile.com" , John Scudder , idr Thread-Topic: [Idr] WG adoption call for draft-hr-idr-rfc5575bis-02 "Dissemination of Flow Specification Rules" Thread-Index: AQHSc/eQ4UTAgffgtEa6ctzvf3aiWKFWl5SAgAtiBNmAALNN8A== Date: Fri, 10 Feb 2017 18:27:46 +0000 Message-ID: References: <36E285C0-C716-437A-806D-A453273146DD@juniper.net>, <4ADCDBDD-934C-4EE6-8069-CB8A60B39A66@juniper.net> <201702101540202437802@chinamobile.com> In-Reply-To: <201702101540202437802@chinamobile.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.32.152.71] Content-Type: multipart/alternative; boundary="_000_cb6e8bf073524492a6c688369fc197bfXCHALN014ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] WG adoption call for draft-hr-idr-rfc5575bis-02 "Dissemination of Flow Specification Rules" X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 18:27:50 -0000 --_000_cb6e8bf073524492a6c688369fc197bfXCHALN014ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLg0KSVB2NCBpcyBzdGlsbCB2ZXJ5IG11Y2ggaW4gdXNlLCByZWdhcmRsZXNzIG9mIHRoZSAi aGlzdG9yaWMiIGxhYmVsLg0KDQpUaGFua3MsDQpKYWtvYi4NCg0KRnJvbTogSWRyIFttYWlsdG86 aWRyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBsaXpoZW5xaWFuZ0BjaGluYW1vYmls ZS5jb20NClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAwOSwgMjAxNyAxMTo0MCBQTQ0KVG86IEpv aG4gU2N1ZGRlciA8amdzQGp1bmlwZXIubmV0PjsgaWRyIDxpZHJAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBSZTogW0lkcl0gV0cgYWRvcHRpb24gY2FsbCBmb3IgZHJhZnQtaHItaWRyLXJmYzU1NzViaXMt MDIgIkRpc3NlbWluYXRpb24gb2YgRmxvdyBTcGVjaWZpY2F0aW9uIFJ1bGVzIg0KDQpIZWxsbyBB bGwsDQoNCkkgc3VwcG9ydCB0aGUgYWRvcHRpb24gb2YgeW91ciBkcmFmdC4gQnV0IEkgd2FudCB0 byBhc2sgYSBxdWVzdGlvbi4gcmZjNTU3NWJpcyBpcyBmb3IgSVB2NCwgYXMgc3RhdGVkIGluIHRo ZSBhYnN0cmFjdC4gSG93ZXZlciwgSVB2NCBpcyBkZWNsYXJlZCB0byBiZSBoaXN0b3JpYy4gRG8g d2Ugc3RpbGwgbmVlZCBhIFJGQyBzcGVjaWZpY2FsbHkgZGVzaWduZWQgZm9yIElQdjQ/DQoNCkJl c3QgUmVnYXJkcywNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmxpemhlbnFp YW5nQGNoaW5hbW9iaWxlLmNvbQ0KDQpGcm9tOiBKb2huIEcuIFNjdWRkZXI8bWFpbHRvOmpnc0Bq dW5pcGVyLm5ldD4NCkRhdGU6IDIwMTctMDItMDMgMDM6NDkNClRvOiBpZHJAaWV0Zi5vcmc8bWFp bHRvOmlkckBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbSWRyXSBXRyBhZG9wdGlvbiBjYWxsIGZv ciBkcmFmdC1oci1pZHItcmZjNTU3NWJpcy0wMiAiRGlzc2VtaW5hdGlvbiBvZiBGbG93IFNwZWNp ZmljYXRpb24gUnVsZXMiDQpGb2xrcywNCg0KSXQgd2FzIHBvaW50ZWQgb3V0IHRvIG1lIHRoYXQg ZHVlIHRvIENoaW5lc2UgTmV3IFllYXIsIGEgc2lnbmlmaWNhbnQgbnVtYmVyIG9mIFdHIG1lbWJl cnMgbWF5IG5vdCBoYXZlIGhhZCB0aGUgb3Bwb3J0dW5pdHkgdG8gcmVzcG9uZCAoSSBkb24ndCBr bm93IHdoYXQgZXZlcnlvbmUgZWxzZSdzIGV4Y3VzZSBpcy4uLikuIFdlIHdpbGwgZXh0ZW5kIHRo ZSBhZG9wdGlvbiBjYWxsIHVudGlsIEZlYnJ1YXJ5IDEzIHVubGVzcyB0aGVyZSBhcmUgb2JqZWN0 aW9ucy4gKElmIHRoZXJlIGFyZSBvYmplY3Rpb25zIGZlZWwgZnJlZSB0byB1bmljYXN0IHRoZW0g dG8gbWUsIG9yIHNlbmQgdGhlbSB0byB0aGUgbGlzdCwgYXMgeW91IHByZWZlci4pDQoNClRoYW5r cywNCg0K4oCUSm9obg0KDQo+IE9uIEphbiAyMSwgMjAxNywgYXQgMTA6MDMgQU0sIEpvaG4gRy4g U2N1ZGRlciA8amdzQGp1bmlwZXIubmV0PiB3cm90ZToNCj4NCj4gSGkgQWxsLA0KPg0KPiBUaGUg YXV0aG9ycyBoYXZlIHJlcXVlc3RlZCBJRFIgd29ya2luZyBncm91cCBhZG9wdGlvbiBvZiBkcmFm dC1oci1pZHItcmZjNTU3NWJpcy0wMiAiRGlzc2VtaW5hdGlvbiBvZiBGbG93IFNwZWNpZmljYXRp b24gUnVsZXMiLiBQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBsaXN0Lg0KPg0KPiBU aGlzIGFkb3B0aW9uIGNhbGwgd2lsbCBjb25jbHVkZSBvbiBNb25kYXksIEZlYnJ1YXJ5IDYuDQo+ DQo+IFRoYW5rcywNCj4NCj4g4oCUSm9obg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBJZHIgbWFpbGluZyBsaXN0DQo+IElkckBpZXRmLm9yZw0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWRyIG1haWxpbmcgbGlzdA0K SWRyQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0K --_000_cb6e8bf073524492a6c688369fc197bfXCHALN014ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiTHVjaWRhIENvbnNvbGUiOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDQgNSA0IDIgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAU2ltU3VuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMg MSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1pY3Jvc29mdCBZYUhlaSI7 DQoJcGFub3NlLTE6MiAxMSA1IDMgMiAyIDQgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiXEBNaWNyb3NvZnQgWWFIZWkiOw0KCXBhbm9zZS0xOjIgMTEgNSAzIDIgMiA0IDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0 IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VmVyZGFuYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsc2VyaWY7DQoJY29sb3I6IzcwMzBBMDsNCglmb250 LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7DQoJdGV4dC1kZWNvcmF0aW9uOm5v bmUgbm9uZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oyxz ZXJpZjtjb2xvcjojNzAzMEEwIj5ZZXMuPG86cD48L286cD48L3NwYW4+PC9hPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMwQTAiPklQdjQgaXMgc3Rp bGwgdmVyeSBtdWNoIGluIHVzZSwgcmVnYXJkbGVzcyBvZiB0aGUgJnF1b3Q7aGlzdG9yaWMmcXVv dDsgbGFiZWwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDssc2VyaWY7Y29sb3I6IzcwMzBBMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7THVjaWRhIENvbnNvbGUmcXVvdDs7Y29sb3I6IzcwMzBBMCI+VGhh bmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7THVjaWRhIENvbnNvbGUmcXVv dDs7Y29sb3I6IzcwMzBBMCI+SmFrb2IuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZjtjb2xvcjojNzAzMEEwIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IElkciBbbWFpbHRvOmlk ci1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5saXpoZW5xaWFuZ0BjaGlu YW1vYmlsZS5jb208YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEZlYnJ1YXJ5IDA5LCAyMDE3 IDExOjQwIFBNPGJyPg0KPGI+VG86PC9iPiBKb2huIFNjdWRkZXIgJmx0O2pnc0BqdW5pcGVyLm5l dCZndDs7IGlkciAmbHQ7aWRyQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W0lkcl0gV0cgYWRvcHRpb24gY2FsbCBmb3IgZHJhZnQtaHItaWRyLXJmYzU1NzViaXMtMDIgJnF1 b3Q7RGlzc2VtaW5hdGlvbiBvZiBGbG93IFNwZWNpZmljYXRpb24gUnVsZXMmcXVvdDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZ YUhlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5IZWxsbyBBbGwsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj5JIHN1cHBvcnQgdGhlIGFkb3B0aW9uIG9mIHlvdXIgZHJhZnQuIEJ1 dCBJIHdhbnQgdG8gYXNrIGEgcXVlc3Rpb24uIHJmYzU1NzViaXMgaXMgZm9yIElQdjQsIGFzIHN0 YXRlZCBpbiB0aGUgYWJzdHJhY3QuIEhvd2V2ZXIsIElQdjQgaXMgZGVjbGFyZWQgdG8gYmUgaGlz dG9yaWMuDQogRG8gd2Ugc3RpbGwgbmVlZCBhIFJGQyBzcGVjaWZpY2FsbHkgZGVzaWduZWQgZm9y IElQdjQ/Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jv c29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5CZXN0IFJlZ2FyZHMsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtN aWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4NCjxociBzaXplPSIxIiB3aWR0aD0iMjEwIiBz dHlsZT0id2lkdGg6MTU3LjVwdCIgbm9zaGFkZT0iIiBzdHlsZT0iY29sb3I6I0I1QzRERiIgYWxp Z249ImxlZnQiPg0KPC9zcGFuPjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0 OjcuNXB0O21hcmdpbi10b3A6Ny41cHQ7bWFyZ2luLXJpZ2h0OjcuNXB0O21hcmdpbi1ib3R0b206 Ny41cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+bGl6aGVucWlhbmdAY2hpbmFtb2JpbGUuY29tPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi1sZWZ0 OjYuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOiNFRkVGRUYiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8YSBo cmVmPSJtYWlsdG86amdzQGp1bmlwZXIubmV0Ij5Kb2huIEcuDQogU2N1ZGRlcjwvYT48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDojRUZFRkVGIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5EYXRl Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7MjAxNy0wMi0wMyZu YnNwOzAzOjQ5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6I0VGRUZFRiI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+VG86PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJz cDs8YSBocmVmPSJtYWlsdG86aWRyQGlldGYub3JnIj5pZHJAaWV0Zi5vcmc8L2E+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6I0VGRUZFRiI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+U3ViamVj dDo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwO1JlOiBbSWRyXSBX RyBhZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1oci1pZHItcmZjNTU3NWJpcy0wMg0KICZxdW90O0Rp c3NlbWluYXRpb24gb2YgRmxvdyBTcGVjaWZpY2F0aW9uIFJ1bGVzJnF1b3Q7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Rm9sa3Ms DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNy b3NvZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkl0IHdhcyBwb2ludGVkIG91dCB0byBtZSB0 aGF0IGR1ZSB0byBDaGluZXNlIE5ldyBZZWFyLCBhIHNpZ25pZmljYW50IG51bWJlciBvZiBXRyBt ZW1iZXJzIG1heSBub3QgaGF2ZSBoYWQgdGhlIG9wcG9ydHVuaXR5IHRvIHJlc3BvbmQgKEkgZG9u J3Qga25vdyB3aGF0DQogZXZlcnlvbmUgZWxzZSdzIGV4Y3VzZSBpcy4uLikuIFdlIHdpbGwgZXh0 ZW5kIHRoZSBhZG9wdGlvbiBjYWxsIHVudGlsIEZlYnJ1YXJ5IDEzIHVubGVzcyB0aGVyZSBhcmUg b2JqZWN0aW9ucy4gKElmIHRoZXJlIGFyZSBvYmplY3Rpb25zIGZlZWwgZnJlZSB0byB1bmljYXN0 IHRoZW0gdG8gbWUsIG9yIHNlbmQgdGhlbSB0byB0aGUgbGlzdCwgYXMgeW91IHByZWZlci4pPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0 IFlhSGVpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+4oCUPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj5Kb2huPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jv c29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7IE9uIEphbiAyMSwg MjAxNywgYXQgMTA6MDMgQU0sIEpvaG4gRy4gU2N1ZGRlciAmbHQ7amdzQGp1bmlwZXIubmV0Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0Ow0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0 IFlhSGVpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsgSGkgQWxsLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhl aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7DQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyBUaGUgYXV0aG9ycyBoYXZlIHJlcXVlc3RlZCBJRFIg d29ya2luZyBncm91cCBhZG9wdGlvbiBvZiBkcmFmdC1oci1pZHItcmZjNTU3NWJpcy0wMiAmcXVv dDtEaXNzZW1pbmF0aW9uIG9mIEZsb3cgU3BlY2lmaWNhdGlvbiBSdWxlcyZxdW90Oy4gUGxlYXNl IHNlbmQgeW91ciBjb21tZW50cw0KIHRvIHRoZSBsaXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj4mZ3Q7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+Jmd0OyBUaGlzIGFkb3B0aW9uIGNhbGwgd2lsbCBjb25jbHVkZSBvbiBNb25kYXksIEZl YnJ1YXJ5IDYuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsNCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29m dCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7IFRoYW5rcyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFI ZWkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0Ow0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsNCjxzcGFuIGxhbmc9IlpILUNOIj7igJQ8L3NwYW4+ Sm9objxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01p Y3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsgSWRyIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7IElkckBpZXRmLm9yZzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaWRyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01p Y3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj5JZHIgbWFpbGluZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPklkckBpZXRmLm9yZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_cb6e8bf073524492a6c688369fc197bfXCHALN014ciscocom_-- From nobody Fri Feb 10 15:05:48 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 496591293FF; Fri, 10 Feb 2017 15:05:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148676794729.29239.3568551832843388884.idtracker@ietfa.amsl.com> Date: Fri, 10 Feb 2017 15:05:47 -0800 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-17.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 23:05:47 -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 : Extended Message support for BGP Authors : Randy Bush Keyur Patel Dave Ward Filename : draft-ietf-idr-bgp-extended-messages-17.txt Pages : 5 Date : 2017-02-10 Abstract: The BGP specification mandates a maximum BGP message size of 4096 octets. As BGP is extended to support newer AFI/SAFIs, there is a need to extend the maximum message size beyond 4096 octets. This document updates the BGP specification RFC 4271 by providing an extension to BGP to extend its current message size from 4096 octets to 65535 octets. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-extended-messages-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Feb 11 07:58:24 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 07A791298CE; Sat, 11 Feb 2017 07:58:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148682869801.10948.17262077388244269106.idtracker@ietfa.amsl.com> Date: Sat, 11 Feb 2017 07:58:18 -0800 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-shutdown-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2017 15:58:18 -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 : BGP Administrative Shutdown Communication Authors : Job Snijders Jakob Heitz John Scudder Filename : draft-ietf-idr-shutdown-06.txt Pages : 6 Date : 2017-02-11 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-shutdown/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-shutdown-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-shutdown-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 Sat Feb 11 08:02: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 36A501298C6 for ; Sat, 11 Feb 2017 08:02:32 -0800 (PST) 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, 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=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 nEOC1LnOlMoF for ; Sat, 11 Feb 2017 08:02:30 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::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 C05FF1298C5 for ; Sat, 11 Feb 2017 08:02:29 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id r141so68724074wmg.1 for ; Sat, 11 Feb 2017 08:02:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=aTcz3VV9gbdzmNrfN8T3+Z9qlLrlQtiyaEbHIEnljUY=; b=yqEv2Ic9BKiMIQimVbxaE5wCTQ06MNqLugvfvWixlWK3PcCvfhQF7lMgFDEQgz+Q4l Ue7CdvmJtnUCIHokNN7fvyTyzO3dSnBae0SxMCqz+1Y4j3gAFvl1z7KCu0X09BQWQp+2 EcdL1D9NVoxGDWx4LiaCSVe+EiQF/RzBUtP/QvHn8mopcWlSNbMVuq4QCypm4unpGVWn 4uFQdb/3LBJpAuuOLDHWyicdW3RI4lZepceBELNFtLk+qvqs2o7N9KP3Vbn5QKZU2fKF ZTytTMntkoS35jF+CXG1+jebqCr7oyhkfw6HOu0p5dje7wQws+wYYOecSKJuvc2rAcCS Z5RA== 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=aTcz3VV9gbdzmNrfN8T3+Z9qlLrlQtiyaEbHIEnljUY=; b=bI2YRaiQpz1enjhdXFLwq1tvWawnoJmTIFvYrDWGEq7ei2sm0P0i7K1LXurC7DeWh6 1AsyRqoTEBg7MqXIQqSKbTvsa1tzNLnXZyJTJBHhJvtih9jqykDjM6xZpVOrbBELeEDv kgrtG7yHgPpjhQI59xOVYG35+QOMIMF4qoOKuBszFJOcl4KIORsBLM4+Xeq/GtAtf9zg 1TcU7ghgtDqNeUexukK+sfNoyXxK9WhDNZac4uBzssShS7Yo6Jmb9ouBDBkanB1lITlx dFjypL82dcdUAJBLXOJJDzGRc7j2eGcV2kCFpODJIK92hxHvB9uU6913iS7uJX5iJnp+ 3ZZQ== X-Gm-Message-State: AMke39kQjkp1K47skb3RjNVMgygogl7c0goEgME35WlHp/r0BqY4nSa0DFtv2BQ3tUUTNg== X-Received: by 10.28.229.73 with SMTP id c70mr29424035wmh.82.1486828948181; Sat, 11 Feb 2017 08:02:28 -0800 (PST) Received: from localhost ([2001:67c:208c:10:20c9:492e:ef4f:1342]) by smtp.gmail.com with ESMTPSA id t202sm3933133wmt.28.2017.02.11.08.02.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 11 Feb 2017 08:02:27 -0800 (PST) Date: Sat, 11 Feb 2017 17:02:26 +0100 From: Job Snijders To: Lou Berger Message-ID: <20170211160226.GB1049@Vurt.local> References: 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: Mutt/1.7.2 (2016-11-26) Archived-At: Cc: rtg-ads@ietf.org, idr@ietf.org, draft-ietf-idr-shutdown.all@ietf.org, rtg-dir@ietf.org Subject: Re: [Idr] RtgDir review: draft-ietf-idr-shutdown-05 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2017 16:02:32 -0000 Dear Lou, draft-ietf-idr-shutdown-06 was published just now to address your comments. On Thu, Feb 09, 2017 at 08:01:13PM -0500, Lou Berger wrote: > Minor Issues: > In reading the document it's unclear if Shutdown Communication field > must include a trailing zero or not. (I authored something similar once > and had an interop problem where one implementation assumed null > termination was required and included in length, while the other didn't. > Our intent was no null required, but the spec wasn't explicit.) Either > are fine, and given there are implementations you might just want to > have the spec match the implementation. The following clarification has been added to the Shutdown Communication field: "This field is not NUL terminated." https://tools.ietf.org/rfcdiff?url2=draft-ietf-idr-shutdown-06.txt > Nits: > > https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-idr-shutdown-05.txt > reports nits that should be fixed. The abstract and Copyright Notice have been updated to fix the nits. Kind regards, Job From nobody Sun Feb 12 21:09:36 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 3A06512940B; Sun, 12 Feb 2017 21:09:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148696257123.6230.1091581697907899756.idtracker@ietfa.amsl.com> Date: Sun, 12 Feb 2017 21:09:31 -0800 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-18.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 05:09:31 -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 : Extended Message support for BGP Authors : Randy Bush Keyur Patel Dave Ward Filename : draft-ietf-idr-bgp-extended-messages-18.txt Pages : 5 Date : 2017-02-12 Abstract: The BGP specification mandates a maximum BGP message size of 4096 octets. As BGP is extended to support newer AFI/SAFIs, there is a need to extend the maximum message size beyond 4096 octets. This document updates the BGP specification RFC 4271 by providing an extension to BGP to extend its current message size from 4096 octets to 65535 octets. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-extended-messages-18 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 Feb 13 08:11: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 1002F1296D3 for ; Mon, 13 Feb 2017 08:11:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=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, 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 ghXqPMdIy_Zz for ; Mon, 13 Feb 2017 08:11:44 -0800 (PST) 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 D392F1296D0 for ; Mon, 13 Feb 2017 08:11:43 -0800 (PST) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id DCB5020091 for ; Mon, 13 Feb 2017 17:11:41 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.32]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id AA69B2006D for ; Mon, 13 Feb 2017 17:11:41 +0100 (CET) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM32.corporate.adroot.infra.ftgroup ([fe80::8924:188:2124:a046%19]) with mapi id 14.03.0319.002; Mon, 13 Feb 2017 17:11:41 +0100 From: To: "idr@ietf.org" Thread-Topic: [spring] WG Last Call for draft-ietf-spring-segment-routing-central-epe Thread-Index: AdKGETHhzYRD2ynlR5uutzdGOz3fog== Date: Mon, 13 Feb 2017 16:11:40 +0000 Message-ID: <31994_1487002301_58A1DABD_31994_4972_1_53C29892C857584299CBF5D05346208A1ED5DCDA@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/mixed; boundary="_004_53C29892C857584299CBF5D05346208A1ED5DCDAOPEXCLILM21corp_" MIME-Version: 1.0 Archived-At: Subject: [Idr] FW: [spring] WG Last Call for draft-ietf-spring-segment-routing-central-epe X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 16:11:46 -0000 --_004_53C29892C857584299CBF5D05346208A1ED5DCDAOPEXCLILM21corp_ Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A1ED5DCDAOPEXCLILM21corp_" --_000_53C29892C857584299CBF5D05346208A1ED5DCDAOPEXCLILM21corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, FYI, draft-ietf-spring-segment-routing-central-epe is under WG Last Call in= the SPRING WG. It is significantly related to draft-ietf-idr-bgpls-segment-routing-epe-07 = hence this may be of interest to the IDR WG. Comments and review is more than welcomed, on the _SPRING_ mailing list. Thanks, Regards, -- Bruno From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Monday, February 13, 2017 11:08 AM To: spring@ietf.org Subject: [spring] WG Last Call for draft-ietf-spring-segment-routing-centra= l-epe Hello Working Group, This email starts a 2-week Working Group Last Call on draft-ietf-spring-seg= ment-routing-central-epe-03 [1]. Please read the document if you haven't read the most recent version yet, a= nd send your comments to the list, no later than the *27th of February*. Note that this is *not only* a call for comments on the document; it is als= o a call for support (or not) to publish this document as an Informational = RFC. We have already polled for IPR knowledge on this document and all Authors h= ave replied. Two IPR have been disclosed [2]. Thank you M&B [1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-central-e= pe-03 [2] https://datatracker.ietf.org/ipr/search/?id=3Ddraft-ietf-spring-segment= -routing-central-epe&submit=3Ddraft ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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. --_000_53C29892C857584299CBF5D05346208A1ED5DCDAOPEXCLILM21corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

FYI, dr= aft-ietf-spring-segment-routing-central-epe is under WG Last Call in the SP= RING WG.

&n= bsp;

It is s= ignificantly related to draft-ietf-idr-bgpls-segment-routing-epe-07 hence t= his may be of interest to the IDR WG.

&n= bsp;

Comment= s and review is more than welcomed, on the _SPRING_ mailing list.

&n= bsp;

Thanks,=

Regards= ,

-- Brun= o

&n= bsp;

&n= bsp;

From:<= /b> spring [mailto:spring-bounces@ietf.= org] On Behalf Of bruno.decraene@orange.com
Sent: Monday, February 13, 2017 11:08 AM
To: spring@ietf.org
Subject: [spring] WG Last Call for draft-ietf-spring-segment-routing= -central-epe

 

Hello Working Group,

 

This email starts a 2-week W= orking Group Last Call on draft-ietf-spring-segment-routing-central-epe-03 = [1].

 

Please read the document if = you haven't read the most recent version yet, and send your comments to the= list, no later than the *27th of February*.

Note that this is *not only*= a call for comments on the document; it is also a call for support (or not= ) to publish this document as an Informational RFC.

 

We have already polled for I= PR knowledge on this document and all Authors have replied.

Two IPR have been disclosed = [2].

 

Thank you<= /p>

 

M&B

[1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-central-epe-0= 3

[2] https://datatracker.ietf.org/ipr/search/?id=3Ddraft-ietf-spring-segment-rou= ting-central-epe&submit=3Ddraft

 

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
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.
______________________________________________________________________=
___________________________________________________

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.
--_000_53C29892C857584299CBF5D05346208A1ED5DCDAOPEXCLILM21corp_-- --_004_53C29892C857584299CBF5D05346208A1ED5DCDAOPEXCLILM21corp_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=133; creation-date="Mon, 13 Feb 2017 10:08:41 GMT"; modification-date="Mon, 13 Feb 2017 10:08:41 GMT" Content-ID: <79794D3435E748499A03149FB1FB9B57@adroot.infra.ftgroup> Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNwcmluZyBt YWlsaW5nIGxpc3QNCnNwcmluZ0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zcHJpbmcNCg== --_004_53C29892C857584299CBF5D05346208A1ED5DCDAOPEXCLILM21corp_-- From nobody Mon Feb 13 11:22: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 3F10E129863; Mon, 13 Feb 2017 11:22:13 -0800 (PST) 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 MaFp8R1MXpUq; Mon, 13 Feb 2017 11:22:12 -0800 (PST) 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 E003E12985D; Mon, 13 Feb 2017 11:22:11 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.173.13; From: "Susan Hares" To: Date: Mon, 13 Feb 2017 14:17:24 -0500 Message-ID: <009d01d2862d$cf32d0f0$6d9872d0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009E_01D28603.E65D1710" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdKGLaiZEfDhJ6P0TAu4kA+GGr+FUg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: grow@ietf.org Subject: [Idr] 2 week WG LC for draft-ietf-idr-shutdown-02 (1/17 to 1/31/2017) - extended 2 weeks (1/31 to 2/14/2017 - Last Day X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 19:22:13 -0000 This is a multipart message in MIME format. ------=_NextPart_000_009E_01D28603.E65D1710 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The time period for comments on draft-ietf-idr-shutdown was extended for 2 weeks, but in that last 2 weeks there has been no mail regarding this draft. If you were going to comment on this draft, please send it to the idr@ietf.org list within 24 hours. At this point, the result of the 4 week WG LC is that the IDR Working group has reached consensus to publish this draft. The authors have resolved the early review by the routing directorate and there are 6 implementations. Unless something is earth shattering this draft will be sent to the IESG for publication on 2/14/2017. Sue Hares ------=_NextPart_000_009E_01D28603.E65D1710 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The time = period for comments on draft-ietf-idr-shutdown was extended for 2 weeks, = but in that last 2 weeks there has been no mail regarding this = draft.   If you were going to comment on this draft, please = send it to the idr@ietf.org list = within 24 hours. 

 

At this = point, the result of the 4 week WG LC is that the IDR Working group has = reached consensus to publish this draft.  The authors have resolved = the early review by the routing directorate and there are 6 = implementations.   Unless something is earth shattering this = draft will be sent to the IESG for publication on 2/14/2017. =

 

Sue Hares

------=_NextPart_000_009E_01D28603.E65D1710-- From nobody Mon Feb 13 11:23: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 D6A90129866 for ; Mon, 13 Feb 2017 11:23:51 -0800 (PST) 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 lwjL9g7wMu1w for ; Mon, 13 Feb 2017 11:23:51 -0800 (PST) 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 0181112985D for ; Mon, 13 Feb 2017 11:23:50 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.173.13; From: "Susan Hares" To: Date: Mon, 13 Feb 2017 14:18:58 -0500 Message-ID: <00aa01d2862e$07121990$15364cb0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AB_01D28604.1E3C86C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdKGLe+/WbwP+m6VRhWAStdA0wOwUg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] IPR call for draft-ietf-idr-shutdown-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 19:23:52 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00AB_01D28604.1E3C86C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Job, Jakob, and John: Do you know of any IPR related to draft-ietf-idr-shutdown-06.txt? Sue Hares ------=_NextPart_000_00AB_01D28604.1E3C86C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Job, = Jakob, and John:

 

Do you know = of any IPR related to draft-ietf-idr-shutdown-06.txt?

 

Sue Hares =  

------=_NextPart_000_00AB_01D28604.1E3C86C0-- From nobody Mon Feb 13 11:26: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 E729E12985D for ; Mon, 13 Feb 2017 11:26:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.936 X-Spam-Level: X-Spam-Status: No, score=-1.936 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665] 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 hQLpXeDu8jm8 for ; Mon, 13 Feb 2017 11:26:01 -0800 (PST) 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 5E48E129858 for ; Mon, 13 Feb 2017 11:26:01 -0800 (PST) Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88) (envelope-from ) id 1cdMG8-0003lM-Ng (job@us.ntt.net); Mon, 13 Feb 2017 19:26:01 +0000 Date: Mon, 13 Feb 2017 20:25:58 +0100 From: Job Snijders To: Susan Hares Message-ID: <20170213192558.GA1111@hanna.meerval.net> References: <00aa01d2862e$07121990$15364cb0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00aa01d2862e$07121990$15364cb0$@ndzh.com> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] IPR call for draft-ietf-idr-shutdown-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 19:26:02 -0000 Dear Susan, On Mon, Feb 13, 2017 at 02:18:58PM -0500, Susan Hares wrote: > Job, Jakob, and John: > > Do you know of any IPR related to draft-ietf-idr-shutdown-06.txt? I do not know of any IPR related to draft-ietf-idr-shutdown Kind regards, Job From nobody Mon Feb 13 11:54: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 4AAE81298A3 for ; Mon, 13 Feb 2017 11:54:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWGOB-OXvS-B for ; Mon, 13 Feb 2017 11:54:20 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C33A612989D for ; Mon, 13 Feb 2017 11:54:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4420; q=dns/txt; s=iport; t=1487015659; x=1488225259; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=7qRvIGjfUr3g1jSRYKmzoiaIYrhF+orEiSZtmHOz5js=; b=PUfZix7aIiQLGp0GnFCbDvib6qHVTq0ZcYWz6fI4RKchdww/gkg5Xcjw Miq1DFM6dsGXdjeyccuuggx2+/TCeyHzd93Dqz10KQIRZKti3jT3fgHt/ 5qF/B4PvbVmQHyU73Zum+DISp6s52plfWslGA7ZGkiB8UFDVrsHAanFLJ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AkAQD3DaJY/40NJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9jYYEJB41akgyQCoUsggyGHgICAoFuPxgBAgEBAQEBAQFiKIR?= =?us-ascii?q?pAQEBBB0QXAIBCA4DBAEBKAcyFAkIAQEEARIIiWKxI4tKAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBHYZMhG+FCoUvBYl0i2CGHgGSCpEOkxQBHziBAFEVhwB1iSEBgQs?= =?us-ascii?q?BAQE?= X-IronPort-AV: E=Sophos;i="5.35,157,1484006400"; d="scan'208,217";a="383612012" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Feb 2017 19:54:19 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v1DJsIUR015741 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 13 Feb 2017 19:54:19 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 13 Feb 2017 13:54:18 -0600 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; Mon, 13 Feb 2017 13:54:18 -0600 From: "Jakob Heitz (jheitz)" To: Susan Hares , "idr@ietf.org" Thread-Topic: [Idr] IPR call for draft-ietf-idr-shutdown-06.txt Thread-Index: AdKGLe+/WbwP+m6VRhWAStdA0wOwUgABPRQQ Date: Mon, 13 Feb 2017 19:54:18 +0000 Message-ID: <18548365791c440fa5130af260ea2e46@XCH-ALN-014.cisco.com> References: <00aa01d2862e$07121990$15364cb0$@ndzh.com> In-Reply-To: <00aa01d2862e$07121990$15364cb0$@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: [128.107.147.88] Content-Type: multipart/alternative; boundary="_000_18548365791c440fa5130af260ea2e46XCHALN014ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] IPR call for draft-ietf-idr-shutdown-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 19:54:21 -0000 --_000_18548365791c440fa5130af260ea2e46XCHALN014ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have no IPR related to this and know of none. Thanks, Jakob. From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, February 13, 2017 11:19 AM To: idr@ietf.org Subject: [Idr] IPR call for draft-ietf-idr-shutdown-06.txt Job, Jakob, and John: Do you know of any IPR related to draft-ietf-idr-shutdown-06.txt? Sue Hares --_000_18548365791c440fa5130af260ea2e46XCHALN014ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have no = IPR related to this and know of none.

 

Thanks,

Jakob.

 

From: Idr [mailto:idr-bounces@ietf.org] On= Behalf Of Susan Hares
Sent: Monday, February 13, 2017 11:19 AM
To: idr@ietf.org
Subject: [Idr] IPR call for draft-ietf-idr-shutdown-06.txt

 

Job, Jakob, and John:

 

Do you know of any IPR related to draft-ietf-idr-shu= tdown-06.txt?

 

Sue Hares  

--_000_18548365791c440fa5130af260ea2e46XCHALN014ciscocom_-- From nobody Mon Feb 13 11:55: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 400E4129618; Mon, 13 Feb 2017 11:55:56 -0800 (PST) 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 IP-SEhFrsjzn; Mon, 13 Feb 2017 11:55:55 -0800 (PST) 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 CC8D31298C1; Mon, 13 Feb 2017 11:55:53 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=50.36.173.13; From: "Susan Hares" To: References: <00e801d28632$4d9ff0e0$e8dfd2a0$@ndzh.com> In-Reply-To: <00e801d28632$4d9ff0e0$e8dfd2a0$@ndzh.com> Date: Mon, 13 Feb 2017 14:50:51 -0500 Message-ID: <00fd01d28632$7bc96a50$735c3ef0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00FE_01D28608.92F3D780" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG9ovYW/axnpAnXPIULrh0NkNZTdqGRHtdQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: cfilsfil@cisco.com, 'Keyur Patel' , raysaikat@gmail.com, draft-ietf-idr-bgpls-segment-routing-epe@ietf.org Subject: [Idr] FW: IPR call for draft-ietf-idr-bgpls-segment-routing-epe-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 19:55:56 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00FE_01D28608.92F3D780 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit [second posting] Authors of draft-ietf-idr-bgpls-segment-routing-epe-07.txt should indicate whether they know of any IPR related to this document? After all authors have provide their IPR statement, we will begin WG LC. Sue Hares ------=_NextPart_000_00FE_01D28608.92F3D780 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

[second posting] <= /span>

 

Authors of = draft-ietf-idr-bgpls-segment-routing-epe-07.txt should indicate whether = they know of any IPR related to this document?  After all authors = have provide their IPR statement, we will begin WG LC.

 

Sue Hares =

------=_NextPart_000_00FE_01D28608.92F3D780-- From nobody Mon Feb 13 12:01: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 BE6E1124281; Mon, 13 Feb 2017 12:01:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N9Km4NVOFg0L; Mon, 13 Feb 2017 12:01:53 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BFB21296D1; Mon, 13 Feb 2017 12:01:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5836; q=dns/txt; s=iport; t=1487016112; x=1488225712; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=leoC2p1oL46fsuC585KoLk3hpP5ajsgEfbEhCiLcgeQ=; b=bScSIjKEJ8mAnxKTfxiDtoyFztYfxwWLd/W0faFOTuf66p7R3yQRDdK5 KgmCGqPm03q04BoZNskjdVI6xtsKboHjKYbDqRP+odOouNxNjV0kHpBEX Ft9zpmhoiv1cXeyJ7KoMoOt3d0yboixMeL6aAW4T7+Co0B22twMfAdLQE 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AjAQBREKJY/5pdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9jYYEJB41akgyIDId+hSyCDIYiAoFuPxgBAgEBAQEBAQFiKIR?= =?us-ascii?q?pAQEBBB0QTBACAQgOAwMBAigHIREUCQgCBAENBYlSAxWxK4ctDYQQAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBHYs7glGCI4VFBZs4OgGNeoQZkQWKNYhfAR84gQBRFT2?= =?us-ascii?q?GQ3WJIYEMAQEB?= X-IronPort-AV: E=Sophos;i="5.35,157,1484006400"; d="scan'208,217";a="208128965" 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; 13 Feb 2017 20:01:52 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v1DK1pxd012964 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 13 Feb 2017 20:01:52 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 13 Feb 2017 15:01:51 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Mon, 13 Feb 2017 15:01:51 -0500 From: "Acee Lindem (acee)" To: Susan Hares , "idr@ietf.org" Thread-Topic: [Idr] FW: IPR call for draft-ietf-idr-bgpls-segment-routing-epe-07.txt Thread-Index: AQHShjQEC3SMGmY9SEO/3OM0SNuuog== Date: Mon, 13 Feb 2017 20:01:51 +0000 Message-ID: References: <00e801d28632$4d9ff0e0$e8dfd2a0$@ndzh.com> <00fd01d28632$7bc96a50$735c3ef0$@ndzh.com> In-Reply-To: <00fd01d28632$7bc96a50$735c3ef0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.195] Content-Type: multipart/alternative; boundary="_000_D4C77ABA9C40Eaceeciscocom_" MIME-Version: 1.0 Archived-At: Cc: 'Keyur Patel' , "draft-ietf-idr-bgpls-segment-routing-epe@ietf.org" , "Clarence Filsfils \(cfilsfil\)" , "raysaikat@gmail.com" Subject: Re: [Idr] FW: IPR call for draft-ietf-idr-bgpls-segment-routing-epe-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 20:01:55 -0000 --_000_D4C77ABA9C40Eaceeciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As a contributor, I know of no IPR related to this document. Thanks, Acee From: Idr > on behalf of = Susan Hares > Date: Monday, February 13, 2017 at 2:50 PM To: IDR List > Cc: "Clarence Filsfils (cfilsfil)" >, Keyur Patel >, Saikat Ra= y >, "draft-ietf-idr-bgpls-= segment-routing-epe@ietf.org" > Subject: [Idr] FW: IPR call for draft-ietf-idr-bgpls-segment-routing-epe-07= .txt [second posting] Authors of draft-ietf-idr-bgpls-segment-routing-epe-07.txt should indicate = whether they know of any IPR related to this document? After all authors h= ave provide their IPR statement, we will begin WG LC. Sue Hares --_000_D4C77ABA9C40Eaceeciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
As a contributor, I know of no IPR related to this document. 
Thanks,
Acee

From: Idr <idr-bounces@ietf.org> on behalf of Susan Hares &l= t;shares@ndzh.com>
Date: Monday, February 13, 2017 at = 2:50 PM
To: IDR List <idr@ietf.org>
Cc: "Clarence Filsfils (cfilsf= il)" <cfilsfil@cisco.com&= gt;, Keyur Patel <keyur@arrcus.com>, Saikat Ray <raysaikat@gma= il.com>, "draft-ietf-idr-bgpls-segment-routing-epe@ietf.org" <draft-ietf-idr-b= gpls-segment-routing-epe@ietf.org>
Subject: [Idr] FW: IPR call for dra= ft-ietf-idr-bgpls-segment-routing-epe-07.txt

[second posting]

 

Authors of draft-ietf-idr-bgpls-segment-routing-epe-= 07.txt should indicate whether they know of any IPR related to this documen= t?  After all authors have provide their IPR statement, we will begin = WG LC.

 

Sue Hares

--_000_D4C77ABA9C40Eaceeciscocom_-- From nobody Mon Feb 13 13:03: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 2BE331298C6 for ; Mon, 13 Feb 2017 13:03:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.787 X-Spam-Level: X-Spam-Status: No, score=-3.787 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=-1.887, 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=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e_qJdxQ31aTO for ; Mon, 13 Feb 2017 13:03:17 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0128.outbound.protection.outlook.com [104.47.38.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 8952D12940F for ; Mon, 13 Feb 2017 13:03:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=OPo5uQ9PoIgZ8PtN6so5GZFcS7xy8/xRSboUpWg1NzY=; b=O0v7cQPMAYlkflyeditrImNan12hxjGk+uStVKmrEva/0wSi8r0eEZfgw//fG5bXjeVNCa7ot08QoZJFs6pyWwSaQ2nybZNZ4X0J3UK8kfDWF9en1q7/Orab1Ir9fjqGvrb9PHLz80VEon4d4RaJK7ylvw8cFwwpAzYF8tcnAsc= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from [172.29.37.215] (66.129.241.13) by BN3PR05MB2500.namprd05.prod.outlook.com (10.167.3.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.10; Mon, 13 Feb 2017 21:03:15 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_9709FBFC-DF12-414F-B5A9-96A6A3786FB5" MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: <00aa01d2862e$07121990$15364cb0$@ndzh.com> Date: Mon, 13 Feb 2017 16:03:10 -0500 Message-ID: References: <00aa01d2862e$07121990$15364cb0$@ndzh.com> To: Susan Hares X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: BN6PR04CA0016.namprd04.prod.outlook.com (10.172.194.26) To BN3PR05MB2500.namprd05.prod.outlook.com (10.167.3.135) X-MS-Office365-Filtering-Correlation-Id: 7891e7e9-9937-43a8-fcdc-08d45453badc X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR05MB2500; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2500; 3:OKl4E+bTI9nkukqlE6/mkkCqZzJMuablGRMQqGvjdbBm0TeyWlvDa0kOhkiHaoI6A7A5yiSqf6viPgz8vZdSd0ubdAieOaCoPItdsbJa/7Nriy2/ya5bUlTsjPntzBWKavX39DZbd4CT3kNn+kMhOKu7L2Wn+O8qGUAGI80pVeVWR7Pcf/QTZfKKuBaOXvSFHtk3Sn44LS55fvRR97+sWhwr55c0T2XL3ub1Jfi6mVkVML6XGmVjOPdw/YClgu/duDF8+B/1GVN7B7YhvFsVeQ5YdQMcU+5t7ih2QnmGlfU=; 25:x1j6eirP9AOS0QqAe1NzI5Syh7uklaCdCwGs1aC2dYoWn2LgThePXzsgUcs7WSplDBu7i6+Yfr2cYmZWEP8zetvSpwOSZm7DC2J4vQ+H0DA0UgOkV/jDVdza1YfiCLqMI4yMKsSqowv0HiFQPiewlOXI8T2PAFqq1glLuu2ZNSYAFeUSSk5ajT9hgl/MJHRa8RIZo752MNAyflhBfYlaqAv5/cYp64DcYqkWoIgNoqzmbMYoXlmfRpKN+bwWbPqukXW3o5o0ztzXs9HfPVx6ZAPB46z/+26crsMIl6QBBkyBACUKgCmuu5Q+d5prX4LJeMnKioS7SXhW01iwDR9PUhuA4rP5ABIV2hPwLBCqzTwlIUT5BZl1NGAsVwjUsFy94TLYM2M6TXF2E45WTj881sfMHrtYgF7B+USNUQiQLdfrg8g5xfza8kml65QTXgQNNgw7I6hEOVhBgoWUS2J/Uw== X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2500; 31:h7NADBkvm3Jmf1C+V0EV1dljFjA8ApGtZ361p9ZoIRwEWk1cEB0n0jyilw0GT/+vW8ZKwA0tLjfMnErRnJnSSgRBpNxPUFf16t8TIGKmutFRJ+MDqOzh4Pcjn/BsdQzyzshUhqh9v25fTR4sD7GjOx774bra+VpK/6tScto560dYrNwSxgve8L9hcEf/tYUXwckN4NzuyyaPe4YeeZqHEZzBvuwKHFz7qrvLDCfZNe+f5U8v3RhIjntgbBSKFG76; 20:YTBMZVC5UtFt+BJuL97pP7n8SeZwFziihciorDi0rthzMESrhpvj7plY0kgHg0FWjbiTumM3uJFmsjkGWH4FifApVB5mo0x7sk+4T77yocA7yuK0FnBnpJgb+vvGBEysW1F5lXhrlaxZGIlZ31bYVAKEJcuEuTexFfJf2XDhU0UCyyW1eMO27RNVPItXJ9w9Y8EueuVDT0Y/foeKK2Sf0EWiIdJW/ZcPSo8p7w4HERIXyndB+k6CktbkUmxxv59c7fj5fcFTs+k1Smu9ta5s6eJOmyM1HHrVm+OGoj/gD8y2hbxjbH6aeIMJIvjrWUk/PSUubaE9u9jNjLcZdJVYOe/vEHBggjOg2friwgay2IuHLxaOxbOtMdc1jS65Jj4aPCjfMvCMKap23+IQvdsPCj6gmH5/cNpUjTB5HNvkbpZTQvmv/18+ZN53uWhX/mWok2PLBzk2battbJJ1UqXtbZJGDhcj5TNusQeUK4K18PhTQG/jwXUVyXu7s78n1hELD6HfuRoCrqrPgkNQiM9QtGYCzKNFxZZJSQlZWbxoysAxDHe4pVBUJyvUnrpb4oB4MNb13Hn8mj0sYGOpysitPejcVUHMNC/ecMUYXPiGosw= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123558025)(20161123564025)(20161123562025)(20161123555025)(6072148); SRVR:BN3PR05MB2500; BCL:0; PCL:0; RULEID:; SRVR:BN3PR05MB2500; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2500; 4:a1p53ALokeT/xSfIBlMNM7Vj5cT9ela6DpUFauAMZ2RyICPth5HVBzIuRtv18RaalHOPsSPBe/XQvKm6XXbZxJXsEGam5mXRnxhTEEtfJMsllIMLhP8bC5V47XUzyI7abGOGFqZ1Qqq99CuUDg7zHFjM/juifdzwbX4R1E3lQgRWuycaTqmYL0lIQkyveYkPF2hy05/IGuvWt2bUdpYBznX0ZdciWOheo818J6hST70xdystw2lr5oc/wzqRUm6NqK1X3vKWX18vPxkiA4EoKD/W44rDun+yznKj5BtE8eCD+mLC1vV7lcjpDz2xXvQ5TlKrp0VlZg9yNUEbnKivu4cq4uKtjIgVxLX6qDPTff9OSql3YyeETnZ02SefYuoOPbTxSUq5yT5kpxLcQlx0MImHCmg1AJb+wdRfZUnT4RERIZ2W5nCi4M6cilwPA8oucUqk0D0LjDik86LdoD/Ek1ulmSfOBRKYHonsVpVSBIEsB5gwuf4b4u8grwS52JqYMi6Zu8TSTjnV2Obug5435gfbictOs9LS6HHUCa98CTvZAy6YDpcWHweGm/EBZMDzEdvQL86Hj/lhJJ0wUQZY6k7wM5KyUYCtYA5xX82GT16u9lyEN2Vzglvq7iZSBVTw X-Forefront-PRVS: 02176E2458 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(7916002)(39860400002)(39450400003)(39850400002)(39840400002)(39410400002)(199003)(24454002)(377454003)(189002)(5660300001)(82746002)(4326007)(25786008)(66066001)(6306002)(83716003)(101416001)(84326002)(90366009)(6916009)(69556001)(6486002)(236005)(512954002)(81156014)(6246003)(77096006)(86362001)(3846002)(229853002)(6116002)(7736002)(92566002)(53936002)(106356001)(57306001)(105586002)(189998001)(68736007)(33656002)(42186005)(2950100002)(260700001)(97736004)(38730400002)(606005)(36756003)(2906002)(110136004)(50226002)(7906003)(50986999)(81166006)(230783001)(8676002)(6666003)(76176999)(81003)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR05MB2500; H:[172.29.37.215]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR05MB2500; 23:cctaPOSpcNMG1dtROtp/soD56KHPveNTii4fkwYY4?= =?us-ascii?Q?Oot/YpEobVJl4F4gpezCislnTIUi1fIRUZNc5DwfA4o/8C1FyjgBVP4I3Vhj?= =?us-ascii?Q?373AaQormSsb1+xuYhqvEfXFrnLmxq1qpbOkG4vDgc5UvnCYjGZ/pmzn2S/v?= =?us-ascii?Q?RMqEIhnHeKdN4WmtBLUsb5CLYMm7qTCAPsR2sD5e1mmTynOqzTaJ3T8FsynP?= =?us-ascii?Q?CGMoi6/w6vVo7kIADk1HbaQLkfXbk5mmZSdtxZN2nViyCmU82CJ3axeAmcVD?= =?us-ascii?Q?p9HJJfZ1YY0U8EKgmFp0i+xpamUqJprXCog69vIwaqvwCgRVsGzAFZlyWbXU?= =?us-ascii?Q?vrhn6Ujf5qb1y4WXveTjToynprcw0ohWfddYPB4EzLIhlPr48C2wLhmemedY?= =?us-ascii?Q?AorOYOwR71OcyVmCf8D3bujS5jSCqsE4DqtacL9jfgy4q5Nt9xhpgPKgpSm8?= =?us-ascii?Q?wUIep1cCeDMqL+EaQi+msvzo+i/6xZJ53UHq0fg/sywE/jgjQ/Mm85RiNv/P?= =?us-ascii?Q?tZn1tnjVVqv3QF/RH1wDpaXQ5itCtoG1tDnwzA1NeX2TZ4QSIL3HpWGXS81z?= =?us-ascii?Q?gdbUsUp3jfUnEqiSjiRPlqNBx0c8VsOrku/jB5KtTMcz1U0DqaUSw/rdARvA?= =?us-ascii?Q?hfN6MdSZu/+haFt/uWdB7k4lh71mh4vvLu3Pz0HqiqhYmC6/lNN9+vdK0bGD?= =?us-ascii?Q?ux7+WXCuikKs2ac/Tdk3qlCJi9yoMpiyk8zZt4yFQrzlWCno7YMG8nhJ//OJ?= =?us-ascii?Q?p/3jxfdWroGJson8gDqKS1HlW0e1UXbrzYedrYylmYdPxkC3xk8EKwOjWlef?= =?us-ascii?Q?k4Rw5P8FJ9AZEIq4wEo09uTlpZ1r20hZBJR91TNt0J82mbc+wvUKkoK5/0Rq?= =?us-ascii?Q?/LvihYo1c2xdGJ5OdkuNYBK3e2ctNdNcJOROzHtdDVVQ8xriHxDVv7TJSCsv?= =?us-ascii?Q?OFc9V2c/Is5fIKdq/GTHgx+GDM8jVhk8L7M2oPNcnFGTsti2aS6Ob0Tafv1a?= =?us-ascii?Q?dI+kMZlxp7pnObz+YFczyZ1K6eAxc4HkMf3IpKut+EX2B4zgtM1OTHDMnIpL?= =?us-ascii?Q?lqqiYMoUA0ijqFm2+F/wsJOKZGO5IzEHOQ/CNtKJ9M9lJMGfc7OVylgkJlDl?= =?us-ascii?Q?fehxVYHTyRmAHc2UL2qeL+Py2FblFLl7nPfhEmXYf9NTcntsGXG4pIOXrHPP?= =?us-ascii?Q?WwjblgA/+k+hN2P/75KDSHudgVaWhqKM6lIfuiiQeuRI+IMENCpWwjGHn1f0?= =?us-ascii?Q?MxxTNHpgKIMsiGQV1+bk01v+BVxZ3ZRmG2w7Od8lUQE29CQ2gBSrnW4t2SBd?= =?us-ascii?Q?zhEyy8rEScRu5xwjRHoS5Y9CGu0P0fxnmLp0yxscAyn0GVX0zN4KePcT+uFN?= =?us-ascii?Q?n/0PsRUCAUN90fYNhJvJoxbg1TFQJ5wwiHhfmdeSmai5L6CsA1heuQMdYZW+?= =?us-ascii?Q?08lK2mGOGYBwuXGv/hvgyRA/zINvrxxMeLmbJAG/KeA/i5k0z2FH7D+6GYhf?= =?us-ascii?Q?HF7IK4IFnNhMQ=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2500; 6:uliAekAHxOJX3Mq1wEYVNelcCAlgwCKwl+X6qNkYsysljHThlP6hE2y5x6ZKIsa0naH4VmdfZhAHZZ1eYZuBdnh5oNBMVh/X4OrKCsP284mK+1DHT86pBWMDMahNBZOMkjdgP9Hj41jhkoI5FPPtD6iRWNCqymUCwSJo4NzjoZTyfwDtDe/AfF8JXiUxANdWbVltHh7F76l6VARn/2UySRKbvNP3PSJaO7XPkcvrqc7cwdzSsGiC0J8G88ejURmxikIr9UiHkkZ630ztKD3CGlme0WiULPsmngAUo74gEEnEJwJ6haWAAnu6eaqb1V9GwIT9nTCfD1at/dLiNLd3utK/d63ZfsGxhfDVKvDu8UFK00GY3ZD2VY4MR1YSJCHkR/MfG6e7ORITliYY3lE9lVu3UYfBLiaWEdHzgzP9C+Q=; 5:iKxXmNk87E7p2b86POc8EMNhZGpESdHH7njtg5UOY90fRzxgKvurtVmGEX+oehWWLgu9yRum6OlbrLMYru+YefDqjJv0k4M7xO7RUHYaF0jJHPme5hhOLa/4DFbFA4KRmbN37L7jFrRIleRKFFqqPA==; 24:DnvfVB2AeLhADY+0owhH2WW0sVL/y2ZUeBRVGD70gNwML5jP8C8ogVChpVJkGqmsDts0nnUGfcF0yGR4Bz/AMySs3l4Q/a2if6tb+0F3Xq8= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2500; 7:v2xx4+/x0msGEVb38C5p6oVLrCrFFrbGLFRniC24NE+huoEBf+kRXJfDSfc9pI//KyX09o9BSKESNWoiLvCwXuUKr+02Zjf45EaCnmLxO/jK0Jeuqy+fWlOzREns9ZMx3EHQrE+f/W3kent3jAknZNBLx0bPO6G97LR267L7uHacPCAhPk2yHLISbfOKygjPq161aSzTXvA89Zoj9f0iQuW7afcGEspUbqpZj2krCYKPT8fK7k0zWtwxUiwNr+7pnWqOQTLI1/gDLkRAv/U21u3bpWX+aJ0qLoHYDZlt0wZ3fVwoPeWyRPydRg9xptkJmPfyNhJ0iZtB4PiW2hMqm4/ZEb6OdVdw7L4lRJrqpPN5a5/a1HJBuMhbj/QtAgxP0u/wqH4rwagjpM1Xl0B+VBHoV1jkrG+yArd3VpResmMPMjddmtpGo6AX/ZX+o0q2QgHHqADv/Loj9BVZWzF4yfrGubQD4WrpLrTyscAaRZuIR6UEGZotd9H2GUoKRU0Ns2bN2t56IaeMVSQswtaJ1Q== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Feb 2017 21:03:15.4091 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR05MB2500 Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] IPR call for draft-ietf-idr-shutdown-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 21:03:19 -0000 --Apple-Mail=_9709FBFC-DF12-414F-B5A9-96A6A3786FB5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" I'm not aware of any related IPR. --John > On Feb 13, 2017, at 2:18 PM, Susan Hares wrote: >=20 > Job, Jakob, and John:=20 > =20 > Do you know of any IPR related to draft-ietf-idr-shutdown-06.txt?=20 > =20 > Sue Hares =20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr = --Apple-Mail=_9709FBFC-DF12-414F-B5A9-96A6A3786FB5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" I'm not aware of any related IPR.

--John

On = Feb 13, 2017, at 2:18 PM, Susan Hares <shares@ndzh.com> = wrote:

Job, Jakob, and John: 
 
Do you = know of any IPR related to draft-ietf-idr-shutdown-06.txt? 
 
Sue Hares =  
_______________________________________________
Idr mailing = list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

= --Apple-Mail=_9709FBFC-DF12-414F-B5A9-96A6A3786FB5-- From nobody Mon Feb 13 16:40: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 08F6512948B for ; Mon, 13 Feb 2017 16:40:47 -0800 (PST) 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 PVUG8vwaejFO for ; Mon, 13 Feb 2017 16:40:45 -0800 (PST) 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 B6361129404 for ; Mon, 13 Feb 2017 16:40:45 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.173.13; From: "Susan Hares" To: References: In-Reply-To: Date: Mon, 13 Feb 2017 19:35:45 -0500 Message-ID: <001201d2865a$48899340$d99cb9c0$@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: AQLSbtDTPbaPFkju+g7Ymnrg910vup9n1jZA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] FW: WG adoption poll for draft-li-opsawg-ipfix-bgp-community-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 00:40:47 -0000 IDR WG: The OPSAWG chairs are reviewing the draft-li-opsawg-ipfix-bgp-community-02.txt for WG adoption. Please comment on this OPSAWG list and/or IDR list if you feel this draft should be adopted on not adopted. Sue Hares -----Original Message----- From: Tianran Zhou [mailto:zhoutianran@huawei.com] Sent: Sunday, February 12, 2017 10:57 PM To: Susan Hares Subject: FW: WG adoption poll for draft-li-opsawg-ipfix-bgp-community-02 Hi Sue, The OPSAWG is polling for adoption of the I-D (draft-li-opsawg-ipfix-bgp-community-02), which I think is highly related to IDR WG. Could you kindly please forward this to IDR to see if there is any comment and opinion on the WG adoption? Best Regards, Tianran Zhou, OPSAWG Co-Chair -----Original Message----- From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Tianran Zhou Sent: Monday, February 13, 2017 11:37 AM To: opsawg@ietf.org Cc: opsawg-chairs@ietf.org Subject: [OPSAWG] WG adoption poll for draft-li-opsawg-ipfix-bgp-community-02 Dear OPSAWG, In Seoul, we got enough interest and positive response on this IPFIX IE extension draft. By the authors' request, this email starts a formal poll. The chairs would like to know if the WG participants agree that the following document should be adopted as a WG document in OPSAWG. Export BGP community information in IP Flow Information Export (IPFIX) https://tools.ietf.org/html/draft-li-opsawg-ipfix-bgp-community-02 The adoption poll will take two weeks. Please let us know your opinion by Feb 27. It would also be good to hear who is willing to review and/or implement or deploy the extension described in the document. Since we already found that the majority of the f2f participants at our IETF97 session like this idea, please do speak up now if you do not agree or have serious objections (with explanation of course). Regards, Tianran _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From nobody Mon Feb 13 17: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 4ED071294C5 for ; Mon, 13 Feb 2017 17:20:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.388 X-Spam-Level: X-Spam-Status: No, score=-3.388 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=-1.887, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.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 BfJ5r6i3Kxyt for ; Mon, 13 Feb 2017 17:20:38 -0800 (PST) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id A24751294B8 for ; Mon, 13 Feb 2017 17:20:38 -0800 (PST) Received: (qmail 21019 invoked by uid 0); 14 Feb 2017 01:20:38 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy8.mail.unifiedlayer.com with SMTP; 14 Feb 2017 01:20:38 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id kRLa1u00C2SSUrH01RLd9P; Mon, 13 Feb 2017 18:20:38 -0700 X-Authority-Analysis: v=2.1 cv=U+QBU4bu c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=n2v9WMKugxEA:10 a=chpMBs1YAAAA:8 a=48vgC7mUAAAA:8 a=mq7DDRrGh-2hrYAdbiwA:9 a=xumIjo680U8g6UNN:21 a=of6htU0ALLVzg83z:21 a=CjuIK1q_8ugA:10 a=E0lemeZvpN5vfT66OZ8A:22 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject: References:In-Reply-To:Message-ID:Date:CC:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=NXfY3Dm8vFFRKOGB44my8zNLt1Jf36budqUV8iy22so=; b=iD0EFVoVtx89AQVhvfdFcm+kkw U5tXV1P20QI9HxNflcFYR7FmjUG5HryeziHm1VOqql3h+jUisDwno7BMdK9RvWkjk3kYyKVKaGMav 5GdTqkkaZTizDTCg3QBbtoWIv; Received: from [172.56.23.244] (port=40341 helo=[192.0.0.4]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.87) (envelope-from ) id 1cdRnF-00084k-LI; Mon, 13 Feb 2017 18:20:34 -0700 From: Lou Berger To: Job Snijders Date: Mon, 13 Feb 2017 20:20:30 -0500 Message-ID: <15a3a34e348.27fd.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <20170211160226.GB1049@Vurt.local> References: <20170211160226.GB1049@Vurt.local> User-Agent: AquaMail/1.7.2-121 (build: 100700200) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 172.56.23.244 X-Exim-ID: 1cdRnF-00084k-LI X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.0.0.4]) [172.56.23.244]:40341 X-Source-Auth: lberger@labn.net X-Email-Count: 3 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Cc: rtg-ads@ietf.org, idr@ietf.org, draft-ietf-idr-shutdown.all@ietf.org, rtg-dir@ietf.org Subject: Re: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-shutdown-05 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 01:20:40 -0000 Thank you! Lou On February 11, 2017 11:03:06 AM Job Snijders wrote: > Dear Lou, > > draft-ietf-idr-shutdown-06 was published just now to address your > comments. > > On Thu, Feb 09, 2017 at 08:01:13PM -0500, Lou Berger wrote: >> Minor Issues: >> In reading the document it's unclear if Shutdown Communication field >> must include a trailing zero or not. (I authored something similar once >> and had an interop problem where one implementation assumed null >> termination was required and included in length, while the other didn't. >> Our intent was no null required, but the spec wasn't explicit.) Either >> are fine, and given there are implementations you might just want to >> have the spec match the implementation. > > The following clarification has been added to the Shutdown Communication > field: "This field is not NUL terminated." > > https://tools.ietf.org/rfcdiff?url2=draft-ietf-idr-shutdown-06.txt > >> Nits: >> >> https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-idr-shutdown-05.txt >> reports nits that should be fixed. > > The abstract and Copyright Notice have been updated to fix the nits. > > Kind regards, > > Job > > From nobody Mon Feb 13 18:06: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 06EA7129563; Mon, 13 Feb 2017 18:06:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 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] 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 NcIdQZN5sjWA; Mon, 13 Feb 2017 18:06:46 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D191C12896F; Mon, 13 Feb 2017 18:06:44 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DGK86490; Tue, 14 Feb 2017 02:06:42 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 14 Feb 2017 02:06:41 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.116]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0235.001; Tue, 14 Feb 2017 10:06:28 +0800 From: Mach Chen To: Susan Hares , "idr@ietf.org" Thread-Topic: IPR call for draft-ietf-idr-bgpls-segment-routing-epe-07.txt Thread-Index: AdKGMjhMKSoyBO7mRUC4SdgWua1xO///emiA//8RG3A= Date: Tue, 14 Feb 2017 02:06:28 +0000 Message-ID: References: <00e801d28632$4d9ff0e0$e8dfd2a0$@ndzh.com> <00fd01d28632$7bc96a50$735c3ef0$@ndzh.com> In-Reply-To: <00fd01d28632$7bc96a50$735c3ef0$@ndzh.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.194.201] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28FDC46A2SZXEMA510MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.58A26633.0019, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.116, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: b16f301771cef6a1fd338c44559776e7 Archived-At: Cc: "cfilsfil@cisco.com" , 'Keyur Patel' , "raysaikat@gmail.com" , "draft-ietf-idr-bgpls-segment-routing-epe@ietf.org" Subject: Re: [Idr] IPR call for draft-ietf-idr-bgpls-segment-routing-epe-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 02:06:47 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28FDC46A2SZXEMA510MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sue, I am not aware of any IPR related to this document. Best regards, Mach From: Susan Hares [mailto:shares@ndzh.com] Sent: Tuesday, February 14, 2017 3:51 AM To: idr@ietf.org Cc: draft-ietf-idr-bgpls-segment-routing-epe@ietf.org; 'Stefano Previdi (sp= revidi)'; 'Keyur Patel'; Dongjie (Jimmy); Mach Chen; cfilsfil@cisco.com; ra= ysaikat@gmail.com Subject: FW: IPR call for draft-ietf-idr-bgpls-segment-routing-epe-07.txt [second posting] Authors of draft-ietf-idr-bgpls-segment-routing-epe-07.txt should indicate = whether they know of any IPR related to this document? After all authors h= ave provide their IPR statement, we will begin WG LC. Sue Hares --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28FDC46A2SZXEMA510MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sue,

 

I am not aware of any IPR related to this document.

 

Best regards,

Mach

 

From: Susan Hares [mailto:shares@ndzh.com]
Sent: Tuesday, February 14, 2017 3:51 AM
To: idr@ietf.org
Cc: draft-ietf-idr-bgpls-segment-routing-epe@ietf.org; 'Stefano Prev= idi (sprevidi)'; 'Keyur Patel'; Dongjie (Jimmy); Mach Chen; cfilsfil@cisco.= com; raysaikat@gmail.com
Subject: FW: IPR call for draft-ietf-idr-bgpls-segment-routing-epe-0= 7.txt

 

[second= posting]

 

Authors of draft-ietf-idr-bgpls= -segment-routing-epe-07.txt should indicate whether they know of any IPR re= lated to this document?  After all authors have provide their IPR stat= ement, we will begin WG LC.

 

Sue Hares

--_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28FDC46A2SZXEMA510MBXchi_-- From nobody Mon Feb 13 18:32: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 4BCEE12946C; Mon, 13 Feb 2017 18:32:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 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] 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 1yfoh4euLDHo; Mon, 13 Feb 2017 18:32:29 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6411412945F; Mon, 13 Feb 2017 18:32:28 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DGK88749; Tue, 14 Feb 2017 02:32:25 +0000 (GMT) Received: from LHREML710-CAH.china.huawei.com (10.201.108.33) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 14 Feb 2017 02:32:24 +0000 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, 14 Feb 2017 02:32:24 +0000 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, 14 Feb 2017 10:32:15 +0800 From: "Dongjie (Jimmy)" To: Susan Hares , "idr@ietf.org" Thread-Topic: IPR call for draft-ietf-idr-bgpls-segment-routing-epe-07.txt Thread-Index: AdKGMjhMKSoyBO7mRUC4SdgWua1xO///emiA//8Kw+A= Date: Tue, 14 Feb 2017 02:33:18 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C9279357EBB2@NKGEML515-MBX.china.huawei.com> References: <00e801d28632$4d9ff0e0$e8dfd2a0$@ndzh.com> <00fd01d28632$7bc96a50$735c3ef0$@ndzh.com> In-Reply-To: <00fd01d28632$7bc96a50$735c3ef0$@ndzh.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_76CD132C3ADEF848BD84D028D243C9279357EBB2NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.58A26C3A.0213, 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: b16f301771cef6a1fd338c44559776e7 Archived-At: Cc: "cfilsfil@cisco.com" , 'Keyur Patel' , "raysaikat@gmail.com" , "draft-ietf-idr-bgpls-segment-routing-epe@ietf.org" Subject: Re: [Idr] IPR call for draft-ietf-idr-bgpls-segment-routing-epe-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 02:32:31 -0000 --_000_76CD132C3ADEF848BD84D028D243C9279357EBB2NKGEML515MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sue, I am not aware of any IPR related to this document. Best regards, Jie From: Susan Hares [mailto:shares@ndzh.com] Sent: Tuesday, February 14, 2017 3:51 AM To: idr@ietf.org Cc: draft-ietf-idr-bgpls-segment-routing-epe@ietf.org; 'Stefano Previdi (sp= revidi)' ; 'Keyur Patel' ; Dongjie (J= immy) ; Mach Chen ; cfilsfil@cis= co.com; raysaikat@gmail.com Subject: FW: IPR call for draft-ietf-idr-bgpls-segment-routing-epe-07.txt [second posting] Authors of draft-ietf-idr-bgpls-segment-routing-epe-07.txt should indicate = whether they know of any IPR related to this document? After all authors h= ave provide their IPR statement, we will begin WG LC. Sue Hares --_000_76CD132C3ADEF848BD84D028D243C9279357EBB2NKGEML515MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sue,

 

I am not aware of any IPR related to this document.

 

Best regards,

Jie

 

From: Susan Hares [mailto:shares@ndzh.com]
Sent: Tuesday, February 14, 2017 3:51 AM
To: idr@ietf.org
Cc: draft-ietf-idr-bgpls-segment-routing-epe@ietf.org; 'Stefano Prev= idi (sprevidi)' <sprevidi@cisco.com>; 'Keyur Patel' <keyur@arrcus.= com>; Dongjie (Jimmy) <jie.dong@huawei.com>; Mach Chen <mach.ch= en@huawei.com>; cfilsfil@cisco.com; raysaikat@gmail.com
Subject: FW: IPR call for draft-ietf-idr-bgpls-segment-routing-epe-0= 7.txt

 

[second= posting]

 

Authors of draft-ietf-idr-bgpls= -segment-routing-epe-07.txt should indicate whether they know of any IPR re= lated to this document?  After all authors have provide their IPR stat= ement, we will begin WG LC.

 

Sue Hares

--_000_76CD132C3ADEF848BD84D028D243C9279357EBB2NKGEML515MBXchi_-- From nobody Mon Feb 13 21:59: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 E3FAD12940B; Mon, 13 Feb 2017 21:59:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 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] 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 5pKIltu2Q5dT; Mon, 13 Feb 2017 21:59:03 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC6821299BF; Mon, 13 Feb 2017 21:59:01 -0800 (PST) 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 DAO88970; Tue, 14 Feb 2017 05:58:59 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 14 Feb 2017 05:58:58 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Tue, 14 Feb 2017 13:58:54 +0800 From: "Dongjie (Jimmy)" To: "idr@ietf.org" Thread-Topic: Implementation call for draft-ietf-idr-bgp-gr-notification Thread-Index: AdKGbSqNay1/KscbSJGF1t29mMc6jA== Date: Tue, 14 Feb 2017 05:59:56 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C9279357EC8A@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_76CD132C3ADEF848BD84D028D243C9279357EC8ANKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.58A29CA3.0359, 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: 2e36c9e4952a519274830494fbe7d979 Archived-At: Cc: "idr-chairs@ietf.org" Subject: [Idr] Implementation call for draft-ietf-idr-bgp-gr-notification X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 05:59:06 -0000 --_000_76CD132C3ADEF848BD84D028D243C9279357EC8ANKGEML515MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Deal all, The document draft-ietf-idr-bgp-gr-notification has past WG LC, now it is a= waiting implementations. Currently one implementation in JUNOS has been rep= orted, and another implementation is needed. Do you know of any other implementations - partial or full? If so, please r= espond with a note to this email, or send the chairs and the secretary a no= te privately. And the implementors are encouraged to update the implementation report on = the wiki: https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-gr-notific= ation%20implementations Best regards, Jie (as IDR secretary) --_000_76CD132C3ADEF848BD84D028D243C9279357EC8ANKGEML515MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Deal all,

 

The document draft-ietf-idr-bgp= -gr-notification has past WG LC, now it is awaiting implementations. Curren= tly one implementation in JUNOS has been reported, and another implementati= on is needed.

 

Do you know of any other implem= entations - partial or full? If so, please respond with a note to this emai= l, or send the chairs and the secretary a note privately.

 

And the implementors are encour= aged to update the implementation report on the wiki: https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-gr-notification%20im= plementations

 

Best regards,=

Jie (as IDR secretary)

 

--_000_76CD132C3ADEF848BD84D028D243C9279357EC8ANKGEML515MBXchi_-- From nobody Tue Feb 14 10:10:34 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 CA1DA12949F; Tue, 14 Feb 2017 10:10:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148709582882.9946.11698348034112788191.idtracker@ietfa.amsl.com> Date: Tue, 14 Feb 2017 10:10:28 -0800 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-hr-idr-rfc5575bis-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 18:10:29 -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 Robert Raszuk Danny McPherson Christoph Loibl Martin Bacher Filename : draft-hr-idr-rfc5575bis-03.txt Pages : 30 Date : 2017-02-14 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-hr-idr-rfc5575bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-hr-idr-rfc5575bis-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-hr-idr-rfc5575bis-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 Tue Feb 14 10:10:49 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 B605612949F; Tue, 14 Feb 2017 10:10:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148709583074.10063.16046914596249516982.idtracker@ietfa.amsl.com> Date: Tue, 14 Feb 2017 10:10:30 -0800 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-hr-idr-rfc5575bis-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 18:10:31 -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 Robert Raszuk Danny McPherson Christoph Loibl Martin Bacher Filename : draft-hr-idr-rfc5575bis-03.txt Pages : 30 Date : 2017-02-14 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-hr-idr-rfc5575bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-hr-idr-rfc5575bis-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-hr-idr-rfc5575bis-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 Tue Feb 14 10:20: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 909F1129A27; Tue, 14 Feb 2017 10:20:41 -0800 (PST) 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 27z8KdA9p2kW; Tue, 14 Feb 2017 10:20:40 -0800 (PST) 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 1AD81129A1B; Tue, 14 Feb 2017 10:20:38 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.2.125; From: "Susan Hares" To: References: <009d01d2862d$cf32d0f0$6d9872d0$@ndzh.com> In-Reply-To: <009d01d2862d$cf32d0f0$6d9872d0$@ndzh.com> Date: Tue, 14 Feb 2017 13:15:49 -0500 Message-ID: <002101d286ee$5f347ee0$1d9d7ca0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01D286C4.765FFD80" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI8wTBqIWcHpBixufRwO9WbpdSQxaCUWGNw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: grow@ietf.org Subject: Re: [Idr] 2 week WG LC for draft-ietf-idr-shutdown-02 (1/17 to 1/31/2017) - extended 2 weeks (1/31 to 2/14/2017 - Last Day X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 18:20:41 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0022_01D286C4.765FFD80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit There have no additional comments on draf-ietf-idr-shutdown-06.txt. The IDR WG has consensus on this draft that it is ready to publish. It has 6 implementations. It has been sent to the IESG. Sue Hares From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, February 13, 2017 2:17 PM To: idr@ietf.org Cc: grow@ietf.org Subject: [Idr] 2 week WG LC for draft-ietf-idr-shutdown-02 (1/17 to 1/31/2017) - extended 2 weeks (1/31 to 2/14/2017 - Last Day The time period for comments on draft-ietf-idr-shutdown was extended for 2 weeks, but in that last 2 weeks there has been no mail regarding this draft. If you were going to comment on this draft, please send it to the idr@ietf.org list within 24 hours. At this point, the result of the 4 week WG LC is that the IDR Working group has reached consensus to publish this draft. The authors have resolved the early review by the routing directorate and there are 6 implementations. Unless something is earth shattering this draft will be sent to the IESG for publication on 2/14/2017. Sue Hares ------=_NextPart_000_0022_01D286C4.765FFD80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There have no additional comments on = draf-ietf-idr-shutdown-06.txt.  The IDR WG has consensus on this = draft that it is ready to publish.  It has 6 implementations.  = It has been sent to the IESG.

 

Sue Hares =

 

From:= = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan = Hares
Sent: Monday, February 13, 2017 2:17 PM
To: = idr@ietf.org
Cc: grow@ietf.org
Subject: [Idr] 2 week = WG LC for draft-ietf-idr-shutdown-02 (1/17 to 1/31/2017) - extended 2 = weeks (1/31 to 2/14/2017 - Last Day

 

The time = period for comments on draft-ietf-idr-shutdown was extended for 2 weeks, = but in that last 2 weeks there has been no mail regarding this = draft.   If you were going to comment on this draft, please = send it to the idr@ietf.org list = within 24 hours. 

 

At this = point, the result of the 4 week WG LC is that the IDR Working group has = reached consensus to publish this draft.  The authors have resolved = the early review by the routing directorate and there are 6 = implementations.   Unless something is earth shattering this = draft will be sent to the IESG for publication on 2/14/2017. =

 

Sue Hares

------=_NextPart_000_0022_01D286C4.765FFD80-- From nobody Wed Feb 15 12:35:56 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 0B4E412943B; Wed, 15 Feb 2017 12:35:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148719095004.31610.1448007636997500489.idtracker@ietfa.amsl.com> Date: Wed, 15 Feb 2017 12:35:50 -0800 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgpls-segment-routing-epe-08.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 20:35: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 of the IETF. Title : Segment Routing BGP Egress Peer Engineering BGP-LS Extensions Authors : Stefano Previdi Clarence Filsfils Keyur Patel Jie Dong Mach (Guoyi) Chen Filename : draft-ietf-idr-bgpls-segment-routing-epe-08.txt Pages : 21 Date : 2017-02-15 Abstract: Segment Routing (SR) leverages source routing. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service-based. SR allows to enforce a flow through any topological path and service chain while maintaining per-flow state only at the ingress node of the SR domain. The Segment Routing architecture can be directly applied to the MPLS dataplane with no change on the forwarding plane. It requires minor extension to the existing link-state routing protocols. This document outline a BGP-LS extension for exporting BGP peering node topology information (including its peers, interfaces and peering ASs) in a way that is exploitable in order to compute efficient BGP Peering Engineering policies and strategies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-bgpls-segment-routing-epe-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgpls-segment-routing-epe-08 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 Feb 15 15:39: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 8BBAD129BDB; Wed, 15 Feb 2017 15:39:39 -0800 (PST) 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 gvyAMHC0erL4; Wed, 15 Feb 2017 15:39:38 -0800 (PST) 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 4CE17129BCF; Wed, 15 Feb 2017 15:39:38 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.124.244.62; From: "Susan Hares" To: Date: Wed, 15 Feb 2017 18:34:44 -0500 Message-ID: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00FA_01D287BA.2E176E40" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdKH5ALnHgVYM3zURr+F4Gs1EKSVZg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: spring@ietf.org Subject: [Idr] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 23:39:39 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00FA_01D287BA.2E176E40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This begins a 2 week IDR WG last call on draft-ietf-idr-bgpls-segment-routing-epe from (2/15 to 3/1/2017) There are two implementations describe on the wiki at: https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-segment-routing-epe %20 The two implementation are from Cisco IOS-XR release 6.0.2 and Cisco Nexus Switch N9000/N3000 platforms running NX-OS 7.0(3)I1(1) or greater. The authors will indicate on the list and in the wiki the following information : 1) Were these implementations separate implementations? 2) What were the results of the interoperability tests? This work is linked to the draft-ietf-spring-segment-routing-central-epe work in the SPRING WG. Based on the two drafts, the WG should might consider: 1) Is there need for this work in deployments in networks/ 2) Is this technically ready for publication? 3) Does it fit with the spring informational draft? For the ease of reference the web references are below: https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/ https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-central-e pe/ Sue Hares ------=_NextPart_000_00FA_01D287BA.2E176E40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This begins a 2 week IDR WG last call on = draft-ietf-idr-bgpls-segment-routing-epe from (2/15 to 3/1/2017) =    There are two implementations describe on the wiki at: =

https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-= segment-routing-epe%20

 

The two = implementation are from  Cisco IOS-XR release 6.0.2 and Cisco = Nexus Switch N9000/N3000 platforms running NX-OS 7.0(3)I1(1) or = greater.   The authors will indicate on the list and in the = wiki the following information :

 =

1)      = Were = these implementations separate implementations?

2)      = What = were the results of the interoperability tests?

 

This work is linked = to the draft-ietf-spring-segment-routing-central-epe work in the SPRING = WG. Based on the two drafts, the WG should might consider: =  

1)      = Is there = need for this work in deployments in networks/

2)      = Is this = technically ready for publication?

3)      = Does it = fit with the spring informational draft?

 

For the ease of = reference the web references are below:

https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-= routing-epe/

https://datatracker.ietf.org/doc/draft-ietf-spring-segmen= t-routing-central-epe/

 

Sue Hares =

------=_NextPart_000_00FA_01D287BA.2E176E40-- From nobody Wed Feb 15 16:40: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 92FE9129957; Wed, 15 Feb 2017 16:40:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=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 kAzEc3rPeMC7; Wed, 15 Feb 2017 16:40:37 -0800 (PST) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0102.outbound.protection.outlook.com [23.103.201.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 30658120725; Wed, 15 Feb 2017 16:40:37 -0800 (PST) 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=GZNfBI8dp1QTgO9Aj2iU/Gkr/rbHtEAR2SuR8klUw2M=; b=ELFXsWFtlXFzVDqIVGWvZL5MwrHQ/CKUoHMzV5FCzH/BDhCQUfbr86MwFCW88gGVdQCI6XgyierJfz8mAD8HMLQcq63zHfM0kDxKrKA46YXiAXoU/WcUJtNuLT6zGiaSnpWmeqNz9giZnrbk/GOUMJ9s+qChlhrt8ANMulSd4h8= Received: from BL2PR09MB0996.namprd09.prod.outlook.com (10.167.102.15) by BL2PR09MB0994.namprd09.prod.outlook.com (10.167.102.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Thu, 16 Feb 2017 00:40:35 +0000 Received: from BL2PR09MB0996.namprd09.prod.outlook.com ([10.167.102.15]) by BL2PR09MB0996.namprd09.prod.outlook.com ([10.167.102.15]) with mapi id 15.01.0888.030; Thu, 16 Feb 2017 00:40:35 +0000 From: "Borchert, Oliver (Fed)" To: Susan Hares , 'John Scudder' Thread-Topic: Implementation call for draft-ietf-idr-bgp-extended-messages (1/24/2017 to 1/31/2017) Thread-Index: AdJ8sBDDhskHW5f6TcW8KGLFsDty8QBpc3kAAJdU7gABxAtQAA== Date: Thu, 16 Feb 2017 00:40:34 +0000 Message-ID: <944428A7-399E-4DDF-9E65-9FBF94DF3F44@nist.gov> References: <24581E62-94D7-4D2E-8157-21ADF1CE7AF1@nist.gov> <00ff01d280b3$33771830$9a654890$@ndzh.com> In-Reply-To: <00ff01d280b3$33771830$9a654890$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 authentication-results: spf=none (sender IP is ) smtp.mailfrom=oliver.borchert@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.140.59] x-ms-office365-filtering-correlation-id: 65e1f720-28bd-4fc9-5c4a-08d456046ba0 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BL2PR09MB0994; x-microsoft-exchange-diagnostics: 1; BL2PR09MB0994; 7:s3I4S8CwHkWMcUzF8CR2ZsaHkRzEOxvg6lG8bZb0XVJX/hm3s+TDnVU28JmgoXNV8mYg1EkaOi0kq87InMDtAmkDKuAv3Ku7a10jE3DqGBA5a/tOqvZMXtckqrlJktzIvdtDB6OH2C53N1SPfVQrCELn99WAKXi5ueuaFE/T9PimKHOmCyNMxrTYGXfkR05BoO8bwrBSLrlWirHXtviU84J7S78srd94yjR9+q+Z3qhxDxoZH68X/f7j8NnAZ7RrYpLkBd4vTWOFwVviswS2Iw7aACFYDaQDNvIpTOvFsB9vPIe2EEDoB5WRAj+5k36Jjmp69/fVbmH3969nQSrRvA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(20558992708506); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(20161123558025)(6072148); SRVR:BL2PR09MB0994; BCL:0; PCL:0; RULEID:; SRVR:BL2PR09MB0994; x-forefront-prvs: 0220D4B98D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39850400002)(39450400003)(39840400002)(39410400002)(5423002)(199003)(189002)(30584003)(189998001)(102836003)(54356999)(68736007)(230783001)(101416001)(86362001)(6116002)(3846002)(76176999)(1941001)(66066001)(50986999)(105586002)(4001350100001)(3660700001)(389900002)(97736004)(106356001)(4326007)(2906002)(15650500001)(82746002)(8666007)(83506001)(5660300001)(77096006)(122556002)(2950100002)(6486002)(229853002)(81166006)(6506006)(8676002)(305945005)(81156014)(36756003)(8936002)(2900100001)(6436002)(3280700002)(54906002)(38730400002)(6306002)(99286003)(6246003)(6512007)(7736002)(33656002)(53936002)(83716003)(25786008)(92566002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR09MB0994; H:BL2PR09MB0996.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <55F8750CEECFD74C96CF833DC6E9AE6C@namprd09.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2017 00:40:34.9680 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR09MB0994 Archived-At: Cc: "idr-chairs@ietf.org" , "idr@ietf.org" Subject: Re: [Idr] Implementation call for draft-ietf-idr-bgp-extended-messages (1/24/2017 to 1/31/2017) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 00:40:39 -0000 U3VlLA0KV2UgdXBkYXRlZCBvdXIgaW1wbGVtZW50YXRpb25zIGFuZCBiZWxvdyBmaW5kIHRoZSB1 cGRhdGVkIGltcGxlbWVudGF0aW9uIHJlcG9ydHMgZm9yIFF1YWdnYVNSeCBhbmQgQkdQU0VDLUlP Og0KDQpDdXJyZW50IFdpa2kgc3VtbWFyeToNCmh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL2lk ci93aWtpL2RyYWZ0LWlldGYtaWRyLWJncC1leHRlbmRlZC1pbXBsZW1lbnRhdGlvbnMNCg0KMQlB bm5vdW5jZSB2aWEgQkdQIENhcGFiaWxpdHkgYWR2ZXJ0aXNlbWVudCAoUkZDNTQ5MikgYXMgQkdQ IEV4dGVuZGVkIENhcGFiaWxpdHkJWWVzCVllcw0KMglJZiBFeHRlbmRlZCBNZXNzYWdlIENhcGFi aWxpdHkgc3VwcG9ydGVkLCBJbXBsZW1lbnRhdGlvbiBNVVNUIGJlIGFibGUgdG86CS0JLQ0KMmEJ UkVDRUlWRSBPUEVOIG1lc3NhZ2UgbGFyZ2VyIHRoYW4gNDA5NiBieXRlcyAoc2VjdGlvbiA0LCBw YXJhZ3JhcGggMikJWWVzCVllcw0KMmIJUkVDRUlWRSBBIFVQREFURSBtZXNzYWdlIGxhcmdlciB0 YW4gNDA5NiBieXRlcwlZZXMJWWVzDQozCUFwcGxpY2F0aW9ucyBwdXR0aW5nIGRhdGEgaW50byBC R1AgRXh0ZW5kZWQgbWVzc2FnZXMgTVVTVCBsaW1pdCBzaXplIG9mIHBheWxvYWQgdG8gaGFuZGxl IG1heCBtZXNzYWdlIHNpemVzIG9uIHBhdGh3YXkJWWVzCVllcw0KNAlTdXBwb3J0cyBFWFRFTkRF RCBNRVNTQUdFLCBidXQgcGVlciBoYXMgbm90IGFkdmVydGlzZWQgQkdQIEV4dGVuZGVkIENhcGFi aWxpdHkJLQktDQo0YQlTSE9VTEQgTk9UIGFjY2VwdCBtZXNzYWdlCXllcwl5ZXMNCjRiCU1BWSBB Y2NlcHQgRVhURU5ERUQgTUVTU0FHRSAoY29uZmlnL2ltcGxlbWVudGF0aW9uIGtub2IpCVllcwlZ ZXMNCjUJRG9lcyBub3Qgc3VwcG9ydCBFWFRFTkRFRCBNZXNzYWdlIChubyBzdXBwb3J0IGluIGNv ZGUpCQkNCjVhCURvZXMgbm90IHNlbmQgRXh0ZW5kZWQgTWVzc2FnZSBjYXBhYmlsaXR5CQkNCjVi CUlmIHJlY2VpdmVzIEV4dGVuZGVkIE1lc3NhZ2UsIGZvbGxvd3MgUkZDNDIyMSBoYW5kbGluZyBh bmQgc2VuZHMgQmFkIG1lc3NhZ2UgbGVuZ3RoIE5vdGlmaWNhdGlvbgkJDQoNCg0KVXBkYXRlZCBT dW1tYXJ5Og0KDQpRdWFnZ2FTUngNCj09PT09PT09PT0NCjEpIHllcw0KMmEpIOKAkyBEcmFmdCB3 YXMgdXBkYXRlZCDigJMgTi9BDQoyYikgeWVzDQozKSB5ZXMNCjRhKSB5ZXMNCjRiKSB5ZXMNCjVh KSB5ZXMsIGNhbiBiZSBjb25maWd1cmVkDQo1YikgeWVzLCBpZiBjb25maWd1cmVkIHRvIG5vdCBz dXBwb3J0DQoNCkJHUFNFQy1JTw0KPT09PT09PT09DQoxKSB5ZXMNCjJhKSDigJMgRHJhZnQgd2Fz IHVwZGF0ZWQg4oCTIE4vQQ0KMmIpIHllcw0KMykgeWVzDQo0YSkgeWVzDQo0YikgeWVzDQo1YSkg eWVzLCBjYW4gYmUgY29uZmlndXJlZA0KNWIpIHllcywgaWYgY29uZmlndXJlZCB0byBub3Qgc3Vw cG9ydA0KDQpPbGl2ZXINCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCk9saXZlciBCb3JjaGVydCwgQ29tcHV0ZXIgU2NpZW50aXN0 DQpOYXRpb25hbCBJbnN0aXR1dGUgb2YgU3RhbmRhcmRzIGFuZCBUZWNobm9sb2d5DQooUGhvbmUp IDMwMS45NzUuNDg1NiAsIChGYXgpIDMwMS45NzUuNjIzOA0KDQoNCg== From nobody Wed Feb 15 18:35: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 6DCFF129B91; Wed, 15 Feb 2017 18:35:12 -0800 (PST) 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 3u9QjZr44NaV; Wed, 15 Feb 2017 18:35:11 -0800 (PST) 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 8682E129462; Wed, 15 Feb 2017 18:35:11 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1ceBuU-00072l-Fj; Thu, 16 Feb 2017 02:35:06 +0000 Date: Thu, 16 Feb 2017 11:35:04 +0900 Message-ID: From: Randy Bush To: "Borchert, Oliver (Fed)" In-Reply-To: <944428A7-399E-4DDF-9E65-9FBF94DF3F44@nist.gov> References: <24581E62-94D7-4D2E-8157-21ADF1CE7AF1@nist.gov> <00ff01d280b3$33771830$9a654890$@ndzh.com> <944428A7-399E-4DDF-9E65-9FBF94DF3F44@nist.gov> 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: Cc: "idr@ietf.org" , Susan Hares , "idr-chairs@ietf.org" Subject: Re: [Idr] Implementation call for draft-ietf-idr-bgp-extended-messages (1/24/2017 to 1/31/2017) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 02:35:12 -0000 very cool. thanks, oliver. randy From nobody Wed Feb 15 22:36: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 D56081294D3; Wed, 15 Feb 2017 22:36:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 R8_FiP1vFnLr; Wed, 15 Feb 2017 22:35:58 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E34C4127078; Wed, 15 Feb 2017 22:35:57 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAS14155; Thu, 16 Feb 2017 06:35:55 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 16 Feb 2017 06:35:54 +0000 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; Thu, 16 Feb 2017 14:35:49 +0800 From: "Dongjie (Jimmy)" To: "Borchert, Oliver (Fed)" , Susan Hares , "'John Scudder'" Thread-Topic: Implementation call for draft-ietf-idr-bgp-extended-messages (1/24/2017 to 1/31/2017) Thread-Index: AQHSh+1P/OYBoqsipUW+4BJj1wfEZaFrIoHA Date: Thu, 16 Feb 2017 06:36:48 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927935813E7@NKGEML515-MBX.china.huawei.com> References: <24581E62-94D7-4D2E-8157-21ADF1CE7AF1@nist.gov> <00ff01d280b3$33771830$9a654890$@ndzh.com> <944428A7-399E-4DDF-9E65-9FBF94DF3F44@nist.gov> In-Reply-To: <944428A7-399E-4DDF-9E65-9FBF94DF3F44@nist.gov> 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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.58A5484C.0080, 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: ff127dbd12045e7879b873b0fe868305 Archived-At: Cc: "idr-chairs@ietf.org" , "idr@ietf.org" Subject: Re: [Idr] Implementation call for draft-ietf-idr-bgp-extended-messages (1/24/2017 to 1/31/2017) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 06:36:02 -0000 SGkgT2xpdmVyLCANCg0KVGhhbmtzIGZvciB0aGUgdXBkYXRlcyBvZiB0aGUgaW1wbGVtZW50YXRp b24gcmVwb3J0LiBJJ3ZlIHVwZGF0ZWQgdGhlIHdpa2kgcGFnZSBhY2NvcmRpbmdseSwgaW5jbHVk aW5nIHNvbWUgZWRpdG9yaWFsIGNoYW5nZXM6DQoNCmh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFj L2lkci93aWtpL2RyYWZ0LWlldGYtaWRyLWJncC1leHRlbmRlZC1pbXBsZW1lbnRhdGlvbnMNCg0K UGxlYXNlIHJldmlldyBhbmQgbGV0IG1lIGtub3cgaWYgeW91IGhhdmUgYW55IGNvbW1lbnRzLg0K DQpCZXN0IHJlZ2FyZHMsDQpKaWUNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBCb3JjaGVydCwgT2xpdmVyIChGZWQpIFttYWlsdG86b2xpdmVyLmJvcmNoZXJ0QG5pc3Qu Z292XQ0KPiBTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMTYsIDIwMTcgODo0MSBBTQ0KPiBUbzog U3VzYW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbT47ICdKb2huIFNjdWRkZXInIDxqZ3NAanVuaXBl ci5uZXQ+DQo+IENjOiBpZHItY2hhaXJzQGlldGYub3JnOyBpZHJAaWV0Zi5vcmcNCj4gU3ViamVj dDogUmU6IEltcGxlbWVudGF0aW9uIGNhbGwgZm9yIGRyYWZ0LWlldGYtaWRyLWJncC1leHRlbmRl ZC1tZXNzYWdlcw0KPiAoMS8yNC8yMDE3IHRvIDEvMzEvMjAxNykNCj4gDQo+IFN1ZSwNCj4gV2Ug dXBkYXRlZCBvdXIgaW1wbGVtZW50YXRpb25zIGFuZCBiZWxvdyBmaW5kIHRoZSB1cGRhdGVkIGlt cGxlbWVudGF0aW9uDQo+IHJlcG9ydHMgZm9yIFF1YWdnYVNSeCBhbmQgQkdQU0VDLUlPOg0KPiAN Cj4gQ3VycmVudCBXaWtpIHN1bW1hcnk6DQo+IGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL2lk ci93aWtpL2RyYWZ0LWlldGYtaWRyLWJncC1leHRlbmRlZC1pbXBsZW1lbnRhdGlvbnMNCj4gDQo+ IDEJQW5ub3VuY2UgdmlhIEJHUCBDYXBhYmlsaXR5IGFkdmVydGlzZW1lbnQgKFJGQzU0OTIpIGFz IEJHUCBFeHRlbmRlZA0KPiBDYXBhYmlsaXR5CVllcwlZZXMNCj4gMglJZiBFeHRlbmRlZCBNZXNz YWdlIENhcGFiaWxpdHkgc3VwcG9ydGVkLCBJbXBsZW1lbnRhdGlvbiBNVVNUIGJlIGFibGUNCj4g dG86CS0JLQ0KPiAyYQlSRUNFSVZFIE9QRU4gbWVzc2FnZSBsYXJnZXIgdGhhbiA0MDk2IGJ5dGVz IChzZWN0aW9uIDQsIHBhcmFncmFwaCAyKQlZZXMNCj4gCVllcw0KPiAyYglSRUNFSVZFIEEgVVBE QVRFIG1lc3NhZ2UgbGFyZ2VyIHRhbiA0MDk2IGJ5dGVzCVllcwlZZXMNCj4gMwlBcHBsaWNhdGlv bnMgcHV0dGluZyBkYXRhIGludG8gQkdQIEV4dGVuZGVkIG1lc3NhZ2VzIE1VU1QgbGltaXQgc2l6 ZSBvZg0KPiBwYXlsb2FkIHRvIGhhbmRsZSBtYXggbWVzc2FnZSBzaXplcyBvbiBwYXRod2F5CVll cwlZZXMNCj4gNAlTdXBwb3J0cyBFWFRFTkRFRCBNRVNTQUdFLCBidXQgcGVlciBoYXMgbm90IGFk dmVydGlzZWQgQkdQIEV4dGVuZGVkDQo+IENhcGFiaWxpdHkJLQktDQo+IDRhCVNIT1VMRCBOT1Qg YWNjZXB0IG1lc3NhZ2UJeWVzCXllcw0KPiA0YglNQVkgQWNjZXB0IEVYVEVOREVEIE1FU1NBR0Ug KGNvbmZpZy9pbXBsZW1lbnRhdGlvbiBrbm9iKQlZZXMJWWVzDQo+IDUJRG9lcyBub3Qgc3VwcG9y dCBFWFRFTkRFRCBNZXNzYWdlIChubyBzdXBwb3J0IGluIGNvZGUpDQo+IDVhCURvZXMgbm90IHNl bmQgRXh0ZW5kZWQgTWVzc2FnZSBjYXBhYmlsaXR5DQo+IDViCUlmIHJlY2VpdmVzIEV4dGVuZGVk IE1lc3NhZ2UsIGZvbGxvd3MgUkZDNDIyMSBoYW5kbGluZyBhbmQgc2VuZHMgQmFkDQo+IG1lc3Nh Z2UgbGVuZ3RoIE5vdGlmaWNhdGlvbg0KPiANCj4gDQo+IFVwZGF0ZWQgU3VtbWFyeToNCj4gDQo+ IFF1YWdnYVNSeA0KPiA9PT09PT09PT09DQo+IDEpIHllcw0KPiAyYSkg4oCTIERyYWZ0IHdhcyB1 cGRhdGVkIOKAkyBOL0ENCj4gMmIpIHllcw0KPiAzKSB5ZXMNCj4gNGEpIHllcw0KPiA0YikgeWVz DQo+IDVhKSB5ZXMsIGNhbiBiZSBjb25maWd1cmVkDQo+IDViKSB5ZXMsIGlmIGNvbmZpZ3VyZWQg dG8gbm90IHN1cHBvcnQNCj4gDQo+IEJHUFNFQy1JTw0KPiA9PT09PT09PT0NCj4gMSkgeWVzDQo+ IDJhKSDigJMgRHJhZnQgd2FzIHVwZGF0ZWQg4oCTIE4vQQ0KPiAyYikgeWVzDQo+IDMpIHllcw0K PiA0YSkgeWVzDQo+IDRiKSB5ZXMNCj4gNWEpIHllcywgY2FuIGJlIGNvbmZpZ3VyZWQNCj4gNWIp IHllcywgaWYgY29uZmlndXJlZCB0byBub3Qgc3VwcG9ydA0KPiANCj4gT2xpdmVyDQo+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gT2xpdmVyIEJvcmNoZXJ0LCBDb21wdXRlciBTY2llbnRpc3QNCj4gTmF0aW9uYWwgSW5zdGl0 dXRlIG9mIFN0YW5kYXJkcyBhbmQgVGVjaG5vbG9neQ0KPiAoUGhvbmUpIDMwMS45NzUuNDg1NiAs IChGYXgpIDMwMS45NzUuNjIzOA0KPiANCg0K From nobody Thu Feb 16 03:07: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 BA0771294E6; Thu, 16 Feb 2017 03:06:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJzNcKei7-3e; Thu, 16 Feb 2017 03:06:58 -0800 (PST) Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::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 442D9128B38; Thu, 16 Feb 2017 03:06:58 -0800 (PST) Received: by mail-it0-x244.google.com with SMTP id e137so3392645itc.0; Thu, 16 Feb 2017 03:06:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dRveMkycAZhXe4faerwg9TalxraCdHIQRjz3guoCDsI=; b=LR/lpp4EDleWowZbbUQK4eJh2mhl9tXGxY+DhEPHSIGfax8D+Cb35xDqFkEfjeAjUQ 0D6ZK7muGcpFDLsBBwX1cjpVtSidW9Rn459BU1FTeVzCWt/bAKerfQPy0MlkUd+4e2vX yAbyZM4qz+HBZeiZHTPplTsPnp63574t9WeblZxbKt1M9hotkUIrj1zeT2x6rlszjEB5 GsYPzehSO3MgKDj7MtKRi8ODyf8ryYyoBncvtVCrBYOlOkZCouBzWNYUmQBwf3KngpvT Xd8jzlv50nEQVNQdVvSa6DQUcxbmzbbY6N6hb0werilKa/sSGwbVt9OMN6unfUoFz7AF EAGw== 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=dRveMkycAZhXe4faerwg9TalxraCdHIQRjz3guoCDsI=; b=bwzI2VT/KXcF5dEO/9lH5yBsctkXoBiEFTXWBazBLVR3I8lLZY2yIihBP/kXtHzE/q 5JOLUtZ3eMiLMVckm5nTv64jYaG9H70Pcy2QqGYbSvcC2Iu7ITz7PL5qTIhsebGLSUj2 N2KLcoVhYVf6xJhKl5Xg1cL9wyZagekGi+3z9udcsYnaI/yZv2wlpLMSn4jbHU+Z2xS/ hoPOGyvpotEKNl1lkHtUzPXwnFOc355lMEHSAoACLqiHoKkxZL+ilE4R/JPOYeeklk7h vYIToxnplvbrsrM9SUj2Ll0YWWqGi5H6JrYuyMk2A/CktiSGSL8Y+tQy6Unuv/uJgylc 9uuA== X-Gm-Message-State: AMke39nXQ6Ez2NtJnj4lAyWlLnAEFaw2UMWrAMCrFDwkhUDoPKQODmG8hNJNgbBTnsbbSA== X-Received: by 10.36.48.208 with SMTP id q199mr1672565itq.28.1487243217633; Thu, 16 Feb 2017 03:06:57 -0800 (PST) Received: from [22.70.247.45] ([172.56.13.228]) by smtp.gmail.com with ESMTPSA id m198sm4063388itg.1.2017.02.16.03.06.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Feb 2017 03:06:56 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-B2938CC4-65DC-4FBC-BB82-43E725A02EF5 Mime-Version: 1.0 (1.0) From: Jeff Tantsura X-Mailer: iPhone Mail (14D27) In-Reply-To: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> Date: Thu, 16 Feb 2017 11:06:53 +0000 Content-Transfer-Encoding: 7bit Message-Id: <1E319B28-BF06-4BEB-9D27-552530FC21EA@gmail.com> References: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> To: Susan Hares Archived-At: Cc: idr@ietf.org, spring@ietf.org Subject: Re: [Idr] [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 11:06:59 -0000 --Apple-Mail-B2938CC4-65DC-4FBC-BB82-43E725A02EF5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Yes/support Regards, Jeff > On Feb 15, 2017, at 23:34, Susan Hares wrote: >=20 > This begins a 2 week IDR WG last call on draft-ietf-idr-bgpls-segment-rout= ing-epe from (2/15 to 3/1/2017) There are two implementations describe on= the wiki at: > https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-segment-routing-e= pe%20 > =20 > The two implementation are from Cisco IOS-XR release 6.0.2 and Cisco Nexu= s Switch N9000/N3000 platforms running NX-OS 7.0(3)I1(1) or greater. The a= uthors will indicate on the list and in the wiki the following information := > =20 > 1) Were these implementations separate implementations? > 2) What were the results of the interoperability tests? > =20 > This work is linked to the draft-ietf-spring-segment-routing-central-epe w= ork in the SPRING WG. Based on the two drafts, the WG should might consider:= =20 > 1) Is there need for this work in deployments in networks/ > 2) Is this technically ready for publication? > 3) Does it fit with the spring informational draft? > =20 > For the ease of reference the web references are below: > https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/= > https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-central= -epe/ > =20 > Sue Hares > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring --Apple-Mail-B2938CC4-65DC-4FBC-BB82-43E725A02EF5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Yes/support

Regards,
Jeff

On Feb 15, 2017, at 23:34, Susan Hares <shares@ndzh.com> wrote:

This begins a 2 week IDR WG last c= all on draft-ietf-idr-bgpls-segment-routing-epe from (2/15 to 3/1/2017) &nbs= p;  There are two implementations describe on the wiki at:

https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-segment-= routing-epe%20

 

The two implementation are from  Cisco= IOS-XR release 6= .0.2 and Cisco Nexus Switch N9000/N3000 platforms running NX-OS 7.0(3)I1(1) o= r greater.   The authors will indicate on the list and in the wiki= the following information :

 = ;

1)      Were these implementa= tions separate implementations?

2) &n= bsp;    What were the results of the interoperability tests?

&= nbsp;

This work is linked to the draft-ietf-spring-segment-routing-central-epe w= ork in the SPRING WG. Based on the two drafts, the WG should might consider:=  

1)      = Is there need for this= work in deployments in networks/

2)   =    Is this technically ready for publication?

3)&nbs= p;     Does it fit with the spring informational draft?

&= nbsp;

For the ease of reference the web references are below: =

https= ://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/

<= a href=3D"https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing= -central-epe/">https://datatracker.ietf.org/doc/draft-ietf-spring-segment-ro= uting-central-epe/

 

<= span style=3D"font-size:12.0pt">Sue Hares

=
__________________________= _____________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailm= an/listinfo/spring
= --Apple-Mail-B2938CC4-65DC-4FBC-BB82-43E725A02EF5-- From nobody Thu Feb 16 03:13:42 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 BBA5B129A15; Thu, 16 Feb 2017 03:13:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148724361376.15968.15608427441487593735.idtracker@ietfa.amsl.com> Date: Thu, 16 Feb 2017 03:13:33 -0800 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgpls-segment-routing-epe-09.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 11:13:33 -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 : Segment Routing BGP Egress Peer Engineering BGP-LS Extensions Authors : Stefano Previdi Clarence Filsfils Keyur Patel Saikat Ray Jie Dong Mach (Guoyi) Chen Filename : draft-ietf-idr-bgpls-segment-routing-epe-09.txt Pages : 21 Date : 2017-02-16 Abstract: Segment Routing (SR) leverages source routing. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service-based. SR allows to enforce a flow through any topological path and service chain while maintaining per-flow state only at the ingress node of the SR domain. The Segment Routing architecture can be directly applied to the MPLS dataplane with no change on the forwarding plane. It requires minor extension to the existing link-state routing protocols. This document outline a BGP-LS extension for exporting BGP peering node topology information (including its peers, interfaces and peering ASs) in a way that is exploitable in order to compute efficient BGP Peering Engineering policies and strategies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-bgpls-segment-routing-epe-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgpls-segment-routing-epe-09 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 Feb 16 03:30: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 30FB1129A8C; Thu, 16 Feb 2017 03:30:43 -0800 (PST) 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 5mAu1fcu5cC0; Thu, 16 Feb 2017 03:30:41 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C40912955F; Thu, 16 Feb 2017 03:30:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2017; q=dns/txt; s=iport; t=1487244640; x=1488454240; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=CzCHvWf8W90fqX/1IPeER+in+x8BdJ4EvGwa7MQ880Q=; b=hLzOHfFpyOi7nwCqqmJIFbnAWivNKw6Swb7u7O4Y8ukgAxmmtnFKnBM3 L/gP8w4R2ajm+WGA63OgbjkeAnceFOmxKzGTN5VKyUFSRz1B8XyZbu870 yubSSyzywldSfL3MhCqvctYEu0v9uTkiH109TvE1YLvP+xAuqN1ZjDTa9 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQCnjKVY/49dJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQkHjVqSEJUzggwfDYUsSgKCHT8YAQIBAQEBAQEBYiiEcAE?= =?us-ascii?q?BAQMBAQE4NAsFCwIBCA4KHgULJwslAQEEDgWJZAgOsi+LOwEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBARgFhkyCBYJqhFSDNIIxBZVYhiMBhm+LJpEGkxYBHziBAFEVPRE?= =?us-ascii?q?BhGqBSHWJKoEMAQEB?= X-IronPort-AV: E=Sophos;i="5.35,168,1484006400"; d="scan'208";a="207458687" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Feb 2017 11:30:39 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v1GBUdWe029030 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 16 Feb 2017 11:30:39 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 16 Feb 2017 06:30:38 -0500 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Thu, 16 Feb 2017 06:30:38 -0500 From: "Stefano Previdi (sprevidi)" To: Susan Hares Thread-Topic: [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) Thread-Index: AdKH5ALnHgVYM3zURr+F4Gs1EKSVZgAjf1oA Date: Thu, 16 Feb 2017 11:30:38 +0000 Message-ID: <49CD63A7-AA91-47D5-A1D8-69FDECD6AE15@cisco.com> References: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> In-Reply-To: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.209.26] Content-Type: text/plain; charset="us-ascii" Content-ID: <4DD45BCFE8FA9D49827211F395761D32@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: idr wg , "spring@ietf.org" Subject: Re: [Idr] [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 11:30:43 -0000 > On Feb 16, 2017, at 12:34 AM, Susan Hares wrote: >=20 > This begins a 2 week IDR WG last call on draft-ietf-idr-bgpls-segment-rou= ting-epe from (2/15 to 3/1/2017) There are two implementations describe = on the wiki at:=20 > https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-segment-routing-= epe%20 > =20 > The two implementation are from Cisco IOS-XR release 6.0.2 and Cisco Nex= us Switch N9000/N3000 platforms running NX-OS 7.0(3)I1(1) or greater. The= authors will indicate on the list and in the wiki the following informatio= n : > =20 > 1) Were these implementations separate implementations?=20 yes. > 2) What were the results of the interoperability tests?=20 the two implementations are interoperable on the set of features they suppo= rt. See https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-segment-ro= uting-epe%20 for details. > This work is linked to the draft-ietf-spring-segment-routing-central-epe = work in the SPRING WG. Based on the two drafts, the WG should might conside= r: =20 > 1) Is there need for this work in deployments in networks/=20 yes. This work has been triggered after several operators requirements for = egress traffic engineering. > 2) Is this technically ready for publication?=20 the authors believe so. > 3) Does it fit with the spring informational draft?=20 yes. The use-case draft describing EPE (draft-ietf-spring-segment-routing-c= entral-epe) has been adopted as WG doc in SPRING and it started the shepher= d review. Thanks. s. > For the ease of reference the web references are below:=20 > https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe= / > https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-centra= l-epe/ > =20 > Sue Hares=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Thu Feb 16 03:34: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 43A4F129A1C; Thu, 16 Feb 2017 03:34:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYuY4_XBzw15; Thu, 16 Feb 2017 03:34:04 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89E7D1299A9; Thu, 16 Feb 2017 03:34:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12880; q=dns/txt; s=iport; t=1487244844; x=1488454444; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DIQM70veXD/80/B4LkqN3fryBvZdOFCInqkBfcUlEO4=; b=ToNwb3W6epGowNYmngg3wtNrrzqPY8Pf/d7x5VjU25Rd3nVQ1Po68ZfH B/XSDajhdRdCdbe3X8tTdeSmDiLbpbX5/K1bqbA1dQW/buh3PxZVtUvlR n1QdNwXaWxmAcYiu2dToSv5ryoKWh4ZXbOPiXQiDTFQRaXl7EltN0foxB o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BjAQDZjKVY/5RdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9iYYEJB41akhCQB4UsggwshXYCgh0/GAECAQEBAQEBAWIohHA?= =?us-ascii?q?BAQEELUwQAgEIDgMEAQEkBAcyFAkIAQEEAQ0FCIlkDrIyizsBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEYBYZMhG+FCoUvBZVYhiMBhm+LHZEPkxYBHziBAFEVPYR8gUh?= =?us-ascii?q?1iSqBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,168,1484006400"; d="scan'208,217";a="181210320" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Feb 2017 11:34:03 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v1GBY3df027375 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 16 Feb 2017 11:34:03 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 16 Feb 2017 05:34:02 -0600 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, 16 Feb 2017 05:34:02 -0600 From: "Ketan Jivan Talaulikar (ketant)" To: Susan Hares , "idr@ietf.org" Thread-Topic: [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) Thread-Index: AdKH5ALnHgVYM3zURr+F4Gs1EKSVZgAZHD7g Date: Thu, 16 Feb 2017 11:34:02 +0000 Message-ID: <79d597ffee2d4231af7d0e0439fca3d6@XCH-ALN-008.cisco.com> References: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> In-Reply-To: <00f901d287e4$16ecb2f0$44c618d0$@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.65.54.241] Content-Type: multipart/alternative; boundary="_000_79d597ffee2d4231af7d0e0439fca3d6XCHALN008ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" Subject: Re: [Idr] [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 11:34:06 -0000 --_000_79d597ffee2d4231af7d0e0439fca3d6XCHALN008ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support this draft. Thanks, Ketan From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Susan Hares Sent: 16 February 2017 05:05 To: idr@ietf.org Cc: Alvaro Retana (aretana) ; spring@ietf.org Subject: [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routi= ng-epe - (2/15/2017 to 3/1/2017) This begins a 2 week IDR WG last call on draft-ietf-idr-bgpls-segment-routi= ng-epe from (2/15 to 3/1/2017) There are two implementations describe on= the wiki at: https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-segment-routing-ep= e%20 The two implementation are from Cisco IOS-XR release 6.0.2 and Cisco Nexus= Switch N9000/N3000 platforms running NX-OS 7.0(3)I1(1) or greater. The a= uthors will indicate on the list and in the wiki the following information = : 1) Were these implementations separate implementations? 2) What were the results of the interoperability tests? This work is linked to the draft-ietf-spring-segment-routing-central-epe wo= rk in the SPRING WG. Based on the two drafts, the WG should might consider: 1) Is there need for this work in deployments in networks/ 2) Is this technically ready for publication? 3) Does it fit with the spring informational draft? For the ease of reference the web references are below: https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/ https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-central-= epe/ Sue Hares --_000_79d597ffee2d4231af7d0e0439fca3d6XCHALN008ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support this draft.

 

Thanks,

Ketan

 

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Susan Hares
Sent: 16 February 2017 05:05
To: idr@ietf.org
Cc: Alvaro Retana (aretana) <aretana@cisco.com>; spring@ietf.o= rg
Subject: [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segmen= t-routing-epe - (2/15/2017 to 3/1/2017)

 

This= begins a 2 week IDR WG last call on draft-ietf-idr-bgpls-segment-routing-e= pe from (2/15 to 3/1/2017)    There are two implementations = describe on the wiki at:

https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-segme= nt-routing-epe%20

 

The = two implementation are from  Cisco IOS-XR release 6= .0.2 and Cisco Nexus Switch N9000/N3000 platforms running NX-OS 7.0(3)I1(1)= or greater.   The authors will indicate on the list and in the w= iki the following information :

 

1)     Were these implementations separate implementations?

2)     What were the results of the interoperability tests?

 

This= work is linked to the draft-ietf-spring-segment-routing-central-epe work i= n the SPRING WG. Based on the two drafts, the WG should might consider: &nb= sp;

1)     Is there need for this work in deployments in networks/

2)     Is this technically ready for publication?

3)     Does it fit with the spring informational draft?

 

For = the ease of reference the web references are below:

https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routi= ng-epe/

https://datatracker.ietf.org/doc/draft-ietf-spring-segment-rou= ting-central-epe/

 

Sue = Hares

--_000_79d597ffee2d4231af7d0e0439fca3d6XCHALN008ciscocom_-- From nobody Thu Feb 16 04:39: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 39D31129578; Thu, 16 Feb 2017 04:39:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, 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 Gl_-wejMlpmn; Thu, 16 Feb 2017 04:39:45 -0800 (PST) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::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 AE621129566; Thu, 16 Feb 2017 04:39:45 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id v23so12732302qtb.0; Thu, 16 Feb 2017 04:39:45 -0800 (PST) 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=CShJalkfJaqeJPB4jcsSd0Y9jT7UQG+kcq1WKonSMgo=; b=mdByE9V/1bjVR1nOWElIQ0o0lgolPWRa3NnxzDsJUL0ZXmqaXyvd+EkG6GI6MOgKFG H8r+BNf8vfwmHphYX3x9+deI5UFn2NanzOXqeXiaIatgIwAeyu1RpdLcXiF17tNjqVqK e4sd4uvoK1zLCmcpMyzRu/RETFjaqt3iEuH6p0OgnFvt7es64ExfTUUl/GuySeiJ0FRh elSUsykbaFZ6S6D9/Mj2/XioSMFPhPCFsOTMXAQ5uu3ApI+kvDNTl1moP24ExZNX/V5a ekwzgyW/hDOzSx/BPuqhCwQhsg9SYXnnEeAXCapS0a3lPaJXUFqSlF8lKru1Oj9sgA+C OEvA== 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=CShJalkfJaqeJPB4jcsSd0Y9jT7UQG+kcq1WKonSMgo=; b=PiSQB5ozHxecnU7FsXDMMN+gfDm9RXwsMhZzx5VJENmHhew+p2estH5QW+184jrDdH nBDF5USJY0VEifWHxins+NHdZvzhaH0AhmYiW289swLJ/yd8cCWStDldCJXI149PaLHe EoZ4O4d8arbei0LlPloZ8SbcJlTD7+0GcDl0oqSmSCGRFCJ5efY7GOE5SInekYVZP3hK Z0sysryEkD3bQh/xdcBlFHaScNBo0o4dSi7ferwV4U0kU6Nx9nedcR5g4p9166Vkb+Zc niMr0nB6f2W1wOsWtGsuV3hDT6DaXzGVfzjkTeVK9sjkmm0dQ46FADwLrjU8qzGTRV9b hiWA== X-Gm-Message-State: AMke39lrqILAG5+W87i1spFaRW/R0HtTUwAnQjOh7QM2mSA/DJ2TAw90LxhLbjbn/n6ulELjxoODBnipaMP/7Q== X-Received: by 10.237.43.36 with SMTP id p33mr1579215qtd.199.1487248784684; Thu, 16 Feb 2017 04:39:44 -0800 (PST) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.140.28.69 with HTTP; Thu, 16 Feb 2017 04:39:44 -0800 (PST) Received: by 10.140.28.69 with HTTP; Thu, 16 Feb 2017 04:39:44 -0800 (PST) In-Reply-To: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> References: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> From: Robert Raszuk Date: Thu, 16 Feb 2017 13:39:44 +0100 X-Google-Sender-Auth: ztrt8OKRQsz4_hFRuEanuIAi-e8 Message-ID: To: Susan Hares Content-Type: multipart/alternative; boundary=94eb2c12507e80fcb40548a517fd Archived-At: Cc: idr wg , spring@ietf.org Subject: Re: [Idr] [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 12:39:47 -0000 --94eb2c12507e80fcb40548a517fd Content-Type: text/plain; charset=UTF-8 Support. Thx R. On Feb 15, 2017 6:39 PM, "Susan Hares" wrote: > This begins a 2 week IDR WG last call on draft-ietf-idr-bgpls-segment-routing-epe > from (2/15 to 3/1/2017) There are two implementations describe on the > wiki at: > > https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls- > segment-routing-epe%20 > > > > The two implementation are from Cisco IOS-XR release 6.0.2 and Cisco > Nexus Switch N9000/N3000 platforms running NX-OS 7.0(3)I1(1) or greater. > The authors will indicate on the list and in the wiki the following > information : > > > > 1) Were these implementations separate implementations? > > 2) What were the results of the interoperability tests? > > > > This work is linked to the draft-ietf-spring-segment-routing-central-epe > work in the SPRING WG. Based on the two drafts, the WG should might > consider: > > 1) Is there need for this work in deployments in networks/ > > 2) Is this technically ready for publication? > > 3) Does it fit with the spring informational draft? > > > > For the ease of reference the web references are below: > > https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/ > > https://datatracker.ietf.org/doc/draft-ietf-spring-segment- > routing-central-epe/ > > > > Sue Hares > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > --94eb2c12507e80fcb40548a517fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Support.

Thx=
R.

On Feb 15, 2017 6:39 PM, "Susan Hares" <<= a href=3D"mailto:shares@ndzh.com">shares@ndzh.com> wrote:

This begins a 2 week IDR= WG last call on draft-ietf-idr-bgpls-segment-routing-epe from (2/15 t= o 3/1/2017) =C2=A0=C2=A0=C2=A0There are two implementations describe on the= wiki at:

https://trac.ietf.org/tr= ac/idr/wiki/draft-ietf-idr-bgpls-segment-routing-epe%20

= =C2=A0

The two implementation are from = =C2=A0Cisco IOS-= XR release 6.0.2 and Cisco Nexus Switch N9000/N3000 platforms running NX-OS= 7.0(3)I1(1) or greater.=C2=A0=C2=A0 The authors will indicate on the list = and in the wiki the following information :

=

=C2=A0

= 1)=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 W= ere these implementations separate implementations?

2)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 What were the results of the interoperab= ility tests?

=C2=A0

This work is linked to the draft-ietf-spring= -segment-routing-central-epe work in the SPRING WG. Based on the two d= rafts, the WG should might consider: =C2=A0

1)=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Is there need for this work in deployments in networks/

<= /u>2)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Is this technically ready for publ= ication?

3)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Does it fit with the= spring informational draft?

=C2=A0

For the ease of reference t= he web references are below:

https://da= tatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/<= /a>

https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-central-epe/

= =C2=A0

Sue Hares


___________________= ____________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
--94eb2c12507e80fcb40548a517fd-- From nobody Thu Feb 16 05:07:55 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 595C5129CEF; Thu, 16 Feb 2017 05:07:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148725047135.16000.6989017029280831465.idtracker@ietfa.amsl.com> Date: Thu, 16 Feb 2017 05:07:51 -0800 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-19.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 13:07: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 of the IETF. Title : Extended Message support for BGP Authors : Randy Bush Keyur Patel Dave Ward Filename : draft-ietf-idr-bgp-extended-messages-19.txt Pages : 5 Date : 2017-02-16 Abstract: The BGP specification mandates a maximum BGP message size of 4096 octets. As BGP is extended to support newer AFI/SAFIs, there is a need to extend the maximum message size beyond 4096 octets. This document updates the BGP specification RFC 4271 by providing an extension to BGP to extend its current message size from 4096 octets to 65535 octets. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-extended-messages-19 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 Feb 16 05:28:13 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 C52571295C9; Thu, 16 Feb 2017 05:28:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148725168780.15892.12762124755097357411.idtracker@ietfa.amsl.com> Date: Thu, 16 Feb 2017 05:28:07 -0800 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-20.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 13:28:08 -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 : Extended Message support for BGP Authors : Randy Bush Keyur Patel Dave Ward Filename : draft-ietf-idr-bgp-extended-messages-20.txt Pages : 5 Date : 2017-02-16 Abstract: The BGP specification mandates a maximum BGP message size of 4096 octets. As BGP is extended to support newer AFI/SAFIs, there is a need to extend the maximum message size beyond 4096 octets. This document updates the BGP specification RFC 4271 by providing an extension to BGP to extend its current message size from 4096 octets to 65535 octets. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-extended-messages-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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 16 05:29: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 21B04129CF9; Thu, 16 Feb 2017 05:29:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkMwB-zh48RG; Thu, 16 Feb 2017 05:28:59 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03251129CF3; Thu, 16 Feb 2017 05:28:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17148; q=dns/txt; s=iport; t=1487251735; x=1488461335; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=74K8pWfFOY+IQBuP27LA+nNY708TArxVLJTYPv03yA0=; b=CZsyPHI648LeRHqGE8MNt0yVU1f2U7wF7BISmGpum717Y6L88kwdjnsS taoYqi3EZATOsrj1gZ6CeXPj/J8RkpNDuye5DXwg+pcB4iFYNowXzv+YD SHFkiuRPLqO7HU222ZQDZzP3rIhRd5ryMdAG1yQapj4axWDTPGswzxXqv 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BBAQDHp6VY/51dJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9iYYEJB4NSigiSEJAHhSyCDCyFdgIagXk/GAECAQEBAQEBAWI?= =?us-ascii?q?ohHABAQEEIwpMEAIBCA4DAwECJAcCAgIwHQgBAQQBDQWJbA6wHYIlK4sQAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBGAWGTIIFgmqEdIJmLoIxBZt/AYZviyeRBpMXAR8?= =?us-ascii?q?4gQBRFT0RAYRqgUh1iSqBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,169,1484006400"; d="scan'208,217";a="207497264" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Feb 2017 13:28:55 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v1GDSstW026682 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 16 Feb 2017 13:28:55 GMT Received: from xch-rtp-018.cisco.com (64.101.220.158) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 16 Feb 2017 08:28:54 -0500 Received: from xch-rtp-018.cisco.com ([64.101.220.158]) by XCH-RTP-018.cisco.com ([64.101.220.158]) with mapi id 15.00.1210.000; Thu, 16 Feb 2017 08:28:54 -0500 From: "Zafar Ali (zali)" To: Susan Hares , "idr@ietf.org" Thread-Topic: [Idr] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) Thread-Index: AdKH5ALnHgVYM3zURr+F4Gs1EKSVZgAdJtMA Date: Thu, 16 Feb 2017 13:28:54 +0000 Message-ID: <59F9549F-084E-42C4-AEC6-B91EF8447B53@cisco.com> References: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> In-Reply-To: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.96.243] Content-Type: multipart/alternative; boundary="_000_59F9549F084E42C4AEC6B91EF8447B53ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" Subject: Re: [Idr] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 13:29:01 -0000 --_000_59F9549F084E42C4AEC6B91EF8447B53ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGk6DQoNCg0KSSd2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFuZCBiZWxpZXZlIGl0IGlzIHJl YWR5IGZvciBwdWJsaWNhdGlvbi4NCg0KVGhhbmtzDQoNClJlZ2FyZHMg4oCmIFphZmFyDQoNCkZy b206IElkciA8aWRyLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBTdXNhbiBIYXJlcyA8 c2hhcmVzQG5kemguY29tPg0KRGF0ZTogV2VkbmVzZGF5LCBGZWJydWFyeSAxNSwgMjAxNyBhdCA2 OjM0IFBNDQpUbzogImlkckBpZXRmLm9yZyIgPGlkckBpZXRmLm9yZz4NCkNjOiAic3ByaW5nQGll dGYub3JnIiA8c3ByaW5nQGlldGYub3JnPg0KU3ViamVjdDogW0lkcl0gSURSIFdHIDIgd2VlayBX RyBMQyBvbiBkcmFmdC1pZXRmLWlkci1iZ3Bscy1zZWdtZW50LXJvdXRpbmctZXBlIC0gKDIvMTUv MjAxNyB0byAzLzEvMjAxNykNCg0KVGhpcyBiZWdpbnMgYSAyIHdlZWsgSURSIFdHIGxhc3QgY2Fs bCBvbiBkcmFmdC1pZXRmLWlkci1iZ3Bscy1zZWdtZW50LXJvdXRpbmctZXBlIGZyb20gKDIvMTUg dG8gMy8xLzIwMTcpICAgIFRoZXJlIGFyZSB0d28gaW1wbGVtZW50YXRpb25zIGRlc2NyaWJlIG9u IHRoZSB3aWtpIGF0Og0KaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvaWRyL3dpa2kvZHJhZnQt aWV0Zi1pZHItYmdwbHMtc2VnbWVudC1yb3V0aW5nLWVwZSUyMA0KDQpUaGUgdHdvIGltcGxlbWVu dGF0aW9uIGFyZSBmcm9tICBDaXNjbyBJT1MtWFIgcmVsZWFzZSA2LjAuMiBhbmQgQ2lzY28gTmV4 dXMgU3dpdGNoIE45MDAwL04zMDAwIHBsYXRmb3JtcyBydW5uaW5nIE5YLU9TIDcuMCgzKUkxKDEp IG9yIGdyZWF0ZXIuICAgVGhlIGF1dGhvcnMgd2lsbCBpbmRpY2F0ZSBvbiB0aGUgbGlzdCBhbmQg aW4gdGhlIHdpa2kgdGhlIGZvbGxvd2luZyBpbmZvcm1hdGlvbiA6DQoNCg0KMSkgICAgICAgV2Vy ZSB0aGVzZSBpbXBsZW1lbnRhdGlvbnMgc2VwYXJhdGUgaW1wbGVtZW50YXRpb25zPw0KDQoyKSAg ICAgICBXaGF0IHdlcmUgdGhlIHJlc3VsdHMgb2YgdGhlIGludGVyb3BlcmFiaWxpdHkgdGVzdHM/ DQoNClRoaXMgd29yayBpcyBsaW5rZWQgdG8gdGhlIGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQt cm91dGluZy1jZW50cmFsLWVwZSB3b3JrIGluIHRoZSBTUFJJTkcgV0cuIEJhc2VkIG9uIHRoZSB0 d28gZHJhZnRzLCB0aGUgV0cgc2hvdWxkIG1pZ2h0IGNvbnNpZGVyOg0KDQoxKSAgICAgICBJcyB0 aGVyZSBuZWVkIGZvciB0aGlzIHdvcmsgaW4gZGVwbG95bWVudHMgaW4gbmV0d29ya3MvDQoNCjIp ICAgICAgIElzIHRoaXMgdGVjaG5pY2FsbHkgcmVhZHkgZm9yIHB1YmxpY2F0aW9uPw0KDQozKSAg ICAgICBEb2VzIGl0IGZpdCB3aXRoIHRoZSBzcHJpbmcgaW5mb3JtYXRpb25hbCBkcmFmdD8NCg0K Rm9yIHRoZSBlYXNlIG9mIHJlZmVyZW5jZSB0aGUgd2ViIHJlZmVyZW5jZXMgYXJlIGJlbG93Og0K aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pZHItYmdwbHMtc2Vn bWVudC1yb3V0aW5nLWVwZS8NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1jZW50cmFsLWVwZS8NCg0KU3VlIEhhcmVzDQo= --_000_59F9549F084E42C4AEC6B91EF8447B53ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <34935297E987A24091C2F4206549F3A8@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJUaXRsZSIgY29udGVudD0i Ij4NCjxtZXRhIG5hbWU9IktleXdvcmRzIiBjb250ZW50PSIiPg0KPG1ldGEgbmFtZT0iR2VuZXJh dG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5 bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFy YWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJ bWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsN CgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFw cGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3Rl eHQ7fQ0KcC5wMSwgbGkucDEsIGRpdi5wMQ0KCXttc28tc3R5bGUtbmFtZTpwMTsNCgltYXJnaW46 MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OS4wcHQ7DQoJZm9udC1m YW1pbHk6Q2FsaWJyaTt9DQpzcGFuLnMxDQoJe21zby1zdHlsZS1uYW1lOnMxO30NCnNwYW4ubXNv SW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoyMTI1NDA3 NzY7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0yMDk0 OTk0Njk0IDEzNjg5NjIwOTggNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2 OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21z by1sZXZlbC10ZXh0OiIlMVwpIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWNvbG9yOmJs YWNrO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1s b3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBw dDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBs MDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6 bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxv d2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlk OjEzODgwNjMzNzM7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUt aWRzOjE5ODAyNzU0NjggNjc2OTg3MDUgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3 MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDE6bGV2ZWwx DQoJe21zby1sZXZlbC10ZXh0OiIlMVwpIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBs aXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlz dCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDUN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9t YW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJ e21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxp c3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7 DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJ e21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9y PSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0Ij5IaTogPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJwMSI+PHNwYW4gY2xhc3M9InMxIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdCI+SSd2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFuZCBiZWxpZXZl IGl0IGlzIHJlYWR5IGZvciBwdWJsaWNhdGlvbi48L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQiPlRoYW5rczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+UmVn YXJkcyDigKYgWmFmYXIgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkZyb206IDwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5JZHIgJmx0O2lkci1ib3VuY2VzQGlldGYu b3JnJmd0OyBvbiBiZWhhbGYgb2YgU3VzYW4gSGFyZXMgJmx0O3NoYXJlc0BuZHpoLmNvbSZndDs8 YnI+DQo8Yj5EYXRlOiA8L2I+V2VkbmVzZGF5LCBGZWJydWFyeSAxNSwgMjAxNyBhdCA2OjM0IFBN PGJyPg0KPGI+VG86IDwvYj4mcXVvdDtpZHJAaWV0Zi5vcmcmcXVvdDsgJmx0O2lkckBpZXRmLm9y ZyZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90O3NwcmluZ0BpZXRmLm9yZyZxdW90OyAmbHQ7c3By aW5nQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5bSWRyXSBJRFIgV0cgMiB3ZWVr IFdHIExDIG9uIGRyYWZ0LWlldGYtaWRyLWJncGxzLXNlZ21lbnQtcm91dGluZy1lcGUgLSAoMi8x NS8yMDE3IHRvIDMvMS8yMDE3KTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdCI+VGhpcyBiZWdpbnMgYSAyIHdlZWsgSURSIFdHIGxhc3QgY2FsbCBvbiBkcmFmdC1pZXRm LWlkci1iZ3Bscy1zZWdtZW50LXJvdXRpbmctZXBlIGZyb20gKDIvMTUgdG8gMy8xLzIwMTcpICZu YnNwOyZuYnNwOyZuYnNwO1RoZXJlIGFyZSB0d28gaW1wbGVtZW50YXRpb25zIGRlc2NyaWJlIG9u IHRoZSB3aWtpIGF0Og0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxhIGhyZWY9Imh0dHBzOi8vdHJhYy5p ZXRmLm9yZy90cmFjL2lkci93aWtpL2RyYWZ0LWlldGYtaWRyLWJncGxzLXNlZ21lbnQtcm91dGlu Zy1lcGUlMjAiPmh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL2lkci93aWtpL2RyYWZ0LWlldGYt aWRyLWJncGxzLXNlZ21lbnQtcm91dGluZy1lcGUlMjA8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij5UaGUgdHdvIGltcGxlbWVudGF0aW9uIGFyZSBmcm9tDQo8 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2s7YmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7Q2lzY28NCjwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hpdGUiPklPUy1YUiByZWxlYXNlIDYuMC4yIGFu ZCBDaXNjbyBOZXh1cyBTd2l0Y2ggTjkwMDAvTjMwMDAgcGxhdGZvcm1zIHJ1bm5pbmcgTlgtT1Mg Ny4wKDMpSTEoMSkgb3IgZ3JlYXRlci4mbmJzcDsmbmJzcDsgVGhlIGF1dGhvcnMgd2lsbCBpbmRp Y2F0ZSBvbiB0aGUgbGlzdCBhbmQgaW4gdGhlIHdpa2kgdGhlIGZvbGxvd2luZyBpbmZvcm1hdGlv biA6PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hpdGUi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtp ZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJt c28tbGlzdDpJZ25vcmUiPjEpPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bh bj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+ V2VyZSB0aGVzZSBpbXBsZW1lbnRhdGlvbnMgc2VwYXJhdGUgaW1wbGVtZW50YXRpb25zPw0KPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0 ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1saXN0Okln bm9yZSI+Mik8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48 L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5XaGF0IHdlcmUg dGhlIHJlc3VsdHMgb2YgdGhlIGludGVyb3BlcmFiaWxpdHkgdGVzdHM/DQo8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlRoaXMgd29yayBpcyBsaW5rZWQgdG8gdGhl IGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1jZW50cmFsLWVwZSB3b3JrIGluIHRo ZSBTUFJJTkcgV0cuIEJhc2VkIG9uIHRoZSB0d28gZHJhZnRzLCB0aGUgV0cgc2hvdWxkIG1pZ2h0 IGNvbnNpZGVyOiAmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlz dFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEg bGZvNCI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+ MSk8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtlbmRp Zl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPklzIHRoZXJlIG5lZWQgZm9yIHRoaXMg d29yayBpbiBkZXBsb3ltZW50cyBpbiBuZXR3b3Jrcy8NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21z by1saXN0OmwxIGxldmVsMSBsZm80Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0i bXNvLWxpc3Q6SWdub3JlIj4yKTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+SXMgdGhp cyB0ZWNobmljYWxseSByZWFkeSBmb3IgcHVibGljYXRpb24/DQo8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVp bjttc28tbGlzdDpsMSBsZXZlbDEgbGZvNCI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5 bGU9Im1zby1saXN0Oklnbm9yZSI+Myk8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkRv ZXMgaXQgZml0IHdpdGggdGhlIHNwcmluZyBpbmZvcm1hdGlvbmFsIGRyYWZ0Pw0KPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Gb3IgdGhlIGVhc2Ugb2YgcmVmZXJl bmNlIHRoZSB3ZWIgcmVmZXJlbmNlcyBhcmUgYmVsb3c6DQo8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PGEg aHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pZHItYmdw bHMtc2VnbWVudC1yb3V0aW5nLWVwZS8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtaWRyLWJncGxzLXNlZ21lbnQtcm91dGluZy1lcGUvPC9hPjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0Ij48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctY2VudHJhbC1lcGUvIj5odHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctY2VudHJh bC1lcGUvPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+U3Vl IEhhcmVzIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_59F9549F084E42C4AEC6B91EF8447B53ciscocom_-- From nobody Thu Feb 16 05:39: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 76EA712948F; Thu, 16 Feb 2017 05:39:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=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 e_Hu3uffm4s7; Thu, 16 Feb 2017 05:39:49 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0096.outbound.protection.outlook.com [23.103.200.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86A65129558; Thu, 16 Feb 2017 05:39:49 -0800 (PST) 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=2ILNrjhrDv7MNZwD3zNJxiEHhJr5v4oIiYvquL6em50=; b=pZKfw4ikc426ockTTzs1jC+L5fMyzdPoHmDdNPuaBMFJi2oQS+gkNyn+0RMCeHiAyfJA2M+McPlrPiw0XcJOjwc3u37kHAY4GH5mgYvXPHbV594KGHKtV0I7tyGtP9QyzSQJZZ8M5JXANztDTlzHIS//JlhqCxMzjZtCFvKDYbY= Received: from BL2PR09MB0996.namprd09.prod.outlook.com (10.167.102.15) by BL2PR09MB0996.namprd09.prod.outlook.com (10.167.102.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Thu, 16 Feb 2017 13:39:47 +0000 Received: from BL2PR09MB0996.namprd09.prod.outlook.com ([10.167.102.15]) by BL2PR09MB0996.namprd09.prod.outlook.com ([10.167.102.15]) with mapi id 15.01.0888.034; Thu, 16 Feb 2017 13:39:47 +0000 From: "Borchert, Oliver (Fed)" To: "Dongjie (Jimmy)" , Susan Hares , 'John Scudder' Thread-Topic: Implementation call for draft-ietf-idr-bgp-extended-messages (1/24/2017 to 1/31/2017) Thread-Index: AdJ8sBDDhskHW5f6TcW8KGLFsDty8QBpc3kAAJdU7gABxAtQAAAW6y8AAARLj4A= Date: Thu, 16 Feb 2017 13:39:47 +0000 Message-ID: <446A644B-6778-4F78-A819-ACF277CE683E@nist.gov> References: <24581E62-94D7-4D2E-8157-21ADF1CE7AF1@nist.gov> <00ff01d280b3$33771830$9a654890$@ndzh.com> <944428A7-399E-4DDF-9E65-9FBF94DF3F44@nist.gov> <76CD132C3ADEF848BD84D028D243C927935813E7@NKGEML515-MBX.china.huawei.com> In-Reply-To: <76CD132C3ADEF848BD84D028D243C927935813E7@NKGEML515-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 authentication-results: spf=none (sender IP is ) smtp.mailfrom=oliver.borchert@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.140.59] x-ms-office365-filtering-correlation-id: c4935258-91de-47b3-f58b-08d45671464d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BL2PR09MB0996; x-microsoft-exchange-diagnostics: 1; BL2PR09MB0996; 7:dbEBqVpOUib2KHsMRFmA9Z85bOZUhkGWW19O207UWJr7JP2fSEUMRxmjsphyZfN855Mm9gWQNWFd2y8dZuVdFW60JP0rU+NsBmtYv7JjgmurArKAc/C9Dpd+jlx5vmRBsVPzBJ9T0iyA9FoL8Ye1Ev/QmyE9MtLzPQwtwNzCijrZQWcXW2l4k+feFfrKPWmoBje46+bUmW1CIiiCO0tYO+Yn8xq8jWZI849Y10Mh+uH7usdpv5mzWRbtwilf9OEdz6P4BCuxLtARm+hfEoyZ3qcWcUrWbs8zVexxc+5QhU+I1E4srRcoSNpsjAgWEhl1TdohXUGU0Lagc+dtG0uPcQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(20558992708506)(50582790962513)(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123564025)(20161123558025)(20161123560025)(20161123555025)(6072148); SRVR:BL2PR09MB0996; BCL:0; PCL:0; RULEID:; SRVR:BL2PR09MB0996; x-forefront-prvs: 0220D4B98D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39850400002)(39410400002)(39450400003)(39840400002)(377454003)(199003)(24454002)(51914003)(13464003)(189002)(5423002)(30584003)(99286003)(3846002)(6306002)(54906002)(6116002)(102836003)(83506001)(83716003)(25786008)(8936002)(2950100002)(6512007)(15650500001)(8666007)(6436002)(97736004)(5660300001)(53936002)(189998001)(93886004)(4001350100001)(82746002)(3280700002)(66066001)(68736007)(2900100001)(92566002)(1941001)(33656002)(7736002)(230783001)(86362001)(4326007)(305945005)(50986999)(54356999)(76176999)(36756003)(2906002)(8676002)(81156014)(6246003)(53546003)(81166006)(229853002)(122556002)(106356001)(101416001)(3660700001)(6506006)(77096006)(6486002)(389900003)(105586002)(38730400002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR09MB0996; H:BL2PR09MB0996.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2017 13:39:47.5548 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR09MB0996 Archived-At: Cc: "idr-chairs@ietf.org" , "idr@ietf.org" Subject: Re: [Idr] Implementation call for draft-ietf-idr-bgp-extended-messages (1/24/2017 to 1/31/2017) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 13:39:52 -0000 TG9va3MgZ29vZCB0byBtZSwNCk9saXZlcg0KDQpPbiAyLzE2LzE3LCAxOjM2IEFNLCAiRG9uZ2pp ZSAoSmltbXkpIiA8amllLmRvbmdAaHVhd2VpLmNvbT4gd3JvdGU6DQoNCiAgICBIaSBPbGl2ZXIs IA0KICAgIA0KICAgIFRoYW5rcyBmb3IgdGhlIHVwZGF0ZXMgb2YgdGhlIGltcGxlbWVudGF0aW9u IHJlcG9ydC4gSSd2ZSB1cGRhdGVkIHRoZSB3aWtpIHBhZ2UgYWNjb3JkaW5nbHksIGluY2x1ZGlu ZyBzb21lIGVkaXRvcmlhbCBjaGFuZ2VzOg0KICAgIA0KICAgIGh0dHBzOi8vdHJhYy5pZXRmLm9y Zy90cmFjL2lkci93aWtpL2RyYWZ0LWlldGYtaWRyLWJncC1leHRlbmRlZC1pbXBsZW1lbnRhdGlv bnMNCiAgICANCiAgICBQbGVhc2UgcmV2aWV3IGFuZCBsZXQgbWUga25vdyBpZiB5b3UgaGF2ZSBh bnkgY29tbWVudHMuDQogICAgDQogICAgQmVzdCByZWdhcmRzLA0KICAgIEppZQ0KICAgIA0KICAg ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCiAgICA+IEZyb206IEJvcmNoZXJ0LCBPbGl2 ZXIgKEZlZCkgW21haWx0bzpvbGl2ZXIuYm9yY2hlcnRAbmlzdC5nb3ZdDQogICAgPiBTZW50OiBU aHVyc2RheSwgRmVicnVhcnkgMTYsIDIwMTcgODo0MSBBTQ0KICAgID4gVG86IFN1c2FuIEhhcmVz IDxzaGFyZXNAbmR6aC5jb20+OyAnSm9obiBTY3VkZGVyJyA8amdzQGp1bmlwZXIubmV0Pg0KICAg ID4gQ2M6IGlkci1jaGFpcnNAaWV0Zi5vcmc7IGlkckBpZXRmLm9yZw0KICAgID4gU3ViamVjdDog UmU6IEltcGxlbWVudGF0aW9uIGNhbGwgZm9yIGRyYWZ0LWlldGYtaWRyLWJncC1leHRlbmRlZC1t ZXNzYWdlcw0KICAgID4gKDEvMjQvMjAxNyB0byAxLzMxLzIwMTcpDQogICAgPiANCiAgICA+IFN1 ZSwNCiAgICA+IFdlIHVwZGF0ZWQgb3VyIGltcGxlbWVudGF0aW9ucyBhbmQgYmVsb3cgZmluZCB0 aGUgdXBkYXRlZCBpbXBsZW1lbnRhdGlvbg0KICAgID4gcmVwb3J0cyBmb3IgUXVhZ2dhU1J4IGFu ZCBCR1BTRUMtSU86DQogICAgPiANCiAgICA+IEN1cnJlbnQgV2lraSBzdW1tYXJ5Og0KICAgID4g aHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvaWRyL3dpa2kvZHJhZnQtaWV0Zi1pZHItYmdwLWV4 dGVuZGVkLWltcGxlbWVudGF0aW9ucw0KICAgID4gDQogICAgPiAxCUFubm91bmNlIHZpYSBCR1Ag Q2FwYWJpbGl0eSBhZHZlcnRpc2VtZW50IChSRkM1NDkyKSBhcyBCR1AgRXh0ZW5kZWQNCiAgICA+ IENhcGFiaWxpdHkJWWVzCVllcw0KICAgID4gMglJZiBFeHRlbmRlZCBNZXNzYWdlIENhcGFiaWxp dHkgc3VwcG9ydGVkLCBJbXBsZW1lbnRhdGlvbiBNVVNUIGJlIGFibGUNCiAgICA+IHRvOgktCS0N CiAgICA+IDJhCVJFQ0VJVkUgT1BFTiBtZXNzYWdlIGxhcmdlciB0aGFuIDQwOTYgYnl0ZXMgKHNl Y3Rpb24gNCwgcGFyYWdyYXBoIDIpCVllcw0KICAgID4gCVllcw0KICAgID4gMmIJUkVDRUlWRSBB IFVQREFURSBtZXNzYWdlIGxhcmdlciB0YW4gNDA5NiBieXRlcwlZZXMJWWVzDQogICAgPiAzCUFw cGxpY2F0aW9ucyBwdXR0aW5nIGRhdGEgaW50byBCR1AgRXh0ZW5kZWQgbWVzc2FnZXMgTVVTVCBs aW1pdCBzaXplIG9mDQogICAgPiBwYXlsb2FkIHRvIGhhbmRsZSBtYXggbWVzc2FnZSBzaXplcyBv biBwYXRod2F5CVllcwlZZXMNCiAgICA+IDQJU3VwcG9ydHMgRVhURU5ERUQgTUVTU0FHRSwgYnV0 IHBlZXIgaGFzIG5vdCBhZHZlcnRpc2VkIEJHUCBFeHRlbmRlZA0KICAgID4gQ2FwYWJpbGl0eQkt CS0NCiAgICA+IDRhCVNIT1VMRCBOT1QgYWNjZXB0IG1lc3NhZ2UJeWVzCXllcw0KICAgID4gNGIJ TUFZIEFjY2VwdCBFWFRFTkRFRCBNRVNTQUdFIChjb25maWcvaW1wbGVtZW50YXRpb24ga25vYikJ WWVzCVllcw0KICAgID4gNQlEb2VzIG5vdCBzdXBwb3J0IEVYVEVOREVEIE1lc3NhZ2UgKG5vIHN1 cHBvcnQgaW4gY29kZSkNCiAgICA+IDVhCURvZXMgbm90IHNlbmQgRXh0ZW5kZWQgTWVzc2FnZSBj YXBhYmlsaXR5DQogICAgPiA1YglJZiByZWNlaXZlcyBFeHRlbmRlZCBNZXNzYWdlLCBmb2xsb3dz IFJGQzQyMjEgaGFuZGxpbmcgYW5kIHNlbmRzIEJhZA0KICAgID4gbWVzc2FnZSBsZW5ndGggTm90 aWZpY2F0aW9uDQogICAgPiANCiAgICA+IA0KICAgID4gVXBkYXRlZCBTdW1tYXJ5Og0KICAgID4g DQogICAgPiBRdWFnZ2FTUngNCiAgICA+ID09PT09PT09PT0NCiAgICA+IDEpIHllcw0KICAgID4g MmEpIOKAkyBEcmFmdCB3YXMgdXBkYXRlZCDigJMgTi9BDQogICAgPiAyYikgeWVzDQogICAgPiAz KSB5ZXMNCiAgICA+IDRhKSB5ZXMNCiAgICA+IDRiKSB5ZXMNCiAgICA+IDVhKSB5ZXMsIGNhbiBi ZSBjb25maWd1cmVkDQogICAgPiA1YikgeWVzLCBpZiBjb25maWd1cmVkIHRvIG5vdCBzdXBwb3J0 DQogICAgPiANCiAgICA+IEJHUFNFQy1JTw0KICAgID4gPT09PT09PT09DQogICAgPiAxKSB5ZXMN CiAgICA+IDJhKSDigJMgRHJhZnQgd2FzIHVwZGF0ZWQg4oCTIE4vQQ0KICAgID4gMmIpIHllcw0K ICAgID4gMykgeWVzDQogICAgPiA0YSkgeWVzDQogICAgPiA0YikgeWVzDQogICAgPiA1YSkgeWVz LCBjYW4gYmUgY29uZmlndXJlZA0KICAgID4gNWIpIHllcywgaWYgY29uZmlndXJlZCB0byBub3Qg c3VwcG9ydA0KICAgID4gDQogICAgPiBPbGl2ZXINCiAgICA+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICA+IE9saXZlciBC b3JjaGVydCwgQ29tcHV0ZXIgU2NpZW50aXN0DQogICAgPiBOYXRpb25hbCBJbnN0aXR1dGUgb2Yg U3RhbmRhcmRzIGFuZCBUZWNobm9sb2d5DQogICAgPiAoUGhvbmUpIDMwMS45NzUuNDg1NiAsIChG YXgpIDMwMS45NzUuNjIzOA0KICAgID4gDQogICAgDQogICAgDQoNCg== From nobody Thu Feb 16 06:02: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 7473F1295E3; Thu, 16 Feb 2017 06:02:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4C_hgDVB7NZ2; Thu, 16 Feb 2017 06:02:35 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A69E1295AD; Thu, 16 Feb 2017 06:02:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13699; q=dns/txt; s=iport; t=1487253755; x=1488463355; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+2zE2UBkyWErKWV28JWXbveGhyVDcCOdDS9wJfUie1c=; b=emzxe6rkpGGiBIUA3yeTNeGmOQMMRIXwTjWHzKGCgd+G0lJgvmglJZ3N FEE7C4KPJ/YDLMfNcHiWngq+G52nq+RA6+jwj2GbpDOVgxcFZarVTRb+k +qb3ghcpxiSF1+kBgHpxNm1KR2ooUGvN+VGj4ms9/0g7kvXvinoqsW1tP Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A1AQDwr6VY/5JdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9iYYEJB41akhCQB4UsggwshXYCggU/GAECAQEBAQEBAWIohHA?= =?us-ascii?q?BAQEELUwQAgEIDgMDAQIkBAcyFAkIAQEEAQ0FiWwOsleLPAEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBARgFizuEdIVFBZVchiMBhm+LJ5EGkxcBHziBAFEVPYR8gUh1iSq?= =?us-ascii?q?BDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,169,1484006400"; d="scan'208,217";a="207508944" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Feb 2017 14:02:34 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v1GE2YCW012465 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 16 Feb 2017 14:02:34 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 16 Feb 2017 09:02:33 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Thu, 16 Feb 2017 09:02:33 -0500 From: "Acee Lindem (acee)" To: Susan Hares , "idr@ietf.org" Thread-Topic: [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) Thread-Index: AdKH5ALnHgVYM3zURr+F4Gs1EKSVZgAeUxWA Date: Thu, 16 Feb 2017 14:02:33 +0000 Message-ID: References: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> In-Reply-To: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.195] Content-Type: multipart/alternative; boundary="_000_D4CB1B179CA03aceeciscocom_" MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" Subject: Re: [Idr] [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 14:02:42 -0000 --_000_D4CB1B179CA03aceeciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support as a contributor. Thanks, Acee From: spring > on b= ehalf of Susan Hares > Date: Wednesday, February 15, 2017 at 6:34 PM To: IDR List > Cc: "Alvaro Retana (aretana)" >= , "spring@ietf.org" > Subject: [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routi= ng-epe - (2/15/2017 to 3/1/2017) This begins a 2 week IDR WG last call on draft-ietf-idr-bgpls-segment-routi= ng-epe from (2/15 to 3/1/2017) There are two implementations describe on= the wiki at: https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-segment-routing-ep= e%20 The two implementation are from Cisco IOS-XR release 6.0.2 and Cisco Nexus= Switch N9000/N3000 platforms running NX-OS 7.0(3)I1(1) or greater. The a= uthors will indicate on the list and in the wiki the following information = : 1) Were these implementations separate implementations? 2) What were the results of the interoperability tests? This work is linked to the draft-ietf-spring-segment-routing-central-epe wo= rk in the SPRING WG. Based on the two drafts, the WG should might consider: 1) Is there need for this work in deployments in networks/ 2) Is this technically ready for publication? 3) Does it fit with the spring informational draft? For the ease of reference the web references are below: https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/ https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-central-= epe/ Sue Hares --_000_D4CB1B179CA03aceeciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <38A6A5CD23D1964B922B8373A047828D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Support as a contributor. 
Thanks,
Acee 

From: spring <spring-bounces@ietf.org> on behalf of Susan= Hares <shares@ndzh.com>
Date: Wednesday, February 15, 2017 = at 6:34 PM
To: IDR List <idr@ietf.org>
Cc: "Alvaro Retana (aretana)&q= uot; <aretana@cisco.com>, &q= uot;spring@ietf.org" <spring@ietf.org>
Subject: [spring] IDR WG 2 week WG = LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017)

This begins a 2 wee= k IDR WG last call on draft-ietf-idr-bgpls-segment-routing-epe from (2/15 t= o 3/1/2017)    There are two implementations describe on the= wiki at:

ht= tps://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-segment-routing-epe%= 20

 

The two implementat= ion are from  Cisco IOS-XR release 6= .0.2 and Cisco Nexus Switch N9000/N3000 platforms running NX-OS 7.0(3)I1(1)= or greater.   The authors will indicate on the list and in the w= iki the following information :

 

1)      Were th= ese implementations separate implementations?

2)      What we= re the results of the interoperability tests?

 

This work is linked= to the draft-ietf-spring-segment-routing-central-epe work in the SPRING WG= . Based on the two drafts, the WG should might consider:  <= /span>

1)      Is ther= e need for this work in deployments in networks/

2)      Is this= technically ready for publication?

3)      Does it= fit with the spring informational draft?

 

For the ease of ref= erence the web references are below:

https:/= /datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/

ht= tps://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-central-ep= e/

 

Sue Hares

--_000_D4CB1B179CA03aceeciscocom_-- From nobody Thu Feb 16 06:10: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 2B5031299BB; Thu, 16 Feb 2017 06:10:34 -0800 (PST) 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 rbPaP5lePHyH; Thu, 16 Feb 2017 06:10:32 -0800 (PST) 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 72F1C1295E4; Thu, 16 Feb 2017 06:10:32 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=50.124.244.62; From: "Susan Hares" To: "'Borchert, Oliver \(Fed\)'" , "'Dongjie \(Jimmy\)'" , "'John Scudder'" References: <24581E62-94D7-4D2E-8157-21ADF1CE7AF1@nist.gov> <00ff01d280b3$33771830$9a654890$@ndzh.com> <944428A7-399E-4DDF-9E65-9FBF94DF3F44@nist.gov> <76CD132C3ADEF848BD84D028D243C927935813E7@NKGEML515-MBX.china.huawei.com> <446A644B-6778-4F78-A819-ACF277CE683E@nist.gov> In-Reply-To: <446A644B-6778-4F78-A819-ACF277CE683E@nist.gov> Date: Thu, 16 Feb 2017 09:05:23 -0500 Message-ID: <02fc01d2885d$b7b0d080$27127180$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFa04UJGQxVwyjfrfL4tU0zb1CHYAIFmXkSAcGR79sBP00BLQIuyIs6ATpV1WmiF5d78A== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: idr-chairs@ietf.org, idr@ietf.org Subject: Re: [Idr] Implementation call for draft-ietf-idr-bgp-extended-messages (1/24/2017 to 1/31/2017) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 14:10:34 -0000 Oliver:=20 Thank you for checking the updates. = Draft-ietf-idr-bgp-extended-messages has been sent to the IESG for = publication.=20 Sue=20 -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Borchert, Oliver = (Fed) Sent: Thursday, February 16, 2017 8:40 AM To: Dongjie (Jimmy); Susan Hares; 'John Scudder' Cc: idr-chairs@ietf.org; idr@ietf.org Subject: Re: [Idr] Implementation call for = draft-ietf-idr-bgp-extended-messages (1/24/2017 to 1/31/2017) Looks good to me, Oliver On 2/16/17, 1:36 AM, "Dongjie (Jimmy)" wrote: Hi Oliver,=20 =20 Thanks for the updates of the implementation report. I've updated = the wiki page accordingly, including some editorial changes: =20 = https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implement= ations =20 Please review and let me know if you have any comments. =20 Best regards, Jie =20 > -----Original Message----- > From: Borchert, Oliver (Fed) [mailto:oliver.borchert@nist.gov] > Sent: Thursday, February 16, 2017 8:41 AM > To: Susan Hares ; 'John Scudder' = > Cc: idr-chairs@ietf.org; idr@ietf.org > Subject: Re: Implementation call for = draft-ietf-idr-bgp-extended-messages > (1/24/2017 to 1/31/2017) >=20 > Sue, > We updated our implementations and below find the updated = implementation > reports for QuaggaSRx and BGPSEC-IO: >=20 > Current Wiki summary: > = https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implement= ations >=20 > 1 Announce via BGP Capability advertisement (RFC5492) as BGP = Extended > Capability Yes Yes > 2 If Extended Message Capability supported, Implementation MUST be = able > to: - - > 2a RECEIVE OPEN message larger than 4096 bytes (section 4, = paragraph 2) Yes > Yes > 2b RECEIVE A UPDATE message larger tan 4096 bytes Yes Yes > 3 Applications putting data into BGP Extended messages MUST limit = size of > payload to handle max message sizes on pathway Yes Yes > 4 Supports EXTENDED MESSAGE, but peer has not advertised BGP = Extended > Capability - - > 4a SHOULD NOT accept message yes yes > 4b MAY Accept EXTENDED MESSAGE (config/implementation knob) Yes = Yes > 5 Does not support EXTENDED Message (no support in code) > 5a Does not send Extended Message capability > 5b If receives Extended Message, follows RFC4221 handling and = sends Bad > message length Notification >=20 >=20 > Updated Summary: >=20 > QuaggaSRx > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 1) yes > 2a) =E2=80=93 Draft was updated =E2=80=93 N/A > 2b) yes > 3) yes > 4a) yes > 4b) yes > 5a) yes, can be configured > 5b) yes, if configured to not support >=20 > BGPSEC-IO > =3D=3D=3D=3D=3D=3D=3D=3D=3D > 1) yes > 2a) =E2=80=93 Draft was updated =E2=80=93 N/A > 2b) yes > 3) yes > 4a) yes > 4b) yes > 5a) yes, can be configured > 5b) yes, if configured to not support >=20 > Oliver > ------------------------------------------------------------- > Oliver Borchert, Computer Scientist > National Institute of Standards and Technology > (Phone) 301.975.4856 , (Fax) 301.975.6238 >=20 =20 =20 _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Thu Feb 16 07:39: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 875AC12009C; Thu, 16 Feb 2017 07:39:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79pQnsDvew1S; Thu, 16 Feb 2017 07:39:41 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4620712965D; Thu, 16 Feb 2017 07:39:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10800; q=dns/txt; s=iport; t=1487259581; x=1488469181; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5zxV0t5qktU89pl54tQOX4JMgtQgWxXQo3aG0oBg3fg=; b=gKw0Q+ypaShEyuUIL7mBPAS5rS2BKPjCWfgbDXtLvV1XUvMS+Mq8V3n2 Y12w26v5zCa6tKEBMeOsn/3atQc8Mll4z8b2F69CXvkBK/tCMWVZsfefo 5ghPLmvldE1RaGtz3Lrqn6LCXoEZX+YJvmeTJFCM8zg9oAmbe/BaBTCbv 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A2AQA1x6VY/4ENJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9iYYEJB41akhCQB4UsggwfAQyFLEoCggo/GAECAQEBAQEBAWI?= =?us-ascii?q?ohHABAQEEAQFsCxACAQgRAwECJAQHJwsUCQgCBAENBYlsDrJoizsBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEYBYZMhG+EdIVFBZVchiMBhm+LJ5EGkxcBHziBAFEVPYQ?= =?us-ascii?q?Nb4FIdYkqgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.35,169,1484006400"; d="scan'208,217";a="207545694" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Feb 2017 15:39:40 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v1GFddLH010540 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 16 Feb 2017 15:39:40 GMT Received: from xch-rtp-012.cisco.com (64.101.220.152) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 16 Feb 2017 10:39:39 -0500 Received: from xch-rtp-012.cisco.com ([64.101.220.152]) by XCH-RTP-012.cisco.com ([64.101.220.152]) with mapi id 15.00.1210.000; Thu, 16 Feb 2017 10:39:39 -0500 From: "Gaurav Dawra (gdawra)" To: Robert Raszuk , Susan Hares Thread-Topic: [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) Thread-Index: AQHSiGri+NyMNxA4e0i/ZPLgTjfcSg== Date: Thu, 16 Feb 2017 15:39:39 +0000 Message-ID: References: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.0.161029 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.58.145] Content-Type: multipart/alternative; boundary="_000_D4CB07AE1D015Dgdawraciscocom_" MIME-Version: 1.0 Archived-At: Cc: idr wg , "spring@ietf.org" Subject: Re: [Idr] [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 15:39:43 -0000 --_000_D4CB07AE1D015Dgdawraciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. Regards, -Gaurav From: spring > on b= ehalf of Robert Raszuk > Date: Thursday, February 16, 2017 at 4:39 AM To: Susan Hares > Cc: idr wg >, "spring@ietf.org" >, "Alvaro Retana (a= retana)" > Subject: Re: [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-r= outing-epe - (2/15/2017 to 3/1/2017) Support. Thx R. On Feb 15, 2017 6:39 PM, "Susan Hares" > wrote: This begins a 2 week IDR WG last call on draft-ietf-idr-bgpls-segment-routi= ng-epe from (2/15 to 3/1/2017) There are two implementations describe on= the wiki at: https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-segment-routing-ep= e%20 The two implementation are from Cisco IOS-XR release 6.0.2 and Cisco Nexus= Switch N9000/N3000 platforms running NX-OS 7.0(3)I1(1) or greater. The a= uthors will indicate on the list and in the wiki the following information = : 1) Were these implementations separate implementations? 2) What were the results of the interoperability tests? This work is linked to the draft-ietf-spring-segment-routing-central-epe wo= rk in the SPRING WG. Based on the two drafts, the WG should might consider: 1) Is there need for this work in deployments in networks/ 2) Is this technically ready for publication? 3) Does it fit with the spring informational draft? For the ease of reference the web references are below: https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/ https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-central-= epe/ Sue Hares _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_D4CB07AE1D015Dgdawraciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Support.

Regards,

-Gaurav

From: spring <spring-bounces@ietf.org> on behalf of Rober= t Raszuk <robert@raszuk.net>=
Date: Thursday, February 16, 2017 a= t 4:39 AM
To: Susan Hares <shares@ndzh.com>
Cc: idr wg <idr@ietf.org>, "= spring@ietf.org" <spring@iet= f.org>, "Alvaro Retana (aretana)" <aretana@cisco.com>
Subject: Re: [spring] IDR WG 2 week= WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017= )

Support.

Thx
R.

On Feb 15, 2017 6:39 PM, "Susan Hares"= <shares@ndzh.com> wrote:

This begins a 2 wee= k IDR WG last call on draft-ietf-idr-bgpls-segment-routing-epe from (2= /15 to 3/1/2017)    There are two implementations describe o= n the wiki at:

https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp= ls-segment-routing-epe%20

 

The two implementat= ion are from  Cisco IOS-XR release 6= .0.2 and Cisco Nexus Switch N9000/N3000 platforms running NX-OS 7.0(3)I1(1)= or greater.   The authors will indicate on the list and in the w= iki the following information :

 

1)      Were these imp= lementations separate implementations?

2)      What were the = results of the interoperability tests?

 

This work is linked= to the draft-ietf-spring-segment-routing-central-epe work in the SPRI= NG WG. Based on the two drafts, the WG should might consider:  =

1)      Is there need = for this work in deployments in networks/

2)      Is this techni= cally ready for publication?

3)      Does it fit wi= th the spring informational draft?

 

For the ease of ref= erence the web references are below:

https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/

https://datatracker.ietf.org/doc/draft-ietf-spring-seg= ment-routing-central-epe/

 

Sue Hares


_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
--_000_D4CB07AE1D015Dgdawraciscocom_-- From nobody Thu Feb 16 08:06: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 9F1B2129448; Tue, 14 Feb 2017 19:22:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebvGz1tSX_5n; Tue, 14 Feb 2017 19:22:35 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05E901293FB; Tue, 14 Feb 2017 19:22:35 -0800 (PST) Received: from [192.168.1.11] (unknown [112.204.169.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id F402F18013DA; Wed, 15 Feb 2017 04:22:28 +0100 (CET) To: "mpls@ietf.org" , TEAS WG , "ospf@ietf.org" , Isis-wg References: From: Loa Andersson Message-ID: <9024912c-9d23-1b60-74f3-3bdf4f8f5085@pi.nu> Date: Wed, 15 Feb 2017 11:22:24 +0800 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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Thu, 16 Feb 2017 08:06:41 -0800 Cc: idr@ietf.org, isis-chairs@ietf.org, draft-ietf-mpls-residence-time@tools.ietf.org, TEAS WG Chairs , "mpls-chairs@ietf.org" , ospf-chairs@ietf.org Subject: [Idr] Closed -- Re: Working group last call on draft-ietf-mpls-residence-time X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 03:22:37 -0000 Working Groups, This working group last call is closed. Authors, There have been comments, the discussion during the wglc seems to have converged on ways to address these comments, Can the authors please post a new version of the the document. /Loa On 2017-01-31 00:01, Loa Andersson wrote: > Working Groups, > > This is to initiate a two week working group last call in four working > groups on draft-ietf-mpls-residence-time-13. > > The MPLS working group has done an earlier working group last call and > a request for publication has been made. > > The changes to the document were such that we decided to do a new > working group last call and extend it to MPLS, TEAS, OSPF and IS-IS. > > There are three major changes between the version of the document for > which publication was requested are: > > (1) that section 7 " One-step Clock and Two-step Clock Modes" has been > moved up to become section 2.1. > (2) that a sub-TLV for TLV 22 instead of TLV 251 is used to RTM > Capability when IS-IS used advertise RTM capabilities > (3) BGP-LS has been added as a RTM capability advertisement method > > A side-by-side diff between version -12 and -13 is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-residence-time-13 > > Please send your comments to the mpls wg mailing list (mpls@ietf.org), > if you are not subscribed to the mpls wg list, send to "your own" > working group mailing list, and we'll make sure they are posted to the > MPLS wg list. > > There were one IPR disclosure against this document. > > All the authors and contributors have stated on the working group > mailing list that they are not aware of any other IPRs that relates > to this document. > > This working group last call ends February 13, 2017. > > > /Loa > MPLS wg co-chairs -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Feb 16 08:06: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 1DE361288B8; Tue, 14 Feb 2017 19:46:57 -0800 (PST) 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 PKB-OjNdg6ns; Tue, 14 Feb 2017 19:46:54 -0800 (PST) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003: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 25FB71293FB; Tue, 14 Feb 2017 19:46:54 -0800 (PST) Received: by mail-oi0-x230.google.com with SMTP id s203so81125563oie.1; Tue, 14 Feb 2017 19:46:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JIaUC3+zrEWZMkjs0eJmFq301I4uhn6GJkOseaJwN0w=; b=Rfk4p+KCgDS14s6RD1Qrh/i4fvS6FGuW1kWsRoYq6eOmSwUlyGHD3EArZOB7giguev 6htKF4o1Wvp1TPi1QMkQ/2k2elOyppKlEAYNYh6YIc6fih6jw8PqIhLgpcu3dJ0NF7GK 1KnfIF+oHZbTmI+LeCOuSDp8hayBTBklwAmDgGbEqvNyo15Cs3Yi7tBd+wXkGIGyIgcv QZTsW5Btjr6Jv6ejHbSemI6QyuWHhKxLPq2p+3bkssEs1wGaIXXFqOOYa6OnNqCEL/A1 dg08aGPggxBugQsy7JESIenRUFiQTAIG79wtuxZhB76Rwd/shK/yswOoyZ0eDfZCjBR6 xulw== 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=JIaUC3+zrEWZMkjs0eJmFq301I4uhn6GJkOseaJwN0w=; b=PPXXxKS/WhlFsZbnJOvdtFGZCOYXAnt9N5GQA6lf9pX7BOnHPnTS6cL1Jior7jgzA+ kYB0Z1e4xmDS3MsAnlvbUAcXx1O7JBapFR0NuuDvE5ydwQaiXNdpiuJqE32GBRgTGoBa 7frlPer/0nBZfLhph21M5oXxKuFnG87aZlP8nt7xRjcSefZmvRqswAI8te0eHRxfSqEK clPOvbYHmIveW7chYOvAW2QkL/Fx4tZl6s4jbtXqi7B/Mm5WTPdD8GR04VZ2VNBBQVHT KYwzXMsLMesmHfdp8s2SSBo5Ztfxs0r+L07JfIPNGTowSAuhLneSXBg14t5+XejXUVL9 b+Ug== X-Gm-Message-State: AMke39nJBzgL0ZpKGnRbzwRCENpvCLMSxgA/TjbXURyPEKAXqxhlE1BJOshdo9O6t99wCAZV48kD/Ofv6VQjxg== X-Received: by 10.202.232.77 with SMTP id f74mr16320591oih.60.1487130413546; Tue, 14 Feb 2017 19:46:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.103 with HTTP; Tue, 14 Feb 2017 19:46:53 -0800 (PST) In-Reply-To: <9024912c-9d23-1b60-74f3-3bdf4f8f5085@pi.nu> References: <9024912c-9d23-1b60-74f3-3bdf4f8f5085@pi.nu> From: Greg Mirsky Date: Tue, 14 Feb 2017 19:46:53 -0800 Message-ID: To: Loa Andersson Content-Type: multipart/alternative; boundary=001a1141b0a008c5210548898800 Archived-At: X-Mailman-Approved-At: Thu, 16 Feb 2017 08:06:34 -0800 Cc: "mpls@ietf.org" , isis-chairs@ietf.org, idr@ietf.org, draft-ietf-mpls-residence-time@tools.ietf.org, TEAS WG Chairs , "mpls-chairs@ietf.org" , TEAS WG , "ospf@ietf.org" , Isis-wg , ospf-chairs@ietf.org Subject: Re: [Idr] [mpls] Closed -- Re: Working group last call on draft-ietf-mpls-residence-time X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 03:46:57 -0000 --001a1141b0a008c5210548898800 Content-Type: text/plain; charset=UTF-8 Hi Loa, et. al, many thanks to all who reviewed the draft and shared their comments that helped us to improve this document. I'll post the updated version shortly. Regards, Greg On Tue, Feb 14, 2017 at 7:22 PM, Loa Andersson wrote: > Working Groups, > > This working group last call is closed. > > Authors, > There have been comments, the discussion during the wglc seems to have > converged on ways to address these comments, > > Can the authors please post a new version of the the document. > > /Loa > > On 2017-01-31 00:01, Loa Andersson wrote: > >> Working Groups, >> >> This is to initiate a two week working group last call in four working >> groups on draft-ietf-mpls-residence-time-13. >> >> The MPLS working group has done an earlier working group last call and >> a request for publication has been made. >> >> The changes to the document were such that we decided to do a new >> working group last call and extend it to MPLS, TEAS, OSPF and IS-IS. >> >> There are three major changes between the version of the document for >> which publication was requested are: >> >> (1) that section 7 " One-step Clock and Two-step Clock Modes" has been >> moved up to become section 2.1. >> (2) that a sub-TLV for TLV 22 instead of TLV 251 is used to RTM >> Capability when IS-IS used advertise RTM capabilities >> (3) BGP-LS has been added as a RTM capability advertisement method >> >> A side-by-side diff between version -12 and -13 is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-residence-time-13 >> >> Please send your comments to the mpls wg mailing list (mpls@ietf.org), >> if you are not subscribed to the mpls wg list, send to "your own" >> working group mailing list, and we'll make sure they are posted to the >> MPLS wg list. >> >> There were one IPR disclosure against this document. >> >> All the authors and contributors have stated on the working group >> mailing list that they are not aware of any other IPRs that relates >> to this document. >> >> This working group last call ends February 13, 2017. >> >> >> /Loa >> MPLS wg co-chairs >> > > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --001a1141b0a008c5210548898800 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Loa, et. al,
many thanks to all who reviewed the dr= aft and shared their comments that helped us to improve this document.
I'll post the updated version shortly.

R= egards,
Greg

On Tue, Feb 14, 2017 at 7:22 PM, Loa Andersson <loa@pi.nu&g= t; wrote:
Working Groups,

This working group last call is closed.

Authors,
There have been comments, the discussion during the wglc seems to have
converged on ways to address these comments,

Can the authors please post a new version of the the document.

/Loa

On 2017-01-31 00:01, Loa Andersson wrote:
Working Groups,

This is to initiate a two week working group last call in four working
groups on draft-ietf-mpls-residence-time-13.

The MPLS working group has done an earlier working group last call and
a request for publication has been made.

The changes to the document were such that we decided to do a new
working group last call and extend it to MPLS, TEAS, OSPF and IS-IS.

There are three major changes between the version of the document for
which publication was requested are:

(1) that section 7 " One-step Clock and Two-step Clock Modes" has= been
=C2=A0 =C2=A0 moved up to become section 2.1.
(2) that a sub-TLV for TLV 22 instead of TLV 251 is used to RTM
=C2=A0 =C2=A0 Capability when IS-IS used advertise RTM capabilities
(3) BGP-LS has been added as a RTM capability advertisement method

A side-by-side diff between version -12 and -13 is available at:
https://www.ietf.org/rfcdiff?u<= wbr>rl2=3Ddraft-ietf-mpls-residence-time-13

Please send your comments to the mpls wg mailing list (mpls@ietf.org),
if you are not subscribed to the mpls wg list, send to "your own"=
working group mailing list, and we'll make sure they are posted to the<= br> MPLS wg list.

There were one IPR disclosure against this document.

All the authors and contributors have stated on the working group
mailing list that they are not aware of any other IPRs that relates
to this document.

This working group last call ends February 13, 2017.


/Loa
MPLS wg co-chairs

--


Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
Senior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.nu
Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739= 81 21 64

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

--001a1141b0a008c5210548898800-- From nobody Thu Feb 16 08:50:11 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 B98E012960B; Thu, 16 Feb 2017 08:50:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 qm5qUPDe4ouD; Thu, 16 Feb 2017 08:50:08 -0800 (PST) Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C79C21294FA; Thu, 16 Feb 2017 08:50:07 -0800 (PST) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 9BF2860633; Thu, 16 Feb 2017 17:50:06 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.42]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 6DC00180055; Thu, 16 Feb 2017 17:50:06 +0100 (CET) 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.0319.002; Thu, 16 Feb 2017 17:50:06 +0100 From: To: Susan Hares , "idr@ietf.org" Thread-Topic: [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) Thread-Index: AdKH5ALnHgVYM3zURr+F4Gs1EKSVZgAj0X2g Date: Thu, 16 Feb 2017 16:50:05 +0000 Message-ID: <10484_1487263806_58A5D83E_10484_6197_1_53C29892C857584299CBF5D05346208A1ED67062@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> In-Reply-To: <00f901d287e4$16ecb2f0$44c618d0$@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.3] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A1ED67062OPEXCLILM21corp_" MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" Subject: Re: [Idr] [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 16:50:09 -0000 --_000_53C29892C857584299CBF5D05346208A1ED67062OPEXCLILM21corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I've read the draft, please find below some minor comments: --- =A74.3 " * A 4 octet index defining the offset in the SID/Label space advert= ised by this router using the encodings defined in Section 3.1." - Following the recent addition of the SRLB Label Space, I'd rather have th= e text explicitly refers to name of that Label space. e.g. OLD: SID/Label space NEW: SRGB - Which (SRGB) advertisement? I'm assuming the IGP one, but I guess someone= may imagine using the BGP "Originator SRGB TLV". Then what if the node run= s multiple IGP with different SRGB configured? - Note that this document has no "Section 3.1". The text seems borrowed fro= m the IS-IS SR draft, hence may be adding the name of this draft would just= solve the point. (with a normative reference to this IS-IS draft) --- OLD: The Link NLRI uses the new Protocol-ID value (to be assigned by IANA) proposed NEW: The Link NLRI uses the BGP Protocol-ID (TBD1) ("new" may become unspecific 2 years from now) --- One could probably argue that [I-D.ietf-spring-segment-routing] should be a= normative reference. Thanks, Regards, --Bruno From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Susan Hares Sent: Thursday, February 16, 2017 12:35 AM To: idr@ietf.org Cc: 'Alvaro Retana (aretana)'; spring@ietf.org Subject: [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routi= ng-epe - (2/15/2017 to 3/1/2017) This begins a 2 week IDR WG last call on draft-ietf-idr-bgpls-segment-routi= ng-epe from (2/15 to 3/1/2017) There are two implementations describe on= the wiki at: https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-segment-routing-ep= e%20 The two implementation are from Cisco IOS-XR release 6.0.2 and Cisco Nexus= Switch N9000/N3000 platforms running NX-OS 7.0(3)I1(1) or greater. The a= uthors will indicate on the list and in the wiki the following information : 1) Were these implementations separate implementations? 2) What were the results of the interoperability tests? This work is linked to the draft-ietf-spring-segment-routing-central-epe wo= rk in the SPRING WG. Based on the two drafts, the WG should might consider: 1) Is there need for this work in deployments in networks/ 2) Is this technically ready for publication? 3) Does it fit with the spring informational draft? For the ease of reference the web references are below: https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/ https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-central-= epe/ Sue Hares ___________________________________________________________________________= ______________________________________________ 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. --_000_53C29892C857584299CBF5D05346208A1ED67062OPEXCLILM21corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

&n= bsp;

I’= ;ve read the draft, please find below some minor comments:

&n= bsp;

---

=A74.3<= o:p>

"&= nbsp;     *  A 4 octet index defining the offset i= n the SID/Label space advertised by this router using the encodings defined= in  Section 3.1."

&n= bsp;

- Follo= wing the recent addition of the SRLB Label Space, I'd rather have the text = explicitly refers to name of that Label space. e.g.

OLD: SI= D/Label space

NEW: SR= GB

&n= bsp;

- Which= (SRGB) advertisement? I'm assuming the IGP one, but I guess someone may im= agine using the BGP "Originator SRGB TLV". Then what if the node = runs multiple IGP with different SRGB configured?

&n= bsp;

- Note = that this document has no "Section 3.1". The text seems borrowed = from the IS-IS SR draft, hence may be adding the name of this draft would j= ust solve the point. (with a normative reference to this IS-IS draft)

&n= bsp;

---

OLD: Th= e Link NLRI uses the new Protocol-ID value (to be assigned by IANA)

propose= d NEW: The Link NLRI uses the BGP Protocol-ID (TBD1)

&n= bsp;

(“= ;new” may become unspecific 2 years from now)

&n= bsp;

---

One cou= ld probably argue that [I-D.ietf-spring-segment-routing] should be a normat= ive reference.

&n= bsp;

Thanks,=

Regards= ,

--Bruno=

&n= bsp;

&n= bsp;

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Thursday, February 16, 2017 12:35 AM
To: idr@ietf.org
Cc: 'Alvaro Retana (aretana)'; spring@ietf.org
Subject: [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segmen= t-routing-epe - (2/15/2017 to 3/1/2017)

 

This= begins a 2 week IDR WG last call on draft-ietf-idr-bgpls-segment-routing-e= pe from (2/15 to 3/1/2017)    There are two implementations = describe on the wiki at:

https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-segme= nt-routing-epe%20

 

The = two implementation are from  Cisco IOS-XR release 6= .0.2 and Cisco Nexus Switch N9000/N3000 platforms running NX-OS 7.0(3)I1(1)= or greater.   The authors will indicate on the list and in the w= iki the following information :

 

1)      Were these implementations separate implementations?

2)      What were the results of the interoperability tests?

 

This= work is linked to the draft-ietf-spring-segment-routing-central-epe work i= n the SPRING WG. Based on the two drafts, the WG should might consider: &nb= sp;

1)      Is there need for this work in deployments in networks/

2)      Is this technically ready for publication?

3)      Does it fit with the spring informational draft?

 

For = the ease of reference the web references are below:

https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routi= ng-epe/

https://datatracker.ietf.org/doc/draft-ietf-spring-segment-rou= ting-central-epe/

 

Sue = Hares 

______________________________________________________________________=
___________________________________________________

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.
--_000_53C29892C857584299CBF5D05346208A1ED67062OPEXCLILM21corp_-- From nobody Thu Feb 16 09:56: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 CE3CD129675; Thu, 16 Feb 2017 09:56:30 -0800 (PST) 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_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=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdSnrjoonSdo; Thu, 16 Feb 2017 09:56:29 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0124.outbound.protection.outlook.com [104.47.37.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 E6A77129406; Thu, 16 Feb 2017 09:56:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8M0XXR26YbU71THw+Gim6tnXQnuhlHnweeldlGJOc/A=; b=XmnQ4+aT79/Q1coth/3kppF2C+9j7/E2rnzTWhHKrtDg5mpWgVK941oz6smRfzyJVfCgt6i76zdtgrD8zGrGGY+UYXJ+29ojIFl5AsxmHWVCkEMXLHQ5ilBeSdpLOPbXK/A4vroSBMKSf/JJ5eNDkwbCl0eQwMbvf+xhhJOvUx4= Received: from BLUPR0501MB2051.namprd05.prod.outlook.com (10.164.23.21) by BLUPR0501MB2049.namprd05.prod.outlook.com (10.164.23.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.10; Thu, 16 Feb 2017 17:56:24 +0000 Received: from BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) by BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) with mapi id 15.01.0919.013; Thu, 16 Feb 2017 17:56:24 +0000 From: Ron Bonica To: "rtg-dir@ietf.org" , "draft-ietf-idr-sla-exchange.all@ietf.org" , "idr@ietf.org" Thread-Topic: RtgDir review: draft-ietf-idr-sla-exchange-10 Thread-Index: AdKIcLCEU+uutt39QyCrZCwOKAXyLQ== Date: Thu, 16 Feb 2017 17:56:24 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rbonica@juniper.net; x-originating-ip: [66.129.241.11] x-ms-office365-filtering-correlation-id: c867edc4-0cbe-4c11-9936-08d456951fb2 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BLUPR0501MB2049; x-microsoft-exchange-diagnostics: 1; BLUPR0501MB2049; 7:OFMFT7Xw4vxBxS4PcWaI25iPkiAuDoEynDlKhU4I17Fo3nnaRFdy6ZQ6XA+mHRP8EJfLRJv1PqHbNSlCiyIUgUXoHpnv3ZRBZ9nlQdT12g1XsLdH7AfO44nkud4HRT0zq8oJxPVhiZ3cRfjn02AR9uY0V0SzMD4x4V+4HSOg1f6XDSX77eMfd+ns90YvAl+cH+bga/eLuiOcU/bzYPhW4ewoZawAYL+BWYuxPF/FPmVhI0ogKx96buNLis6aMBrSiiwmWP5XZ6fJXr7PBOWmXCV+EncXI+CKvA9K3lryobZ/oxK0J7ZdecTyz+VU/nij5y5n6MLgpu+QNA8Ws13G/A== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123558025)(20161123555025)(20161123560025)(20161123562025)(6072148); SRVR:BLUPR0501MB2049; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB2049; x-forefront-prvs: 0220D4B98D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39850400002)(39450400003)(39840400002)(39860400002)(39410400002)(199003)(189002)(81166006)(101416001)(9686003)(8676002)(81156014)(1720100001)(92566002)(2900100001)(50986999)(230783001)(189998001)(97736004)(54356999)(66066001)(106356001)(2906002)(68736007)(33656002)(122556002)(105586002)(3280700002)(86362001)(55016002)(77096006)(8936002)(6116002)(2501003)(2201001)(6436002)(25786008)(3846002)(6506006)(99286003)(102836003)(3660700001)(74316002)(305945005)(7696004)(53936002)(5660300001)(7736002)(450100001)(38730400002)(389900003); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB2049; H:BLUPR0501MB2051.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2017 17:56:24.6902 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB2049 Archived-At: Subject: [Idr] RtgDir review: draft-ietf-idr-sla-exchange-10 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 17:56:31 -0000 SGVsbG8sDQoNCkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRl IHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0 byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBh c3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcuIFRoZSBwdXJwb3NlIG9m IHRoZSByZXZpZXcgaXMgdG8gcHJvdmlkZSBhc3Npc3RhbmNlIHRvIHRoZSBSb3V0aW5nIEFEcy4g Rm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUsIHBsZWFz ZSBzZWUg4oCLaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0 Z0Rpcg0KDQpBbHRob3VnaCB0aGVzZSBjb21tZW50cyBhcmUgcHJpbWFyaWx5IGZvciB0aGUgdXNl IG9mIHRoZSBSb3V0aW5nIEFEcywgaXQgd291bGQgYmUgaGVscGZ1bCBpZiB5b3UgY291bGQgY29u c2lkZXIgdGhlbSBhbG9uZyB3aXRoIGFueSBvdGhlciBJRVRGIExhc3QgQ2FsbCBjb21tZW50cyB0 aGF0IHlvdSByZWNlaXZlLCBhbmQgc3RyaXZlIHRvIHJlc29sdmUgdGhlbSB0aHJvdWdoIGRpc2N1 c3Npb24gb3IgYnkgdXBkYXRpbmcgdGhlIGRyYWZ0Lg0KDQpEb2N1bWVudDogIGRyYWZ0LWlldGYt aWRyLXNsYS1leGNoYW5nZS0xMA0KUmV2aWV3ZXI6IFJvbiBCb25pY2ENClJldmlldyBEYXRlOiAg Mi8xNi8yMDE3DQpJRVRGIExDIEVuZCBEYXRlOiBUQkQgDQpJbnRlbmRlZCBTdGF0dXM6IFN0YW5k YXJkcyBUcmFjaw0KDQpTdW1tYXJ5OiANCg0KSSBoYXZlIHNvbWUgbWlub3IgY29uY2VybnMgYWJv dXQgdGhpcyBkb2N1bWVudCB0aGF0IEkgdGhpbmsgc2hvdWxkIGJlIHJlc29sdmVkIGJlZm9yZSBw dWJsaWNhdGlvbi4NCg0KQ29tbWVudHM6IA0KDQpNYWpvciBJc3N1ZXM6IA0KDQpUaGlzIGRvY3Vt ZW50IG1pZ2h0IGJlbmVmaXQgZnJvbSBkaXNjdXNzaW9uIG9mIG9wZXJhdGlvbmFsIGlzc3Vlcy4g SSBhc3N1bWUgdGhhdCB3aGVuIGEgQkdQIGxpc3RlbmVyIGxlYXJucyBhIHJvdXRlIHdpdGggdGhl IFNMQSBFeGNoYW5nZSBBdHRyaWJ1dGUsIGl0IHByb3Zpc2lvbnMgY2xhc3Mgb2Ygc2VydmljZSBm b3J3YXJkaW5nIGNsYXNzZXMgb24gaW50ZXJmYWNlcy4gSSBhbHNvIGFzc3VtZSB0aGF0IGEpIGl0 IHRha2VzIHRpbWUgdG8gcHJvdmlzaW9uIGNsYXNzIG9mIHNlcnZpY2UgZm9yd2FyZGluZyBjbGFz c2VzIGFuZCBiKSB0aGUgbnVtYmVyIG9mIGZvcndhcmRpbmcgY2xhc3NlcyB0aGF0IGNhbiBiZSBw cm92aXNpb25lZCBhcmUgZmluaXRlLiBXaGF0IGRvZXMgdGhlIEJHUCBsaXN0ZW5lciBkbyB3aGVu IHRoZSBudW1iZXIgb2YgZm9yd2FyZGluZyBjbGFzc2VzIHJlcXVlc3RlZCBleGNlZWRzIGl0cyBj YXBhY2l0eSB0byBkZWxpdmVyPyBXaGVuIGEgcm91dGUgZmxhcHM/IEhvdyBkb2VzIHRoZSByb3V0 ZXIgcHJvdGVjdCBpdHNlbGYNCg0KSW4gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rp b24sIEkgYW0gY29uY2VybmVkIGFib3V0IHRoZSBwb3NzaWJpbGl0eSBvZiBpbnRlcm1lZGlhdGUg QVMncyBtb2RpZnlpbmcgdGhlIFNMQSBFeGNoYW5nZSBBdHRyaWJ1dGUuIEl0IHNlZW1zIHRoYXQg eW91IG5lZWQgdG8gaGF2ZSBzb21lIGRlZ3JlZSBvZiB0cnVzdCBpbiBldmVyeSBBUyBvbiB0aGUg cGF0aCAobm90IG9ubHkgdGhvc2UgaW5jbHVkZWQgaW4gdGhlIGF0dHJpYnV0ZSkNCg0KDQpNaW5v ciBJc3N1ZXM6IA0KDQpJbiBTZWN0aW9uIDMuMiwgaXMgdGhlIGZsYWcgcmVhbGx5IG5lZWRlZD8g RG9lc24ndCBhbiBBUyBsaXN0IGNvbnRhaW5pbmcgb25seSB0aGUgcmVjZWl2ZXJzIEFTIGhhdmUg ZXhhY3RseSB0aGUgc2FtZSBtZWFuaW5nPw0KDQpOaXRzOiANCg0KTWlzY2VsbGFuZW91cyB3YXJu aW5nczoNCiAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQogID09IFRoZSBkb2N1bWVudCBzZWVtcyB0 byB1c2UgJ05PVCBSRUNPTU1FTkRFRCcgYXMgYW4gUkZDIDIxMTkga2V5d29yZCwgYnV0DQogICAg IGRvZXMgbm90IGluY2x1ZGUgdGhlIHBocmFzZSBpbiBpdHMgUkZDIDIxMTkga2V5IHdvcmRzIGxp c3QuDQoNCg0KICBDaGVja2luZyByZWZlcmVuY2VzIGZvciBpbnRlbmRlZCBzdGF0dXM6IFByb3Bv c2VkIFN0YW5kYXJkDQogIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KICAgICAoU2VlIFJGQ3MgMzk2 NyBhbmQgNDg5NyBmb3IgaW5mb3JtYXRpb24gYWJvdXQgdXNpbmcgbm9ybWF0aXZlIHJlZmVyZW5j ZXMNCiAgICAgdG8gbG93ZXItbWF0dXJpdHkgZG9jdW1lbnRzIGluIFJGQ3MpDQoNCiAgPT0gVW51 c2VkIFJlZmVyZW5jZTogJ1JGQzI0MzQnIGlzIGRlZmluZWQgb24gbGluZSAxMjc5LCBidXQgbm8g ZXhwbGljaXQNCiAgICAgcmVmZXJlbmNlIHdhcyBmb3VuZCBpbiB0aGUgdGV4dA0KDQogID09IFVu dXNlZCBSZWZlcmVuY2U6ICdSRkM2NzkzJyBpcyBkZWZpbmVkIG9uIGxpbmUgMTMwMSwgYnV0IG5v IGV4cGxpY2l0DQogICAgIHJlZmVyZW5jZSB3YXMgZm91bmQgaW4gdGhlIHRleHQNCg0KICAqKiBP YnNvbGV0ZSBub3JtYXRpdmUgcmVmZXJlbmNlOiBSRkMgMjQzNCAoT2Jzb2xldGVkIGJ5IFJGQyA1 MjI2KQ0KDQogICoqIERvd25yZWY6IE5vcm1hdGl2ZSByZWZlcmVuY2UgdG8gYW4gSW5mb3JtYXRp b25hbCBSRkM6IFJGQyA0MjcyDQoNCiAgKiogRG93bnJlZjogTm9ybWF0aXZlIHJlZmVyZW5jZSB0 byBhbiBJbmZvcm1hdGlvbmFsIFJGQzogUkZDIDcxMzINCg0KICA9PSBPdXRkYXRlZCByZWZlcmVu Y2U6IGRyYWZ0LWlldGYtbmV0Y29uZi1yZXN0Y29uZiBoYXMgYmVlbiBwdWJsaXNoZWQgYXMNCiAg ICAgUkZDIDgwNDANCg== From nobody Thu Feb 16 10:24: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 E88C6129ADF; Thu, 16 Feb 2017 10:24:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgY0j6YjCnse; Thu, 16 Feb 2017 10:24:25 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B76512966F; Thu, 16 Feb 2017 10:23:50 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id DE675B8151F; Thu, 16 Feb 2017 10:23:49 -0800 (PST) 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 Message-Id: <20170216182349.DE675B8151F@rfc-editor.org> Date: Thu, 16 Feb 2017 10:23:49 -0800 (PST) Archived-At: Cc: drafts-update-ref@iana.org, idr@ietf.org, rfc-editor@rfc-editor.org Subject: [Idr] RFC 8092 on BGP Large Communities Attribute X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 18:24:35 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8092 Title: BGP Large Communities Attribute Author: J. Heitz, Ed., J. Snijders, Ed., K. Patel, I. Bagdonas, N. Hilliard Status: Standards Track Stream: IETF Date: February 2017 Mailbox: jheitz@cisco.com, job@ntt.net, keyur@arrcus.com, ibagdona.ietf@gmail.com, nick@inex.ie Pages: 8 Characters: 15979 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-idr-large-community-12.txt URL: https://www.rfc-editor.org/info/rfc8092 DOI: 10.17487/RFC8092 This document describes the BGP Large Communities attribute, an extension to BGP-4. This attribute provides a mechanism to signal opaque information within separate namespaces to aid in routing management. The attribute is suitable for use with all Autonomous System Numbers (ASNs) including four-octet ASNs. 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 Thu Feb 16 10:25: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 2A22D12955D; Thu, 16 Feb 2017 10:24:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ETpFEhQ2Fwq; Thu, 16 Feb 2017 10:24:40 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8F0E1296CC; Thu, 16 Feb 2017 10:24:05 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 7CE56B81548; Thu, 16 Feb 2017 10:24:05 -0800 (PST) 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 Message-Id: <20170216182405.7CE56B81548@rfc-editor.org> Date: Thu, 16 Feb 2017 10:24:05 -0800 (PST) Archived-At: Cc: drafts-update-ref@iana.org, idr@ietf.org, rfc-editor@rfc-editor.org Subject: [Idr] RFC 8093 on Deprecation of BGP Path Attribute Values 30, 31, 129, 241, 242, and 243 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 18:24:49 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8093 Title: Deprecation of BGP Path Attribute Values 30, 31, 129, 241, 242, and 243 Author: J. Snijders Status: Standards Track Stream: IETF Date: February 2017 Mailbox: job@ntt.net Pages: 3 Characters: 5494 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-idr-deprecate-30-31-129-02.txt URL: https://www.rfc-editor.org/info/rfc8093 DOI: 10.17487/RFC8093 This document requests IANA to mark BGP path attribute values 30, 31, 129, 241, 242, and 243 as "Deprecated". 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 Thu Feb 16 10:30: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 B37AA1295EC for ; Thu, 16 Feb 2017 10:30:25 -0800 (PST) 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 1wsgORxaLsnS for ; Thu, 16 Feb 2017 10:30:24 -0800 (PST) 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 B72141294F5 for ; Thu, 16 Feb 2017 10:30:23 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.167.252; From: "Susan Hares" To: References: <20170216182405.7CE56B81548@rfc-editor.org> In-Reply-To: <20170216182405.7CE56B81548@rfc-editor.org> Date: Thu, 16 Feb 2017 13:25:27 -0500 Message-ID: <04fa01d28882$0c5f1690$251d43b0$@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: AQG1BqrGT4DXH1NWQ0ymUKZDqy+T3qGm9ndg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] FW: RFC 8093 on Deprecation of BGP Path Attribute Values 30, 31, 129, 241, 242, and 243 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 18:30:26 -0000 Congratulation WG and Job Snijders on getting this protection to RFC quickly! Sue Hares -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of rfc-editor@rfc-editor.org Sent: Thursday, February 16, 2017 1:24 PM To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org Cc: drafts-update-ref@iana.org; idr@ietf.org; rfc-editor@rfc-editor.org Subject: [Idr] RFC 8093 on Deprecation of BGP Path Attribute Values 30, 31, 129, 241, 242, and 243 A new Request for Comments is now available in online RFC libraries. RFC 8093 Title: Deprecation of BGP Path Attribute Values 30, 31, 129, 241, 242, and 243 Author: J. Snijders Status: Standards Track Stream: IETF Date: February 2017 Mailbox: job@ntt.net Pages: 3 Characters: 5494 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-idr-deprecate-30-31-129-02.txt URL: https://www.rfc-editor.org/info/rfc8093 DOI: 10.17487/RFC8093 This document requests IANA to mark BGP path attribute values 30, 31, 129, 241, 242, and 243 as "Deprecated". 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 _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Thu Feb 16 12:00: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 87ADF129B21 for ; Thu, 16 Feb 2017 12:00:37 -0800 (PST) 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 0KE-0bRY_j7I for ; Thu, 16 Feb 2017 12:00:36 -0800 (PST) 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 D706A129AF3 for ; Thu, 16 Feb 2017 12:00:28 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.20.38; From: "Susan Hares" To: "'Ron Bonica'" References: In-Reply-To: Date: Thu, 16 Feb 2017 14:55:30 -0500 Message-ID: <055c01d2888e$a10e2cc0$e32a8640$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH+U8bIprcHIBv9vIIxWXYNekqkjaEUaoSw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] RtgDir review: draft-ietf-idr-sla-exchange-10 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 20:00:37 -0000 Ron:=20 Thank you for the review. I will let authors respond to you. =20 Sue=20 -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Ron Bonica Sent: Thursday, February 16, 2017 12:56 PM To: rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; = idr@ietf.org Subject: [Idr] RtgDir review: draft-ietf-idr-sla-exchange-10 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. The purpose = of the review is to provide assistance to the Routing ADs. For more = information about the Routing Directorate, please see = =E2=80=8Bhttp://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 = Last Call comments that you receive, and strive to resolve them through = discussion or by updating the draft. Document: draft-ietf-idr-sla-exchange-10 Reviewer: Ron Bonica Review Date: 2/16/2017 IETF LC End Date: TBD=20 Intended Status: Standards Track Summary:=20 I have some minor concerns about this document that I think should be = resolved before publication. Comments:=20 Major Issues:=20 This document might benefit from discussion of operational issues. I = assume that when a BGP listener learns a route with the SLA Exchange = Attribute, it provisions class of service forwarding classes on = interfaces. I also assume that a) it takes time to provision class of = service forwarding classes and b) the number of forwarding classes that = can be provisioned are finite. What does the BGP listener do when the = number of forwarding classes requested exceeds its capacity to deliver? = When a route flaps? How does the router protect itself In the Security Considerations section, I am concerned about the = possibility of intermediate AS's modifying the SLA Exchange Attribute. = It seems that you need to have some degree of trust in every AS on the = path (not only those included in the attribute) Minor Issues:=20 In Section 3.2, is the flag really needed? Doesn't an AS list containing = only the receivers AS have exactly the same meaning? Nits:=20 Miscellaneous warnings: = -------------------------------------------------------------------------= --- =3D=3D The document seems to use 'NOT RECOMMENDED' as an RFC 2119 = keyword, but does not include the phrase in its RFC 2119 key words list. Checking references for intended status: Proposed Standard = -------------------------------------------------------------------------= --- (See RFCs 3967 and 4897 for information about using normative = references to lower-maturity documents in RFCs) =3D=3D Unused Reference: 'RFC2434' is defined on line 1279, but no = explicit reference was found in the text =3D=3D Unused Reference: 'RFC6793' is defined on line 1301, but no = explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Downref: Normative reference to an Informational RFC: RFC 4272 ** Downref: Normative reference to an Informational RFC: RFC 7132 =3D=3D Outdated reference: draft-ietf-netconf-restconf has been = published as RFC 8040 _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Thu Feb 16 13:25: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 9BA9B1296E0 for ; Thu, 16 Feb 2017 13:25:31 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, 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 3namfkL8pHZi for ; Thu, 16 Feb 2017 13:25:27 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CC60129541 for ; Thu, 16 Feb 2017 13:25:26 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1GLPOBI005907 for ; Thu, 16 Feb 2017 21:25:24 GMT Received: from 950129200 ([176.241.251.4]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1GLPJ8k005842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 16 Feb 2017 21:25:23 GMT From: "Adrian Farrel" To: Date: Thu, 16 Feb 2017 21:25:18 -0000 Message-ID: <0a2c01d2889b$2eda90f0$8c8fb2d0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdKImyrDnxgaHHXPTOi5LvYFNvdWug== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22890.002 X-TM-AS-Result: No--3.075-10.0-31-10 X-imss-scan-details: No--3.075-10.0-31-10 X-TMASE-MatchedRID: IczRV1NxQ4W77rpLLmM7AsWUKBjERoYTzJmqByfAaS0gbNDlPT+rW4N2 pMn0FcvGXIsFfI8Rrp6xdNvdS/WxrbWd3Qhj3xBVVU3yVpaj3QxMkOX0UoduufEf3vDTPPt1eqO qRRe6+9GakvRUUhDHxLE3s3jsznvfMtCMcfANeKYSaNhZLec7QFPniy82Q6c7H46Jyk9t8h0l3W kwfnyDsS3PP/lRNSyBaeqGQCNgxozR4aWLy95VW6t9n66zJ4RI9NYqzb2oOWsPpGoR1th3non/i oA/OBIdm0VAoQhcJHIu+FzXyTad7TZJ9FayTxRpq1ZJZ2z+SbbJ5SXtoJPLyApcq1+LTpsUo8WM kQWv6iV95l0nVeyiuDrm2CwlZwVRrFldG3ZH+DmctPRRi1pLaISpzlM+e8DN8wrJ6gure4VP9V9 SpUxtCK9T2b/eJnmJlo3Iojv8AKj6/zAH+bBXQx9avEsi0xwEMps6DAw1eWkogMKdauoOlfR5gL DNdb9LuOZoyiCGGN8YgmnfWgSln5vaf0QvfUyeC8XKjsVbJjU= Archived-At: Subject: [Idr] IDR heads up on BESS draft: BGP for SFC: draft-mackie-bess-nsh-bgp-control-plane-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 21:25:32 -0000 Hi IDR, We have an I-D in BESS (also discussed in SFC) that proposes to use BGP as a control plane for and SFC (overlay) network. You can best grasp the proposed extensions to BGP by looking at the I-D. We think the extensions are natural and relatively small, by YMMV :-) Completely understanding what we are planning may be hard without some background in service function chaining, but from 30,000 ft... An SFC network is an overlay network. Service Function Forwarders (SFFs) are connected by tunnels over one or more underlay networks. SFFs provide access to Service Function Instances (SFIs) SFIs are strung together in an ordered sequence called a Service Function Path (SFP) [an instance of a Service Function Chain (SFC)] It used to be that service functions were installed as physical bumps in the wire, but now they may be remote and virtualized. Packets that need to be acted on by a series of service functions (an SFC) are classified by a Classifier and assigned to an SFP. The packets are marked (with an additional encapsulation header) and passed from SFF to SFF for delivery to the SFIs. Our approach uses BGP so that: - SFFs can advertise which SFIs they provide access to so that a controller can build SFPs - a controller to advertise the various SFPs so that SFFs can work out how to deliver packets to the right SFIs, and how to route packets to the correct next SFF - a controller to instruct a Classifier on how to select the right SFP We also help the SFF know what tunnel to use to reach the next SFF, and what SFC encapsulation to use on each hop. For more details, read the draft :-) Discussions should probably be on the BESS list, but we will probably also spot them if they happen here. Thanks, Adrian From nobody Thu Feb 16 14:56: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 CC37912955E for ; Thu, 16 Feb 2017 14:56:18 -0800 (PST) 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 sh5yVx4BhoP9 for ; Thu, 16 Feb 2017 14:56:17 -0800 (PST) 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 36C5F129526 for ; Thu, 16 Feb 2017 14:56:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3060; q=dns/txt; s=iport; t=1487285777; x=1488495377; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=g7s6lgj45rjNe6RGme/pzJf4h+WkeNKo68XdICq2spY=; b=Dh3cqpCf4jzHVUd9Y0ylLowkp9Yq8eSIDgER2SaNxmewf3tvbAHnjLXI h+MK9zt4fhDSkCPRmZWprAn4dGcKPYdMMuzQ/03xOeyluONDZiNDdQkw8 8bQey0ZofUpfw5wA6pAyVubSb4Y2AwD60VtOvpePX0Xh3rZ+uY/UHwHxG g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQBlLaZY/5FdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQkHjVqSD4gLjSiCDB8LhXgCghA/GAECAQEBAQEBAWIdC4R?= =?us-ascii?q?wAQEBBAEBOBQgFwQCAQgRAwEBAQ0SCQchBgoBFAkIAgQTCAwHAgSJMwMVDrJ+h?= =?us-ascii?q?zUNhBMBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYZMhG+BPIEVgWSGBAWVXIVpOgG?= =?us-ascii?q?Gb4cNhBGCBIUXiXSILYIKiGABHziBAFEVGCWERh2BYXWICYEhAYEMAQEB?= X-IronPort-AV: E=Sophos;i="5.35,169,1484006400"; d="scan'208";a="386529745" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Feb 2017 22:56:16 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v1GMuG1e016566 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 16 Feb 2017 22:56:16 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 16 Feb 2017 16:56:15 -0600 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, 16 Feb 2017 16:56:15 -0600 From: "Jakob Heitz (jheitz)" To: "idr@ietf.org" Thread-Topic: [Idr] RFC 8092 on BGP Large Communities Attribute Thread-Index: AQHSiII65xve03/AI0WS9de5gqZeQqFsPngQ Date: Thu, 16 Feb 2017 22:56:15 +0000 Message-ID: <23f1de27c8b24920acc4fbd1e2114ce6@XCH-ALN-014.cisco.com> References: <20170216182349.DE675B8151F@rfc-editor.org> In-Reply-To: <20170216182349.DE675B8151F@rfc-editor.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: [128.107.151.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] RFC 8092 on BGP Large Communities Attribute X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 22:56:19 -0000 Thanks to all supporters, Jakob. > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of rfc-editor@rfc-edito= r.org > Sent: Thursday, February 16, 2017 10:24 AM > To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org > Cc: drafts-update-ref@iana.org; idr@ietf.org; rfc-editor@rfc-editor.org > Subject: [Idr] RFC 8092 on BGP Large Communities Attribute >=20 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 8092 >=20 > Title: BGP Large Communities Attribute > Author: J. Heitz, Ed., > J. Snijders, Ed., > K. Patel, > I. Bagdonas, > N. Hilliard > Status: Standards Track > Stream: IETF > Date: February 2017 > Mailbox: jheitz@cisco.com, > job@ntt.net, > keyur@arrcus.com, > ibagdona.ietf@gmail.com, > nick@inex.ie > Pages: 8 > Characters: 15979 > Updates/Obsoletes/SeeAlso: None >=20 > I-D Tag: draft-ietf-idr-large-community-12.txt >=20 > URL: https://www.rfc-editor.org/info/rfc8092 >=20 > DOI: 10.17487/RFC8092 >=20 > This document describes the BGP Large Communities attribute, an > extension to BGP-4. This attribute provides a mechanism to signal > opaque information within separate namespaces to aid in routing > management. The attribute is suitable for use with all Autonomous > System Numbers (ASNs) including four-octet ASNs. >=20 > This document is a product of the Inter-Domain Routing Working Group of t= he IETF. >=20 > This is now a Proposed Standard. >=20 > STANDARDS TRACK: This document specifies an Internet Standards Track > protocol for the Internet community, and requests discussion and suggesti= ons > for improvements. Please refer to the current edition of the Official > Internet Protocol Standards (https://www.rfc-editor.org/standards) for th= e > standardization state and status of this protocol. Distribution of this > memo is unlimited. >=20 > 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 >=20 > For searching the RFC series, see https://www.rfc-editor.org/search > For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk >=20 > 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. >=20 >=20 > The RFC Editor Team > Association Management Solutions, LLC >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Thu Feb 16 16:16: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 DF91512941D for ; Thu, 16 Feb 2017 16:16:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.775 X-Spam-Level: ** X-Spam-Status: No, score=2.775 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, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=3.795, 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 OvJ-YIOQgDgF for ; Thu, 16 Feb 2017 16:16:39 -0800 (PST) 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 EC8981293EC for ; Thu, 16 Feb 2017 16:16:38 -0800 (PST) Received: by mail-wr0-x22f.google.com with SMTP id i10so21655463wrb.0 for ; Thu, 16 Feb 2017 16:16:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:mime-version:date:reply-to:message-id :in-reply-to:references; bh=dzhhCmXabZhEJ8bo9vA0+tg5hysecA+kHgFhiLufTPw=; b=S0oZl9KzTkA0l/YnmeWhx+v5T+8zB4Kvcq/Nf0S7i+N1QYi9czrbzg752Aqg6NMWl4 0IeL7ve1qlSZh8mNY7MnFjmjA+v9QjuNRyfd8gjO+MgK66nN0LSeMtkFowv+z3mH12Ef TaMfyEs3mkxsrqAO1DzOGo9aFdPhFcrQsRGeJ3JIhTgfi7t3ULmC8EAMDjEsn/9U31DG Ie0tPqvbNkiAuyAM0nPPN2brXMa0X8WGEebke8nZQjYzXZXvfUr2qxoPF17Z4Gn3fW/L HPWQ/rmn+Ddw8ua1nmGaVdXfrBTHjAckh/nx5dsHAd9B4pGPc8rA38TlOgZXlYk08mgX C1jA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:mime-version:date:reply-to :message-id:in-reply-to:references; bh=dzhhCmXabZhEJ8bo9vA0+tg5hysecA+kHgFhiLufTPw=; b=MFUQ+rswcMd0rtd9QP0jMLWDupnV6OSru+HFlEZNvnodAHIzaQ4G594LRC9NboGW7Q EWTAxzr8PkVhODHMHqqaYQt/ofQ1N25CDSviXgpVXPKlVdzuiyhMFurAD9NPOmqNlSJ/ u2Ecko8Ps160YMXnh65E5ZngrCsSq7ahmLVcMGmejWf0xelILF9esiVyTk2dOlIkCA4i NZbl7otOtcivV/IMDOs8v3ogigp6T4OhFq7KVwQjreKXWelkNj+1lXQxLiaxuIQyCiD5 lYtBJi39XxaFMueJeXY12mefpUiaXssK1kQki8ILOZSO+KatwPoG57lUcZt0Y8wXIYdD +ZkQ== X-Gm-Message-State: AMke39n55sGVm53y6UOrXziQ95KLM++b+7bC5hnl4Vl7A8YAx3SllmULF8AEoroTkWoY9A== X-Received: by 10.223.160.246 with SMTP id n51mr4156614wrn.158.1487290597505; Thu, 16 Feb 2017 16:16:37 -0800 (PST) Received: from f4.my.com (f4.my.com. [185.30.176.114]) by smtp.gmail.com with ESMTPSA id g11sm10847045wrb.63.2017.02.16.16.16.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Feb 2017 16:16:35 -0800 (PST) From: =?UTF-8?B?VG9ueSBQcnp5Z2llbmRh?= To: =?UTF-8?B?QWRyaWFuIEZhcnJlbA==?= MIME-Version: 1.0 X-Mailer: My.com Mailer 1.0 X-Originating-IP: [208.54.39.179] Date: Fri, 17 Feb 2017 03:16:34 +0300 X-Letter-Fingerprint: Hi3K8Fbd1zgY7RjVljmHFedtsOENyySx X-Priority: 3 (Normal) Message-ID: <1487290594.4104319@f4.my.com> Content-Type: multipart/alternative; boundary="--ALT--iM8uhhfa1487290594" X-E1FCDC63: A328DCBFD0D48ACA2DCFE6D27BA78028074A40F52AF1438D X-Mras: OK X-Spam: undefined In-Reply-To: <0a2c01d2889b$2eda90f0$8c8fb2d0$@olddog.co.uk> References: <0a2c01d2889b$2eda90f0$8c8fb2d0$@olddog.co.uk> Archived-At: Cc: =?UTF-8?B?aWRyIHdn?= Subject: Re: [Idr] =?utf-8?q?IDR_heads_up_on_BESS_draft=3A_BGP_for_SFC=3A_draf?= =?utf-8?q?t-mackie-bess-nsh-bgp-control-plane-04=2Etxt?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: =?UTF-8?B?VG9ueSBQcnp5Z2llbmRh?= List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 00:16:41 -0000 ----ALT--iM8uhhfa1487290594 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 CkRpc2NvdW50ZWQgZm9yIHNhbWUgYWZmaWxpYXRpb24gd2l0aCB0aGUgYXV0aG9ycyDwn5iPIEkg ZG8gdGhpbmsgcGVyc29uYWxseSBpdCdzIGEgc3ltbWV0cmljYWwsIHF1aXRlIGVsZWdhbnQgYW5k IGxvdyByaXNrL2VmZm9ydCBkcmFmdCBnaXZlbiBob3cgc3VjY2Vzc2Z1bCBlcXVpdmFsZW50IEJH UCAibG93IGxldmVsIG5ldHdvcmsgc2VydmljZSBhY2Nlc3MgcG9pbnQiIHN5bmNocm9uaXphdGlv biBwcm9wb3NhbHMgd2VyZSBvdmVyIGxhc3QgeWVhcnMgLi4uCgoKClNlbnQgZnJvbSBteU1haWwg Zm9yIGlPUwoKClRodXJzZGF5LCBGZWJydWFyeSAxNiwgMjAxNywgMTM6MjUgLTA4MDAgZnJvbSBB ZHJpYW4gRmFycmVsICA8YWRyaWFuQG9sZGRvZy5jby51az46Cj5IaSBJRFIsCj4KPldlIGhhdmUg YW4gSS1EIGluIEJFU1MgKGFsc28gZGlzY3Vzc2VkIGluIFNGQykgdGhhdCBwcm9wb3NlcyB0byB1 c2UgQkdQIGFzIGEKPmNvbnRyb2wgcGxhbmUgZm9yIGFuZCBTRkMgKG92ZXJsYXkpIG5ldHdvcmsu Cj4KPllvdSBjYW4gYmVzdCBncmFzcCB0aGUgcHJvcG9zZWQgZXh0ZW5zaW9ucyB0byBCR1AgYnkg bG9va2luZyBhdCB0aGUgSS1ELiBXZQo+dGhpbmsgdGhlIGV4dGVuc2lvbnMgYXJlIG5hdHVyYWwg YW5kIHJlbGF0aXZlbHkgc21hbGwsIGJ5IFlNTVYgOi0pCj4KPkNvbXBsZXRlbHkgdW5kZXJzdGFu ZGluZyB3aGF0IHdlIGFyZSBwbGFubmluZyBtYXkgYmUgaGFyZCB3aXRob3V0IHNvbWUKPmJhY2tn cm91bmQgaW4gc2VydmljZSBmdW5jdGlvbiBjaGFpbmluZywgYnV0IGZyb20gMzAsMDAwIGZ0Li4u Cj4KPkFuIFNGQyBuZXR3b3JrIGlzIGFuIG92ZXJsYXkgbmV0d29yay4KPlNlcnZpY2UgRnVuY3Rp b24gRm9yd2FyZGVycyAoU0ZGcykgYXJlIGNvbm5lY3RlZCBieSB0dW5uZWxzIG92ZXIgb25lIG9y IG1vcmUKPnVuZGVybGF5IG5ldHdvcmtzLgo+U0ZGcyBwcm92aWRlIGFjY2VzcyB0byBTZXJ2aWNl IEZ1bmN0aW9uIEluc3RhbmNlcyAoU0ZJcykKPlNGSXMgYXJlIHN0cnVuZyB0b2dldGhlciBpbiBh biBvcmRlcmVkIHNlcXVlbmNlIGNhbGxlZCBhIFNlcnZpY2UgRnVuY3Rpb24gUGF0aAo+KFNGUCkg W2FuIGluc3RhbmNlIG9mIGEgU2VydmljZSBGdW5jdGlvbiBDaGFpbiAoU0ZDKV0KPkl0IHVzZWQg dG8gYmUgdGhhdCBzZXJ2aWNlIGZ1bmN0aW9ucyB3ZXJlIGluc3RhbGxlZCBhcyBwaHlzaWNhbCBi dW1wcyBpbiB0aGUKPndpcmUsIGJ1dCBub3cgdGhleSBtYXkgYmUgcmVtb3RlIGFuZCB2aXJ0dWFs aXplZC4KPlBhY2tldHMgdGhhdCBuZWVkIHRvIGJlIGFjdGVkIG9uIGJ5IGEgc2VyaWVzIG9mIHNl cnZpY2UgZnVuY3Rpb25zIChhbiBTRkMpIGFyZQo+Y2xhc3NpZmllZCBieSBhIENsYXNzaWZpZXIg YW5kIGFzc2lnbmVkIHRvIGFuIFNGUC4KPlRoZSBwYWNrZXRzIGFyZSBtYXJrZWQgKHdpdGggYW4g YWRkaXRpb25hbCBlbmNhcHN1bGF0aW9uIGhlYWRlcikgYW5kIHBhc3NlZCBmcm9tCj5TRkYgdG8g U0ZGIGZvciBkZWxpdmVyeSB0byB0aGUgU0ZJcy4KPgo+T3VyIGFwcHJvYWNoIHVzZXMgQkdQIHNv IHRoYXQ6Cj4tIFNGRnMgY2FuIGFkdmVydGlzZSB3aGljaCBTRklzIHRoZXkgcHJvdmlkZSBhY2Nl c3MgdG8gc28gdGhhdCBhIGNvbnRyb2xsZXIgY2FuCj5idWlsZCBTRlBzCj4tIGEgY29udHJvbGxl ciB0byBhZHZlcnRpc2UgdGhlIHZhcmlvdXMgU0ZQcyBzbyB0aGF0IFNGRnMgY2FuIHdvcmsgb3V0 IGhvdyB0bwo+ZGVsaXZlciAKPsKgwqDCoHBhY2tldHMgdG8gdGhlIHJpZ2h0IFNGSXMsIGFuZCBo b3cgdG8gcm91dGUgcGFja2V0cyB0byB0aGUgY29ycmVjdCBuZXh0IFNGRgo+LSBhIGNvbnRyb2xs ZXIgdG8gaW5zdHJ1Y3QgYSBDbGFzc2lmaWVyIG9uIGhvdyB0byBzZWxlY3QgdGhlIHJpZ2h0IFNG UAo+Cj5XZSBhbHNvIGhlbHAgdGhlIFNGRiBrbm93IHdoYXQgdHVubmVsIHRvIHVzZSB0byByZWFj aCB0aGUgbmV4dCBTRkYsIGFuZCB3aGF0IFNGQwo+ZW5jYXBzdWxhdGlvbiB0byB1c2Ugb24gZWFj aCBob3AuCj4KPkZvciBtb3JlIGRldGFpbHMsIHJlYWQgdGhlIGRyYWZ0IDotKQo+Cj5EaXNjdXNz aW9ucyBzaG91bGQgcHJvYmFibHkgYmUgb24gdGhlIEJFU1MgbGlzdCwgYnV0IHdlIHdpbGwgcHJv YmFibHkgYWxzbyBzcG90Cj50aGVtIGlmIHRoZXkgaGFwcGVuIGhlcmUuCj4KPlRoYW5rcywKPkFk cmlhbgo+Cj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+ SWRyIG1haWxpbmcgbGlzdAo+SWRyQGlldGYub3JnCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2lkcgo= ----ALT--iM8uhhfa1487290594 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 CjxIVE1MPjxCT0RZPjxkaXYgaWQ9ImNvbXBvc2VXZWJWaWV3X2VkaXRhYmxlX2NvbnRlbnQiIGRh dGEtbWFpbHJ1YXBwLWNvbXBvc2UtaWQ9ImNvbXBvc2VXZWJWaWV3X2VkaXRhYmxlX2NvbnRlbnQi IHN0eWxlPSJ0ZXh0LWFsaWduOiBsZWZ0OyI+PGRpdj5EaXNjb3VudGVkIGZvciBzYW1lIGFmZmls aWF0aW9uIHdpdGggdGhlIGF1dGhvcnMg8J+YjyBJIGRvIHRoaW5rIHBlcnNvbmFsbHkgaXQncyBh IHN5bW1ldHJpY2FsLCBxdWl0ZSBlbGVnYW50IGFuZCBsb3cgcmlzay9lZmZvcnQgZHJhZnQgZ2l2 ZW4gaG93IHN1Y2Nlc3NmdWwgZXF1aXZhbGVudCBCR1AgImxvdyBsZXZlbCBuZXR3b3JrIHNlcnZp Y2UgYWNjZXNzIHBvaW50IiBzeW5jaHJvbml6YXRpb24gcHJvcG9zYWxzIHdlcmUgb3ZlciBsYXN0 IHllYXJzIC4uLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXYgaWQ9Im1haWwtYXBwLWF1dG8tZGVm YXVsdC1zaWduYXR1cmUiPjxicj48YnI+U2VudCBmcm9tIG15TWFpbCBmb3IgaU9TPGJyPjwvZGl2 Pjxicj48YnI+VGh1cnNkYXksIEZlYnJ1YXJ5IDE2LCAyMDE3LCAxMzoyNSAtMDgwMCBmcm9tIEFk cmlhbiBGYXJyZWwgICZsdDthZHJpYW5Ab2xkZG9nLmNvLnVrJmd0Ozo8YnI+ICAgIDxkaXYgaWQ9 ImNvbXBvc2VXZWJWaWV3X3ByZXZpb3VzZV9jb250ZW50IiBkYXRhLW1haWxydWFwcC1jb21wb3Nl LWlkPSJjb21wb3NlV2ViVmlld19wcmV2aW91c2VfY29udGVudCI+PGJsb2NrcXVvdGUgaWQ9Im1h aWwtYXBwLWF1dG8tcXVvdGUiIHN0eWxlPSJib3JkZXItbGVmdDogMXB4IHNvbGlkICNmYzJjMzg7 IG1hcmdpbjogMTBweCAxMHB4IDEwcHggNXB4OyBwYWRkaW5nOiAwIDAgMCAxMHB4OyI+PGRpdiBj bGFzcz0ianMtaGVscGVyIGpzLXJlYWRtc2ctbXNnIj4KCTxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+ PC9zdHlsZT4KIAk8ZGl2PgoJCTxiYXNlIHRhcmdldD0iX3NlbGYiIGhyZWY9Imh0dHBzOi8vZS1h ai5teS5jb20vIj4KCQkKCQkJPGRpdiBpZD0ic3R5bGVfMTQ4NzI4MDM3MjAwMDAwMTAzOTFfQk9E WSI+SGkgSURSLDxicj4KPGJyPgpXZSBoYXZlIGFuIEktRCBpbiBCRVNTIChhbHNvIGRpc2N1c3Nl ZCBpbiBTRkMpIHRoYXQgcHJvcG9zZXMgdG8gdXNlIEJHUCBhcyBhPGJyPgpjb250cm9sIHBsYW5l IGZvciBhbmQgU0ZDIChvdmVybGF5KSBuZXR3b3JrLjxicj4KPGJyPgpZb3UgY2FuIGJlc3QgZ3Jh c3AgdGhlIHByb3Bvc2VkIGV4dGVuc2lvbnMgdG8gQkdQIGJ5IGxvb2tpbmcgYXQgdGhlIEktRC4g V2U8YnI+CnRoaW5rIHRoZSBleHRlbnNpb25zIGFyZSBuYXR1cmFsIGFuZCByZWxhdGl2ZWx5IHNt YWxsLCBieSBZTU1WIDotKTxicj4KPGJyPgpDb21wbGV0ZWx5IHVuZGVyc3RhbmRpbmcgd2hhdCB3 ZSBhcmUgcGxhbm5pbmcgbWF5IGJlIGhhcmQgd2l0aG91dCBzb21lPGJyPgpiYWNrZ3JvdW5kIGlu IHNlcnZpY2UgZnVuY3Rpb24gY2hhaW5pbmcsIGJ1dCBmcm9tIDMwLDAwMCBmdC4uLjxicj4KPGJy PgpBbiBTRkMgbmV0d29yayBpcyBhbiBvdmVybGF5IG5ldHdvcmsuPGJyPgpTZXJ2aWNlIEZ1bmN0 aW9uIEZvcndhcmRlcnMgKFNGRnMpIGFyZSBjb25uZWN0ZWQgYnkgdHVubmVscyBvdmVyIG9uZSBv ciBtb3JlPGJyPgp1bmRlcmxheSBuZXR3b3Jrcy48YnI+ClNGRnMgcHJvdmlkZSBhY2Nlc3MgdG8g U2VydmljZSBGdW5jdGlvbiBJbnN0YW5jZXMgKFNGSXMpPGJyPgpTRklzIGFyZSBzdHJ1bmcgdG9n ZXRoZXIgaW4gYW4gb3JkZXJlZCBzZXF1ZW5jZSBjYWxsZWQgYSBTZXJ2aWNlIEZ1bmN0aW9uIFBh dGg8YnI+CihTRlApIFthbiBpbnN0YW5jZSBvZiBhIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW4gKFNG QyldPGJyPgpJdCB1c2VkIHRvIGJlIHRoYXQgc2VydmljZSBmdW5jdGlvbnMgd2VyZSBpbnN0YWxs ZWQgYXMgcGh5c2ljYWwgYnVtcHMgaW4gdGhlPGJyPgp3aXJlLCBidXQgbm93IHRoZXkgbWF5IGJl IHJlbW90ZSBhbmQgdmlydHVhbGl6ZWQuPGJyPgpQYWNrZXRzIHRoYXQgbmVlZCB0byBiZSBhY3Rl ZCBvbiBieSBhIHNlcmllcyBvZiBzZXJ2aWNlIGZ1bmN0aW9ucyAoYW4gU0ZDKSBhcmU8YnI+CmNs YXNzaWZpZWQgYnkgYSBDbGFzc2lmaWVyIGFuZCBhc3NpZ25lZCB0byBhbiBTRlAuPGJyPgpUaGUg cGFja2V0cyBhcmUgbWFya2VkICh3aXRoIGFuIGFkZGl0aW9uYWwgZW5jYXBzdWxhdGlvbiBoZWFk ZXIpIGFuZCBwYXNzZWQgZnJvbTxicj4KU0ZGIHRvIFNGRiBmb3IgZGVsaXZlcnkgdG8gdGhlIFNG SXMuPGJyPgo8YnI+Ck91ciBhcHByb2FjaCB1c2VzIEJHUCBzbyB0aGF0Ojxicj4KLSBTRkZzIGNh biBhZHZlcnRpc2Ugd2hpY2ggU0ZJcyB0aGV5IHByb3ZpZGUgYWNjZXNzIHRvIHNvIHRoYXQgYSBj b250cm9sbGVyIGNhbjxicj4KYnVpbGQgU0ZQczxicj4KLSBhIGNvbnRyb2xsZXIgdG8gYWR2ZXJ0 aXNlIHRoZSB2YXJpb3VzIFNGUHMgc28gdGhhdCBTRkZzIGNhbiB3b3JrIG91dCBob3cgdG88YnI+ CmRlbGl2ZXIgPGJyPgombmJzcDsmbmJzcDsmbmJzcDtwYWNrZXRzIHRvIHRoZSByaWdodCBTRklz LCBhbmQgaG93IHRvIHJvdXRlIHBhY2tldHMgdG8gdGhlIGNvcnJlY3QgbmV4dCBTRkY8YnI+Ci0g YSBjb250cm9sbGVyIHRvIGluc3RydWN0IGEgQ2xhc3NpZmllciBvbiBob3cgdG8gc2VsZWN0IHRo ZSByaWdodCBTRlA8YnI+Cjxicj4KV2UgYWxzbyBoZWxwIHRoZSBTRkYga25vdyB3aGF0IHR1bm5l bCB0byB1c2UgdG8gcmVhY2ggdGhlIG5leHQgU0ZGLCBhbmQgd2hhdCBTRkM8YnI+CmVuY2Fwc3Vs YXRpb24gdG8gdXNlIG9uIGVhY2ggaG9wLjxicj4KPGJyPgpGb3IgbW9yZSBkZXRhaWxzLCByZWFk IHRoZSBkcmFmdCA6LSk8YnI+Cjxicj4KRGlzY3Vzc2lvbnMgc2hvdWxkIHByb2JhYmx5IGJlIG9u IHRoZSBCRVNTIGxpc3QsIGJ1dCB3ZSB3aWxsIHByb2JhYmx5IGFsc28gc3BvdDxicj4KdGhlbSBp ZiB0aGV5IGhhcHBlbiBoZXJlLjxicj4KPGJyPgpUaGFua3MsPGJyPgpBZHJpYW48YnI+Cjxicj4K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+CklkciBt YWlsaW5nIGxpc3Q8YnI+CjxhIGhyZWY9Ii9jb21wb3NlP1RvPUlkckBpZXRmLm9yZyI+SWRyQGll dGYub3JnPC9hPjxicj4KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pZHIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2lkcjwvYT48YnI+CjwvZGl2PgoJCQkKCQkKCQk8YmFzZSB0YXJnZXQ9Il9zZWxmIiBo cmVmPSJodHRwczovL2UtYWoubXkuY29tLyI+Cgk8L2Rpdj4KCgkKPC9kaXY+PC9ibG9ja3F1b3Rl PjwvZGl2PjwvZGl2PjwvQk9EWT48L0hUTUw+Cg== ----ALT--iM8uhhfa1487290594-- From nobody Thu Feb 16 16:55: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 042211296E7; Thu, 16 Feb 2017 16:55:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, 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 7iGMxsmo6WOY; Thu, 16 Feb 2017 16:55:08 -0800 (PST) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::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 7A64512944F; Thu, 16 Feb 2017 16:55:08 -0800 (PST) Received: by mail-qk0-x229.google.com with SMTP id s186so32198061qkb.1; Thu, 16 Feb 2017 16:55:08 -0800 (PST) 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=c3z4cwIzURhxML3Aif/BHxSrHFTVrSUXjVvqW55wy2E=; b=YRXBvk6vBBcSEbsq8HF7G7rQAYgivMlFig5Ii9r3aGnZm/EOMXQKTj9hA4TeFRrA4O mBzxOoyY9dsCAjBo4wPyP0LRUZhRtiUcmhg/NzR02nvv4k3w2/1b09RVK9FnoIuJACsc cJjiVN813iiVvXCUd7UxTqYxoGNjFETneGpltj/D3b/b+Mj24FU3hhUclK2bryjsQkjq BwvqBUiL8slMOSJqxQda2RVIhrV9BkqYAApO8c7OPEw7ip+n7Le8b/b6D5Nh11UNgfCb 79A1q6K6EwfvDCqXPAaX0rvB4PiUteNzZ+4x93dNdqNzDWPDyrviNWeK+JVLpJKP+8q9 jYQg== 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=c3z4cwIzURhxML3Aif/BHxSrHFTVrSUXjVvqW55wy2E=; b=XctKu3immc3Mmg1LBpXEq8skkd0B5XKEdfaj0u4v6d7RNV+Mp8COUAdY3t5wEm2oLS BAylZjiE5Wbye2UIgDBs8AGosdtzYktrUoC29KEv5d4jcTa1J75EK34pc3EeL/GkstZT wTNnO444pOr//LC+gyM5BNWsd5kTGoHYq6ncc8uMxCrTTi94LXsqxMsqKFLTx5iNdOlw 9iPkSaRrQbk++HOVOMwn7482h3tmNuOTwYZiPzJ+XQkY/0U1LVoHYoQft+T+Oq0yZfNg IQJ6Y5fUlxp97yiwaHIRNARYQQsqaLoYCX/J0KX3MdEhtQI0e/rVO8S5Yc9YknEe6As4 na1g== X-Gm-Message-State: AMke39niciYWB2lQujVseHlg+OrxvNIGdLXZKQs3Royie+2xPEGN8h+WiwFuaZRKAXnlkjBkgSxSrzDTM5yvPg== X-Received: by 10.55.192.93 with SMTP id o90mr4914410qki.18.1487292907607; Thu, 16 Feb 2017 16:55:07 -0800 (PST) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.140.28.69 with HTTP; Thu, 16 Feb 2017 16:55:07 -0800 (PST) Received: by 10.140.28.69 with HTTP; Thu, 16 Feb 2017 16:55:07 -0800 (PST) In-Reply-To: <1487290594.4104319@f4.my.com> References: <0a2c01d2889b$2eda90f0$8c8fb2d0$@olddog.co.uk> <1487290594.4104319@f4.my.com> From: Robert Raszuk Date: Fri, 17 Feb 2017 01:55:07 +0100 X-Google-Sender-Auth: xZ8cBrFCyp5DHPrUNISN6wDeAis Message-ID: To: Tony Przygienda Content-Type: multipart/alternative; boundary=001a114990b26f61200548af5dd9 Archived-At: Cc: bess@ietf.org, idr wg Subject: Re: [Idr] IDR heads up on BESS draft: BGP for SFC: draft-mackie-bess-nsh-bgp-control-plane-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 00:55:11 -0000 --001a114990b26f61200548af5dd9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Using BGP as control plane for arbitrary service topology creation is by all means a good thing. That is why in 2013 Keyur and myself have posted proposal describing it to IETF in form of BGP Vector Routing: https://tools.ietf.org/html/draft-patel-raszuk-bgp-vector-routing-00 I leave it to the audience of bess and idr working groups to jugde which of two proposals is more elegant and low risk and effort. Cheers, R. On Feb 16, 2017 7:17 PM, "Tony Przygienda" wrote: Discounted for same affiliation with the authors =F0=9F=98=8F I do think pe= rsonally it's a symmetrical, quite elegant and low risk/effort draft given how successful equivalent BGP "low level network service access point" synchronization proposals were over last years ... Sent from myMail for iOS Thursday, February 16, 2017, 13:25 -0800 from Adrian Farrel < adrian@olddog.co.uk>: Hi IDR, We have an I-D in BESS (also discussed in SFC) that proposes to use BGP as = a control plane for and SFC (overlay) network. You can best grasp the proposed extensions to BGP by looking at the I-D. We think the extensions are natural and relatively small, by YMMV :-) Completely understanding what we are planning may be hard without some background in service function chaining, but from 30,000 ft... An SFC network is an overlay network. Service Function Forwarders (SFFs) are connected by tunnels over one or mor= e underlay networks. SFFs provide access to Service Function Instances (SFIs) SFIs are strung together in an ordered sequence called a Service Function Path (SFP) [an instance of a Service Function Chain (SFC)] It used to be that service functions were installed as physical bumps in th= e wire, but now they may be remote and virtualized. Packets that need to be acted on by a series of service functions (an SFC) are classified by a Classifier and assigned to an SFP. The packets are marked (with an additional encapsulation header) and passed from SFF to SFF for delivery to the SFIs. Our approach uses BGP so that: - SFFs can advertise which SFIs they provide access to so that a controller can build SFPs - a controller to advertise the various SFPs so that SFFs can work out how to deliver packets to the right SFIs, and how to route packets to the correct next SFF - a controller to instruct a Classifier on how to select the right SFP We also help the SFF know what tunnel to use to reach the next SFF, and what SFC encapsulation to use on each hop. For more details, read the draft :-) Discussions should probably be on the BESS list, but we will probably also spot them if they happen here. Thanks, Adrian _______________________________________________ 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 --001a114990b26f61200548af5dd9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Usi= ng BGP as control plane for arbitrary service topology creation is by all m= eans a good thing.

That = is why in 2013 Keyur and myself have posted proposal describing it to IETF = in form of BGP Vector Routing:


I leave i= t to the audience of bess and idr working groups to jugde which of two prop= osals is more elegant and low risk and effort.

<= /div>
Cheers,
R.


On Feb 16, 2017 7:17 PM, &= quot;Tony Przygienda" <tonys= ietf@gmail.com> wrote:
Discounted for same affiliation with the authors= =F0=9F=98=8F I do think personally it's a symmetrical, quite elegant a= nd low risk/effort draft given how successful equivalent BGP "low leve= l network service access point" synchronization proposals were over la= st years ...



Sent from myMail for iOS


T= hursday, February 16, 2017, 13:25 -0800 from Adrian Farrel <adrian@olddog.co.uk>:<= div class=3D"elided-text">
=09
=09 =09
Hi IDR= ,

We have an I-D in BESS (also discussed in SFC) that proposes to use BGP as = a
control plane for and SFC (overlay) network.

You can best grasp the proposed extensions to BGP by looking at the I-D. We=
think the extensions are natural and relatively small, by YMMV :-)

Completely understanding what we are planning may be hard without some
background in service function chaining, but from 30,000 ft...

An SFC network is an overlay network.
Service Function Forwarders (SFFs) are connected by tunnels over one or mor= e
underlay networks.
SFFs provide access to Service Function Instances (SFIs)
SFIs are strung together in an ordered sequence called a Service Function P= ath
(SFP) [an instance of a Service Function Chain (SFC)]
It used to be that service functions were installed as physical bumps in th= e
wire, but now they may be remote and virtualized.
Packets that need to be acted on by a series of service functions (an SFC) = are
classified by a Classifier and assigned to an SFP.
The packets are marked (with an additional encapsulation header) and passed= from
SFF to SFF for delivery to the SFIs.

Our approach uses BGP so that:
- SFFs can advertise which SFIs they provide access to so that a controller= can
build SFPs
- a controller to advertise the various SFPs so that SFFs can work out how = to
deliver
=C2=A0=C2=A0=C2=A0packets to the right SFIs, and how to route packets to th= e correct next SFF
- a controller to instruct a Classifier on how to select the right SFP

We also help the SFF know what tunnel to use to reach the next SFF, and wha= t SFC
encapsulation to use on each hop.

For more details, read the draft :-)

Discussions should probably be on the BESS list, but we will probably also = spot
them if they happen here.

Thanks,
Adrian

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

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


--001a114990b26f61200548af5dd9-- From nobody Thu Feb 16 22:02: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 3A643129514; Thu, 16 Feb 2017 22:02:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.586 X-Spam-Level: X-Spam-Status: No, score=-4.586 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, RCVD_IN_MSPIKE_H2=-1.887, 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=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 KpsoOB1DcOhp; Thu, 16 Feb 2017 22:01:59 -0800 (PST) Received: from BAY004-OMC1S28.hotmail.com (bay004-omc1s28.hotmail.com [65.54.190.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36FED129409; Thu, 16 Feb 2017 22:01:59 -0800 (PST) Received: from NAM04-BN3-obe.outbound.protection.outlook.com ([65.54.190.59]) by BAY004-OMC1S28.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Thu, 16 Feb 2017 22:01:59 -0800 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=xnL58kMx77QmzUGa9H9qXkdbzwSHjCZDfEfZA5oQKoo=; b=ja+19YriRP0SBh6IsP2ZcDF//RIRjfW+8EXaDnbXBYe8QGjq5pjn7Ii3+EiOL+EQ54DlZmPVo4ANaxFOuXwVMeNzBm04Ji9fCIcro6/mGWDP2XxEZgv/owQ0kuvWIPR59Dc6L9rxJGD4Yzwj/t0ekx4KkWh8lVKXdkJqvJLww9buxb4tq5aV1ilSk4g5Anzhh3LXCk8dV8iDR8lipUayor18LumkP8NFEASNLguFxj1hiu3aRYh+TAiaFHJn8GW4yBVtvxlVTUVLDH/VBDOBmJRdYcg+cqF3XgbJ7JLSLrfjO54CpOiOklmO3grj5wCFp0P4yTXO4FS9xiJfzA0aRg== Received: from SN1NAM04FT042.eop-NAM04.prod.protection.outlook.com (10.152.88.54) by SN1NAM04HT221.eop-NAM04.prod.protection.outlook.com (10.152.89.227) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.904.16; Fri, 17 Feb 2017 06:01:57 +0000 Received: from DM3PR13MB0604.namprd13.prod.outlook.com (10.152.88.60) by SN1NAM04FT042.mail.protection.outlook.com (10.152.89.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.904.16 via Frontend Transport; Fri, 17 Feb 2017 06:01:57 +0000 Received: from DM3PR13MB0604.namprd13.prod.outlook.com ([10.164.8.150]) by DM3PR13MB0604.namprd13.prod.outlook.com ([10.164.8.150]) with mapi id 15.01.0919.013; Fri, 17 Feb 2017 06:01:57 +0000 From: Shitanshu Shah To: Ron Bonica , "rtg-dir@ietf.org" , "draft-ietf-idr-sla-exchange.all@ietf.org" , "idr@ietf.org" Thread-Topic: RtgDir review: draft-ietf-idr-sla-exchange-10 Thread-Index: AdKIcLCEU+uutt39QyCrZCwOKAXyLQAcLKCo Date: Fri, 17 Feb 2017 06:01:56 +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: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=hotmail.com; x-incomingtopheadermarker: OriginalChecksum:1736BB9E1053C13FDE03841AE68FC64F7155BF168C4E923157FCBF1B86BBA3BD; UpperCasedChecksum:C7EEF6058EE9E9110EB5580708AB4420795B4FFD613366CC899ACA227D3BB277; SizeAsReceived:7965; Count:39 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [9YgaT+u8APbvmGpt52VgtVAgpmMRp51S] x-incomingheadercount: 39 x-eopattributedmessage: 0 x-microsoft-exchange-diagnostics: 1; SN1NAM04HT221; 7:+K0c/igJPYJr7+gTFGBhFDlNQ5gqvaZh/J7+V/6436rIY24bZUUTaY5dw3pMZggPmyQCR/cTcGCXC56vPC9In+EMrBh3c7H8IuWlDPjbAFIBBIbxUsoBTcMcJ06P6jmXWMFlHk6mO+iwNLKawBhG8xhSM8kTrh77AbgQumRoO7YDH3qw3hpbXI81LxQHJAg+umtARCMnOZlMzQpdPuT2eA2QU9Pkqe6F8sAfPVsq0iiVv0V4TuXx2Q5LhNNodUC1Mu01pTdTS2qdJvofhOKhu7eCYNVz25Kho2Vb4nj5vBbShvuQGWXJCE6EdGZhmulN/hIhB4af0AWT/gcynFGmZA== x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(10019020)(98900012); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1NAM04HT221; H:DM3PR13MB0604.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: bdd8b80f-5487-4285-4126-08d456fa7aef x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(5061506541)(5061507331)(1603103135)(1601125222)(1603101373)(1701031045); SRVR:SN1NAM04HT221; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015087)(444000031); SRVR:SN1NAM04HT221; BCL:0; PCL:0; RULEID:; SRVR:SN1NAM04HT221; x-forefront-prvs: 02213C82F8 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM3PR13MB060413F4B03D932E5E6BE75DE55D0DM3PR13MB0604namp_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Feb 2017 06:01:56.9834 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM04HT221 X-OriginalArrivalTime: 17 Feb 2017 06:01:59.0191 (UTC) FILETIME=[59C08A70:01D288E3] Archived-At: Subject: Re: [Idr] RtgDir review: draft-ietf-idr-sla-exchange-10 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 06:02:02 -0000 --_000_DM3PR13MB060413F4B03D932E5E6BE75DE55D0DM3PR13MB0604namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank you Ron Bonica for spending time for the review, Please find response inline ##svshah Regards, Shitanshu ________________________________ From: Ron Bonica Sent: Thursday, February 16, 2017 10:56 AM To: rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.or= g Subject: RtgDir review: draft-ietf-idr-sla-exchange-10 Hello, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review. The purpose of the re= view is to provide assistance to the Routing ADs. For more information abou= t the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/t= rac/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 Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-ietf-idr-sla-exchange-10 Reviewer: Ron Bonica Review Date: 2/16/2017 IETF LC End Date: TBD Intended Status: Standards Track Summary: I have some minor concerns about this document that I think should be resol= ved before publication. Comments: Major Issues: This document might benefit from discussion of operational issues. I assume= that when a BGP listener learns a route with the SLA Exchange Attribute, i= t provisions class of service forwarding classes on interfaces. ##svshah, though this is one desired use of exchanging SLA content, the dra= ft focuses on transporting SLA content from the SLA Producer to the SLA Con= sumer. Processing of the QoS attribute content, at the SLA Consumer, is out= side the scope of this document. ##svshah, Let me know if you have a suggestion to make description clearer = in Section 1 and 2 to highlight this. I also assume that a) it takes time to provision class of service forwardin= g classes and b) the number of forwarding classes that can be provisioned a= re finite. What does the BGP listener do when the number of forwarding clas= ses requested exceeds its capacity to deliver? ##svshah, Since scope of the document is to transport SLA content from the = SLA Producer to the SLA Consumer, the document considers error handling in = the context of transporting data and thus any formating errors and semantic= s errors within that context. Any errors in the context of processing QoS a= ttribute content at the SLA Consumer is outside the scope of the document. When a route flaps? How does the router protect itself ##svshah, As highlighted in section 4, some sort of SLA policy change may b= e considered for SLA advertisement. That approach should protect from route= flaps. did I understand your question correct? If not please clarify. In the Security Considerations section, I am concerned about the possibilit= y of intermediate AS's modifying the SLA Exchange Attribute. It seems that = you need to have some degree of trust in every AS on the path (not only tho= se included in the attribute) ##svshah, it is correct that "Deployment considerations mainly target use o= f QoS Attribute and SLA SubType in managed networks and those where a trust= relationship is in place (Customer to Provider, or Provider to Provider). = It is NOT RECOMMENDED to enable this attribute at the scale of the Interne= t unless if means to prevent leaking sensitive information are enforced." [= from the Security section]. do you suggest any more clarity on this statement? Minor Issues: In Section 3.2, is the flag really needed? Doesn't an AS list containing on= ly the receivers AS have exactly the same meaning? ##svshah, We find it very helpful to keep implementations simple for the on= es that would want to support SLA Exchange only for peer receivers and thus= making availability of this option. Nits: ##svshah, will take care of all the nits. Thank you, Miscellaneous warnings: -------------------------------------------------------------------------= --- =3D=3D The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword= , but does not include the phrase in its RFC 2119 key words list. Checking references for intended status: Proposed Standard -------------------------------------------------------------------------= --- (See RFCs 3967 and 4897 for information about using normative referenc= es to lower-maturity documents in RFCs) =3D=3D Unused Reference: 'RFC2434' is defined on line 1279, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC6793' is defined on line 1301, but no explic= it reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Downref: Normative reference to an Informational RFC: RFC 4272 ** Downref: Normative reference to an Informational RFC: RFC 7132 =3D=3D Outdated reference: draft-ietf-netconf-restconf has been published= as RFC 8040 --_000_DM3PR13MB060413F4B03D932E5E6BE75DE55D0DM3PR13MB0604namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable


Thank you Ron Bonica for spending time for the review,


Please find response inline ##svshah


Regards,
Shitanshu

From: Ron Bonica <rbon= ica@juniper.net>
Sent: Thursday, February 16, 2017 10:56 AM
To: rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@= ietf.org
Subject: RtgDir review: draft-ietf-idr-sla-exchange-10
 
Hello,

I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review. The purpose of the re= view is to provide assistance to the Routing ADs. For more information about the Routing Directorate, pleas= e see 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 Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft.

Document:  draft-ietf-idr-sla-exchange-10
Reviewer: Ron Bonica
Review Date:  2/16/2017
IETF LC End Date: TBD
Intended Status: Standards Track

Summary:

I have some minor concerns about this document that I think should be resol= ved before publication.

Comments:

Major Issues:

This document might benefit from discussion of operational issues. I assume= that when a BGP listener learns a route with the SLA Exchange Attribute, i= t provisions class of service forwarding classes on interfaces.

##svshah, thoug= h this is one desired use of exchanging SLA content, the draft focuses on t= ransporting SLA content from the SLA Producer to the SLA Consumer. Processi= ng of the QoS attribute content, at the SLA Consumer, is outside the scope of this document.


##svshah, Let m= e know if you have a suggestion to make description clearer in Section 1 an= d 2 to highlight this.



I also assume that a) it takes time to provision c= lass of service forwarding classes and b) the number of forwarding classes = that can be provisioned are finite. What does the BGP listener do when the = number of forwarding classes requested exceeds its capacity to deliver? 

##svshah, Since= scope of the document is to transport SLA content from the SLA Producer to= the SLA Consumer, the document considers error handling in the context of = transporting data and thus any formating errors and semantics errors within that context. Any errors in the context= of processing QoS attribute content at the SLA Consumer is outside the sco= pe of the document.



When a route flaps? How does the router protect it= self

##svshah, As hi= ghlighted in section 4, some sort of SLA policy change may be considered fo= r SLA advertisement. That approach should protect from route flaps. did I u= nderstand your question correct? If not please clarify.



In the Security Considerations section, I am concerned about the possibilit= y of intermediate AS's modifying the SLA Exchange Attribute. It seems that = you need to have some degree of trust in every AS on the path (not only tho= se included in the attribute)

##svshah, it is= correct that "Deployment considerations mainly target use of QoS = ;Attribute and SLA SubType in managed networks and those where a tru= st relationship is in place (Customer to Provider, or Provider to Provider).  It is NOT RECOMMENDED to enable this = attribute at the scale of the Internet unless if means to prevent leak= ing sensitive information are enforced." [from the Security secti= on].


do you suggest any more clarity on this statement?



Minor Issues:

In Section 3.2, is the flag really needed? Doesn't an AS list containing on= ly the receivers AS have exactly the same meaning?

##svshah, We fi= nd it very helpful to keep implementations simple for the ones that would w= ant to support SLA Exchange only for peer receivers and thus making availab= ility of this option.



Nits:


##svshah, will = take care of all the nits.


Thank you,



Miscellaneous warnings:
  --------------------------------------------------------------------= --------

  =3D=3D The document seems to use 'NOT RECOMMENDED' as an RFC 2119 ke= yword, but
     does not include the phrase in its RFC 2119 key wo= rds list.


  Checking references for intended status: Proposed Standard
  --------------------------------------------------------------------= --------

     (See RFCs 3967 and 4897 for information about usin= g normative references
     to lower-maturity documents in RFCs)

  =3D=3D Unused Reference: 'RFC2434' is defined on line 1279, but no e= xplicit
     reference was found in the text

  =3D=3D Unused Reference: 'RFC6793' is defined on line 1301, but no e= xplicit
     reference was found in the text

  ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226)
  ** Downref: Normative reference to an Informational RFC: RFC 4272
  ** Downref: Normative reference to an Informational RFC: RFC 7132
  =3D=3D Outdated reference: draft-ietf-netconf-restconf has been publ= ished as
     RFC 8040
--_000_DM3PR13MB060413F4B03D932E5E6BE75DE55D0DM3PR13MB0604namp_-- From nobody Thu Feb 16 22:56: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 9F7D5128874; Thu, 16 Feb 2017 22:56:50 -0800 (PST) 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 UEtr1sJMJrdS; Thu, 16 Feb 2017 22:56:49 -0800 (PST) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::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 C521B1293F0; Thu, 16 Feb 2017 22:56:48 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id k15so33718458qtg.3; Thu, 16 Feb 2017 22:56:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hi8QOpL9a+xF5ZAaNibNHqhFTVFEND8hp0V/bZ+mOjg=; b=kfierrtD9F33IiwKEK4Tmia7rIHRQZwDvpLcwp8HF1+SQDwPh+CcZnF8AbpwnbHnS8 zBUTpUm89e7xLrYSmlgl6nNT6ufPjio60fnhyMfkMgGL48aMQ/xHtV+PRmE5mYIxyhp7 oX8SfCpDmxEODrzzq+j+0GYChecfoK+sUVCClMfFwLQ2/qOInjDEIcztHsRx+cpRMNnu WrPt7xi4+ASexPllEc7am86/euzfm2U8zjXlNNv+cdUdBtPLk04mlsFVu+/s7LfZ/HlH YNepvUk8pMZg6AL4FmPtpi6VK0o5bJ4E4wRoQKB7mDNmCHau5tuxTB4uSf7WKMCZ5tED Urbw== 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=hi8QOpL9a+xF5ZAaNibNHqhFTVFEND8hp0V/bZ+mOjg=; b=TfG0uV/JS1n13lafs4hR/Vgo2PAejPjX2uhap95ORlowlqCSyg92PtPQXICen5kOCR HmEJW7wxOnp5Y1J3D2+Pe779Qt/RIxtKljh0g10E9/TEv1ahoRFpaxKqtU9YBnmygLCb cQ+MWSkKcmBLUklgIwvTUmrUiwExHYa3bppVKb2Pa81fvbSqGkznLK9UuNlqt/Idf7qs diTPTgr8zhs9zODC2wQa/unzN1d9uk3wCZfQAQ8pnCBwd7eNvy/ph+B/tXftmowEvcCm J2a5De5706NP67PRWxTJwBsrbrEyUyR1iccK4CqcmFq8T+ocQe9EVEHU8S93qP7oWmR5 fTjg== X-Gm-Message-State: AMke39nO4x2rh3EgbMG01tIA/twGit6EGAqOBpjdfOIZc2511bkc0zsqt2FOAdaH1NEZDa9wMb7u8zTfdgZsMQ== X-Received: by 10.237.38.133 with SMTP id q5mr5628127qtd.21.1487314607959; Thu, 16 Feb 2017 22:56:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.3.27 with HTTP; Thu, 16 Feb 2017 22:56:47 -0800 (PST) In-Reply-To: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> References: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> From: Miya Kohno Date: Fri, 17 Feb 2017 15:56:47 +0900 Message-ID: To: Susan Hares Content-Type: multipart/alternative; boundary=001a114dabaee07f960548b46a8d Archived-At: Cc: idr@ietf.org, spring@ietf.org Subject: Re: [Idr] [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 06:56:50 -0000 --001a114dabaee07f960548b46a8d Content-Type: text/plain; charset=UTF-8 I support this draft. Thanks! Miya Kohno On Thu, Feb 16, 2017 at 8:34 AM, Susan Hares wrote: > This begins a 2 week IDR WG last call on draft-ietf-idr-bgpls-segment-routing-epe > from (2/15 to 3/1/2017) There are two implementations describe on the > wiki at: > > https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls- > segment-routing-epe%20 > > > > The two implementation are from Cisco IOS-XR release 6.0.2 and Cisco > Nexus Switch N9000/N3000 platforms running NX-OS 7.0(3)I1(1) or greater. > The authors will indicate on the list and in the wiki the following > information : > > > > 1) Were these implementations separate implementations? > > 2) What were the results of the interoperability tests? > > > > This work is linked to the draft-ietf-spring-segment-routing-central-epe > work in the SPRING WG. Based on the two drafts, the WG should might > consider: > > 1) Is there need for this work in deployments in networks/ > > 2) Is this technically ready for publication? > > 3) Does it fit with the spring informational draft? > > > > For the ease of reference the web references are below: > > https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/ > > https://datatracker.ietf.org/doc/draft-ietf-spring-segment- > routing-central-epe/ > > > > Sue Hares > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > --001a114dabaee07f960548b46a8d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I support this draft.


Th= anks!
Miya Kohno

On Thu, Feb 16, 2017 at 8:34 AM, Susan Hares <shares@nd= zh.com> wrote:

This = begins a 2 week IDR WG last call on draft-ietf-idr-bgpls-segment-routi= ng-epe from (2/15 to 3/1/2017) =C2=A0=C2=A0=C2=A0There are two implementati= ons describe on the wiki at:

https= ://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-segment-routi= ng-epe%20

=C2=A0

The two implementation are from =C2=A0Cisco IOS-XR release 6.0.2 and Cisco Nexus Switch N9000/N3000 plat= forms running NX-OS 7.0(3)I1(1) or greater.=C2=A0=C2=A0 The authors will in= dicate on the list and in the wiki the following information :

=C2=A0

1)Were these implementations separate implementations? =

<= u>2)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 What were the resul= ts of the interoperability tests?

=C2=A0

This work is linked to = the draft-ietf-spring-segment-routing-central-epe work in the SPRING W= G. Based on the two drafts, the WG should might consider: =C2=A0<= /u>

1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <= /u>Is there need for this work in deployme= nts in networks/

2)=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Is this te= chnically ready for publication?

= 3)=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Does it fit with the spring informational draft? =

=C2=A0

For= the ease of reference the web references are below: <= /p>

https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/

= https:/= /datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-centr= al-epe/

=C2=A0

Sue Hares


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

--001a114dabaee07f960548b46a8d-- From nobody Fri Feb 17 00:05: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 EED37129527; Fri, 17 Feb 2017 00:05:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.786 X-Spam-Level: X-Spam-Status: No, score=-8.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-1.887, 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 2Rnsk7LWfPvz; Fri, 17 Feb 2017 00:05:21 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 E29DB1294D3; Fri, 17 Feb 2017 00:05:20 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id B88CA868AD9FF; Fri, 17 Feb 2017 08:05:16 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id v1H85HOf031013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 Feb 2017 09:05:18 +0100 Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id v1H85681006769 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Feb 2017 08:05:17 GMT Received: from FR711WXCHMBA06.zeu.alcatel-lucent.com ([169.254.2.227]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0301.000; Fri, 17 Feb 2017 09:05:11 +0100 From: "Van De Velde, Gunter (Nokia - BE)" To: Susan Hares Thread-Topic: [ALU] Re: [Idr] [spring] IDR WG 2 week WG LC ondraft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) Thread-Index: AQHSiPSPHgVYM3zURr+F4Gs1EKSVZg== Date: Fri, 17 Feb 2017 08:05:09 +0000 Message-ID: References: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> <1E319B28-BF06-4BEB-9D27-552530FC21EA@gmail.com> In-Reply-To: <1E319B28-BF06-4BEB-9D27-552530FC21EA@gmail.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_B3307E1244314B2384C6A0BE9BA511AFalcatellucentcom_" MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" , "spring@ietf.org" Subject: Re: [Idr] [ALU] Re: [spring] IDR WG 2 week WG LC ondraft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 08:05:23 -0000 --_000_B3307E1244314B2384C6A0BE9BA511AFalcatellucentcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSByZWFkIHRoZSBwYXBlciBhbmQgWWVwIEkgc3VwcG9ydA0KDQpHLw0KDQpGcm9tOiBJZHIgPGlk ci1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgSmVmZiBUYW50c3VyYSA8amVmZnRhbnQu aWV0ZkBnbWFpbC5jb20+DQpEYXRlOiBUaHVyc2RheSwgMTYgRmVicnVhcnkgMjAxNyBhdCAxMjow Ng0KVG86IFN1c2FuIEhhcmVzIDxzaGFyZXNAbmR6aC5jb20+DQpDYzogImlkckBpZXRmLm9yZyIg PGlkckBpZXRmLm9yZz4sICJzcHJpbmdAaWV0Zi5vcmciIDxzcHJpbmdAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBbQUxVXSBSZTogW0lkcl0gW3NwcmluZ10gSURSIFdHIDIgd2VlayBXRyBMQyBvbmRyYWZ0 LWlldGYtaWRyLWJncGxzLXNlZ21lbnQtcm91dGluZy1lcGUgLSAoMi8xNS8yMDE3IHRvIDMvMS8y MDE3KQ0KDQpZZXMvc3VwcG9ydA0KDQpSZWdhcmRzLA0KSmVmZg0KDQpPbiBGZWIgMTUsIDIwMTcs IGF0IDIzOjM0LCBTdXNhbiBIYXJlcyA8c2hhcmVzQG5kemguY29tPG1haWx0bzpzaGFyZXNAbmR6 aC5jb20+PiB3cm90ZToNClRoaXMgYmVnaW5zIGEgMiB3ZWVrIElEUiBXRyBsYXN0IGNhbGwgb24g ZHJhZnQtaWV0Zi1pZHItYmdwbHMtc2VnbWVudC1yb3V0aW5nLWVwZSBmcm9tICgyLzE1IHRvIDMv MS8yMDE3KSAgICBUaGVyZSBhcmUgdHdvIGltcGxlbWVudGF0aW9ucyBkZXNjcmliZSBvbiB0aGUg d2lraSBhdDoNCmh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL2lkci93aWtpL2RyYWZ0LWlldGYt aWRyLWJncGxzLXNlZ21lbnQtcm91dGluZy1lcGUlMjANCg0KVGhlIHR3byBpbXBsZW1lbnRhdGlv biBhcmUgZnJvbSAgQ2lzY28gSU9TLVhSIHJlbGVhc2UgNi4wLjIgYW5kIENpc2NvIE5leHVzIFN3 aXRjaCBOOTAwMC9OMzAwMCBwbGF0Zm9ybXMgcnVubmluZyBOWC1PUyA3LjAoMylJMSgxKSBvciBn cmVhdGVyLiAgIFRoZSBhdXRob3JzIHdpbGwgaW5kaWNhdGUgb24gdGhlIGxpc3QgYW5kIGluIHRo ZSB3aWtpIHRoZSBmb2xsb3dpbmcgaW5mb3JtYXRpb24gOg0KDQoNCjEpICAgICAgIFdlcmUgdGhl c2UgaW1wbGVtZW50YXRpb25zIHNlcGFyYXRlIGltcGxlbWVudGF0aW9ucz8NCg0KMikgICAgICAg V2hhdCB3ZXJlIHRoZSByZXN1bHRzIG9mIHRoZSBpbnRlcm9wZXJhYmlsaXR5IHRlc3RzPw0KDQpU aGlzIHdvcmsgaXMgbGlua2VkIHRvIHRoZSBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRp bmctY2VudHJhbC1lcGUgd29yayBpbiB0aGUgU1BSSU5HIFdHLiBCYXNlZCBvbiB0aGUgdHdvIGRy YWZ0cywgdGhlIFdHIHNob3VsZCBtaWdodCBjb25zaWRlcjoNCg0KMSkgICAgICAgSXMgdGhlcmUg bmVlZCBmb3IgdGhpcyB3b3JrIGluIGRlcGxveW1lbnRzIGluIG5ldHdvcmtzLw0KDQoyKSAgICAg ICBJcyB0aGlzIHRlY2huaWNhbGx5IHJlYWR5IGZvciBwdWJsaWNhdGlvbj8NCg0KMykgICAgICAg RG9lcyBpdCBmaXQgd2l0aCB0aGUgc3ByaW5nIGluZm9ybWF0aW9uYWwgZHJhZnQ/DQoNCkZvciB0 aGUgZWFzZSBvZiByZWZlcmVuY2UgdGhlIHdlYiByZWZlcmVuY2VzIGFyZSBiZWxvdzoNCmh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaWRyLWJncGxzLXNlZ21lbnQt cm91dGluZy1lcGUvDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRm LXNwcmluZy1zZWdtZW50LXJvdXRpbmctY2VudHJhbC1lcGUvDQoNClN1ZSBIYXJlcw0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNwcmluZyBtYWlsaW5n IGxpc3QNCnNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmcNCg== --_000_B3307E1244314B2384C6A0BE9BA511AFalcatellucentcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MCAw IDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlz dFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7 bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDow Y207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6Q2FsaWJyaTsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uYXBwbGUtY29udmVydGVk LXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVt YWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3 Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0 IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoyMTI1NDA3NzY7DQoJbXNv LWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0yMDk0OTk0Njk0IDEz Njg5NjIwOTggNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2 OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC10 ZXh0OiIlMVwpIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgljb2xvcjpibGFjazt9DQpA bGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBs aXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZl bDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVs Nw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2Vy Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjEz ODgwNjMzNzM7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz OjE5ODAyNzU0NjggNjc2OTg3MDUgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMg Njc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJ e21zby1sZXZlbC10ZXh0OiIlMVwpIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlz dCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0 IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDUN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJv bWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwxOmxldmVsNw0K CXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0K QGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmln aHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVs DQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2Nv bG9yPSJ3aGl0ZSIgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SSByZWFkIHRoZSBwYXBlciBhbmQgWWVwIEkg c3VwcG9ydDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj5HLzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SWRyICZsdDtpZHItYm91bmNlc0BpZXRmLm9yZyZndDsg b24gYmVoYWxmIG9mIEplZmYgVGFudHN1cmEgJmx0O2plZmZ0YW50LmlldGZAZ21haWwuY29tJmd0 Ozxicj4NCjxiPkRhdGU6IDwvYj5UaHVyc2RheSwgMTYgRmVicnVhcnkgMjAxNyBhdCAxMjowNjxi cj4NCjxiPlRvOiA8L2I+U3VzYW4gSGFyZXMgJmx0O3NoYXJlc0BuZHpoLmNvbSZndDs8YnI+DQo8 Yj5DYzogPC9iPiZxdW90O2lkckBpZXRmLm9yZyZxdW90OyAmbHQ7aWRyQGlldGYub3JnJmd0Oywg JnF1b3Q7c3ByaW5nQGlldGYub3JnJnF1b3Q7ICZsdDtzcHJpbmdAaWV0Zi5vcmcmZ3Q7PGJyPg0K PGI+U3ViamVjdDogPC9iPltBTFVdIFJlOiBbSWRyXSBbc3ByaW5nXSBJRFIgV0cgMiB3ZWVrIFdH IExDIG9uZHJhZnQtaWV0Zi1pZHItYmdwbHMtc2VnbWVudC1yb3V0aW5nLWVwZSAtICgyLzE1LzIw MTcgdG8gMy8xLzIwMTcpPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5ZZXMvc3VwcG9ydDxicj4NCjxicj4NClJlZ2FyZHMsIDxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkplZmY8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiBGZWIgMTUsIDIwMTcsIGF0IDIzOjM0LCBTdXNhbiBI YXJlcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNoYXJlc0BuZHpoLmNvbSI+c2hhcmVzQG5kemguY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5UaGlzIGJlZ2lucyBh IDIgd2VlayBJRFIgV0cgbGFzdCBjYWxsIG9uIGRyYWZ0LWlldGYtaWRyLWJncGxzLXNlZ21lbnQt cm91dGluZy1lcGUgZnJvbSAoMi8xNSB0byAzLzEvMjAxNykgJm5ic3A7Jm5ic3A7Jm5ic3A7VGhl cmUgYXJlIHR3byBpbXBsZW1lbnRhdGlvbnMgZGVzY3JpYmUgb24gdGhlIHdpa2kgYXQ6DQo8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+PGEgaHJlZj0iaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvaWRyL3dp a2kvZHJhZnQtaWV0Zi1pZHItYmdwbHMtc2VnbWVudC1yb3V0aW5nLWVwZSUyMCI+aHR0cHM6Ly90 cmFjLmlldGYub3JnL3RyYWMvaWRyL3dpa2kvZHJhZnQtaWV0Zi1pZHItYmdwbHMtc2VnbWVudC1y b3V0aW5nLWVwZSUyMDwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQiPlRoZSB0d28gaW1wbGVtZW50YXRpb24gYXJlIGZyb20NCjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjaztiYWNrZ3JvdW5kOndoaXRl Ij4mbmJzcDtDaXNjbw0KPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2s7YmFj a2dyb3VuZDp3aGl0ZSI+SU9TLVhSIHJlbGVhc2UgNi4wLjIgYW5kIENpc2NvIE5leHVzIFN3aXRj aCBOOTAwMC9OMzAwMCBwbGF0Zm9ybXMgcnVubmluZyBOWC1PUyA3LjAoMylJMSgxKSBvciBncmVh dGVyLiZuYnNwOyZuYnNwOyBUaGUgYXV0aG9ycyB3aWxsIGluZGljYXRlIG9uIHRoZSBsaXN0IGFu ZCBpbiB0aGUgd2lraSB0aGUgZm9sbG93aW5nIGluZm9ybWF0aW9uIDo8L3NwYW4+PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Y29sb3I6YmxhY2s7YmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVu dDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEp PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwh W2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+V2VyZSB0aGVzZSBpbXBsZW1l bnRhdGlvbnMgc2VwYXJhdGUgaW1wbGVtZW50YXRpb25zPw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0 O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjIpPHNwYW4gc3R5 bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+V2hhdCB3ZXJlIHRoZSByZXN1bHRzIG9mIHRo ZSBpbnRlcm9wZXJhYmlsaXR5IHRlc3RzPw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij5UaGlzIHdvcmsgaXMgbGlua2VkIHRvIHRoZSBkcmFmdC1pZXRmLXNwcmlu Zy1zZWdtZW50LXJvdXRpbmctY2VudHJhbC1lcGUgd29yayBpbiB0aGUgU1BSSU5HIFdHLiBCYXNl ZCBvbiB0aGUgdHdvIGRyYWZ0cywgdGhlIFdHIHNob3VsZCBtaWdodCBjb25zaWRlcjogJm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwxIGxldmVsMSBsZm80Ij48IVtpZiAhc3Vw cG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4xKTxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdCI+SXMgdGhlcmUgbmVlZCBmb3IgdGhpcyB3b3JrIGluIGRlcGxveW1l bnRzIGluIG5ldHdvcmtzLw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwxIGxldmVs MSBsZm80Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3Jl Ij4yKTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwhW2Vu ZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+SXMgdGhpcyB0ZWNobmljYWxseSBy ZWFkeSBmb3IgcHVibGljYXRpb24/DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDEg bGV2ZWwxIGxmbzQiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJ Z25vcmUiPjMpPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+ PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Eb2VzIGl0IGZpdCB3aXRo IHRoZSBzcHJpbmcgaW5mb3JtYXRpb25hbCBkcmFmdD8NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdCI+Rm9yIHRoZSBlYXNlIG9mIHJlZmVyZW5jZSB0aGUgd2ViIHJl ZmVyZW5jZXMgYXJlIGJlbG93Og0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxhIGhyZWY9Imh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaWRyLWJncGxzLXNlZ21lbnQtcm91 dGluZy1lcGUvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWlk ci1iZ3Bscy1zZWdtZW50LXJvdXRpbmctZXBlLzwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PGEgaHJl Zj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zcHJpbmctc2Vn bWVudC1yb3V0aW5nLWNlbnRyYWwtZXBlLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLWNlbnRyYWwtZXBlLzwvYT48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlN1ZSBIYXJlcyA8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpzcHJpbmcgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0i bWFpbHRvOnNwcmluZ0BpZXRmLm9yZyI+c3ByaW5nQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_B3307E1244314B2384C6A0BE9BA511AFalcatellucentcom_-- From nobody Fri Feb 17 00:22: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 95C791293E4; Fri, 17 Feb 2017 00:22:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mw9F6oh7Jgt1; Fri, 17 Feb 2017 00:21:59 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5F26128B37; Fri, 17 Feb 2017 00:21:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13920; q=dns/txt; s=iport; t=1487319718; x=1488529318; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=bAIDS1ynbBtZN0BHanpBPwabHjbxGHUETryb0ADXZGQ=; b=MoW3pS73AOqZx0ZC+G8Lu5MvdT5NQUanQze5bkAwawn+5DmI0v2AQmZW dzC0vdJE+rSbuhnja+Q0d4K2rqYSXTLcwQJDmPLcKPEP2z2gxPXntNvcW NJk/1j02g9ivnga9saJBcE3zMHC2p9omOz8Iy7JF0RgPa34vJ5TR4rw/G I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BYAQBmsaZY/5JdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9iYYEJB41aohiFLIIMHwEMhSxKAoIWPxgBAgEBAQEBAQFiKIR?= =?us-ascii?q?xAgQBAStBCxACAQg7BAcnCxQRAgQBDQWJbA6yUiuLLQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBARgFhkyEb4o5BZwAAYZwiyiRCJMbAR84gQBRFT2EfIFIdYlegQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.35,171,1484006400"; d="scan'208,217";a="386806449" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Feb 2017 08:21:57 +0000 Received: from XCH-ALN-009.cisco.com (xch-aln-009.cisco.com [173.36.7.19]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v1H8Lvj5002834 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 17 Feb 2017 08:21:57 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-009.cisco.com (173.36.7.19) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 17 Feb 2017 02:21:57 -0600 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; Fri, 17 Feb 2017 02:21:57 -0600 From: "Bertrand Duvivier (bduvivie)" To: "Van De Velde, Gunter (Nokia - BE)" , "Susan Hares" Thread-Topic: [Idr] [ALU] Re: [spring] IDR WG 2 week WG LC ondraft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) Thread-Index: AQHSiPSg2Nylgmp+6EK0TuDohdN8LKFtUVGA Date: Fri, 17 Feb 2017 08:21:57 +0000 Message-ID: References: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> <1E319B28-BF06-4BEB-9D27-552530FC21EA@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.101.83] Content-Type: multipart/alternative; boundary="_000_D4CC701C752F0bduvivieciscocom_" MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" , "spring@ietf.org" Subject: Re: [Idr] [ALU] Re: [spring] IDR WG 2 week WG LC ondraft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 08:22:00 -0000 --_000_D4CC701C752F0bduvivieciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Fully support, yes. Best Regards Bertrand Duvivier On Feb 15, 2017, at 23:34, Susan Hares > wrote: This begins a 2 week IDR WG last call on draft-ietf-idr-bgpls-segment-routi= ng-epe from (2/15 to 3/1/2017) There are two implementations describe on= the wiki at: https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-segment-routing-ep= e%20 The two implementation are from Cisco IOS-XR release 6.0.2 and Cisco Nexus= Switch N9000/N3000 platforms running NX-OS 7.0(3)I1(1) or greater. The a= uthors will indicate on the list and in the wiki the following information = : 1) Were these implementations separate implementations? BD> YES 2) What were the results of the interoperability tests? BD > WORKING This work is linked to the draft-ietf-spring-segment-routing-central-epe wo= rk in the SPRING WG. Based on the two drafts, the WG should might consider: 1) Is there need for this work in deployments in networks/ 2) Is this technically ready for publication? 3) Does it fit with the spring informational draft? For the ease of reference the web references are below: https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/ https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-central-= epe/ Sue Hares _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_D4CC701C752F0bduvivieciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <6AD5ACBC425CC447ACE07A32D53BF0F2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Fully support, yes. 

Best Regards Bertrand Duvivier


On Feb 15, 2017, at 23:34, Susan Hares <shares@ndzh.com> wrote:

This begins a 2 wee= k IDR WG last call on draft-ietf-idr-bgpls-segment-routing-epe from (2/15 t= o 3/1/2017)    There are two implementations describe on the= wiki at:

ht= tps://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-segment-routing-epe%= 20

 <= /o:p>

The two implementat= ion are from  Cisco IOS-XR release 6= .0.2 and Cisco Nexus Switch N9000/N3000 platforms running NX-OS 7.0(3)I1(1)= or greater.   The authors will indicate on the list and in the w= iki the following information :

 

1)       Were th= ese implementations separate implementations?
BD> YES 

2)       What we= re the results of the interoperability tests?
BD > WORKING

 <= /o:p>

This work is linked= to the draft-ietf-spring-segment-routing-central-epe work in the SPRING WG= . Based on the two drafts, the WG should might consider:  =

1) &nb= sp;     Is there need = for this work in deployments in networks/

2) &nb= sp;     Is this techni= cally ready for publication?

3) &nb= sp;     Does it fit wi= th the spring informational draft?

 <= /o:p>

For the ease of ref= erence the web references are below:

https:/= /datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/

ht= tps://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-central-ep= e/

 <= /o:p>

Sue Hares

_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.o= rg/mailman/listinfo/spring

 --_000_D4CC701C752F0bduvivieciscocom_-- From nobody Fri Feb 17 00: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 58AF91295B3 for ; Fri, 17 Feb 2017 00:52:02 -0800 (PST) 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, 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 UV3pK49N4vIQ for ; Fri, 17 Feb 2017 00:52:01 -0800 (PST) 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 1E5F31293E4 for ; Fri, 17 Feb 2017 00:52:01 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=70.194.5.209; From: "Susan Hares" To: "'Jakob Heitz \(jheitz\)'" , References: <20170216182349.DE675B8151F@rfc-editor.org> <23f1de27c8b24920acc4fbd1e2114ce6@XCH-ALN-014.cisco.com> In-Reply-To: <23f1de27c8b24920acc4fbd1e2114ce6@XCH-ALN-014.cisco.com> Date: Fri, 17 Feb 2017 03:47:01 -0500 Message-ID: <06ff01d288fa$689c4900$39d4db00$@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: AQGvifW+m8yZV2TmdHwz5ACFThNAGgIif4AqoaHMwFA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] RFC 8092 on BGP Large Communities Attribute X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 08:52:02 -0000 Jakob, Job, Keyur, Ignas, and Nick: Congratulations! Thank you for all your hard work on Large communities! Sue Hares -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz (jheitz) Sent: Thursday, February 16, 2017 5:56 PM To: idr@ietf.org Subject: Re: [Idr] RFC 8092 on BGP Large Communities Attribute Thanks to all supporters, Jakob. > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of > rfc-editor@rfc-editor.org > Sent: Thursday, February 16, 2017 10:24 AM > To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org > Cc: drafts-update-ref@iana.org; idr@ietf.org; > rfc-editor@rfc-editor.org > Subject: [Idr] RFC 8092 on BGP Large Communities Attribute > > A new Request for Comments is now available in online RFC libraries. > > > RFC 8092 > > Title: BGP Large Communities Attribute > Author: J. Heitz, Ed., > J. Snijders, Ed., > K. Patel, > I. Bagdonas, > N. Hilliard > Status: Standards Track > Stream: IETF > Date: February 2017 > Mailbox: jheitz@cisco.com, > job@ntt.net, > keyur@arrcus.com, > ibagdona.ietf@gmail.com, > nick@inex.ie > Pages: 8 > Characters: 15979 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-idr-large-community-12.txt > > URL: https://www.rfc-editor.org/info/rfc8092 > > DOI: 10.17487/RFC8092 > > This document describes the BGP Large Communities attribute, an > extension to BGP-4. This attribute provides a mechanism to signal > opaque information within separate namespaces to aid in routing > management. The attribute is suitable for use with all Autonomous > System Numbers (ASNs) including four-octet ASNs. > > 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 > > > _______________________________________________ > 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 From nobody Fri Feb 17 06:27: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 B8D51129A9A; Fri, 17 Feb 2017 06:27:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXLsKSiSW7tV; Fri, 17 Feb 2017 06:27:49 -0800 (PST) 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 A2FD5129443; Fri, 17 Feb 2017 06:27:48 -0800 (PST) Received: by mail-wr0-x235.google.com with SMTP id i10so30868930wrb.0; Fri, 17 Feb 2017 06:27:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ioVwQBWaOVtAhxQJ+OG6JlRAU6xyUEUzjMbC3mQ+8Ss=; b=j9EDf5Ae7RIMWxLt0QQLLAdhyVEb4m8UpuCrKFMr7HtgqWa/wfYxyMM0sMUmz6M/3l msgJq36PO+MOiKUs/m9Ueeu0gNq9ODvIXmwgC9Asv1i5hUEDqLAgzus4iEWwgjmEbHe5 6deKyP1BRCgqzZxxcIbysbKf6ZGx9g701t057juWVK+k8pdkl0H+UcKIlIGqwoZwx2+5 oP0e6L0UpXydEEQWwQZQZqSVuM00etDQKdaXFRxw4K2OXZmE0uK6D1MeQEuvGzGoirr5 o2fojmXLnC0ZILo4cA40XLZLbfYOYROqyoUkwcJnPeyfCRKmDvW3bO8o/JJZzb2/ST+6 y+EQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ioVwQBWaOVtAhxQJ+OG6JlRAU6xyUEUzjMbC3mQ+8Ss=; b=uCk8BTLrKXrLbImKn/Y6wDPeQM5IAVvXlh2PbjhwQ9x3yfGPamaQ3cGhBaR35IrdcF rlse65Hwthn2bNRpwWawRgcSStPrze7vSZ1tbuEJ4eUjlH6k9bVXy7b9/fisNhJnygN4 E2EtVt1uaRErcGKZoO4dVrbLzINmIOr4IW/ntWl2lXdRJ8EaeOVwTWX5C5BQ7axT0lVg U80XK4CWpqMRPnJHgYFcIXveEM+bWLabkbwSPer0EjTxozhyxoWgnEQRBD0uLJPDdptQ GBtXQylogMT0/gU0NpirU/l41OO56x+nL5roQaKOXyATyB6T28OF8B5huyp7xDIqgAWE K1Pg== X-Gm-Message-State: AMke39lYWs8f3/J4mJhhWwdDX3wD3D+0onf/fWd8inLFaI4LLt7CM8rKYvyKvGIV/pKrcA== X-Received: by 10.223.177.134 with SMTP id q6mr6601154wra.83.1487341666984; Fri, 17 Feb 2017 06:27:46 -0800 (PST) Received: from ams-giheron-nitro3.cisco.com ([173.38.220.39]) by smtp.gmail.com with ESMTPSA id k142sm1887664wmg.31.2017.02.17.06.27.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Feb 2017 06:27:46 -0800 (PST) From: Giles Heron Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_6243CB72-F4C1-4B7C-9543-2AE3D54858CD" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Fri, 17 Feb 2017 14:27:44 +0000 In-Reply-To: To: "Bertrand Duvivier (bduvivie)" References: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> <1E319B28-BF06-4BEB-9D27-552530FC21EA@gmail.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "idr@ietf.org" , "spring@ietf.org" , Susan Hares , "Van De Velde, Gunter \(Nokia - BE\)" Subject: Re: [Idr] [spring] [ALU] Re: IDR WG 2 week WG LC ondraft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 14:27:51 -0000 --Apple-Mail=_6243CB72-F4C1-4B7C-9543-2AE3D54858CD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Likewise. And it=E2=80=99s worth noting that OpenDaylight has an open-source = implementation of the draft, and interops ok with IOS XR. I may get = around to testing interop with NX-OS also. Giles > On 17 Feb 2017, at 08:21, Bertrand Duvivier (bduvivie) = wrote: >=20 > Fully support, yes.=20 >=20 > Best Regards Bertrand Duvivier >=20 >=20 > On Feb 15, 2017, at 23:34, Susan Hares > wrote: >=20 >> This begins a 2 week IDR WG last call on = draft-ietf-idr-bgpls-segment-routing-epe from (2/15 to 3/1/2017) = There are two implementations describe on the wiki at: >> = https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-segment-routing-e= pe%20 = >> =20 >> The two implementation are from Cisco IOS-XR release 6.0.2 and Cisco = Nexus Switch N9000/N3000 platforms running NX-OS 7.0(3)I1(1) or greater. = The authors will indicate on the list and in the wiki the following = information : >> =20 >> 1) Were these implementations separate implementations? >=20 > BD> YES=20 >> 2) What were the results of the interoperability tests? >=20 > BD > WORKING >> =20 >> This work is linked to the = draft-ietf-spring-segment-routing-central-epe work in the SPRING WG. = Based on the two drafts, the WG should might consider: =20 >> 1) Is there need for this work in deployments in networks/ >> 2) Is this technically ready for publication? >> 3) Does it fit with the spring informational draft? >> =20 >> For the ease of reference the web references are below: >> = https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/= = >> = https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-central= -epe/ = >> =20 >> Sue Hares=20 >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring = ____________________________= ___________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring = --Apple-Mail=_6243CB72-F4C1-4B7C-9543-2AE3D54858CD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Likewise.

And it=E2=80=99s worth noting that OpenDaylight has an = open-source implementation of the draft, and interops ok with IOS XR. =  I may get around to testing interop with NX-OS also.

Giles

On 17 Feb 2017, at 08:21, = Bertrand Duvivier (bduvivie) <bduvivie@cisco.com> wrote:

Fully = support, yes. 

Best Regards Bertrand Duvivier


On = Feb 15, 2017, at 23:34, Susan Hares <shares@ndzh.com> wrote:

This = begins a 2 week IDR WG last call on = draft-ietf-idr-bgpls-segment-routing-epe from (2/15 to 3/1/2017) =    There are two implementations describe on the wiki = at:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-segmen= t-routing-epe%20
 
The two implementation are = from  Cisco IOS-XR release 6.0.2 and = Cisco Nexus Switch N9000/N3000 platforms running NX-OS 7.0(3)I1(1) or = greater.   The authors will indicate on the list and in the = wiki the following information :
 
1)       Were these implementations = separate = implementations?
<= span style=3D"font-family: Calibri, sans-serif; font-size: 14px; = font-style: normal; font-variant-caps: normal; font-weight: normal; = letter-spacing: normal; orphans: auto; text-align: start; text-indent: = 0px; text-transform: none; white-space: normal; widows: auto; = word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: = inline !important;" class=3D"">
BD> YES 
2)       What were the results of the = interoperability = tests?
BD > WORKING
 
This work is linked to the = draft-ietf-spring-segment-routing-central-epe work in the SPRING WG. = Based on the two drafts, the WG should might consider:  
1)       Is there need for this work in = deployments in networks/
2)       Is this technically ready for = publication?
3)       Does it fit with the spring = informational draft?
 
For the ease of reference the web = references are below:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-r= outing-epe/
https://datatracker.ietf.org/doc/draft-ietf-spring-segment-rout= ing-central-epe/
 
Sue Hares 
_______________________________________________spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
= _______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

= --Apple-Mail=_6243CB72-F4C1-4B7C-9543-2AE3D54858CD-- From nobody Mon Feb 20 16:05: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 CC10C129415; Mon, 20 Feb 2017 16:05:49 -0800 (PST) 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 K25WuMO4_sdZ; Mon, 20 Feb 2017 16:05:48 -0800 (PST) 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 2ECB112943B; Mon, 20 Feb 2017 16:05:47 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.164.147; From: "Susan Hares" To: "'Giles Heron'" , "'Bertrand Duvivier \(bduvivie\)'" References: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> <1E319B28-BF06-4BEB-9D27-552530FC21EA@gmail.com> In-Reply-To: Date: Mon, 20 Feb 2017 19:01:27 -0500 Message-ID: <017001d28bd5$a6c85f10$f4591d30$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0171_01D28BAB.BDF404C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJT2wOnmfqsL5/KzR2EzWLnKupfBQFcWVRrAi7YyF4ChPeZ0gMNybK2oCcFdmA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: idr@ietf.org, spring@ietf.org, "'Van De Velde, Gunter \(Nokia - BE\)'" Subject: Re: [Idr] [spring] [ALU] Re: IDR WG 2 week WG LC ondraft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 00:05:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0171_01D28BAB.BDF404C0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Giles:=20 =20 It would be helpful to fill out the wiki on the =E2=80=9CSHOULD, MAY and = MUSTs=E2=80=9D. If it is easier, you can just send me the answers and = I will post it.=20 =20 Sue=20 =20 From: Giles Heron [mailto:giles.heron@gmail.com]=20 Sent: Friday, February 17, 2017 9:28 AM To: Bertrand Duvivier (bduvivie) Cc: Van De Velde, Gunter (Nokia - BE); Susan Hares; idr@ietf.org; = spring@ietf.org Subject: Re: [spring] [Idr] [ALU] Re: IDR WG 2 week WG LC = ondraft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) =20 Likewise. =20 And it=E2=80=99s worth noting that OpenDaylight has an open-source = implementation of the draft, and interops ok with IOS XR. I may get = around to testing interop with NX-OS also. =20 Giles =20 On 17 Feb 2017, at 08:21, Bertrand Duvivier (bduvivie) = wrote: =20 Fully support, yes.=20 =20 Best Regards Bertrand Duvivier =20 On Feb 15, 2017, at 23:34, Susan Hares < = shares@ndzh.com> wrote: This begins a 2 week IDR WG last call on = draft-ietf-idr-bgpls-segment-routing-epe from (2/15 to 3/1/2017) = There are two implementations describe on the wiki at: = = https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-segment-routing-= epe%20 =20 The two implementation are from Cisco IOS-XR release 6.0.2 and Cisco = Nexus Switch N9000/N3000 platforms running NX-OS 7.0(3)I1(1) or greater. = The authors will indicate on the list and in the wiki the following = information : =20 1) Were these implementations separate implementations? BD> YES=20 2) What were the results of the interoperability tests? BD > WORKING =20 This work is linked to the draft-ietf-spring-segment-routing-central-epe = work in the SPRING WG. Based on the two drafts, the WG should might = consider: =20 1) Is there need for this work in deployments in networks/ 2) Is this technically ready for publication? 3) Does it fit with the spring informational draft? =20 For the ease of reference the web references are below: = = https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe= / = = https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-centra= l-epe/ =20 Sue Hares=20 _______________________________________________ spring mailing list spring@ietf.org = https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list spring@ietf.org = https://www.ietf.org/mailman/listinfo/spring =20 ------=_NextPart_000_0171_01D28BAB.BDF404C0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Giles:

 

It would be helpful to fill out the wiki on the =E2=80=9CSHOULD, MAY = and MUSTs=E2=80=9D.=C2=A0=C2=A0 If it is easier, you can just send me = the answers and I will post it.

 

Sue

 

From:= = Giles Heron [mailto:giles.heron@gmail.com]
Sent: Friday, = February 17, 2017 9:28 AM
To: Bertrand Duvivier = (bduvivie)
Cc: Van De Velde, Gunter (Nokia - BE); Susan Hares; = idr@ietf.org; spring@ietf.org
Subject: Re: [spring] [Idr] = [ALU] Re: IDR WG 2 week WG LC ondraft-ietf-idr-bgpls-segment-routing-epe = - (2/15/2017 to 3/1/2017)

 

Likewise.

 

And it=E2=80=99s worth noting that OpenDaylight has an = open-source implementation of the draft, and interops ok with IOS XR. =  I may get around to testing interop with NX-OS = also.

 

Giles

 

On 17 Feb 2017, at 08:21, Bertrand Duvivier (bduvivie) = <bduvivie@cisco.com> = wrote:

 

Fully = support, yes. 

 =

Best = Regards Bertrand Duvivier

 =


On Feb = 15, 2017, at 23:34, Susan Hares <shares@ndzh.com> = wrote:

This begins a 2 week IDR WG = last call on draft-ietf-idr-bgpls-segment-routing-epe from (2/15 to = 3/1/2017)    There are two implementations describe on = the wiki at:=

 =

The two implementation are = from  Cisco IOS-XR release 6.0.2 and Cisco Nexus Switch = N9000/N3000 platforms running NX-OS 7.0(3)I1(1) or greater.   = The authors will indicate on the list and in the wiki the following = information :=

 =

1)       Were these implementations = separate implementations?=

BD> = YES 

2)       What were the results of = the interoperability tests?=

BD > = WORKING

 =

This work is linked to the = draft-ietf-spring-segment-routing-central-epe work in the SPRING WG. = Based on the two drafts, the WG should might consider: =  =

1)       Is there need for this work = in deployments in networks/=

2)       Is this technically ready = for publication?=

3)       Does it fit with the spring = informational draft?=

 =

For the ease of reference = the web references are below:=

 =

Sue Hares =

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

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

<= /div>

 

------=_NextPart_000_0171_01D28BAB.BDF404C0-- From nobody Tue Feb 21 07:32: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 EF3EF129C1A for ; Tue, 21 Feb 2017 07:32:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=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, 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 aAcaI_yWsN6y for ; Tue, 21 Feb 2017 07:32:13 -0800 (PST) Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 687D4129409 for ; Tue, 21 Feb 2017 07:32:13 -0800 (PST) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id D0CDC120512 for ; Tue, 21 Feb 2017 16:32:11 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id B1B91180040 for ; Tue, 21 Feb 2017 16:32:11 +0100 (CET) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM5D.corporate.adroot.infra.ftgroup ([fe80::9898:741c:bc1d:258d%19]) with mapi id 14.03.0319.002; Tue, 21 Feb 2017 16:32:11 +0100 From: To: "idr@ietf.org" Thread-Topic: WG Last Call for draft-ietf-spring-segment-routing-msdc-02 Thread-Index: AdKMJ4Hwg4mKj2LrQwW7nmbydnVyPgAIdd6g Date: Tue, 21 Feb 2017 15:32:11 +0000 Message-ID: <29463_1487691131_58AC5D7B_29463_447_1_53C29892C857584299CBF5D05346208A1ED71E6A@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <27991_1487670653_58AC0D7D_27991_2292_1_53C29892C857584299CBF5D05346208A1ED7122E@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <27991_1487670653_58AC0D7D_27991_2292_1_53C29892C857584299CBF5D05346208A1ED7122E@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.3] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A1ED71E6AOPEXCLILM21corp_" MIME-Version: 1.0 Archived-At: Subject: [Idr] FW: WG Last Call for draft-ietf-spring-segment-routing-msdc-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 15:32:15 -0000 --_000_53C29892C857584299CBF5D05346208A1ED71E6AOPEXCLILM21corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, FYI, the SPRING WG has just initiated a WG last call on draft-ietf-spring-s= egment-routing-msdc-02. That document is related to the following IDR document: draft-ietf-idr-bgp-= prefix-sid. Comments and review are more than welcomed, on the _SPRING_ mailing list. Thanks, Regards, -- Bruno From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Tuesday, February 21, 2017 10:51 AM To: spring@ietf.org Subject: [spring] WG Last Call for draft-ietf-spring-segment-routing-msdc-02 Hello Working Group, This email starts a 2-week Working Group Last Call on draft-ietf-spring-seg= ment-routing-msdc-02 [1]. Please read the document if you haven't read the most recent version yet, a= nd send your comments to the list, no later than the *7th of March*. Note that this is *not only* a call for comments on the document; it is als= o a call for support (or not) to publish this document as an Informational = RFC. We have already polled for IPR knowledge on this document and all Authors h= ave replied. No IPR has been disclosed [2]. Thank you M&B [1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-msdc-02 [2] https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraft-ietf= -spring-segment-routing-msdc ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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. --_000_53C29892C857584299CBF5D05346208A1ED71E6AOPEXCLILM21corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

FYI, th= e SPRING WG has just initiated a WG last call on draft-ietf-spring-segment-= routing-msdc-02.

That do= cument is related to the following IDR document: draft-ietf-idr-bgp-prefix-= sid.

&n= bsp;

Comment= s and review are more than welcomed, on the _SPRING_ mailing list.

&n= bsp;

Thanks,=

Regards= ,

-- Brun= o

&n= bsp;

&n= bsp;

From:<= /b> spring [mailto:spring-bounces@ietf.= org] On Behalf Of bruno.decraene@orange.com
Sent: Tuesday, February 21, 2017 10:51 AM
To: spring@ietf.org
Subject: [spring] WG Last Call for draft-ietf-spring-segment-routing= -msdc-02

 

Hello Working Group,

 

This email starts a 2-week W= orking Group Last Call on draft-ietf-spring-segment-routing-msdc-02 [1].

 

Please read the document if = you haven't read the most recent version yet, and send your comments to the= list, no later than the *7th of March*.

Note that this is *not only*= a call for comments on the document; it is also a call for support (or not= ) to publish this document as an Informational RFC.

 

We have already polled for I= PR knowledge on this document and all Authors have replied.

No IPR has been disclosed [2= ].

 

Thank you<= /p>

 

M&B

 

[1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-msdc-02

[2] https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraft-ietf= -spring-segment-routing-msdc

 

 

 

 

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
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.
______________________________________________________________________=
___________________________________________________

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.
--_000_53C29892C857584299CBF5D05346208A1ED71E6AOPEXCLILM21corp_-- From nobody Tue Feb 21 10:46: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 78590129C3A for ; Tue, 21 Feb 2017 10:46:02 -0800 (PST) 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 5oLYFxPgkaeZ for ; Tue, 21 Feb 2017 10:46:01 -0800 (PST) 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 35F13129C6E for ; Tue, 21 Feb 2017 10:46:01 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.9.51; From: "Susan Hares" To: Date: Tue, 21 Feb 2017 13:41:28 -0500 Message-ID: <00a901d28c72$1dba3a70$592eaf50$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AA_01D28C48.34E48090" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdKMceb+tcnatgNgTpy4nKexMAmXNw== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: "'Clarence Filsfils \(cfilsfil\)'" , 'Keyur Patel' , 'Saikat Ray' , bruno.decraene@orange.com, 'Hannes Gredler' Subject: [Idr] draft-ietf-idr-bgp-prefix-sid-04 - IPR call X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 18:46:02 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00AA_01D28C48.34E48090 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Stefano, Clarence, Acee, Keyur, Hannes, and Saikat: Please indicate whether you know of any IPR for draft-ietf-bgp-prefix-sid-04.txt. After we have all of your IPR calls, we will begin the WG LC for this document. Sue Hares ------=_NextPart_000_00AA_01D28C48.34E48090 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stefano, = Clarence, Acee, Keyur, Hannes, and Saikat:

 

Please = indicate whether you know of any IPR for = draft-ietf-bgp-prefix-sid-04.txt.   After we have all of your = IPR calls, we will begin the WG LC for this document.

 

Sue Hares =

------=_NextPart_000_00AA_01D28C48.34E48090-- From nobody Tue Feb 21 10:48: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 49267129C3A for ; Tue, 21 Feb 2017 10:48:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 LCSbVxxgdEZY for ; Tue, 21 Feb 2017 10:48:28 -0800 (PST) Received: from kangchenjunga.rtbrick.net (kangchenjunga.rtbrick.com [217.160.181.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB744129C44 for ; Tue, 21 Feb 2017 10:48:27 -0800 (PST) Received: from hannes-mba.local (80-121-37-157.adsl.highway.telekom.at [::ffff:80.121.37.157]) (AUTH: LOGIN hannes, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by kangchenjunga.rtbrick.net with ESMTPSA; Tue, 21 Feb 2017 19:48:24 +0100 id 000000002873A01C.0000000058AC8B78.000042CF Received: from hannes-mba.local (localhost [127.0.0.1]) by hannes-mba.local (Postfix) with ESMTP id 9B1F7255CDCD; Tue, 21 Feb 2017 19:48:22 +0100 (CET) To: Susan Hares , idr@ietf.org References: <00a901d28c72$1dba3a70$592eaf50$@ndzh.com> From: Hannes Gredler Message-ID: <566e485f-6cf3-f618-ec66-32aee45073b8@rtbrick.com> Date: Tue, 21 Feb 2017 19:48:22 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <00a901d28c72$1dba3a70$592eaf50$@ndzh.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "'Clarence Filsfils \(cfilsfil\)'" , 'Keyur Patel' , 'Saikat Ray' , bruno.decraene@orange.com Subject: Re: [Idr] draft-ietf-idr-bgp-prefix-sid-04 - IPR call X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 18:48:29 -0000 hi sue, i am not aware of any IPR. /hannes On 2/21/17 19:41, Susan Hares wrote: > > Stefano, Clarence, Acee, Keyur, Hannes, and Saikat: > > > > Please indicate whether you know of any IPR for > draft-ietf-bgp-prefix-sid-04.txt. After we have all of your IPR > calls, we will begin the WG LC for this document. > > > > Sue Hares > From nobody Tue Feb 21 10:49: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 B7251129C70 for ; Tue, 21 Feb 2017 10:49:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 kqb_IjEREV29 for ; Tue, 21 Feb 2017 10:49:37 -0800 (PST) Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::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 4832C129C6A for ; Tue, 21 Feb 2017 10:49:37 -0800 (PST) Received: by mail-ot0-x229.google.com with SMTP id x10so55286018otb.1 for ; Tue, 21 Feb 2017 10:49:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=b0tV/dZBAUz3fpxC/W0BnHKhR7HETs0Anmb0tVpXCuI=; b=YaDJnUEe3M9iH8g5/fyzXWa91HirSd72gIIABBL6Y7PRFxzi2E+1ulgM1NTl9Vo/mt Nf0zSTyJdf3O68JHaDCcGlKPXZscmQyCW1+keINdP5LD7Mcm8GigeT0yAaem0x9rqkMf aMzWndSYtpfsJk9CFFUOx8xz3YLITLGUYTBq4dsPVJhrgX+5hJaizZj2+3dbzPQVwUTD GBfSTyshBaDFzhW8DM5zxRDDSP/AaWy36VQzmsa6xUqEahm5YNfwtIPxFxEUIB5hSjV+ QK9kr1CNNI0BwP69gtdLxfCFc99U+ZHAyL1dkzENlESnACHrFkBPkyrvBzPVIlkLi7zg +5nw== 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=b0tV/dZBAUz3fpxC/W0BnHKhR7HETs0Anmb0tVpXCuI=; b=lHO3EN48MkhzHzp3tvryE31bIpXRgu0Vfc4hPKf4tiBx+eB4Mpfx+sTARSHptNJfVA gbtlbs0QNqeux9syLK8xskTrySOWsb155p/L90tDb/rISzeFgCGEgEmoUycuYcZcBil6 SmaGLvwoyZehjp0AWxlAgjPL9A/BTfv+bd2wy+gJF5u6v4Ozyh0Ts391aihIqBJ0bqa/ mZV3ClRLuTnGoLL35rGTJMj41zF8eIh3HV4L7pJ1/18LhW66a4Te/DMN9udyjoJUoFjX hVGoKJDsUKlUPUjsuTatXXAR1x/2jgWOH7ZEiXL5dmY5/KlqV9SSMpGLXDG04ZYHEd0c 6bAQ== X-Gm-Message-State: AMke39ncVEFWvp5vUnn2vRh20h4hAIAM2wU7HC1xSYBdE9/Ofit2RnQPre37Qwx2WYraV4QrqqRx/r7lhslbKg== X-Received: by 10.157.36.107 with SMTP id p98mr10972271ota.96.1487702976641; Tue, 21 Feb 2017 10:49:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.152.36 with HTTP; Tue, 21 Feb 2017 10:49:36 -0800 (PST) In-Reply-To: <566e485f-6cf3-f618-ec66-32aee45073b8@rtbrick.com> References: <00a901d28c72$1dba3a70$592eaf50$@ndzh.com> <566e485f-6cf3-f618-ec66-32aee45073b8@rtbrick.com> From: Saikat Ray Date: Tue, 21 Feb 2017 10:49:36 -0800 Message-ID: To: Hannes Gredler Content-Type: multipart/alternative; boundary=001a113cf5ec74425405490ed770 Archived-At: Cc: idr@ietf.org, "Clarence Filsfils \(cfilsfil\)" , Keyur Patel , Bruno Decraene , Susan Hares Subject: Re: [Idr] draft-ietf-idr-bgp-prefix-sid-04 - IPR call X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 18:49:39 -0000 --001a113cf5ec74425405490ed770 Content-Type: text/plain; charset=UTF-8 Neither am I. On Tue, Feb 21, 2017 at 10:48 AM, Hannes Gredler wrote: > hi sue, > > > i am not aware of any IPR. > > > /hannes > > > On 2/21/17 19:41, Susan Hares wrote: > > > > Stefano, Clarence, Acee, Keyur, Hannes, and Saikat: > > > > > > > > Please indicate whether you know of any IPR for > > draft-ietf-bgp-prefix-sid-04.txt. After we have all of your IPR > > calls, we will begin the WG LC for this document. > > > > > > > > Sue Hares > > > > -- Saikat Ray Web: http://raysaikat.googlepages.com --001a113cf5ec74425405490ed770 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Neither am I.

On Tue, Feb 21, 2017 at 10:48 AM, Hannes Gredler <hann= es@rtbrick.com> wrote:
hi s= ue,


i am not aware of any IPR.


/hannes


On 2/21/17 19:41, Susan Hares wrote:
>
> Stefano, Clarence, Acee, Keyur, Hannes, and Saikat:
>
>
>
> Please indicate whether you know of any IPR for
> draft-ietf-bgp-prefix-sid-04.txt.=C2=A0 =C2=A0After we have all o= f your IPR
> calls, we will begin the WG LC for this document.
>
>
>
> Sue Hares
>




--
=
Saikat Ra= y
Web: ht= tp://raysaikat.googlepages.com
--001a113cf5ec74425405490ed770-- From nobody Tue Feb 21 10:49: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 AD66F1296D1 for ; Tue, 21 Feb 2017 10:49:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.986 X-Spam-Level: X-Spam-Status: No, score=-3.986 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, RCVD_IN_MSPIKE_H2=-1.887, RCVD_IN_SORBS_SPAM=0.5, 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=netorgft1331857.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 vQFhZ3zynRRu for ; Tue, 21 Feb 2017 10:49:49 -0800 (PST) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) (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 87E3A1294B4 for ; Tue, 21 Feb 2017 10:49:48 -0800 (PST) Received: from pure.maildistiller.com (unknown [10.110.50.29]) by dispatch1-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTP id 03D1C8008E; Tue, 21 Feb 2017 18:49:48 +0000 (UTC) X-Virus-Scanned: Proofpoint Essentials engine Received: from mx7-us1.ppe-hosted.com (unknown [10.110.49.251]) by pure.maildistiller.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 8BDC780052; Tue, 21 Feb 2017 18:49:47 +0000 (UTC) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02lp0052.outbound.protection.outlook.com [207.46.163.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx7-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 6087254006B; Tue, 21 Feb 2017 18:49:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector1-arrcus-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=omBT1BmojzOk32nezQIAgvzvWWGmeLq0UDRVfIAgIOw=; b=KCP5kk9Iio6AUjgM8/U6J55tOxjQsRLvyAiX9VfcMjJswCezAD7SvcUkN65YRC9Een/c2KqagOlx67IcmsNmNhz80p2o8QvE5Sra0rRLVLFlESXiu9rpqSSkwahg7zP9cCBUE3cbtA3L0PsPN0bM+bCeNn/7SlbnIikV7wK03EU= Received: from BY2PR18MB0262.namprd18.prod.outlook.com (10.163.72.152) by BY2PR18MB0264.namprd18.prod.outlook.com (10.163.72.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.13; Tue, 21 Feb 2017 18:49:36 +0000 Received: from BY2PR18MB0262.namprd18.prod.outlook.com ([10.163.72.152]) by BY2PR18MB0262.namprd18.prod.outlook.com ([10.163.72.152]) with mapi id 15.01.0919.018; Tue, 21 Feb 2017 18:49:36 +0000 From: Keyur Patel To: Susan Hares , "idr@ietf.org" Thread-Topic: draft-ietf-idr-bgp-prefix-sid-04 - IPR call Thread-Index: AdKMceb+tcnatgNgTpy4nKexMAmXN///fJIA Date: Tue, 21 Feb 2017 18:49:36 +0000 Message-ID: References: <00a901d28c72$1dba3a70$592eaf50$@ndzh.com> In-Reply-To: <00a901d28c72$1dba3a70$592eaf50$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=keyur@arrcus.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [96.68.143.133] x-ms-office365-filtering-correlation-id: 2f14208b-156b-4397-ab87-08d45a8a625d x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BY2PR18MB0264; x-microsoft-exchange-diagnostics: 1; BY2PR18MB0264; 7:huDLtezodA3mAm+KuseSoyYe1Yyaj8uLOFh23SUhHE5QClR2CczuKjMXqTCJCjqljAkA/1jFH189I3gMWsXj1FLGke7qfKGYaxJIqkZ7GaBfzzKbHrk5S7GCc/s88ywCoI440mRLu+T8Colvazdzxgo4qtMiS9E4JpPYIFuqmh2dsc04RnLN7xs+6SMCJzqls+Ensuzi6QKfqXaJgeKS7qaV+TGvjFjucMBboG3Wmtc1PkgLgoRowONB4mhMuuV3KU5bTY5GptuLKHkbiNidH2gJrY4jBHY2D2/5w/DcHb7wo55g6k20/beYdJpDUSSJ0oPgQALlvyk7ynM/YO3JeQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014)(18271650672692)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123560025)(20161123558025)(20161123564025)(20161123562025)(20161123555025)(2016111802025)(6043046)(6072148); SRVR:BY2PR18MB0264; BCL:0; PCL:0; RULEID:; SRVR:BY2PR18MB0264; x-forefront-prvs: 0225B0D5BC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39410400002)(39830400002)(39450400003)(189002)(377454003)(199003)(4326007)(53936002)(3280700002)(3660700001)(77096006)(2950100002)(92566002)(6486002)(38730400002)(6246003)(6436002)(229853002)(2501003)(83716003)(2906002)(189998001)(5660300001)(6506006)(6116002)(122556002)(82746002)(102836003)(3846002)(86362001)(7736002)(8676002)(101416001)(50986999)(97736004)(8936002)(68736007)(36756003)(81156014)(54356999)(9326002)(53546006)(39060400002)(54896002)(33656002)(54906002)(230783001)(6306002)(81166006)(99286003)(25786008)(6512007)(2900100001)(105586002)(106356001)(76176999)(66066001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR18MB0264; H:BY2PR18MB0262.namprd18.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: arrcus.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_EE0E4858552C4A4CACA07F4C05985AAAarrcuscom_" MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Feb 2017 18:49:36.6893 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR18MB0264 X-MDID: 1487702988-hEAJ2JEsRFvg Archived-At: Cc: "'Clarence Filsfils \(cfilsfil\)'" , 'Saikat Ray' , "bruno.decraene@orange.com" , 'Hannes Gredler' Subject: Re: [Idr] draft-ietf-idr-bgp-prefix-sid-04 - IPR call X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 18:49:50 -0000 --_000_EE0E4858552C4A4CACA07F4C05985AAAarrcuscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU3VlLA0KDQpJIGFtIG5vdCBhd2FyZSBvZiBhbnkgSVBSLg0KDQpSZWdhcmRzLA0KS2V5dXIN Cg0KRnJvbTogU3VzYW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbT4NCkRhdGU6IFR1ZXNkYXksIEZl YnJ1YXJ5IDIxLCAyMDE3IGF0IDEwOjQxIEFNDQpUbzogImlkckBpZXRmLm9yZyIgPGlkckBpZXRm Lm9yZz4NCkNjOiAiJ1N0ZWZhbm8gUHJldmlkaSAoc3ByZXZpZGkpJyIgPHNwcmV2aWRpQGNpc2Nv LmNvbT4sICInQ2xhcmVuY2UgRmlsc2ZpbHMgKGNmaWxzZmlsKSciIDxjZmlsc2ZpbEBjaXNjby5j b20+LCAiJ0FjZWUgTGluZGVtIChhY2VlKSciIDxhY2VlQGNpc2NvLmNvbT4sIEtleXVyIFBhdGVs IDxrZXl1ckBhcnJjdXMuY29tPiwgJ0hhbm5lcyBHcmVkbGVyJyA8aGFubmVzQHJ0YnJpY2suY29t PiwgJ1NhaWthdCBSYXknIDxyYXlzYWlrYXRAZ21haWwuY29tPiwgImJydW5vLmRlY3JhZW5lQG9y YW5nZS5jb20iIDxicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPg0KU3ViamVjdDogZHJhZnQtaWV0 Zi1pZHItYmdwLXByZWZpeC1zaWQtMDQgLSBJUFIgY2FsbA0KDQpTdGVmYW5vLCBDbGFyZW5jZSwg QWNlZSwgS2V5dXIsIEhhbm5lcywgYW5kIFNhaWthdDoNCg0KUGxlYXNlIGluZGljYXRlIHdoZXRo ZXIgeW91IGtub3cgb2YgYW55IElQUiBmb3IgZHJhZnQtaWV0Zi1iZ3AtcHJlZml4LXNpZC0wNC50 eHQuICAgQWZ0ZXIgd2UgaGF2ZSBhbGwgb2YgeW91ciBJUFIgY2FsbHMsIHdlIHdpbGwgYmVnaW4g dGhlIFdHIExDIGZvciB0aGlzIGRvY3VtZW50Lg0KDQpTdWUgSGFyZXMNCg== --_000_EE0E4858552C4A4CACA07F4C05985AAAarrcuscom_ 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 CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1h aWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OkNhbGli cmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNv LXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFs O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3 aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIFN1ZSw8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSBhbSBub3QgYXdhcmUgb2YgYW55IElQUi48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPktl eXVyPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPlN1c2FuIEhhcmVzICZsdDtzaGFyZXNAbmR6aC5jb20mZ3Q7PGJyPg0KPGI+ RGF0ZTogPC9iPlR1ZXNkYXksIEZlYnJ1YXJ5IDIxLCAyMDE3IGF0IDEwOjQxIEFNPGJyPg0KPGI+ VG86IDwvYj4mcXVvdDtpZHJAaWV0Zi5vcmcmcXVvdDsgJmx0O2lkckBpZXRmLm9yZyZndDs8YnI+ DQo8Yj5DYzogPC9iPiZxdW90OydTdGVmYW5vIFByZXZpZGkgKHNwcmV2aWRpKScmcXVvdDsgJmx0 O3NwcmV2aWRpQGNpc2NvLmNvbSZndDssICZxdW90OydDbGFyZW5jZSBGaWxzZmlscyAoY2ZpbHNm aWwpJyZxdW90OyAmbHQ7Y2ZpbHNmaWxAY2lzY28uY29tJmd0OywgJnF1b3Q7J0FjZWUgTGluZGVt IChhY2VlKScmcXVvdDsgJmx0O2FjZWVAY2lzY28uY29tJmd0OywgS2V5dXIgUGF0ZWwgJmx0O2tl eXVyQGFycmN1cy5jb20mZ3Q7LCAnSGFubmVzIEdyZWRsZXInICZsdDtoYW5uZXNAcnRicmljay5j b20mZ3Q7LCAnU2Fpa2F0IFJheScgJmx0O3JheXNhaWthdEBnbWFpbC5jb20mZ3Q7LA0KICZxdW90 O2JydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20mcXVvdDsgJmx0O2JydW5vLmRlY3JhZW5lQG9yYW5n ZS5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPmRyYWZ0LWlldGYtaWRyLWJncC1wcmVmaXgt c2lkLTA0IC0gSVBSIGNhbGwgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Nv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlN0ZWZhbm8sIENsYXJlbmNlLCBBY2VlLCBLZXl1ciwgSGFubmVzLCBhbmQg U2Fpa2F0OiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGxlYXNlIGluZGljYXRlIHdoZXRoZXIg eW91IGtub3cgb2YgYW55IElQUiBmb3IgZHJhZnQtaWV0Zi1iZ3AtcHJlZml4LXNpZC0wNC50eHQu Jm5ic3A7Jm5ic3A7IEFmdGVyIHdlIGhhdmUgYWxsIG9mIHlvdXIgSVBSIGNhbGxzLCB3ZSB3aWxs IGJlZ2luIHRoZSBXRyBMQyBmb3IgdGhpcyBkb2N1bWVudC4NCjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5TdWUgSGFyZXMgPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_EE0E4858552C4A4CACA07F4C05985AAAarrcuscom_-- From nobody Tue Feb 21 10:53: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 34A18129C76 for ; Tue, 21 Feb 2017 10:53:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LoKhJ6QePcVN for ; Tue, 21 Feb 2017 10:53:52 -0800 (PST) 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 ED3DF1294B4 for ; Tue, 21 Feb 2017 10:53:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=552; q=dns/txt; s=iport; t=1487703231; x=1488912831; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=JnFKmIthO5HVzgpyoWYuRAgGuiwQguGHKqxIIGtEpNc=; b=RejQoueQYJZfLySwON/OYshZax012WLF/Xhfiyc/nCzzBNJoKRUqtr7R X2qclFHKWcKX6aX6PvWUVIowCkxMlooQh3s4vsDheZStSvuSjNoo/wB38 s28suAovi0AGCTEwYAo1+OZWDFQ/mdz88zT96xwncUwfEBHzLtPAluwQH w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CNAQCXjKxY/4oNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1GBageDVIoIkXcflTSCDYYiAhqCVj8YAQIBAQEBAQEBYiiEcAE?= =?us-ascii?q?BAQMBIxFFBQsCAQgOCgICJgICAjAVEAEBBA4FiWYIrmiCJos9AQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBHYELhUGCBQiCYoRUgwYugjEBBJwLAZIegWMBF4UciXiTJAE?= =?us-ascii?q?fOIEAUxVPAYQ4HYFhdYktgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.35,190,1484006400"; d="scan'208";a="200880923" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Feb 2017 18:53:25 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v1LIrPYU008287 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 21 Feb 2017 18:53:25 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 21 Feb 2017 13:53:24 -0500 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Tue, 21 Feb 2017 13:53:24 -0500 From: "Stefano Previdi (sprevidi)" To: Susan Hares Thread-Topic: draft-ietf-idr-bgp-prefix-sid-04 - IPR call Thread-Index: AdKMceb+tcnatgNgTpy4nKexMAmXNwAK8fwA Date: Tue, 21 Feb 2017 18:53:24 +0000 Message-ID: References: <00a901d28c72$1dba3a70$592eaf50$@ndzh.com> In-Reply-To: <00a901d28c72$1dba3a70$592eaf50$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.254.26] Content-Type: text/plain; charset="utf-8" Content-ID: <6528F70C533C814E9630AD7A439E38C9@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: idr wg , "Clarence Filsfils \(cfilsfil\)" , Keyur Patel , Saikat Ray , "bruno.decraene@orange.com" , Hannes Gredler Subject: Re: [Idr] draft-ietf-idr-bgp-prefix-sid-04 - IPR call X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 18:53:53 -0000 SeKAmW0gbm90IGF3YXJlIG9mIGFueSBJUFIgb3RoZXIgdGhhbiB0aGUgb25lcyBhbHJlYWR5IGRp c2Nsb3NlZC4NCg0Kcy4NCg0KDQo+IE9uIEZlYiAyMSwgMjAxNywgYXQgNzo0MSBQTSwgU3VzYW4g SGFyZXMgPHNoYXJlc0BuZHpoLmNvbT4gd3JvdGU6DQo+IA0KPiBTdGVmYW5vLCBDbGFyZW5jZSwg QWNlZSwgS2V5dXIsIEhhbm5lcywgYW5kIFNhaWthdDogDQo+ICANCj4gUGxlYXNlIGluZGljYXRl IHdoZXRoZXIgeW91IGtub3cgb2YgYW55IElQUiBmb3IgZHJhZnQtaWV0Zi1iZ3AtcHJlZml4LXNp ZC0wNC50eHQuICAgQWZ0ZXIgd2UgaGF2ZSBhbGwgb2YgeW91ciBJUFIgY2FsbHMsIHdlIHdpbGwg YmVnaW4gdGhlIFdHIExDIGZvciB0aGlzIGRvY3VtZW50LiANCj4gIA0KPiBTdWUgSGFyZXMgDQoN Cg== From nobody Tue Feb 21 10:58: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 184AC129564 for ; Tue, 21 Feb 2017 10:58:48 -0800 (PST) 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, 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 h7bwOET0aNEC for ; Tue, 21 Feb 2017 10:58:47 -0800 (PST) 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 418581294B4 for ; Tue, 21 Feb 2017 10:58:47 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=70.194.9.51; From: "Susan Hares" To: "'Stefano Previdi \(sprevidi\)'" References: <00a901d28c72$1dba3a70$592eaf50$@ndzh.com> In-Reply-To: Date: Tue, 21 Feb 2017 13:54:14 -0500 Message-ID: <00e701d28c73$e61a59e0$b24f0da0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLRmZ897QD/Rst3CoPQS8v4sIhJ4QJCScJyn2OiGRA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'idr wg' , "'Clarence Filsfils \(cfilsfil\)'" , 'Keyur Patel' , 'Saikat Ray' , bruno.decraene@orange.com, 'Hannes Gredler' Subject: Re: [Idr] draft-ietf-idr-bgp-prefix-sid-04 - IPR call X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 18:58:48 -0000 Wow that was quick. We still need Acee and Clarence. If we get these = today, I will start the IPR call.=20 Sue=20 -----Original Message----- From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]=20 Sent: Tuesday, February 21, 2017 1:53 PM To: Susan Hares Cc: idr wg; Clarence Filsfils (cfilsfil); Acee Lindem (acee); Keyur = Patel; Hannes Gredler; Saikat Ray; bruno.decraene@orange.com Subject: Re: draft-ietf-idr-bgp-prefix-sid-04 - IPR call=20 I=E2=80=99m not aware of any IPR other than the ones already disclosed. s. > On Feb 21, 2017, at 7:41 PM, Susan Hares wrote: >=20 > Stefano, Clarence, Acee, Keyur, Hannes, and Saikat:=20 > =20 > Please indicate whether you know of any IPR for = draft-ietf-bgp-prefix-sid-04.txt. After we have all of your IPR calls, = we will begin the WG LC for this document.=20 > =20 > Sue Hares=20 From nobody Tue Feb 21 11:05: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 A1E771294F3 for ; Tue, 21 Feb 2017 11:05:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlm09QlnIoLx for ; Tue, 21 Feb 2017 11:05:34 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F5DF127076 for ; Tue, 21 Feb 2017 11:05:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5436; q=dns/txt; s=iport; t=1487703934; x=1488913534; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=EuqPaU6Gbz3+2foNz1XA7gYaWTzj4+cLcX9YxkN5WwE=; b=lC3/Dgqfnsvk3TLhfUXY8ts1ibScvDyCpS+cDAwY3FtpaBpJIUVvgxw/ twY/DzbQOuUgZrGDDhoHa5+jXIP7rm53MEoy4FnsIQYuOcY6gXH570oik 7nHjX2ewUr5eSF2Ab0c84Iae7aYFEX9KZFBzMb9GGrBNGRrjvTp1ZcW6r M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AjAQALjqxY/5BdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9iYYEJB41ckhaIDId8hSyCDYYiAoJwPxgBAgEBAQEBAQFiKIR?= =?us-ascii?q?wAQEBBC1MEAIBCA4DAwECKAchERQJCAEBBAENBYlWAxWxEIc5DYN3AQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBHYs7glGCI4VFBZVihW86AY4DhBuBe4UciXiKQohiAR8?= =?us-ascii?q?4gQBTFT6ESh2BYXWJLYENAQEB?= X-IronPort-AV: E=Sophos;i="5.35,190,1484006400"; d="scan'208,217";a="388522077" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Feb 2017 19:05:33 +0000 Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v1LJ5XFB012480 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 21 Feb 2017 19:05:33 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 21 Feb 2017 14:05:32 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Tue, 21 Feb 2017 14:05:32 -0500 From: "Acee Lindem (acee)" To: Susan Hares , "idr@ietf.org" Thread-Topic: draft-ietf-idr-bgp-prefix-sid-04 - IPR call Thread-Index: AdKMceb+tcnatgNgTpy4nKexMAmXNwAA44OA Date: Tue, 21 Feb 2017 19:05:32 +0000 Message-ID: References: <00a901d28c72$1dba3a70$592eaf50$@ndzh.com> In-Reply-To: <00a901d28c72$1dba3a70$592eaf50$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: multipart/alternative; boundary="_000_D4D1F9959D87Caceeciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Clarence Filsfils \(cfilsfil\)" , 'Keyur Patel' , 'Saikat Ray' , "bruno.decraene@orange.com" , 'Hannes Gredler' Subject: Re: [Idr] draft-ietf-idr-bgp-prefix-sid-04 - IPR call X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 19:05:35 -0000 --_000_D4D1F9959D87Caceeciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am not aware of any IPR. Thanks, Acee From: Susan Hares > Date: Tuesday, February 21, 2017 at 1:41 PM To: IDR List > Cc: "Stefano Previdi (sprevidi)" >, "Clarence Filsfils (cfilsfil)" >, Acee Lindem >, Keyur Pate= l >, 'Hannes Gredler' >, Saikat Ray >, Bruno Decraene > Subject: draft-ietf-idr-bgp-prefix-sid-04 - IPR call Stefano, Clarence, Acee, Keyur, Hannes, and Saikat: Please indicate whether you know of any IPR for draft-ietf-bgp-prefix-sid-0= 4.txt. After we have all of your IPR calls, we will begin the WG LC for t= his document. Sue Hares --_000_D4D1F9959D87Caceeciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <637FA9A53C2E3C49873A9DAD426781E1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
I am not aware of any IPR. 
Thanks,
Acee

From: Susan Hares <shares@ndzh.com>
Date: Tuesday, February 21, 2017 at= 1:41 PM
To: IDR List <idr@ietf.org>
Cc: "Stefano Previdi (sprevidi= )" <sprevidi@cisco.com>= ;, "Clarence Filsfils (cfilsfil)" <cfilsfil@cisco.com>, Acee Lindem <acee@cisco.com>, Keyur Patel <keyur@arrcus.com&g= t;, 'Hannes Gredler' <hannes@rtbri= ck.com>, Saikat Ray <raysa= ikat@gmail.com>, Bruno Decraene <bruno.decraene@orange.com>
Subject: draft-ietf-idr-bgp-prefix-= sid-04 - IPR call

Stefano, Clarence, Acee, Keyur, Hannes, and Saikat: =

 

Please indicate whether you know of any IPR for draf= t-ietf-bgp-prefix-sid-04.txt.   After we have all of your IPR cal= ls, we will begin the WG LC for this document.

 

Sue Hares

--_000_D4D1F9959D87Caceeciscocom_-- From nobody Tue Feb 21 14:31: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 1EC47129D5E; Tue, 21 Feb 2017 14:31:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: David Black To: X-Test-IDTracker: no X-IETF-IDTracker: 6.45.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148771630812.19122.17152051080250251501.idtracker@ietfa.amsl.com> Date: Tue, 21 Feb 2017 14:31:48 -0800 Archived-At: Cc: idr@ietf.org, draft-ietf-idr-sla-exchange.all@ietf.org, ietf@ietf.org Subject: [Idr] Review of draft-ietf-idr-sla-exchange-10 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 22:31:48 -0000 Reviewer: David Black Review result: Not Ready I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. When done at the time of IETF Last Call, the authors should consider this review together with any other last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. Document: draft-ietf-idr-sla-10 Reviewer: David Black Review Date: February 21, 2017 Review result: Not Ready This is an early TSV-ART review of a working group draft, requested by the IDR Working Group. This draft defines an extension to BGP to allow exchange of traffic handling parameters (e.g., configured rates, burst sizes, drop thresholds). While this is a useful area of technology to standardize across network operators, this draft has significant problems, and parts of it could use some serious rethought. This reviewer has discussed small portions of this draft with some of the authors in the past, but this is his first comprehensive reading and review of the draft. Major Issues: [1] The draft is misnamed. This is not an SLA (Service Level Agreement) draft - it's a TCA (Traffic Conditioning Agreement) draft - see the definition of TCA in RFC 2475. This draft should start from that definition and generalize the applicability of TCA beyond Diffserv. Large areas of SLA content are not covered by this draft - for more details, see the Wikipedia article on SLA: https://en.wikipedia.org/wiki/Service-level_agreement . [2] Section 3.3.2.1's reuse of the TSpec construct from RFC 2115 to specify a token bucket is a good idea, but it's not a good idea to respecify that construct in terms of L2 (link-layer, e.g., Ethernet) octets, as the RFC 2115 TSpec is specified in terms of IP octets. This change to specification in terms of L2 octets results in needing the L2_OVERHEAD TLV to cope with the possible differences in L2 (link) framing overhead at sender and receiver of this information. The TSpec should be respecified at the IP layer, with L2 framing overhead left to the Producer and Consumer to factor into their calculations based on each's direct knowledge of L2 functionality and configuration in the local AS. That ought to enable elimination of the L2_OVERHEAD TLV, thereby reducing complexity. [3] A token bucket should have two rate-related marking parameters based on its token fill rate, i.e., min-rate, not the four rate-related marking parameters in this draft. The max-rate parameters in sections 3.3.2.5-6 ought to be specified against a second token bucket. In addition, the handling precedence algorithm in section 3.3.2.7 is an overly complex way to specify the relationship of two token buckets. All of this is even more important, because max-rate, as defined in RFC 2115, is only applicable to bursting - that max-rate for bursting often turns out to be an interface line rate, which is not generally useful for the traffic provisioning purposes of this draft. The following should be done instead: - Define TSpecs for two token buckets, a primary/committed token bucket and a secondary/peak token bucket that MUST be nested, i.e., traffic that is in-profile for the secondary/peak token bucket is always in-profile for the primary/committed token bucket. Some of the details of how to specify this are subtle, see RFC 2698 for a worked example. Use of a secondary/peak token bucket requires use of the primary/ committed token bucket, but a primary/committed token bucket can be used without a secondary/peak token bucket. - For a single token bucket, define two handling TLVs, Committed (in profile) and Excess (out of profile). - For two token buckets, define three handling TLVs, Committed (in profile for both token buckets), Peak (out of profile for primary/committed token bucket, but in profile for secondary/peak token bucket) and Excess (out of profile for both token buckets). NB: Could use Green/Yellow/Red terms instead of Committed/Peak/Excess terms. [4] The drop threshold TLV in section 3.3.2.8 is not specified sufficiently to be implemented interoperably. For example, I don't understand what an implementation is supposed to do when it receives 3 drop thresholds. [5] The relative priority TLV in section 3.3.2.9 has the same insufficient specification problem as the drop threshold TLV, compounded by a functional incompleteness problem - if the recipient is using a weighted packet transmission scheduler (e.g., WRR), priorities cannot be used to configure that scheduler. Hence, some specification of weights and scheduling algorithms that use weights needs to be added. [6] I have no idea what the sub-traffic classes TLV in section 3.3.2.10 is supposed to do, as that TLV is specified based on "Traffic Class TLVs" which is an undefined term in this draft (e.g., that term is not used outside of section 3.3.2.10. [7] This draft's QoS contents need to be functionally aligned with work-in-progress on YANG QoS models, in order to provide some assurance that that this draft is implementable for actual network switch/router data paths. The current acknowledgement of the existence of YANG, NETCONF and RESTConf at the end of Section 1 does not suffice. [8] There are significant complexity and correctness problems caused by the option to not specify the Source AS - e.g., Section 3.2 defines an SLA ID as an "identifier which is unique in the scope of Source AS" which is meaningless if there is no Source AS. It would be simpler to always specify Source AS, even in the point-to-point case. [9] In section 3.2, the "intended for the peer receiver of the BGP UPDATE message" text in the specification of bit 0 of the SLA Subtype flags is unclear. I suspect that this is intended to differentiate the two usages described in sections 4.1.1 (Point-to-Point) and 4.1.2 (Multiple Hops), in which case the parenthesized terms (or similar terminology) should be used with cross-references to those two sections. [10] There needs to be a coherent discussion in one place about how SLA advertisement, update and withdrawal work. A single ADVERTISE method may suffice on the wire, but the details on how initial advertisement, subsequent advertisement (update) and withdrawal work need to be specified in one place. The third paragraph of Section 4 is a start on this material, but it's too terse; it should be expanded into its own subsection, and moved earlier to come before the ADVERTISE method in Section 3.2. This text from Section 3.2 should be moved into that new subsection and likewise expanded: If an advertised SLA ID is different from earlier advertised one, for the same prefix and from the same Source AS, indicates Source AS is advertising new SLA Content to replace the previous one advertised with the same SLA ID. In addition, I wonder whether functionality should be added to allow withdrawal of an advertisement by specifying its SLA ID, although that was not part of the original design. [11] Notions of context for interpretation of all the IPFIX parameters in 3.3.1 need to be added, e.g.: - The first three parameters (DSCP, MPLS EXP field in top label, 802.1q priority) can and do vary on a link-by-link or LSP-by-LSP basis along a traffic's network path. - The IP address parameters are rather likely to be VPN-specific when there's more than one BGP/MPLS VPN that spans or transits the ASs involved. - The transport port parameters need specification of which transport header and where it is located (e.g., for TCP traffic carried by in VXLAN, is this the inner TCP header or the outer UDP header in VXLAN). There are probably simple approaches to specifying context in all cases, but that context does need to be specified ... in all cases. [12] The security considerations (section 10) are severely incomplete and insufficient: - Discussion of possible abuse of this BGP option for denial-of-service and theft-of-service, needs to be added, including possible countermeasures and mitigations. - This sentence at the end of the second paragraph in Section 10 is content-free: It is NOT RECOMMENDED to enable this attribute at the scale of the Internet unless if means to prevent leaking sensitive information are enforced. What exactly is an implementer or admin supposed to do? How does one figure out whether an implementation or deployment is "at the scale of the Internet" ?? - The next to last paragraph in section 10 is almost content-free, as it leaves decisions on implementation and deployment of key security functionality as "an exercise for the reader" - that's not acceptable. - Last, but not least, the final paragraph in Section 10 is a joke that will be lost on a security directorate reviewer - to understand why, see Section 2 of RFC 6919, and take note of the publication date of RFC 6919. ------------------------ Having noted a dozen major issues, I'll end the review here for now, as I believe a serious revision of the draft is called for, which would be a better starting point to review for minor issues and editorial items. -------------------------------------------------------- David L. Black, Distinguished Engineer Dell EMC, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 Cell: +1 (978) 394-7754 David.Black@dell.com <=== NEW === -------------------------------------------------------- From nobody Wed Feb 22 00:18: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 AD901129444 for ; Wed, 22 Feb 2017 00:18:05 -0800 (PST) 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 u_H3UdVE-514 for ; Wed, 22 Feb 2017 00:18:04 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39BE71293DF for ; Wed, 22 Feb 2017 00:18:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=552; q=dns/txt; s=iport; t=1487751484; x=1488961084; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=LD4bGwemJUEbOqocg6wW0HQeuvNFm/LCjHLG3Kc5dpU=; b=Wr0j7ossYHazljs8zaJTWvIkQCnDsrNDJn2YM5+Nvxy9gVkhygE6lA5K GT98zAhoZKRSszG9xgkT75SyphktxRn61rrTudhmo/++U9Up+MtyK7Gk/ 4hUVtjP74yoDfU5N+tRITZwSIN4wiMRxAcSdDKR8WZpyH7NU2IW2LOJQm c=; X-IronPort-AV: E=Sophos;i="5.35,193,1484006400"; d="scan'208";a="650895738" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Feb 2017 08:18:02 +0000 Received: from [10.61.251.77] ([10.61.251.77]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v1M8I16u030147; Wed, 22 Feb 2017 08:18:02 GMT To: "Stefano Previdi (sprevidi)" , Susan Hares References: <00a901d28c72$1dba3a70$592eaf50$@ndzh.com> From: Clarence Filsfils Message-ID: <58AD493A.4010300@cisco.com> Date: Wed, 22 Feb 2017 09:18:02 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: idr wg , Keyur Patel , Saikat Ray , "bruno.decraene@orange.com" , Hannes Gredler Subject: Re: [Idr] draft-ietf-idr-bgp-prefix-sid-04 - IPR call X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 08:18:05 -0000 I’m not aware of any IPR other than the ones already disclosed. Cheers, Clarence On 21-Feb-17 19:53, Stefano Previdi (sprevidi) wrote: > I’m not aware of any IPR other than the ones already disclosed. > > s. > > >> On Feb 21, 2017, at 7:41 PM, Susan Hares wrote: >> >> Stefano, Clarence, Acee, Keyur, Hannes, and Saikat: >> >> Please indicate whether you know of any IPR for draft-ietf-bgp-prefix-sid-04.txt. After we have all of your IPR calls, we will begin the WG LC for this document. >> >> Sue Hares > From nobody Wed Feb 22 05:38: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 C94191298AA; Wed, 22 Feb 2017 05:38:32 -0800 (PST) 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 u-l6z4NU_WF3; Wed, 22 Feb 2017 05:38:30 -0800 (PST) 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 7734B129895; Wed, 22 Feb 2017 05:38:30 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.124.243.128; From: "Susan Hares" To: "'David Black'" , References: <148771630812.19122.17152051080250251501.idtracker@ietfa.amsl.com> In-Reply-To: <148771630812.19122.17152051080250251501.idtracker@ietfa.amsl.com> Date: Wed, 22 Feb 2017 08:34:08 -0500 Message-ID: <00bc01d28d10$58be37e0$0a3aa7a0$@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: AQKDUuAoPuK0lQdnfnc2fTnq9qa/26ATetSg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: idr@ietf.org, draft-ietf-idr-sla-exchange.all@ietf.org, ietf@ietf.org Subject: Re: [Idr] Review of draft-ietf-idr-sla-exchange-10 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 13:38:33 -0000 David: Thank you for the review. The authors will respond to you on these issues. Sue -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of David Black Sent: Tuesday, February 21, 2017 5:32 PM To: tsv-art@ietf.org Cc: idr@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; ietf@ietf.org Subject: [Idr] Review of draft-ietf-idr-sla-exchange-10 Reviewer: David Black Review result: Not Ready I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. When done at the time of IETF Last Call, the authors should consider this review together with any other last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. Document: draft-ietf-idr-sla-10 Reviewer: David Black Review Date: February 21, 2017 Review result: Not Ready This is an early TSV-ART review of a working group draft, requested by the IDR Working Group. This draft defines an extension to BGP to allow exchange of traffic handling parameters (e.g., configured rates, burst sizes, drop thresholds). While this is a useful area of technology to standardize across network operators, this draft has significant problems, and parts of it could use some serious rethought. This reviewer has discussed small portions of this draft with some of the authors in the past, but this is his first comprehensive reading and review of the draft. Major Issues: [1] The draft is misnamed. This is not an SLA (Service Level Agreement) draft - it's a TCA (Traffic Conditioning Agreement) draft - see the definition of TCA in RFC 2475. This draft should start from that definition and generalize the applicability of TCA beyond Diffserv. Large areas of SLA content are not covered by this draft - for more details, see the Wikipedia article on SLA: https://en.wikipedia.org/wiki/Service-level_agreement . [2] Section 3.3.2.1's reuse of the TSpec construct from RFC 2115 to specify a token bucket is a good idea, but it's not a good idea to respecify that construct in terms of L2 (link-layer, e.g., Ethernet) octets, as the RFC 2115 TSpec is specified in terms of IP octets. This change to specification in terms of L2 octets results in needing the L2_OVERHEAD TLV to cope with the possible differences in L2 (link) framing overhead at sender and receiver of this information. The TSpec should be respecified at the IP layer, with L2 framing overhead left to the Producer and Consumer to factor into their calculations based on each's direct knowledge of L2 functionality and configuration in the local AS. That ought to enable elimination of the L2_OVERHEAD TLV, thereby reducing complexity. [3] A token bucket should have two rate-related marking parameters based on its token fill rate, i.e., min-rate, not the four rate-related marking parameters in this draft. The max-rate parameters in sections 3.3.2.5-6 ought to be specified against a second token bucket. In addition, the handling precedence algorithm in section 3.3.2.7 is an overly complex way to specify the relationship of two token buckets. All of this is even more important, because max-rate, as defined in RFC 2115, is only applicable to bursting - that max-rate for bursting often turns out to be an interface line rate, which is not generally useful for the traffic provisioning purposes of this draft. The following should be done instead: - Define TSpecs for two token buckets, a primary/committed token bucket and a secondary/peak token bucket that MUST be nested, i.e., traffic that is in-profile for the secondary/peak token bucket is always in-profile for the primary/committed token bucket. Some of the details of how to specify this are subtle, see RFC 2698 for a worked example. Use of a secondary/peak token bucket requires use of the primary/ committed token bucket, but a primary/committed token bucket can be used without a secondary/peak token bucket. - For a single token bucket, define two handling TLVs, Committed (in profile) and Excess (out of profile). - For two token buckets, define three handling TLVs, Committed (in profile for both token buckets), Peak (out of profile for primary/committed token bucket, but in profile for secondary/peak token bucket) and Excess (out of profile for both token buckets). NB: Could use Green/Yellow/Red terms instead of Committed/Peak/Excess terms. [4] The drop threshold TLV in section 3.3.2.8 is not specified sufficiently to be implemented interoperably. For example, I don't understand what an implementation is supposed to do when it receives 3 drop thresholds. [5] The relative priority TLV in section 3.3.2.9 has the same insufficient specification problem as the drop threshold TLV, compounded by a functional incompleteness problem - if the recipient is using a weighted packet transmission scheduler (e.g., WRR), priorities cannot be used to configure that scheduler. Hence, some specification of weights and scheduling algorithms that use weights needs to be added. [6] I have no idea what the sub-traffic classes TLV in section 3.3.2.10 is supposed to do, as that TLV is specified based on "Traffic Class TLVs" which is an undefined term in this draft (e.g., that term is not used outside of section 3.3.2.10. [7] This draft's QoS contents need to be functionally aligned with work-in-progress on YANG QoS models, in order to provide some assurance that that this draft is implementable for actual network switch/router data paths. The current acknowledgement of the existence of YANG, NETCONF and RESTConf at the end of Section 1 does not suffice. [8] There are significant complexity and correctness problems caused by the option to not specify the Source AS - e.g., Section 3.2 defines an SLA ID as an "identifier which is unique in the scope of Source AS" which is meaningless if there is no Source AS. It would be simpler to always specify Source AS, even in the point-to-point case. [9] In section 3.2, the "intended for the peer receiver of the BGP UPDATE message" text in the specification of bit 0 of the SLA Subtype flags is unclear. I suspect that this is intended to differentiate the two usages described in sections 4.1.1 (Point-to-Point) and 4.1.2 (Multiple Hops), in which case the parenthesized terms (or similar terminology) should be used with cross-references to those two sections. [10] There needs to be a coherent discussion in one place about how SLA advertisement, update and withdrawal work. A single ADVERTISE method may suffice on the wire, but the details on how initial advertisement, subsequent advertisement (update) and withdrawal work need to be specified in one place. The third paragraph of Section 4 is a start on this material, but it's too terse; it should be expanded into its own subsection, and moved earlier to come before the ADVERTISE method in Section 3.2. This text from Section 3.2 should be moved into that new subsection and likewise expanded: If an advertised SLA ID is different from earlier advertised one, for the same prefix and from the same Source AS, indicates Source AS is advertising new SLA Content to replace the previous one advertised with the same SLA ID. In addition, I wonder whether functionality should be added to allow withdrawal of an advertisement by specifying its SLA ID, although that was not part of the original design. [11] Notions of context for interpretation of all the IPFIX parameters in 3.3.1 need to be added, e.g.: - The first three parameters (DSCP, MPLS EXP field in top label, 802.1q priority) can and do vary on a link-by-link or LSP-by-LSP basis along a traffic's network path. - The IP address parameters are rather likely to be VPN-specific when there's more than one BGP/MPLS VPN that spans or transits the ASs involved. - The transport port parameters need specification of which transport header and where it is located (e.g., for TCP traffic carried by in VXLAN, is this the inner TCP header or the outer UDP header in VXLAN). There are probably simple approaches to specifying context in all cases, but that context does need to be specified ... in all cases. [12] The security considerations (section 10) are severely incomplete and insufficient: - Discussion of possible abuse of this BGP option for denial-of-service and theft-of-service, needs to be added, including possible countermeasures and mitigations. - This sentence at the end of the second paragraph in Section 10 is content-free: It is NOT RECOMMENDED to enable this attribute at the scale of the Internet unless if means to prevent leaking sensitive information are enforced. What exactly is an implementer or admin supposed to do? How does one figure out whether an implementation or deployment is "at the scale of the Internet" ?? - The next to last paragraph in section 10 is almost content-free, as it leaves decisions on implementation and deployment of key security functionality as "an exercise for the reader" - that's not acceptable. - Last, but not least, the final paragraph in Section 10 is a joke that will be lost on a security directorate reviewer - to understand why, see Section 2 of RFC 6919, and take note of the publication date of RFC 6919. ------------------------ Having noted a dozen major issues, I'll end the review here for now, as I believe a serious revision of the draft is called for, which would be a better starting point to review for minor issues and editorial items. -------------------------------------------------------- David L. Black, Distinguished Engineer Dell EMC, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 Cell: +1 (978) 394-7754 David.Black@dell.com <=== NEW === -------------------------------------------------------- _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Wed Feb 22 13:24: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 047DD129B79 for ; Wed, 22 Feb 2017 13:24:12 -0800 (PST) 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_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=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UaBkE1CFtkiU for ; Wed, 22 Feb 2017 13:24:11 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0096.outbound.protection.outlook.com [104.47.34.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A2E6129B78 for ; Wed, 22 Feb 2017 13:24:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XMY449wKARYIv5CnZQFbb9h7nqRciTZDhsHtfi3EfK4=; b=LXA3nwSZKTPnHYn3gxLSgJ+pXa0ke6vJwQGPAaz0PMcnATIZvQ+75hlOttVsUI+5UDq72Jhob/2JrnnPf8VfVnOYQArzsVGbRAAdo/aHBePMhM51df9c7BQuQYCu6Bn9QB7lhmfFhYTg30QIEm/YDjvIB+5jeib53x9sUyXhK28= 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.101.237] (66.129.239.15) by CY1PR05MB2507.namprd05.prod.outlook.com (10.167.10.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.7; Wed, 22 Feb 2017 21:24:09 +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: <4ADCDBDD-934C-4EE6-8069-CB8A60B39A66@juniper.net> Date: Wed, 22 Feb 2017 16:24:03 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <51907C40-32CC-45A5-A426-12C781929E79@juniper.net> References: <36E285C0-C716-437A-806D-A453273146DD@juniper.net> <4ADCDBDD-934C-4EE6-8069-CB8A60B39A66@juniper.net> To: X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.239.15] X-ClientProxiedBy: BY1PR13CA0042.namprd13.prod.outlook.com (10.162.107.180) To CY1PR05MB2507.namprd05.prod.outlook.com (10.167.10.134) X-MS-Office365-Filtering-Correlation-Id: 1bf9f121-df78-4778-5e54-08d45b692427 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR05MB2507; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 3:Y/X/afSS0ZLzhvXmYpqWkVQIQAe+b4rprry1EU/pXq21i/NJwFfqTY4BflZyxR5iOCbRNYzUml8i6GrCCjFiS9XtJ/U8FKtUh3f/Yp8mOwvCsXeWLix1KkO3U0nnr5uuG7riQSJvng5yu08KjbIzXQK01XR2MtUjkm7aG6QFlge4bON3pg9n/H8HqOMqY6ijRzTNnJl/X8FfIipyMLmvRb3b73608pDyaBUNPHLRYOnZ4c9sUDTVLLuTFcQ2kM5ZZ6Z0AXnH5sL2jyY/o6Lz1fw1UGnabBQwbse5A4oL51s=; 25:FmZveSsiNva/d/1SmJpDogXQzlRvuXDCDmroODGxol4t/0lMwo3VJTiCLxZCsQQP38J7LaB8vBxOA8foj69Due9RKxrU5rGeBlJv5Y+YusQkicuEVp2SgR3gDVEKPh9gYkb3iZ4AY5e5+farPv5vyLd2NZrNGagIDOba2XLwEgkkBa2kaqDc+A1Xkh1JovZlufs3vI2pt88yoJLNxZ51E/NvH6NzSyViOfTNDsFOiEomWSBXZbExOVSQ26+52d3JMBlJVpu2vCoUbPWi59YXsU6aHUq57F/ia8IczCYQh7nvXKd4eJZNs64H1XTadWA+2UetzOI+lAbVks0E/nYSvag6xeK+0oMVvF5oVXat7xqghuEHgFVQU9m+stHZtu0cRE0ELHZ4Jr3ZLwrmpQ3d8Gjm+TkaGRP13OXbfdvHhXpYwC/bk+c4W8E3+yMR5jrU4i7eDeV7Yk/m5PP0KpCR4Q== X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 31:Cod48o5DgnhMwuizvk0nX+jhp91djmssd3BF142X8GkM5PZU2GMYTr6we6z5svdLOornDKEBrV3rL5XBB2f8UJzdQyKz3HRpyn3Se/gFSskhwE/sfa3JRA5t2GOYy8IPuICpUqGe+wBlr7WSJS4NvtMct5uxo4iVvXgcVpw0NPq6bSSFCYOyaliXifE8lEzuqMpk43LqsIY1t52p8+hU9J/aut7/IBnIAuHsh0ZpA9QZaauRRMPieuvUqEcP1fCZV2Wvp8j5dPNy45p8bA/QBw==; 20:FatGumVs/QayX9g0AWyNA98xjC81QMAw2k6pNhqOXP6MXZxRgQSQQqhMiQKmesjNHEu639K2E3kFTgmMl08MGjVgulpkt1VE2hB7sKrK+4WxytLPzuawdfIUO/aqh3MVKi0H3mwRJ/+l1zRz78mO1IImoLBy1o1ARC8B+PwOazgkPAQSQE8I/F8UeKmPUM/E8JauhvjINHaSrDwOMk8RS0BAGwdOn7uxjATockgrJhpe5mzXls5a5AQBfu4FJfP0WS/oE7BAY4zg41zvWD3LBfNqUlWW5mc6PdLB8mYpKSw/U6TUIq6MqhS/3XdtKLp1hU5Pk0VhZYs+OZ8wnPHanV0/NhsiHpGJ1z2frNmhUVX6s6RsEMECqwBjWih4UHaWsHKjw3mEJeU74JywIWJ5q7WRb3ltpreemBiqMbJFN5wXD2hhkPSnVM0uIC+LAt+QuP7udfASaGNpr2TJhRqplDpCDL1WXA6VwzoUkEMCeO4Elt82WtTokotbLqxUr2nN X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008)(100405760836317); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123558025)(20161123564025)(20161123562025)(20161123555025)(6072148); SRVR:CY1PR05MB2507; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2507; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 4:oZTASf35dNvBUPb2VeAu1X7PRXCFuZvd31w5Yb1MfazwGdaY0v6w47JsAVHllB5JYPspI+LSoG0Jpy6QwlHcaYc0dvcrYX9K0JBYYw26B+meqXXyMec1JtLtPu3eBfzOOHYmnGb8TusmOyMrub9YuN+EodvR4tqNZGd1SCjhM1rjoytUiM5fNEkTmquGZBdwA5KIt+1GbqIRt/VF6WZ4zbkrO9ayaxRQU1zGXjMyPtNdsRJXnNXNOcku+Fq1VQ/nEWN9wV6R0zmR+VILTZdJkCdnrdo8vJQCf5G/GlwLOQQdj98ncPZGiG6ODhFQj8Sr49UyrCCJPQuiQ590p4QW6WxZ8wdr+xCBo7Kclh6vv5zAxs9c+NYM4MkW4E6yrO83IPMkB/VEipkZ/6oUFS804H9Yr9GNWXHD608LBCiB3m3MMxld5fHxHezL4/7+wRwqUbqcEMneqcAcKm+9A3PqhawK/TJoNcqwHRK3TpdNH+TOKkVHeFBM04aDYUJir2rujzB+w6dfD2x9F1tFulMqkD+NBVieHj84nvpaoPSbmsuUAy9kjsU1qCMswyYNmt22rQtFCR7e7ZWGUHvRMD/c8IZv1TfkH2Oj3BsDe8g3m8kGr6VYVPnUcoNbtCVph+Z68o7+rV/sEVDPYKLk4E0h/vMdSlaQuvB7NrsmLM/CxLE4z4vR2d/HOltkmKLcJsgeZ+Cx996gPD2AwC8vF+85vQ== X-Forefront-PRVS: 022649CC2C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(39450400003)(39850400002)(39840400002)(39860400002)(39410400002)(53754006)(24454002)(377454003)(92566002)(90366009)(6116002)(229853002)(25786008)(450100001)(2950100002)(6916009)(57306001)(81166006)(230783001)(66066001)(86362001)(38730400002)(47776003)(189998001)(42186005)(6246003)(110136004)(3846002)(36756003)(8676002)(5660300001)(2351001)(6666003)(77096006)(82746002)(8746002)(50466002)(6306002)(53936002)(33656002)(83716003)(305945005)(7736002)(23676002)(2906002)(6486002)(76176999)(50986999)(50226002)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2507; H:[172.29.101.237]; FPR:; SPF:None; MLV:nspm; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTFQUjA1TUIyNTA3OzIzOlFUeXh2NjJrNkphUm9WeVFGVEEvZDREbmtp?= =?utf-8?B?ZGRlU3V0V1lQdjNmVGZhblVPbExKSjJkaStxQWQ4QkpsMGNaTnFUSUZVYXFr?= =?utf-8?B?Z2lZVXlMTkRTMG5QRWtxckptcFpvKzhJeWxPV1M2T2xpN09MYXFHTzFNSzI0?= =?utf-8?B?WnAzY1lZejh0NUVoaml1Smd3Nm5LK0ZNbUxHdmNVaHJFWThHZUlrL0RXTUNa?= =?utf-8?B?bVdKUGFkdjFHMFk4OE1yamY2TFBFVVd2Zlp3MlE4TndBMThUd1NOc1ZjbFIv?= =?utf-8?B?WS9QZnkzY1Q0Z3VNbTVsbmtvU3BmbmpiWlgwN2drM1VNWUhTK0NtWitOb3ls?= =?utf-8?B?YStYMFRZOERRZnQ0VkxGa1h1MjFGL3Q2eXdQQ0RZUW1SNGRlQTJIc2pSdGxN?= =?utf-8?B?K2NqOG9GUmt6NG1wY3pUa2VyVmlDajM4ejI2R2F5OUljZTFUTU5SSmRSdDJK?= =?utf-8?B?aDl4YTdpVU5SNnk2MTdsSThEQTc5aDNTeGkyc0cwMU9xeDI4d1J5M0VvZXlY?= =?utf-8?B?Skxtb3ZTMnFMeW1hY1EydzVKTitSYWh2K3J4NFhzMmpQZEI5SDh6bVp1QnlS?= =?utf-8?B?L2Q5emx1Nit5UE1mOWxKNUNpeUNBZGFjelNBWi9uRC9YaEJtQkIrei9mbGpI?= =?utf-8?B?OXN6T2pPa3hXL25qbllxV3FSK1M3aS80ZXpISC8va0RMYUc1Q3VFTnZzOHo5?= =?utf-8?B?VklpTGFTMklSOUNjcERLUkZmMkEwNElZN2dEY0xTNEYycmU1c05MbGRYWDU0?= =?utf-8?B?Vi9OSnlYYzZEMUt5cGxHTEk0Y1VKOHdGQVVWbm4rQzlGQXFXVVBUMlkweUp6?= =?utf-8?B?T0RMb2lmVjQxZFRZUm1menYwdmVieFhlTFpTbTUyRkFoREhUOFRqUnpIMlZR?= =?utf-8?B?czd1RzZqbDF4S1BvbmcyaVlReFhKcytDQ1VoU2ZEamdUcVNaRk5zYU1JeEFy?= =?utf-8?B?RGJxcTc3Z2pyOExwWHVaSW52SHBoWWlGL29UdE5HcTlsWEljT3Z2c29DRUZL?= =?utf-8?B?b3UwdVJjTXZCZ0pWdnpDRFo2MWZ0d2pob0xZWkc3TlZtQ0hlSFBRYjMxRUs1?= =?utf-8?B?T0VsTTZNTjcwelkrblVYVUhJK2VFaUNVM1Q3cm1wZkV6dVNGQmJuLzNROGlV?= =?utf-8?B?NFdXRFpPekdBNzJlSzVwMHlQZENMNUdZajQvYUZPdU5pWmxMK0lGeStGMm9X?= =?utf-8?B?Z1RQOTk4dkZzNktNWUlGa3N2c0c3SE1nTExwV25WY1VrQUdTbnY4OW9lMlVz?= =?utf-8?B?cU54dDRjVlh1ZE1qaXFaSmRVbkgxMFlMVkRvWnBnSFRPZERRbnQvc0pMUUpW?= =?utf-8?B?bEVIOGRrYWFlcnhGSUlXaUM4S1d3K2ZaQXNvT05GbGx6U3QvbkRwakhkR1Jv?= =?utf-8?B?WXF4TWF6OUJqMDgwdzZ4OXd5SzVZQ0J5Y2dQdElRNWk2OUc0Z3NLd056bTNV?= =?utf-8?B?WC9OV2hnSmlxTHJPblZ4Ynh3QU95c0ZpTUxWL0J6eW9VcVFib2V5SnZzclZL?= =?utf-8?B?a0NaYlI2R1d6OHlSRFF2ZDdpZTIzbGZ1SHBkV0ZsTDg2TG40c3U2SDlxU2o4?= =?utf-8?B?SE5qK3NxSjZzbllYOVFjMUp5bE80RmlPcURNVUlrSkc1c3E5ZlBPWUNwS2d1?= =?utf-8?B?bk56MkV5UXltRkt4NHJ2ekpNWGdIZm1zcS9MUVM5SndyaUVqUHZLUkMrTjRN?= =?utf-8?B?Ky9iaDdxeHFZSCtJWjhZSTNTWVBYWW9EQWNqSTNNSHYyeDFmdmllc2xyRitY?= =?utf-8?B?RXVYdEZhd1VWK0d3QzRaRG0zOTNPYjdZS0RudENmdXpFdXBZNWdsSXBhckw5?= =?utf-8?Q?xJqGnbyXVFbFk?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 6:IbdS8C30CnKmIBhcnLlF3uO8LJeiOMAjFXodwFcaq/n0a5ka3kXfIXq6Ah2qE7VwGt8mMnFjSv4MV145Sn2dpBZwLMEKYknheTrBiDu6aar+dyRFhw1FDBLnxuWvE1Uth6JKE5fPYkMk49aJVpukDF8D0CZCd57fyVDlfXdDqYlwlWbXNbuVXLtupWTttZbU/2tc4B+ZkiObdT8hsOk/CcTeMtBaD13ctxutRVfHX7Ppnsaj/A0kvw5RWOyULukSL0er098c6TCVfwnazRxvf6rIBh5yFOgsXTzxvAs8JHLff136w1+4cux60Eag2vNwjmMDAZc+If2+rvrAtYNiJag4g8C71nDbsLqJDWaaGCDKMiNDf8yGFOiROtERlMLNlotjaIGAkjneOYGdva6L8nqD4GLndT/BeQ9Sk9m5zzo=; 5:M1lHZQ+VvuSoFoHN4k/dREjOks5dG7kv5ErRlxzX4X9+A88TQne8gRkADXft/2Q4me+zJ00ajIqQ70vv2LhajpFjZL52IjB5V8mq4LNxr+KsUFnhlmed11rRG1XrSBzwSoJVfmgaPJBY0gBrjOifMA==; 24:WD/8uaXaWsJp7W/ldPfE1pwlmmnm2xkiTz8wUTYyD/Q91hlBt+QsKJvbc9aFeRIWw8ixaCL7aaMyjrjTauL7p4SDkbgjJ9Y4lz56K0SmmaE= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 7:3WGUWs3rrTiaSkdIw+T9C0HzGgB/PX/JIVcgufrQ1MdxWl+Fc/5VAyVeHEUoO/aL8rdY3vd814pz9sQQBY4sec+Zf1uJXK9SDt6IE6MESmHCLteLW6AvXUK6rrETQlHbID8ido5GHNOZWtWKP5WIhCYD5hUlVjmc6xtTqwVOAjIp0QUg2DAHhzfls/klcwTYprEx5bNYpnCXoMiwYKcCNUsxyzAArbmoiVNWQJojoUYXwbAJS9q6Z40nS1W+H6fBGYsozGGCfPioFQu6/+46kNl2l1jGyONz4lzA9JnMXv+fJs51aOj7qy1Hyasz1fcz3rfRwDJucOGZZRtPgdH34g== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Feb 2017 21:24:09.8262 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2507 Archived-At: Subject: Re: [Idr] WG adoption call for draft-hr-idr-rfc5575bis-02 "Dissemination of Flow Specification Rules" X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 21:24:13 -0000 Hi All, The draft has consensus to be accepted as an IDR WG item. Authors, = please resubmit as draft-ietf-idr-rfc5575bis-00. Thanks, --John > On Feb 2, 2017, at 2:49 PM, John G. Scudder wrote: >=20 > Folks,=20 >=20 > It was pointed out to me that due to Chinese New Year, a significant = number of WG members may not have had the opportunity to respond (I = don't know what everyone else's excuse is...). We will extend the = adoption call until February 13 unless there are objections. (If there = are objections feel free to unicast them to me, or send them to the = list, as you prefer.) >=20 > Thanks, >=20 > =E2=80=94John >=20 >> On Jan 21, 2017, at 10:03 AM, John G. Scudder = wrote: >>=20 >> Hi All, >>=20 >> The authors have requested IDR working group adoption of = draft-hr-idr-rfc5575bis-02 "Dissemination of Flow Specification Rules". = Please send your comments to the list. >>=20 >> This adoption call will conclude on Monday, February 6. >>=20 >> Thanks, >>=20 >> =E2=80=94John >> _______________________________________________ >> 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 Thu Feb 23 03:23:59 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 2F7F21296E7; Thu, 23 Feb 2017 03:23:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.45.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148784903318.20350.3977002902067988959.idtracker@ietfa.amsl.com> Date: Thu, 23 Feb 2017 03:23:53 -0800 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-rfc5575bis-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 11:23:53 -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 Robert Raszuk Danny McPherson Christoph Loibl Martin Bacher Filename : draft-ietf-idr-rfc5575bis-00.txt Pages : 30 Date : 2017-02-22 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's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-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 Feb 23 08:04: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 91AC212986E for ; Mon, 20 Feb 2017 22:43:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 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, 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 GYvw3vJeMtKE for ; Mon, 20 Feb 2017 22:43:07 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7324112986D for ; Mon, 20 Feb 2017 22:43:07 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 662DDB818AE; Mon, 20 Feb 2017 22:43:07 -0800 (PST) To: rsrihari@cisco.com, tappan@cisco.com, yakov@juniper.net, akatlas@gmail.com, db3546@att.com, aretana@cisco.com, jgs@juniper.net, shares@ndzh.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20170221064307.662DDB818AE@rfc-editor.org> Date: Mon, 20 Feb 2017 22:43:07 -0800 (PST) Archived-At: X-Mailman-Approved-At: Thu, 23 Feb 2017 08:04:28 -0800 Cc: idr@ietf.org, text/plain@rfc-editor.org, rfc-editor@rfc-editor.orgContent-Type, yang@nohdmi.com, charset=UTF-8@rfc-editor.org Subject: [Idr] [Editorial Errata Reported] RFC4360 (4944) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 06:43:08 -0000 The following errata report has been submitted for RFC4360, "BGP Extended Communities Attribute". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4360&eid=4944 -------------------------------------- Type: Editorial Reported by: Yang Yu Section: GLOBAL Original Text ------------- 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 high | Type low(*) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |I|T| | +-+-+-+-+-+-+-+-+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x00 or 0x40 | Sub-Type | Global Administrator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Administrator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x01 or 0x41 | Sub-Type | Global Administrator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Global Administrator (cont.) | Local Administrator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x03 or 0x43 | Sub-Type | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Corrected Text -------------- 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 high | Type low(*) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |I|T| | +-+-+-+-+-+-+-+-+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x00 or 0x40 | Sub-Type | Global Administrator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Administrator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x01 or 0x41 | Sub-Type | Global Administrator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Global Administrator (cont.) | Local Administrator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x03 or 0x43 | Sub-Type | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Notes ----- The packet format convention used in this RFC is different from how it is commonly used. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4360 (draft-ietf-idr-bgp-ext-communities-09) -------------------------------------- Title : BGP Extended Communities Attribute Publication Date : February 2006 Author(s) : S. Sangli, D. Tappan, Y. Rekhter Category : PROPOSED STANDARD Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From nobody Thu Feb 23 09:06: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 8FF6A129A62; Thu, 23 Feb 2017 09:06:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ksK9eIoqNih; Thu, 23 Feb 2017 09:06:37 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0134.outbound.protection.outlook.com [104.47.37.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1DD0129A44; Thu, 23 Feb 2017 09:06:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9ZkodiTYEpbcAjwrqaYk66rdplvqBB/R5ILNz/UVz9I=; b=I7Z6Kfhr+lBpWwNV6pIhqGCwFDDZStyRsOfGDhMffaphOQIRflCz5ClCnEZXHBlBxzHtTzCWchQ/dUztxA0he49hdZG/rv8l5d8aTo/JQ7ko4dDIW/Sc4V6Hbfi3YjZe9w76Y+NOoX4cSv91B3HRG79lP5az1WjI4jgCfEf4rX8= Received: from BLUPR0501MB2051.namprd05.prod.outlook.com (10.164.23.21) by BLUPR0501MB2051.namprd05.prod.outlook.com (10.164.23.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.7; Thu, 23 Feb 2017 17:06:36 +0000 Received: from BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) by BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) with mapi id 15.01.0933.011; Thu, 23 Feb 2017 17:06:36 +0000 From: Ron Bonica To: Shitanshu Shah , "rtg-dir@ietf.org" , "draft-ietf-idr-sla-exchange.all@ietf.org" , "idr@ietf.org" Thread-Topic: RtgDir review: draft-ietf-idr-sla-exchange-10 Thread-Index: AdKIcLCEU+uutt39QyCrZCwOKAXyLQAcLKCoAUVZnUA= Date: Thu, 23 Feb 2017 17:06:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rbonica@juniper.net; x-originating-ip: [66.129.241.10] x-ms-office365-filtering-correlation-id: 348d1843-f1fe-4916-a9c4-08d45c0e5357 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BLUPR0501MB2051; x-microsoft-exchange-diagnostics: 1; BLUPR0501MB2051; 7:NFNfqxX9j4xy8rNbZf3sEvoscE/UO9HzCvtYkuVtPY85L2SsNCoVhhqY0SSXvoouhLJVcmCi55F9PchNKxHyuPOH9hyFJeGs3BJmkeDCfz9qR/8vXH5z98fHK5wfyQP+Asc5bTw649NhiwJl6w8uvQsao8ZtMiSEbZ71RBE3b74JqC1ljwi9jWRaXu7ECzg+qQxah0oU+W0r0CMEiinhU8qGQyTxVVtBju/G27DajJKAG9J/LQuhzMEa7aIDRcqs5i57Or56Gl7NbfcRK0stxMLeLYHyeB1Nkge/LBBTvU7PEO+ZHbtGR/AMA7s3jv5rpik7lU2kH7+EemrsrfmAHA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123558025)(20161123560025)(20161123564025)(20161123555025)(6072148); SRVR:BLUPR0501MB2051; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB2051; x-forefront-prvs: 02272225C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39860400002)(39840400002)(39410400002)(39450400003)(39850400002)(189002)(199003)(54094003)(3280700002)(81156014)(74316002)(189998001)(68736007)(2906002)(6116002)(33656002)(102836003)(3846002)(97736004)(2900100001)(790700001)(81166006)(8676002)(77096006)(6506006)(9326002)(122556002)(6436002)(25786008)(7736002)(92566002)(2201001)(2501003)(229853002)(66066001)(105586002)(2950100002)(230783001)(86362001)(101416001)(5660300001)(106356001)(3660700001)(38730400002)(53936002)(9686003)(8936002)(99286003)(39060400002)(55016002)(6306002)(6246003)(54896002)(7696004)(54356999)(76176999)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB2051; H:BLUPR0501MB2051.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_BLUPR0501MB20518C25229CB24F15458B4CAE530BLUPR0501MB2051_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2017 17:06:36.2540 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB2051 Archived-At: Subject: Re: [Idr] RtgDir review: draft-ietf-idr-sla-exchange-10 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 17:06:39 -0000 --_000_BLUPR0501MB20518C25229CB24F15458B4CAE530BLUPR0501MB2051_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, The draft is internally consistent. But given what is left out of scope, I = wonder if the new attributes will ever be widely deployed. = Ron This document might benefit from discussion of operational issues. I assume= that when a BGP listener learns a route with the SLA Exchange Attribute, i= t provisions class of service forwarding classes on interfaces. ##svshah, though this is one desired use of exchanging SLA content, the dra= ft focuses on transporting SLA content from the SLA Producer to the SLA Con= sumer. Processing of the QoS attribute content, at the SLA Consumer, is out= side the scope of this document. ##svshah, Let me know if you have a suggestion to make description clearer = in Section 1 and 2 to highlight this. I also assume that a) it takes time to provision class of service forwardin= g classes and b) the number of forwarding classes that can be provisioned a= re finite. What does the BGP listener do when the number of forwarding clas= ses requested exceeds its capacity to deliver? ##svshah, Since scope of the document is to transport SLA content from the = SLA Producer to the SLA Consumer, the document considers error handling in = the context of transporting data and thus any formating errors and semantic= s errors within that context. Any errors in the context of processing QoS a= ttribute content at the SLA Consumer is outside the scope of the document. --_000_BLUPR0501MB20518C25229CB24F15458B4CAE530BLUPR0501MB2051_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

The draft is internally consistent. B= ut given what is left out of scope, I wonder if the new attributes will eve= r be widely deployed.

 

      &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;           Ron

 

 


This document might benefit from discussion of operational issues. I assume= that when a BGP listener learns a route with the SLA Exchange Attribute, i= t provisions class of service forwarding classes on interfaces.<= /span>

 

##svshah, = though this is one desired use of exchanging SLA content, the draft focuses= on transporting SLA content from the SLA Producer to the SLA Consumer. Pro= cessing of the QoS attribute content, at the SLA Consumer, is outside the scope of this document.

 

##svshah, = Let me know if you have a suggestion to make description clearer in Section= 1 and 2 to highlight this.

 

 

I also assume that a) it takes time to = provision class of service forwarding classes and b) the number of forwardi= ng classes that can be provisioned are finite. What does the BGP listener do when the number of forwarding classes reques= ted exceeds its capacity to deliver? 

 

##svshah, = Since scope of the document is to transport SLA content from the SLA Produc= er to the SLA Consumer, the document considers error handling in the contex= t of transporting data and thus any formating errors and semantics errors within that context. Any errors in t= he context of processing QoS attribute content at the SLA Consumer is outsi= de the scope of the document.



 

 

--_000_BLUPR0501MB20518C25229CB24F15458B4CAE530BLUPR0501MB2051_-- From nobody Thu Feb 23 11:17: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 6D71B12A267; Thu, 23 Feb 2017 11:17:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzHtG1iw6RpG; Thu, 23 Feb 2017 11:17:08 -0800 (PST) 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 2AEDA12A25D; Thu, 23 Feb 2017 11:17:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=38564; q=dns/txt; s=iport; t=1487877428; x=1489087028; h=from:to:cc:subject:date:message-id:mime-version; bh=P0r7KIojGorX5uASo6uVmW91ATHB50rXE3JNOV8VVbk=; b=VYFlUqpCnJ2KisCpWSZDjNGFnof5e7RJjVhtZi0HfXhaAe2rcS3Y0K7g 7Hk1PFgJGZdLXvA/0jP/2/Pxjt2PFgTkV4/19pKUtEPayZ95WSiMd4azd wmxz9KVbxqyjefc5vgriIuzQgoJ64oAGGp+vTbm80IJhyWvYCLwbd9P4A A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CGAQCFNK9Y/5NdJa1XBhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJuYmGBEINUigiRPZVTgg0uhXQcgwk/GAECAQEBAQEBAWIdC4U?= =?us-ascii?q?aBAZMEgEGLwsKAgQwJwQOAyGHaQOBag6QP51YgWw6K4sXAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBGAWGTIIFCIV5gRAKFU2CLxgugjEFlWmGKwGGc4swgXuFHINRhim?= =?us-ascii?q?IN4pwAR84gQBUFT4RASeEDwMdgWFDN4kFgS+BDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,198,1484006400"; d="scan'208,217";a="389565259" 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; 23 Feb 2017 19:17:06 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v1NJH6CR026989 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 23 Feb 2017 19:17:06 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 23 Feb 2017 13:17:05 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Thu, 23 Feb 2017 13:17:05 -0600 From: "Alvaro Retana (aretana)" To: "draft-ietf-idr-bgp-extended-messages@ietf.org" Thread-Topic: AD Review of draft-ietf-idr-bgp-extended-messages-20 Thread-Index: AQHSjglrFbHoeYS2WUyxb/MV1Degzg== Date: Thu, 23 Feb 2017 19:17:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.6] Content-Type: multipart/alternative; boundary="_000_DAEE98CC8483499EB71CFE4C6FC15A4Aciscocom_" MIME-Version: 1.0 Archived-At: Cc: "idr-chairs@ietf.org" , Susan Hares , "idr@ietf.org" Subject: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 19:17:11 -0000 --_000_DAEE98CC8483499EB71CFE4C6FC15A4Aciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhdXRob3JzOg0KDQpJIGp1c3QgZmluaXNoZWQgcmVhZGluZyB0aGlzIGRvY3VtZW50LiAg SSBzdGFydGVkIGhvcGluZyB0aGF0IHRoaXMgd291bGQgYmUgYSBxdWljayBhbmQgZWFzeSByZWFk LCBhbmQgaXQgd2FzLCBidXQgSSBoYXZlIHNvbWUgY29uY2VybnMgcmVsYXRlZCB0byB0aGUgb3Bl cmF0aW9uIG9mIHRoaXMgZXh0ZW5zaW9uLCBzcGVjaWZpY2FsbHkgYXMgaXQgcmVmZXJzIHRvIGVy cm9yIGNvcnJlY3Rpb24gYW5kIHRyYW5zaXRpb24uICBQbGVhc2UgdGFrZSBhIGxvb2sgYXQgdGhl IGNvbW1lbnRzIGJlbG93LiAgSSBub3RlIHRoYXQgdGhlc2UgdHdvIG1ham9yIGNvbmNlcm5zIHdl cmUgYWxyZWFkeSBkaXNjdXNzZWQgb24gdGhlIFdHIGxpc3QgYXMgYSByZXN1bHQgb2YgdGhlIFJ0 Z0RpciByZXZpZXcgWzFdIGFuZCBkdXJpbmcgdGhlIFdHTEMgWzJdLCBidXQsIHdoaWxlIHRoZXJl IHNlZW1lZCB0byBiZSB1bmRlcnN0YW5kaW5nIG9mIHRoZSBwb2ludHMgbWFkZSBhbmQgZ29vZCBk aXNjdXNzaW9uLCBub25lIG9mIHRoYXQgd2FzIHJlZmxlY3RlZCBpbiB0aGUgZHJhZnQuDQoNCkkg d2lsbCB3YWl0IHVudGlsIHdlIHJlc29sdmUgd2hhdCBJIGNvbnNpZGVyIGFyZSBNYWpvciBpc3N1 ZXMgYmVmb3JlIHN0YXJ0aW5nIHRoZSBJRVRGIExhc3QgQ2FsbC4NCg0KVGhhbmtzIQ0KDQpBbHZh cm8uDQoNClsxXSBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3J0Zy1kaXIv NkVKSzNVQzdiRm5UcHMwYWZkcGwySXczZDVZLz9xaWQ9MzY2OGE5ZjRhODQ2NDc2ZTc4Yzg5OTJm Y2QzY2UyZTYNClsyXSBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2lkci9t QnhVTndGMHFzZEdVV3BxcFVrR1lBd0prWWcvP3FpZD0xOGMzMmVlZWU5MTcyODA0MDJhNjJkYTM2 MTkwMjE5MA0KDQoNCg0KTWFqb3I6DQoNCk0xLiBTZWN0aW9uIDQuIChPcGVyYXRpb24pOiDigJxB biBpbXBsZW1lbnRhdGlvbiB0aGF0IHN1cHBvcnRzIHRoZSBCR1AgRXh0ZW5kZWQgTWVzc2FnZXMg TVVTVCBiZSBwcmVwYXJlZCB0byByZWNlaXZlIGFuIFVQREFURSBtZXNzYWdlIHRoYXQgaXMgbGFy Z2VyIHRoYW4gNDA5NiBieXRlcy7igJwgIE9ubHkgVVBEQVRFcz8gIEkga25vdyB0aGF0IHRoZSBt b3N0IGxpa2VseSBjYXNlIGZvciBleGNlZWRpbmcgdGhlIDRrIHNpemUgaXMgYW4gVVBEQVRFLCBi dXQgd2h5IGFyZSB0aGUgb3RoZXIgbWVzc2FnZXMgbm90IGNvbnNpZGVyZWQ/ICBJIHRoaW5rIHRo YXQgT1BFTi9OT1RJRklDQVRJT05zIGV4Y2VlZGluZyA0ayB3b3VsZCBiZSB1bnVzdWFsIChhbmQg bWF5YmUgZXZlbiB1bm5lY2Vzc2FyeSBvciB1bndhbnRlZCksIGJ1dCBnaXZlbiB0aGUgZXh0cmEg c3BhY2UgSSBjYW4gaW1hZ2luZSB0aGUgYmVuZWZpdHMgb2YgYWRkaW5nIG1vcmUgZGV0YWlsZWQg aW5mb3JtYXRpb24gaW4gTk9USUZJQ0FUSU9OcyDigJMgbm90IHRoYXQgd2Ugc2hvdWxkLCBidXQg d2UgY291bGQuICBBbHNvLCB3aGF0IGRvZXMg4oCccHJlcGFyZWQgdG8gcmVjZWl2ZeKAnSBtZWFu LCBhbmQgaG93IGNhbiDigJxNVVNUIGJlIHByZXBhcmVkIHRvIHJlY2VpdmXigJ0gYmUgZW5mb3Jj ZWQ/ICBHaXZlbiB0aGUgZGlzY3Vzc2lvbiBpbiBTZWN0aW9uIDUgKEVycm9yIEhhbmRsaW5nKSwg eW91IG1pZ2h0IHdhbnQgdG8gYWRkIHNvbWV0aGluZyBsaWtlIOKAnOKApmV2ZW4gaWYgdGhlIENh cGFiaWxpdHkgaXMgbm90IGFkdmVydGlzZWTigJ0uDQoNCg0KTTIuIFNlY3Rpb24gNSAoRXJyb3Ig SGFuZGxpbmcpLiAg4oCcQSBCR1Agc3BlYWtlciB0aGF0IGhhcyB0aGUgYWJpbGl0eSB0byB1c2Ug ZXh0ZW5kZWQgbWVzc2FnZXMgYnV0IGhhcyBub3QgYWR2ZXJ0aXNlZCB0aGUgQkdQIEV4dGVuZGVk IE1lc3NhZ2VzIGNhcGFiaWxpdHksIHByZXN1bWFibHkgZHVlIHRvIGNvbmZpZ3VyYXRpb24sIFNI T1VMRCBOT1QgYWNjZXB0IGFuIGV4dGVuZGVkIG1lc3NhZ2UuICBBIHNwZWFrZXIgTUFZIGltcGxl bWVudCBhIG1vcmUgbGliZXJhbCBwb2xpY3kgYW5kIGFjY2VwdCBleHRlbmRlZCBtZXNzYWdlcyBl dmVuIGZyb20gYSBwZWVyIHRoYXQgaGFzIG5vdCBhZHZlcnRpc2VkIHRoZSBjYXBhYmlsaXR5LuKA nSAgVGhpcyBwYXJhZ3JhcGggdHJvdWJsZXMgbWUgYSBsb3QgYmVjYXVzZSBpdCBpcyBpbiBkaXJl Y3QgY29udHJhY3Rpb24gd2l0aCBTZWN0aW9uIDM6IOKAnEEgcGVlciB3aGljaCBkb2VzIG5vdCBh ZHZlcnRpc2UgdGhpcyBjYXBhYmlsaXR5IE1VU1QgTk9UIHNlbmQgQkdQIEV4dGVuZGVkIE1lc3Nh Z2VzLCBhbmQgQkdQIEV4dGVuZGVkIE1lc3NhZ2VzIE1VU1QgTk9UIGJlIHNlbnQgdG8gaXQu4oCd LiAgSG93ZXZlciwgSSB0aGluayB0aGF0IEpvaG4gU2N1ZGRlcuKAmXMgcmVhc29uaW5nIFszXSBt YWtlcyBzZW5zZSAoImtlZXAgdGhlIHNlc3Npb24gdXAgYXQgKGFsbW9zdCkgYWxsIGNvc3RzIiwg YW5kIHRoZXJl4oCZcyBjbGVhciBwcmVjZWRlbmNlIGluIHRoZSBXRykgZm9yIHRoZSBjYXNlIHdo ZXJlIHRoZSBzZW5kZXIgZGlkIGFkdmVydGlzZSB0aGUgQ2FwYWJpbGl0eSwgYnV0IEnigJltIG5v dCBjb252aW5jZWQgb24gdGhlIGNhc2Ugd2hlcmUgaXQgZGlkbuKAmXQg4oCTIHBsZWFzZSBpbmNs dWRlIHNvbWV0aGluZyBsaWtlIEpvaG7igJlzIGV4cGxhbmF0aW9uIGluIHRoZSB0ZXh0Lg0KDQpN Mi4xLiAgRXZlbiB3aXRoIEpvaG7igJlzIGV4cGxhbmF0aW9uLCBJIGZpbmQgbXlzZWxmIHRoaW5r aW5nIHRoYXQgdGhpcyBzcGVjaWZpY2F0aW9uIGNvdWxkIHJlc3VsdCBpbiBzb21lIHNsb3BweSBp bXBsZW1lbnRhdGlvbnM6IGlmIEkgbmVlZCB0byBhY2NvdW50IGZvciByZWNlaXZpbmcgdW5leHBl Y3RlZCBFeHRlbmRlZCBNZXNzYWdlcyBpbiBteSBjb2RlLCB0aGVuIG1heWJlIEkgd29u4oCZdCB3 b3JyeSB0b28gbXVjaCBhYm91dCBjb250cm9sbGluZyB3aGF0IHRvIHNlbmQgdG8gbXkgcGVlcnMg 4oCTIHNwZWNpYWxseSBpbiBjYXNlcyB3aGVyZSBpdCB3b3VsZCBiZSBlYXN5IHRvIGp1c3QgcmVw bGljYXRlIGFuIFVQREFURSAobGlrZSBpbiBhIHBlZXItZ3JvdXApIGFuZCBub3Qgd29ycnkgYWJv dXQgcG9zc2libGUgZXhjZXB0aW9ucy4gIEkga25vdyB0aGF0IHdlIGNhbuKAmXQgYXZvaWQgYmFk IGltcGxlbWVudGF0aW9ucywgbm8gbWF0dGVyIHdoYXQgdGV4dCBpcyBhZGRlZCDigJMgYnV0IEkg dGhpbmsgdGhhdCByZWNvZ25pemluZyB0aGUgdGhyZWF0IChtYXliZSBpbiB0aGUgU2VjdXJpdHkg Q29uc2lkZXJhdGlvbnMgc2VjdGlvbikgb2Ygc29tZW9uZSByZWNlaXZpbmcgYW4gRXh0ZW5kZWQg TWVzc2FnZSB3aGVuIHRoZXkgZG9u4oCZdCBzdXBwb3J0IGl0IHdvdWxkIGJlIGdvb2QuICAgSSBr bm93IHRoYXQgdGhlcmXigJlzIHRleHQgaW4gdGhlIGRvY3VtZW50IGFscmVhZHkgd2hpY2ggdGFs a3MgYWJvdXQgd2hhdCB0byBkbyBpZiB0aGUgcmVjZWl2ZXIgZG9lc27igJl0IHN1cHBvcnQgRXh0 ZW5kZWQgTWVzc2FnZXMg4oCTIEnigJltIGp1c3Qgd29ycmllZCBhYm91dCBwb3RlbnRpYWwgaXNz dWVzIHdpdGggbWVtb3J5IGFsbG9jYXRpb24gaWYgdGhlIHJlY2VpdmVyIHdhcyBub3QgcmVhZHni gKYNCg0KWzNdIGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvaWRyLy1fR1c2 cmZ0YWJKTHJyUW54b3hNNVhYREdBTS8/cWlkPTVlODUyMWZjM2E0M2E1NTgwYTNjMWUwNTk2MWRj MDg0DQoNCg0KTTMuIFNlY3Rpb24gNSAoRXJyb3IgSGFuZGxpbmcpLiAg4oCc4oCmcmVzZXQgdGhl IHNlc3Npb24gd2l0aCBhIEJhZCBNZXNzYWdlIExlbmd0aCBOT1RJRklDQVRJT07igKbigJ0gIFBs ZWFzZSBiZSBjbGVhciBhbmQgc3BlY2lmaWM6IChzb21ldGhpbmcgbGlrZSB0aGlzIHdvdWxkIGJl IG1vcmUgcHJlY2lzZSkg4oCcLi4uc2VuZCBhIE5PVElGSUNBVElPTiBtZXNzYWdlIHdpdGggdGhl IEVycm9yIENvZGUgc2V0IHRvIE1lc3NhZ2UgSGVhZGVyIEVycm9yIGFuZCB0aGUgRXJyb3IgU3Vi Y29kZSBzZXQgdG8gQmFkIE1lc3NhZ2UgVHlwZSwgYW5kIGNsb3NlIHRoZSBzZXNzaW9u4oCdLiAg QWx0ZXJuYXRpdmVseSwgeW91IGNhbiBqdXN0IHJlbW92ZSB0aGUgdGV4dCAoYWZ0ZXIgdGhlIHJl ZmVyZW5jZSB0byByZmM0MjcxKSBhcyB0aGF0IGlzIHdoYXQgcmZjNDI3MSBhbHJlYWR5IHNheXMg YW5kIHRoZXJl4oCZcyBubyBuZWVkIHRvIHJlcGVhdCBpdCBoZXJlIGFuZCByaXNrIG5vdCBiZWlu ZyBwcmVjaXNl4oCmDQoNCg0KTTQuIFNlY3Rpb24gNSAoRXJyb3IgSGFuZGxpbmcpLiAg4oCcU2lt aWxhcmx5LCBhbnkgc3BlYWtlciB0aGF0IHRyZWF0cyBhbiBpbXByb3BlciBleHRlbmRlZCBtZXNz YWdlIGFzIGEgZmF0YWwgZXJyb3IsIE1VU1QgZG8gbGlrZXdpc2Uu4oCdICBJdCBzb3VuZHMgdGhh dCB5b3XigJlyZSBzYXlpbmcgdGhhdCBhbnkgZmF0YWwgZXJyb3Igd2lsbCByZXN1bHQgaW4gYSDi gJxCYWQgTWVzc2FnZSBMZW5ndGggTk9USUZJQ0FUSU9O4oCdLiAgSSBob3BlIHRoYXQgaXMgbm90 IHdoYXQgeW91IG1lYW50IOKAkyBhbmQgdGhhdCBvdGhlciBlcnJvcnMgc2hvdWxkIHJlc3VsdCBp biB0aGUgYXBwcm9wcmlhdGUgYWN0aW9uIGZyb20gcmZjNDI3MS9yZmM3NjA2LiAgSU9XLCB0aGUg ZXJyb3IgY2hlY2tpbmcgZm9yIHRoZSBtZXNzYWdlIChiZXNpZGVzIGRlIGxlbmd0aCkgZG9lc27i gJl0IGNoYW5nZSwgcmlnaHQ/DQoNCg0KTTUuIFNlY3Rpb24gNSAoRXJyb3IgSGFuZGxpbmcpLiAg 4oCcVGhlIGluY29uc2lzdGVuY3kgYmV0d2VlbiB0aGUgbG9jYWwgYW5kIHJlbW90ZSBCR1Agc3Bl YWtlcnMgTVVTVCBiZSByZXBvcnRlZCB2aWEgc3lzbG9nIGFuZC9vciBTTk1QLuKAnSAgIFNOTVA/ ICBBRkFJSywgdGhlcmXigJlzIG5vIG9iamVjdCB0aGF0IGNhbiByZXBvcnQgdGhpcyBpbmNvbnNp c3RlbmN5IHNpbmNlIHRoZXJl4oCZcyBubyBOT1RJRklDQVRJT04gZ2VuZXJhdGVkLiAgSW4gdGhl IHByb3Bvc2VkIHRleHQgYnkgR3VudGVyIFZhbiBEZSBWZWxkZSBbNF0sIFNOTVAgYW5kIHN5c2xv ZyB3ZXJlIG1lbnRpb25lZCBhcyBleGFtcGxlcyDigJMgSSBzdWdnZXN0IHlvdSBmb2xsb3cgdGhh dCBwYXRoIChubyBuZWVkIGZvciBhbGwgdGhlIOKAnGZsb3dlcnkgbGFuZ3VhZ2XigJ0pIGFuZCBq dXN0IHJlZmVyZW5jZSBtZWNoYW5pc21zIGJ5IGV4YW1wbGUgdG8gYXZvaWQgaGF2aW5nIHRvIHBv aW50IGF0IGhvdyBpdCB3b3VsZCBiZSBkb25lLg0KDQpNNS4xLiBbbWlub3JdIEd1bnRlciBoYWQg b3JpZ2luYWxseSBzdWdnZXN0ZWQgdGhhdCB0aGUgbWVzc2FnZSB0aGF0IGNhdXNlZCB0aGUgaW5j b25zaXN0ZW5jeSBiZSBpbmNsdWRlZCBpbiB0aGUgcmVwb3J0LiAgQXJlIHlvdSBleHBlY3Rpbmcg dGhlIGluY29uc2lzdGVuY3kgcmVwb3J0IHRvIGp1c3QgYmUgYSDigJxCb2Igc2VudCBtZSBhbiBF eHRlbmRlZCBNZXNzYWdlLCBidXQgSSBkaWRu4oCZdCBhZHZlcnRpc2UgdGhlIENhcGFiaWxpdHkg dG8gaGlt4oCdLXR5cGUgbWVzc2FnZSwgb3Igc29tZXRoaW5nIG1vcmU/ICBJdCBtaWdodCBiZSB1 c2VmdWwgdG8gcHJvdmlkZSBzb21lIGd1aWRhbmNlIGluZGljYXRpbmcgd2hhdCB0eXBlIG9mIGlu Zm9ybWF0aW9uIG1pZ2h0IGJlIHVzZWZ1bC9pbnRlcmVzdGluZy4NCg0KWzRdIGh0dHBzOi8vbWFp bGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvaWRyL1J0Y1gtLWNHOTFfclhadzZKYjNPcFNPV0kw MC8/cWlkPWJmYzdhOGYwNWE0Yzg2Y2E5YThjNTY4ZWM2OGE5YmY1DQoNCg0KTTYuIFVwZGF0ZXMg dG8gcmZjNDI3MS4gIFRoZSBBYnN0cmFjdC9JbnRyb2R1Y3Rpb24gY29ycmVjdGx5IG1lbnRpb24g dGhhdCB0aGlzIGRvY3VtZW50IFVwZGF0ZXMgcmZjNDI3MS4gIEJ1dCBJIHRoaW5rIHdlIG5lZWQg dG8gYmUgbW9yZSBzcGVjaWZpYywgc3BlY2lhbGx5IHdoZXJlIHJmYzQyNzEgY2hhbmdlcyBhbmQg dGhlcmUgaXMgbm9ybWF0aXZlIGxhbmd1YWdlIGludm9sdmVkLiAgSSBmb3VuZCB0d28gY2FzZXM6 DQoNCk02LjEuIFNlY3Rpb24gNSBkb2VzbuKAmXQgZGVzY3JpYmUgdGhlIGJlaGF2aW9yIGlmIHRo ZSBtZXNzYWdlIGlzIGxvbmdlciB0aGFuIDY1NTM1LiAgUGxlYXNlIGluY2x1ZGUgZWl0aGVyIGFu IGV4cGxpY2l0IHVwZGF0ZSB0byByZmM0MjcxL1NlY3Rpb24gNi4xIGZvciB0aGUgdXNlIG9mIEV4 dGVuZGVkIE1lc3NhZ2VzLCBvciB0aGUgc3BlY2lmaWMgcHJvY2VzcyBoZXJlLg0KDQpNNi4yLiBy ZmM0MjcxOiDigJxUaGUgdmFsdWUgb2YgdGhlIExlbmd0aCBmaWVsZCBNVVNUIGFsd2F5cyBiZSBh dCBsZWFzdCAxOSBhbmQgbm8gZ3JlYXRlciB0aGFuIDQwOTbigJ0gIFRoYXQgbmVlZHMgdG8gYmUg dXBkYXRlZCB0byA2NTUzNS4NCg0KDQpNNy4gV2hhdCBhYm91dCB0cmFuc2l0aW9uL21pZ3JhdGlv bi9wYXJ0aWFsIGRlcGxveW1lbnQ/ICBXaGF0IHNob3VsZCB0aGUgYmVoYXZpb3IgYmUgaWYsIGZv ciBleGFtcGxlLCBhbiBFeHRlbmRlZCBNZXNzYWdlIFVQREFURSBpcyByZWNlaXZlZCBmcm9tIGEg cGVlciwgYnV0IGNhbuKAmXQgYmUgcHJvcGFnYXRlZCB0byBvdGhlcnMgYmVjYXVzZSB0aGV5IGRv buKAmXQgc3VwcG9ydCBFeHRlbmRlZCBNZXNzYWdlcyAodGhpbmsgcm91dGUgcmVmbGVjdG9ycyBv ciBzaW1wbGUgZUJHUCAtPiBpQkdQKT8/ICBUaGVyZSBzaG91bGQgYmUgc29tZSBndWlkYW5jZSBm b3IgdGhlIGdlbmVyYWwgY2FzZSAoaS5lLiB3aGVuIHRoZSB0b3RhbCBzaXplIGlzID40ayBkdWUg c2ltcGx5IHRvIHRoZSB0b3RhbCBhbW91bnQgb2YgaW5mb3JtYXRpb24sIGFuZCBub3QgYmVjYXVz ZSBhIHNpbmdsZSBhdHRyaWJ1dGUsIGZvciBleGFtcGxlLCBpcyByZWFsbHkgYmlnKSwgYW5kIHNv bWUgcmVxdWlyZW1lbnRzIGxvb2tpbmcgZm9yd2FyZCB0byBwb3RlbnRpYWwgbmV3IG1lc3NhZ2Vz L2F0dHJpYnV0ZXMgdGhhdCBzcGVjaWZpY2FsbHkgcmVseSBvbiBFeHRlbmRlZCBNZXNzYWdlcy4N Cg0KTTcuMS4gVGhpcyB0b3BpYyB3YXMgYWxzbyBicm91Z2h0IHVwIGR1cmluZyBXR0xDLCBmb3Ig ZXhhbXBsZSBbNV0gYW5kIFs2XS4gIFRoZXJlIGFyZSBhIGNvdXBsZSBvZiBzdWdnZXN0ZWQgYWN0 aW9ucy90ZXh0IG9uIHRoZSBsaXN0IHRvbzogWzddIGFuZCBbOF0g4oCTIG9uZSBvZiB0aGVtIGlz OiDigJxpZiB0aGUgYXR0cmlidXRlIHNpemUgaXMgc3VjaCB0aGF0IHRoZSBtZXNzYWdlIGxlbmd0 aCBkb2VzIGdldCBleGNlZWRlZCB0aGVuIHRoZSBQcmVmaXggU0hPVUxEIG5vdCBiZSBhbm5vdW5j ZWQgYW5kIGFuIGVycm9yIHNob3VsZCBiZSBsb2dnZWQgKGV4aXN0aW5nIGNhc2Up4oCdIFs4XS4g IEEgY291cGxlIG9mIHBvaW50cyB0byBoaWdobGlnaHQ6ICgxKSDigJxTSE9VTEQgbm90IGJlIGFu bm91bmNlZOKAnTogd2hpY2ggZ29lcyBiYWNrIHRvIFNlY3Rpb24gNSAoYW5kLCBpbiB0aGlzIGNh c2UsIHNlbmRpbmcgRXh0ZW5kZWQgTWVzc2FnZXMgd2l0aG91dCByZWNlaXZpbmcgdGhlIENhcGFi aWxpdHkgZnJvbSB0aGUgbmVpZ2hib3JzKTsgKDIpIHRoZSBiZWhhdmlvciBjYW4gcmVzdWx0IGlu IGluY29uc2lzdGVudCByb3V0aW5nLCBldGPigKZwbGVhc2UgbWVudGlvbiB0aGUgcG90ZW50aWFs IHJpc2tzIG9mIHBhcnRpYWwgZGVwbG95bWVudC4NCg0KTTcuMi4gV2hhdCBzaG91bGQgdGhlIGRl ZmF1bHQgYmUgZm9yIHRoaXMgZXh0ZW5zaW9uPyAgU2hvdWxkIGl0IGJlIGVuYWJsZWQgYnkgZGVm YXVsdCBvciBub3Q/DQoNCls1XSBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNn L2lkci9ELTBRQUNXWFpJdl9Nd2ZOdDMxLVowQjIxa0kvP3FpZD1hYjJjOTNkMWRmMDE2NzA1YTQ4 MzRiNGUyZmIwYzFiZg0KWzZdIGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cv aWRyL24zVVFxa1dmNVJUc2wyRkJSS1Ayb3FqenFvay8/cWlkPWEzNTY5OWM5MzdjY2QzOGQ5Yjkw NTRlMDQzNTE0ODdkDQpbN10gaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9p ZHIvVWdkbTZYVG5OcDVKTkxhaUNVUXdmT1pOd3lJLz9xaWQ9YWY0NzVkZTM2YzlkMmQ2ZTY0YjNj NWZiZjk1ZDhiMWUNCls4XSBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2lk ci9kUXJ5SnFBcm1BNE9aVVdBSExBMnpwd2hTTjQvP3FpZD1hZjQ3NWRlMzZjOWQyZDZlNjRiM2M1 ZmJmOTVkOGIxZQ0KDQoNCg0KDQpNaW5vcjoNCg0KUDEuIEFic3RyYWN0OiBzL2V4dGVuZCBpdHMg Y3VycmVudCBtZXNzYWdlIHNpemUgZnJvbSA0MDk2L2V4dGVuZCBpdHMgY3VycmVudCBtYXhpbXVt IG1lc3NhZ2Ugc2l6ZSBmcm9tIDQwOTYNCg0KUDIuIHMvSS1ELmlldGYtc2lkci1iZ3BzZWMtb3Zl cnZpZXcvSS1ELmlldGYtc2lkci1iZ3BzZWMtcHJvdG9jb2wNCg0KUDMuIElBTkEgYWxyZWFkeSBh c3NpZ25lZCBDb2RlIDYgZm9yIHRoZSBDYXBhYmlsaXR5LiAgUGxlYXNlIHVzZSB0aGF0IHZhbHVl IGFuZCByZW1pbmQgSUFOQSBvZiB0aGUgZWFybHkgYWxsb2NhdGlvbiBpbiB0aGUgSUFOQSBDb25z aWRlcmF0aW9ucyBzZWN0aW9uLg0KDQpQNC4gSSBkb27igJl0IHVuZGVyc3RhbmQgd2hhdCB0aGlz IG1lYW5zOiDigJxBcHBsaWNhdGlvbnMgZ2VuZXJhdGluZyBtZXNzYWdlcyB3aGljaCBtaWdodCBi ZSBlbmNhcHN1bGF0ZWQgd2l0aGluIEJHUCBtZXNzYWdlcyBNVVNUIGxpbWl0IHRoZSBzaXplIG9m IHRoZWlyIHBheWxvYWQgdG8gdGFrZSBpbnRvIGFjY291bnQgdGhlIG1heGltdW0gbWVzc2FnZSBz aXplLuKAnSAgIFRoZSBwYXJ0IHRoYXQgaXMgbm90IGNsZWFyIGlzIOKAnG1lc3NhZ2Vz4oCmZW5j YXBzdWxhdGVkIHdpdGhpbiBCR1AgbWVzc2FnZXPigKbigJ0uICBXaGF0IGlzIHRoYXQ/ICBJIGd1 ZXNzIHlvdeKAmXJlIHRhbGtpbmcgYWJvdXQgYW55IHN0dWZmIHRoYXQgQkdQIG1heSBiZSB0cmFu c3BvcnRpbmcsIHJpZ2h0PyAgTWF5YmUgcy9tZXNzYWdlcyB3aGljaCBtaWdodCBiZS9pbmZvcm1h dGlvbiB0byBiZQ0KDQpQNS4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnM6IEkgdGhpbmsgaXQgd291 bGQgYmUgZ29vZCB0byBhbHNvIHJlZmVyZW5jZSByZmM0MjcyIChCR1AgU2VjdXJpdHkgVnVsbmVy YWJpbGl0aWVzIEFuYWx5c2lzKSBpbiB0aGlzIHNlY3Rpb24uDQoNCg0KTml0czoNCg0KTjEuIOKA nEl0IGRvZXMgZW5hYmxlIGxhcmdlIEJHUHNlYyBCR1BTRUNfUEFUSHMsIHNlZSBbSS1ELmlldGYt c2lkci1iZ3BzZWMtcHJvdG9jb2xdLuKAnSAgTmljZSwgYnV0IHN1cGVyZmx1b3VzIGFzIGl0IHJl ZmVycyB0byB0aGlzIGRvY3VtZW50Lg0K --_000_DAEE98CC8483499EB71CFE4C6FC15A4Aciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <8F11B76E5671494F8D57F5C9E4ACF371@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxuczptdj0iaHR0cDovL21hY1ZtbFNj aGVtYVVyaSIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPGhlYWQ+ DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hh cnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJUaXRsZSIgY29udGVudD0iIj4NCjxtZXRhIG5hbWU9 IktleXdvcmRzIiBjb250ZW50PSIiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJN aWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9u dCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRo IjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHls ZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1h bA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDsNCglmb250LXdlaWdo dDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xvcjp3aW5k b3d0ZXh0Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDsNCglmb250LXdlaWdodDpub3JtYWw7 DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjciLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjND MSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5EZWFyIGF1dGhvcnM6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JIGp1c3QgZmluaXNo ZWQgcmVhZGluZyB0aGlzIGRvY3VtZW50LiZuYnNwOyBJIHN0YXJ0ZWQgaG9waW5nIHRoYXQgdGhp cyB3b3VsZCBiZSBhIHF1aWNrIGFuZCBlYXN5IHJlYWQsIGFuZCBpdCB3YXMsIGJ1dCBJIGhhdmUg c29tZSBjb25jZXJucyByZWxhdGVkIHRvIHRoZSBvcGVyYXRpb24gb2YgdGhpcyBleHRlbnNpb24s IHNwZWNpZmljYWxseSBhcyBpdCByZWZlcnMNCiB0byBlcnJvciBjb3JyZWN0aW9uIGFuZCB0cmFu c2l0aW9uLiZuYnNwOyBQbGVhc2UgdGFrZSBhIGxvb2sgYXQgdGhlIGNvbW1lbnRzIGJlbG93LiZu YnNwOyBJIG5vdGUgdGhhdCB0aGVzZSB0d28gbWFqb3IgY29uY2VybnMgd2VyZSBhbHJlYWR5IGRp c2N1c3NlZCBvbiB0aGUgV0cgbGlzdCBhcyBhIHJlc3VsdCBvZiB0aGUgUnRnRGlyIHJldmlldyBb MV0gYW5kIGR1cmluZyB0aGUgV0dMQyBbMl0sIGJ1dCwgd2hpbGUgdGhlcmUgc2VlbWVkIHRvIGJl IHVuZGVyc3RhbmRpbmcNCiBvZiB0aGUgcG9pbnRzIG1hZGUgYW5kIGdvb2QgZGlzY3Vzc2lvbiwg bm9uZSBvZiB0aGF0IHdhcyByZWZsZWN0ZWQgaW4gdGhlIGRyYWZ0LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SSB3aWxsIHdhaXQgdW50aWwgd2UgcmVzb2x2ZSB3 aGF0IEkgY29uc2lkZXIgYXJlIE1ham9yIGlzc3VlcyBiZWZvcmUgc3RhcnRpbmcgdGhlIElFVEYg TGFzdCBDYWxsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhh bmtzITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+QWx2YXJvLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+WzFdIDxhIGhyZWY9Imh0 dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvcnRnLWRpci82RUpLM1VDN2JGblRw czBhZmRwbDJJdzNkNVkvP3FpZD0zNjY4YTlmNGE4NDY0NzZlNzhjODk5MmZjZDNjZTJlNiI+DQpo dHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3J0Zy1kaXIvNkVKSzNVQzdiRm5U cHMwYWZkcGwySXczZDVZLz9xaWQ9MzY2OGE5ZjRhODQ2NDc2ZTc4Yzg5OTJmY2QzY2UyZTY8L2E+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPlsyXSA8YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYu b3JnL2FyY2gvbXNnL2lkci9tQnhVTndGMHFzZEdVV3BxcFVrR1lBd0prWWcvP3FpZD0xOGMzMmVl ZWU5MTcyODA0MDJhNjJkYTM2MTkwMjE5MCI+DQpodHRwczovL21haWxhcmNoaXZlLmlldGYub3Jn L2FyY2gvbXNnL2lkci9tQnhVTndGMHFzZEdVV3BxcFVrR1lBd0prWWcvP3FpZD0xOGMzMmVlZWU5 MTcyODA0MDJhNjJkYTM2MTkwMjE5MDwvYT4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5NYWpvcjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi Pk0xLiBTZWN0aW9uIDQuIChPcGVyYXRpb24pOiDigJxBbiBpbXBsZW1lbnRhdGlvbiB0aGF0IHN1 cHBvcnRzIHRoZSBCR1AgRXh0ZW5kZWQgTWVzc2FnZXMgTVVTVCBiZSBwcmVwYXJlZCB0byByZWNl aXZlIGFuIFVQREFURSBtZXNzYWdlIHRoYXQgaXMgbGFyZ2VyIHRoYW4gNDA5NiBieXRlcy7igJwm bmJzcDsgT25seSBVUERBVEVzPyZuYnNwOyBJIGtub3cgdGhhdCB0aGUgbW9zdCBsaWtlbHkNCiBj YXNlIGZvciBleGNlZWRpbmcgdGhlIDRrIHNpemUgaXMgYW4gVVBEQVRFLCBidXQgd2h5IGFyZSB0 aGUgb3RoZXIgbWVzc2FnZXMgbm90IGNvbnNpZGVyZWQ/Jm5ic3A7IEkgdGhpbmsgdGhhdCBPUEVO L05PVElGSUNBVElPTnMgZXhjZWVkaW5nIDRrIHdvdWxkIGJlIHVudXN1YWwgKGFuZCBtYXliZSBl dmVuIHVubmVjZXNzYXJ5IG9yIHVud2FudGVkKSwgYnV0IGdpdmVuIHRoZSBleHRyYSBzcGFjZSBJ IGNhbiBpbWFnaW5lIHRoZSBiZW5lZml0cyBvZiBhZGRpbmcNCiBtb3JlIGRldGFpbGVkIGluZm9y bWF0aW9uIGluIE5PVElGSUNBVElPTnMg4oCTIG5vdCB0aGF0IHdlIHNob3VsZCwgYnV0IHdlIGNv dWxkLiZuYnNwOyBBbHNvLCB3aGF0IGRvZXMg4oCccHJlcGFyZWQgdG8gcmVjZWl2ZeKAnSBtZWFu LCBhbmQgaG93IGNhbiDigJxNVVNUIGJlIHByZXBhcmVkIHRvIHJlY2VpdmXigJ0gYmUgZW5mb3Jj ZWQ/Jm5ic3A7IEdpdmVuIHRoZSBkaXNjdXNzaW9uIGluIFNlY3Rpb24gNSAoRXJyb3IgSGFuZGxp bmcpLCB5b3UgbWlnaHQgd2FudCB0byBhZGQgc29tZXRoaW5nDQogbGlrZSDigJzigKZldmVuIGlm IHRoZSBDYXBhYmlsaXR5IGlzIG5vdCBhZHZlcnRpc2Vk4oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk0yLiBTZWN0 aW9uIDUgKEVycm9yIEhhbmRsaW5nKS4mbmJzcDsg4oCcQSBCR1Agc3BlYWtlciB0aGF0IGhhcyB0 aGUgYWJpbGl0eSB0byB1c2UgZXh0ZW5kZWQgbWVzc2FnZXMgYnV0IGhhcyBub3QgYWR2ZXJ0aXNl ZCB0aGUgQkdQIEV4dGVuZGVkIE1lc3NhZ2VzIGNhcGFiaWxpdHksIHByZXN1bWFibHkgZHVlIHRv IGNvbmZpZ3VyYXRpb24sIFNIT1VMRCBOT1QgYWNjZXB0DQogYW4gZXh0ZW5kZWQgbWVzc2FnZS4m bmJzcDsgQSBzcGVha2VyIE1BWSBpbXBsZW1lbnQgYSBtb3JlIGxpYmVyYWwgcG9saWN5IGFuZCBh Y2NlcHQgZXh0ZW5kZWQgbWVzc2FnZXMgZXZlbiBmcm9tIGEgcGVlciB0aGF0IGhhcyBub3QgYWR2 ZXJ0aXNlZCB0aGUgY2FwYWJpbGl0eS7igJ0mbmJzcDsgVGhpcyBwYXJhZ3JhcGggdHJvdWJsZXMg bWUgYSBsb3QgYmVjYXVzZSBpdCBpcyBpbiBkaXJlY3QgY29udHJhY3Rpb24gd2l0aCBTZWN0aW9u IDM6IOKAnEEgcGVlciB3aGljaCBkb2VzDQogbm90IGFkdmVydGlzZSB0aGlzIGNhcGFiaWxpdHkg TVVTVCBOT1Qgc2VuZCBCR1AgRXh0ZW5kZWQgTWVzc2FnZXMsIGFuZCBCR1AgRXh0ZW5kZWQgTWVz c2FnZXMgTVVTVCBOT1QgYmUgc2VudCB0byBpdC7igJ0uJm5ic3A7IEhvd2V2ZXIsIEkgdGhpbmsg dGhhdCBKb2huIFNjdWRkZXLigJlzIHJlYXNvbmluZyBbM10gbWFrZXMgc2Vuc2UgKCZxdW90O2tl ZXAgdGhlIHNlc3Npb24gdXAgYXQgKGFsbW9zdCkgYWxsIGNvc3RzJnF1b3Q7LCBhbmQgdGhlcmXi gJlzIGNsZWFyIHByZWNlZGVuY2UNCiBpbiB0aGUgV0cpIGZvciB0aGUgY2FzZSB3aGVyZSB0aGUg c2VuZGVyIGRpZCBhZHZlcnRpc2UgdGhlIENhcGFiaWxpdHksIGJ1dCBJ4oCZbSBub3QgY29udmlu Y2VkIG9uIHRoZSBjYXNlIHdoZXJlIGl0IGRpZG7igJl0IOKAkyBwbGVhc2UgaW5jbHVkZSBzb21l dGhpbmcgbGlrZSBKb2hu4oCZcyBleHBsYW5hdGlvbiBpbiB0aGUgdGV4dC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk0yLjEuJm5ic3A7IEV2ZW4gd2l0aCBKb2hu 4oCZcyBleHBsYW5hdGlvbiwgSSBmaW5kIG15c2VsZiB0aGlua2luZyB0aGF0IHRoaXMgc3BlY2lm aWNhdGlvbiBjb3VsZCByZXN1bHQgaW4gc29tZSBzbG9wcHkgaW1wbGVtZW50YXRpb25zOiBpZiBJ IG5lZWQgdG8gYWNjb3VudCBmb3IgcmVjZWl2aW5nIHVuZXhwZWN0ZWQgRXh0ZW5kZWQgTWVzc2Fn ZXMgaW4gbXkgY29kZSwNCiB0aGVuIG1heWJlIEkgd29u4oCZdCB3b3JyeSB0b28gbXVjaCBhYm91 dCBjb250cm9sbGluZyB3aGF0IHRvIHNlbmQgdG8gbXkgcGVlcnMg4oCTIHNwZWNpYWxseSBpbiBj YXNlcyB3aGVyZSBpdCB3b3VsZCBiZSBlYXN5IHRvIGp1c3QgcmVwbGljYXRlIGFuIFVQREFURSAo bGlrZSBpbiBhIHBlZXItZ3JvdXApIGFuZCBub3Qgd29ycnkgYWJvdXQgcG9zc2libGUgZXhjZXB0 aW9ucy4mbmJzcDsgSSBrbm93IHRoYXQgd2UgY2Fu4oCZdCBhdm9pZCBiYWQgaW1wbGVtZW50YXRp b25zLA0KIG5vIG1hdHRlciB3aGF0IHRleHQgaXMgYWRkZWQg4oCTIGJ1dCBJIHRoaW5rIHRoYXQg cmVjb2duaXppbmcgdGhlIHRocmVhdCAobWF5YmUgaW4gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRp b25zIHNlY3Rpb24pIG9mIHNvbWVvbmUgcmVjZWl2aW5nIGFuIEV4dGVuZGVkIE1lc3NhZ2Ugd2hl biB0aGV5IGRvbuKAmXQgc3VwcG9ydCBpdCB3b3VsZCBiZSBnb29kLiZuYnNwOyAmbmJzcDtJIGtu b3cgdGhhdCB0aGVyZeKAmXMgdGV4dCBpbiB0aGUgZG9jdW1lbnQgYWxyZWFkeSB3aGljaA0KIHRh bGtzIGFib3V0IHdoYXQgdG8gZG8gaWYgdGhlIHJlY2VpdmVyIGRvZXNu4oCZdCBzdXBwb3J0IEV4 dGVuZGVkIE1lc3NhZ2VzIOKAkyBJ4oCZbSBqdXN0IHdvcnJpZWQgYWJvdXQgcG90ZW50aWFsIGlz c3VlcyB3aXRoIG1lbW9yeSBhbGxvY2F0aW9uIGlmIHRoZSByZWNlaXZlciB3YXMgbm90IHJlYWR5 4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5bM10gPGEgaHJl Zj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9pZHIvLV9HVzZyZnRhYkpM cnJRbnhveE01WFhER0FNLz9xaWQ9NWU4NTIxZmMzYTQzYTU1ODBhM2MxZTA1OTYxZGMwODQiPg0K aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9pZHIvLV9HVzZyZnRhYkpMcnJR bnhveE01WFhER0FNLz9xaWQ9NWU4NTIxZmMzYTQzYTU1ODBhM2MxZTA1OTYxZGMwODQ8L2E+DQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij5NMy4gU2VjdGlvbiA1IChFcnJvciBIYW5kbGluZykuJm5ic3A7IOKAnOKApnJl c2V0IHRoZSBzZXNzaW9uIHdpdGggYSBCYWQgTWVzc2FnZSBMZW5ndGggTk9USUZJQ0FUSU9O4oCm 4oCdJm5ic3A7IFBsZWFzZSBiZSBjbGVhciBhbmQgc3BlY2lmaWM6IChzb21ldGhpbmcgbGlrZSB0 aGlzIHdvdWxkIGJlIG1vcmUgcHJlY2lzZSkg4oCcLi4uc2VuZCBhIE5PVElGSUNBVElPTiBtZXNz YWdlIHdpdGgNCiB0aGUgRXJyb3IgQ29kZSBzZXQgdG8gTWVzc2FnZSBIZWFkZXIgRXJyb3IgYW5k IHRoZSBFcnJvciBTdWJjb2RlIHNldCB0byBCYWQgTWVzc2FnZSBUeXBlLCBhbmQgY2xvc2UgdGhl IHNlc3Npb27igJ0uJm5ic3A7IEFsdGVybmF0aXZlbHksIHlvdSBjYW4ganVzdCByZW1vdmUgdGhl IHRleHQgKGFmdGVyIHRoZSByZWZlcmVuY2UgdG8gcmZjNDI3MSkgYXMgdGhhdCBpcyB3aGF0IHJm YzQyNzEgYWxyZWFkeSBzYXlzIGFuZCB0aGVyZeKAmXMgbm8gbmVlZCB0byByZXBlYXQNCiBpdCBo ZXJlIGFuZCByaXNrIG5vdCBiZWluZyBwcmVjaXNl4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+TTQuIFNlY3Rpb24g NSAoRXJyb3IgSGFuZGxpbmcpLiZuYnNwOyDigJxTaW1pbGFybHksIGFueSBzcGVha2VyIHRoYXQg dHJlYXRzIGFuIGltcHJvcGVyIGV4dGVuZGVkIG1lc3NhZ2UgYXMgYSBmYXRhbCBlcnJvciwgTVVT VCBkbyBsaWtld2lzZS7igJ0mbmJzcDsgSXQgc291bmRzIHRoYXQgeW914oCZcmUgc2F5aW5nIHRo YXQgYW55IGZhdGFsIGVycm9yIHdpbGwgcmVzdWx0IGluIGEg4oCcQmFkDQogTWVzc2FnZSBMZW5n dGggTk9USUZJQ0FUSU9O4oCdLiZuYnNwOyBJIGhvcGUgdGhhdCBpcyBub3Qgd2hhdCB5b3UgbWVh bnQg4oCTIGFuZCB0aGF0IG90aGVyIGVycm9ycyBzaG91bGQgcmVzdWx0IGluIHRoZSBhcHByb3By aWF0ZSBhY3Rpb24gZnJvbSByZmM0MjcxL3JmYzc2MDYuJm5ic3A7IElPVywgdGhlIGVycm9yIGNo ZWNraW5nIGZvciB0aGUgbWVzc2FnZSAoYmVzaWRlcyBkZSBsZW5ndGgpIGRvZXNu4oCZdCBjaGFu Z2UsIHJpZ2h0PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk01LiBTZWN0aW9uIDUgKEVycm9yIEhhbmRsaW5nKS4mbmJz cDsg4oCcVGhlIGluY29uc2lzdGVuY3kgYmV0d2VlbiB0aGUgbG9jYWwgYW5kIHJlbW90ZSBCR1Ag c3BlYWtlcnMgTVVTVCBiZSByZXBvcnRlZCB2aWEgc3lzbG9nIGFuZC9vciBTTk1QLuKAnSZuYnNw OyZuYnNwOyBTTk1QPyZuYnNwOyBBRkFJSywgdGhlcmXigJlzIG5vIG9iamVjdCB0aGF0IGNhbiBy ZXBvcnQgdGhpcyBpbmNvbnNpc3RlbmN5DQogc2luY2UgdGhlcmXigJlzIG5vIE5PVElGSUNBVElP TiBnZW5lcmF0ZWQuJm5ic3A7IEluIHRoZSBwcm9wb3NlZCB0ZXh0IGJ5IEd1bnRlciBWYW4gRGUg VmVsZGUgWzRdLCBTTk1QIGFuZCBzeXNsb2cgd2VyZSBtZW50aW9uZWQgYXMgZXhhbXBsZXMg4oCT IEkgc3VnZ2VzdCB5b3UgZm9sbG93IHRoYXQgcGF0aCAobm8gbmVlZCBmb3IgYWxsIHRoZSDigJxm bG93ZXJ5IGxhbmd1YWdl4oCdKSBhbmQganVzdCByZWZlcmVuY2UgbWVjaGFuaXNtcyBieSBleGFt cGxlIHRvIGF2b2lkDQogaGF2aW5nIHRvIHBvaW50IGF0IGhvdyBpdCB3b3VsZCBiZSBkb25lLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+TTUuMS4gW21pbm9yXSBH dW50ZXIgaGFkIG9yaWdpbmFsbHkgc3VnZ2VzdGVkIHRoYXQgdGhlIG1lc3NhZ2UgdGhhdCBjYXVz ZWQgdGhlIGluY29uc2lzdGVuY3kgYmUgaW5jbHVkZWQgaW4gdGhlIHJlcG9ydC4mbmJzcDsgQXJl IHlvdSBleHBlY3RpbmcgdGhlIGluY29uc2lzdGVuY3kgcmVwb3J0IHRvIGp1c3QgYmUgYSDigJxC b2Igc2VudCBtZSBhbiBFeHRlbmRlZCBNZXNzYWdlLA0KIGJ1dCBJIGRpZG7igJl0IGFkdmVydGlz ZSB0aGUgQ2FwYWJpbGl0eSB0byBoaW3igJ0tdHlwZSBtZXNzYWdlLCBvciBzb21ldGhpbmcgbW9y ZT8mbmJzcDsgSXQgbWlnaHQgYmUgdXNlZnVsIHRvIHByb3ZpZGUgc29tZSBndWlkYW5jZSBpbmRp Y2F0aW5nIHdoYXQgdHlwZSBvZiBpbmZvcm1hdGlvbiBtaWdodCBiZSB1c2VmdWwvaW50ZXJlc3Rp bmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5bNF0gPGEgaHJl Zj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9pZHIvUnRjWC0tY0c5MV9y WFp3NkpiM09wU09XSTAwLz9xaWQ9YmZjN2E4ZjA1YTRjODZjYTlhOGM1NjhlYzY4YTliZjUiPg0K aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9pZHIvUnRjWC0tY0c5MV9yWFp3 NkpiM09wU09XSTAwLz9xaWQ9YmZjN2E4ZjA1YTRjODZjYTlhOGM1NjhlYzY4YTliZjU8L2E+DQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij5NNi4gVXBkYXRlcyB0byByZmM0MjcxLiZuYnNwOyBUaGUgQWJzdHJhY3QvSW50 cm9kdWN0aW9uIGNvcnJlY3RseSBtZW50aW9uIHRoYXQgdGhpcyBkb2N1bWVudCBVcGRhdGVzIHJm YzQyNzEuJm5ic3A7IEJ1dCBJIHRoaW5rIHdlIG5lZWQgdG8gYmUgbW9yZSBzcGVjaWZpYywgc3Bl Y2lhbGx5IHdoZXJlIHJmYzQyNzEgY2hhbmdlcyBhbmQgdGhlcmUgaXMgbm9ybWF0aXZlIGxhbmd1 YWdlDQogaW52b2x2ZWQuJm5ic3A7IEkgZm91bmQgdHdvIGNhc2VzOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+TTYuMS4gU2VjdGlvbiA1IGRvZXNu4oCZdCBkZXNj cmliZSB0aGUgYmVoYXZpb3IgaWYgdGhlIG1lc3NhZ2UgaXMgbG9uZ2VyIHRoYW4gNjU1MzUuJm5i c3A7IFBsZWFzZSBpbmNsdWRlIGVpdGhlciBhbiBleHBsaWNpdCB1cGRhdGUgdG8gcmZjNDI3MS9T ZWN0aW9uIDYuMSBmb3IgdGhlIHVzZSBvZiBFeHRlbmRlZCBNZXNzYWdlcywgb3IgdGhlIHNwZWNp ZmljIHByb2Nlc3MNCiBoZXJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+TTYuMi4gcmZjNDI3MTog4oCcVGhlIHZhbHVlIG9mIHRoZSBMZW5ndGggZmllbGQgTVVT VCBhbHdheXMgYmUgYXQgbGVhc3QgMTkgYW5kIG5vIGdyZWF0ZXIgdGhhbiA0MDk24oCdJm5ic3A7 IFRoYXQgbmVlZHMgdG8gYmUgdXBkYXRlZCB0byA2NTUzNS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5NNy4gV2hhdCBh Ym91dCB0cmFuc2l0aW9uL21pZ3JhdGlvbi9wYXJ0aWFsIGRlcGxveW1lbnQ/Jm5ic3A7IFdoYXQg c2hvdWxkIHRoZSBiZWhhdmlvciBiZSBpZiwgZm9yIGV4YW1wbGUsIGFuIEV4dGVuZGVkIE1lc3Nh Z2UgVVBEQVRFIGlzIHJlY2VpdmVkIGZyb20gYSBwZWVyLCBidXQgY2Fu4oCZdCBiZSBwcm9wYWdh dGVkIHRvIG90aGVycyBiZWNhdXNlIHRoZXkgZG9u4oCZdA0KIHN1cHBvcnQgRXh0ZW5kZWQgTWVz c2FnZXMgKHRoaW5rIHJvdXRlIHJlZmxlY3RvcnMgb3Igc2ltcGxlIGVCR1AgLSZndDsgaUJHUCk/ PyZuYnNwOyBUaGVyZSBzaG91bGQgYmUgc29tZSBndWlkYW5jZSBmb3IgdGhlIGdlbmVyYWwgY2Fz ZSAoaS5lLiB3aGVuIHRoZSB0b3RhbCBzaXplIGlzICZndDs0ayBkdWUgc2ltcGx5IHRvIHRoZSB0 b3RhbCBhbW91bnQgb2YgaW5mb3JtYXRpb24sIGFuZCBub3QgYmVjYXVzZSBhIHNpbmdsZSBhdHRy aWJ1dGUsIGZvciBleGFtcGxlLA0KIGlzIHJlYWxseSBiaWcpLCBhbmQgc29tZSByZXF1aXJlbWVu dHMgbG9va2luZyBmb3J3YXJkIHRvIHBvdGVudGlhbCBuZXcgbWVzc2FnZXMvYXR0cmlidXRlcyB0 aGF0IHNwZWNpZmljYWxseSByZWx5IG9uIEV4dGVuZGVkIE1lc3NhZ2VzLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+TTcuMS4gVGhpcyB0b3BpYyB3YXMgYWxzbyBi cm91Z2h0IHVwIGR1cmluZyBXR0xDLCBmb3IgZXhhbXBsZSBbNV0gYW5kIFs2XS4mbmJzcDsgVGhl cmUgYXJlIGEgY291cGxlIG9mIHN1Z2dlc3RlZCBhY3Rpb25zL3RleHQgb24gdGhlIGxpc3QgdG9v OiBbN10gYW5kIFs4XSDigJMgb25lIG9mIHRoZW0gaXM6IOKAnGlmIHRoZSBhdHRyaWJ1dGUgc2l6 ZSBpcyBzdWNoIHRoYXQgdGhlDQogbWVzc2FnZSBsZW5ndGggZG9lcyBnZXQgZXhjZWVkZWQgdGhl biB0aGUgUHJlZml4IFNIT1VMRCBub3QgYmUgYW5ub3VuY2VkIGFuZCBhbiBlcnJvciBzaG91bGQg YmUgbG9nZ2VkIChleGlzdGluZyBjYXNlKeKAnSBbOF0uJm5ic3A7IEEgY291cGxlIG9mIHBvaW50 cyB0byBoaWdobGlnaHQ6ICgxKSDigJxTSE9VTEQgbm90IGJlIGFubm91bmNlZOKAnTogd2hpY2gg Z29lcyBiYWNrIHRvIFNlY3Rpb24gNSAoYW5kLCBpbiB0aGlzIGNhc2UsIHNlbmRpbmcgRXh0ZW5k ZWQNCiBNZXNzYWdlcyB3aXRob3V0IHJlY2VpdmluZyB0aGUgQ2FwYWJpbGl0eSBmcm9tIHRoZSBu ZWlnaGJvcnMpOyAoMikgdGhlIGJlaGF2aW9yIGNhbiByZXN1bHQgaW4gaW5jb25zaXN0ZW50IHJv dXRpbmcsIGV0Y+KApnBsZWFzZSBtZW50aW9uIHRoZSBwb3RlbnRpYWwgcmlza3Mgb2YgcGFydGlh bCBkZXBsb3ltZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ TTcuMi4gV2hhdCBzaG91bGQgdGhlIGRlZmF1bHQgYmUgZm9yIHRoaXMgZXh0ZW5zaW9uPyZuYnNw OyBTaG91bGQgaXQgYmUgZW5hYmxlZCBieSBkZWZhdWx0IG9yIG5vdD88bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPls1XSA8YSBocmVmPSJodHRwczovL21haWxhcmNo aXZlLmlldGYub3JnL2FyY2gvbXNnL2lkci9ELTBRQUNXWFpJdl9Nd2ZOdDMxLVowQjIxa0kvP3Fp ZD1hYjJjOTNkMWRmMDE2NzA1YTQ4MzRiNGUyZmIwYzFiZiI+DQpodHRwczovL21haWxhcmNoaXZl LmlldGYub3JnL2FyY2gvbXNnL2lkci9ELTBRQUNXWFpJdl9Nd2ZOdDMxLVowQjIxa0kvP3FpZD1h YjJjOTNkMWRmMDE2NzA1YTQ4MzRiNGUyZmIwYzFiZjwvYT4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5b Nl0gPGEgaHJlZj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9pZHIvbjNV UXFrV2Y1UlRzbDJGQlJLUDJvcWp6cW9rLz9xaWQ9YTM1Njk5YzkzN2NjZDM4ZDliOTA1NGUwNDM1 MTQ4N2QiPg0KaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9pZHIvbjNVUXFr V2Y1UlRzbDJGQlJLUDJvcWp6cW9rLz9xaWQ9YTM1Njk5YzkzN2NjZDM4ZDliOTA1NGUwNDM1MTQ4 N2Q8L2E+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+WzddIDxhIGhyZWY9Imh0dHBzOi8vbWFpbGFyY2hp dmUuaWV0Zi5vcmcvYXJjaC9tc2cvaWRyL1VnZG02WFRuTnA1Sk5MYWlDVVF3Zk9aTnd5SS8/cWlk PWFmNDc1ZGUzNmM5ZDJkNmU2NGIzYzVmYmY5NWQ4YjFlIj4NCmh0dHBzOi8vbWFpbGFyY2hpdmUu aWV0Zi5vcmcvYXJjaC9tc2cvaWRyL1VnZG02WFRuTnA1Sk5MYWlDVVF3Zk9aTnd5SS8/cWlkPWFm NDc1ZGUzNmM5ZDJkNmU2NGIzYzVmYmY5NWQ4YjFlPC9hPg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPls4 XSA8YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2lkci9kUXJ5 SnFBcm1BNE9aVVdBSExBMnpwd2hTTjQvP3FpZD1hZjQ3NWRlMzZjOWQyZDZlNjRiM2M1ZmJmOTVk OGIxZSI+DQpodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2lkci9kUXJ5SnFB cm1BNE9aVVdBSExBMnpwd2hTTjQvP3FpZD1hZjQ3NWRlMzZjOWQyZDZlNjRiM2M1ZmJmOTVkOGIx ZTwvYT4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+TWlub3I6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij5QMS4gQWJzdHJhY3Q6IHMvZXh0ZW5kIGl0cyBjdXJyZW50IG1lc3NhZ2Ugc2l6ZSBmcm9t IDQwOTYvZXh0ZW5kIGl0cyBjdXJyZW50IG1heGltdW0gbWVzc2FnZSBzaXplIGZyb20gNDA5Njxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UDIuIHMvSS1ELmlldGYt c2lkci1iZ3BzZWMtb3ZlcnZpZXcvSS1ELmlldGYtc2lkci1iZ3BzZWMtcHJvdG9jb2w8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlAzLiBJQU5BIGFscmVhZHkgYXNz aWduZWQgQ29kZSA2IGZvciB0aGUgQ2FwYWJpbGl0eS4mbmJzcDsgUGxlYXNlIHVzZSB0aGF0IHZh bHVlIGFuZCByZW1pbmQgSUFOQSBvZiB0aGUgZWFybHkgYWxsb2NhdGlvbiBpbiB0aGUgSUFOQSBD b25zaWRlcmF0aW9ucyBzZWN0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+UDQuIEkgZG9u4oCZdCB1bmRlcnN0YW5kIHdoYXQgdGhpcyBtZWFuczog4oCcQXBw bGljYXRpb25zIGdlbmVyYXRpbmcgbWVzc2FnZXMgd2hpY2ggbWlnaHQgYmUgZW5jYXBzdWxhdGVk IHdpdGhpbiBCR1AgbWVzc2FnZXMgTVVTVCBsaW1pdCB0aGUgc2l6ZSBvZiB0aGVpciBwYXlsb2Fk IHRvIHRha2UgaW50byBhY2NvdW50IHRoZSBtYXhpbXVtIG1lc3NhZ2Ugc2l6ZS7igJ0mbmJzcDsm bmJzcDsNCiBUaGUgcGFydCB0aGF0IGlzIG5vdCBjbGVhciBpcyDigJxtZXNzYWdlc+KApmVuY2Fw c3VsYXRlZCB3aXRoaW4gQkdQIG1lc3NhZ2Vz4oCm4oCdLiZuYnNwOyBXaGF0IGlzIHRoYXQ/Jm5i c3A7IEkgZ3Vlc3MgeW914oCZcmUgdGFsa2luZyBhYm91dCBhbnkgc3R1ZmYgdGhhdCBCR1AgbWF5 IGJlIHRyYW5zcG9ydGluZywgcmlnaHQ/Jm5ic3A7IE1heWJlIHMvbWVzc2FnZXMgd2hpY2ggbWln aHQgYmUvaW5mb3JtYXRpb24gdG8gYmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPlA1LiBTZWN1cml0eSBDb25zaWRlcmF0aW9uczogSSB0aGluayBpdCB3b3VsZCBi ZSBnb29kIHRvIGFsc28gcmVmZXJlbmNlIHJmYzQyNzIgKEJHUCBTZWN1cml0eSBWdWxuZXJhYmls aXRpZXMgQW5hbHlzaXMpIGluIHRoaXMgc2VjdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5OaXRzOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+TjEuIOKAnEl0IGRvZXMgZW5hYmxl IGxhcmdlIEJHUHNlYyBCR1BTRUNfUEFUSHMsIHNlZSBbSS1ELmlldGYtc2lkci1iZ3BzZWMtcHJv dG9jb2xdLuKAnSZuYnNwOyBOaWNlLCBidXQgc3VwZXJmbHVvdXMgYXMgaXQgcmVmZXJzIHRvIHRo aXMgZG9jdW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_DAEE98CC8483499EB71CFE4C6FC15A4Aciscocom_-- From nobody Thu Feb 23 11: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 B35711297C5; Thu, 23 Feb 2017 11:24:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.646 X-Spam-Level: *** X-Spam-Status: No, score=3.646 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 vpTicOsl1fhP; Thu, 23 Feb 2017 11:24:11 -0800 (PST) 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 51D6D129606; Thu, 23 Feb 2017 11:24:08 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.9.51; From: "Susan Hares" To: Date: Thu, 23 Feb 2017 14:19:42 -0500 Message-ID: <008501d28e09$c9cd23c0$5d676b40$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0086_01D28DDF.E0F790F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdKOCb5vJ70pxN6ZSw2MDtc/sHwnmg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: draft-ietf-idr-flowspec-interfaceset@ietf.org Subject: [Idr] draft-ietf-idr-flowspec-interfaceset - IPR call prior to call for WG early codepoint allocation X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 19:24:13 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0086_01D28DDF.E0F790F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This an IPR call for draft-ietf-idr-flowspec-interfaceset-02.txt. Wil the authors (Lucy, Jeff, Keyur, Adam and Stephane) please indicate if they know of any IPR. Sue Hares ------=_NextPart_000_0086_01D28DDF.E0F790F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This an = IPR call for draft-ietf-idr-flowspec-interfaceset-02.txt.  Wil the = authors (Lucy, Jeff, Keyur, Adam and Stephane) please indicate if they = know of any IPR.

 

Sue Hares =

------=_NextPart_000_0086_01D28DDF.E0F790F0-- From nobody Thu Feb 23 11:27: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 395F012A282; Thu, 23 Feb 2017 11:27:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.787 X-Spam-Level: X-Spam-Status: No, score=-3.787 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=-1.887, 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=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtTiqADRk_Zh; Thu, 23 Feb 2017 11:27:09 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0125.outbound.protection.outlook.com [104.47.34.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 901A612A272; Thu, 23 Feb 2017 11:27:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=YTFY6L+LDyTFkd0ZTCFAxvBgecMX9EqAzPdO6rros+I=; b=AaXmKKUl+DKx5/zZP/XVImpgfbeL4IdCPTmfsTOjE0JUuhg0HiKHHNsOPoT5aOsLYc9XaunyPMHEhX+MX2si9mwCeW0H7b8+iK5mwBskSw0d37cSCf6UOmtrYMFA67gSY11Y77xmhZS+BQU7Q5mdFvhEoswsnLvS2q6Z1rsvpSw= Received: from SN1PR0501MB1821.namprd05.prod.outlook.com (10.163.131.144) by SN1PR0501MB1824.namprd05.prod.outlook.com (10.163.131.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.7; Thu, 23 Feb 2017 19:26:57 +0000 Received: from SN1PR0501MB1821.namprd05.prod.outlook.com ([10.163.131.144]) by SN1PR0501MB1821.namprd05.prod.outlook.com ([10.163.131.144]) with mapi id 15.01.0933.011; Thu, 23 Feb 2017 19:26:57 +0000 From: Jeff Haas To: Susan Hares Thread-Topic: draft-ietf-idr-flowspec-interfaceset - IPR call prior to call for WG early codepoint allocation Thread-Index: AQHSjgrL4i7SDpDnv0a7R+DhHEAoAA== Date: Thu, 23 Feb 2017 19:26:57 +0000 Message-ID: <1642D003-44F3-40E5-8E41-867726DCCFD0@juniper.net> References: <008501d28e09$c9cd23c0$5d676b40$@ndzh.com> In-Reply-To: <008501d28e09$c9cd23c0$5d676b40$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jhaas@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.12] x-microsoft-exchange-diagnostics: 1; SN1PR0501MB1824; 7:vG+ySb9lwkf4VITyg2bg8OQgXVcKEyiOe5BUICxDX5Ycm2jiRHlJq7LpHDnrOMhLkaWyKXNepBFrENxAZYrbK9wTOC4WP0nLleIBgazoLH9KKdbhQvEeVAdDBkx4dAj/V1jmrQZe24V2A2FPSjTiWuAI855vxt9AZ55mB56HtvPEjC67oNkS3tSzOHuuS5RJF9Cv1F/MxYfpNFf+ahhEit4EtXPSkCE/inxWuTvq0g+33dDNMSoShGnKCdAZAk4qj7z+nHPbJK7CQvXzAVgLYnVp4zyaQ8cTnzcXv2ZfCHVDCTKYnBrkzEeq6nov8CuGQKGUh5NO6Ep0D8F9nZxLGg== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(7916002)(39850400002)(39410400002)(39450400003)(39840400002)(39860400002)(189002)(377454003)(199003)(24454002)(6512007)(558084003)(77096006)(33656002)(6916009)(6506006)(6486002)(54906002)(122556002)(2900100001)(81156014)(229853002)(82746002)(236005)(86362001)(6436002)(81166006)(54896002)(99286003)(97736004)(8676002)(66066001)(25786008)(8936002)(2950100002)(189998001)(92566002)(83716003)(53936002)(3280700002)(38730400002)(110136004)(3660700001)(50986999)(54356999)(4326007)(6246003)(102836003)(6116002)(76176999)(7736002)(3846002)(68736007)(106356001)(101416001)(36756003)(106116001)(2906002)(105586002)(230783001)(5660300001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB1824; H:SN1PR0501MB1821.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-correlation-id: f68ea2c3-1501-4796-85d6-08d45c21ee97 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:SN1PR0501MB1824; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123560025)(20161123558025)(20161123562025)(20161123564025)(6072148); SRVR:SN1PR0501MB1824; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1824; x-forefront-prvs: 02272225C5 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_1642D00344F340E58E41867726DCCFD0junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2017 19:26:57.1103 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB1824 Archived-At: Cc: "idr@ietf.org" , "draft-ietf-idr-flowspec-interfaceset@ietf.org" Subject: Re: [Idr] draft-ietf-idr-flowspec-interfaceset - IPR call prior to call for WG early codepoint allocation X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 19:27:11 -0000 --_000_1642D00344F340E58E41867726DCCFD0junipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Feb 23, 2017, at 2:19 PM, Susan Hares > wrote: This an IPR call for draft-ietf-idr-flowspec-interfaceset-02.txt. Wil the = authors (Lucy, Jeff, Keyur, Adam and Stephane) please indicate if they know= of any IPR. I know of no IPR on this draft. -- Jeff --_000_1642D00344F340E58E41867726DCCFD0junipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <4252DA024F0E9A47B4AC83328220B307@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
On Feb 23, 2017, at 2:19 PM, Susan Hares <shares@ndzh.com> wrote:

This an IPR call for draft-ietf-idr-flowspec-interfaceset-02.txt.  Wil= the authors (Lucy, Jeff, Keyur, Adam and Stephane) please indicate if they= know of any IPR.

I know of no IPR on this draft.

-- Jeff

--_000_1642D00344F340E58E41867726DCCFD0junipernet_-- From nobody Thu Feb 23 13:31: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 910FC129AAB for ; Thu, 23 Feb 2017 13:26:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IyqPbbdkJUiA for ; Thu, 23 Feb 2017 13:26:50 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C0701299DC for ; Thu, 23 Feb 2017 13:26:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6625; q=dns/txt; s=iport; t=1487885210; x=1489094810; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=cs6L8dcEyi8s8QghNXGhjZlZG0ibE0zBSebLwah6Fq4=; b=YtF3T2ahqzwV6qHutLy832u6+G9r3RpQTKKE8J53+hbmignP/0T1L9OW +S5EQhQZhfDTfdFmjhXfpXfdUlzKqpdIbLCETV7R9vv1qidAJWbLZMDWI dKTeSKc3bVhqPRcTD+hfJIV+d1EIQfmpu4bsX99wwkZeZKkCXS/ZhiaPc E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQACU69Y/4ENJK1DGhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMnKWGBCQeNXJFciAyNKIINHwuFeAKDJT8YAQIBAQEBAQEBYii?= =?us-ascii?q?EcAEBAQQBATg0CwwEAgEIEQQBAR8JByEGCxQJCAIEAQ0FCIlVAxUOLbAThzkNg?= =?us-ascii?q?34BAQEBAQEBAQEBAQEBAQEBAQEBAQEdhkyEb4E8gRVGhyIFiRIRh3SKQzoBjgO?= =?us-ascii?q?EF4IEhRyJeopEiGMBHzgVa1QVGCaERgUdgWF1AROKJYENAQEB?= X-IronPort-AV: E=Sophos;i="5.35,198,1484006400"; d="scan'208";a="212316443" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Feb 2017 21:26:49 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v1NLQn6o002172 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 23 Feb 2017 21:26:49 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 23 Feb 2017 15:26:48 -0600 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, 23 Feb 2017 15:26:48 -0600 From: "Jakob Heitz (jheitz)" To: RFC Errata System , "Srihari R Sangli (rsrihari)" , "tappan@cisco.com" , "yakov@juniper.net" , "akatlas@gmail.com" , "db3546@att.com" , "Alvaro Retana (aretana)" , "jgs@juniper.net" , "shares@ndzh.com" Thread-Topic: [Idr] [Editorial Errata Reported] RFC4360 (4944) Thread-Index: AQHSje7NTeLAqNZF1UC3g33mEKQhqaF22MWg Date: Thu, 23 Feb 2017 21:26:48 +0000 Message-ID: <254cf63ad9f94b5697b63c36af0f6d86@XCH-ALN-014.cisco.com> References: <20170221064307.662DDB818AE@rfc-editor.org> In-Reply-To: <20170221064307.662DDB818AE@rfc-editor.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.82.178.245] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Thu, 23 Feb 2017 13:31:27 -0800 Cc: "idr@ietf.org" , "text/plain@rfc-editor.org" , "rfc-editor@rfc-editor.orgContent-Type" , "yang@nohdmi.com" , "charset=UTF-8@rfc-editor.org" Subject: Re: [Idr] [Editorial Errata Reported] RFC4360 (4944) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 21:26:52 -0000 Reject. This will waste people's time opening the errata to try to find the differe= nce. The original makes sense and looks fine. Thanks, Jakob. > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of RFC Errata System > Sent: Monday, February 20, 2017 10:43 PM > To: Srihari R Sangli (rsrihari) ; tappan@cisco.com; y= akov@juniper.net; akatlas@gmail.com; > db3546@att.com; Alvaro Retana (aretana) ; jgs@juniper.= net; shares@ndzh.com > Cc: idr@ietf.org; text/plain@rfc-editor.org; rfc-editor@rfc-editor.orgCon= tent-Type; yang@nohdmi.com; charset=3DUTF- > 8@rfc-editor.org > Subject: [Idr] [Editorial Errata Reported] RFC4360 (4944) >=20 > The following errata report has been submitted for RFC4360, > "BGP Extended Communities Attribute". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D4360&eid=3D4944 >=20 > -------------------------------------- > Type: Editorial > Reported by: Yang Yu >=20 > Section: GLOBAL >=20 > Original Text > ------------- >=20 > 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 high | Type low(*) | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+ > |I|T| | > +-+-+-+-+-+-+-+-+ >=20 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0x00 or 0x40 | Sub-Type | Global Administrator | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Local Administrator | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0x01 or 0x41 | Sub-Type | Global Administrator | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Global Administrator (cont.) | Local Administrator | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0x03 or 0x43 | Sub-Type | Value | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Value (cont.) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 >=20 >=20 >=20 > Corrected Text > -------------- >=20 > 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 high | Type low(*) | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+ > |I|T| | > +-+-+-+-+-+-+-+-+ >=20 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0x00 or 0x40 | Sub-Type | Global Administrator | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Local Administrator | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0x01 or 0x41 | Sub-Type | Global Administrator | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Global Administrator (cont.) | Local Administrator | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0x03 or 0x43 | Sub-Type | Value | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Value (cont.) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Notes > ----- > The packet format convention used in this RFC is different from how it is= commonly used. >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. >=20 > -------------------------------------- > RFC4360 (draft-ietf-idr-bgp-ext-communities-09) > -------------------------------------- > Title : BGP Extended Communities Attribute > Publication Date : February 2006 > Author(s) : S. Sangli, D. Tappan, Y. Rekhter > Category : PROPOSED STANDARD > Source : Inter-Domain Routing > Area : Routing > Stream : IETF > Verifying Party : IESG >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Thu Feb 23 13:50: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 0B5AA129AB3 for ; Thu, 23 Feb 2017 13:50:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.115 X-Spam-Level: X-Spam-Status: No, score=-1.115 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, 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 CuooaNjelGkC for ; Thu, 23 Feb 2017 13:50:10 -0800 (PST) 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 F3377129A23 for ; Thu, 23 Feb 2017 13:50:09 -0800 (PST) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88) (envelope-from ) id 1ch1Gw-000FXo-W3 (job@us.ntt.net); Thu, 23 Feb 2017 21:50:09 +0000 Date: Thu, 23 Feb 2017 22:49:57 +0100 From: Job Snijders To: idr@ietf.org Message-ID: <20170223214957.GZ89584@hanna.meerval.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [Idr] [Editorial Errata Reported] RFC4360 (4944) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 21:50:13 -0000 resending, mailman rejected the many recipients ----- Forwarded message from Job Snijders ----- Date: Thu, 23 Feb 2017 22:45:08 +0100 From: Job Snijders To: "Jakob Heitz (jheitz)" Cc: RFC Errata System , "Srihari R Sangli (rsrihari)" , "tappan@cisco.com" , "yakov@juniper.net" , "akatlas@gmail.com" , "db3546@att.com" , "Alvaro Retana (aretana)" , "jgs@juniper.net" , "shares@ndzh.com" , "idr@ietf.org" Subject: Re: [Idr] [Editorial Errata Reported] RFC4360 (4944) On Thu, Feb 23, 2017 at 09:26:48PM +0000, Jakob Heitz (jheitz) wrote: > Reject. > This will waste people's time opening the errata to try to find the > difference. The original makes sense and looks fine. seconded. Only after reading Jakob's phrase "waste of time" i realised what to look for and saw the difference. :-) Kind regards, Job ----- End forwarded message ----- From nobody Thu Feb 23 13:50: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 513FD129B0F for ; Thu, 23 Feb 2017 13:50:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDOSpkRWO-NP for ; Thu, 23 Feb 2017 13:50:20 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0108.outbound.protection.outlook.com [104.47.40.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 197CC129B06 for ; Thu, 23 Feb 2017 13:50:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qGxabttbsHHkvo8NfSsfgKfX6eSBobbrDg1sP1tIH6c=; b=k1LG1p3gHR7Rmdke8RUHqBzZ4p5oobcvpkaeuh8VqkmML5NAW+ankKJ31daNdNLbFj5zuinMU0mWOIc1GT3MzCNEmp9tUTV40yy7L2c210IgW73KzBWxl0v8Kpw2FVmJ1OMYex4jQTYDIhPBnc8rX2lREVpyjA1+6q5XqDicLPM= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from [172.29.102.180] (66.129.239.10) by BN3PR05MB2499.namprd05.prod.outlook.com (10.167.3.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.7; Thu, 23 Feb 2017 21:50:17 +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: <20170221064307.662DDB818AE@rfc-editor.org> Date: Thu, 23 Feb 2017 16:50:10 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <176CF6D8-2000-434D-B594-67D97FAF6B66@juniper.net> References: <20170221064307.662DDB818AE@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.239.10] X-ClientProxiedBy: BY1PR13CA0021.namprd13.prod.outlook.com (10.162.107.159) To BN3PR05MB2499.namprd05.prod.outlook.com (10.167.3.134) X-MS-Office365-Filtering-Correlation-Id: 43f23cb6-0030-45c1-c912-08d45c35f557 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR05MB2499; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2499; 3:IMr6D+dsmh4IypMo+BHZs/DUVRRy+ISMcpd79SmSubiMxmL/RXINju1A3vWqjyZjCL5weX1/wgnqrNzNRYc8xyAOof61aZDbr7Gi0S7johaYa9tv4bf0vtn4jP7R6x1Y+QrIDetx/0qyoogvo8FCrIVUSJJOnVTTxRRHH7lk4oy8SMTJFQT70NaNDueAuh4DqlfBTLlxbJ2hFyhXzG0y3XXOwZtsAxOc+hzBLboq7PuCniebPJ5zCpzEAyNZI23lhX0OuPP3veZAtKBuEEFmRpJ1OP0jJnIwzGIe+ze76tw=; 25:lxK7O+v03+kzNMd+TGeNfedx8cvRJqv1yk10NKFZ8mnoouZmRpNXNT2BLmvbJ8nS+WXBI47BjHCxN+/gksXZ7CXb9qPilnTaTtH9RiedwrC8IhRVMzIOmXOWGstT8TSUVZ+5vVSlME0Dk9NYbJ6GKXV+GMgBrh1KjghN6zhYkAtX/UgQOM421XJotiWXta9YRf3esWtn8zUDmAAD/CxOiQOILlLBpsBXNZUzT1IXViMr7EWBNb5iyeza1AyfYjE1js03xbJO2Sgio2Zw77mVKmaXfrFIxKHg98hOJG4qtMP8kZmtJkt3rZ7MY5eC/0lwfpbFlWC/UGzNiXQCtBwe5KoC9keuKJVsVgDq3DccEryTIFSxxNjYSIMv34m8jB3EcuLvH/YxfBNn6iK7Hlq3uqqTiI/5PS1CSTDHVLzOGGa5p6FA5mdhtXyOaRKG8NBs8XoTc6WIfO/DjFE0XB3oFw== X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2499; 31:9Yxne5Pz44GUW0uGriYWZ2xU8ZJTdwuZQ1bubF7nJGfkX3FfuYJOD9yPH/zqpd7H4Z7w2ljIomPvO66muwsdNaNCtv+xtdThFNXEwHsbI559zVU1jXHPjHkoAoRkmAKdhfkzk/9PVyK08QDpkIc4J+57d8Y9t4dpMtNUcdSCATtzW+86p9rWBgac9f1pjxbDh3VbonZa11j71CPYQUDkCouMwGz9lZjFkIto7S8pG0mq7DysxNLKi7wXqWMng2zkwNP4KY0Fx/FcLK4Uudz07v+Xx4+TNQxAZzBAa8Cfn80=; 20:DWZrBhcXSkTyshkjeVOYNDdziV0jvy/sZ+e6HoqR+Ak/Sxc3qpwna3yq9Bmaw1ofOc1vIU5Dt3TdTwhUoEM0jsEGFrCBEB3qd8sFQF8xTWWmM0cKIYoS368UqI3dHevZpTHyPkPPQOtg7+SKgaNUevhLO6uoZxvkswStsdd1Xb0WSo0j2TLyfu+jaK4+ho2RmgCl/YgE/OFR20Ac4g4KKcbnb0D4LqyLwZo5DvYLn8G7OMxZuRYCPIk2klTQ5k0NwB1/vNthaiIrl0eqo3/PiTwbT9NzmbrSsZgXBuv5RTWlNZYmkPU/es36bk9pOHD/LdVPiqcL6HEgJ5+/EWeRFMqmeReVDbgCJYMrumWuhRBNXa0W0/E1vNC9jCddyNKY9bz5AU1WqIaXqUONHHg9MoBB+Fuw0C1rSA/uyLuOV/bNp8gafkF4BhMCreSHWcpa+feU7SsW3oiuQUy8ekh9N95jLu2rFex/eJcPkV697rHc/Apr1ef/i0dXCqZWBFju X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123560025)(20161123558025)(20161123562025)(20161123564025)(6072148); SRVR:BN3PR05MB2499; BCL:0; PCL:0; RULEID:; SRVR:BN3PR05MB2499; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2499; 4:VXUJao6/IQzu3P6e/vhJ7ZoEcYAHJBZq34/7ckEaT9QA1yt+1RVvARoec9VPSF9YRVkQKRmEWbgt8q2DYe/B1LrFuu6LUihVtmh6b1X5fCqGKxYt588dGZfrz/0J+2UjGXT3XxxnJDXJcXaffCcIjxwo7XKigQmZ1ZieSsmj84Rw+32KD3bZbMNtwrZkJ3oNHmstwpa+GUTSu1Uzq8NGP8JApZFe5NTnU3UHhHOum/HgSkGebN4WIJoxY9xkf0Uu0ecUeMo+3Fo8aCstNdlMqaEB3s06CASpJYPU2Q8qYf1ENvWeZUdkY16HXZXrVsT9G6ERhalNkt+9x4qIM9Zbcc8wQfe0g7hLKi6nWwgFa7ZGFGNHQCoI5TTTjgGbIeGIj23qyX/IsoBOcqoUq9tsTIpigCholpbVnov81ulGI8z/oj13pjko2wM/jYIQ2qSiszonS2MKm/jshOOz5sNc1B/OAya1zTAx42LaXs1aM2jZItdGbBSe/tJsXuivgLWO62uawUTfuR4dQrWD/833GCtYgUiElRF1Ex+HFPDcJXQnKSVa5jGJTahW8qH5TDqm4XSf3+uA33lgR7Ka+4EtaIBkW6v9jBbfblUJoQMNHpmRj713U2PyDp9r0wpMk4Uy X-Forefront-PRVS: 02272225C5 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(39850400002)(39860400002)(39450400003)(39410400002)(39840400002)(24454002)(199003)(189002)(377454003)(66066001)(6666003)(105586002)(83716003)(110136004)(36756003)(90366009)(6306002)(25786008)(86362001)(54906002)(5660300001)(106356001)(6246003)(57306001)(4326007)(33656002)(47776003)(92566002)(38730400002)(82746002)(189998001)(23676002)(2950100002)(6916009)(16799955002)(3846002)(15188155005)(6116002)(8676002)(81166006)(81156014)(2906002)(53936002)(42186005)(50226002)(50466002)(77096006)(6486002)(68736007)(8746002)(97736004)(966004)(50986999)(76176999)(7736002)(101416001)(305945005)(229853002)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR05MB2499; H:[172.29.102.180]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjNQUjA1TUIyNDk5OzIzOmttcHBFekozbjYrakI2NDVaMlhnTEM1d1lJ?= =?utf-8?B?cXlnYjR0TWk3RWk1TVVBSXBRVG1mTFhPV2F6R1Vib2pzbWo5WmdGSFFQdFp2?= =?utf-8?B?OUVCbkNBWDRrSXJybmRjblhKdndrSWhWMGxwanAxZmZ2M3pvYVlKdEtKNm5t?= =?utf-8?B?K25KeXFaaWxseVRPb0JrdC9pV04rUXYxMG5tbXVkZkhMOXF2KzErRXJPREUz?= =?utf-8?B?ek0rYkJZWHBkMzJxeVV3MmdYR21YTlYzTkRLV1lNRHY5L3A5VjNEUmYyNytJ?= =?utf-8?B?SjV2anZLT2VqK09MRHFMOWNMcVFwUlZNOUlXczd6cTFCZmVlRWhaNkNtd1RI?= =?utf-8?B?SjE0N3BzSUM0TUR6MCsvNVR0WGl4U21OZzJiRTF6RUk3d29NQVhEbWRjdXpq?= =?utf-8?B?eSs2c202NmpuY2s2RVoxbWRHbXZrNjhxWWhkK3FtZEFYRTRBcTNBdWpZb2Ez?= =?utf-8?B?ZlBIZG5DTWR2QWFoWmtEVzB4SlBqZEZrQ1BZUEhPd1VoZ0FOV25qMGFxdHZD?= =?utf-8?B?ZDU0L2pzbTFtMGVIMGM1dmVmOXkwcmR3ODhPSTlLNXUram1sN2dwY2dyM201?= =?utf-8?B?NzZkVXFTZ2ZRTnVpTUlDbXRFaFdwTVhxamw2V3pQZSttaVEvK3dhRjJCV2FO?= =?utf-8?B?SURXRTY2ZGN0aXdVL3JleHRCRE9VWjJrL2ljVWtiK3gwb1d0Tm5RQlpVNCsv?= =?utf-8?B?ZWJ6RThWZkw2c1FqbVNQTk1DaytGd3kvbTc0eFFhUHJBVTdGS0pnQWVxMGtr?= =?utf-8?B?dWRLTHMwM2V4VUdkNS9QNXpJQzJIeThrMmFTMmhrYm5vZzJjM01rYS9WMVRK?= =?utf-8?B?S0R3dWN3UnM3Q3UvZUtwaHNEa2xsWTVlUDhNbXppMFhqWC9JUFMwVGZFM0d6?= =?utf-8?B?VEJaRHhOeWNGb0ZMZ0ZjYVE0WkwxcnlnZU54OFRtUWhTSjNNc1dycjY4bG5a?= =?utf-8?B?KzBpTllCSUxCZFBTbmUwaVFwRUdnYkR2UWJtSlZIQ2IxSmt4SE9sSHRXaEVm?= =?utf-8?B?UjNLMGN3a09UMjhXZ1JtRDhkek5HQ2ZVZUNwL2ZjNFY2bFdDSkIvYXZIaDlH?= =?utf-8?B?eTBFblJFc2lBSENCcUJRRnZnOTdkN0Zhb1NrTXVpcjBLanYxQjBUWkNYTG0r?= =?utf-8?B?bTRQVHdIa1Q4YWJwOHhqYW1TZk01a09YaGpVVEduazBGTGdOK2tmcFJQVm1m?= =?utf-8?B?ZElRMXpFZHcxZ01zUng0YXlZNitVQndyTGVkUDNXVW1nNWxVOVVCVExGdFpP?= =?utf-8?B?QldQSW12YjdvTVhQRXNKbVlVWlh6MDdLREd6ZkhWc2JjMTVkSHVNbVVMOURt?= =?utf-8?B?SEtIQkVqTlBEMnNROGRWZHZGRXZMTWpKZ0JJL1RjQTlXN1Bkb1E4UDZPQ08z?= =?utf-8?B?TnJXcExVZCtPYVh0S09pNjVmL2U1QXFkS2VrN0dkZjRKcWZLODdDSDFLcjY1?= =?utf-8?B?dk9xMGVldVhQVFhEZnFsZVQwOUJZaEFlWW15U1NGZy9qTVlDOFVneDhTbkdn?= =?utf-8?B?emJ5VnBSb2ZPQkptL1gzNVJ5VlpqN1dSd1VUQ2NIbGs3NHRlWDVVZUdwYzNa?= =?utf-8?B?QW85UG90NWl1S2ZmZGZ4ZWR3dnoxS2EvVm5oTEZFVmlERWlZK2JtNUpvalFV?= =?utf-8?B?aDZXVnhDcS9LQzBrb3dvZWFadlNoUlI1K1JhV28xMWtJM05tL3ZnNlRPQm83?= =?utf-8?B?MWlXV0ZIVmFMbmFHemREOGd3NlFHdndzdVZ5Q0R2UUc1SEYxYzdyL3ErOXRh?= =?utf-8?B?OEFQUkljbk9aK3NCMC9weDlrcnlVaWRHRWlaMUFWZ3N2UzZndUNjZU5rZDNa?= =?utf-8?B?alR0dklMNzh4L3Z3S24remMvaEh1Z1dDUkdSU0NkanJKVEt0ZVl0WHdIYnhp?= =?utf-8?B?M0s3WGxPKzFaM1pLTVpqdXhaZzBQb2VDK2dIcmxieUpjcUpvblBVNmFONzRL?= =?utf-8?B?RVpIZzkySldBQzRhU1BlbXk2eXNyaHpvL0ZxTzNOOXYwTCsvdFNheHI5cVBa?= =?utf-8?B?aFk1SC9JUjR1Sk9OWmFFQ0cxa1REd1MvV2V0UGhITXRpQlRGUUE2QnhkWTFH?= =?utf-8?Q?zIi3Hnx969qzyIQuEgwYoHUiS?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2499; 6:2iDVUiIsZ/8dCx5CA97hU1cboL6mZ9rcHMpC4xwKwrWB04hMR6pviB6T1HlylPBbyhDHEVksV54T5r1C0ladPpxV9zYpdcjRsPEsWnsMOlBOxjcQLaZQVs4+1oEoMTpCLwMlO2VlflTmSaSdwqkmhlalKLUyuKsPY3Apj6NHNKt7J31LpnPEYbB/a2FaxOKOqCUPcqcF7epEI3ig24fMA1FqlSyTV6aHNdTnGz15ayMSqf7BMviPHqTbq5mS6hnCGNxXLr6HaGmXFdbO/wyHvVPyz/HGStPMAG3yyMnCXXMQWaASWXIi7TmhTNIuSX5Otde+Sg//K/1PW9EiPKA/kuy1sY8wuAhvZVafLJvbGW3ExU4IUjsHjnEeedgPoOvZCCS0LYZwZvRpa1SdiZVBUlwv+ek3jT4wmYE6PW/iTVQ=; 5:iPXjxDAhattUU/KY0KZgUtYAOT+ZzCAoH/Omded20+VWkft/haOuGcgbL3KtLPojbgKJCDXl35sSmhwvXg/2vQGxzBAcMPL6pWpWlQijpfVahWQwC0OBHZcWgQuvIkk6WU+AymggDWqJZYlipkWUvg==; 24:b3rE9o5k+8jDeboOocXviI0+1BQaFVwa4Am+KyDCMA0P4a8sc6SOf3ZrWBbptGm/pQP0WilarGDU1B4IoF8+nRda/sZQTHe9R1yxOy6KxDc= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2499; 7:Fe2KgtmLJa10UNioxARjA2uKVD/LH/ucaOHpzZ/mmxpQK4DJ7Nsi9ea7X5O812DewA9V51oPeEVyDaJTtztttxTzvfAeR57gq/4x66rxNQn4iea7Buw5Z3MDYF+AObPWZK0IPSaq4+3LUEjgkM/2R/yzJRQKR7qDPrOOdqSLAVp9ck0WZRGDaTww3r8GeY5Q+DHMwywTPLLI4j8HFTyJGfjjit6ndQmrJvrU625JkOGlghRDQ+E2AUtFnWnoNIGNNdBe/Zrb8OOPdarGLEvf4tQYQtCickct67Te8p8VSsEbKKoNvT5HqgBo6GsRSP/aAhNWwjunJnJtyaFSMiximw== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Feb 2017 21:50:17.0223 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR05MB2499 Archived-At: Cc: idr wg , yang@nohdmi.com, Susan Hares Subject: Re: [Idr] [Editorial Errata Reported] RFC4360 (4944) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 21:50:24 -0000 To save others the trouble of figuring out just exactly what this = erratum even *is*: in the original text, the numbers in the diagram = rulers align above the minus signs. In the "corrected" text they align = above the plus signs. I would like to remind anyone who might submit an = erratum in the future: please use the "notes" section to make it clear = what your proposed change is, unless it's perfectly obvious. Looking at https://www.ietf.org/iesg/statement/errata-processing.html, = we have=20 > =E2=80=A2 Rejected - The erratum is in error, or proposes a = change to the RFC that should be done by publishing a new RFC that = replaces the current RFC. In the latter case, if the change is to be = considered for future updates of the document, it should be proposed = using channels other than the errata process, such as a WG mailing list.=20= > =E2=80=A2 Hold for Document Update - The erratum is not a = necessary update to the RFC. However, any future update of the document = might consider this erratum, and determine whether it is correct and = merits including in the update.=20 > ... > Guidelines for review are:=20 >=20 > 5. Typographical errors which would not cause any confusions to = implementation or deployments should be Hold for Document Update. The erratum either is for a typographical error, in which case it should = be Hold for Document Update, or it's in error, in which case it should = be Rejected. The guidelines don't offer a "this is a matter of taste" = option, which I think is what applies here, unless someone can cite an = RFC Editor style guideline specifying that the rulers are supposed to = have the numbers above the pluses? Right now my inclination would be go with Reject, but if someone can = cite evidence that the proposed fix is objectively more correct than the = current text (or if the mood of the WG supports that option, for that = matter) we could do Hold for Document Update instead. --John P.S.: FWIW my eyes prefer the as-published text to the proposed = "correction". > On Feb 21, 2017, at 1:43 AM, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC4360, > "BGP Extended Communities Attribute". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D4360&eid=3D4944 >=20 > -------------------------------------- > Type: Editorial > Reported by: Yang Yu >=20 > Section: GLOBAL >=20 > Original Text > ------------- >=20 > 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 high | Type low(*) | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+ > |I|T| | > +-+-+-+-+-+-+-+-+ >=20 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0x00 or 0x40 | Sub-Type | Global Administrator | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Local Administrator | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0x01 or 0x41 | Sub-Type | Global Administrator | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Global Administrator (cont.) | Local Administrator | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0x03 or 0x43 | Sub-Type | Value | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Value (cont.) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 >=20 >=20 >=20 > Corrected Text > -------------- >=20 > 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 high | Type low(*) | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+ > |I|T| | > +-+-+-+-+-+-+-+-+ >=20 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0x00 or 0x40 | Sub-Type | Global Administrator | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Local Administrator | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0x01 or 0x41 | Sub-Type | Global Administrator | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Global Administrator (cont.) | Local Administrator | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0x03 or 0x43 | Sub-Type | Value | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Value (cont.) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Notes > ----- > The packet format convention used in this RFC is different from how it = is commonly used. >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC4360 (draft-ietf-idr-bgp-ext-communities-09) > -------------------------------------- > Title : BGP Extended Communities Attribute > Publication Date : February 2006 > Author(s) : S. Sangli, D. Tappan, Y. Rekhter > Category : PROPOSED STANDARD > Source : Inter-Domain Routing > Area : Routing > Stream : IETF > Verifying Party : IESG From nobody Thu Feb 23 13: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 19C65129AC3; Thu, 23 Feb 2017 13:33:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 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, 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 Ap2hgiqdkR_N; Thu, 23 Feb 2017 13:33:35 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEA18129ABB; Thu, 23 Feb 2017 13:33:35 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id A8138B81DD8; Thu, 23 Feb 2017 13:33:35 -0800 (PST) To: yang@nohdmi.com, rsrihari@cisco.com, tappan@cisco.com, yakov@juniper.net X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20170223213335.A8138B81DD8@rfc-editor.org> Date: Thu, 23 Feb 2017 13:33:35 -0800 (PST) Archived-At: X-Mailman-Approved-At: Thu, 23 Feb 2017 13:50:53 -0800 Cc: idr@ietf.org, text/plain@rfc-editor.org, charset=UTF-8@rfc-editor.org, rfc-editor@rfc-editor.orgContent-Type, iesg@ietf.org Subject: [Idr] [Errata Rejected] RFC4360 (4944) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 21:33:37 -0000 The following errata report has been rejected for RFC4360, "BGP Extended Communities Attribute". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4360&eid=4944 -------------------------------------- Status: Rejected Type: Editorial Reported by: Yang Yu Date Reported: 2017-02-21 Rejected by: Alvaro Retana (IESG) Section: GLOBAL Original Text ------------- 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 high | Type low(*) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |I|T| | +-+-+-+-+-+-+-+-+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x00 or 0x40 | Sub-Type | Global Administrator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Administrator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x01 or 0x41 | Sub-Type | Global Administrator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Global Administrator (cont.) | Local Administrator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x03 or 0x43 | Sub-Type | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Corrected Text -------------- 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 high | Type low(*) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |I|T| | +-+-+-+-+-+-+-+-+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x00 or 0x40 | Sub-Type | Global Administrator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Administrator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x01 or 0x41 | Sub-Type | Global Administrator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Global Administrator (cont.) | Local Administrator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x03 or 0x43 | Sub-Type | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Notes ----- The packet format convention used in this RFC is different from how it is commonly used. --VERIFIER NOTES-- While the format used may not be the "common" one, the representation is clear and there's no need for this errata. -------------------------------------- RFC4360 (draft-ietf-idr-bgp-ext-communities-09) -------------------------------------- Title : BGP Extended Communities Attribute Publication Date : February 2006 Author(s) : S. Sangli, D. Tappan, Y. Rekhter Category : PROPOSED STANDARD Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From nobody Thu Feb 23 13:51: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 1A331129AB3 for ; Thu, 23 Feb 2017 13:46:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 viPzmljiBdnD for ; Thu, 23 Feb 2017 13:46:16 -0800 (PST) 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 0F47A12940A for ; Thu, 23 Feb 2017 13:46:16 -0800 (PST) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88) (envelope-from ) id 1ch1DD-000F6K-Dj (job@us.ntt.net); Thu, 23 Feb 2017 21:46:07 +0000 Date: Thu, 23 Feb 2017 22:45:08 +0100 From: Job Snijders To: "Jakob Heitz (jheitz)" Message-ID: <20170223214508.GY89584@hanna.meerval.net> References: <20170221064307.662DDB818AE@rfc-editor.org> <254cf63ad9f94b5697b63c36af0f6d86@XCH-ALN-014.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <254cf63ad9f94b5697b63c36af0f6d86@XCH-ALN-014.cisco.com> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: X-Mailman-Approved-At: Thu, 23 Feb 2017 13:50:53 -0800 Cc: "idr@ietf.org" , "tappan@cisco.com" , "yakov@juniper.net" , "shares@ndzh.com" , RFC Errata System Subject: Re: [Idr] [Editorial Errata Reported] RFC4360 (4944) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 21:46:17 -0000 On Thu, Feb 23, 2017 at 09:26:48PM +0000, Jakob Heitz (jheitz) wrote: > Reject. > This will waste people's time opening the errata to try to find the > difference. The original makes sense and looks fine. seconded. Only after reading Jakob's phrase "waste of time" i realised what to look for and saw the difference. :-) Kind regards, Job From nobody Thu Feb 23 13:56: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 E066D1299E3 for ; Thu, 23 Feb 2017 13:56:17 -0800 (PST) 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, 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 Qqw4-wWf5sLa for ; Thu, 23 Feb 2017 13:56:16 -0800 (PST) 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 685311298BF for ; Thu, 23 Feb 2017 13:56:16 -0800 (PST) Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88) (envelope-from ) id 1ch1Mm-0004fK-CC (job@us.ntt.net); Thu, 23 Feb 2017 21:56:11 +0000 Date: Thu, 23 Feb 2017 22:55:25 +0100 From: Job Snijders To: "John G. Scudder" Message-ID: <20170223215525.GA89584@hanna.meerval.net> References: <20170221064307.662DDB818AE@rfc-editor.org> <176CF6D8-2000-434D-B594-67D97FAF6B66@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <176CF6D8-2000-434D-B594-67D97FAF6B66@juniper.net> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Cc: idr wg , yang@nohdmi.com, Susan Hares , RFC Errata System Subject: Re: [Idr] [Editorial Errata Reported] RFC4360 (4944) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 21:56:18 -0000 On Thu, Feb 23, 2017 at 04:50:10PM -0500, John G. Scudder wrote: > To save others the trouble of figuring out just exactly what this erratum even *is*: in the original text, the numbers in the diagram rulers align above the minus signs. In the "corrected" text they align above the plus signs. I would like to remind anyone who might submit an erratum in the future: please use the "notes" section to make it clear what your proposed change is, unless it's perfectly obvious. > > Looking at https://www.ietf.org/iesg/statement/errata-processing.html, we have > > > • Rejected - The erratum is in error, or proposes a change to > > the RFC that should be done by publishing a new RFC that > > replaces the current RFC. In the latter case, if the change is > > to be considered for future updates of the document, it should > > be proposed using channels other than the errata process, such > > as a WG mailing list. > > • Hold for Document Update - The erratum is not a necessary > > update to the RFC. However, any future update of the document > > might consider this erratum, and determine whether it is correct > > and merits including in the update. > > ... > > Guidelines for review are: > > > > 5. Typographical errors which would not cause any confusions to > > implementation or deployments should be Hold for Document > > Update. > > The erratum either is for a typographical error, in which case it > should be Hold for Document Update, or it's in error, in which case it > should be Rejected. The guidelines don't offer a "this is a matter of > taste" option, which I think is what applies here, unless someone can > cite an RFC Editor style guideline specifying that the rulers are > supposed to have the numbers above the pluses? > > Right now my inclination would be go with Reject, but if someone can > cite evidence that the proposed fix is objectively more correct than > the current text (or if the mood of the WG supports that option, for > that matter) we could do Hold for Document Update instead. The example provided in RFC 2360 is aligned with the currently published text: https://tools.ietf.org/html/rfc2360#section-3.1 Kind regards, Job From nobody Thu Feb 23 14:11: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 3AAA81299E3 for ; Thu, 23 Feb 2017 14:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmOkmPA7aTJT for ; Thu, 23 Feb 2017 14:11:30 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D976A1296E5 for ; Thu, 23 Feb 2017 14:11:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1118; q=dns/txt; s=iport; t=1487887889; x=1489097489; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=XtgxUU0E7As1cRSiErRzrUJuAxEKzediZmDi/xxPQi0=; b=Dic4t7LpxI2CWuipdQ3+oD4sLvoT3D/tEWmuWPz9fJSzVlMEDYwj69JG gaCJaX8LDWq8s9dfRFrTz5RtZqd8vX74lBNz88nW8hos5tAkKDiQDnEJ+ 9y/nTnaLIqCckQ+/XQPkx2stNzbZH0tBlg6xXf6R/B/23Ri0R0vlkSTxZ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CXAgCUXa9Y/5xdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1CBageDVIoIpxCCDYYiAhqDCz8YAQIBAQEBAQEBYihCEIQfBiM?= =?us-ascii?q?RRRACAQgaAiYCAgIwFRACBAENBYl1riyCJotDAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBHYELhUGCBYJqgTyDGIMGLoIxAQSJI4d0hFKGKwGSI4F7jxaIN4pwAR84gQB?= =?us-ascii?q?UFU8BhEaBcXWEfYU8gQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.35,198,1484006400"; d="scan'208";a="210510520" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Feb 2017 22:11:28 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v1NMBRuk014356 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 23 Feb 2017 22:11:28 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 23 Feb 2017 16:11:27 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Thu, 23 Feb 2017 16:11:26 -0600 From: "Alvaro Retana (aretana)" To: "John G. Scudder" , RFC Errata System Thread-Topic: [Editorial Errata Reported] RFC4360 (4944) Thread-Index: AQHSjA3G7e9MIEgYR0mGdXEn8tWFbqF3ihUA//+yHwA= Date: Thu, 23 Feb 2017 22:11:26 +0000 Message-ID: References: <20170221064307.662DDB818AE@rfc-editor.org> <176CF6D8-2000-434D-B594-67D97FAF6B66@juniper.net> In-Reply-To: <176CF6D8-2000-434D-B594-67D97FAF6B66@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.6] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: idr wg , "yang@nohdmi.com" , Susan Hares Subject: Re: [Idr] [Editorial Errata Reported] RFC4360 (4944) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 22:11:31 -0000 SSBSZWplY3RlZCBpdCBhbHJlYWR5LiDimLoNCg0KVGhhbmtzIQ0KDQpBbHZhcm8uDQoNCg0KDQoN Cg0KT24gMi8yMy8xNywgNDo1MCBQTSwgIkpvaG4gRy4gU2N1ZGRlciIgPGpnc0BqdW5pcGVyLm5l dD4gd3JvdGU6DQoNCiAgICBUaGUgZXJyYXR1bSBlaXRoZXIgaXMgZm9yIGEgdHlwb2dyYXBoaWNh bCBlcnJvciwgaW4gd2hpY2ggY2FzZSBpdCBzaG91bGQgYmUgSG9sZCBmb3IgRG9jdW1lbnQgVXBk YXRlLCBvciBpdCdzIGluIGVycm9yLCBpbiB3aGljaCBjYXNlIGl0IHNob3VsZCANCmJlIFJlamVj dGVkLiBUaGUgZ3VpZGVsaW5lcyBkb24ndCBvZmZlciBhICJ0aGlzIGlzIGEgbWF0dGVyIG9mIHRh c3RlIiBvcHRpb24sIHdoaWNoIEkgdGhpbmsgaXMgd2hhdCBhcHBsaWVzIGhlcmUsIHVubGVzcyBz b21lb25lIGNhbiBjaXRlIGFuIFJGQyBFZGl0b3Igc3R5bGUgZ3VpZGVsaW5lIHNwZWNpZnlpbmcg dGhhdCB0aGUgcnVsZXJzIGFyZSBzdXBwb3NlZCB0byBoYXZlIHRoZSBudW1iZXJzIGFib3ZlIHRo ZSBwbHVzZXM/DQogICAgDQogICAgUmlnaHQgbm93IG15IGluY2xpbmF0aW9uIHdvdWxkIGJlIGdv IHdpdGggUmVqZWN0LCBidXQgaWYgc29tZW9uZSBjYW4gY2l0ZSBldmlkZW5jZSB0aGF0IHRoZSBw cm9wb3NlZCBmaXggaXMgb2JqZWN0aXZlbHkgbW9yZSBjb3JyZWN0IHRoYW4gdGhlIGN1cnJlbnQg dGV4dCAob3IgaWYgdGhlIG1vb2Qgb2YgdGhlIFdHIHN1cHBvcnRzIHRoYXQgb3B0aW9uLCBmb3Ig dGhhdCBtYXR0ZXIpIHdlIGNvdWxkIGRvIEhvbGQgZm9yIERvY3VtZW50IFVwZGF0ZSBpbnN0ZWFk Lg0KICAgIA0KICAgIA0KDQo= From nobody Thu Feb 23 14:19: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 3DFA7129B92 for ; Thu, 23 Feb 2017 14:19:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzAJGFNWGT9K for ; Thu, 23 Feb 2017 14:19:23 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99DD6129B50 for ; Thu, 23 Feb 2017 14:19:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2078; q=dns/txt; s=iport; t=1487888361; x=1489097961; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=/zEPSxexHZBkowwU22zi2H3ADFNmy5IVo6c8XE2oagU=; b=alESYB+MFVGLiW3HX/PXpsaPZx3ROfIRQdYIRZ3mM1VU3DElBvErdg/M 7zyJlZD7MgMRp0gRXoazTqtmJHWMshSm3dGn2K06RENMpXURXONrfuLho QOCuCHwJkAYX7RwXC3wPRsJ1lb78LC+2dYQqL1wmcKeVoJSrTmyZzMjbW 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AMAgDHXq9Y/4sNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1BhgQkHg1SKCJFclTSCDR8LhXgcgws/GAECAQEBAQEBAWIohHE?= =?us-ascii?q?BAQQBASEROgsSAQgYAgImAgQlCxUSBAENBYl1Dq4igiaLQwEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEaBYELijCBPIMYgwaCXwWJI4d0in0BkiOBe48WiDeKcAEfOIEAVBU?= =?us-ascii?q?+hFiBcXUBijiBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,198,1484006400"; d="scan'208";a="388890636" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Feb 2017 22:19:20 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v1NMJK8C003608 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 23 Feb 2017 22:19:20 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 23 Feb 2017 17:19:19 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Thu, 23 Feb 2017 17:19:19 -0500 From: "Acee Lindem (acee)" To: "Alvaro Retana (aretana)" , "John G. Scudder" , RFC Errata System Thread-Topic: [Idr] [Editorial Errata Reported] RFC4360 (4944) Thread-Index: AQHSjiLgj6B6WbnDmk2Sy0n5XeEa0A== Date: Thu, 23 Feb 2017 22:19:19 +0000 Message-ID: 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: <91A649F48D581A4A8C02C7757515F7A1@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: idr wg , "yang@nohdmi.com" , Susan Hares Subject: Re: [Idr] [Editorial Errata Reported] RFC4360 (4944) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 22:19:25 -0000 SGkgYWxsLCANCg0KT24gMi8yMy8xNywgNToxMSBQTSwgIklkciBvbiBiZWhhbGYgb2YgQWx2YXJv IFJldGFuYSAoYXJldGFuYSkiDQo8aWRyLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGFy ZXRhbmFAY2lzY28uY29tPiB3cm90ZToNCg0KPkkgUmVqZWN0ZWQgaXQgYWxyZWFkeS4g4pi6DQo+ DQo+VGhhbmtzIQ0KPg0KPkFsdmFyby4NCj4NCj4NCj4NCj4NCj4NCj5PbiAyLzIzLzE3LCA0OjUw IFBNLCAiSm9obiBHLiBTY3VkZGVyIiA8amdzQGp1bmlwZXIubmV0PiB3cm90ZToNCj4NCj4gICAg VGhlIGVycmF0dW0gZWl0aGVyIGlzIGZvciBhIHR5cG9ncmFwaGljYWwgZXJyb3IsIGluIHdoaWNo IGNhc2UgaXQNCj5zaG91bGQgYmUgSG9sZCBmb3IgRG9jdW1lbnQgVXBkYXRlLCBvciBpdCdzIGlu IGVycm9yLCBpbiB3aGljaCBjYXNlIGl0DQo+c2hvdWxkIA0KPmJlIFJlamVjdGVkLiBUaGUgZ3Vp ZGVsaW5lcyBkb24ndCBvZmZlciBhICJ0aGlzIGlzIGEgbWF0dGVyIG9mIHRhc3RlIg0KPm9wdGlv biwgd2hpY2ggSSB0aGluayBpcyB3aGF0IGFwcGxpZXMgaGVyZSwgdW5sZXNzIHNvbWVvbmUgY2Fu IGNpdGUgYW4NCj5SRkMgRWRpdG9yIHN0eWxlIGd1aWRlbGluZSBzcGVjaWZ5aW5nIHRoYXQgdGhl IHJ1bGVycyBhcmUgc3VwcG9zZWQgdG8NCj5oYXZlIHRoZSBudW1iZXJzIGFib3ZlIHRoZSBwbHVz ZXM/DQo+ICAgIA0KPiAgICBSaWdodCBub3cgbXkgaW5jbGluYXRpb24gd291bGQgYmUgZ28gd2l0 aCBSZWplY3QsIGJ1dCBpZiBzb21lb25lIGNhbg0KPmNpdGUgZXZpZGVuY2UgdGhhdCB0aGUgcHJv cG9zZWQgZml4IGlzIG9iamVjdGl2ZWx5IG1vcmUgY29ycmVjdCB0aGFuIHRoZQ0KPmN1cnJlbnQg dGV4dCAob3IgaWYgdGhlIG1vb2Qgb2YgdGhlIFdHIHN1cHBvcnRzIHRoYXQgb3B0aW9uLCBmb3Ig dGhhdA0KPm1hdHRlcikgd2UgY291bGQgZG8gSG9sZCBmb3IgRG9jdW1lbnQgVXBkYXRlIGluc3Rl YWQuDQoNCknigJltIGNlcnRhaW5seSBub3QgcmVjb21tZW5kaW5nIHRoYXQgdGhlIHJ1bGVyIGFs aWdubWVudCBqdXN0aWZpZXMgYW4NCmVycmF0YSBidXQsIGZvciBmdXR1cmUgcmVmZXJlbmNlLCB0 aGUgcHJlZmVycmVkIHJ1bGVyIHN0eWxlIGlzIGNvbnNpc3RlbmN5DQp3aXRoIFJGQyA3OTEgd2l0 aCB0aGUgbnVtYmVycyBvdmVyIHRoZSBtaWRkbGUgb2YgdGhlIGJpdCBwb3NpdGlvbnMuDQoNClJl ZmVyIHRvIHNlY3Rpb24gMy40IG9yDQpodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9vbGQvaW5z dHJ1Y3Rpb25zMmF1dGhvcnMudHh0DQoNClRoaXMgaXMgc29tZXRoaW5nIEkgdHlwaWNhbGx5IHdp bGwgY29ycmVjdCB3aGVuIEkgcmV2aWV3IGEgZHJhZnQuDQoNClRoYW5rcywNCkFjZWUNCg0KDQoN Cj4gICAgDQo+ICAgIA0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+SWRyIG1haWxpbmcgbGlzdA0KPklkckBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQoNCg== From nobody Thu Feb 23 16:47: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 23485129404 for ; Thu, 23 Feb 2017 16:47:43 -0800 (PST) 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 cMLoKd_X81Ks for ; Thu, 23 Feb 2017 16:47:41 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 750821293DA for ; Thu, 23 Feb 2017 16:47:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3182; q=dns/txt; s=iport; t=1487897261; x=1489106861; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=f5jHOYQ8pz4kR57zCtoIHFvH8L4HI7OOvkjqVO1cMOU=; b=bs/I7EiHHqF+/OjaTmxIYZXWexB+5qpLAandV7SyhCq82AmKlciCH3sz zLNvNoO3LpAFhZa4eOJBv+Nap3ubK55yrfTw7DcLp/S6nkh9tKGCSMsQM sqDvxbCt7toIrsivN8C+5ng35Jq31X17nAz3UOmSUuNZ2bk0t2r35b7sa g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANAgDjga9Y/4kNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1BhgQkHg1SKCJFelTSCDR8LhXgCGoMLPxgBAgEBAQEBAQFiKIR?= =?us-ascii?q?wAQEBBAEBIRE6CwwEAgEIEQQBAQECAiMDAgICJQsUAQgIAgQBDQUIiW0OrVeCJ?= =?us-ascii?q?otCAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBC4VBhG+BPIYegl8FiSOHdIp9AZI?= =?us-ascii?q?aggSFHIl6iDeKcAEfOIEAVBU+hkl1AYo4gQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.35,199,1484006400"; d="scan'208";a="389072817" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Feb 2017 00:47:40 +0000 Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v1O0leMU030644 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 24 Feb 2017 00:47:40 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, 23 Feb 2017 18:47:40 -0600 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, 23 Feb 2017 18:47:39 -0600 From: "Jakob Heitz (jheitz)" To: "Acee Lindem (acee)" , "Alvaro Retana (aretana)" , "John G. Scudder" , RFC Errata System Thread-Topic: [Idr] [Editorial Errata Reported] RFC4360 (4944) Thread-Index: AQHSjiLgTeLAqNZF1UC3g33mEKQhqaF3Uo9w Date: Fri, 24 Feb 2017 00:47:39 +0000 Message-ID: <336d69bd7e72405daaf4a79cdf863e9e@XCH-ALN-014.cisco.com> 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.82.178.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: idr wg , "yang@nohdmi.com" , Susan Hares Subject: Re: [Idr] [Editorial Errata Reported] RFC4360 (4944) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 00:47:43 -0000 VGhhdCdzIGZpbmUgYmVmb3JlIGFuIFJGQyBpcyBwdWJsaXNoZWQsIGJ1dCBwbGVhc2UgZG9uJ3QN CnN1Ym1pdCBhbiBlcnJhdGEgb24gUkZDIDQyNzEgb3IgYW55IG90aGVyIFJGQyB0aGF0IGRvZXMg aXQgdGhlIG90aGVyIHdheS4NCg0KVGhhbmtzLA0KSmFrb2IuDQoNCj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gRnJvbTogSWRyIFttYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBBY2VlIExpbmRlbSAoYWNlZSkNCj4gU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5 IDIzLCAyMDE3IDI6MTkgUE0NCj4gVG86IEFsdmFybyBSZXRhbmEgKGFyZXRhbmEpIDxhcmV0YW5h QGNpc2NvLmNvbT47IEpvaG4gRy4gU2N1ZGRlciA8amdzQGp1bmlwZXIubmV0PjsgUkZDIEVycmF0 YSBTeXN0ZW0gPHJmYy0NCj4gZWRpdG9yQHJmYy1lZGl0b3Iub3JnPg0KPiBDYzogaWRyIHdnIDxp ZHJAaWV0Zi5vcmc+OyB5YW5nQG5vaGRtaS5jb207IFN1c2FuIEhhcmVzIDxzaGFyZXNAbmR6aC5j b20+DQo+IFN1YmplY3Q6IFJlOiBbSWRyXSBbRWRpdG9yaWFsIEVycmF0YSBSZXBvcnRlZF0gUkZD NDM2MCAoNDk0NCkNCj4gDQo+IEhpIGFsbCwNCj4gDQo+IE9uIDIvMjMvMTcsIDU6MTEgUE0sICJJ ZHIgb24gYmVoYWxmIG9mIEFsdmFybyBSZXRhbmEgKGFyZXRhbmEpIg0KPiA8aWRyLWJvdW5jZXNA aWV0Zi5vcmcgb24gYmVoYWxmIG9mIGFyZXRhbmFAY2lzY28uY29tPiB3cm90ZToNCj4gDQo+ID5J IFJlamVjdGVkIGl0IGFscmVhZHkuIOKYug0KPiA+DQo+ID5UaGFua3MhDQo+ID4NCj4gPkFsdmFy by4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID5PbiAyLzIzLzE3LCA0OjUwIFBNLCAiSm9o biBHLiBTY3VkZGVyIiA8amdzQGp1bmlwZXIubmV0PiB3cm90ZToNCj4gPg0KPiA+ICAgIFRoZSBl cnJhdHVtIGVpdGhlciBpcyBmb3IgYSB0eXBvZ3JhcGhpY2FsIGVycm9yLCBpbiB3aGljaCBjYXNl IGl0DQo+ID5zaG91bGQgYmUgSG9sZCBmb3IgRG9jdW1lbnQgVXBkYXRlLCBvciBpdCdzIGluIGVy cm9yLCBpbiB3aGljaCBjYXNlIGl0DQo+ID5zaG91bGQNCj4gPmJlIFJlamVjdGVkLiBUaGUgZ3Vp ZGVsaW5lcyBkb24ndCBvZmZlciBhICJ0aGlzIGlzIGEgbWF0dGVyIG9mIHRhc3RlIg0KPiA+b3B0 aW9uLCB3aGljaCBJIHRoaW5rIGlzIHdoYXQgYXBwbGllcyBoZXJlLCB1bmxlc3Mgc29tZW9uZSBj YW4gY2l0ZSBhbg0KPiA+UkZDIEVkaXRvciBzdHlsZSBndWlkZWxpbmUgc3BlY2lmeWluZyB0aGF0 IHRoZSBydWxlcnMgYXJlIHN1cHBvc2VkIHRvDQo+ID5oYXZlIHRoZSBudW1iZXJzIGFib3ZlIHRo ZSBwbHVzZXM/DQo+ID4NCj4gPiAgICBSaWdodCBub3cgbXkgaW5jbGluYXRpb24gd291bGQgYmUg Z28gd2l0aCBSZWplY3QsIGJ1dCBpZiBzb21lb25lIGNhbg0KPiA+Y2l0ZSBldmlkZW5jZSB0aGF0 IHRoZSBwcm9wb3NlZCBmaXggaXMgb2JqZWN0aXZlbHkgbW9yZSBjb3JyZWN0IHRoYW4gdGhlDQo+ ID5jdXJyZW50IHRleHQgKG9yIGlmIHRoZSBtb29kIG9mIHRoZSBXRyBzdXBwb3J0cyB0aGF0IG9w dGlvbiwgZm9yIHRoYXQNCj4gPm1hdHRlcikgd2UgY291bGQgZG8gSG9sZCBmb3IgRG9jdW1lbnQg VXBkYXRlIGluc3RlYWQuDQo+IA0KPiBJ4oCZbSBjZXJ0YWlubHkgbm90IHJlY29tbWVuZGluZyB0 aGF0IHRoZSBydWxlciBhbGlnbm1lbnQganVzdGlmaWVzIGFuDQo+IGVycmF0YSBidXQsIGZvciBm dXR1cmUgcmVmZXJlbmNlLCB0aGUgcHJlZmVycmVkIHJ1bGVyIHN0eWxlIGlzIGNvbnNpc3RlbmN5 DQo+IHdpdGggUkZDIDc5MSB3aXRoIHRoZSBudW1iZXJzIG92ZXIgdGhlIG1pZGRsZSBvZiB0aGUg Yml0IHBvc2l0aW9ucy4NCj4gDQo+IFJlZmVyIHRvIHNlY3Rpb24gMy40IG9yDQo+IGh0dHBzOi8v d3d3LnJmYy1lZGl0b3Iub3JnL29sZC9pbnN0cnVjdGlvbnMyYXV0aG9ycy50eHQNCj4gDQo+IFRo aXMgaXMgc29tZXRoaW5nIEkgdHlwaWNhbGx5IHdpbGwgY29ycmVjdCB3aGVuIEkgcmV2aWV3IGEg ZHJhZnQuDQo+IA0KPiBUaGFua3MsDQo+IEFjZWUNCj4gDQo+IA0KPiANCj4gPg0KPiA+DQo+ID4N Cj4gPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID5J ZHIgbWFpbGluZyBsaXN0DQo+ID5JZHJAaWV0Zi5vcmcNCj4gPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaWRyDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBJZHIgbWFpbGluZyBsaXN0DQo+IElkckBpZXRmLm9yZw0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0K From nobody Thu Feb 23 17:04: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 26A761293F5 for ; Thu, 23 Feb 2017 17:04:00 -0800 (PST) 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 9lWyZ_poEWGh for ; Thu, 23 Feb 2017 17:03:58 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F4351293F3 for ; Thu, 23 Feb 2017 17:03:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4402; q=dns/txt; s=iport; t=1487898238; x=1489107838; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=EDg32aGuUu6IarTsWfvK2cRUJbp1kYXh0twgbDQJsGs=; b=P3+P93FeWfi4HiNdraRfyJ3nVFlRUM1Z33eL5DUuAzYZ2Y0XhT18+/2b U71lmBqoT0Po5cZfiWc1X5u/dTTNiMYwqhDiUnpWGRDNcfw2HLe1lCPhQ TckGhCk+Jjpl4Yah2dz+qMg1hUZkDWAg+LdTk1AaraW7EQaVeySBelxCJ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANAgCqha9Y/4wNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1BhgQkHg1SKCJFelTSCDR8LhXgCGoMLPxgBAgEBAQEBAQFiKIR?= =?us-ascii?q?wAQEBBAEBIRE6CwwEAgEIEQQBAQECAiMDAgICJQsUAQgIAgQBDQUIiW0OrVOCJ?= =?us-ascii?q?otCAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBC4VBhG+BPIJqEQGDIoJfBYkjh3S?= =?us-ascii?q?KfQGSGoIEhRyDUYYpiDeKcAEfOHgIVBU+hkl1AYkXgSGBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,199,1484006400"; d="scan'208";a="212388371" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Feb 2017 01:03:57 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v1O13vCC029750 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 24 Feb 2017 01:03:57 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 23 Feb 2017 19:03:56 -0600 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, 23 Feb 2017 19:03:56 -0600 From: "Jakob Heitz (jheitz)" To: "Acee Lindem (acee)" , "Alvaro Retana (aretana)" , "John G. Scudder" , RFC Errata System Thread-Topic: [Idr] [Editorial Errata Reported] RFC4360 (4944) Thread-Index: AQHSjiLgTeLAqNZF1UC3g33mEKQhqaF3Uo9wgAAD3XA= Date: Fri, 24 Feb 2017 01:03:56 +0000 Message-ID: <5398e61e8a0545b4b1a73f3d1b8669ad@XCH-ALN-014.cisco.com> References: <336d69bd7e72405daaf4a79cdf863e9e@XCH-ALN-014.cisco.com> In-Reply-To: <336d69bd7e72405daaf4a79cdf863e9e@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.82.178.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: idr wg , "yang@nohdmi.com" , Susan Hares Subject: Re: [Idr] [Editorial Errata Reported] RFC4360 (4944) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 01:04:00 -0000 QXBwYXJlbnRseSwgSSBkaWRuJ3QgcmVhZCBBY2VlJ3MgZW1haWwgd2VsbCBlbm91Z2g6DQoNCkni gJltIGNlcnRhaW5seSBub3QgcmVjb21tZW5kaW5nIHRoYXQgdGhlIHJ1bGVyIGFsaWdubWVudCBq dXN0aWZpZXMgYW4NCmVycmF0YQ0KDQoNClRoYW5rcywNCkpha29iLg0KDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IElkciBbbWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgSmFrb2IgSGVpdHogKGpoZWl0eikNCj4gU2VudDogVGh1cnNkYXksIEZl YnJ1YXJ5IDIzLCAyMDE3IDQ6NDggUE0NCj4gVG86IEFjZWUgTGluZGVtIChhY2VlKSA8YWNlZUBj aXNjby5jb20+OyBBbHZhcm8gUmV0YW5hIChhcmV0YW5hKSA8YXJldGFuYUBjaXNjby5jb20+OyBK b2huIEcuIFNjdWRkZXINCj4gPGpnc0BqdW5pcGVyLm5ldD47IFJGQyBFcnJhdGEgU3lzdGVtIDxy ZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnPg0KPiBDYzogaWRyIHdnIDxpZHJAaWV0Zi5vcmc+OyB5 YW5nQG5vaGRtaS5jb207IFN1c2FuIEhhcmVzIDxzaGFyZXNAbmR6aC5jb20+DQo+IFN1YmplY3Q6 IFJlOiBbSWRyXSBbRWRpdG9yaWFsIEVycmF0YSBSZXBvcnRlZF0gUkZDNDM2MCAoNDk0NCkNCj4g DQo+IFRoYXQncyBmaW5lIGJlZm9yZSBhbiBSRkMgaXMgcHVibGlzaGVkLCBidXQgcGxlYXNlIGRv bid0DQo+IHN1Ym1pdCBhbiBlcnJhdGEgb24gUkZDIDQyNzEgb3IgYW55IG90aGVyIFJGQyB0aGF0 IGRvZXMgaXQgdGhlIG90aGVyIHdheS4NCj4gDQo+IFRoYW5rcywNCj4gSmFrb2IuDQo+IA0KPiA+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogSWRyIFttYWlsdG86aWRyLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBY2VlIExpbmRlbSAoYWNlZSkNCj4gPiBTZW50 OiBUaHVyc2RheSwgRmVicnVhcnkgMjMsIDIwMTcgMjoxOSBQTQ0KPiA+IFRvOiBBbHZhcm8gUmV0 YW5hIChhcmV0YW5hKSA8YXJldGFuYUBjaXNjby5jb20+OyBKb2huIEcuIFNjdWRkZXIgPGpnc0Bq dW5pcGVyLm5ldD47IFJGQyBFcnJhdGEgU3lzdGVtIDxyZmMtDQo+ID4gZWRpdG9yQHJmYy1lZGl0 b3Iub3JnPg0KPiA+IENjOiBpZHIgd2cgPGlkckBpZXRmLm9yZz47IHlhbmdAbm9oZG1pLmNvbTsg U3VzYW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbT4NCj4gPiBTdWJqZWN0OiBSZTogW0lkcl0gW0Vk aXRvcmlhbCBFcnJhdGEgUmVwb3J0ZWRdIFJGQzQzNjAgKDQ5NDQpDQo+ID4NCj4gPiBIaSBhbGws DQo+ID4NCj4gPiBPbiAyLzIzLzE3LCA1OjExIFBNLCAiSWRyIG9uIGJlaGFsZiBvZiBBbHZhcm8g UmV0YW5hIChhcmV0YW5hKSINCj4gPiA8aWRyLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9m IGFyZXRhbmFAY2lzY28uY29tPiB3cm90ZToNCj4gPg0KPiA+ID5JIFJlamVjdGVkIGl0IGFscmVh ZHkuIOKYug0KPiA+ID4NCj4gPiA+VGhhbmtzIQ0KPiA+ID4NCj4gPiA+QWx2YXJvLg0KPiA+ID4N Cj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPk9uIDIvMjMvMTcsIDQ6NTAgUE0sICJK b2huIEcuIFNjdWRkZXIiIDxqZ3NAanVuaXBlci5uZXQ+IHdyb3RlOg0KPiA+ID4NCj4gPiA+ICAg IFRoZSBlcnJhdHVtIGVpdGhlciBpcyBmb3IgYSB0eXBvZ3JhcGhpY2FsIGVycm9yLCBpbiB3aGlj aCBjYXNlIGl0DQo+ID4gPnNob3VsZCBiZSBIb2xkIGZvciBEb2N1bWVudCBVcGRhdGUsIG9yIGl0 J3MgaW4gZXJyb3IsIGluIHdoaWNoIGNhc2UgaXQNCj4gPiA+c2hvdWxkDQo+ID4gPmJlIFJlamVj dGVkLiBUaGUgZ3VpZGVsaW5lcyBkb24ndCBvZmZlciBhICJ0aGlzIGlzIGEgbWF0dGVyIG9mIHRh c3RlIg0KPiA+ID5vcHRpb24sIHdoaWNoIEkgdGhpbmsgaXMgd2hhdCBhcHBsaWVzIGhlcmUsIHVu bGVzcyBzb21lb25lIGNhbiBjaXRlIGFuDQo+ID4gPlJGQyBFZGl0b3Igc3R5bGUgZ3VpZGVsaW5l IHNwZWNpZnlpbmcgdGhhdCB0aGUgcnVsZXJzIGFyZSBzdXBwb3NlZCB0bw0KPiA+ID5oYXZlIHRo ZSBudW1iZXJzIGFib3ZlIHRoZSBwbHVzZXM/DQo+ID4gPg0KPiA+ID4gICAgUmlnaHQgbm93IG15 IGluY2xpbmF0aW9uIHdvdWxkIGJlIGdvIHdpdGggUmVqZWN0LCBidXQgaWYgc29tZW9uZSBjYW4N Cj4gPiA+Y2l0ZSBldmlkZW5jZSB0aGF0IHRoZSBwcm9wb3NlZCBmaXggaXMgb2JqZWN0aXZlbHkg bW9yZSBjb3JyZWN0IHRoYW4gdGhlDQo+ID4gPmN1cnJlbnQgdGV4dCAob3IgaWYgdGhlIG1vb2Qg b2YgdGhlIFdHIHN1cHBvcnRzIHRoYXQgb3B0aW9uLCBmb3IgdGhhdA0KPiA+ID5tYXR0ZXIpIHdl IGNvdWxkIGRvIEhvbGQgZm9yIERvY3VtZW50IFVwZGF0ZSBpbnN0ZWFkLg0KPiA+DQo+ID4gSeKA mW0gY2VydGFpbmx5IG5vdCByZWNvbW1lbmRpbmcgdGhhdCB0aGUgcnVsZXIgYWxpZ25tZW50IGp1 c3RpZmllcyBhbg0KPiA+IGVycmF0YSBidXQsIGZvciBmdXR1cmUgcmVmZXJlbmNlLCB0aGUgcHJl ZmVycmVkIHJ1bGVyIHN0eWxlIGlzIGNvbnNpc3RlbmN5DQo+ID4gd2l0aCBSRkMgNzkxIHdpdGgg dGhlIG51bWJlcnMgb3ZlciB0aGUgbWlkZGxlIG9mIHRoZSBiaXQgcG9zaXRpb25zLg0KPiA+DQo+ ID4gUmVmZXIgdG8gc2VjdGlvbiAzLjQgb3INCj4gPiBodHRwczovL3d3dy5yZmMtZWRpdG9yLm9y Zy9vbGQvaW5zdHJ1Y3Rpb25zMmF1dGhvcnMudHh0DQo+ID4NCj4gPiBUaGlzIGlzIHNvbWV0aGlu ZyBJIHR5cGljYWxseSB3aWxsIGNvcnJlY3Qgd2hlbiBJIHJldmlldyBhIGRyYWZ0Lg0KPiA+DQo+ ID4gVGhhbmtzLA0KPiA+IEFjZWUNCj4gPg0KPiA+DQo+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4N Cj4gPiA+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g PiA+SWRyIG1haWxpbmcgbGlzdA0KPiA+ID5JZHJAaWV0Zi5vcmcNCj4gPiA+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHINCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gSWRyIG1haWxpbmcgbGlzdA0KPiA+ IElkckBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aWRyDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IElkciBtYWlsaW5nIGxpc3QNCj4gSWRyQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaWRyDQo= From nobody Fri Feb 24 00:32: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 051AD129421; Fri, 24 Feb 2017 00:32:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 F1QShMLUYW3J; Fri, 24 Feb 2017 00:32:38 -0800 (PST) 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 8A165129400; Fri, 24 Feb 2017 00:32:38 -0800 (PST) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 0CB88160351; Fri, 24 Feb 2017 09:32:37 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id DBF768006E; Fri, 24 Feb 2017 09:32:36 +0100 (CET) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM5D.corporate.adroot.infra.ftgroup ([fe80::9898:741c:bc1d:258d%19]) with mapi id 14.03.0319.002; Fri, 24 Feb 2017 09:32:36 +0100 From: To: Susan Hares , "idr@ietf.org" Thread-Topic: draft-ietf-idr-flowspec-interfaceset - IPR call prior to call for WG early codepoint allocation Thread-Index: AdKOCb5vJ70pxN6ZSw2MDtc/sHwnmgAbsQ+A Date: Fri, 24 Feb 2017 08:32:35 +0000 Message-ID: <6867_1487925156_58AFEFA4_6867_8643_1_9E32478DFA9976438E7A22F69B08FF921DD0FD1A@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <008501d28e09$c9cd23c0$5d676b40$@ndzh.com> In-Reply-To: <008501d28e09$c9cd23c0$5d676b40$@ndzh.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF921DD0FD1AOPEXCLILMA4corp_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-idr-flowspec-interfaceset@ietf.org" Subject: Re: [Idr] draft-ietf-idr-flowspec-interfaceset - IPR call prior to call for WG early codepoint allocation X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 08:32:40 -0000 --_000_9E32478DFA9976438E7A22F69B08FF921DD0FD1AOPEXCLILMA4corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm not aware of any IPR regarding this document From: Susan Hares [mailto:shares@ndzh.com] Sent: Thursday, February 23, 2017 20:20 To: idr@ietf.org Cc: draft-ietf-idr-flowspec-interfaceset@ietf.org Subject: draft-ietf-idr-flowspec-interfaceset - IPR call prior to call for = WG early codepoint allocation This an IPR call for draft-ietf-idr-flowspec-interfaceset-02.txt. Wil the = authors (Lucy, Jeff, Keyur, Adam and Stephane) please indicate if they know= of any IPR. Sue Hares ___________________________________________________________________________= ______________________________________________ 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. --_000_9E32478DFA9976438E7A22F69B08FF921DD0FD1AOPEXCLILMA4corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m not aware of= any IPR regarding this document

 

From: Susan Ha= res [mailto:shares@ndzh.com]
Sent: Thursday, February 23, 2017 20:20
To: idr@ietf.org
Cc: draft-ietf-idr-flowspec-interfaceset@ietf.org
Subject: draft-ietf-idr-flowspec-interfaceset - IPR call prior to ca= ll for WG early codepoint allocation

 

This an IPR call for draft-ietf-idr-flowspec-interfa= ceset-02.txt.  Wil the authors (Lucy, Jeff, Keyur, Adam and Stephane) = please indicate if they know of any IPR.

 

Sue Hares 

______________________________________________________________________=
___________________________________________________

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.
--_000_9E32478DFA9976438E7A22F69B08FF921DD0FD1AOPEXCLILMA4corp_-- From nobody Fri Feb 24 01:09: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 8EFAC129653; Fri, 24 Feb 2017 01:08:55 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 YMTTxDPWB_Vk; Fri, 24 Feb 2017 01:08:51 -0800 (PST) Received: from BLU004-OMC4S35.hotmail.com (blu004-omc4s35.hotmail.com [65.55.111.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2095812964B; Fri, 24 Feb 2017 01:08:51 -0800 (PST) Received: from NAM04-SN1-obe.outbound.protection.outlook.com ([65.55.111.135]) by BLU004-OMC4S35.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Fri, 24 Feb 2017 01:08:50 -0800 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=tvPejQ9ueDVz6O8UoCbDyJi2lHS71Z8YmvAQKZqcNUk=; b=J0UdNb5N0kwjKNWTuyrbNPxeH+/0Ekq5riQi0GT1MTJU6xIFkrcEKhyJzZoB7vMeN/vVn8EvM22uBpJHRYodcP/+fwj/shSy8IDIAXYdn6JhDsnPILyntu0eNKvXDKmQRrMBRFoJTGF7z9fe+q6scxCcU/P2/6a2YykxfK+STBz0Da7awG9CCnzHbBHPtsBEBNU/BOP7wxAsnATivj64Yc6LBGtxmBGz9qwrrEKJTlo8AeUmLmAybez68jHQb3CjTm2y/EmBbyeh7/xKqEUYU5OicdJ5uhe2WMbrDuxYetpaIyEYkTiOwtHd7DJF+NvzebIol5ELbEXzmk9OGjcMtg== Received: from BN3NAM04FT006.eop-NAM04.prod.protection.outlook.com (10.152.92.57) by BN3NAM04HT005.eop-NAM04.prod.protection.outlook.com (10.152.92.94) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.904.16; Fri, 24 Feb 2017 09:08:49 +0000 Received: from DM3PR13MB0604.namprd13.prod.outlook.com (10.152.92.55) by BN3NAM04FT006.mail.protection.outlook.com (10.152.92.96) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.10 via Frontend Transport; Fri, 24 Feb 2017 09:08:48 +0000 Received: from DM3PR13MB0604.namprd13.prod.outlook.com ([10.164.8.150]) by DM3PR13MB0604.namprd13.prod.outlook.com ([10.164.8.150]) with mapi id 15.01.0933.011; Fri, 24 Feb 2017 09:08:48 +0000 From: Shitanshu Shah To: David Black , "tsv-art@ietf.org" Thread-Topic: Review of draft-ietf-idr-sla-exchange-10 Thread-Index: AQHSjJJLT08h8arb7kKXAYa1wCM/2KF32nBg Date: Fri, 24 Feb 2017 09:08:48 +0000 Message-ID: References: <148771630812.19122.17152051080250251501.idtracker@ietfa.amsl.com> In-Reply-To: <148771630812.19122.17152051080250251501.idtracker@ietfa.amsl.com> 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=hotmail.com; x-incomingtopheadermarker: OriginalChecksum:9A064EEAB07F54851A715F2F74E80C8DA0B4B3A606E74B648E4C47CC0F7FA35E; UpperCasedChecksum:3AFC029FA63F8C251377EF6B4D9961CBDE7906AD010C7AC060E89BA24FC9D54B; SizeAsReceived:7964; Count:40 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [pjjwzSAqV0lvBrTqXOxXZTIutsVq7otw] x-incomingheadercount: 40 x-eopattributedmessage: 0 x-microsoft-exchange-diagnostics: 1; BN3NAM04HT005; 5:pGuyYfRta1iA36U6LbghAaeKU+MnGR4onIExy2CGA+hGw1kIZIOIcgr+jfQA7UcRbmCtNPk0bhCKx5u/PrhMxYHu6HlG6iYI3DMrmLO2SSQ6A1aJOUh1IljomLLrzwvZrdWUqkCma46K394McWsm3DR8nBwUk4b8zelNwkZbIgY=; 24:A1ZXrOeU4daX4Sg/o1inuiZn1iA30pTE/tRZsTgLrBwCrPzCnUzr3+98tOvaFcP/hmKL/Ym8rBbi+2gfG8fP0EFzTCGUkxvI+vCJpvItE5A=; 7:JrJ3qpRhwipUQiJ0KEgjiebM870X4mWembTDcQGLE1Zemt4/EOtvnpfpAouo4KuuOn2vIX+HeUuG+k0HQnXczBsOsGxRwj3M3AuDgxZvNYGKVqtmp6Q7kgi7Q4oG2jgCXIfYt1UEdGsxZXJz1Ioa+3Lj0lWz1um7JkZPSLgeuCxXwuBnt7v43pwwxj6kixZXkq6hYjKq/MKmLEqZdSDDOp1dAEdKpGm2Olaro6xFCQY8xu6YYOXVHLhrLt9GZA+obMjPNtBEvJYwQPdgtc4nMBZ3/zldEK4RQw25G8+PP4TcdSU7RVduKMHzSerk8PuF x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(10019020)(98900012); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3NAM04HT005; H:DM3PR13MB0604.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: bd0fd79a-0342-4c12-8df1-08d45c94be37 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(1601125254)(1603101373)(1701031045); SRVR:BN3NAM04HT005; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015087)(444000031); SRVR:BN3NAM04HT005; BCL:0; PCL:0; RULEID:; SRVR:BN3NAM04HT005; x-forefront-prvs: 0228DDDDD7 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM3PR13MB0604160394059613AD0331AFE5520DM3PR13MB0604namp_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2017 09:08:48.1372 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3NAM04HT005 X-OriginalArrivalTime: 24 Feb 2017 09:08:50.0294 (UTC) FILETIME=[9CFB5960:01D28E7D] Archived-At: Cc: "idr@ietf.org" , "draft-ietf-idr-sla-exchange.all@ietf.org" , "ietf@ietf.org" Subject: Re: [Idr] Review of draft-ietf-idr-sla-exchange-10 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 09:08:55 -0000 --_000_DM3PR13MB0604160394059613AD0331AFE5520DM3PR13MB0604namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi David, Thank you for taking time for the review.. Please find our response inline ##svshah and [Med] Regards, Shitanshu ________________________________ From: David Black Sent: Tuesday, February 21, 2017 3:31 PM To: tsv-art@ietf.org Cc: idr@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; ietf@ietf.org Subject: Review of draft-ietf-idr-sla-exchange-10 Reviewer: David Black Review result: Not Ready I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. When done at the time of IETF Last Call, the authors should consider this review together with any other last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. Document: draft-ietf-idr-sla-10 Reviewer: David Black Review Date: February 21, 2017 Review result: Not Ready This is an early TSV-ART review of a working group draft, requested by the IDR Working Group. This draft defines an extension to BGP to allow exchange of traffic handling parameters (e.g., configured rates, burst sizes, drop thresholds). While this is a useful area of technology to standardize across network operators, this draft has significant problems, and parts of it could use some serious rethought. This reviewer has discussed small portions of this draft with some of the authors in the past, but this is his first comprehensive reading and review of the draft. Major Issues: [1] The draft is misnamed. This is not an SLA (Service Level Agreement) draft - it's a TCA (Traffic Conditioning Agreement) draft - see the definition of TCA in RFC 2475. This draft should start from that definition and generalize the applicability of TCA beyond Diffserv. Large areas of SLA content are not covered by this draft - for more details, see the Wikipedia article on SLA: https://en.wikipedia.org/wiki/Service-level_agreement . ##svshah, sure, we can change the term to TCA (Traffic Conditioning Agreeme= nt), which fairly represents intention in the draft, if there is no otherwi= se comment from the working group. [2] Section 3.3.2.1's reuse of the TSpec construct from RFC 2115 to specify a token bucket is a good idea, but it's not a good idea to respecify that construct in terms of L2 (link-layer, e.g., Ethernet) octets, as the RFC 2115 TSpec is specified in terms of IP octets. This change to specification in terms of L2 octets results in needing the L2_OVERHEAD TLV to cope with the possible differences in L2 (link) framing overhead at sender and receiver of this information. The TSpec should be respecified at the IP layer, with L2 framing overhead left to the Producer and Consumer to factor into their calculations based on each's direct knowledge of L2 functionality and configuration in the local AS. That ought to enable elimination of the L2_OVERHEAD TLV, thereby reducing complexity. ##svshah, the purpose for advertising L2 overhead, from the Producer to the= Consumer, is to make sure traffic is well conditioned, at the egress of th= e Consumer, to avoid possible indiscriminate drops at the ingress of the Pr= oducer. In another words, the Producer is telling the Consumer to ignore it= s own link level overhead, instead use Producer's provided link level overh= ead while running frames through QoS functions (this is relevant in use-cas= es where l2 overhead of the egress link on Consumer and of ingress link on = the Producer are of different size, e.g., in the vpn/tunnel connection betw= een two peer nodes which physically may be multiple hops away). I understand your comments regarding re-using TSpec without any modificatio= n. Do you agree with the use-case of l2 differences? If yes, any suggestion= how to accommodate that? [3] A token bucket should have two rate-related marking parameters based on its token fill rate, i.e., min-rate, not the four rate-related marking parameters in this draft. The max-rate parameters in sections 3.3.2.5-6 ought to be specified against a second token bucket. In addition, the handling precedence algorithm in section 3.3.2.7 is an overly complex way to specify the relationship of two token buckets. All of this is even more important, because max-rate, as defined in RFC 2115, is only applicable to bursting - that max-rate for bursting often turns out to be an interface line rate, which is not generally useful for the traffic provisioning purposes of this draft. ##svshah, what you describe below conceptually very much makes sense and th= at is what we attempt to achieve. What is unclear though how to capture tha= t using TSpec definition specified in RFC2215. Since that TSpec definition = has both minimum-rate and maximum-rate, but no in/out profile marking param= eters. Is your proposal below to define two TSpecs using the same definition from = RFC2215? Wouldn't in that case we have min/max specified twice? min/max in = each TSpec? and thus confusing to represent one min and one max through two= TSpecs? The following should be done instead: - Define TSpecs for two token buckets, a primary/committed token bucket and a secondary/peak token bucket that MUST be nested, i.e.= , traffic that is in-profile for the secondary/peak token bucket is a= lways in-profile for the primary/committed token bucket. Some of= the details of how to specify this are subtle, see RFC 2698 for a worke= d example. Use of a secondary/peak token bucket requires use of the pr= imary/ committed token bucket, but a primary/committed token bucke= t can be used without a secondary/peak token bucket. - For a single token bucket, define two handling TLVs, Committed (i= n profile) and Excess (out of profile). - For two token buckets, define three handling TLVs, Committed (in profile for both token buckets), Peak (out of profile for primary/committed = token bucket, but in profile for secondary/peak token bucket) and Excess (out of= profile for both token buckets). NB: Could use Green/Yellow/Red terms instead of Committed/Peak/Excess terms. [4] The drop threshold TLV in section 3.3.2.8 is not specified sufficiently to be implemented interoperably. For example, I don't understand what an implementation is supposed to do when it receives 3 drop thresholds. ##svshah, It is around the semantics of a single queue with a different thr= eshold for a set of code-points, where packet for a specific code-point is = to be tail dropped if overall queue-depth hits code-point specific threshol= d at the arrival of that packet. We will add appropriate clarification for this semantics. [5] The relative priority TLV in section 3.3.2.9 has the same insufficient specification problem as the drop threshold TLV, compounded by a functional incompleteness problem - if the recipient is using a weighted packet transmission scheduler (e.g., WRR), priorities cannot be used to configure that scheduler. Hence, some specification of weights and scheduling algorithms that use weights needs to be added. ##svshah, Sure. Is following clarification okay? (some of the wordings take= n from RFC2598) " A higher priority class of traffic to be served without pre-empted by lower= priority class of traffic for more than a packet time at the configured ra= te. In the system that implements WRR, the use of relative priority may get res= tricted where a single queue may be used for a higher priority traffic clas= s where that queue is configured for the full share of the output bandwidt= h. " [6] I have no idea what the sub-traffic classes TLV in section 3.3.2.10 is supposed to do, as that TLV is specified based on "Traffic Class TLVs" which is an undefined term in this draft (e.g., that term is not used outside of section 3.3.2.10. ##svshah, They are to facilitate hierarchy. A specific Traffic Class, can f= urther be divided in a multiple subset of Traffic Classes, with their own = Traffic Class Elements and Traffic Class Services. Will correct the wording to remove your this specific concern. [7] This draft's QoS contents need to be functionally aligned with work-in-progress on YANG QoS models, in order to provide some assurance that that this draft is implementable for actual network switch/router data paths. The current acknowledgement of the existence of YANG, NETCONF and RESTConf at the end of Section 1 does not suffice. ##svshah, While eventually "Traffic Conditioning Agreement" should be trans= lated to the actual forwarding qos policy on any vendor specific device, TC= A exchange largely carries concepts/semantics that is either standard based= or well understood. While we are not aware of any working group document of QoS Yang Model, we = think that concepts of Traffic Conditioning should be easily adaptable to = any QoS Yang Models since they also have to be defined to support those con= cepts. [8] There are significant complexity and correctness problems caused by the option to not specify the Source AS - e.g., Section 3.2 defines an SLA ID as an "identifier which is unique in the scope of Source AS" which is meaningless if there is no Source AS. It would be simpler to always specify Source AS, even in the point-to-point case. ##svshah, okay. Ron Bonica also suggested same in his review earlier. We ha= d chosen a path of optional Source AS to simplify implementations in cases.= Given specification of Source AS always is more clearer in multiple feed-b= ack we have gotten so far, we can modify the specification to incorporate t= hat over the simplicity of implementation for certain cases. [9] In section 3.2, the "intended for the peer receiver of the BGP UPDATE message" text in the specification of bit 0 of the SLA Subtype flags is unclear. I suspect that this is intended to differentiate the two usages described in sections 4.1.1 (Point-to-Point) and 4.1.2 (Multiple Hops), in which case the parenthesized terms (or similar terminology) should be used with cross-references to those two sections. ##svshah, sure will make necessary changes, also in the context of earlier = comment. [10] There needs to be a coherent discussion in one place about how SLA advertisement, update and withdrawal work. A single ADVERTISE method may suffice on the wire, but the details on how initial advertisement, subsequent advertisement (update) and withdrawal work need to be specified in one place. The third paragraph of Section 4 is a start on this material, but it's too terse; [Med] That text is terse because we are reusing the BGP machinery for adver= tising/withdrawing; we only augment it with triggers that are linked to the= SLA information. A new SLA will lead to an update message with ADVERTISE, = an update of an existing SLA will trigger an update message. We do think th= is information is already present in the document. it should be expanded into its own subsection, and moved earlier to come before the ADVERTISE method in Section 3.2. This text from Section 3.2 should be moved into that new subsection and likewise expanded: [Med] Another option is to move it Section 4. From our standpoint, we do th= ink it is straightforward to describe the behavior once the attributes form= at are defined. If an advertised SLA ID is different from earlier advertised one, for the same prefix and from the same Source AS, indicates Source AS is advertising new SLA Content to replace the previous one advertised with the same SLA ID. In addition, I wonder whether functionality should be added to allow withdrawal of an advertisement by specifying its SLA ID, although that was not part of the original design. [Med] The reason we didn=92t adopted that design is that we don=92t want to= make assumptions on which data the remote peer will be used for enforcing = local actions and also because of this text: The SLA ID applies to aggregate traffic to prefixes for a given AFI/SAFI that share the same Source AS and SLA ID. [11] Notions of context for interpretation of all the IPFIX parameters in 3.3.1 need to be added, e.g.: - The first three parameters (DSCP, MPLS EXP field in top label, 802.1q priority) can and do vary on a link-by-link or LSP-by-LSP basis along a t= raffic's network path. - The IP address parameters are rather likely to be VPN-specific wh= en there's more than one BGP/MPLS VPN that spans or transits the ASs involv= ed. - The transport port parameters need specification of which transpo= rt header and where it is located (e.g., for TCP traffic carried by in VXLAN, is t= his the inner TCP header or the outer UDP header in VXLAN). There are probably simple approaches to specifying context in all cases, but that context does need to be specified ... in all cases. [Med] We dind=92t include a context field because we thought that the defin= ition of the IPFIX attributes is sufficient by itself, but if you do think = it is helpful to have such information, we can update the table. [12] The security considerations (section 10) are severely incomplete and insufficient: - Discussion of possible abuse of this BGP option for denial-of-service and theft-of-service, needs to be added, including possible countermeasures and mitigations. [Med] This attack vector is not specific to this attribute; this is valid f= or BGP in general. - This sentence at the end of the second paragraph in Section 10 is content-free: It is NOT RECOMMENDED to enable this attribute at the scale of the Internet unless if means to prevent leaking sensitive information are enforced. What exactly is an implementer or admin supposed to do? [Med] An example of what an admin needs to check if this information can be= sent to a given peer or not. Some of the content of the attribute contains= some sensitive information such as contract Id, classes, etc. How does one figure out whether an implementation or deployment is "at = the scale of the Internet" ?? [Med] The idea here is to avoid leaking such data in to the global routing = table. Only entitled peers need receive such information with controlled sc= ope. - The next to last paragraph in section 10 is almost content-free, = as it leaves decisions on implementation and deployment of key security functionality as "an exercise for the reader" - that's not acceptable. [Med] I guess you are referring to the following text. Validation checks ar= e really deployment-specific. The text calls out the issue and recommends a= n action; how to translate this action into detailed actions is realty loca= l to a domain The attribute may be advertised by a misbehaving node to communicate SLA parameters that are not aligned with the SLA agreements. Though the enforcement of SLA parameters is outside the scope of this document, it is RECOMMENDED that the SLA Consumer to enforce a set of validation checks before translating the SLA parameters conveyed in the QoS attributes into provisioning actions. Such validations MAY rely on SLA parameters like the origin AS or SLA ID, like generating SLA ID using pseudo-random schemes [RFC4086]. - Last, but not least, the final paragraph in Section 10 is a joke that will be lost on a security directorate reviewer - to understand = why, see Section 2 of RFC 6919, and take note of the publication dat= e of RFC 6919. ------------------------ Having noted a dozen major issues, I'll end the review here for now, as I believe a serious revision of the draft is called for, which would be a better starting point to review for minor issues and editorial items. -------------------------------------------------------- David L. Black, Distinguished Engineer Dell EMC, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 Cell: +1 (978) 394-7754 David.Black@dell.com <=3D=3D=3D NEW =3D=3D=3D -------------------------------------------------------- --_000_DM3PR13MB0604160394059613AD0331AFE5520DM3PR13MB0604namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable


Hi David,


Thank you for taking time for the review..


Please find our response inline ##svshah and [Med]


Regards,
Shitanshu

From: David Black <dav= id.black@emc.com>
Sent: Tuesday, February 21, 2017 3:31 PM
To: tsv-art@ietf.org
Cc: idr@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; ietf@iet= f.org
Subject: Review of draft-ietf-idr-sla-exchange-10
 
Re= viewer: David Black
Review result: Not Ready

I've reviewed this document as part of the transport area
directorate's ongoing effort to review key IETF documents. These
comments were written primarily for the transport area directors, but
are copied to the document's authors for their information and to
allow them to address any issues raised. When done at the time of IETF
Last Call, the authors should consider this review together with any
other last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

Document: draft-ietf-idr-sla-10
Reviewer: David Black
Review Date: February 21, 2017

Review result: Not Ready

This is an early TSV-ART review of a working group draft, requested by
the IDR Working Group.

This draft defines an extension to BGP to allow exchange of traffic
handling parameters (e.g., configured rates, burst sizes, drop
thresholds).  While this is a useful area of technology to standardize=
across network operators, this draft has significant problems, and
parts of it could use some serious rethought.

This reviewer has discussed small portions of this draft with some of
the authors in the past, but this is his first comprehensive reading
and review of the draft.

Major Issues:

[1] The draft is misnamed.  This is not an SLA (Service Level
Agreement) draft - it's a TCA (Traffic Conditioning Agreement) draft -
see the definition of TCA in RFC 2475.  This draft should start from that definition and generalize the applicability of TCA beyond
Diffserv.  Large areas of SLA content are not covered by this draft -<= br> for more details, see the Wikipedia article on SLA:
https://en.wikipedia.org/wiki/Service-lev= el_agreement .

##svsha= h, sure, we can change the term to TCA (Traffic Conditioning Agreement), wh= ich fairly represents intention in the draft, if there is no otherwise comm= ent from the working group.




[2] Section 3.3.2.1's reuse of the TSpec construct from RFC 2115 to
specify a token bucket is a good idea, but it's not a good idea to
respecify that construct in terms of L2 (link-layer, e.g., Ethernet)
octets, as the RFC 2115 TSpec is specified in terms of IP octets.
This change to specification in terms of L2 octets results in needing
the L2_OVERHEAD TLV to cope with the possible differences in L2 (link)
framing overhead at sender and receiver of this information.  The
TSpec should be respecified at the IP layer, with L2 framing overhead
left to the Producer and Consumer to factor into their calculations
based on each's direct knowledge of L2 functionality and configuration
in the local AS.  That ought to enable elimination of the L2_OVERHEAD<= br> TLV, thereby reducing complexity.

##svshah, the purpose for advertising L2 overhead, from the Producer to the= Consumer, is to make sure traffic is well conditioned, at the egress = of the Consumer, to avoid possible indiscriminate drops at the ingress= of the Producer. In another words, the Producer is telling the Consumer to ignore its own link level overhead, instea= d use Producer's provided link level overhead while running frames through = QoS functions (this is relevant in use-cases where l2 overhead of the&= nbsp;egress link on Consumer and of ingress link on the Producer are of different size, e.g., in the vpn/tunnel connec= tion between two peer nodes which physically may be multiple hops away= ).
I understand your comments regarding = re-using TSpec without any modification. Do you agree with the use-case of l2 differences? If yes, a= ny suggestion how to accommodate that?



[3] A token bucket should have two rate-related marking parameters
based on its token fill rate, i.e., min-rate, not the four
rate-related marking parameters in this draft.  The max-rate
parameters in sections 3.3.2.5-6 ought to be specified against a
second token bucket.  In addition, the handling precedence algorithm in section 3.3.2.7 is an overly complex way to specify the
relationship of two token buckets.  All of this is even more
important, because max-rate, as defined in RFC 2115, is only
applicable to bursting - that max-rate for bursting often turns out to
be an interface line rate, which is not generally useful for the
traffic provisioning purposes of this draft.
##svshah, what you describe below conceptually very much makes sense and th= at is what we attempt to achieve. What is unclear though how to capture tha= t using TSpec definition specified in RFC2215. Since that TSpec definition = has both minimum-rate and maximum-rate, but no in/out profile marking parameters.

Is your proposal below to define two TSpecs using the same definition = from RFC2215? Wouldn't in that case we have min/max specified twice? min/ma= x in each TSpec? and thus confusing to represent one min and one max throug= h two TSpecs?




The following should be done instead:
        - Define TSpecs for two token bu= ckets, a primary/committed token
bucket
            &nb= sp;   and a secondary/peak token bucket that MUST be nested, i.e.= ,
traffic
            &nb= sp;   that is in-profile for the secondary/peak token bucket is a= lways
            &nb= sp;   in-profile for the primary/committed token bucket.  So= me of the
details
            &nb= sp;   of how to specify this are subtle, see RFC 2698 for a worke= d
example.
            &nb= sp;   Use of a secondary/peak token bucket requires use of the pr= imary/
            &nb= sp;   committed token bucket, but a primary/committed token bucke= t can be
used
            &nb= sp;   without a secondary/peak token bucket.
        - For a single token bucket, def= ine two handling TLVs, Committed (in
profile) and
            &nb= sp;   Excess (out of profile).
        - For two token buckets, define = three handling TLVs, Committed (in
profile for both
            &nb= sp;   token buckets), Peak (out of profile for primary/committed = token
bucket, but in
            &nb= sp;   profile for secondary/peak token bucket) and Excess (out of= profile
for both
            &nb= sp;   token buckets).
NB: Could use Green/Yellow/Red terms instead of Committed/Peak/Excess
terms.

[4] The drop threshold TLV in section 3.3.2.8 is not specified
sufficiently to be implemented interoperably.  For example, I don't understand what an implementation is supposed to do when it receives 3
drop thresholds.

##svshah, It is around the semantics of a single queue with a dif= ferent threshold for a set of code-points, where packet for a specific code= -point is to be tail dropped if overall queue-depth hits code-point specifi= c threshold at the arrival of that packet.
We will add appropriate clarification= for this semantics.



[5] The relative priority TLV in section 3.3.2.9 has the same
insufficient specification problem as the drop threshold TLV,
compounded by a functional incompleteness problem - if the recipient
is using a weighted packet transmission scheduler (e.g., WRR),
priorities cannot be used to configure that scheduler.  Hence, some specification of weights and scheduling algorithms that use weights
needs to be added.

##svshah, Sure. Is following clarification okay? (some of the wordings take= n from RFC2598)

"
A higher priority class of traffic to be served without pre-empted by = lower priority class of traffic for more than a packet time at th= e configured rate.

In the system that implements WRR, the use of relative priority may get res= tricted where a single queue may be used for a higher priority traffic= class where that queue  is configured for the full share of the outpu= t bandwidth.
"




[6] I have no idea what the sub-traffic classes TLV in section
3.3.2.10 is supposed to do, as that TLV is specified based on "Traffic=
Class TLVs" which is an undefined term in this draft (e.g., that term<= br> is not used outside of section 3.3.2.10.

##svshah, They are to facilitate hierarchy. A specific Traffic Class, can f= urther be divided in a multiple  subset of Traffic Classes, with = their own Traffic Class Elements and Traffic Class Services.

Will correct the wording to remove your this specific concern.




[7] This draft's QoS contents need to be functionally aligned with
work-in-progress on YANG QoS models, in order to provide some
assurance that that this draft is implementable for actual network
switch/router data paths.  The current acknowledgement of the
existence of YANG, NETCONF and RESTConf at the end of Section 1 does
not suffice.

##svshah, While eventually "Traffic Conditioning Agreement" = should be translated to the actual forwarding qos policy on any vendor spec= ific device, TCA exchange largely carries concepts/semantics that is either= standard based or well understood.

While we are not aware of any working group document of QoS Yang Model, we = think that  concepts of Traffic Conditioning should be easily adaptabl= e to any QoS Yang Models since they also have to be defined to support thos= e concepts.





[8] There are significant complexity and correctness problems caused
by the option to not specify the Source AS - e.g., Section 3.2 defines
an SLA ID as an "identifier which is unique in the scope of Source AS&= quot;
which is meaningless if there is no Source AS.  It would be simpler to=
always specify Source AS, even in the point-to-point case.

##svs= hah, okay. Ron Bonica also suggested same in his review earlier. We had cho= sen a path of optional Source AS to simplify implementations in cases. Given specification of Source AS a= lways is more clearer in multiple feed-back we have gotten so far, we can m= odify the specification to incorporate that over the simplicity of implemen= tation for certain cases.




[9] In section 3.2, the "intended for the peer receiv= er of the BGP
UPDATE message" text in the specification of bit 0 of= the SLA Subtype
flags is unclear.  I suspect that this is intended to= differentiate
the two usages described in sections 4.1.1 (Point-to-Point= ) and 4.1.2
(Multiple Hops), in which case the parenthesized terms (or= similar
terminology) should be used with cross-references to those= two
sections.

##svshah, sure will make necessary changes, also in the context of earlier = comment.


[10] There needs to be a coherent discussion in one place = about how
SLA advertisement, update and withdrawal work.  A sin= gle ADVERTISE
method may suffice on the wire, but the details on how ini= tial
advertisement, subsequent advertisement (update) and withd= rawal work
need to be specified in one place.  The third paragra= ph of Section 4
is a start on this material, but it's too terse; 

[Med= ] That text is terse because we are reusing the BGP machinery for advertisi= ng/withdrawing; we only augment it with triggers that are linked to the SLA information. A new SLA will lead to an= update message with ADVERTISE, an update of an existing SLA will trigger a= n update message. We do think this information is already present in the do= cument.  

it should be expanded
into its own subsection, and moved earlier to come before = the
ADVERTISE method in Section 3.2.  This text from Sect= ion 3.2 should be
moved into that new subsection and likewise expanded:

[Med] Another option is to mo= ve it Section 4. From our standpoint, we do think it is straightforward to = describe the behavior once the attributes format are defined. 

 = ;     If an advertised SLA ID is different from earlier= advertised
one,
      for the same prefix and fro= m the same Source AS, indicates
Source
      AS is advertising new SLA C= ontent to replace the previous one
      advertised with the same SL= A ID.

In addition, I wonder whether functionality should be adde= d to allow
withdrawal of an advertisement by specifying its SLA ID, a= lthough that
was not part of the original design.

[Med] The reason we didn=92t adopted that design i= s that we don=92t want to make assumptions on which data the remote peer wi= ll be used for enforcing local actions and also because of this text:

      The SLA ID applies to aggregate t= raffic to prefixes for a given

      AFI/SAFI that share the same Sour= ce AS and SLA ID.



[11] Notions of context for interpretation of all the IPFI= X parameters
in 3.3.1 need to be added, e.g.:
        - The first thr= ee parameters (DSCP, MPLS EXP field in top label,
802.1q priority) can
         &nbs= p;      and do vary on a link-by-link or LSP-by-LS= P basis along a traffic's
network path.
        - The IP addres= s parameters are rather likely to be VPN-specific when
there's more
         &nbs= p;      than one BGP/MPLS VPN that spans or transi= ts the ASs involved.
        - The transport= port parameters need specification of which transport
header and where it
         &nbs= p;      is located (e.g., for TCP traffic carried = by in VXLAN, is this the
inner TCP header
         &nbs= p;      or the outer UDP header in VXLAN).<= br> There are probably simple approaches to specifying context= in all
cases, but that context does need to be specified ... in a= ll cases.

[Med] We dind=92t include a c= ontext field because we thought that the definition of the IPFIX attributes= is sufficient by itself, but if you do think it is helpful to have such information, we can update the table.<= /span>


[12] The security considerations (section 10) are severely= incomplete
and insufficient:

        - Discussion of= possible abuse of this BGP option for
denial-of-service and theft-of-service,
         &nbs= p;      needs to be added, including possible coun= termeasures and
mitigations.

[Med] This attack vector is n= ot specific to this attribute; this is valid for BGP in general.


        - This sentence= at the end of the second paragraph in Section 10 is
content-free:

         &nbs= p;         It is NOT RECOMMENDED to= enable this attribute at the
         &nbs= p;         scale of the Internet un= less if means to prevent leaking
sensitive
         &nbs= p;         information are enforced= .

         &nbs= p;      What exactly is an implementer or admin su= pposed to do? 

[Med= ] An example of what an admin needs to check if this information can be sen= t to a given peer or not. Some of the content of the attribute contains some sensitive information such as contr= act Id, classes, etc.
How does
one
         &nbs= p;      figure out whether an implementation or de= ployment is  "at the
scale
         &nbs= p;      of the Internet" ??

[Med= ] The idea here is to avoid leaking such data in to the global routing tabl= e. Only entitled peers need receive such information with controlled scope.

     &nb= sp;  - The next to last paragraph in section 10 is almost content-free= , as
it leaves
         &nbs= p;      decisions on implementation and deployment= of key security
functionality as
         &nbs= p;      "an exercise for the reader" - t= hat's not acceptable.

[Med] I guess you are referring to the following t= ext. Validation checks are really deployment-specific. The text calls out t= he issue and recommends an action; how to translate this action into detailed actions is realty local to a domain

   The attribute may be adver=
tised by a misbehaving node to communicate
   SLA parameters that are no=
t aligned with the SLA agreements.  Though
   the enforcement of SLA par=
ameters is outside the scope of this
   document, it is RECOMMENDE=
D that the SLA Consumer to enforce a set of
   validation checks before t=
ranslating the SLA parameters conveyed in
   the QoS attributes into pr=
ovisioning actions.  Such validations MAY
   rely on SLA parameters lik=
e the origin AS or SLA ID, like generating
   SLA ID using pseudo-random=
 schemes [RFC4086].



        - Last, but not= least, the final paragraph in Section 10 is a joke
that will
         &nbs= p;      be lost on a security directorate reviewer= - to understand why, see
         &nbs= p;      Section 2 of RFC 6919, and take note of th= e publication date of RFC
6919.

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

Having noted a dozen major issues, I'll end the review her= e for now,
as I believe a serious revision of the draft is called for= , which
would be a better starting point to review for minor issue= s and
editorial items.

--------------------------------------------------------
David L. Black, Distinguished Engineer
Dell EMC, 176 South St., Hopkinton, MA  01748<= br> +1 (508) 293-7953     Cell: +1= (978) 394-7754
David.Black@dell.com  <=3D=3D=3D NEW =3D=3D=3D
--------------------------------------------------------



--_000_DM3PR13MB0604160394059613AD0331AFE5520DM3PR13MB0604namp_-- From nobody Fri Feb 24 01:31: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 8BC64129442; Fri, 24 Feb 2017 01:31:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 pmWGAmsb9q2C; Fri, 24 Feb 2017 01:31:40 -0800 (PST) Received: from BAY004-OMC3S4.hotmail.com (bay004-omc3s4.hotmail.com [65.54.190.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0E6E126FDC; Fri, 24 Feb 2017 01:31:40 -0800 (PST) Received: from NAM04-BN3-obe.outbound.protection.outlook.com ([65.54.190.188]) by BAY004-OMC3S4.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Fri, 24 Feb 2017 01:31:40 -0800 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=69hTC700muGR4qb4auL7rhnejicMu1uY29DIKk3eL3Y=; b=DPphM/u4KU5zaMave8ZUn+tXdgzDEo2V82h5G/m3LcRXUCtrXr1W9RpQ6z95QiYJwpvAlIiHua9cBHYs7NAtuxbVeQPyoG61z1oiEEtRh0HlSuYNU4EabVYk6d3sF6BjtQV20+HSmaAjYgiuaDKYl0tVZisZo4rCzRwTbocEecO4VqHhFE6EHjSdcMucAb+kmVYGh/VWcpyCK1YZBeI7HifYB01pIyIK4tp35/pL6m5mAbcBafPooqXpJhTsDkTe/H5k+XUqZBnSF99IJzx4bcEJLlLu3T7to99ZkamSmedI3dKoK94JiiPyNP5Tq3cMif4x0414hxyos5bzD1l+OA== Received: from SN1NAM04FT045.eop-NAM04.prod.protection.outlook.com (10.152.88.59) by SN1NAM04HT114.eop-NAM04.prod.protection.outlook.com (10.152.88.213) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.10; Fri, 24 Feb 2017 09:31:38 +0000 Received: from DM3PR13MB0604.namprd13.prod.outlook.com (10.152.88.58) by SN1NAM04FT045.mail.protection.outlook.com (10.152.89.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.10 via Frontend Transport; Fri, 24 Feb 2017 09:31:38 +0000 Received: from DM3PR13MB0604.namprd13.prod.outlook.com ([10.164.8.150]) by DM3PR13MB0604.namprd13.prod.outlook.com ([10.164.8.150]) with mapi id 15.01.0933.011; Fri, 24 Feb 2017 09:31:38 +0000 From: Shitanshu Shah To: Ron Bonica , "rtg-dir@ietf.org" , "draft-ietf-idr-sla-exchange.all@ietf.org" , "idr@ietf.org" Thread-Topic: RtgDir review: draft-ietf-idr-sla-exchange-10 Thread-Index: AdKIcLCEU+uutt39QyCrZCwOKAXyLQAcLKCoAUVZnUAAIdzQ0g== Date: Fri, 24 Feb 2017 09:31:38 +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: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=hotmail.com; x-incomingtopheadermarker: OriginalChecksum:CEA9F0CD31866D7401C7239B1C05EA69F31C007076C42836C430718318B16A67; UpperCasedChecksum:EB58E53E51818311443852746F8797EF9E9E6A76298FB3FA00CC75DB3F0B8470; SizeAsReceived:8156; Count:39 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [M5tmHFhUVc6FvwD5F4QQLTly54o6rfgq] x-incomingheadercount: 39 x-eopattributedmessage: 0 x-microsoft-exchange-diagnostics: 1; SN1NAM04HT114; 5:SKWAmEUle5y8smfE4UK8EWM5j7HhL/aICVvWKDqv/a4pLulMxlz6QxZQfQtfvOpuW5IWHrenPsQDIjxe1m1loeYACPj4OPtME8HbMzjc3bZ5cY2swppwE5qGMRQEP/ufCtlBypJArY3UBwbuuVKoog==; 24:oo1W5UAMcul1Li118YW+zmi0VJQZD+YLJXEwluN9hOmTsnPIqQtrmfTlgEbjqnhVRMVYItn6MNLpIy4B3WI7nZ3cbQrX6vGrDLQAPQL8RSw=; 7:gdTfxmm7v21hJ2O7htTTaKYcQld7ur2yIbomX2LQ6snjQSABaMJS6nfRP2AdAdwcBn0Vd/ITPCsN9kKnL0stze4bsKiRVwsTHlNsMhB42swfnGeZ5H8d6xfyoD3WjPLBFT+lhRjWJvMQTHqTlJE9SSPmpTMwu4xYnXH9pWfV8pFZH4CIisOAyhOFoI/O7JZ7am2CX73FmDswFwgBVCbFUOQqIcqHRnFAX2Syx35kVGYdFa/1m6wGnp/1uLdbfUnBu6HVOP9WOnQEubcKHTOivaCeOX241ovt1Ji3poLMutQRLaf5jyJqoewsvTKT5tHW x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(10019020)(98900012); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1NAM04HT114; H:DM3PR13MB0604.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: 8e7919ca-c702-42ff-f44f-08d45c97ef0c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(1601125254)(1603101373)(1701031045); SRVR:SN1NAM04HT114; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015087)(444000031); SRVR:SN1NAM04HT114; BCL:0; PCL:0; RULEID:; SRVR:SN1NAM04HT114; x-forefront-prvs: 0228DDDDD7 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM3PR13MB060435809FFDF2373F4FE308E5520DM3PR13MB0604namp_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2017 09:31:38.5096 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM04HT114 X-OriginalArrivalTime: 24 Feb 2017 09:31:40.0509 (UTC) FILETIME=[CDB190D0:01D28E80] Archived-At: Subject: Re: [Idr] RtgDir review: draft-ietf-idr-sla-exchange-10 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 09:31:42 -0000 --_000_DM3PR13MB060435809FFDF2373F4FE308E5520DM3PR13MB0604namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ron, To break it down in two point response, 1) This draft is not changing how SLA is established at first place. The dr= aft is providing a method to convey this a priori established SLA to help r= educe lot of manual complexities and errors to admin. Thus given a knowledg= e of what SLA is established, in general devices should be capable to suppo= rt that established SLA. 2) If there still are any issues in implementing exchanged SLA in forwardin= g, we think they either are implementation specific or of temporary nature = where for example enough resources not available at any specific point of a= time. We feel that in current state of the draft, it can be largely useful in dep= loyments. One can imagine though even establishment of SLA also can be done via excha= nging it over bgp. However, negotiation of SLA does not have to be clubbed = with exchange of SLA. Negotiation of SLA is not in this scope. Regards, Shitanshu ________________________________ From: Ron Bonica Sent: Thursday, February 23, 2017 10:06 AM To: Shitanshu Shah; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.= org; idr@ietf.org Subject: RE: RtgDir review: draft-ietf-idr-sla-exchange-10 Hello, The draft is internally consistent. But given what is left out of scope, I = wonder if the new attributes will ever be widely deployed. = Ron This document might benefit from discussion of operational issues. I assume= that when a BGP listener learns a route with the SLA Exchange Attribute, i= t provisions class of service forwarding classes on interfaces. ##svshah, though this is one desired use of exchanging SLA content, the dra= ft focuses on transporting SLA content from the SLA Producer to the SLA Con= sumer. Processing of the QoS attribute content, at the SLA Consumer, is out= side the scope of this document. ##svshah, Let me know if you have a suggestion to make description clearer = in Section 1 and 2 to highlight this. I also assume that a) it takes time to provision class of service forwardin= g classes and b) the number of forwarding classes that can be provisioned a= re finite. What does the BGP listener do when the number of forwarding clas= ses requested exceeds its capacity to deliver? ##svshah, Since scope of the document is to transport SLA content from the = SLA Producer to the SLA Consumer, the document considers error handling in = the context of transporting data and thus any formating errors and semantic= s errors within that context. Any errors in the context of processing QoS a= ttribute content at the SLA Consumer is outside the scope of the document. --_000_DM3PR13MB060435809FFDF2373F4FE308E5520DM3PR13MB0604namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable


Hi Ron,


To break it down in two point response,


1) This draft is not changing how SLA is established at first place. The= draft is providing a method to convey this a priori established = SLA to help reduce lot of manual complexities and errors to admin. Thus giv= en a knowledge of what SLA is established, in general devices should be capable to support that established SLA.=



2) If there still are any issues in implementing exchanged SLA in forwar= ding, we think they either are implementation specific or of temporary= nature where for example enough resources not available at any specific po= int of a time.


We feel that in current state of the draft, it can be largely useful in = deployments.




One can imagine though even establishment of SLA also can be done v= ia exchanging it over bgp. However, negotiation of SLA does not have to be = clubbed with exchange of SLA. Negotiation of SLA is not in this scope.


Regards,
Shitanshu


From: Ron Bonica <rbonic= a@juniper.net>
Sent: Thursday, February 23, 2017 10:06 AM
To: Shitanshu Shah; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.al= l@ietf.org; idr@ietf.org
Subject: RE: RtgDir review: draft-ietf-idr-sla-exchange-10
 

Hello,

 

The draft is internally consistent. But given what is left= out of scope, I wonder if the new attributes will ever be widely deployed.=

 

         &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;       Ron

 

 


This document might benefit from discussion of operational issues. I assume= that when a BGP listener learns a route with the SLA Exchange Attribute, i= t provisions class of service forwarding classes on interfaces.

 

##svshah= , though this is one desired use of exchanging SLA content, the draft focus= es on transporting SLA content from the SLA Producer to the SLA Consumer. P= rocessing of the QoS attribute content, at the SLA Consumer, is outside the scope of this document.

 

##svshah= , Let me know if you have a suggestion to make description clearer in Secti= on 1 and 2 to highlight this.

 

 

I also assume that a) it takes time to provision class of se= rvice forwarding classes and b) the number of forwarding classes that can b= e provisioned are finite. What does the BGP listener do when the number of forwarding classes requested exceeds its ca= pacity to deliver? 

 

##svshah= , Since scope of the document is to transport SLA content from the SLA Prod= ucer to the SLA Consumer, the document considers error handling in the cont= ext of transporting data and thus any formating errors and semantics errors within that context. Any errors = in the context of processing QoS attribute content at the SLA Consumer is o= utside the scope of the document.



 

 

--_000_DM3PR13MB060435809FFDF2373F4FE308E5520DM3PR13MB0604namp_-- From nobody Fri Feb 24 07:54: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 AF2A11298C7; Fri, 24 Feb 2017 07:53:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.087 X-Spam-Level: X-Spam-Status: No, score=-4.087 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_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.887, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=s2obd2Iw; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=MGpd70zp Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id st_djehYaqLY; Fri, 24 Feb 2017 07:53:44 -0800 (PST) Received: from esa1.dell-outbound.iphmx.com (esa1.dell-outbound.iphmx.com [68.232.153.90]) (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 B01C9129890; Fri, 24 Feb 2017 07:53:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1487951531; x=1519487531; h=from:cc:to:subject:date:message-id:references: in-reply-to:mime-version; bh=5o9b3waqCwEE0g689d8vnQH6QwC+3jutlTclyuV8QDo=; b=s2obd2IwaHXk1BpTogSAgRWwMAodywsbVkQ2Il/SX+LuSQDlZboj8HHf xefCUoYOUZgpxKGse2IbMF7/8hBOECAy00LBaMM6Q1UgE2/rXmhoA2dRh WB8KX5lxdtn7LJrbjFu/0d0CPyZaTBem5Oenz/rtak+S+eBBFsbOqosOb M=; Received: from esa5.dell-outbound2.iphmx.com ([68.232.153.203]) by esa1.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Feb 2017 09:52:10 -0600 From: "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa5.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Feb 2017 21:53:25 +0600 Received: from maildlpprd01.lss.emc.com (maildlpprd01.lss.emc.com [10.253.24.33]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v1OFrWZW013675 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 24 Feb 2017 10:53:34 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com v1OFrWZW013675 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1487951614; bh=/ZNF07InB2ddXdy1s+lDIdLXjMc=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=MGpd70zpF4flAw3sMLX+GyvNJL7AEaCnPNjNKQR6CZrGw54QKkWXzuCdLULlfTHdP X6cGEaGPm7oNa3PIz43zNrs3Gd3RSqrZ4qZlOCx2diAOHfxNEQ02SHJ+n6X+bCpmTn wQtuzUB+U64fnmzpRCav/WYcuEVwadZoz9A7qHIE= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com v1OFrWZW013675 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd01.lss.emc.com (RSA Interceptor); Fri, 24 Feb 2017 10:52:04 -0500 Received: from MXHUB301.corp.emc.com (MXHUB301.corp.emc.com [10.146.3.27]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v1OFrJYp017478 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Fri, 24 Feb 2017 10:53:19 -0500 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB301.corp.emc.com ([10.146.3.27]) with mapi id 14.03.0266.001; Fri, 24 Feb 2017 10:53:18 -0500 To: Shitanshu Shah , "tsv-art@ietf.org" Thread-Topic: Review of draft-ietf-idr-sla-exchange-10 Thread-Index: AQHSjn2hotpFQg8pf0qPmuGxW7GZeaF4QrTw Date: Fri, 24 Feb 2017 15:53:17 +0000 Message-ID: References: <148771630812.19122.17152051080250251501.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.109] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949362F8C4510MX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "idr@ietf.org" , "Black, David" , "draft-ietf-idr-sla-exchange.all@ietf.org" , "ietf@ietf.org" Subject: Re: [Idr] Review of draft-ietf-idr-sla-exchange-10 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 15:53:53 -0000 --_000_CE03DB3D7B45C245BCA0D243277949362F8C4510MX307CL04corpem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable David> Inline ... Thanks, --David From: Shitanshu Shah [mailto:shitanshu_shah@hotmail.com] Sent: Friday, February 24, 2017 4:09 AM To: Black, David; tsv-art@ietf.org Cc: idr@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; ietf@ietf.org Subject: Re: Review of draft-ietf-idr-sla-exchange-10 Hi David, Thank you for taking time for the review.. Please find our response inline ##svshah and [Med] Regards, Shitanshu ________________________________ From: David Black > Sent: Tuesday, February 21, 2017 3:31 PM To: tsv-art@ietf.org Cc: idr@ietf.org; draft-ietf-idr-sla-exchange.all@ietf= .org; ietf@ietf.org Subject: Review of draft-ietf-idr-sla-exchange-10 Reviewer: David Black Review result: Not Ready I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. When done at the time of IETF Last Call, the authors should consider this review together with any other last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this r= eview. Document: draft-ietf-idr-sla-10 Reviewer: David Black Review Date: February 21, 2017 Review result: Not Ready This is an early TSV-ART review of a working group draft, requested by the IDR Working Group. This draft defines an extension to BGP to allow exchange of traffic handling parameters (e.g., configured rates, burst sizes, drop thresholds). While this is a useful area of technology to standardize across network operators, this draft has significant problems, and parts of it could use some serious rethought. This reviewer has discussed small portions of this draft with some of the authors in the past, but this is his first comprehensive reading and review of the draft. Major Issues: [1] The draft is misnamed. This is not an SLA (Service Level Agreement) draft - it's a TCA (Traffic Conditioning Agreement) draft - see the definition of TCA in RFC 2475. This draft should start from that definition and generalize the applicability of TCA beyond Diffserv. Large areas of SLA content are not covered by this draft - for more details, see the Wikipedia article on SLA: https://en.wikipedia.org/wiki/Service-level_agreement . ##svshah, sure, we can change the term to TCA (Traffic Conditioning Agreeme= nt), which fairly represents intention in the draft, if there is no otherwi= se comment from the working group. David> That would be good, thanks. [2] Section 3.3.2.1's reuse of the TSpec construct from RFC 2115 to specify a token bucket is a good idea, but it's not a good idea to respecify that construct in terms of L2 (link-layer, e.g., Ethernet) octets, as the RFC 2115 TSpec is specified in terms of IP octets. This change to specification in terms of L2 octets results in needing the L2_OVERHEAD TLV to cope with the possible differences in L2 (link) framing overhead at sender and receiver of this information. The TSpec should be respecified at the IP layer, with L2 framing overhead left to the Producer and Consumer to factor into their calculations based on each's direct knowledge of L2 functionality and configuration in the local AS. That ought to enable elimination of the L2_OVERHEAD TLV, thereby reducing complexity. ##svshah, the purpose for advertising L2 overhead, from the Producer to the= Consumer, is to make sure traffic is well conditioned, at the egress of th= e Consumer, to avoid possible indiscriminate drops at the ingress of the Pr= oducer. In another words, the Producer is telling the Consumer to ignore it= s own link level overhead, instead use Producer's provided link level overh= ead while running frames through QoS functions (this is relevant in use-cas= es where l2 overhead of the egress link on Consumer and of ingress link on = the Producer are of different size, e.g., in the vpn/tunnel connection betw= een two peer nodes which physically may be multiple hops away). I understand your comments regarding re-using TSpec without any modificatio= n. Do you agree with the use-case of l2 differences? If yes, any suggestion= how to accommodate that? David> Specifying this in terms of IP octets implies that L2 overhead is to= be ignored on both links. That's simpler, and a few sentences of discussi= on about possible L2 framing differences should cover what needs to be done= (e.g., if traffic rates are configured in terms of L2 octets, then explain= how each entity converts between IP traffic and L2 traffic - the draft alr= eady effectively contains that explanation). [3] A token bucket should have two rate-related marking parameters based on its token fill rate, i.e., min-rate, not the four rate-related marking parameters in this draft. The max-rate parameters in sections 3.3.2.5-6 ought to be specified against a second token bucket. In addition, the handling precedence algorithm in section 3.3.2.7 is an overly complex way to specify the relationship of two token buckets. All of this is even more important, because max-rate, as defined in RFC 2115, is only applicable to bursting - that max-rate for bursting often turns out to be an interface line rate, which is not generally useful for the traffic provisioning purposes of this draft. ##svshah, what you describe below conceptually very much makes sense and th= at is what we attempt to achieve. What is unclear though how to capture tha= t using TSpec definition specified in RFC2215. Since that TSpec definition = has both minimum-rate and maximum-rate, but no in/out profile marking param= eters. Is your proposal below to define two TSpecs using the same definition from = RFC2215? Wouldn't in that case we have min/max specified twice? min/max in = each TSpec? and thus confusing to represent one min and one max through two= TSpecs? David> See RFC 2698 for the desired behavior and the parameters needed to s= pecify it. The current idr-sla draft is not able to represent the traffic = conditioning mechanisms specified in both RFC 2698 and RFC 2697, as each me= chanism requires two token buckets (e.g., there are two burst sizes, but th= e idr-sla draft TSpec only contains one). This deficiency needs to be deal= t with. One possibility for simplification is to drop the max-rate from th= e RFC 2115 TSpec and assume that the max-rate for bursting is the effective= line rate. The following should be done instead: - Define TSpecs for two token buckets, a primary/committed token bu= cket and a secondary/peak token bucket that MUST be nested, i.e.= , traffic that is in-profile for the secondary/peak token bucket is a= lways in-profile for the primary/committed token bucket. Some of= the details of how to specify this are subtle, see RFC 2698 for a worke= d example. Use of a secondary/peak token bucket requires use of the pr= imary/ committed token bucket, but a primary/committed token bucke= t can be used without a secondary/peak token bucket. - For a single token bucket, define two handling TLVs, Committed (i= n profile) and Excess (out of profile). - For two token buckets, define three handling TLVs, Committed (in = profile for both token buckets), Peak (out of profile for primary/committed = token bucket, but in profile for secondary/peak token bucket) and Excess (out of= profile for both token buckets). NB: Could use Green/Yellow/Red terms instead of Committed/Peak/Excess terms. [4] The drop threshold TLV in section 3.3.2.8 is not specified sufficiently to be implemented interoperably. For example, I don't understand what an implementation is supposed to do when it receives 3 drop thresholds. ##svshah, It is around the semantics of a single queue with a different thr= eshold for a set of code-points, where packet for a specific code-point is = to be tail dropped if overall queue-depth hits code-point specific threshol= d at the arrival of that packet. We will add appropriate clarification for this semantics. David> Will look at revision [5] The relative priority TLV in section 3.3.2.9 has the same insufficient specification problem as the drop threshold TLV, compounded by a functional incompleteness problem - if the recipient is using a weighted packet transmission scheduler (e.g., WRR), priorities cannot be used to configure that scheduler. Hence, some specification of weights and scheduling algorithms that use weights needs to be added. ##svshah, Sure. Is following clarification okay? (some of the wordings take= n from RFC2598) " A higher priority class of traffic to be served without pre-empted by lower= priority class of traffic for more than a packet time at the configured ra= te. In the system that implements WRR, the use of relative priority may get res= tricted where a single queue may be used for a higher priority traffic clas= s where that queue is configured for the full share of the output bandwidt= h. " David> Last sentence basically says that WRR weights are out-of-scope. Tha= t seems wrong. Will look at revision. [6] I have no idea what the sub-traffic classes TLV in section 3.3.2.10 is supposed to do, as that TLV is specified based on "Traffic Class TLVs" which is an undefined term in this draft (e.g., that term is not used outside of section 3.3.2.10. ##svshah, They are to facilitate hierarchy. A specific Traffic Class, can f= urther be divided in a multiple subset of Traffic Classes, with their own = Traffic Class Elements and Traffic Class Services. Will correct the wording to remove your this specific concern. David> Will look at revision [7] This draft's QoS contents need to be functionally aligned with work-in-progress on YANG QoS models, in order to provide some assurance that that this draft is implementable for actual network switch/router data paths. The current acknowledgement of the existence of YANG, NETCONF and RESTConf at the end of Section 1 does not suffice. ##svshah, While eventually "Traffic Conditioning Agreement" should be trans= lated to the actual forwarding qos policy on any vendor specific device, TC= A exchange largely carries concepts/semantics that is either standard based= or well understood. While we are not aware of any working group document of QoS Yang Model, we = think that concepts of Traffic Conditioning should be easily adaptable to = any QoS Yang Models since they also have to be defined to support those con= cepts. David> Still want to see cross-check with implementations here. [8] There are significant complexity and correctness problems caused by the option to not specify the Source AS - e.g., Section 3.2 defines an SLA ID as an "identifier which is unique in the scope of Source AS" which is meaningless if there is no Source AS. It would be simpler to always specify Source AS, even in the point-to-point case. ##svshah, okay. Ron Bonica also suggested same in his review earlier. We ha= d chosen a path of optional Source AS to simplify implementations in cases.= Given specification of Source AS always is more clearer in multiple feed-b= ack we have gotten so far, we can modify the specification to incorporate t= hat over the simplicity of implementation for certain cases. David> OK, thanks. [9] In section 3.2, the "intended for the peer receiver of the BGP UPDATE message" text in the specification of bit 0 of the SLA Subtype flags is unclear. I suspect that this is intended to differentiate the two usages described in sections 4.1.1 (Point-to-Point) and 4.1.2 (Multiple Hops), in which case the parenthesized terms (or similar terminology) should be used with cross-references to those two sections. ##svshah, sure will make necessary changes, also in the context of earlier = comment. [10] There needs to be a coherent discussion in one place about how SLA advertisement, update and withdrawal work. A single ADVERTISE method may suffice on the wire, but the details on how initial advertisement, subsequent advertisement (update) and withdrawal work need to be specified in one place. The third paragraph of Section 4 is a start on this material, but it's too terse; [Med] That text is terse because we are reusing the BGP machinery for adver= tising/withdrawing; we only augment it with triggers that are linked to the= SLA information. A new SLA will lead to an update message with ADVERTISE, = an update of an existing SLA will trigger an update message. We do think th= is information is already present in the document. David>This is hard to understand it, as there is no statement that the BGP = machinery is being used, and the material on SLA usage is spread in differe= nt places. I suggest starting section 3 with a discussion of advertisement= /update/withdrawal, and how all three are realized via a single ADVERTISE m= ethod via BGP UPDATE - this was difficult to figure out in reading the curr= ent draft. it should be expanded into its own subsection, and moved earlier to come before the ADVERTISE method in Section 3.2. This text from Section 3.2 should be moved into that new subsection and likewise expanded: [Med] Another option is to move it Section 4. From our standpoint, we do th= ink it is straightforward to describe the behavior once the attributes form= at are defined. David> Ok, that's an editorial choice - I prefer to explain how something w= orks before defining its on-the-wire data format. If an advertised SLA ID is different from earlier advertised one, for the same prefix and from the same Source AS, indicates Source AS is advertising new SLA Content to replace the previous one advertised with the same SLA ID. In addition, I wonder whether functionality should be added to allow withdrawal of an advertisement by specifying its SLA ID, although that was not part of the original design. [Med] The reason we didn't adopted that design is that we don't want to mak= e assumptions on which data the remote peer will be used for enforcing loca= l actions and also because of this text: The SLA ID applies to aggregate traffic to prefixes for a given AFI/SAFI that share the same Source AS and SLA ID. David> That's fine, I wanted to ensure that this had been considered. The = discussion of BGP mechanism reuse will probably help here. [11] Notions of context for interpretation of all the IPFIX parameters in 3.3.1 need to be added, e.g.: - The first three parameters (DSCP, MPLS EXP field in top label, 80= 2.1q priority) can and do vary on a link-by-link or LSP-by-LSP basis along a t= raffic's network path. - The IP address parameters are rather likely to be VPN-specific wh= en there's more than one BGP/MPLS VPN that spans or transits the ASs involv= ed. - The transport port parameters need specification of which transpo= rt header and where it is located (e.g., for TCP traffic carried by in VXLAN, is t= his the inner TCP header or the outer UDP header in VXLAN). There are probably simple approaches to specifying context in all cases, but that context does need to be specified ... in all cases. [Med] We dind't include a context field because we thought that the definit= ion of the IPFIX attributes is sufficient by itself, but if you do think it= is helpful to have such information, we can update the table. David> Really??? Please reread the first comment above: - The first three parameters (DSCP, MPLS EXP field in top label, 80= 2.1q priority) can and do vary on a link-by-link or LSP-by-LSP basis along a t= raffic's network path. David> Taking just DSCP, it can change on a per-link basis, so something h= as to specify which link (between the SLA Producer and SLA Consumer?) is in= volved. It probably suffices to say that it's the link that crosses the re= levant AS boundary, but that does have to be stated, as it's nowhere to be = found in the far more general IPFIX registry. [12] The security considerations (section 10) are severely incomplete and insufficient: David> I stand by this statement and recommend a complete rewrite of the se= curity considerations. - Discussion of possible abuse of this BGP option for denial-of-ser= vice and theft-of-service, needs to be added, including possible countermeasures and m= itigations. [Med] This attack vector is not specific to this attribute; this is valid f= or BGP in general. David> There are additional attacks enabled by this attribute. - This sentence at the end of the second paragraph in Section 10 is= content-free: It is NOT RECOMMENDED to enable this attribute at the scale of the Internet unless if means to prevent leaking= sensitive information are enforced. What exactly is an implementer or admin supposed to do? [Med] An example of what an admin needs to check if this information can be= sent to a given peer or not. Some of the content of the attribute contains= some sensitive information such as contract Id, classes, etc. How does one figure out whether an implementation or deployment is "at = the scale of the Internet" ?? [Med] The idea here is to avoid leaking such data in to the global routing = table. Only entitled peers need receive such information with controlled sc= ope. David> I understand the idea - the problem is that I don't see specificatio= n of what has to be implemented in either the text in the draft or the abov= e explanations. - The next to last paragraph in section 10 is almost content-free, = as it leaves decisions on implementation and deployment of key security = functionality as "an exercise for the reader" - that's not acceptable. [Med] I guess you are referring to the following text. Validation checks ar= e really deployment-specific. The text calls out the issue and recommends a= n action; how to translate this action into detailed actions is realty loca= l to a domain The attribute may be advertised by a misbehaving node to communicate SLA parameters that are not aligned with the SLA agreements. Though the enforcement of SLA parameters is outside the scope of this document, it is RECOMMENDED that the SLA Consumer to enforce a set of validation checks before translating the SLA parameters conveyed in the QoS attributes into provisioning actions. Such validations MAY rely on SLA parameters like the origin AS or SLA ID, like generating SLA ID using pseudo-random schemes [RFC4086]. David> I stand by the "exercise to the reader" criticism - one way to be h= onest about this would be to change the paragraph to: The attribute may be advertised by a misbehaving node to communicat= e SLA parameters that are not aligned with the SLA agreements. The enforcement of SLA parameters is outside the scope of this document. David> That does not change any normative content of the original paragraph= . My view is that the "outside the scope of this document" statement is wr= ong because all of these parameters are being defined in this draft. - Last, but not least, the final paragraph in Section 10 is a joke = that will be lost on a security directorate reviewer - to understand = why, see Section 2 of RFC 6919, and take note of the publication dat= e of RFC 6919. David> For anyone who didn't catch the reference, RFC 6919 is an April 1 RF= C ... and the "SHOULD BE considered" language used in the last security con= siderations paragraph of this draft is accurately characterized as vague in= Section 2 of RFC 6919: The phrase "SHOULD CONSIDER" indicates that the authors of the specification think that implementations should do something, but they're not sure quite what. ------------------------ Having noted a dozen major issues, I'll end the review here for now, as I believe a serious revision of the draft is called for, which would be a better starting point to review for minor issues and editorial items. -------------------------------------------------------- David L. Black, Distinguished Engineer Dell EMC, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 Cell: +1 (978) 394-7754 David.Black@dell.com <=3D=3D=3D NEW =3D=3D=3D -------------------------------------------------------- --_000_CE03DB3D7B45C245BCA0D243277949362F8C4510MX307CL04corpem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

David> Inline ...=

 <= /p>

Thanks, --David

 <= /p>

From: Shitansh= u Shah [mailto:shitanshu_shah@hotmail.com]
Sent: Friday, February 24, 2017 4:09 AM
To: Black, David; tsv-art@ietf.org
Cc: idr@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; ietf@iet= f.org
Subject: Re: Review of draft-ietf-idr-sla-exchange-10

 

 

Hi David,

 

Thank you for taking time for the review..

 

Please find our response inline ##svshah and [Med]

 

Regards,

Shitanshu

From: David Black <da= vid.black@emc.com>
Sent: Tuesday, February 21, 2017 3:31 PM
To: tsv-art@ietf.org
Cc: idr@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; ietf@ietf.org
Subject: Review of draft-ietf-idr-sla-exchange-10

 

Reviewer: David Black
Review result: Not Ready

I've reviewed this document as part of the transport area
directorate's ongoing effort to review key IETF documents. These
comments were written primarily for the transport area directors, but
are copied to the document's authors for their information and to
allow them to address any issues raised. When done at the time of IETF
Last Call, the authors should consider this review together with any
other last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or= forward this review.

Document: draft-ietf-idr-sla-10
Reviewer: David Black
Review Date: February 21, 2017

Review result: Not Ready

This is an early TSV-ART review of a working group draft, requested by
the IDR Working Group.

This draft defines an extension to BGP to allow exchange of traffic
handling parameters (e.g., configured rates, burst sizes, drop
thresholds).  While this is a useful area of technology to standardize=
across network operators, this draft has significant problems, and
parts of it could use some serious rethought.

This reviewer has discussed small portions of this draft with some of
the authors in the past, but this is his first comprehensive reading
and review of the draft.

Major Issues:

[1] The draft is misnamed.  This is not an SLA (Service Level
Agreement) draft - it's a TCA (Traffic Conditioning Agreement) draft -
see the definition of TCA in RFC 2475.  This draft should start from that definition and generalize the applicability of TCA beyond
Diffserv.  Large areas of SLA content are not covered by this draft -<= br> for more details, see the Wikipedia article on SLA:
https://en.wikipedia.org/wiki/Service-level_agreement .

##svshah, sure, we can change the term to TCA (Traffic Conditioning Agreeme= nt), which fairly represents intention in the draft, if there is no otherwi= se comment from the working group.

 


David> That would be good, thanks.

[2] Section 3.3.2.1's reuse of the TSpec construct from RFC 2115 to
specify a token bucket is a good idea, but it's not a good idea to
respecify that construct in terms of L2 (link-layer, e.g., Ethernet)
octets, as the RFC 2115 TSpec is specified in terms of IP octets.
This change to specification in terms of L2 octets results in needing
the L2_OVERHEAD TLV to cope with the possible differences in L2 (link)
framing overhead at sender and receiver of this information.  The
TSpec should be respecified at the IP layer, with L2 framing overhead
left to the Producer and Consumer to factor into their calculations
based on each's direct knowledge of L2 functionality and configuration
in the local AS.  That ought to enable elimination of the L2_OVERHEAD<= br> TLV, thereby reducing complexity.

##svshah, the purpose for a= dvertising L2 overhead, from the Producer to the Consumer, is to make = sure traffic is well conditioned, at the egress of the Consumer, to avoid possible indiscriminate drops at the ingress of the Producer. In = another words, the Producer is telling the Consumer to ignore its= own link level overhead, instead use Producer's provided link level overhe= ad while running frames through QoS functions (this is relevant in use-cases where l2 overhead of the egress l= ink on Consumer and of ingress link on the Producer are of different size, = e.g., in the vpn/tunnel connection between two peer nodes which p= hysically may be multiple hops away).

I understand your comments = regarding re-using TSpec without any modification. Do you agree with t= he use-case of l2 differences? If yes, any suggestion how to accommodate that?

 

David> Specifying this= in terms of IP octets implies that L2 overhead is to be ignored on both li= nks.  That’s simpler, and a few sentences of discussion about possible L2 framing differences should cover what needs to be done (e.g., = if traffic rates are configured in terms of L2 octets, then explain how eac= h entity converts between IP traffic and L2 traffic - the draft already eff= ectively contains that explanation).


[3] A token bucket should have two rate-related marking parameters
based on its token fill rate, i.e., min-rate, not the four
rate-related marking parameters in this draft.  The max-rate
parameters in sections 3.3.2.5-6 ought to be specified against a
second token bucket.  In addition, the handling precedence algorithm in section 3.3.2.7 is an overly complex way to specify the
relationship of two token buckets.  All of this is even more
important, because max-rate, as defined in RFC 2115, is only
applicable to bursting - that max-rate for bursting often turns out to
be an interface line rate, which is not generally useful for the
traffic provisioning purposes of this draft.

 

##svshah, what you describe= below conceptually very much makes sense and that is what we attempt to ac= hieve. What is unclear though how to capture that using TSpec definition specified in RFC2215. Since that TSpec definition has bot= h minimum-rate and maximum-rate, but no in/out profile marking parameters.<= o:p>

 

Is your proposal below to d= efine two TSpecs using the same definition from RFC2215? Wouldn't in t= hat case we have min/max specified twice? min/max in each TSpec? and thus confusing to represent one min and one max through two TSpecs?

 

David> See RFC 2698 fo= r the desired behavior and the parameters needed to specify it.  The c= urrent idr-sla draft is not able to represent the traffic conditioning mechanisms specified in both RFC 2698 and RFC 2697, as each mechanism requ= ires two token buckets (e.g., there are two burst sizes, but the idr-sla dr= aft TSpec only contains one).  This deficiency needs to be dealt with.=   One possibility for simplification is to drop the max-rate from the RFC 2115 TSpec and assume that the max-ra= te for bursting is the effective line rate.=


The following should be done instead:
        - Define TSpecs for two token bu= ckets, a primary/committed token bucket
            &nb= sp;   and a secondary/peak token bucket that MUST be nested, i.e.= , traffic
            &nb= sp;   that is in-profile for the secondary/peak token bucket is a= lways
            &nb= sp;   in-profile for the primary/committed token bucket.  So= me of the details
            &nb= sp;   of how to specify this are subtle, see RFC 2698 for a worke= d example.
            &nb= sp;   Use of a secondary/peak token bucket requires use of the pr= imary/
            &nb= sp;   committed token bucket, but a primary/committed token bucke= t can be used
            &nb= sp;   without a secondary/peak token bucket.
        - For a single token bucket, def= ine two handling TLVs, Committed (in profile) and
            &nb= sp;   Excess (out of profile).
        - For two token buckets, define = three handling TLVs, Committed (in profile for both
            &nb= sp;   token buckets), Peak (out of profile for primary/committed = token bucket, but in
            &nb= sp;   profile for secondary/peak token bucket) and Excess (out of= profile for both
            &nb= sp;   token buckets).
NB: Could use Green/Yellow/Red terms instead of Committed/Peak/Excess
terms.

[4] The drop threshold TLV in section 3.3.2.8 is not specified
sufficiently to be implemented interoperably.  For example, I don't understand what an implementation is supposed to do when it receives 3
drop thresholds.

##svshah, It is around= the semantics of a single queue with a different threshold for a set = of code-points, where packet for a specific code-point is to be tail dropped if overall queue-depth hits code-point specific threshold at the a= rrival of that packet.

We will add appropriate cla= rification for this semantics.

 

David> Will look at revision


[5] The relative priority TLV in section 3.3.2.9 has the same
insufficient specification problem as the drop threshold TLV,
compounded by a functional incompleteness problem - if the recipient
is using a weighted packet transmission scheduler (e.g., WRR),
priorities cannot be used to configure that scheduler.  Hence, some specification of weights and scheduling algorithms that use weights
needs to be added.

##svshah, Sure. Is followin= g clarification okay? (some of the wordings taken from RFC2598)<= /span>

 

"

A higher priority class of = traffic to be served without pre-empted by lower priority class o= f traffic for more than a packet time at the configured rate.

 

In the system that implemen= ts WRR, the use of relative priority may get restricted where a single queu= e may be used for a higher priority traffic class where that queue  is configured for the full share of the output bandwidth.=

"

 

David> Last sentence basically says that WRR weights are out-of-sc= ope.  That seems wrong.  Will look at revision.

[6] I have no idea what the sub-traffic classes TLV in section
3.3.2.10 is supposed to do, as that TLV is specified based on "Traffic=
Class TLVs" which is an undefined term in this draft (e.g., that term<= br> is not used outside of section 3.3.2.10.

##svshah, They are to facil= itate hierarchy. A specific Traffic Class, can further be divided in a mult= iple  subset of Traffic Classes, with their own Traffic Class Elements and Traffic Class Services.

 

Will correct the wording to= remove your this specific concern.


David> Will look at revision


[7] This draft's QoS contents need to be functionally aligned with
work-in-progress on YANG QoS models, in order to provide some
assurance that that this draft is implementable for actual network
switch/router data paths.  The current acknowledgement of the
existence of YANG, NETCONF and RESTConf at the end of Section 1 does
not suffice.

##svshah, While eventu= ally "Traffic Conditioning Agreement" should be translated to the= actual forwarding qos policy on any vendor specific device, TCA exchange largely carries concepts/semantics that is either standard based or w= ell understood.

 

While we are not aware of a= ny working group document of QoS Yang Model, we think that  concepts o= f Traffic Conditioning should be easily adaptable to any QoS Yang Models since they also have to be defined to support those concepts.<= o:p>

 

 

David> Still want to s= ee cross-check with implementations here.

[8] There are significant complexity and correctness problems caused
by the option to not specify the Source AS - e.g., Section 3.2 defines
an SLA ID as an "identifier which is unique in the scope of Source AS&= quot;
which is meaningless if there is no Source AS.  It would be simpler to=
always specify Source AS, even in the point-to-point case.

##svshah, okay. Ron Bonica also suggested same in his review earlier. We ha= d chosen a path of optional Source AS to simplify implementations in c= ases. Given specification of Source AS always is more clearer in multiple f= eed-back we have gotten so far, we can modify the specification to incorporate that over the simplicity of implem= entation for certain cases.

 

David> OK, thanks.


[9] In section 3.2, the "intended for = the peer receiver of the BGP
UPDATE message" text in the specificat= ion of bit 0 of the SLA Subtype
flags is unclear.  I suspect that this= is intended to differentiate
the two usages described in sections 4.1.1 = (Point-to-Point) and 4.1.2
(Multiple Hops), in which case the parenthe= sized terms (or similar
terminology) should be used with cross-refe= rences to those two
sections.<= /p>

##svshah, sure will make ne= cessary changes, also in the context of earlier comment.<= /p>

 


[10] There needs to be a coherent discussio= n in one place about how
SLA advertisement, update and withdrawal wo= rk.  A single ADVERTISE
method may suffice on the wire, but the det= ails on how initial
advertisement, subsequent advertisement (up= date) and withdrawal work
need to be specified in one place.  Th= e third paragraph of Section 4
is a start on this material, but it's too t= erse; 

 

[Med] That text is terse because we are reusin= g the BGP machinery for advertising/withdrawing; we only augment it with tr= iggers that are linked to the SLA information. A new SLA will lead to an update message with ADVERTISE, an update of an e= xisting SLA will trigger an update message. We do think this information is= already present in the document.

 <= /p>

David>This is hard to = understand it, as there is no statement that the BGP machinery is being use= d, and the material on SLA usage is spread in different places.  I suggest starting section 3 with a discussion of advertisement/update/wit= hdrawal, and how all three are realized via a single ADVERTISE method via B= GP UPDATE - this was difficult to figure out in reading the current draft.<= /span>

 

it should be expanded
into its own subsection, and moved earlier = to come before the
ADVERTISE method in Section 3.2.  This= text from Section 3.2 should be
moved into that new subsection and likewise= expanded:

[Med] Another option is to move it Section 4. From our standpo= int, we do think it is straightforward to describe the behavior once the at= tributes format are defined. 

 <= /p>

David> Ok, that’= s an editorial choice - I prefer to explain how something works before defi= ning its on-the-wire data format.

 

    &nb= sp; If an advertised SLA ID is different from earlier advertised one,
      for the same= prefix and from the same Source AS, indicates Source
      AS is advert= ising new SLA Content to replace the previous one
      advertised w= ith the same SLA ID.

In addition, I wonder whether functionality= should be added to allow
withdrawal of an advertisement by specifyin= g its SLA ID, although that
was not part of the original design.=

 

[Med] The reason we didn’t adopted that design is that we don&#= 8217;t want to make assumptions on which data the remote peer will be used = for enforcing local actions and also because of this text:

      The SLA ID applies to aggregate traf= fic to prefixes for a given=

      AFI/SAFI that share the same Source = AS and SLA ID.

 <= /p>

David> That’s fi= ne, I wanted to ensure that this had been considered.  The discussion = of BGP mechanism reuse will probably help here.

[11] Notions of context for interpretation = of all the IPFIX parameters
in 3.3.1 need to be added, e.g.:
        = - The first three parameters (DSCP, MPLS EXP field in top label, 802.1q priority) can
       &= nbsp;        and do vary on a link-by-li= nk or LSP-by-LSP basis along a traffic's network path.
        = - The IP address parameters are rather likely to be VPN-specific when there's more
       &= nbsp;        than one BGP/MPLS VPN that = spans or transits the ASs involved.
        = - The transport port parameters need specification of which transport header and where it
       &= nbsp;        is located (e.g., for TCP t= raffic carried by in VXLAN, is this the inner TCP header
       &= nbsp;        or the outer UDP header in = VXLAN).
There are probably simple approaches to spe= cifying context in all
cases, but that context does need to be spe= cified ... in all cases.

[Med] We dind’t include a context field because we thoug= ht that the definition of the IPFIX attributes is sufficient by itself, but= if you do think it is helpful to have such information, we can update the table.

David>  Really???=   Please reread the first comment above:

 <= /p>

    &nb= sp;   - The first three parameters (DSCP, MPLS EXP field in top l= abel, 802.1q priority) can
       &= nbsp;        and do vary on a link-by-li= nk or LSP-by-LSP basis along a traffic's network path.

 

David>  Taking ju= st DSCP, it can change on a per-link basis, so something has to specify whi= ch link (between the SLA Producer and SLA Consumer?) is involved.  It probably suffices to say that it’s the link that crosses the rele= vant AS boundary, but that does have to be stated, as it’s nowhere to= be found in the far more general IPFIX registry.

[12] The security considerations (section 1= 0) are severely incomplete
and insufficient:

 <= /p>

David> I stand by this= statement and recommend a complete rewrite of the security considerations.=


        = - Discussion of possible abuse of this BGP option for denial-of-service and theft-of-service,
       &= nbsp;        needs to be added, includin= g possible countermeasures and mitigations.

[Med] This attack vector is not specific to this attribute; th= is is valid for BGP in general.

 

David> There are addit= ional attacks enabled by this attribute.<= o:p>


        = - This sentence at the end of the second paragraph in Section 10 is<= span style=3D"font-size:10.0pt;font-family:"Calibri","sans-s= erif";color:#1F497D"> content-free:

       &= nbsp;           It is NOT= RECOMMENDED to enable this attribute at the
       &= nbsp;           scale of = the Internet unless if means to prevent leaking sensitive
       &= nbsp;           informati= on are enforced.

       &= nbsp;        What exactly is an implemen= ter or admin supposed to do? 

 

[Med] An example of what an admin needs to che= ck if this information can be sent to a given peer or not. Some of the cont= ent of the attribute contains some sensitive information such as contract Id, classes, etc.

 <= /p>

How does one
       &= nbsp;        figure out whether an imple= mentation or deployment is  "at the scale
       &= nbsp;        of the Internet" ??



[Med] The idea here is to avoid leaking such d= ata in to the global routing table. Only entitled peers need receive such i= nformation with controlled scope.

 

David> I understand th= e idea - the problem is that I don’t see specification of what has to= be implemented in either the text in the draft or the above explanations.<= /span>

    &nb= sp;   - The next to last paragraph in section 10 is almost conten= t-free, as it leaves
       &= nbsp;        decisions on implementation= and deployment of key security functionality as
       &= nbsp;        "an exercise for the r= eader" - that's not acceptable.


[Med] I guess = you are referring to the following text. Validation checks are really deplo= yment-specific. The text calls out the issue and recommends an action; how to translate this action into detailed actions i= s realty local to a domain<= /span>

   The attribute may be advertised by a mis=
behaving node to communicate
   SLA parameters that are not aligned with=
 the SLA agreements.  Though
   the enforcement of SLA parameters is out=
side the scope of this
   document, it is RECOMMENDED that the SLA=
 Consumer to enforce a set of
   validation checks before translating the=
 SLA parameters conveyed in
   the QoS attributes into provisioning act=
ions.  Such validations MAY
   rely on SLA parameters like the origin A=
S or SLA ID, like generating
   SLA ID using pseudo-random schemes [RFC4086].

 

David> I stand by the = “exercise to the reader”  criticism - one way to be honest= about this would be to change the paragraph to:

 
        =
The attribute may be advertised by a m=
isbehaving node to communicate
   SLA parameters that are not aligned with=
 the SLA agreements.  The
   enforcement of SLA paramete=
rs is outside the scope of this document.
 
David> That does not change any normative content of the =
original paragraph.  My view is that the “outside the scope of t=
his document” statement is wrong because all of these parameters are =
being defined in this draft.


        = - Last, but not least, the final paragraph in Section 10 is a joke that will
       &= nbsp;        be lost on a security direc= torate reviewer - to understand why, see
       &= nbsp;        Section 2 of RFC 6919, and = take note of the publication date of RFC 6919.

David> For anyone who didn’t catch the reference, RFC 6919 is an A= pril 1 RFC ... and the “SHOULD BE considered” language used in = the last security considerations paragraph of this draft is accurately char= acterized as vague in Section 2 of RFC 6919:

   The phrase &quo= t;SHOULD CONSIDER" indicates that the authors of the=

   specification t= hink that implementations should do something, but

   they're not su= re quite what.

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

Having noted a dozen major issues, I'll end= the review here for now,
as I believe a serious revision of the draf= t is called for, which
would be a better starting point to review = for minor issues and
editorial items.

-------------------------------------------= -------------
David L. Black, Distinguished Engineer
Dell EMC, 176 South St., Hopkinton, MA = ; 01748
+1 (508) 293-7953   &nbs= p; Cell: +1 (978) 394-7754
Dav= id.Black@dell.com  <=3D=3D=3D NEW =3D=3D=3D -------------------------------------------= -------------


--_000_CE03DB3D7B45C245BCA0D243277949362F8C4510MX307CL04corpem_-- From nobody Fri Feb 24 09:26: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 5C38712943C; Fri, 24 Feb 2017 09:25:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.788 X-Spam-Level: X-Spam-Status: No, score=-3.788 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=-1.887, 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 DKOoUYOU9ml1; Fri, 24 Feb 2017 09:25:55 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0095.outbound.protection.outlook.com [104.47.0.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70B3012943A; Fri, 24 Feb 2017 09:25:54 -0800 (PST) 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=I3vO6WM1oUDlJ2b5wf7sjBG5zXbccKE9zjt4hw9NabQ=; b=Qs2X3lU30ROzEh0HJxKuxDYVFv0jQIKFlTjP+TU/65okAIfhIii95GJo9Ap3P69mAfgszDH/EuGN7/byZwMuC0giVx9UB69/R9/b7DeYvWRNb6+n209ZnDFDCEkSCIhfM8ZZ8OUUwe2ycVUADXjGSam7fh1pa2ziHB+zjPWcTZ8= Received: from AM4PR07MB1412.eurprd07.prod.outlook.com (10.165.248.15) by AM4PR07MB1411.eurprd07.prod.outlook.com (10.165.248.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.7; Fri, 24 Feb 2017 17:25:51 +0000 Received: from AM4PR07MB1412.eurprd07.prod.outlook.com ([10.165.248.15]) by AM4PR07MB1412.eurprd07.prod.outlook.com ([10.165.248.15]) with mapi id 15.01.0933.011; Fri, 24 Feb 2017 17:25:51 +0000 From: "Simpson, Adam 1. (Nokia - CA)" To: "stephane.litkowski@orange.com" , "Susan Hares" , "idr@ietf.org" Thread-Topic: [ALU] Re: [Idr] draft-ietf-idr-flowspec-interfaceset - IPR call prior tocall for WG early codepoint allocation Thread-Index: AQHSjniXJH0fJ6vv4UuqbW0xhjmsaKF34wMA Date: Fri, 24 Feb 2017 17:25:51 +0000 Message-ID: <01E0501B-FE6B-4930-B9E5-0978B8BB315F@nokia.com> References: <008501d28e09$c9cd23c0$5d676b40$@ndzh.com> <6867_1487925156_58AFEFA4_6867_8643_1_9E32478DFA9976438E7A22F69B08FF921DD0FD1A@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: <6867_1487925156_58AFEFA4_6867_8643_1_9E32478DFA9976438E7A22F69B08FF921DD0FD1A@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 authentication-results: spf=none (sender IP is ) smtp.mailfrom=adam.1.simpson@nokia.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [135.245.48.253] x-ms-office365-filtering-correlation-id: 00f14ab8-09c7-4026-4154-08d45cda2e5d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:AM4PR07MB1411; x-microsoft-exchange-diagnostics: 1; AM4PR07MB1411; 7:cTpaLT6Rvj2Yp7uwRSLyecqCk1N7uVcaSZJFJMuE2sTWTbwtvPAg8K78iDWR/TXFFQ5ot/7+JgtZQ4kcELVCAJV2BcVIDjQKYmImVgoWpbuQ1AIw9M21x9nvzJ0YHv+q3O1zV3IVW1V0ZARDTkwYH9xej9cAoHJLyNniBGFaT/Vw89TIQSPPFY7Fn6ue863vIqJDWC09X36CUaM42OHBFfLFyllO9cQueBa58NKEWSxlP3jyz1rNEUuZM/k8whKuUx5Cx0g7PAmkKpg3c3xvC/E97xJgrEijUkhnBNL5QcZiH+fGqh/aW9y1QXClz6gzZH39R6v1rosbecL3X9VBiA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(18271650672692)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123560025)(20161123558025)(20161123564025)(20161123555025)(6072148); SRVR:AM4PR07MB1411; BCL:0; PCL:0; RULEID:; SRVR:AM4PR07MB1411; x-forefront-prvs: 0228DDDDD7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39860400002)(39410400002)(39840400002)(39450400003)(39850400002)(199003)(377454003)(189002)(99286003)(68736007)(5660300001)(4326007)(229853002)(25786008)(33656002)(230783001)(92566002)(86362001)(36756003)(66066001)(3280700002)(6506006)(3846002)(102836003)(2906002)(189998001)(2900100001)(6436002)(6486002)(6116002)(77096006)(38730400002)(76176999)(54356999)(101416001)(106116001)(81166006)(122556002)(8676002)(4001350100001)(6306002)(3660700001)(106356001)(105586002)(6246003)(81156014)(53546006)(54896002)(83716003)(2501003)(53936002)(97736004)(82746002)(2950100002)(83506001)(5890100001)(7736002)(6512007)(50986999)(8936002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR07MB1411; H:AM4PR07MB1412.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_01E0501BFE6B4930B9E50978B8BB315Fnokiacom_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2017 17:25:51.5009 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1411 Archived-At: Cc: "draft-ietf-idr-flowspec-interfaceset@ietf.org" Subject: Re: [Idr] [ALU] Re: draft-ietf-idr-flowspec-interfaceset - IPR call prior tocall for WG early codepoint allocation X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 17:25:58 -0000 --_000_01E0501BFE6B4930B9E50978B8BB315Fnokiacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiBlaXRoZXIuDQoNCkZyb206IElkciA8aWRyLWJvdW5j ZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiAic3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20i IDxzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbT4NCkRhdGU6IEZyaWRheSwgRmVicnVhcnkg MjQsIDIwMTcgYXQgMTI6MzIgQU0NClRvOiBTdXNhbiBIYXJlcyA8c2hhcmVzQG5kemguY29tPiwg ImlkckBpZXRmLm9yZyIgPGlkckBpZXRmLm9yZz4NCkNjOiAiZHJhZnQtaWV0Zi1pZHItZmxvd3Nw ZWMtaW50ZXJmYWNlc2V0QGlldGYub3JnIiA8ZHJhZnQtaWV0Zi1pZHItZmxvd3NwZWMtaW50ZXJm YWNlc2V0QGlldGYub3JnPg0KU3ViamVjdDogW0FMVV0gUmU6IFtJZHJdIGRyYWZ0LWlldGYtaWRy LWZsb3dzcGVjLWludGVyZmFjZXNldCAtIElQUiBjYWxsIHByaW9yIHRvY2FsbCBmb3IgV0cgZWFy bHkgY29kZXBvaW50IGFsbG9jYXRpb24NCg0KSeKAmW0gbm90IGF3YXJlIG9mIGFueSBJUFIgcmVn YXJkaW5nIHRoaXMgZG9jdW1lbnQNCg0KRnJvbTogU3VzYW4gSGFyZXMgW21haWx0bzpzaGFyZXNA bmR6aC5jb21dDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMjMsIDIwMTcgMjA6MjANClRvOiBp ZHJAaWV0Zi5vcmcNCkNjOiBkcmFmdC1pZXRmLWlkci1mbG93c3BlYy1pbnRlcmZhY2VzZXRAaWV0 Zi5vcmcNClN1YmplY3Q6IGRyYWZ0LWlldGYtaWRyLWZsb3dzcGVjLWludGVyZmFjZXNldCAtIElQ UiBjYWxsIHByaW9yIHRvIGNhbGwgZm9yIFdHIGVhcmx5IGNvZGVwb2ludCBhbGxvY2F0aW9uDQoN ClRoaXMgYW4gSVBSIGNhbGwgZm9yIGRyYWZ0LWlldGYtaWRyLWZsb3dzcGVjLWludGVyZmFjZXNl dC0wMi50eHQuICBXaWwgdGhlIGF1dGhvcnMgKEx1Y3ksIEplZmYsIEtleXVyLCBBZGFtIGFuZCBT dGVwaGFuZSkgcGxlYXNlIGluZGljYXRlIGlmIHRoZXkga25vdyBvZiBhbnkgSVBSLg0KDQpTdWUg SGFyZXMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KDQoNCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMg cGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2 aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQoNCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0 ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNz YWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQoNCmEgbCdleHBlZGl0ZXVyIGV0 IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBl bGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQoNCk9yYW5nZSBk ZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBk ZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0 dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0 aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQoNCnRoZXkgc2hvdWxkIG5vdCBiZSBk aXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KDQpJZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCg0KQXMg ZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMg dGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KDQpUaGFuayB5 b3UuDQo= --_000_01E0501BFE6B4930B9E50978B8BB315Fnokiacom_ Content-Type: text/html; charset="utf-8" Content-ID: <64A9CA8F7A8C5445A3EB2F7620C86E74@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseToiTm9raWEgUHVyZSBUZXh0IExpZ2h0IjsNCglwYW5vc2UtMToy IDExIDMgNCA0IDYgMiA2IDMgMzt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsN CglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNt Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OkNhbGlicmk7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0 ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uRW1haWxTdHls ZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbDsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5I VE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFBy ZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q291cmllcjt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiTm9raWEgUHVy ZSBUZXh0IExpZ2h0IjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4w cHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Tm9raWEgUHVyZSBUZXh0IExpZ2h0JnF1b3Q7Ij5JIGFtIG5vdCBhd2FyZSBvZiBh bnkgSVBSIGVpdGhlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtOb2tpYSBQ dXJlIFRleHQgTGlnaHQmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5JZHIgJmx0O2lkci1ib3VuY2VzQGlldGYub3Jn Jmd0OyBvbiBiZWhhbGYgb2YgJnF1b3Q7c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20mcXVv dDsgJmx0O3N0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwv Yj5GcmlkYXksIEZlYnJ1YXJ5IDI0LCAyMDE3IGF0IDEyOjMyIEFNPGJyPg0KPGI+VG86IDwvYj5T dXNhbiBIYXJlcyAmbHQ7c2hhcmVzQG5kemguY29tJmd0OywgJnF1b3Q7aWRyQGlldGYub3JnJnF1 b3Q7ICZsdDtpZHJAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDtkcmFmdC1pZXRm LWlkci1mbG93c3BlYy1pbnRlcmZhY2VzZXRAaWV0Zi5vcmcmcXVvdDsgJmx0O2RyYWZ0LWlldGYt aWRyLWZsb3dzcGVjLWludGVyZmFjZXNldEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8 L2I+W0FMVV0gUmU6IFtJZHJdIGRyYWZ0LWlldGYtaWRyLWZsb3dzcGVjLWludGVyZmFjZXNldCAt IElQUiBjYWxsIHByaW9yIHRvY2FsbCBmb3IgV0cgZWFybHkgY29kZXBvaW50IGFsbG9jYXRpb248 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPknigJltIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHJlZ2FyZGluZyB0 aGlzIGRvY3VtZW50PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBj bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpUYWhvbWEiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpUYWhvbWEi PiBTdXNhbiBIYXJlcyBbbWFpbHRvOnNoYXJlc0BuZHpoLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9i PiBUaHVyc2RheSwgRmVicnVhcnkgMjMsIDIwMTcgMjA6MjA8YnI+DQo8Yj5Ubzo8L2I+IGlkckBp ZXRmLm9yZzxicj4NCjxiPkNjOjwvYj4gZHJhZnQtaWV0Zi1pZHItZmxvd3NwZWMtaW50ZXJmYWNl c2V0QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IGRyYWZ0LWlldGYtaWRyLWZsb3dzcGVj LWludGVyZmFjZXNldCAtIElQUiBjYWxsIHByaW9yIHRvIGNhbGwgZm9yIFdHIGVhcmx5IGNvZGVw b2ludCBhbGxvY2F0aW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+VGhpcyBhbiBJUFIgY2FsbCBmb3IgZHJhZnQtaWV0Zi1pZHItZmxvd3NwZWMtaW50ZXJmYWNl c2V0LTAyLnR4dC4mbmJzcDsgV2lsIHRoZSBhdXRob3JzIChMdWN5LCBKZWZmLCBLZXl1ciwgQWRh bSBhbmQgU3RlcGhhbmUpIHBsZWFzZSBpbmRpY2F0ZSBpZiB0aGV5IGtub3cgb2YgYW55IElQUi48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+U3VlIEhhcmVzIDxvOnA+PC9vOnA+PC9wPg0KPHByZSBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMg cGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2 aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+cGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3Bp ZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVy cmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXI8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij5hIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBx dWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBz dXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNp IGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS48bzpw PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5UaGlzIG1lc3Nh Z2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmls ZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OzxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPnRoZXkgc2hvdWxkIG5vdCBi ZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPklmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBh bmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkFzIGVtYWlscyBtYXkgYmUgYWx0 ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1v ZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5UaGFuayB5b3UuPG86cD48L286cD48L3ByZT4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_01E0501BFE6B4930B9E50978B8BB315Fnokiacom_-- From nobody Fri Feb 24 09:41: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 F05AB129440; Fri, 24 Feb 2017 09:41:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 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, RCVD_IN_MSPIKE_H2=-1.887, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.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 JjVyhfTPNsNy; Fri, 24 Feb 2017 09:41:38 -0800 (PST) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) (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 DD0FB12943F; Fri, 24 Feb 2017 09:41:37 -0800 (PST) Received: from pure.maildistiller.com (unknown [10.110.50.29]) by dispatch1-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTP id 4343B80067; Fri, 24 Feb 2017 17:41:31 +0000 (UTC) X-Virus-Scanned: Proofpoint Essentials engine Received: from mx2-us1.ppe-hosted.com (unknown [10.110.49.251]) by pure.maildistiller.com (Proofpoint Essentials ESMTP Server) with ESMTPS id C052160049; Fri, 24 Feb 2017 17:41:30 +0000 (UTC) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01lp0183.outbound.protection.outlook.com [216.32.180.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx2-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 913A180094; Fri, 24 Feb 2017 17:41:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector1-arrcus-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2vkzl58P0FwM01zSWHgNZkjLQbpuyVW7smIZB2v3AKU=; b=R9L5QMYVYEOz+jEUNw/jSrh1T5Ldz5xv0lIe1+He4qi4+r1TRzYsL6MLZACFwp8Q0I4oaKO6XxZVWQruG/F//aGF2yXpJLw2TdZzNfWBQmBImrLmdb05SGOKgBeKpifGCVKqtOhGgmNVDsmAWwYAVS4xHjJfP4UEa2F825Y0zv0= Received: from BY2PR18MB0262.namprd18.prod.outlook.com (10.163.72.152) by BY2PR18MB0263.namprd18.prod.outlook.com (10.163.72.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.13; Fri, 24 Feb 2017 17:41:23 +0000 Received: from BY2PR18MB0262.namprd18.prod.outlook.com ([10.163.72.152]) by BY2PR18MB0262.namprd18.prod.outlook.com ([10.163.72.152]) with mapi id 15.01.0919.018; Fri, 24 Feb 2017 17:41:23 +0000 From: Keyur Patel To: "stephane.litkowski@orange.com" , "Susan Hares" , "idr@ietf.org" Thread-Topic: draft-ietf-idr-flowspec-interfaceset - IPR call prior to call for WG early codepoint allocation Thread-Index: AdKOCb5vJ70pxN6ZSw2MDtc/sHwnmgAbsQ+AAAJptAA= Date: Fri, 24 Feb 2017 17:41:23 +0000 Message-ID: <79D51D5B-5C85-4883-9362-858B10031B4A@arrcus.com> References: <008501d28e09$c9cd23c0$5d676b40$@ndzh.com> <6867_1487925156_58AFEFA4_6867_8643_1_9E32478DFA9976438E7A22F69B08FF921DD0FD1A@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: <6867_1487925156_58AFEFA4_6867_8643_1_9E32478DFA9976438E7A22F69B08FF921DD0FD1A@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=keyur@arrcus.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [96.68.143.133] x-ms-office365-filtering-correlation-id: 14cec17d-465b-41ca-2b3a-08d45cdc5a0a x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BY2PR18MB0263; x-microsoft-exchange-diagnostics: 1; BY2PR18MB0263; 7:Bh6JjMayJVNpVo32S+yPmVYatEfUEDayVnDPEcez9hXwR35idZ5VUZL7DnyxFS2taQxw7sRRD+89Se0b7TmZZU7gf/xUQIaix2khQGE3bhb6kHA/85guw6b/5eW6Vx+7zpgxV4OoR+TMoBD7352xWJpQ608tR4hTrsJEtNGD84ooiZTFDf5FRn4eXIe3Zh99eGARUXQmfognvj3vmXno3L4smg6DYQITU+MaC7YJ+uWmcsutl/Xhdx++iQU6Te/NvlzI97bmM6afMN2dWwxXqEDZRNypeFq3Ffb/D+VpUG3QoHPpPv2HCOFuqOTVdosTslcbCh8ukXikrsF/MneeBg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(82608151540597)(18271650672692)(21748063052155)(50582790962513); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123562025)(20161123564025)(20161123555025)(20161123560025)(2016111802025)(20161123558025)(6072148)(6043046); SRVR:BY2PR18MB0263; BCL:0; PCL:0; RULEID:; SRVR:BY2PR18MB0263; x-forefront-prvs: 0228DDDDD7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(189002)(377454003)(199003)(2950100002)(5660300001)(6436002)(92566002)(189998001)(97736004)(6506006)(229853002)(77096006)(83716003)(6486002)(25786008)(2501003)(8676002)(86362001)(5890100001)(66066001)(82746002)(81156014)(2900100001)(81166006)(6512007)(54896002)(6306002)(99286003)(122556002)(4326007)(33656002)(6116002)(106356001)(105586002)(6246003)(53936002)(36756003)(3660700001)(50986999)(68736007)(8936002)(53546006)(2906002)(54356999)(3846002)(76176999)(102836003)(7736002)(230783001)(101416001)(3280700002)(38730400002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR18MB0263; H:BY2PR18MB0262.namprd18.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: arrcus.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_79D51D5B5C8548839362858B10031B4Aarrcuscom_" MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2017 17:41:23.7447 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR18MB0263 X-MDID: 1487958091-GNcpV8xW1sZJ Archived-At: Cc: "draft-ietf-idr-flowspec-interfaceset@ietf.org" Subject: Re: [Idr] draft-ietf-idr-flowspec-interfaceset - IPR call prior to call for WG early codepoint allocation X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 17:41:40 -0000 --_000_79D51D5B5C8548839362858B10031B4Aarrcuscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiByZWdhcmRpbmcgdGhpcyBkb2N1bWVudC4NCg0KUmVn YXJkcywNCktleXVyDQoNCkZyb206ICJzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbSIgPHN0 ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPg0KRGF0ZTogRnJpZGF5LCBGZWJydWFyeSAyNCwg MjAxNyBhdCAxMjozMiBBTQ0KVG86IFN1c2FuIEhhcmVzIDxzaGFyZXNAbmR6aC5jb20+LCAiaWRy QGlldGYub3JnIiA8aWRyQGlldGYub3JnPg0KQ2M6ICJkcmFmdC1pZXRmLWlkci1mbG93c3BlYy1p bnRlcmZhY2VzZXRAaWV0Zi5vcmciIDxkcmFmdC1pZXRmLWlkci1mbG93c3BlYy1pbnRlcmZhY2Vz ZXRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogZHJhZnQtaWV0Zi1pZHItZmxvd3NwZWMtaW50ZXJm YWNlc2V0IC0gSVBSIGNhbGwgcHJpb3IgdG8gY2FsbCBmb3IgV0cgZWFybHkgY29kZXBvaW50IGFs bG9jYXRpb24NClJlc2VudC1Gcm9tOiA8YWxpYXMtYm91bmNlc0BpZXRmLm9yZz4NClJlc2VudC1U bzogPHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPiwgPGpoYWFzQGp1bmlwZXIubmV0Piwg PGFkYW0uc2ltcHNvbkBub2tpYS5jb20+LCA8a2V5dXJAYXJyY3VzLmNvbT4sIDxsdWN5LnlvbmdA aHVhd2VpLmNvbT4NClJlc2VudC1EYXRlOiBGcmlkYXksIEZlYnJ1YXJ5IDI0LCAyMDE3IGF0IDEy OjMyIEFNDQoNCknigJltIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHJlZ2FyZGluZyB0aGlzIGRvY3Vt ZW50DQoNCkZyb206IFN1c2FuIEhhcmVzIFttYWlsdG86c2hhcmVzQG5kemguY29tXQ0KU2VudDog VGh1cnNkYXksIEZlYnJ1YXJ5IDIzLCAyMDE3IDIwOjIwDQpUbzogaWRyQGlldGYub3JnDQpDYzog ZHJhZnQtaWV0Zi1pZHItZmxvd3NwZWMtaW50ZXJmYWNlc2V0QGlldGYub3JnDQpTdWJqZWN0OiBk cmFmdC1pZXRmLWlkci1mbG93c3BlYy1pbnRlcmZhY2VzZXQgLSBJUFIgY2FsbCBwcmlvciB0byBj YWxsIGZvciBXRyBlYXJseSBjb2RlcG9pbnQgYWxsb2NhdGlvbg0KDQpUaGlzIGFuIElQUiBjYWxs IGZvciBkcmFmdC1pZXRmLWlkci1mbG93c3BlYy1pbnRlcmZhY2VzZXQtMDIudHh0LiAgV2lsIHRo ZSBhdXRob3JzIChMdWN5LCBKZWZmLCBLZXl1ciwgQWRhbSBhbmQgU3RlcGhhbmUpIHBsZWFzZSBp bmRpY2F0ZSBpZiB0aGV5IGtub3cgb2YgYW55IElQUi4NCg0KU3VlIEhhcmVzDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cg0KDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIg ZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRv aXZlbnQgZG9uYw0KDQpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5z IGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2 ZXVpbGxleiBsZSBzaWduYWxlcg0KDQphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5z aSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFu dCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KDQpPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNw b25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZp ZS4gTWVyY2kuDQoNCg0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29u dGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBw cm90ZWN0ZWQgYnkgbGF3Ow0KDQp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQg b3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUg dGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQoNCkFzIGVtYWlscyBtYXkgYmUgYWx0 ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1v ZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCg0KVGhhbmsgeW91Lg0K --_000_79D51D5B5C8548839362858B10031B4Aarrcuscom_ Content-Type: text/html; charset="utf-8" Content-ID: <0F73C9D0977B3640B4BEB7C2FA403A69@namprd18.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9s bG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bDsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6Q2FsaWJy aTsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0 eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNv dXJpZXI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ubXNv SW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHJlZ2FyZGlu ZyB0aGlzIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+S2V5dXI8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+JnF1b3Q7c3RlcGhh bmUubGl0a293c2tpQG9yYW5nZS5jb20mcXVvdDsgJmx0O3N0ZXBoYW5lLmxpdGtvd3NraUBvcmFu Z2UuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5GcmlkYXksIEZlYnJ1YXJ5IDI0LCAyMDE3IGF0 IDEyOjMyIEFNPGJyPg0KPGI+VG86IDwvYj5TdXNhbiBIYXJlcyAmbHQ7c2hhcmVzQG5kemguY29t Jmd0OywgJnF1b3Q7aWRyQGlldGYub3JnJnF1b3Q7ICZsdDtpZHJAaWV0Zi5vcmcmZ3Q7PGJyPg0K PGI+Q2M6IDwvYj4mcXVvdDtkcmFmdC1pZXRmLWlkci1mbG93c3BlYy1pbnRlcmZhY2VzZXRAaWV0 Zi5vcmcmcXVvdDsgJmx0O2RyYWZ0LWlldGYtaWRyLWZsb3dzcGVjLWludGVyZmFjZXNldEBpZXRm Lm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UkU6IGRyYWZ0LWlldGYtaWRyLWZsb3dzcGVj LWludGVyZmFjZXNldCAtIElQUiBjYWxsIHByaW9yIHRvIGNhbGwgZm9yIFdHIGVhcmx5IGNvZGVw b2ludCBhbGxvY2F0aW9uPGJyPg0KPGI+UmVzZW50LUZyb206IDwvYj4mbHQ7YWxpYXMtYm91bmNl c0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5SZXNlbnQtVG86IDwvYj4mbHQ7c3RlcGhhbmUubGl0a293 c2tpQG9yYW5nZS5jb20mZ3Q7LCAmbHQ7amhhYXNAanVuaXBlci5uZXQmZ3Q7LCAmbHQ7YWRhbS5z aW1wc29uQG5va2lhLmNvbSZndDssICZsdDtrZXl1ckBhcnJjdXMuY29tJmd0OywgJmx0O2x1Y3ku eW9uZ0BodWF3ZWkuY29tJmd0Ozxicj4NCjxiPlJlc2VudC1EYXRlOiA8L2I+RnJpZGF5LCBGZWJy dWFyeSAyNCwgMjAxNyBhdCAxMjozMiBBTTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SeKAmW0gbm90 IGF3YXJlIG9mIGFueSBJUFIgcmVnYXJkaW5nIHRoaXMgZG9jdW1lbnQ8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OlRhaG9tYSI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlRhaG9tYSI+IFN1c2FuIEhhcmVzIFttYWlsdG86c2hh cmVzQG5kemguY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBGZWJydWFyeSAyMywg MjAxNyAyMDoyMDxicj4NCjxiPlRvOjwvYj4gaWRyQGlldGYub3JnPGJyPg0KPGI+Q2M6PC9iPiBk cmFmdC1pZXRmLWlkci1mbG93c3BlYy1pbnRlcmZhY2VzZXRAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gZHJhZnQtaWV0Zi1pZHItZmxvd3NwZWMtaW50ZXJmYWNlc2V0IC0gSVBSIGNhbGwg cHJpb3IgdG8gY2FsbCBmb3IgV0cgZWFybHkgY29kZXBvaW50IGFsbG9jYXRpb248L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGFuIElQUiBjYWxsIGZv ciBkcmFmdC1pZXRmLWlkci1mbG93c3BlYy1pbnRlcmZhY2VzZXQtMDIudHh0LiZuYnNwOyBXaWwg dGhlIGF1dGhvcnMgKEx1Y3ksIEplZmYsIEtleXVyLCBBZGFtIGFuZCBTdGVwaGFuZSkgcGxlYXNl IGluZGljYXRlIGlmIHRoZXkga25vdyBvZiBhbnkgSVBSLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5TdWUgSGFyZXMgPG86cD48L286cD48L3A+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5DZSBtZXNzYWdlIGV0IHNlcyBw aWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50 aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmM8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT5wYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9y aXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxl eiBsZSBzaWduYWxlcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmEgbCdleHBlZGl0ZXVyIGV0IGxl IGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVj dHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sPG86cD48L286cD48L3By ZT4NCjxwcmU+T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2Fn ZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlRoaXMgbWVzc2FnZSBhbmQg aXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGlu Zm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7PG86cD48L286cD48L3ByZT4N CjxwcmU+dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRo b3V0IGF1dGhvcmlzYXRpb24uPG86cD48L286cD48L3ByZT4NCjxwcmU+SWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBk ZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuPG86cD48L286cD48L3ByZT4N CjxwcmU+QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3Ig bWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRoYW5rIHlvdS48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_79D51D5B5C8548839362858B10031B4Aarrcuscom_-- From nobody Fri Feb 24 10:05: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 6693F12944C; Fri, 24 Feb 2017 10:05:08 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 zwqks5DsVNvA; Fri, 24 Feb 2017 10:05:05 -0800 (PST) Received: from BAY004-OMC3S15.hotmail.com (bay004-omc3s15.hotmail.com [65.54.190.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 531DD12945F; Fri, 24 Feb 2017 10:05:05 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com ([65.54.190.189]) by BAY004-OMC3S15.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Fri, 24 Feb 2017 10:05:04 -0800 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=k7bc2Mup9gC5iL7apsALptW0M+pFo0OEoDDx83GvS8c=; b=npZcfe+L3s33GOoXy7T1lrIAReCMX30ML0p8rxQu+jrV1NtmqvA8Rs1iuWeocryjD8pdcXoTrO9640k+SGZ7z20Sl+roidFI0Cc76VPpzC4wFKHN+bt+2TXG3oWovjdmnRlSwCAkNu5k7OkggNOnLwJTu3OrrEmmecmXejggnma3F+v6hP3XGIpk5mF3oyUclu6rUMyaYt16bUxKUbrBh6sDCXypnNpsLQfk8QYwnJj3Tj0irITkjfHi2CcMqUuJuhVIx8q0AFbiSHcCQaLPXHsewVvyN6/KCoLr3mCy/6ssKinxDTlISXMh1tTN7Oug+lZA/AF21lCHlkoRCxNFuA== Received: from SN1NAM02FT033.eop-nam02.prod.protection.outlook.com (10.152.72.59) by SN1NAM02HT115.eop-nam02.prod.protection.outlook.com (10.152.73.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.10; Fri, 24 Feb 2017 18:05:03 +0000 Received: from DM3PR13MB0604.namprd13.prod.outlook.com (10.152.72.60) by SN1NAM02FT033.mail.protection.outlook.com (10.152.72.133) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.10 via Frontend Transport; Fri, 24 Feb 2017 18:05:03 +0000 Received: from DM3PR13MB0604.namprd13.prod.outlook.com ([10.164.8.150]) by DM3PR13MB0604.namprd13.prod.outlook.com ([10.164.8.150]) with mapi id 15.01.0933.011; Fri, 24 Feb 2017 18:05:03 +0000 From: Shitanshu Shah To: "Black, David" , "tsv-art@ietf.org" Thread-Topic: Review of draft-ietf-idr-sla-exchange-10 Thread-Index: AQHSjJJLT08h8arb7kKXAYa1wCM/2KF32nBggAB4pYCAACEyqw== Date: Fri, 24 Feb 2017 18:05:02 +0000 Message-ID: References: <148771630812.19122.17152051080250251501.idtracker@ietfa.amsl.com> , 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=hotmail.com; x-incomingtopheadermarker: OriginalChecksum:B9E947B70435A1E9A89403BB8F68D449ED89013DCE32C30411F1405A643B00AB; UpperCasedChecksum:D36E9CFD16BE57215670AEDB58518ABC2868835187B1A1C2C97B4E0575452C11; SizeAsReceived:8146; Count:40 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [qIfDCqBQ3MQIDxFbQ7cukkNueWqwPaGz] x-incomingheadercount: 40 x-eopattributedmessage: 0 x-microsoft-exchange-diagnostics: 1; SN1NAM02HT115; 5:p2VLU54M1dff+5cq5CzghmTFml8kwuLDzCtTWPQB16j5rNFUB06xuf4u7L2/05lRlO4rrlYfZ/rJ0MT6cPzd4lphNF6CZWDdNHWaeNGK8Ecrhl4nJXEuPuJDwAXqe+Q7G1toVrPN+yXQGRXWx1KBs0a9y8J6fSnLS4BI/bDHuAI=; 24:YGIpWTmEWdAUR1HOhkbg44deElYZ0HGkum21pnqXd7ohThW7leOvGptqdzOM3qVT5KFfSUX0qlJGIXdH4twvTXthR7uLwEeZXq1mKzEJ8d4=; 7:N7ht5VKaKAsTL4FH9ZoPmQ0PKc9IQY3EdR+lyQFdnTIcx+ARfoeMdqL9mJqp3d+R9+enlmuihCqgKH7ctTZ5Ztoywx4jrG+W9/M6KjdZI3fRZYkoHQEVGORg/ofjko74Xe49To/SXeC34lahGTaZZfJ7kHLZyufFINzKkvyOVd9xMP3eQUUPhtLK01J0e0Uvz5g94RGbhSrH4QRODwbQ1Bty51m9gxNTY+daULN6htZiNNuUkQToJDXVmjF7EzEs3sYcn6MDoLqfRTcV4N8lCeMwRdXryl+F0ak9cV93/WbQ4r6J/6BSBrk/ikitKRw2 x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(10019020)(98900012); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1NAM02HT115; H:DM3PR13MB0604.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: c33233cc-3248-4f5b-80af-08d45cdfa7ea x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(1603101415)(1601125254)(1701031045); SRVR:SN1NAM02HT115; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015087)(444000031); SRVR:SN1NAM02HT115; BCL:0; PCL:0; RULEID:; SRVR:SN1NAM02HT115; x-forefront-prvs: 0228DDDDD7 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM3PR13MB0604865EC77A246609544830E5520DM3PR13MB0604namp_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2017 18:05:02.7739 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM02HT115 X-OriginalArrivalTime: 24 Feb 2017 18:05:05.0008 (UTC) FILETIME=[869B1700:01D28EC8] Archived-At: Cc: "idr@ietf.org" , "draft-ietf-idr-sla-exchange.all@ietf.org" , "ietf@ietf.org" Subject: Re: [Idr] Review of draft-ietf-idr-sla-exchange-10 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 18:05:08 -0000 --_000_DM3PR13MB0604865EC77A246609544830E5520DM3PR13MB0604namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi David, One response inline ##svshah2 ________________________________ From: Black, David Sent: Friday, February 24, 2017 8:53 AM To: Shitanshu Shah; tsv-art@ietf.org Cc: idr@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; ietf@ietf.org; = Black, David Subject: RE: Review of draft-ietf-idr-sla-exchange-10 David> Inline ... Thanks, --David From: Shitanshu Shah [mailto:shitanshu_shah@hotmail.com] Sent: Friday, February 24, 2017 4:09 AM To: Black, David; tsv-art@ietf.org Cc: idr@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; ietf@ietf.org Subject: Re: Review of draft-ietf-idr-sla-exchange-10 Hi David, Thank you for taking time for the review.. Please find our response inline ##svshah and [Med] Regards, Shitanshu ________________________________ From: David Black > Sent: Tuesday, February 21, 2017 3:31 PM To: tsv-art@ietf.org Cc: idr@ietf.org; draft-ietf-idr-sla-exchange.all@ietf= .org; ietf@ietf.org Subject: Review of draft-ietf-idr-sla-exchange-10 Reviewer: David Black Review result: Not Ready I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. When done at the time of IETF Last Call, the authors should consider this review together with any other last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this r= eview. Document: draft-ietf-idr-sla-10 Reviewer: David Black Review Date: February 21, 2017 Review result: Not Ready This is an early TSV-ART review of a working group draft, requested by the IDR Working Group. This draft defines an extension to BGP to allow exchange of traffic handling parameters (e.g., configured rates, burst sizes, drop thresholds). While this is a useful area of technology to standardize across network operators, this draft has significant problems, and parts of it could use some serious rethought. This reviewer has discussed small portions of this draft with some of the authors in the past, but this is his first comprehensive reading and review of the draft. Major Issues: [1] The draft is misnamed. This is not an SLA (Service Level Agreement) draft - it's a TCA (Traffic Conditioning Agreement) draft - see the definition of TCA in RFC 2475. This draft should start from that definition and generalize the applicability of TCA beyond Diffserv. Large areas of SLA content are not covered by this draft - for more details, see the Wikipedia article on SLA: https://en.wikipedia.org/wiki/Service-level_agreement . ##svshah, sure, we can change the term to TCA (Traffic Conditioning Agreeme= nt), which fairly represents intention in the draft, if there is no otherwi= se comment from the working group. David> That would be good, thanks. [2] Section 3.3.2.1's reuse of the TSpec construct from RFC 2115 to specify a token bucket is a good idea, but it's not a good idea to respecify that construct in terms of L2 (link-layer, e.g., Ethernet) octets, as the RFC 2115 TSpec is specified in terms of IP octets. This change to specification in terms of L2 octets results in needing the L2_OVERHEAD TLV to cope with the possible differences in L2 (link) framing overhead at sender and receiver of this information. The TSpec should be respecified at the IP layer, with L2 framing overhead left to the Producer and Consumer to factor into their calculations based on each's direct knowledge of L2 functionality and configuration in the local AS. That ought to enable elimination of the L2_OVERHEAD TLV, thereby reducing complexity. ##svshah, the purpose for advertising L2 overhead, from the Producer to the= Consumer, is to make sure traffic is well conditioned, at the egress of th= e Consumer, to avoid possible indiscriminate drops at the ingress of the Pr= oducer. In another words, the Producer is telling the Consumer to ignore it= s own link level overhead, instead use Producer's provided link level overh= ead while running frames through QoS functions (this is relevant in use-cas= es where l2 overhead of the egress link on Consumer and of ingress link on = the Producer are of different size, e.g., in the vpn/tunnel connection betw= een two peer nodes which physically may be multiple hops away). I understand your comments regarding re-using TSpec without any modificatio= n. Do you agree with the use-case of l2 differences? If yes, any suggestion= how to accommodate that? David> Specifying this in terms of IP octets implies that L2 overhead is to= be ignored on both links. That=92s simpler, and a few sentences of discus= sion about possible L2 framing differences should cover what needs to be do= ne (e.g., if traffic rates are configured in terms of L2 octets, then expla= in how each entity converts between IP traffic and L2 traffic - the draft a= lready effectively contains that explanation). ##svshah2, just to make sure that some of the real use are not left out.. For the traffic conditioning where sla established is for the ip based rate= s only, it suffices for the Producer to send rates only IP based ignoring a= ny specific of l2 overheads. Though for the cases where physical links are not to be over-run, and/or, s= la defined are based on l2 rates, the Consumer would need to know l2 overhe= ad from the Producer. Otherwise 10 byes of l2 overhead difference on 64 byt= es packets can be significant compare to on 1400 bytes packets, and thus th= e Producer does not have a way to convert rates to ip based (this can cause= functional issue), since this has to be per packet consideration. Regards, Shitanshu [3] A token bucket should have two rate-related marking parameters based on its token fill rate, i.e., min-rate, not the four rate-related marking parameters in this draft. The max-rate parameters in sections 3.3.2.5-6 ought to be specified against a second token bucket. In addition, the handling precedence algorithm in section 3.3.2.7 is an overly complex way to specify the relationship of two token buckets. All of this is even more important, because max-rate, as defined in RFC 2115, is only applicable to bursting - that max-rate for bursting often turns out to be an interface line rate, which is not generally useful for the traffic provisioning purposes of this draft. ##svshah, what you describe below conceptually very much makes sense and th= at is what we attempt to achieve. What is unclear though how to capture tha= t using TSpec definition specified in RFC2215. Since that TSpec definition = has both minimum-rate and maximum-rate, but no in/out profile marking param= eters. Is your proposal below to define two TSpecs using the same definition from = RFC2215? Wouldn't in that case we have min/max specified twice? min/max in = each TSpec? and thus confusing to represent one min and one max through two= TSpecs? David> See RFC 2698 for the desired behavior and the parameters needed to s= pecify it. The current idr-sla draft is not able to represent the traffic = conditioning mechanisms specified in both RFC 2698 and RFC 2697, as each me= chanism requires two token buckets (e.g., there are two burst sizes, but th= e idr-sla draft TSpec only contains one). This deficiency needs to be deal= t with. One possibility for simplification is to drop the max-rate from th= e RFC 2115 TSpec and assume that the max-rate for bursting is the effective= line rate. The following should be done instead: - Define TSpecs for two token buckets, a primary/committed token bu= cket and a secondary/peak token bucket that MUST be nested, i.e.= , traffic that is in-profile for the secondary/peak token bucket is a= lways in-profile for the primary/committed token bucket. Some of= the details of how to specify this are subtle, see RFC 2698 for a worke= d example. Use of a secondary/peak token bucket requires use of the pr= imary/ committed token bucket, but a primary/committed token bucke= t can be used without a secondary/peak token bucket. - For a single token bucket, define two handling TLVs, Committed (i= n profile) and Excess (out of profile). - For two token buckets, define three handling TLVs, Committed (in = profile for both token buckets), Peak (out of profile for primary/committed = token bucket, but in profile for secondary/peak token bucket) and Excess (out of= profile for both token buckets). NB: Could use Green/Yellow/Red terms instead of Committed/Peak/Excess terms. [4] The drop threshold TLV in section 3.3.2.8 is not specified sufficiently to be implemented interoperably. For example, I don't understand what an implementation is supposed to do when it receives 3 drop thresholds. ##svshah, It is around the semantics of a single queue with a different thr= eshold for a set of code-points, where packet for a specific code-point is = to be tail dropped if overall queue-depth hits code-point specific threshol= d at the arrival of that packet. We will add appropriate clarification for this semantics. David> Will look at revision [5] The relative priority TLV in section 3.3.2.9 has the same insufficient specification problem as the drop threshold TLV, compounded by a functional incompleteness problem - if the recipient is using a weighted packet transmission scheduler (e.g., WRR), priorities cannot be used to configure that scheduler. Hence, some specification of weights and scheduling algorithms that use weights needs to be added. ##svshah, Sure. Is following clarification okay? (some of the wordings take= n from RFC2598) " A higher priority class of traffic to be served without pre-empted by lower= priority class of traffic for more than a packet time at the configured ra= te. In the system that implements WRR, the use of relative priority may get res= tricted where a single queue may be used for a higher priority traffic clas= s where that queue is configured for the full share of the output bandwidt= h. " David> Last sentence basically says that WRR weights are out-of-scope. Tha= t seems wrong. Will look at revision. [6] I have no idea what the sub-traffic classes TLV in section 3.3.2.10 is supposed to do, as that TLV is specified based on "Traffic Class TLVs" which is an undefined term in this draft (e.g., that term is not used outside of section 3.3.2.10. ##svshah, They are to facilitate hierarchy. A specific Traffic Class, can f= urther be divided in a multiple subset of Traffic Classes, with their own = Traffic Class Elements and Traffic Class Services. Will correct the wording to remove your this specific concern. David> Will look at revision [7] This draft's QoS contents need to be functionally aligned with work-in-progress on YANG QoS models, in order to provide some assurance that that this draft is implementable for actual network switch/router data paths. The current acknowledgement of the existence of YANG, NETCONF and RESTConf at the end of Section 1 does not suffice. ##svshah, While eventually "Traffic Conditioning Agreement" should be trans= lated to the actual forwarding qos policy on any vendor specific device, TC= A exchange largely carries concepts/semantics that is either standard based= or well understood. While we are not aware of any working group document of QoS Yang Model, we = think that concepts of Traffic Conditioning should be easily adaptable to = any QoS Yang Models since they also have to be defined to support those con= cepts. David> Still want to see cross-check with implementations here. [8] There are significant complexity and correctness problems caused by the option to not specify the Source AS - e.g., Section 3.2 defines an SLA ID as an "identifier which is unique in the scope of Source AS" which is meaningless if there is no Source AS. It would be simpler to always specify Source AS, even in the point-to-point case. ##svshah, okay. Ron Bonica also suggested same in his review earlier. We ha= d chosen a path of optional Source AS to simplify implementations in cases.= Given specification of Source AS always is more clearer in multiple feed-b= ack we have gotten so far, we can modify the specification to incorporate t= hat over the simplicity of implementation for certain cases. David> OK, thanks. [9] In section 3.2, the "intended for the peer receiver of the BGP UPDATE message" text in the specification of bit 0 of the SLA Subtype flags is unclear. I suspect that this is intended to differentiate the two usages described in sections 4.1.1 (Point-to-Point) and 4.1.2 (Multiple Hops), in which case the parenthesized terms (or similar terminology) should be used with cross-references to those two sections. ##svshah, sure will make necessary changes, also in the context of earlier = comment. [10] There needs to be a coherent discussion in one place about how SLA advertisement, update and withdrawal work. A single ADVERTISE method may suffice on the wire, but the details on how initial advertisement, subsequent advertisement (update) and withdrawal work need to be specified in one place. The third paragraph of Section 4 is a start on this material, but it's too terse; [Med] That text is terse because we are reusing the BGP machinery for adver= tising/withdrawing; we only augment it with triggers that are linked to the= SLA information. A new SLA will lead to an update message with ADVERTISE, = an update of an existing SLA will trigger an update message. We do think th= is information is already present in the document. David>This is hard to understand it, as there is no statement that the BGP = machinery is being used, and the material on SLA usage is spread in differe= nt places. I suggest starting section 3 with a discussion of advertisement= /update/withdrawal, and how all three are realized via a single ADVERTISE m= ethod via BGP UPDATE - this was difficult to figure out in reading the curr= ent draft. it should be expanded into its own subsection, and moved earlier to come before the ADVERTISE method in Section 3.2. This text from Section 3.2 should be moved into that new subsection and likewise expanded: [Med] Another option is to move it Section 4. From our standpoint, we do th= ink it is straightforward to describe the behavior once the attributes form= at are defined. David> Ok, that=92s an editorial choice - I prefer to explain how something= works before defining its on-the-wire data format. If an advertised SLA ID is different from earlier advertised one, for the same prefix and from the same Source AS, indicates Source AS is advertising new SLA Content to replace the previous one advertised with the same SLA ID. In addition, I wonder whether functionality should be added to allow withdrawal of an advertisement by specifying its SLA ID, although that was not part of the original design. [Med] The reason we didn=92t adopted that design is that we don=92t want to= make assumptions on which data the remote peer will be used for enforcing = local actions and also because of this text: The SLA ID applies to aggregate traffic to prefixes for a given AFI/SAFI that share the same Source AS and SLA ID. David> That=92s fine, I wanted to ensure that this had been considered. Th= e discussion of BGP mechanism reuse will probably help here. [11] Notions of context for interpretation of all the IPFIX parameters in 3.3.1 need to be added, e.g.: - The first three parameters (DSCP, MPLS EXP field in top label, 80= 2.1q priority) can and do vary on a link-by-link or LSP-by-LSP basis along a t= raffic's network path. - The IP address parameters are rather likely to be VPN-specific wh= en there's more than one BGP/MPLS VPN that spans or transits the ASs involv= ed. - The transport port parameters need specification of which transpo= rt header and where it is located (e.g., for TCP traffic carried by in VXLAN, is t= his the inner TCP header or the outer UDP header in VXLAN). There are probably simple approaches to specifying context in all cases, but that context does need to be specified ... in all cases. [Med] We dind=92t include a context field because we thought that the defin= ition of the IPFIX attributes is sufficient by itself, but if you do think = it is helpful to have such information, we can update the table. David> Really??? Please reread the first comment above: - The first three parameters (DSCP, MPLS EXP field in top label, 80= 2.1q priority) can and do vary on a link-by-link or LSP-by-LSP basis along a t= raffic's network path. David> Taking just DSCP, it can change on a per-link basis, so something h= as to specify which link (between the SLA Producer and SLA Consumer?) is in= volved. It probably suffices to say that it=92s the link that crosses the = relevant AS boundary, but that does have to be stated, as it=92s nowhere to= be found in the far more general IPFIX registry. [12] The security considerations (section 10) are severely incomplete and insufficient: David> I stand by this statement and recommend a complete rewrite of the se= curity considerations. - Discussion of possible abuse of this BGP option for denial-of-ser= vice and theft-of-service, needs to be added, including possible countermeasures and m= itigations. [Med] This attack vector is not specific to this attribute; this is valid f= or BGP in general. David> There are additional attacks enabled by this attribute. - This sentence at the end of the second paragraph in Section 10 is= content-free: It is NOT RECOMMENDED to enable this attribute at the scale of the Internet unless if means to prevent leaking= sensitive information are enforced. What exactly is an implementer or admin supposed to do? [Med] An example of what an admin needs to check if this information can be= sent to a given peer or not. Some of the content of the attribute contains= some sensitive information such as contract Id, classes, etc. How does one figure out whether an implementation or deployment is "at = the scale of the Internet" ?? [Med] The idea here is to avoid leaking such data in to the global routing = table. Only entitled peers need receive such information with controlled sc= ope. David> I understand the idea - the problem is that I don=92t see specificat= ion of what has to be implemented in either the text in the draft or the ab= ove explanations. - The next to last paragraph in section 10 is almost content-free, = as it leaves decisions on implementation and deployment of key security = functionality as "an exercise for the reader" - that's not acceptable. [Med] I guess you are referring to the following text. Validation checks ar= e really deployment-specific. The text calls out the issue and recommends a= n action; how to translate this action into detailed actions is realty loca= l to a domain The attribute may be advertised by a misbehaving node to communicate SLA parameters that are not aligned with the SLA agreements. Though the enforcement of SLA parameters is outside the scope of this document, it is RECOMMENDED that the SLA Consumer to enforce a set of validation checks before translating the SLA parameters conveyed in the QoS attributes into provisioning actions. Such validations MAY rely on SLA parameters like the origin AS or SLA ID, like generating SLA ID using pseudo-random schemes [RFC4086]. David> I stand by the =93exercise to the reader=94 criticism - one way to = be honest about this would be to change the paragraph to: The attribute may be advertised by a misbehaving node to communicat= e SLA parameters that are not aligned with the SLA agreements. The enforcement of SLA parameters is outside the scope of this document. David> That does not change any normative content of the original paragraph= . My view is that the =93outside the scope of this document=94 statement i= s wrong because all of these parameters are being defined in this draft. - Last, but not least, the final paragraph in Section 10 is a joke = that will be lost on a security directorate reviewer - to understand = why, see Section 2 of RFC 6919, and take note of the publication dat= e of RFC 6919. David> For anyone who didn=92t catch the reference, RFC 6919 is an April 1 = RFC ... and the =93SHOULD BE considered=94 language used in the last securi= ty considerations paragraph of this draft is accurately characterized as va= gue in Section 2 of RFC 6919: The phrase "SHOULD CONSIDER" indicates that the authors of the specification think that implementations should do something, but they're not sure quite what. ------------------------ Having noted a dozen major issues, I'll end the review here for now, as I believe a serious revision of the draft is called for, which would be a better starting point to review for minor issues and editorial items. -------------------------------------------------------- David L. Black, Distinguished Engineer Dell EMC, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 Cell: +1 (978) 394-7754 David.Black@dell.com <=3D=3D=3D NEW =3D=3D=3D -------------------------------------------------------- --_000_DM3PR13MB0604865EC77A246609544830E5520DM3PR13MB0604namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable


Hi David,


One response inline ##svshah2



= From: Black, David <David.Black@dell.com>
Sent: Friday, February 24, 2017 8:53 AM
To: Shitanshu Shah; tsv-art@ietf.org
Cc: idr@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; ietf@iet= f.org; Black, David
Subject: RE: Review of draft-ietf-idr-sla-exchange-10
 

David> Inline ...

 

Thanks, --David<= /p>

 

From: Shitan= shu Shah [mailto:shitanshu_shah@hotmail.com]
Sent: Friday, February 24, 2017 4:09 AM
To: Black, David; tsv-art@ietf.org
Cc: idr@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; ietf@iet= f.org
Subject: Re: Review of draft-ietf-idr-sla-exchange-10

 

 

Hi David,

 

Thank you for taking time for th= e review..

 

Please find our response inline = ##svshah and [Med]

 

Regards,

= Shitanshu

From: David Black <david.black@emc.com>
Sent: Tuesday, February 21, 2017 3:31 PM
To: tsv-art@ietf.org
Cc: idr@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; ietf@ietf.org
Subject: Review of draft-ietf-idr-sla-exchange-10

 

Reviewer: David Black
Review result: Not Ready

I've reviewed this document as part of the transport area
directorate's ongoing effort to review key IETF documents. These
comments were written primarily for the transport area directors, but
are copied to the document's authors for their information and to
allow them to address any issues raised. When done at the time of IETF
Last Call, the authors should consider this review together with any
other last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or= forward this review.

Document: draft-ietf-idr-sla-10
Reviewer: David Black
Review Date: February 21, 2017

Review result: Not Ready

This is an early TSV-ART review of a working group draft, requested by
the IDR Working Group.

This draft defines an extension to BGP to allow exchange of traffic
handling parameters (e.g., configured rates, burst sizes, drop
thresholds).  While this is a useful area of technology to standardize=
across network operators, this draft has significant problems, and
parts of it could use some serious rethought.

This reviewer has discussed small portions of this draft with some of
the authors in the past, but this is his first comprehensive reading
and review of the draft.

Major Issues:

[1] The draft is misnamed.  This is not an SLA (Service Level
Agreement) draft - it's a TCA (Traffic Conditioning Agreement) draft -
see the definition of TCA in RFC 2475.  This draft should start from that definition and generalize the applicability of TCA beyond
Diffserv.  Large areas of SLA content are not covered by this draft -<= br> for more details, see the Wikipedia article on SLA:
https://en.wikipedia.org/wiki/Service-lev= el_agreement .

##svshah, sure, we can change the term to TCA (Traffic Conditioning Agreeme= nt), which fairly represents intention in the draft, if there is no otherwi= se comment from the working group.

 

=
David> That would be good, thanks.

[2] Section 3.3.2.1's reuse of the TSpec construct from RFC 2115 to
specify a token bucket is a good idea, but it's not a good idea to
respecify that construct in terms of L2 (link-layer, e.g., Ethernet)
octets, as the RFC 2115 TSpec is specified in terms of IP octets.
This change to specification in terms of L2 octets results in needing
the L2_OVERHEAD TLV to cope with the possible differences in L2 (link)
framing overhead at sender and receiver of this information.  The
TSpec should be respecified at the IP layer, with L2 framing overhead
left to the Producer and Consumer to factor into their calculations
based on each's direct knowledge of L2 functionality and configuration
in the local AS.  That ought to enable elimination of the L2_OVERHEAD<= br> TLV, thereby reducing complexity.

##svshah, the purpose for= advertising L2 overhead, from the Producer to the Consumer, is to mak= e sure traffic is well conditioned, at the egress of the Consumer, to avoid possible indiscriminate drops at the ingress of the Producer. In = another words, the Producer is telling the Consumer to ignore its= own link level overhead, instead use Producer's provided link level overhe= ad while running frames through QoS functions (this is relevant in use-cases where l2 overhead of the egress l= ink on Consumer and of ingress link on the Producer are of different size, = e.g., in the vpn/tunnel connection between two peer nodes which p= hysically may be multiple hops away).

I understand your comment= s regarding re-using TSpec without any modification. Do you agree with= the use-case of l2 differences? If yes, any suggestion how to accommodate that?

 

David> Specifying th= is in terms of IP octets implies that L2 overhead is to be ignored on both = links.  That=92s simpler, and a few sentences of discussion about possible L2 framing differences should cover what needs to be done (e.g., = if traffic rates are configured in terms of L2 octets, then explain how eac= h entity converts between IP traffic and L2 traffic - the draft already eff= ectively contains that explanation).


##svshah2, just to make sure that some of the real use are not left o= ut..


For th= e traffic conditioning where sla established is for the ip based rates only= , it suffices for the Producer to send rates only IP based ignoring an= y specific of l2 overheads.


Though= for the cases where physical links are not to be over-run, = and/or, sla defined are based on l2 rates, the Consumer would nee= d to know l2 overhead from the Producer. Otherwise 10 byes of l2 overhead difference on 64 bytes packets can be significant compare to on 1= 400 bytes packets, and thus the Producer does not have a way to convert rat= es to ip based (this can cause functional issue), since this has to be= per packet consideration.


Regard= s,

Shitan= shu





[3] A token bucket should have two rate-related marking parameters
based on its token fill rate, i.e., min-rate, not the four
rate-related marking parameters in this draft.  The max-rate
parameters in sections 3.3.2.5-6 ought to be specified against a
second token bucket.  In addition, the handling precedence algorithm in section 3.3.2.7 is an overly complex way to specify the
relationship of two token buckets.  All of this is even more
important, because max-rate, as defined in RFC 2115, is only
applicable to bursting - that max-rate for bursting often turns out to
be an interface line rate, which is not generally useful for the
traffic provisioning purposes of this draft.

 

##svshah, what you descri= be below conceptually very much makes sense and that is what we attempt to = achieve. What is unclear though how to capture that using TSpec definition specified in RFC2215. Since that TSpec definition has bot= h minimum-rate and maximum-rate, but no in/out profile marking parameters.<= /span>

 

Is your proposal below to= define two TSpecs using the same definition from RFC2215? Wouldn't in= that case we have min/max specified twice? min/max in each TSpec? and thus confusing to represent one min and one max through two TSpecs?

 

David> See RFC 2698 = for the desired behavior and the parameters needed to specify it.  The= current idr-sla draft is not able to represent the traffic conditioning mechanisms specified in both RFC 2698 and RFC 2697, as each mechanism requ= ires two token buckets (e.g., there are two burst sizes, but the idr-sla dr= aft TSpec only contains one).  This deficiency needs to be dealt with.=   One possibility for simplification is to drop the max-rate from the RFC 2115 TSpec and assume that the max-ra= te for bursting is the effective line rate.
The following should be done instead:
        - Define TSpecs for two token bu= ckets, a primary/committed token bucket
            &nb= sp;   and a secondary/peak token bucket that MUST be nested, i.e.= , traffic
            &nb= sp;   that is in-profile for the secondary/peak token bucket is a= lways
            &nb= sp;   in-profile for the primary/committed token bucket.  So= me of the details
            &nb= sp;   of how to specify this are subtle, see RFC 2698 for a worke= d example.
            &nb= sp;   Use of a secondary/peak token bucket requires use of the pr= imary/
            &nb= sp;   committed token bucket, but a primary/committed token bucke= t can be used
            &nb= sp;   without a secondary/peak token bucket.
        - For a single token bucket, def= ine two handling TLVs, Committed (in profile) and
            &nb= sp;   Excess (out of profile).
        - For two token buckets, define = three handling TLVs, Committed (in profile for both
            &nb= sp;   token buckets), Peak (out of profile for primary/committed = token bucket, but in
            &nb= sp;   profile for secondary/peak token bucket) and Excess (out of= profile for both
            &nb= sp;   token buckets).
NB: Could use Green/Yellow/Red terms instead of Committed/Peak/Excess
terms.

[4] The drop threshold TLV in section 3.3.2.8 is not specified
sufficiently to be implemented interoperably.  For example, I don't understand what an implementation is supposed to do when it receives 3
drop thresholds.

##svshah, It is arou= nd the semantics of a single queue with a different threshold for a se= t of code-points, where packet for a specific code-point is to be tail dropped if overall queue-depth hits code-point specific threshold at = the arrival of that packet.

We will add appropriate c= larification for this semantics.

 

David> Will look at revision


[5] The relative priority TLV in section 3.3.2.9 has the same
insufficient specification problem as the drop threshold TLV,
compounded by a functional incompleteness problem - if the recipient
is using a weighted packet transmission scheduler (e.g., WRR),
priorities cannot be used to configure that scheduler.  Hence, some specification of weights and scheduling algorithms that use weights
needs to be added.

##svshah, Sure. Is follow= ing clarification okay? (some of the wordings taken from RFC2598)

 

"

A higher priority class o= f traffic to be served without pre-empted by lower priority class= of traffic for more than a packet time at the configured rate.=

 

In the system that implem= ents WRR, the use of relative priority may get restricted where a single qu= eue may be used for a higher priority traffic class where that queue  is configured for the full share of the output bandwidth.=

"

 

David> Last sentence basically says that WRR weights are out-of-= scope.  That seems wrong.  Will look at revision.

[6] I have no idea what the sub-traffic classes TLV in section
3.3.2.10 is supposed to do, as that TLV is specified based on "Traffic=
Class TLVs" which is an undefined term in this draft (e.g., that term<= br> is not used outside of section 3.3.2.10.

##svshah, They are to fac= ilitate hierarchy. A specific Traffic Class, can further be divided in a mu= ltiple  subset of Traffic Classes, with their own Traffic Class Elements and Traffic Class Services.

 

Will correct the wording = to remove your this specific concern.


David> Will look at revision


[7] This draft's QoS contents need to be functionally aligned with
work-in-progress on YANG QoS models, in order to provide some
assurance that that this draft is implementable for actual network
switch/router data paths.  The current acknowledgement of the
existence of YANG, NETCONF and RESTConf at the end of Section 1 does
not suffice.

##svshah, While even= tually "Traffic Conditioning Agreement" should be translated to t= he actual forwarding qos policy on any vendor specific device, TCA exchange largely carries concepts/semantics that is either standard based or w= ell understood.

 

While we are not aware of= any working group document of QoS Yang Model, we think that  concepts= of Traffic Conditioning should be easily adaptable to any QoS Yang Models since they also have to be defined to support those concepts.<= /span>

 

 

David> Still want to= see cross-check with implementations here.

 

David> OK, thanks.


[9] In section 3.2, the "intended fo= r the peer receiver of the BGP
UPDATE message" text in the specific= ation of bit 0 of the SLA Subtype
flags is unclear.  I suspect that th= is is intended to differentiate
the two usages described in sections 4.1.= 1 (Point-to-Point) and 4.1.2
(Multiple Hops), in which case the parent= hesized terms (or similar
terminology) should be used with cross-re= ferences to those two
sections.

##svshah, sure will make = necessary changes, also in the context of earlier comment.

 


[10] There needs to be a coherent discuss= ion in one place about how
SLA advertisement, update and withdrawal = work.  A single ADVERTISE
method may suffice on the wire, but the d= etails on how initial
advertisement, subsequent advertisement (= update) and withdrawal work
need to be specified in one place.  = The third paragraph of Section 4
is a start on this material, but it's too= terse; 

 

[Med] That text is terse because we are reus= ing the BGP machinery for advertising/withdrawing; we only augment it with = triggers that are linked to the SLA information. A new SLA will lead to an update message with ADVERTISE, an update of an e= xisting SLA will trigger an update message. We do think this information is= already present in the document.

 

David>This is hard t= o understand it, as there is no statement that the BGP machinery is being u= sed, and the material on SLA usage is spread in different places.  I suggest starting section 3 with a discussion of advertisement/update/wit= hdrawal, and how all three are realized via a single ADVERTISE method via B= GP UPDATE - this was difficult to figure out in reading the current draft.<= /span>

 

it should be expanded
into its own subsection, and moved earlie= r to come before the
ADVERTISE method in Section 3.2.  Th= is text from Section 3.2 should be
moved into that new subsection and likewi= se expanded:

[Med] Another option is to move it Section 4. From our stand= point, we do think it is straightforward to describe the behavior once the = attributes format are defined. 

 

David> Ok, that=92s = an editorial choice - I prefer to explain how something works before defini= ng its on-the-wire data format.<= /p>

 

    &= nbsp; If an advertised SLA ID is different from earlier advertised one,
      for the sa= me prefix and from the same Source AS, indicates Source
      AS is adve= rtising new SLA Content to replace the previous one
      advertised= with the same SLA ID.

In addition, I wonder whether functionali= ty should be added to allow
withdrawal of an advertisement by specify= ing its SLA ID, although that
was not part of the original design.

 

[Med] The reason we didn=92t adopted that design is that we don=92= t want to make assumptions on which data the remote peer will be used for enforcing local actions and also because of this tex= t:

  = ;    The SLA ID applies to aggregate traffic to prefixes for= a given

  = ;    AFI/SAFI that share the same Source AS and SLA ID.

 

David> That=92s fine= , I wanted to ensure that this had been considered.  The discussion of= BGP mechanism reuse will probably help here.

[11] Notions of context for interpretatio= n of all the IPFIX parameters
in 3.3.1 need to be added, e.g.:
       = ; - The first three parameters (DSCP, MPLS EXP field in top label, 802.1q priority) can
       = ;         and do vary on a link-by-= link or LSP-by-LSP basis along a traffic's network path.
       = ; - The IP address parameters are rather likely to be VPN-specific when there's more
       = ;         than one BGP/MPLS VPN tha= t spans or transits the ASs involved.
       = ; - The transport port parameters need specification of which transport header and where it
       = ;         is located (e.g., for TCP= traffic carried by in VXLAN, is this theinner TCP header
       = ;         or the outer UDP header i= n VXLAN).
There are probably simple approaches to s= pecifying context in all
cases, but that context does need to be s= pecified ... in all cases.

[Med] We dind=92t include a context field because we thought= that the definition of the IPFIX attributes is sufficient by itself, but i= f you do think it is helpful to have such information, we can update the table.

David>  Really?= ??  Please reread the first comment above:

 

    &= nbsp;   - The first three parameters (DSCP, MPLS EXP field in top= label, 802.1q priority) can
       = ;         and do vary on a link-by-= link or LSP-by-LSP basis along a traffic's network path.

 

David>  Taking = just DSCP, it can change on a per-link basis, so something has to specify w= hich link (between the SLA Producer and SLA Consumer?) is involved.  It probably suffices to say that it=92s the link that crosses the relevant= AS boundary, but that does have to be stated, as it=92s nowhere to be foun= d in the far more general IPFIX registry.

[12] The security considerations (section= 10) are severely incomplete
and insufficient:

 

David> I stand by th= is statement and recommend a complete rewrite of the security consideration= s.


       = ; - Discussion of possible abuse of this BGP option for denial-of-service and theft-of-service,
       = ;         needs to be added, includ= ing possible countermeasures and mitigations.

[Med] This attack vector is not specific to this attribute; = this is valid for BGP in general.

 

David> There are add= itional attacks enabled by this attribute.


       = ; - This sentence at the end of the second paragraph in Section 10 is content-free:

       = ;            It is N= OT RECOMMENDED to enable this attribute at the
       = ;            scale o= f the Internet unless if means to prevent leaking sensitive
       = ;            informa= tion are enforced.

       = ;         What exactly is an implem= enter or admin supposed to do? 

 

[Med] An example of what an admin needs to c= heck if this information can be sent to a given peer or not. Some of the co= ntent of the attribute contains some sensitive information such as contract Id, classes, etc.

 

How does one
       = ;         figure out whether an imp= lementation or deployment is  "at the scale
       = ;         of the Internet" ??<= /span>



[Med] The idea here is to avoid leaking such= data in to the global routing table. Only entitled peers need receive such= information with controlled scope.

 

David> I understand = the idea - the problem is that I don=92t see specification of what has to b= e implemented in either the text in the draft or the above explanations.

    &= nbsp;   - The next to last paragraph in section 10 is almost cont= ent-free, as it leaves
       = ;         decisions on implementati= on and deployment of key security functionality as
       = ;         "an exercise for the= reader" - that's not acceptable.


[Med] I gues= s you are referring to the following text. Validation checks are really dep= loyment-specific. The text calls out the issue and recommends an action; how to translate this action into detailed actions i= s realty local to a domain

 &nbs=
p; The attribute may be advertised by a misbehaving node to communicate
 &nbs=
p; SLA parameters that are not aligned with the SLA agreements.  Thoug=
h
 &nbs=
p; the enforcement of SLA parameters is outside the scope of this

 &nbs=
p; document, it is RECOMMENDED that the SLA Consumer to enforce a set of


 &nbs=
p; validation checks before translating the SLA parameters conveyed in


 &nbs=
p; the QoS attributes into provisioning actions.  Such validations MAY=



 &nbs=
p; rely on SLA parameters like the origin AS or SLA ID, like generating


 &nbs=
p; SLA ID using pseudo-random schemes [RFC4086].




 






David> I stand by th=
e =93exercise to the reader=94  criticism - one way to be honest about=
 this would be to change the paragraph to:


 


       =
; The attribute may be advertised by a=
 misbehaving node to communicate


 &nbs=
p; SLA parameters that are not aligned with the SLA agreements.  The


   enforcement of SLA paramete=
rs is outside the scope of this document.


 


David> That does not change any normative content of the=
 original paragraph.  My view is that the =93outside the scope of this=
 document=94 statement is wrong because all of these parameters are being d=
efined in this draft.






       =
; - Last, but not least, the final paragraph in Section 10 is a joke=

that will

       =
;         be lost on a security dir=
ectorate reviewer - to understand why, see

       =
;         Section 2 of RFC 6919, an=
d take note of the publication date of RFC
6919.



David> For anyone who didn=92t catch the reference, RFC 6919 is an April=
 1 RFC ... and the =93SHOULD BE considered=94 language used in the last sec=
urity considerations paragraph of this draft is accurately characterized as=
 vague in Section 2 of RFC 6919:


   The phrase &qu=
ot;SHOULD CONSIDER" indicates that the authors of the


   specification =
think that implementations should do something, but


   they're not s=
ure quite what.


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



Having noted a dozen major issues, I'll e=
nd the review here for now,

as I believe a serious revision of the dr=
aft is called for, which

would be a better starting point to revie=
w for minor issues and

editorial items.



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

David L. Black, Distinguished Engineer

Dell EMC, 176 South St., Hopkinton, MA&nb=
sp; 01748

+1 (508) 293-7953   &n=
bsp; Cell: +1 (978) 394-7754

D=
avid.Black@dell.com  <=3D=3D=3D NEW =3D=3D=3D
-----------------------------------------=
---------------
--_000_DM3PR13MB0604865EC77A246609544830E5520DM3PR13MB0604namp_-- From nobody Sun Feb 26 19:02: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 AD054129AC6 for ; Sun, 26 Feb 2017 19:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 bpHhf4dhmS98 for ; Sun, 26 Feb 2017 19:02:15 -0800 (PST) Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:851::25]) (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 38588129AC9 for ; Sun, 26 Feb 2017 19:02:14 -0800 (PST) Received: from iamda3.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by ia-mailgw.apnic.net (Halon) with ESMTPS id 218ac948-fc99-11e6-b818-005056b6f213; Mon, 27 Feb 2017 13:02:10 +1000 (AEST) Received: from 74.148.dhcp.conference.apricot.net (203.119.101.249) by iamda3.org.apnic.net (203.119.111.31) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 27 Feb 2017 13:02:09 +1000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Geoff Huston In-Reply-To: <9C5FD3EFA72E1740A3D41BADDE0B461FC61A7A91@szxema506-mbs.china.huawei.com> Date: Mon, 27 Feb 2017 14:02:05 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <9C5FD3EFA72E1740A3D41BADDE0B461FC61A7A91@szxema506-mbs.china.huawei.com> To: "Yemin (Amy)" , X-Mailer: Apple Mail (2.3259) Archived-At: Cc: idr wg , rtg-dir@ietf.org Subject: [Idr] Routing directorate QA review of draft-ietf-idr-flowspec-interfaceset X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 03:02:18 -0000 Hi, I have been assigned the QA reviewer for this draft. there appears to be = no formal template for this review, but the general guidelines at = https://trac.ietf.org/trac/rtg/wiki/RtgDirDocQa state: "When reviewing a draft at WG Adoption, the QA Reviewer should = determine whether the draft is readable, understandable, makes sense and = is a good start for a WG draft. Any issues the QA Reviewer finds are = written down, sent to the mailing list and discussed for future = versions" So here are mo responses to these questions fter reviewing this draft: ** Is the draft readable?=20 yes ** Is the draft understandable?=20 yes, provided the reader takes to time to familiarise themselves with = the BGP flowspec structure and operation in the first place. At least I = think it is understandable - if the authors believe that I have = misinterpreted the intent of this draft then that may be a very clear = signal that it was less understandable than I thought! ** Does it make sense? Here=E2=80=99s where I have a few issues that I found in reviewing this = draft. The diagram in figures 1 and 2 appear to overuse the term =E2=80=9CPE=E2=80= =9D - it appears that this may or may not be a MPLS PE router, as in the = context of this draft it appears that they are simply EBGP speakers. It = would be helpful to clarify this. This brings on a second comment that the document is not overly clear = about the scope of intended application - the ability to declare filter = rules per interface appears to assume a detailed level of device = configuration that would only normally be accessible to a network = management - so that the intended scope of this form of flowspec = propagation is iBGP. But the example in section 2 appears to say = otherwise - the draft would benefit from some clarity over the intended = (and safe) scope of propagation of such interface flowspecs. The third comment is that the draft is a mix of motivation for the = desired mechanism, advocating the chosen solution, and the protocol = mechanisms (extension to BGP extended community set). My own personal = taste is to split this to a document about the need, and a seperate = document about the protocol mechanism and the related IANA = considerations. The fourth comment is that the section =E2=80=9CSecurity = Considerations=E2=80=9D appears to also contain some critical design = information that is conveniently ignored in the rest of the draft. A = broader document about the general problem space and the strengths and = weaknesses of various approaches to automated traffic filter management = in devices (see previous comment) would be a better place to argue the = relative merits of various forms of network automation vs the use of = signalling within BGP. Previous schools of through were that flow spec = signalling was an ideal approach to remote (inter-AS) RBH signalling, = while various in-house forms of network management would be more = approach to operate the local network. This draft does not appear to to = clearly state exactly what problem it is solving. If it is trying to = perform remote filter management in Other Peoples Networks then there = are huge security implications. The draft conveniently waves its hands = about the group identifier and its intended interpretation. This is a = large conceptual hole in the draft imho. The second part of this is also = touched upon in a passing comment in the Security Considerations, that = these filters are ephemeral in nature, as compared to a more = =E2=80=98conventional=E2=80=99 network management tool that would = maintain filters as configured elements in the device. I think what is missing relates to the observation that sure, you CAN = stuff this into BGP using extended communities, but SHOULD we do this? = What are the reasons why this particular approach makes sense over and = above other existing tools and approaches. If the role of this WG is to = document everything we COULD do in BGP then the workload may well be = infinite - if the role is to document what we SHOULD be specifying as a = BGP-based tool then this would make more sense. As a result, I suspect = that this draft could benefit from some operational perspectives. Does = this materially help network operators in attempting to respond to DDOS = attacks? Or is it just another tool in an environment already replete = with various tools and technique and as such limited adoption would = imply that it would be effectively unused by network operators. Obviously I am at this point unconvinced that it =E2=80=9Cmakes sense=E2=80= =9D in the broader sense, and rather than trying to add more words to a = single document it may be helpful to look at splitting the specification = of the proposed mechanism and the IANA instructions and the discussion = of why this particular approach to distributed filter management makes = more sense than what current operational practices rely on. regards, Geoff > On 24 Feb 2017, at 3:40 pm, Yemin (Amy) wrote: >=20 > Hi Geoff, > =20 > Please would you be the routing directorate QA reviewer for = draft-ietf-idr-flowspec-interfaceset >=20 > https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-interfaceset/ >=20 > Note that this is a =E2=80=9CQA review.=E2=80=9D The document does not = yet have consensus to be forwarded to the IESG. The goal of this review = is to provide a new perspective on the work in progress and to improve = its quality. Hence, your comments will be provided primarily for the = benefit of the IDR chairs and the document authors. > Please could you provide your comments by March, 9th, 2017? You should = send your comments to the draft authors and WG chairs, and copy the = relevant WG mailing list and the rtg-dir list. > The following web page contains a briefing on the QA process, and = guidance for the QA reviewer. > https://trac.ietf.org/trac/rtg/wiki/RtgDirDocQa >=20 > Please let me know if you can do it, or not. >=20 > Many thanks > Amy >=20 > =20 > =20 > This e-mail and its attachments contain confidential information from = HUAWEI, which=20 > is intended only for the person or entity whose address is listed = above. Any use of the=20 > information contained herein in any way (including, but not limited = to, total or partial=20 > disclosure, reproduction, or dissemination) by persons other than the = intended=20 > recipient(s) is prohibited. If you receive this e-mail in error, = please notify the sender by=20 > phone or email immediately and delete it! From nobody Sun Feb 26 21:35: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 06EDA12986E; Sun, 26 Feb 2017 21:35:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33muAVOBSjAs; Sun, 26 Feb 2017 21:35:08 -0800 (PST) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::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 B68161293F4; Sun, 26 Feb 2017 21:35:08 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id n186so6082996qkb.3; Sun, 26 Feb 2017 21:35:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KGzjVzzpVt1vLLz3mZnxCDmNtYONkaPfJR5+/pxwqhU=; b=Cr87mwCKVIzrh5LOEaS7r+cW2LQXI/z4FRiorWYHxXesIOomrG6F34JboUM8IpjJne gTrdXyMNt0Vg/NOsEtMkewuvlTX5xwTMZ5ZOGrcAerMnoD5WiQqjpgBJQYzyF8vflZTV XrcvGhLMGcqnR0S1paVyH8KVv2smD/pIzPLsk3lPMwSEGPmSPspcd0pQ15aT7mbAvxoy KXJWQcKJnRXLRgKWh/6GSxW6XCMmQSZPkBi3YwKY3O7oeIfEt//s/OiKM6yD49DRwudH SY4U+oESMhBEt1JJjakHg0eLKwwyUxeKjxFaWIKUdfUXjChBLTs+ByWKRZRaKkh6byUc GcIw== 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=KGzjVzzpVt1vLLz3mZnxCDmNtYONkaPfJR5+/pxwqhU=; b=U5GD6XXNMcC5+9hDUudUAeYyEVdQTlr2vQCrRdkxDSd7QzlQvJlql8hRoMLDByEKrW HJECPDH6jda4xoV/KR0+5C/4U4IkwEqTW/THHSRTE1DPrlLR/75ah73ehCTH7Se6PBHx yZEMj64iuStOd9s7D2Y+sAHuEdiyS805GzPu3K6WjNGP7a6GBqaX95tsm4FPyj6+Pevq Zf+vmmW1XQjxcjfnQf9qsxWSl0L0AXWMDo1ahCyJp4FchbhtH2AZeq0/RH3g6R+r/Dg0 OG0RYT4ACWJSnyKI0EfdoxXJXQu/yYPeei27u/Nw0LqQpOTWNarXbIG1wOn7BGDo6OJ6 QO2Q== X-Gm-Message-State: AMke39ln1q9mzOAp0v2K8PTxgGazsmeTLcVsjzbeIhxgSFoaqoLpLB2QR8yWZdRxajfZo3poCfh3DHq80qTieQ== X-Received: by 10.55.76.209 with SMTP id z200mr15136799qka.282.1488173707924; Sun, 26 Feb 2017 21:35:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.92.197 with HTTP; Sun, 26 Feb 2017 21:35:07 -0800 (PST) In-Reply-To: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> References: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> From: Mohan Nanduri Date: Mon, 27 Feb 2017 00:35:07 -0500 Message-ID: To: Susan Hares Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "idr@ietf.org List" , spring@ietf.org Subject: Re: [Idr] [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 05:35:10 -0000 Support the publication of this draft. Cheers, -Mohan On Wed, Feb 15, 2017 at 6:34 PM, Susan Hares wrote: > This begins a 2 week IDR WG last call on > draft-ietf-idr-bgpls-segment-routing-epe from (2/15 to 3/1/2017) There > are two implementations describe on the wiki at: > > https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-segment-routing-epe%20 > > > > The two implementation are from Cisco IOS-XR release 6.0.2 and Cisco Nexus > Switch N9000/N3000 platforms running NX-OS 7.0(3)I1(1) or greater. The > authors will indicate on the list and in the wiki the following information > : > > > > 1) Were these implementations separate implementations? > > 2) What were the results of the interoperability tests? > > > > This work is linked to the draft-ietf-spring-segment-routing-central-epe > work in the SPRING WG. Based on the two drafts, the WG should might > consider: > > 1) Is there need for this work in deployments in networks/ > > 2) Is this technically ready for publication? > > 3) Does it fit with the spring informational draft? > > > > For the ease of reference the web references are below: > > https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/ > > https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-central-epe/ > > > > Sue Hares > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > From nobody Mon Feb 27 09:43: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 6616C1299A0; Mon, 27 Feb 2017 09:43:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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=dell.com header.b=jKLTPo/j; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=rE7b/KxP Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aegoWNoCTaJW; Mon, 27 Feb 2017 09:43:16 -0800 (PST) Received: from esa1.dell-outbound.iphmx.com (esa1.dell-outbound.iphmx.com [68.232.153.90]) (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 006F912A297; Mon, 27 Feb 2017 09:43:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1488216909; x=1519752909; h=from:cc:to:subject:date:message-id:references: in-reply-to:mime-version; bh=re7Py42rwuRK79e6MWTU58HbRHrZd/gl1MX1+tadZEI=; b=jKLTPo/jdd/o6InK2iwJcpzw/PK+rKtT8PxiUGlhYS+KdgQS8fxjkNAo NeTkI8C82o//T1+DqZAAEGVGfm3oZ/Mn5vvg59xIruGwgjmf0u+7/BCmb OY1F8e4P4vTLTwQi6Zh0JK0ourakr7lB/LHT0n6OPT23SshGe3e0KWsOr U=; Received: from esa5.dell-outbound2.iphmx.com ([68.232.153.203]) by esa1.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Feb 2017 11:35:08 -0600 From: "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa5.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Feb 2017 23:36:29 +0600 Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v1RHhB9F025060 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 27 Feb 2017 12:43:12 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com v1RHhB9F025060 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1488217393; bh=anAjdWrfDa1swjSid9JN2StPolo=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=rE7b/KxPmavudMsBRCtZUHCKpwd5bRKO3Ht5si2egPwodlTPfKmPKKsluCmvCezkI 31szUiZTPDRJjh9LE/5XyLfHKFFxHV4w0YRVhBiI/y8L244TuucByCq6SuYrJv0MAC 2BpkCrM/Yb/WyruW64hfd3jjnuMXgS4BEeH9AuEs= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com v1RHhB9F025060 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd52.lss.emc.com (RSA Interceptor); Mon, 27 Feb 2017 12:42:59 -0500 Received: from MXHUB316.corp.emc.com (MXHUB316.corp.emc.com [10.146.3.94]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v1RHgw3c001695 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Mon, 27 Feb 2017 12:42:58 -0500 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB316.corp.emc.com ([10.146.3.94]) with mapi id 14.03.0266.001; Mon, 27 Feb 2017 12:42:57 -0500 To: Shitanshu Shah , "tsv-art@ietf.org" Thread-Topic: Review of draft-ietf-idr-sla-exchange-10 Thread-Index: AQHSjn2hotpFQg8pf0qPmuGxW7GZeaF4QrTwgACFLACABFiS0A== Date: Mon, 27 Feb 2017 17:42:57 +0000 Message-ID: References: <148771630812.19122.17152051080250251501.idtracker@ietfa.amsl.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.45.62] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949362F8D16F3MX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "idr@ietf.org" , "Black, David" , "draft-ietf-idr-sla-exchange.all@ietf.org" , "ietf@ietf.org" Subject: Re: [Idr] Review of draft-ietf-idr-sla-exchange-10 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 17:43:22 -0000 --_000_CE03DB3D7B45C245BCA0D243277949362F8D16F3MX307CL04corpem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ok, please make that rationale for the L2_OVERHEAD parameter clear in the d= raft: > Though for the cases where physical links are not to be over-run, and/or,= sla defined are based on l2 rates, the Consumer would > need to know l2 overhead from the Producer. Otherwise 10 byes of l2 overh= ead difference on 64 bytes packets can be significant > compare to on 1400 bytes packets, and thus the Producer does not have a w= ay to convert rates to ip based (this can cause > functional issue), since this has to be per packet consideration. It looks like the result is that if the Producer's L2 overhead is larger th= an the Consumer's, and the token buckets are specified in IP octets, the co= nsumer has to calculate a per-packet charge of the L2 overhead difference a= gainst the IP token bucket (and in the opposite case, there may be a per-pa= cket credit). Are there cases where the overhead is not all L2, e.g., SLA= /TCA Consumer is using a VPN that terminates between Consumer and Producer? Thanks, --David From: Shitanshu Shah [mailto:shitanshu_shah@hotmail.com] Sent: Friday, February 24, 2017 1:05 PM To: Black, David; tsv-art@ietf.org Cc: idr@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; ietf@ietf.org Subject: Re: Review of draft-ietf-idr-sla-exchange-10 Hi David, One response inline ##svshah2 ________________________________ From: Black, David > Sent: Friday, February 24, 2017 8:53 AM To: Shitanshu Shah; tsv-art@ietf.org Cc: idr@ietf.org; draft-ietf-idr-sla-exchange.all@ietf= .org; ietf@ietf.org; Black, David Subject: RE: Review of draft-ietf-idr-sla-exchange-10 David> Inline ... Thanks, --David From: Shitanshu Shah [mailto:shitanshu_shah@hotmail.com] Sent: Friday, February 24, 2017 4:09 AM To: Black, David; tsv-art@ietf.org Cc: idr@ietf.org; draft-ietf-idr-sla-exchange.all@ietf= .org; ietf@ietf.org Subject: Re: Review of draft-ietf-idr-sla-exchange-10 Hi David, Thank you for taking time for the review.. Please find our response inline ##svshah and [Med] Regards, Shitanshu ________________________________ From: David Black > Sent: Tuesday, February 21, 2017 3:31 PM To: tsv-art@ietf.org Cc: idr@ietf.org; draft-ietf-idr-sla-exchange.all@ietf= .org; ietf@ietf.org Subject: Review of draft-ietf-idr-sla-exchange-10 Reviewer: David Black Review result: Not Ready I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. When done at the time of IETF Last Call, the authors should consider this review together with any other last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this r= eview. Document: draft-ietf-idr-sla-10 Reviewer: David Black Review Date: February 21, 2017 Review result: Not Ready This is an early TSV-ART review of a working group draft, requested by the IDR Working Group. This draft defines an extension to BGP to allow exchange of traffic handling parameters (e.g., configured rates, burst sizes, drop thresholds). While this is a useful area of technology to standardize across network operators, this draft has significant problems, and parts of it could use some serious rethought. This reviewer has discussed small portions of this draft with some of the authors in the past, but this is his first comprehensive reading and review of the draft. Major Issues: [1] The draft is misnamed. This is not an SLA (Service Level Agreement) draft - it's a TCA (Traffic Conditioning Agreement) draft - see the definition of TCA in RFC 2475. This draft should start from that definition and generalize the applicability of TCA beyond Diffserv. Large areas of SLA content are not covered by this draft - for more details, see the Wikipedia article on SLA: https://en.wikipedia.org/wiki/Service-level_agreement . ##svshah, sure, we can change the term to TCA (Traffic Conditioning Agreeme= nt), which fairly represents intention in the draft, if there is no otherwi= se comment from the working group. David> That would be good, thanks. [2] Section 3.3.2.1's reuse of the TSpec construct from RFC 2115 to specify a token bucket is a good idea, but it's not a good idea to respecify that construct in terms of L2 (link-layer, e.g., Ethernet) octets, as the RFC 2115 TSpec is specified in terms of IP octets. This change to specification in terms of L2 octets results in needing the L2_OVERHEAD TLV to cope with the possible differences in L2 (link) framing overhead at sender and receiver of this information. The TSpec should be respecified at the IP layer, with L2 framing overhead left to the Producer and Consumer to factor into their calculations based on each's direct knowledge of L2 functionality and configuration in the local AS. That ought to enable elimination of the L2_OVERHEAD TLV, thereby reducing complexity. ##svshah, the purpose for advertising L2 overhead, from the Producer to the= Consumer, is to make sure traffic is well conditioned, at the egress of th= e Consumer, to avoid possible indiscriminate drops at the ingress of the Pr= oducer. In another words, the Producer is telling the Consumer to ignore it= s own link level overhead, instead use Producer's provided link level overh= ead while running frames through QoS functions (this is relevant in use-cas= es where l2 overhead of the egress link on Consumer and of ingress link on = the Producer are of different size, e.g., in the vpn/tunnel connection betw= een two peer nodes which physically may be multiple hops away). I understand your comments regarding re-using TSpec without any modificatio= n. Do you agree with the use-case of l2 differences? If yes, any suggestion= how to accommodate that? David> Specifying this in terms of IP octets implies that L2 overhead is to= be ignored on both links. That's simpler, and a few sentences of discussi= on about possible L2 framing differences should cover what needs to be done= (e.g., if traffic rates are configured in terms of L2 octets, then explain= how each entity converts between IP traffic and L2 traffic - the draft alr= eady effectively contains that explanation). ##svshah2, just to make sure that some of the real use are not left out.. For the traffic conditioning where sla established is for the ip based rate= s only, it suffices for the Producer to send rates only IP based ignoring a= ny specific of l2 overheads. Though for the cases where physical links are not to be over-run, and/or, s= la defined are based on l2 rates, the Consumer would need to know l2 overhe= ad from the Producer. Otherwise 10 byes of l2 overhead difference on 64 byt= es packets can be significant compare to on 1400 bytes packets, and thus th= e Producer does not have a way to convert rates to ip based (this can cause= functional issue), since this has to be per packet consideration. Regards, Shitanshu [3] A token bucket should have two rate-related marking parameters based on its token fill rate, i.e., min-rate, not the four rate-related marking parameters in this draft. The max-rate parameters in sections 3.3.2.5-6 ought to be specified against a second token bucket. In addition, the handling precedence algorithm in section 3.3.2.7 is an overly complex way to specify the relationship of two token buckets. All of this is even more important, because max-rate, as defined in RFC 2115, is only applicable to bursting - that max-rate for bursting often turns out to be an interface line rate, which is not generally useful for the traffic provisioning purposes of this draft. ##svshah, what you describe below conceptually very much makes sense and th= at is what we attempt to achieve. What is unclear though how to capture tha= t using TSpec definition specified in RFC2215. Since that TSpec definition = has both minimum-rate and maximum-rate, but no in/out profile marking param= eters. Is your proposal below to define two TSpecs using the same definition from = RFC2215? Wouldn't in that case we have min/max specified twice? min/max in = each TSpec? and thus confusing to represent one min and one max through two= TSpecs? David> See RFC 2698 for the desired behavior and the parameters needed to s= pecify it. The current idr-sla draft is not able to represent the traffic = conditioning mechanisms specified in both RFC 2698 and RFC 2697, as each me= chanism requires two token buckets (e.g., there are two burst sizes, but th= e idr-sla draft TSpec only contains one). This deficiency needs to be deal= t with. One possibility for simplification is to drop the max-rate from th= e RFC 2115 TSpec and assume that the max-rate for bursting is the effective= line rate. The following should be done instead: - Define TSpecs for two token buckets, a primary/committed token bu= cket and a secondary/peak token bucket that MUST be nested, i.e.= , traffic that is in-profile for the secondary/peak token bucket is a= lways in-profile for the primary/committed token bucket. Some of= the details of how to specify this are subtle, see RFC 2698 for a worke= d example. Use of a secondary/peak token bucket requires use of the pr= imary/ committed token bucket, but a primary/committed token bucke= t can be used without a secondary/peak token bucket. - For a single token bucket, define two handling TLVs, Committed (i= n profile) and Excess (out of profile). - For two token buckets, define three handling TLVs, Committed (in = profile for both token buckets), Peak (out of profile for primary/committed = token bucket, but in profile for secondary/peak token bucket) and Excess (out of= profile for both token buckets). NB: Could use Green/Yellow/Red terms instead of Committed/Peak/Excess terms. [4] The drop threshold TLV in section 3.3.2.8 is not specified sufficiently to be implemented interoperably. For example, I don't understand what an implementation is supposed to do when it receives 3 drop thresholds. ##svshah, It is around the semantics of a single queue with a different thr= eshold for a set of code-points, where packet for a specific code-point is = to be tail dropped if overall queue-depth hits code-point specific threshol= d at the arrival of that packet. We will add appropriate clarification for this semantics. David> Will look at revision [5] The relative priority TLV in section 3.3.2.9 has the same insufficient specification problem as the drop threshold TLV, compounded by a functional incompleteness problem - if the recipient is using a weighted packet transmission scheduler (e.g., WRR), priorities cannot be used to configure that scheduler. Hence, some specification of weights and scheduling algorithms that use weights needs to be added. ##svshah, Sure. Is following clarification okay? (some of the wordings take= n from RFC2598) " A higher priority class of traffic to be served without pre-empted by lower= priority class of traffic for more than a packet time at the configured ra= te. In the system that implements WRR, the use of relative priority may get res= tricted where a single queue may be used for a higher priority traffic clas= s where that queue is configured for the full share of the output bandwidt= h. " David> Last sentence basically says that WRR weights are out-of-scope. Tha= t seems wrong. Will look at revision. [6] I have no idea what the sub-traffic classes TLV in section 3.3.2.10 is supposed to do, as that TLV is specified based on "Traffic Class TLVs" which is an undefined term in this draft (e.g., that term is not used outside of section 3.3.2.10. ##svshah, They are to facilitate hierarchy. A specific Traffic Class, can f= urther be divided in a multiple subset of Traffic Classes, with their own = Traffic Class Elements and Traffic Class Services. Will correct the wording to remove your this specific concern. David> Will look at revision [7] This draft's QoS contents need to be functionally aligned with work-in-progress on YANG QoS models, in order to provide some assurance that that this draft is implementable for actual network switch/router data paths. The current acknowledgement of the existence of YANG, NETCONF and RESTConf at the end of Section 1 does not suffice. ##svshah, While eventually "Traffic Conditioning Agreement" should be trans= lated to the actual forwarding qos policy on any vendor specific device, TC= A exchange largely carries concepts/semantics that is either standard based= or well understood. While we are not aware of any working group document of QoS Yang Model, we = think that concepts of Traffic Conditioning should be easily adaptable to = any QoS Yang Models since they also have to be defined to support those con= cepts. David> Still want to see cross-check with implementations here. [8] There are significant complexity and correctness problems caused by the option to not specify the Source AS - e.g., Section 3.2 defines an SLA ID as an "identifier which is unique in the scope of Source AS" which is meaningless if there is no Source AS. It would be simpler to always specify Source AS, even in the point-to-point case. ##svshah, okay. Ron Bonica also suggested same in his review earlier. We ha= d chosen a path of optional Source AS to simplify implementations in cases.= Given specification of Source AS always is more clearer in multiple feed-b= ack we have gotten so far, we can modify the specification to incorporate t= hat over the simplicity of implementation for certain cases. David> OK, thanks. [9] In section 3.2, the "intended for the peer receiver of the BGP UPDATE message" text in the specification of bit 0 of the SLA Subtype flags is unclear. I suspect that this is intended to differentiate the two usages described in sections 4.1.1 (Point-to-Point) and 4.1.2 (Multiple Hops), in which case the parenthesized terms (or similar terminology) should be used with cross-references to those two sections. ##svshah, sure will make necessary changes, also in the context of earlier = comment. [10] There needs to be a coherent discussion in one place about how SLA advertisement, update and withdrawal work. A single ADVERTISE method may suffice on the wire, but the details on how initial advertisement, subsequent advertisement (update) and withdrawal work need to be specified in one place. The third paragraph of Section 4 is a start on this material, but it's too terse; [Med] That text is terse because we are reusing the BGP machinery for adver= tising/withdrawing; we only augment it with triggers that are linked to the= SLA information. A new SLA will lead to an update message with ADVERTISE, = an update of an existing SLA will trigger an update message. We do think th= is information is already present in the document. David>This is hard to understand it, as there is no statement that the BGP = machinery is being used, and the material on SLA usage is spread in differe= nt places. I suggest starting section 3 with a discussion of advertisement= /update/withdrawal, and how all three are realized via a single ADVERTISE m= ethod via BGP UPDATE - this was difficult to figure out in reading the curr= ent draft. it should be expanded into its own subsection, and moved earlier to come before the ADVERTISE method in Section 3.2. This text from Section 3.2 should be moved into that new subsection and likewise expanded: [Med] Another option is to move it Section 4. From our standpoint, we do th= ink it is straightforward to describe the behavior once the attributes form= at are defined. David> Ok, that's an editorial choice - I prefer to explain how something w= orks before defining its on-the-wire data format. If an advertised SLA ID is different from earlier advertised one, for the same prefix and from the same Source AS, indicates Source AS is advertising new SLA Content to replace the previous one advertised with the same SLA ID. In addition, I wonder whether functionality should be added to allow withdrawal of an advertisement by specifying its SLA ID, although that was not part of the original design. [Med] The reason we didn't adopted that design is that we don't want to mak= e assumptions on which data the remote peer will be used for enforcing loca= l actions and also because of this text: The SLA ID applies to aggregate traffic to prefixes for a given AFI/SAFI that share the same Source AS and SLA ID. David> That's fine, I wanted to ensure that this had been considered. The = discussion of BGP mechanism reuse will probably help here. [11] Notions of context for interpretation of all the IPFIX parameters in 3.3.1 need to be added, e.g.: - The first three parameters (DSCP, MPLS EXP field in top label, 80= 2.1q priority) can and do vary on a link-by-link or LSP-by-LSP basis along a t= raffic's network path. - The IP address parameters are rather likely to be VPN-specific wh= en there's more than one BGP/MPLS VPN that spans or transits the ASs involv= ed. - The transport port parameters need specification of which transpo= rt header and where it is located (e.g., for TCP traffic carried by in VXLAN, is t= his the inner TCP header or the outer UDP header in VXLAN). There are probably simple approaches to specifying context in all cases, but that context does need to be specified ... in all cases. [Med] We dind't include a context field because we thought that the definit= ion of the IPFIX attributes is sufficient by itself, but if you do think it= is helpful to have such information, we can update the table. David> Really??? Please reread the first comment above: - The first three parameters (DSCP, MPLS EXP field in top label, 80= 2.1q priority) can and do vary on a link-by-link or LSP-by-LSP basis along a t= raffic's network path. David> Taking just DSCP, it can change on a per-link basis, so something h= as to specify which link (between the SLA Producer and SLA Consumer?) is in= volved. It probably suffices to say that it's the link that crosses the re= levant AS boundary, but that does have to be stated, as it's nowhere to be = found in the far more general IPFIX registry. [12] The security considerations (section 10) are severely incomplete and insufficient: David> I stand by this statement and recommend a complete rewrite of the se= curity considerations. - Discussion of possible abuse of this BGP option for denial-of-ser= vice and theft-of-service, needs to be added, including possible countermeasures and m= itigations. [Med] This attack vector is not specific to this attribute; this is valid f= or BGP in general. David> There are additional attacks enabled by this attribute. - This sentence at the end of the second paragraph in Section 10 is= content-free: It is NOT RECOMMENDED to enable this attribute at the scale of the Internet unless if means to prevent leaking= sensitive information are enforced. What exactly is an implementer or admin supposed to do? [Med] An example of what an admin needs to check if this information can be= sent to a given peer or not. Some of the content of the attribute contains= some sensitive information such as contract Id, classes, etc. How does one figure out whether an implementation or deployment is "at = the scale of the Internet" ?? [Med] The idea here is to avoid leaking such data in to the global routing = table. Only entitled peers need receive such information with controlled sc= ope. David> I understand the idea - the problem is that I don't see specificatio= n of what has to be implemented in either the text in the draft or the abov= e explanations. - The next to last paragraph in section 10 is almost content-free, = as it leaves decisions on implementation and deployment of key security = functionality as "an exercise for the reader" - that's not acceptable. [Med] I guess you are referring to the following text. Validation checks ar= e really deployment-specific. The text calls out the issue and recommends a= n action; how to translate this action into detailed actions is realty loca= l to a domain The attribute may be advertised by a misbehaving node to communicate SLA parameters that are not aligned with the SLA agreements. Though the enforcement of SLA parameters is outside the scope of this document, it is RECOMMENDED that the SLA Consumer to enforce a set of validation checks before translating the SLA parameters conveyed in the QoS attributes into provisioning actions. Such validations MAY rely on SLA parameters like the origin AS or SLA ID, like generating SLA ID using pseudo-random schemes [RFC4086]. David> I stand by the "exercise to the reader" criticism - one way to be h= onest about this would be to change the paragraph to: The attribute may be advertised by a misbehaving node to communicat= e SLA parameters that are not aligned with the SLA agreements. The enforcement of SLA parameters is outside the scope of this document. David> That does not change any normative content of the original paragraph= . My view is that the "outside the scope of this document" statement is wr= ong because all of these parameters are being defined in this draft. - Last, but not least, the final paragraph in Section 10 is a joke = that will be lost on a security directorate reviewer - to understand = why, see Section 2 of RFC 6919, and take note of the publication dat= e of RFC 6919. David> For anyone who didn't catch the reference, RFC 6919 is an April 1 RF= C ... and the "SHOULD BE considered" language used in the last security con= siderations paragraph of this draft is accurately characterized as vague in= Section 2 of RFC 6919: The phrase "SHOULD CONSIDER" indicates that the authors of the specification think that implementations should do something, but they're not sure quite what. ------------------------ Having noted a dozen major issues, I'll end the review here for now, as I believe a serious revision of the draft is called for, which would be a better starting point to review for minor issues and editorial items. -------------------------------------------------------- David L. Black, Distinguished Engineer Dell EMC, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 Cell: +1 (978) 394-7754 David.Black@dell.com <=3D=3D=3D NEW =3D=3D=3D -------------------------------------------------------- --_000_CE03DB3D7B45C245BCA0D243277949362F8D16F3MX307CL04corpem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ok, please make that rati= onale for the L2_OVERHEAD parameter clear in the draft:

> Though for the cases where phys= ical links are not to be over-run, and/or, sla defined are b= ased on l2 rates, the Consumer would
> need to know l2 overhead from the Producer. Otherwise 10 byes of l2 ov= erhead difference on 64 bytes packets can be significant
> compare to on 1400 bytes packets, and thus the Producer does not have = a way to convert rates to ip based (this can cause
> functional issue), since this has to be per packet consideration.=

It looks like the result = is that if the Producer’s L2 overhead is larger than the ConsumerR= 17;s, and the token buckets are specified in IP octets, the consumer has to calculate a per-packet charge of the L2 overhead difference against= the IP token bucket (and in the opposite case, there may be a per-packet c= redit).   Are there cases where the overhead is not all L2, e.g.,= SLA/TCA Consumer is using a VPN that terminates between Consumer and Producer?

 <= /p>

Thanks, --David

 <= /p>

From: Shitansh= u Shah [mailto:shitanshu_shah@hotmail.com]
Sent: Friday, February 24, 2017 1:05 PM
To: Black, David; tsv-art@ietf.org
Cc: idr@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; ietf@iet= f.org
Subject: Re: Review of draft-ietf-idr-sla-exchange-10

 

 

Hi David,

 

One response inline ##svshah2

 

From: Black, David <= David.Black@dell.com>
Sent: Friday, February 24, 2017 8:53 AM
To: Shitanshu Shah; tsv-art@ietf= .org
Cc: idr@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; ietf@ietf.org; Black, David
Subject: RE: Review of draft-ietf-idr-sla-exchange-10

 

David> Inline ...

 

Thanks, --David

 

From: Shitanshu Shah [mailto:shitanshu_shah@= hotmail.com]
Sent: Friday, February 24, 2017 4:09 AM
To: Black, David; tsv-art@ietf.o= rg
Cc: idr@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; ietf@ietf.org
Subject: Re: Review of draft-ietf-idr-sla-exchange-10

 

 

Hi David,

 

Thank you for taking time for the review..

 

Please find our response inline ##svshah and [Med]

 

Regards,

Shitanshu

From: David Black <david.black@emc.com&g= t;
Sent: Tuesday, February 21, 2017 3:31 PM
To: tsv-art@ietf.org
Cc: idr@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; ietf@ietf.org
Subject: Review of draft-ietf-idr-sla-exchange-10

 

Reviewer: David Black
Review result: Not Ready

I've reviewed this document as part of the transport area
directorate's ongoing effort to review key IETF documents. These
comments were written primarily for the transport area directors, but
are copied to the document's authors for their information and to
allow them to address any issues raised. When done at the time of IETF
Last Call, the authors should consider this review together with any
other last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or= forward this review.

Document: draft-ietf-idr-sla-10
Reviewer: David Black
Review Date: February 21, 2017

Review result: Not Ready

This is an early TSV-ART review of a working group draft, requested by
the IDR Working Group.

This draft defines an extension to BGP to allow exchange of traffic
handling parameters (e.g., configured rates, burst sizes, drop
thresholds).  While this is a useful area of technology to standardize=
across network operators, this draft has significant problems, and
parts of it could use some serious rethought.

This reviewer has discussed small portions of this draft with some of
the authors in the past, but this is his first comprehensive reading
and review of the draft.

Major Issues:

[1] The draft is misnamed.  This is not an SLA (Service Level
Agreement) draft - it's a TCA (Traffic Conditioning Agreement) draft -
see the definition of TCA in RFC 2475.  This draft should start from that definition and generalize the applicability of TCA beyond
Diffserv.  Large areas of SLA content are not covered by this draft -<= br> for more details, see the Wikipedia article on SLA:
https://en.wikipedia.org/wiki/Service-level_agreement .

##svshah, sure, we can change the term to TCA (Traffic Conditioning Agreeme= nt), which fairly represents intention in the draft, if there is no otherwi= se comment from the working group.<= /o:p>

 =


David> That would be good, thanks.

[2] Section 3.3.2.1's reuse of the TSpec construct from RFC 2115 to
specify a token bucket is a good idea, but it's not a good idea to
respecify that construct in terms of L2 (link-layer, e.g., Ethernet)
octets, as the RFC 2115 TSpec is specified in terms of IP octets.
This change to specification in terms of L2 octets results in needing
the L2_OVERHEAD TLV to cope with the possible differences in L2 (link)
framing overhead at sender and receiver of this information.  The
TSpec should be respecified at the IP layer, with L2 framing overhead
left to the Producer and Consumer to factor into their calculations
based on each's direct knowledge of L2 functionality and configuration
in the local AS.  That ought to enable elimination of the L2_OVERHEAD<= br> TLV, thereby reducing complexity.

##svshah, the purpose for advertising L2 = overhead, from the Producer to the Consumer, is to make sure traffic is well conditioned, at the egress of the Consumer, to avoid = possible indiscriminate drops at the ingress of the Producer. In another wo= rds, the Producer is telling the Consumer to ignore its own link = level overhead, instead use Producer's provided link level overhead while running frames through QoS functions (this is&nb= sp;relevant in use-cases where l2 overhead of the egress link on Consu= mer and of ingress link on the Producer are of different size, e.g., in the=  vpn/tunnel connection between two peer nodes which physically may be multiple hops away).

I understand your comments regarding re-u= sing TSpec without any modification. Do you agree with the use-case of l2 differences? If yes, any suggestion how to accommodate that= ?

 =

David> Specifying this in terms of I= P octets implies that L2 overhead is to be ignored on both links.  That’s simpler, and a few sentences of discussion about possible L2 = framing differences should cover what needs to be done (e.g., if traffic ra= tes are configured in terms of L2 octets, then explain how each entity conv= erts between IP traffic and L2 traffic - the draft already effectively contains that explanation).

 

##svshah2, just to make sure that some of= the real use are not left out..

 

For the traffic conditioning where sla es= tablished is for the ip based rates only, it suffices for the Producer to send rates only IP based ignoring any specific of l2 = overheads.

 

Though for the cases where physical&= nbsp;links are not to be over-run, and/or, sla defined are based = on l2 rates, the Consumer would need to know l2 overhead from the Produc= er. Otherwise 10 byes of l2 overhead difference on 64 bytes packets can be = significant compare to on 1400 bytes packets, and thus the Producer does no= t have a way to convert rates to ip based (this can cause functional issue), since this has to be per packet conside= ration.

 

Regards,

Shitanshu

 

 

 


[3] A token bucket should have two rate-related marking parameters
based on its token fill rate, i.e., min-rate, not the four
rate-related marking parameters in this draft.  The max-rate
parameters in sections 3.3.2.5-6 ought to be specified against a
second token bucket.  In addition, the handling precedence algorithm in section 3.3.2.7 is an overly complex way to specify the
relationship of two token buckets.  All of this is even more
important, because max-rate, as defined in RFC 2115, is only
applicable to bursting - that max-rate for bursting often turns out to
be an interface line rate, which is not generally useful for the
traffic provisioning purposes of this draft.

 =

##svshah, what you describe below concept= ually very much makes sense and that is what we attempt to achieve. What is unclear though how to capture that using TSpec definition= specified in RFC2215. Since that TSpec definition has both minimum-rate an= d maximum-rate, but no in/out profile marking parameters.

 =

Is your proposal below to define two TSpe= cs using the same definition from RFC2215? Wouldn't in that case we have min/max specified twice? min/max in each TSpec? and thus conf= using to represent one min and one max through two TSpecs?

 =

David> See RFC 2698 for the desired = behavior and the parameters needed to specify it.  The current idr-sla draft is not able to represent the traffic conditioning mechanisms= specified in both RFC 2698 and RFC 2697, as each mechanism requires two to= ken buckets (e.g., there are two burst sizes, but the idr-sla draft TSpec o= nly contains one).  This deficiency needs to be dealt with.  One possibility for simplification is to dro= p the max-rate from the RFC 2115 TSpec and assume that the max-rate for bur= sting is the effective line rate.


The following should be done instead:
        - Define TSpecs for two token bu= ckets, a primary/committed token bucket
            &nb= sp;   and a secondary/peak token bucket that MUST be nested, i.e.= , traffic
            &nb= sp;   that is in-profile for the secondary/peak token bucket is a= lways
            &nb= sp;   in-profile for the primary/committed token bucket.  So= me of the details
            &nb= sp;   of how to specify this are subtle, see RFC 2698 for a worke= d example.
            &nb= sp;   Use of a secondary/peak token bucket requires use of the pr= imary/
            &nb= sp;   committed token bucket, but a primary/committed token bucke= t can be used
            &nb= sp;   without a secondary/peak token bucket.
        - For a single token bucket, def= ine two handling TLVs, Committed (in profile) and
            &nb= sp;   Excess (out of profile).
        - For two token buckets, define = three handling TLVs, Committed (in profile for both
            &nb= sp;   token buckets), Peak (out of profile for primary/committed = token bucket, but in
            &nb= sp;   profile for secondary/peak token bucket) and Excess (out of= profile for both
            &nb= sp;   token buckets).
NB: Could use Green/Yellow/Red terms instead of Committed/Peak/Excess
terms.

[4] The drop threshold TLV in section 3.3.2.8 is not specified
sufficiently to be implemented interoperably.  For example, I don't understand what an implementation is supposed to do when it receives 3
drop thresholds.

##svshah, It is around the semantics= of a single queue with a different threshold for a set of code-points= , where packet for a specific code-point is to be tail dropped if overall qu= eue-depth hits code-point specific threshold at the arrival of that packet.=

We will add appropriate clarification for= this semantics.

 =

David> Will look at revision


[5] The relative priority TLV in section 3.3.2.9 has the same
insufficient specification problem as the drop threshold TLV,
compounded by a functional incompleteness problem - if the recipient
is using a weighted packet transmission scheduler (e.g., WRR),
priorities cannot be used to configure that scheduler.  Hence, some specification of weights and scheduling algorithms that use weights
needs to be added.

##svshah, Sure. Is following clarificatio= n okay? (some of the wordings taken from RFC2598)

 =

"=

A higher priority class of traffic t= o be served without pre-empted by lower priority class of traffic = ;for more than a packet time at the configured rate.

 =

In the system that implements WRR, the us= e of relative priority may get restricted where a single queue may be used for a higher priority traffic class where that queue &nbs= p;is configured for the full share of the output bandwidth.

"=

 =

David> Last sentence basically says that W= RR weights are out-of-scope.  That seems wrong.  Will look at revision.

[6] I have no idea what the sub-traffic classes TLV in section
3.3.2.10 is supposed to do, as that TLV is specified based on "Traffic=
Class TLVs" which is an undefined term in this draft (e.g., that term<= br> is not used outside of section 3.3.2.10.=

##svshah, They are to facilitate hierarch= y. A specific Traffic Class, can further be divided in a multiple  subset of Traffic Classes, with their own Traffic Class Element= s and Traffic Class Services.=

 =

Will correct the wording to remove your t= his specific concern.<= /p>


David> Will look at revision


[7] This draft's QoS contents need to be functionally aligned with
work-in-progress on YANG QoS models, in order to provide some
assurance that that this draft is implementable for actual network
switch/router data paths.  The current acknowledgement of the
existence of YANG, NETCONF and RESTConf at the end of Section 1 does
not suffice.

##svshah, While eventually "Tra= ffic Conditioning Agreement" should be translated to the actual forwar= ding qos policy on any vendor specific device, TCA exchange largely carries con= cepts/semantics that is either standard based or well understood.

 =

While we are not aware of any working gro= up document of QoS Yang Model, we think that  concepts of Traffic Conditioning should be easily adaptable to any QoS Yang Models sin= ce they also have to be defined to support those concepts.

 =

 =

David> Still want to see cross-check= with implementations here.


[8] There are significant complexity and correctness problems caused
by the option to not specify the Source AS - e.g., Section 3.2 defines
an SLA ID as an "identifier which is unique in the scope of Source AS&= quot;
which is meaningless if there is no Source AS.  It would be simpler to=
always specify Source AS, even in the point-to-point case.

##svshah, okay. Ron Bonica also suggested same in his review earlier. We ha= d chosen a path of optional Source AS to simplify implementations in c= ases. Given specification of Source AS always is more clearer in multiple f= eed-back we have gotten so far, we can modify the specification to incorporate that over the simplicity of implem= entation for certain cases.

 

David> OK, thanks.


[9] In section 3.2, the "intended for = the peer receiver of the BGP
UPDATE message" text in the specificat= ion of bit 0 of the SLA Subtype
flags is unclear.  I suspect that this= is intended to differentiate
the two usages described in sections 4.1.1 = (Point-to-Point) and 4.1.2
(Multiple Hops), in which case the parenthe= sized terms (or similar
terminology) should be used with cross-refe= rences to those two
sections.

##svshah, sure will make necessary change= s, also in the context of earlier comment.

 


[10] There needs to be a coherent discussio= n in one place about how
SLA advertisement, update and withdrawal wo= rk.  A single ADVERTISE
method may suffice on the wire, but the det= ails on how initial
advertisement, subsequent advertisement (up= date) and withdrawal work
need to be specified in one place.  Th= e third paragraph of Section 4
is a start on this material, but it's too t= erse; 

 

[Med] That text is terse because we are reusing the BGP mach= inery for advertising/withdrawing; we only augment it with triggers that are linked to the SLA information. A new SLA will le= ad to an update message with ADVERTISE, an update of an existing SLA will t= rigger an update message. We do think this information is already present i= n the document.

 

David>This is hard to understand it,= as there is no statement that the BGP machinery is being used, and the material on SLA usage is spread in different places.  I sugge= st starting section 3 with a discussion of advertisement/update/withdrawal,= and how all three are realized via a single ADVERTISE method via BGP UPDAT= E - this was difficult to figure out in reading the current draft.

 <= /p>

it should be expanded into its own subsection, and moved earlier = to come before the
ADVERTISE method in Section 3.2.  This= text from Section 3.2 should be
moved into that new subsection and likewise= expanded:

[Med] Another option is to move it Section 4. From our standpo= int, we do think it is straightforward to describe the behavior once the at= tributes format are defined. <= /o:p>

 

David> Ok, that’s an editorial= choice - I prefer to explain how something works before defining its on-the-wire data format.

 

      If an adve= rtised SLA ID is different from earlier advertised one,
      for the same= prefix and from the same Source AS, indicates Source
      AS is advert= ising new SLA Content to replace the previous one
      advertised w= ith the same SLA ID.

In addition, I wonder whether functionality= should be added to allow
withdrawal of an advertisement by specifyin= g its SLA ID, although that
was not part of the original design.=

 

<= span style=3D"font-size:10.0pt;font-family:"Courier New";color:bl= ack">[Med] The reason we didn’t adopted that design is that we don= 217;t want to make assumptions on which data the remote peer will be used for enforcing local actions and also because of this text:

  &n= bsp;   The SLA ID applies to aggregate traffic to prefixes for a = given

  &n= bsp;   AFI/SAFI that share the same Source AS and SLA ID.<= span style=3D"font-family:"Calibri","sans-serif";color:= black">

 

David> That’s fine, I wanted to ensu= re that this had been considered.  The discussion of BGP mechanism reuse will probably help here.

[11] Notions of context for interpretation = of all the IPFIX parameters
in 3.3.1 need to be added, e.g.:
        = - The first three parameters (DSCP, MPLS EXP field in top label, 802.1q priority) can
       &= nbsp;        and do vary on a link-by-li= nk or LSP-by-LSP basis along a traffic's network path.
        = - The IP address parameters are rather likely to be VPN-specific when there's more
       &= nbsp;        than one BGP/MPLS VPN that = spans or transits the ASs involved.
        = - The transport port parameters need specification of which transport header and where it
       &= nbsp;        is located (e.g., for TCP t= raffic carried by in VXLAN, is this the inner TCP header
       &= nbsp;        or the outer UDP header in = VXLAN).
There are probably simple approaches to spe= cifying context in all
cases, but that context does need to be spe= cified ... in all cases.

[Med] We dind’t include a context field because we thoug= ht that the definition of the IPFIX attributes is sufficient by itself, but= if you do think it is helpful to have such information, we can update the table.

David>  Really???  Please = reread the first comment above:

 

       = ; - The first three parameters (DSCP, MPLS EXP field in top label, 802.1q p= riority) can
       &= nbsp;        and do vary on a link-by-li= nk or LSP-by-LSP basis along a traffic's network path.

 

David>  Taking just DSCP, it ca= n change on a per-link basis, so something has to specify which link (between the SLA Producer and SLA Consumer?) is involved.  It probabl= y suffices to say that it’s the link that crosses the relevant AS bou= ndary, but that does have to be stated, as it’s nowhere to be found i= n the far more general IPFIX registry.

[12] The security considerations (section 1= 0) are severely incomplete
and insufficient:

 

David> I stand by this statement and= recommend a complete rewrite of the security considerations.


        = - Discussion of possible abuse of this BGP option for denial-of-service and theft-of-service,
       &= nbsp;        needs to be added, includin= g possible countermeasures and mitigations.

[Med] This attack vector is not specific to this attribute; th= is is valid for BGP in general.

 

David> There are additional attacks = enabled by this attribute.


        = - This sentence at the end of the second paragraph in Section 10 is<= span style=3D"font-size:10.0pt;font-family:"Calibri","sans-s= erif";color:#1F497D"> content-free:

       &= nbsp;           It is NOT= RECOMMENDED to enable this attribute at the
       &= nbsp;           scale of = the Internet unless if means to prevent leaking sensitive
       &= nbsp;           informati= on are enforced.

       &= nbsp;        What exactly is an implemen= ter or admin supposed to do? <= /o:p>

 

[Med] An example of what an admin needs to check if this inf= ormation can be sent to a given peer or not. Some of the content of the attribute contains some sensitive information such a= s contract Id, classes, etc.<= /span>

 

How does one
       &= nbsp;        figure out whether an imple= mentation or deployment is  "at the scale
       &= nbsp;        of the Internet" ??

 

[Med] The idea here is to avoid leaking such data in to the = global routing table. Only entitled peers need receive such information with controlled scope.=

 

David> I understand the idea - the problem= is that I don’t see specification of what has to be implemented in either the text in the draft or the above explanations.

        - Th= e next to last paragraph in section 10 is almost content-free, as it leaves
       &= nbsp;        decisions on implementation= and deployment of key security functionality as
       &= nbsp;        "an exercise for the r= eader" - that's not acceptable.

[Med] I guess = you are referring to the following text. Validation checks are really deplo= yment-specific. The text calls out the issue and recommends an action; how to translate this action into detailed actions i= s realty local to a domain

  =
; The attribute may be advertised by a misbehaving node to communicate
  =
; SLA parameters that are not aligned with the SLA agreements.  Though=

  =
; the enforcement of SLA parameters is outside the scope of this
  =
; document, it is RECOMMENDED that the SLA Consumer to enforce a set of
  =
; validation checks before translating the SLA parameters conveyed in
  =
; the QoS attributes into provisioning actions.  Such validations MAY<=
/span>
  =
; rely on SLA parameters like the origin AS or SLA ID, like generating
  =
; SLA ID using pseudo-random schemes [RFC4086].

 

David> I stand by the “exercis= e to the reader”  criticism - one way to be honest about this wo= uld be to change the paragraph to:

 
        =
The attribute may be advertised by a m=
isbehaving node to communicate
  =
; SLA parameters that are not aligned with the SLA agreements.  The
   enforcement of SLA paramete=
rs is outside the scope of this document.
 
David> That does not change any normative content of the =
original paragraph.  My view is that the “outside the scope of t=
his document” statement is wrong because all of these parameters are =
being defined in this draft.<=
/span>


        = - Last, but not least, the final paragraph in Section 10 is a joke that will
       &= nbsp;        be lost on a security direc= torate reviewer - to understand why, see
       &= nbsp;        Section 2 of RFC 6919, and = take note of the publication date of RFC 6919.

David> For anyone who didn’t catch the reference, RFC 6919 is an A= pril 1 RFC ... and the “SHOULD BE considered” language used in = the last security considerations paragraph of this draft is accurately char= acterized as vague in Section 2 of RFC 6919:

   The phrase "SHOULD CONSIDER" indicates that th= e authors of the

   specification think that implementations should do somet= hing, but

   they're not sure quite what.

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

Having noted a dozen major issues, I'll end= the review here for now,
as I believe a serious revision of the draf= t is called for, which
would be a better starting point to review = for minor issues and
editorial items.

-------------------------------------------= -------------
David L. Black, Distinguished Engineer
Dell EMC, 176 South St., Hopkinton, MA = ; 01748
+1 (508) 293-7953   &nbs= p; Cell: +1 (978) 394-7754
Dav= id.Black@dell.com  <=3D=3D=3D NEW =3D=3D=3D -------------------------------------------= -------------

--_000_CE03DB3D7B45C245BCA0D243277949362F8D16F3MX307CL04corpem_-- From nobody Tue Feb 28 10:24: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 DAF18129662; Tue, 28 Feb 2017 10:24:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 GqKw278KOWfD; Tue, 28 Feb 2017 10:24:13 -0800 (PST) Received: from SNT004-OMC3S13.hotmail.com (snt004-omc3s13.hotmail.com [65.55.90.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABFCE129561; Tue, 28 Feb 2017 10:24:12 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com ([65.55.90.135]) by SNT004-OMC3S13.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Tue, 28 Feb 2017 10:24:11 -0800 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=srPayWmpE7secuLtkLNyWe+anURy2chI2BLLhexpE3E=; b=Bn/TEfSjJvAUst/n3hyw1wM5rRT3oMZOoU0Fn7khL1pDr1SQkGmM7RuvuMPqgVANGUn5Lz0EFz6TnT1pgi+GPOD3HQ0lX4HZeHCcoHtw6ABsv1izXIz6BXwQXC8GAWi9KbRfAj4U8xM+sB30fl1wEhBfqYNQu4voyI1Ykp4q34WF05EudrDfOMXmKG7Wcz/JPmdlWfharzWt3uO7d5gfBevdbqy6AvFRnjpF5/pKUjTF2V2q1ji4kcVcsDdysnRCgjMy4vCxng1WBXX+iOQ3g1mWzdFs+YG/YfqsYaXrXTrXgpLqiT26PSF316hoCCIaeoAI3ug7i3XgcblR74f+5Q== Received: from BN3NAM01FT041.eop-nam01.prod.protection.outlook.com (10.152.66.52) by BN3NAM01HT153.eop-nam01.prod.protection.outlook.com (10.152.67.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.10; Tue, 28 Feb 2017 18:24:09 +0000 Received: from DM3PR13MB0604.namprd13.prod.outlook.com (10.152.66.55) by BN3NAM01FT041.mail.protection.outlook.com (10.152.67.200) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.11 via Frontend Transport; Tue, 28 Feb 2017 18:24:09 +0000 Received: from DM3PR13MB0604.namprd13.prod.outlook.com ([10.164.8.150]) by DM3PR13MB0604.namprd13.prod.outlook.com ([10.164.8.150]) with mapi id 15.01.0947.011; Tue, 28 Feb 2017 18:24:09 +0000 From: Shitanshu Shah To: "Black, David" , "tsv-art@ietf.org" Thread-Topic: Review of draft-ietf-idr-sla-exchange-10 Thread-Index: AQHSjJJLT08h8arb7kKXAYa1wCM/2KF32nBggAB4pYCAACEyq4AEtHCAgAGczIA= Date: Tue, 28 Feb 2017 18:24:09 +0000 Message-ID: References: <148771630812.19122.17152051080250251501.idtracker@ietfa.amsl.com> , , 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=hotmail.com; x-incomingtopheadermarker: OriginalChecksum:C194A302BDABDAAAD6B1FE90F31AC2A02EDDABBE46695C56F2ED1D83BE8ADD29; UpperCasedChecksum:22C3832B2723EAB7536AE8D6E7C0513ADC1BD84AE157665AF307ED026C326C87; SizeAsReceived:8293; Count:40 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [u14L/4hIBkDd7t2dFmu0dnthBO/nHB0A] x-incomingheadercount: 40 x-eopattributedmessage: 0 x-microsoft-exchange-diagnostics: 1; BN3NAM01HT153; 5:8FgDJIAdZgD3ruzj7PbTGNXEiqF4Fd3z5VFHHDn5fOXts+3QcJX/PutnMmHEWY3sdiNSKqV4NI49Bsu8TjeUJSsJKuxdxivXkgIzTHmx1cw6DPYeYeAG7aewZgEa4qm1Wl3aBPo0WeIc9yGNkEOevg==; 24:W2/q4+j9T8PWNJV0vWehI8J+OvVGbhruKr5Ls5pjTYxKOnQGCQ4mmsEbxpCG7pIW8bpROh1GT9kVSoW4x4BLqL7F4X61t7FdM9ggddKizMY=; 7:Gk+WI4DTMQVAm3cGTQDTYw3jnw1VR369NhmRm23fxYT7vcPeeGhHt3pDMPeF0Cb0m5IjkAEy7DiVJauX947dS3IIrqwG/Sn+93BDDFm+f/xNuYwVq0bfq7KRH1MJgwbDOm8TDIJNxxouM/qO0u/3SPo0qKE8Prj0UtYtNhdg+Zuvzon60ZCpoFC3TmkWsZnIHh0vREVmRk/Ce9u+qR7Dh1xHLpd4LUxDjGaJWtVWBXTpxjVxTn88ZzqdmeMe/9R9kkRMk/S0HwOwrP5SHR8AXMwZNlOggrfSSebmU6T2Mhs0+uNiBN0mt1rHonmCOu+H x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(10019020)(98900012); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3NAM01HT153; H:DM3PR13MB0604.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: 0f4c1498-26a1-4c9c-e288-08d46006fcc9 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(1601125254)(1603101448)(1701031045); SRVR:BN3NAM01HT153; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015087)(444000031); SRVR:BN3NAM01HT153; BCL:0; PCL:0; RULEID:; SRVR:BN3NAM01HT153; x-forefront-prvs: 0232B30BBC spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM3PR13MB0604AF5667DD40C1C569422AE5560DM3PR13MB0604namp_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2017 18:24:09.2148 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3NAM01HT153 X-OriginalArrivalTime: 28 Feb 2017 18:24:11.0814 (UTC) FILETIME=[DBCECC60:01D291EF] Archived-At: Cc: "idr@ietf.org" , "draft-ietf-idr-sla-exchange.all@ietf.org" , "ietf@ietf.org" Subject: Re: [Idr] Review of draft-ietf-idr-sla-exchange-10 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 18:24:17 -0000 --_000_DM3PR13MB0604AF5667DD40C1C569422AE5560DM3PR13MB0604namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi David, We will add more text to clarify rationale for L2_OVERHEAD. Do you have a preference or suggest a way to specify L2 rates? We will work= on defining 2 TSpecs to specify two rates (min and max). As far as VPN terminating between Consumer and Producer, I am not aware of = use-cases, at least in the context of the deployment scenario considered fo= r the draft. Regards, Shitanshu ________________________________ From: Black, David Sent: Monday, February 27, 2017 10:42 AM To: Shitanshu Shah; tsv-art@ietf.org Cc: idr@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; ietf@ietf.org; = Black, David Subject: RE: Review of draft-ietf-idr-sla-exchange-10 Ok, please make that rationale for the L2_OVERHEAD parameter clear in the d= raft: > Though for the cases where physical links are not to be over-run, and/or,= sla defined are based on l2 rates, the Consumer would > need to know l2 overhead from the Producer. Otherwise 10 byes of l2 overh= ead difference on 64 bytes packets can be significant > compare to on 1400 bytes packets, and thus the Producer does not have a w= ay to convert rates to ip based (this can cause > functional issue), since this has to be per packet consideration. It looks like the result is that if the Producer=92s L2 overhead is larger = than the Consumer=92s, and the token buckets are specified in IP octets, th= e consumer has to calculate a per-packet charge of the L2 overhead differen= ce against the IP token bucket (and in the opposite case, there may be a pe= r-packet credit). Are there cases where the overhead is not all L2, e.g.,= SLA/TCA Consumer is using a VPN that terminates between Consumer and Produ= cer? Thanks, --David From: Shitanshu Shah [mailto:shitanshu_shah@hotmail.com] Sent: Friday, February 24, 2017 1:05 PM To: Black, David; tsv-art@ietf.org Cc: idr@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; ietf@ietf.org Subject: Re: Review of draft-ietf-idr-sla-exchange-10 Hi David, One response inline ##svshah2 ________________________________ From: Black, David > Sent: Friday, February 24, 2017 8:53 AM To: Shitanshu Shah; tsv-art@ietf.org Cc: idr@ietf.org; draft-ietf-idr-sla-exchange.all@ietf= .org; ietf@ietf.org; Black, David Subject: RE: Review of draft-ietf-idr-sla-exchange-10 David> Inline ... Thanks, --David From: Shitanshu Shah [mailto:shitanshu_shah@hotmail.com] Sent: Friday, February 24, 2017 4:09 AM To: Black, David; tsv-art@ietf.org Cc: idr@ietf.org; draft-ietf-idr-sla-exchange.all@ietf= .org; ietf@ietf.org Subject: Re: Review of draft-ietf-idr-sla-exchange-10 Hi David, Thank you for taking time for the review.. Please find our response inline ##svshah and [Med] Regards, Shitanshu ________________________________ From: David Black > Sent: Tuesday, February 21, 2017 3:31 PM To: tsv-art@ietf.org Cc: idr@ietf.org; draft-ietf-idr-sla-exchange.all@ietf= .org; ietf@ietf.org Subject: Review of draft-ietf-idr-sla-exchange-10 Reviewer: David Black Review result: Not Ready I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. When done at the time of IETF Last Call, the authors should consider this review together with any other last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this r= eview. Document: draft-ietf-idr-sla-10 Reviewer: David Black Review Date: February 21, 2017 Review result: Not Ready This is an early TSV-ART review of a working group draft, requested by the IDR Working Group. This draft defines an extension to BGP to allow exchange of traffic handling parameters (e.g., configured rates, burst sizes, drop thresholds). While this is a useful area of technology to standardize across network operators, this draft has significant problems, and parts of it could use some serious rethought. This reviewer has discussed small portions of this draft with some of the authors in the past, but this is his first comprehensive reading and review of the draft. Major Issues: [1] The draft is misnamed. This is not an SLA (Service Level Agreement) draft - it's a TCA (Traffic Conditioning Agreement) draft - see the definition of TCA in RFC 2475. This draft should start from that definition and generalize the applicability of TCA beyond Diffserv. Large areas of SLA content are not covered by this draft - for more details, see the Wikipedia article on SLA: https://en.wikipedia.org/wiki/Service-level_agreement . ##svshah, sure, we can change the term to TCA (Traffic Conditioning Agreeme= nt), which fairly represents intention in the draft, if there is no otherwi= se comment from the working group. David> That would be good, thanks. [2] Section 3.3.2.1's reuse of the TSpec construct from RFC 2115 to specify a token bucket is a good idea, but it's not a good idea to respecify that construct in terms of L2 (link-layer, e.g., Ethernet) octets, as the RFC 2115 TSpec is specified in terms of IP octets. This change to specification in terms of L2 octets results in needing the L2_OVERHEAD TLV to cope with the possible differences in L2 (link) framing overhead at sender and receiver of this information. The TSpec should be respecified at the IP layer, with L2 framing overhead left to the Producer and Consumer to factor into their calculations based on each's direct knowledge of L2 functionality and configuration in the local AS. That ought to enable elimination of the L2_OVERHEAD TLV, thereby reducing complexity. ##svshah, the purpose for advertising L2 overhead, from the Producer to the= Consumer, is to make sure traffic is well conditioned, at the egress of th= e Consumer, to avoid possible indiscriminate drops at the ingress of the Pr= oducer. In another words, the Producer is telling the Consumer to ignore it= s own link level overhead, instead use Producer's provided link level overh= ead while running frames through QoS functions (this is relevant in use-cas= es where l2 overhead of the egress link on Consumer and of ingress link on = the Producer are of different size, e.g., in the vpn/tunnel connection betw= een two peer nodes which physically may be multiple hops away). I understand your comments regarding re-using TSpec without any modificatio= n. Do you agree with the use-case of l2 differences? If yes, any suggestion= how to accommodate that? David> Specifying this in terms of IP octets implies that L2 overhead is to= be ignored on both links. That=92s simpler, and a few sentences of discus= sion about possible L2 framing differences should cover what needs to be do= ne (e.g., if traffic rates are configured in terms of L2 octets, then expla= in how each entity converts between IP traffic and L2 traffic - the draft a= lready effectively contains that explanation). ##svshah2, just to make sure that some of the real use are not left out.. For the traffic conditioning where sla established is for the ip based rate= s only, it suffices for the Producer to send rates only IP based ignoring a= ny specific of l2 overheads. Though for the cases where physical links are not to be over-run, and/or, s= la defined are based on l2 rates, the Consumer would need to know l2 overhe= ad from the Producer. Otherwise 10 byes of l2 overhead difference on 64 byt= es packets can be significant compare to on 1400 bytes packets, and thus th= e Producer does not have a way to convert rates to ip based (this can cause= functional issue), since this has to be per packet consideration. Regards, Shitanshu [3] A token bucket should have two rate-related marking parameters based on its token fill rate, i.e., min-rate, not the four rate-related marking parameters in this draft. The max-rate parameters in sections 3.3.2.5-6 ought to be specified against a second token bucket. In addition, the handling precedence algorithm in section 3.3.2.7 is an overly complex way to specify the relationship of two token buckets. All of this is even more important, because max-rate, as defined in RFC 2115, is only applicable to bursting - that max-rate for bursting often turns out to be an interface line rate, which is not generally useful for the traffic provisioning purposes of this draft. ##svshah, what you describe below conceptually very much makes sense and th= at is what we attempt to achieve. What is unclear though how to capture tha= t using TSpec definition specified in RFC2215. Since that TSpec definition = has both minimum-rate and maximum-rate, but no in/out profile marking param= eters. Is your proposal below to define two TSpecs using the same definition from = RFC2215? Wouldn't in that case we have min/max specified twice? min/max in = each TSpec? and thus confusing to represent one min and one max through two= TSpecs? David> See RFC 2698 for the desired behavior and the parameters needed to s= pecify it. The current idr-sla draft is not able to represent the traffic = conditioning mechanisms specified in both RFC 2698 and RFC 2697, as each me= chanism requires two token buckets (e.g., there are two burst sizes, but th= e idr-sla draft TSpec only contains one). This deficiency needs to be deal= t with. One possibility for simplification is to drop the max-rate from th= e RFC 2115 TSpec and assume that the max-rate for bursting is the effective= line rate. The following should be done instead: - Define TSpecs for two token buckets, a primary/committed token bu= cket and a secondary/peak token bucket that MUST be nested, i.e.= , traffic that is in-profile for the secondary/peak token bucket is a= lways in-profile for the primary/committed token bucket. Some of= the details of how to specify this are subtle, see RFC 2698 for a worke= d example. Use of a secondary/peak token bucket requires use of the pr= imary/ committed token bucket, but a primary/committed token bucke= t can be used without a secondary/peak token bucket. - For a single token bucket, define two handling TLVs, Committed (i= n profile) and Excess (out of profile). - For two token buckets, define three handling TLVs, Committed (in = profile for both token buckets), Peak (out of profile for primary/committed = token bucket, but in profile for secondary/peak token bucket) and Excess (out of= profile for both token buckets). NB: Could use Green/Yellow/Red terms instead of Committed/Peak/Excess terms. [4] The drop threshold TLV in section 3.3.2.8 is not specified sufficiently to be implemented interoperably. For example, I don't understand what an implementation is supposed to do when it receives 3 drop thresholds. ##svshah, It is around the semantics of a single queue with a different thr= eshold for a set of code-points, where packet for a specific code-point is = to be tail dropped if overall queue-depth hits code-point specific threshol= d at the arrival of that packet. We will add appropriate clarification for this semantics. David> Will look at revision [5] The relative priority TLV in section 3.3.2.9 has the same insufficient specification problem as the drop threshold TLV, compounded by a functional incompleteness problem - if the recipient is using a weighted packet transmission scheduler (e.g., WRR), priorities cannot be used to configure that scheduler. Hence, some specification of weights and scheduling algorithms that use weights needs to be added. ##svshah, Sure. Is following clarification okay? (some of the wordings take= n from RFC2598) " A higher priority class of traffic to be served without pre-empted by lower= priority class of traffic for more than a packet time at the configured ra= te. In the system that implements WRR, the use of relative priority may get res= tricted where a single queue may be used for a higher priority traffic clas= s where that queue is configured for the full share of the output bandwidt= h. " David> Last sentence basically says that WRR weights are out-of-scope. Tha= t seems wrong. Will look at revision. [6] I have no idea what the sub-traffic classes TLV in section 3.3.2.10 is supposed to do, as that TLV is specified based on "Traffic Class TLVs" which is an undefined term in this draft (e.g., that term is not used outside of section 3.3.2.10. ##svshah, They are to facilitate hierarchy. A specific Traffic Class, can f= urther be divided in a multiple subset of Traffic Classes, with their own = Traffic Class Elements and Traffic Class Services. Will correct the wording to remove your this specific concern. David> Will look at revision [7] This draft's QoS contents need to be functionally aligned with work-in-progress on YANG QoS models, in order to provide some assurance that that this draft is implementable for actual network switch/router data paths. The current acknowledgement of the existence of YANG, NETCONF and RESTConf at the end of Section 1 does not suffice. ##svshah, While eventually "Traffic Conditioning Agreement" should be trans= lated to the actual forwarding qos policy on any vendor specific device, TC= A exchange largely carries concepts/semantics that is either standard based= or well understood. While we are not aware of any working group document of QoS Yang Model, we = think that concepts of Traffic Conditioning should be easily adaptable to = any QoS Yang Models since they also have to be defined to support those con= cepts. David> Still want to see cross-check with implementations here. [8] There are significant complexity and correctness problems caused by the option to not specify the Source AS - e.g., Section 3.2 defines an SLA ID as an "identifier which is unique in the scope of Source AS" which is meaningless if there is no Source AS. It would be simpler to always specify Source AS, even in the point-to-point case. ##svshah, okay. Ron Bonica also suggested same in his review earlier. We ha= d chosen a path of optional Source AS to simplify implementations in cases.= Given specification of Source AS always is more clearer in multiple feed-b= ack we have gotten so far, we can modify the specification to incorporate t= hat over the simplicity of implementation for certain cases. David> OK, thanks. [9] In section 3.2, the "intended for the peer receiver of the BGP UPDATE message" text in the specification of bit 0 of the SLA Subtype flags is unclear. I suspect that this is intended to differentiate the two usages described in sections 4.1.1 (Point-to-Point) and 4.1.2 (Multiple Hops), in which case the parenthesized terms (or similar terminology) should be used with cross-references to those two sections. ##svshah, sure will make necessary changes, also in the context of earlier = comment. [10] There needs to be a coherent discussion in one place about how SLA advertisement, update and withdrawal work. A single ADVERTISE method may suffice on the wire, but the details on how initial advertisement, subsequent advertisement (update) and withdrawal work need to be specified in one place. The third paragraph of Section 4 is a start on this material, but it's too terse; [Med] That text is terse because we are reusing the BGP machinery for adver= tising/withdrawing; we only augment it with triggers that are linked to the= SLA information. A new SLA will lead to an update message with ADVERTISE, = an update of an existing SLA will trigger an update message. We do think th= is information is already present in the document. David>This is hard to understand it, as there is no statement that the BGP = machinery is being used, and the material on SLA usage is spread in differe= nt places. I suggest starting section 3 with a discussion of advertisement= /update/withdrawal, and how all three are realized via a single ADVERTISE m= ethod via BGP UPDATE - this was difficult to figure out in reading the curr= ent draft. it should be expanded into its own subsection, and moved earlier to come before the ADVERTISE method in Section 3.2. This text from Section 3.2 should be moved into that new subsection and likewise expanded: [Med] Another option is to move it Section 4. From our standpoint, we do th= ink it is straightforward to describe the behavior once the attributes form= at are defined. David> Ok, that=92s an editorial choice - I prefer to explain how something= works before defining its on-the-wire data format. If an advertised SLA ID is different from earlier advertised one, for the same prefix and from the same Source AS, indicates Source AS is advertising new SLA Content to replace the previous one advertised with the same SLA ID. In addition, I wonder whether functionality should be added to allow withdrawal of an advertisement by specifying its SLA ID, although that was not part of the original design. [Med] The reason we didn=92t adopted that design is that we don=92t want to= make assumptions on which data the remote peer will be used for enforcing = local actions and also because of this text: The SLA ID applies to aggregate traffic to prefixes for a given AFI/SAFI that share the same Source AS and SLA ID. David> That=92s fine, I wanted to ensure that this had been considered. Th= e discussion of BGP mechanism reuse will probably help here. [11] Notions of context for interpretation of all the IPFIX parameters in 3.3.1 need to be added, e.g.: - The first three parameters (DSCP, MPLS EXP field in top label, 80= 2.1q priority) can and do vary on a link-by-link or LSP-by-LSP basis along a t= raffic's network path. - The IP address parameters are rather likely to be VPN-specific wh= en there's more than one BGP/MPLS VPN that spans or transits the ASs involv= ed. - The transport port parameters need specification of which transpo= rt header and where it is located (e.g., for TCP traffic carried by in VXLAN, is t= his the inner TCP header or the outer UDP header in VXLAN). There are probably simple approaches to specifying context in all cases, but that context does need to be specified ... in all cases. [Med] We dind=92t include a context field because we thought that the defin= ition of the IPFIX attributes is sufficient by itself, but if you do think = it is helpful to have such information, we can update the table. David> Really??? Please reread the first comment above: - The first three parameters (DSCP, MPLS EXP field in top label, 80= 2.1q priority) can and do vary on a link-by-link or LSP-by-LSP basis along a t= raffic's network path. David> Taking just DSCP, it can change on a per-link basis, so something h= as to specify which link (between the SLA Producer and SLA Consumer?) is in= volved. It probably suffices to say that it=92s the link that crosses the = relevant AS boundary, but that does have to be stated, as it=92s nowhere to= be found in the far more general IPFIX registry. [12] The security considerations (section 10) are severely incomplete and insufficient: David> I stand by this statement and recommend a complete rewrite of the se= curity considerations. - Discussion of possible abuse of this BGP option for denial-of-ser= vice and theft-of-service, needs to be added, including possible countermeasures and m= itigations. [Med] This attack vector is not specific to this attribute; this is valid f= or BGP in general. David> There are additional attacks enabled by this attribute. - This sentence at the end of the second paragraph in Section 10 is= content-free: It is NOT RECOMMENDED to enable this attribute at the scale of the Internet unless if means to prevent leaking= sensitive information are enforced. What exactly is an implementer or admin supposed to do? [Med] An example of what an admin needs to check if this information can be= sent to a given peer or not. Some of the content of the attribute contains= some sensitive information such as contract Id, classes, etc. How does one figure out whether an implementation or deployment is "at = the scale of the Internet" ?? [Med] The idea here is to avoid leaking such data in to the global routing = table. Only entitled peers need receive such information with controlled sc= ope. David> I understand the idea - the problem is that I don=92t see specificat= ion of what has to be implemented in either the text in the draft or the ab= ove explanations. - The next to last paragraph in section 10 is almost content-free, = as it leaves decisions on implementation and deployment of key security = functionality as "an exercise for the reader" - that's not acceptable. [Med] I guess you are referring to the following text. Validation checks ar= e really deployment-specific. The text calls out the issue and recommends a= n action; how to translate this action into detailed actions is realty loca= l to a domain The attribute may be advertised by a misbehaving node to communicate SLA parameters that are not aligned with the SLA agreements. Though the enforcement of SLA parameters is outside the scope of this document, it is RECOMMENDED that the SLA Consumer to enforce a set of validation checks before translating the SLA parameters conveyed in the QoS attributes into provisioning actions. Such validations MAY rely on SLA parameters like the origin AS or SLA ID, like generating SLA ID using pseudo-random schemes [RFC4086]. David> I stand by the =93exercise to the reader=94 criticism - one way to = be honest about this would be to change the paragraph to: The attribute may be advertised by a misbehaving node to communicat= e SLA parameters that are not aligned with the SLA agreements. The enforcement of SLA parameters is outside the scope of this document. David> That does not change any normative content of the original paragraph= . My view is that the =93outside the scope of this document=94 statement i= s wrong because all of these parameters are being defined in this draft. - Last, but not least, the final paragraph in Section 10 is a joke = that will be lost on a security directorate reviewer - to understand = why, see Section 2 of RFC 6919, and take note of the publication dat= e of RFC 6919. David> For anyone who didn=92t catch the reference, RFC 6919 is an April 1 = RFC ... and the =93SHOULD BE considered=94 language used in the last securi= ty considerations paragraph of this draft is accurately characterized as va= gue in Section 2 of RFC 6919: The phrase "SHOULD CONSIDER" indicates that the authors of the specification think that implementations should do something, but they're not sure quite what. ------------------------ Having noted a dozen major issues, I'll end the review here for now, as I believe a serious revision of the draft is called for, which would be a better starting point to review for minor issues and editorial items. -------------------------------------------------------- David L. Black, Distinguished Engineer Dell EMC, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 Cell: +1 (978) 394-7754 David.Black@dell.com <=3D=3D=3D NEW =3D=3D=3D -------------------------------------------------------- --_000_DM3PR13MB0604AF5667DD40C1C569422AE5560DM3PR13MB0604namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable


Hi David,


We will add more text to clarify rationale for L2_OVERHEAD.


Do you have a preference or suggest a way to specify L2 rates? We will w= ork on defining 2 TSpecs to specify two rates (min and max). 


As far as VPN terminating between Consumer and Producer, I am not aware of = use-cases, at least in the context of the deployment scenario considered fo= r the draft.

Regards,
Shitanshu
From: Black, David <Davi= d.Black@dell.com>
Sent: Monday, February 27, 2017 10:42 AM
To: Shitanshu Shah; tsv-art@ietf.org
Cc: idr@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; ietf@iet= f.org; Black, David
Subject: RE: Review of draft-ietf-idr-sla-exchange-10
 

Ok, please make that ra= tionale for the L2_OVERHEAD parameter clear in the draft:

> Though fo= r the cases where physical links are not to be over-run, and= /or, sla defined are based on l2 rates, the Consumer would
> need to know l2 overhead from the Producer. Otherwise 10 byes of l2 ov= erhead difference on 64 bytes packets can be significant
> compare to on 1400 bytes packets, and thus the Producer does not have = a way to convert rates to ip based (this can cause
> functional issue), since this has to be per packet consideration.

It looks like the resul= t is that if the Producer=92s L2 overhead is larger than the Consumer=92s, = and the token buckets are specified in IP octets, the consumer has to calculate a per-packet charge of the L2 overhead difference against= the IP token bucket (and in the opposite case, there may be a per-packet c= redit).   Are there cases where the overhead is not all L2, e.g.,= SLA/TCA Consumer is using a VPN that terminates between Consumer and Producer?

 

Thanks, --David<= /p>

 

From: Shitan= shu Shah [mailto:shitanshu_shah@hotmail.com]
Sent: Friday, February 24, 2017 1:05 PM
To: Black, David; tsv-art@ietf.org
Cc: idr@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; ietf@iet= f.org
Subject: Re: Review of draft-ietf-idr-sla-exchange-10

 

 

Hi David,

 

One response inline ##svshah2

 

From: Black, David <David.Black@dell.com>
Sent: Friday, February 24, 2017 8:53 AM
To: Shitanshu Shah; tsv-art@ietf= .org
Cc: idr@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; ietf@ietf.org; Black, David
Subject: RE: Review of draft-ietf-idr-sla-exchange-10

 

David> In= line ...

 

Thanks, --Da= vid

 

From:= Shitanshu Shah [mailto:shitanshu_shah@hotmail.com]
Sent: Friday, February 24, 2017 4:09 AM
To: Black, David; tsv-art@ietf.o= rg
Cc: idr@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; ietf@ietf.org
Subject: Re: Review of draft-ietf-idr-sla-exchange-10

 =

 

Hi David,

 

Thank you for taking time for the review..

 

Please find our response inline ##svshah and [Med]

 

Regards,

Shitanshu

From: David Black <david.black@emc.com>
Sent: Tuesday, February 21, 2017 3:31 PM
To: tsv-art@ietf.org
Cc: idr@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; ietf@ietf.org
Subject: Review of draft-ietf-idr-sla-exchange-10

 

Reviewer: Davi= d Black
Review result: Not Ready

I've reviewed this document as part of the transport area
directorate's ongoing effort to review key IETF documents. These
comments were written primarily for the transport area directors, but
are copied to the document's authors for their information and to
allow them to address any issues raised. When done at the time of IETF
Last Call, the authors should consider this review together with any
other last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or= forward this review.

Document: draft-ietf-idr-sla-10
Reviewer: David Black
Review Date: February 21, 2017

Review result: Not Ready

This is an early TSV-ART review of a working group draft, requested by
the IDR Working Group.

This draft defines an extension to BGP to allow exchange of traffic
handling parameters (e.g., configured rates, burst sizes, drop
thresholds).  While this is a useful area of technology to standardize=
across network operators, this draft has significant problems, and
parts of it could use some serious rethought.

This reviewer has discussed small portions of this draft with some of
the authors in the past, but this is his first comprehensive reading
and review of the draft.

Major Issues:

[1] The draft is misnamed.  This is not an SLA (Service Level
Agreement) draft - it's a TCA (Traffic Conditioning Agreement) draft -
see the definition of TCA in RFC 2475.  This draft should start from that definition and generalize the applicability of TCA beyond
Diffserv.  Large areas of SLA content are not covered by this draft -<= br> for more details, see the Wikipedia article on SLA:
https://en.wikipedia.org/wiki/Service-lev= el_agreement .

##svshah, sure, we can change the term to TCA (Traffic Conditioning Agreeme= nt), which fairly represents intention in the draft, if there is no otherwi= se comment from the working group.

 <= span style=3D"color:black">


David> That would be good, thanks.

[2] Section 3.3.2.1's reuse of the TSpec construct from RFC 2115 to
specify a token bucket is a good idea, but it's not a good idea to
respecify that construct in terms of L2 (link-layer, e.g., Ethernet)
octets, as the RFC 2115 TSpec is specified in terms of IP octets.
This change to specification in terms of L2 octets results in needing
the L2_OVERHEAD TLV to cope with the possible differences in L2 (link)
framing overhead at sender and receiver of this information.  The
TSpec should be respecified at the IP layer, with L2 framing overhead
left to the Producer and Consumer to factor into their calculations
based on each's direct knowledge of L2 functionality and configuration
in the local AS.  That ought to enable elimination of the L2_OVERHEAD<= br> TLV, thereby reducing complexity.=

##svshah, the = purpose for advertising L2 overhead, from the Producer to the Consumer,&nbs= p;is to make sure traffic is well conditioned, at the egress of the Consumer, to avoid possible indiscriminate drops at the ingress o= f the Producer. In another words, the Producer is telling the Con= sumer to ignore its own link level overhead, instead use Producer's provide= d link level overhead while running frames through QoS functions (this is relevant in use-cases where l2 overhead of the=  egress link on Consumer and of ingress link on the Producer are of di= fferent size, e.g., in the vpn/tunnel connection between two peer = ;nodes which physically may be multiple hops away).

I understand y= our comments regarding re-using TSpec without any modification. Do you= agree with the use-case of l2 differences? If yes, any suggestion how to accommodate that?

 <= span style=3D"color:black">

David> Sp= ecifying this in terms of IP octets implies that L2 overhead is to be ignor= ed on both links.  That=92s simpler, and a few sentences of discussion about possible L2 framing differences should cover what needs to be done (= e.g., if traffic rates are configured in terms of L2 octets, then explain h= ow each entity converts between IP traffic and L2 traffic - the draft alrea= dy effectively contains that explanation).

 =

##svshah2, jus= t to make sure that some of the real use are not left out..

 =

For the traffi= c conditioning where sla established is for the ip based rates only, it suf= fices for the Producer to send rates only IP based ignoring any specific of l2 overheads.

 =

Though for the= cases where physical links are not to be over-run, and/or,&= nbsp;sla defined are based on l2 rates, the Consumer would need to kno= w l2 overhead from the Producer. Otherwise 10 byes of l2 overhead difference on 64 bytes= packets can be significant compare to on 1400 bytes packets, and thus the = Producer does not have a way to convert rates to ip based (this can ca= use functional issue), since this has to be per packet consideration.<= /p>

 =

Regards,

Shitanshu

 =

 =

 =


[3] A token bucket should have two rate-related marking parameters
based on its token fill rate, i.e., min-rate, not the four
rate-related marking parameters in this draft.  The max-rate
parameters in sections 3.3.2.5-6 ought to be specified against a
second token bucket.  In addition, the handling precedence algorithm in section 3.3.2.7 is an overly complex way to specify the
relationship of two token buckets.  All of this is even more
important, because max-rate, as defined in RFC 2115, is only
applicable to bursting - that max-rate for bursting often turns out to
be an interface line rate, which is not generally useful for the
traffic provisioning purposes of this draft.

 <= span style=3D"color:black">

##svshah, what= you describe below conceptually very much makes sense and that is what we = attempt to achieve. What is unclear though how to capture that using TSpec definition specified in RFC2215. Since that TSpec definit= ion has both minimum-rate and maximum-rate, but no in/out profile marking p= arameters.

 <= span style=3D"color:black">

Is your propos= al below to define two TSpecs using the same definition from RFC2215? = Wouldn't in that case we have min/max specified twice? min/max in each TSpec? and thus confusing to represent one min and one max through= two TSpecs?

 <= span style=3D"color:black">

David> Se= e RFC 2698 for the desired behavior and the parameters needed to specify it= .  The current idr-sla draft is not able to represent the traffic conditioning mechanisms specified in both RFC 2698 and RFC 2697, as each m= echanism requires two token buckets (e.g., there are two burst sizes, but t= he idr-sla draft TSpec only contains one).  This deficiency needs to b= e dealt with.  One possibility for simplification is to drop the max-rate from the RFC 2115 TSpec and assume that the max-ra= te for bursting is the effective line rate.


The following should be done instead:
        - Define TSpecs for two token bu= ckets, a primary/committed token bucket
            &nb= sp;   and a secondary/peak token bucket that MUST be nested, i.e.= , traffic
            &nb= sp;   that is in-profile for the secondary/peak token bucket is a= lways
            &nb= sp;   in-profile for the primary/committed token bucket.  So= me of the details
            &nb= sp;   of how to specify this are subtle, see RFC 2698 for a worke= d example.
            &nb= sp;   Use of a secondary/peak token bucket requires use of the pr= imary/
            &nb= sp;   committed token bucket, but a primary/committed token bucke= t can be used
            &nb= sp;   without a secondary/peak token bucket.
        - For a single token bucket, def= ine two handling TLVs, Committed (in profile) and
            &nb= sp;   Excess (out of profile).
        - For two token buckets, define = three handling TLVs, Committed (in profile for both
            &nb= sp;   token buckets), Peak (out of profile for primary/committed = token bucket, but in
            &nb= sp;   profile for secondary/peak token bucket) and Excess (out of= profile for both
            &nb= sp;   token buckets).
NB: Could use Green/Yellow/Red terms instead of Committed/Peak/Excess
terms.

[4] The drop threshold TLV in section 3.3.2.8 is not specified
sufficiently to be implemented interoperably.  For example, I don't understand what an implementation is supposed to do when it receives 3
drop thresholds.

##svshah, = ;It is around the semantics of a single queue with a different thresho= ld for a set of code-points, where packet for a specific code-point is to be tail dropped if overall queue-depth hits code-point specific thre= shold at the arrival of that packet.

We will add ap= propriate clarification for this semantics.

 <= span style=3D"color:black">

David> Will look at revision


[5] The relative priority TLV in section 3.3.2.9 has the same
insufficient specification problem as the drop threshold TLV,
compounded by a functional incompleteness problem - if the recipient
is using a weighted packet transmission scheduler (e.g., WRR),
priorities cannot be used to configure that scheduler.  Hence, some specification of weights and scheduling algorithms that use weights
needs to be added.

##svshah, Sure= . Is following clarification okay? (some of the wordings taken from RFC2598= )

 <= span style=3D"color:black">

"<= span style=3D"color:black">

A higher prior= ity class of traffic to be served without pre-empted by lower priority=  class of traffic for more than a packet time at the configured rate.

 <= span style=3D"color:black">

In the system = that implements WRR, the use of relative priority may get restricted where = a single queue may be used for a higher priority traffic class where that queue  is configured for the full share of the output band= width.

"<= span style=3D"color:black">

 <= span style=3D"color:black">

David> Last sentence basically says that WRR weights are out-of-= scope.  That seems wrong.  Will look at revision.

[6] I have no idea what the sub-traffic classes TLV in section
3.3.2.10 is supposed to do, as that TLV is specified based on "Traffic=
Class TLVs" which is an undefined term in this draft (e.g., that term<= br> is not used outside of section 3.3.2.10.=

##svshah, They= are to facilitate hierarchy. A specific Traffic Class, can further be divi= ded in a multiple  subset of Traffic Classes, with their own Traffic Class Elements and Traffic Class Services.

 <= span style=3D"color:black">

Will correct t= he wording to remove your this specific concern.


David> Will look at revision


[7] This draft's QoS contents need to be functionally aligned with
work-in-progress on YANG QoS models, in order to provide some
assurance that that this draft is implementable for actual network
switch/router data paths.  The current acknowledgement of the
existence of YANG, NETCONF and RESTConf at the end of Section 1 does
not suffice.

##svshah, Whil= e eventually "Traffic Conditioning Agreement" should be tran= slated to the actual forwarding qos policy on any vendor specific device, TCA exchange largely carries concepts/semantics that is either standard ba= sed or well understood.

 <= span style=3D"color:black">

While we are n= ot aware of any working group document of QoS Yang Model, we think that &nb= sp;concepts of Traffic Conditioning should be easily adaptable to any QoS Yang Models since they also have to be defined to support those= concepts.

 <= span style=3D"color:black">

 <= span style=3D"color:black">

David> St= ill want to see cross-check with implementations here.


[8] There are significant complexity and correctness problems caused
by the option to not specify the Source AS - e.g., Section 3.2 defines
an SLA ID as an "identifier which is unique in the scope of Source AS&= quot;
which is meaningless if there is no Source AS.  It would be simpler to=
always specify Source AS, even in the point-to-point case.

##svshah, okay. Ron Bonica also suggested same in his review earlier. We ha= d chosen a path of optional Source AS to simplify implementations in c= ases. Given specification of Source AS always is more clearer in multiple f= eed-back we have gotten so far, we can modify the specification to incorporate that over the simplicity of implem= entation for certain cases.

 

David> OK= , thanks.


[9] In section 3.2, the "intended fo= r the peer receiver of the BGP
UPDATE message" text in the specific= ation of bit 0 of the SLA Subtype
flags is unclear.  I suspect that th= is is intended to differentiate
the two usages described in sections 4.1.= 1 (Point-to-Point) and 4.1.2
(Multiple Hops), in which case the parent= hesized terms (or similar
terminology) should be used with cross-re= ferences to those two
sections.

##svshah, sure= will make necessary changes, also in the context of earlier comment.

 


[10] There needs to be a coherent discuss= ion in one place about how
SLA advertisement, update and withdrawal = work.  A single ADVERTISE
method may suffice on the wire, but the d= etails on how initial
advertisement, subsequent advertisement (= update) and withdrawal work
need to be specified in one place.  = The third paragraph of Section 4
is a start on this material, but it's too= terse; 

 

[Med] That text is terse because = we are reusing the BGP machinery for advertising/withdrawing; we only augme= nt it with triggers that are linked to the SLA information. A new SLA will lead to an update message with ADVERTISE, an update of an e= xisting SLA will trigger an update message. We do think this information is= already present in the document.

 

David>Thi= s is hard to understand it, as there is no statement that the BGP machinery= is being used, and the material on SLA usage is spread in different places.  I suggest starting section 3 with a discussion of advertisem= ent/update/withdrawal, and how all three are realized via a single ADVERTIS= E method via BGP UPDATE - this was difficult to figure out in reading the c= urrent draft.

 

it should be e= xpanded
into its own subsection, and moved earlie= r to come before the
ADVERTISE method in Section 3.2.  Th= is text from Section 3.2 should be
moved into that new subsection and likewi= se expanded:

[Med] Another option is to move it Section 4. From our stand= point, we do think it is straightforward to describe the behavior once the = attributes format are defined. 

 

David> Ok= , that=92s an editorial choice - I prefer to explain how something works be= fore defining its on-the-wire data format.

 

  &n= bsp;   If an advertised SLA ID is different from earlier advertis= ed one,
      for the sa= me prefix and from the same Source AS, indicates Source
      AS is adve= rtising new SLA Content to replace the previous one
      advertised= with the same SLA ID.

In addition, I wonder whether functionali= ty should be added to allow
withdrawal of an advertisement by specify= ing its SLA ID, although that
was not part of the original design.

 

[Med] The reason we didn=92t adopted that design is that we don=92= t want to make assumptions on which data the remote peer will be used for enforcing local actions and also because of this tex= t:

  = ;    The SLA ID applies to aggregate traffic to prefixes for= a given

  = ;    AFI/SAFI that share the same Source AS and SLA ID.

 

David> That=92s fine, I wanted to ensure that this had been cons= idered.  The discussion of BGP mechanism reuse will probably help here.

[11] Notions of context for interpretatio= n of all the IPFIX parameters
in 3.3.1 need to be added, e.g.:
       = ; - The first three parameters (DSCP, MPLS EXP field in top label, 802.1q priority) can
       = ;         and do vary on a link-by-= link or LSP-by-LSP basis along a traffic's network path.
       = ; - The IP address parameters are rather likely to be VPN-specific when there's more
       = ;         than one BGP/MPLS VPN tha= t spans or transits the ASs involved.
       = ; - The transport port parameters need specification of which transport header and where it
       = ;         is located (e.g., for TCP= traffic carried by in VXLAN, is this theinner TCP header
       = ;         or the outer UDP header i= n VXLAN).
There are probably simple approaches to s= pecifying context in all
cases, but that context does need to be s= pecified ... in all cases.

[Med] We dind=92t include a context field because we thought= that the definition of the IPFIX attributes is sufficient by itself, but i= f you do think it is helpful to have such information, we can update the table.

David>&nb= sp; Really???  Please reread the first comment above:

 

  &n= bsp;     - The first three parameters (DSCP, MPLS EXP f= ield in top label, 802.1q priority) can
       = ;         and do vary on a link-by-= link or LSP-by-LSP basis along a traffic's network path.

 

David>&nb= sp; Taking just DSCP, it can change on a per-link basis, so something has t= o specify which link (between the SLA Producer and SLA Consumer?) is involved.  It probably suffices to say that it=92s the link that c= rosses the relevant AS boundary, but that does have to be stated, as it=92s= nowhere to be found in the far more general IPFIX registry.

[12] The security considerations (section= 10) are severely incomplete
and insufficient:

 

David> I = stand by this statement and recommend a complete rewrite of the security co= nsiderations.


       = ; - Discussion of possible abuse of this BGP option for denial-of-service and theft-of-service,
       = ;         needs to be added, includ= ing possible countermeasures and mitigations.

[Med] This attack vector is not specific to this attribute; = this is valid for BGP in general.=

 

David> Th= ere are additional attacks enabled by this attribute.


       = ; - This sentence at the end of the second paragraph in Section 10 is content-free:

       = ;            It is N= OT RECOMMENDED to enable this attribute at the
       = ;            scale o= f the Internet unless if means to prevent leaking sensitive
       = ;            informa= tion are enforced.

       = ;         What exactly is an implem= enter or admin supposed to do? 

 

[Med] An example of what an admin= needs to check if this information can be sent to a given peer or not. Som= e of the content of the attribute contains some sensitive information such as contract Id, classes, etc.

 

How does one
       = ;         figure out whether an imp= lementation or deployment is  "at the scale
       = ;         of the Internet" ??<= /span>

 

[Med] The idea here is to avoid l= eaking such data in to the global routing table. Only entitled peers need r= eceive such information with controlled scope.

 

David> I understand the idea - the problem is that I don=92t see= specification of what has to be implemented in either the text in the draft or the above explanations.=

        - The next to last paragra= ph in section 10 is almost content-free, as it leaves
       = ;         decisions on implementati= on and deployment of key security functionality as
       = ;         "an exercise for the= reader" - that's not acceptable.

[Med] I gues= s you are referring to the following text. Validation checks are really dep= loyment-specific. The text calls out the issue and recommends an action; how to translate this action into detailed actions i= s realty local to a domain

 &nbs=
p; The attribute may be advertised by a misbehaving node to communicate
 &nbs=
p; SLA parameters that are not aligned with the SLA agreements.  Thoug=
h
 &nbs=
p; the enforcement of SLA parameters is outside the scope of this
 &nbs=
p; document, it is RECOMMENDED that the SLA Consumer to enforce a set of
 &nbs=
p; validation checks before translating the SLA parameters conveyed in
 &nbs=
p; the QoS attributes into provisioning actions.  Such validations MAY=

 &nbs=
p; rely on SLA parameters like the origin AS or SLA ID, like generating
 &nbs=
p; SLA ID using pseudo-random schemes [RFC4086].

 

David> I = stand by the =93exercise to the reader=94  criticism - one way to be h= onest about this would be to change the paragraph to:

 =

       =
; The attribute may be advertised by a=
 misbehaving node to communicate<=
/pre>

 &nbs=
p; SLA parameters that are not aligned with the SLA agreements.  The


   enforcement of SLA paramete=
rs is outside the scope of this document.


 


David> That does not change any normative content of the=
 original paragraph.  My view is that the =93outside the scope of this=
 document=94 statement is wrong because all of these parameters are being d=
efined in this draft.


       = ; - Last, but not least, the final paragraph in Section 10 is a joke= that will
       = ;         be lost on a security dir= ectorate reviewer - to understand why, see
       = ;         Section 2 of RFC 6919, an= d take note of the publication date of RFC 6919.

David> For anyone who didn=92t catch the reference, RFC 6919 is an April= 1 RFC ... and the =93SHOULD BE considered=94 language used in the last sec= urity considerations paragraph of this draft is accurately characterized as= vague in Section 2 of RFC 6919:<= /p>

   T= he phrase "SHOULD CONSIDER" indicates that the authors of the

   s= pecification think that implementations should do something, but

   = they're not sure quite what.

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

Having noted a dozen major issues, I'll e= nd the review here for now,
as I believe a serious revision of the dr= aft is called for, which
would be a better starting point to revie= w for minor issues and
editorial items.

-----------------------------------------= ---------------
David L. Black, Distinguished Engineer
Dell EMC, 176 South St., Hopkinton, MA&nb= sp; 01748
+1 (508) 293-7953   &n= bsp; Cell: +1 (978) 394-7754
D= avid.Black@dell.com  <=3D=3D=3D NEW =3D=3D=3D -----------------------------------------= ---------------

--_000_DM3PR13MB0604AF5667DD40C1C569422AE5560DM3PR13MB0604namp_-- From nobody Tue Feb 28 13:00: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 207F01296E9; Tue, 28 Feb 2017 13:00:46 -0800 (PST) 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 vrExcRT934Iy; Tue, 28 Feb 2017 13:00:44 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 994131295B5; Tue, 28 Feb 2017 13:00:40 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id C1D561E32D; Tue, 28 Feb 2017 16:06:27 -0500 (EST) Date: Tue, 28 Feb 2017 16:06:27 -0500 From: Jeffrey Haas To: "Alvaro Retana (aretana)" Message-ID: <20170228210627.GB17448@pfrc.org> References: 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: Cc: "idr-chairs@ietf.org" , "draft-ietf-idr-bgp-extended-messages@ietf.org" , Susan Hares , "idr@ietf.org" Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 21:00:46 -0000 Alvaro, I'm not speaking for the authors. However, a few comments on your writeup: On Thu, Feb 23, 2017 at 07:17:05PM +0000, Alvaro Retana (aretana) wrote: > M1. Section 4. (Operation): “An implementation that supports the BGP > Extended Messages MUST be prepared to receive an UPDATE message that is > larger than 4096 bytes.“ Only UPDATEs? I know that the most likely case > for exceeding the 4k size is an UPDATE, but why are the other messages not > considered? The fundamental issue is with regards to not only the basic behavior of RFC 4271 and its earlier RFC 1771 but also to BGP Versioning. Those RFCs set the expectation that version 4 of BGP will have at most a 4k packet size. Capability advertisement, an extension on top of BGP, isn't a required feature - although it's certainly very common these days. Thus, for backward compatibility reasons, OPEN messages must be no bigger than 4k if we're still BGP-4. I don't think there's an argument for larger KEEPALIVE messages. :-) Similarly, the NOTIFICATION with no restrictions for version compatibility reasons. *However*, once BGP has reached the Established state, it is possible for it to send longer NOTIFICATION messages, if we permitted it and the feature was duly negotiated. This is probably not the best idea because it will still be necessary to be able to deal with an old speaker in such cases. Also, most implementations don't dump that much information in the NOTIFICATION Data section. Putting sufficient semantics on the content would start to get messy. We don't want XML or backtrace over that message. The case for UPDATE is clear. The remaining message with some potential motivation is ROUTE-REFRESH. The basic refresh message is likely to be able to hold AFI/SAFI sets for some time. The ORF feature that is built upon refresh already deals with sending its filters over the course of multiple messages. So, there's not a lot of motivation. And that's the messages we have so far. While I can see new messages being defined that may want it, I don't think there's a strong argument for it today. > Also, what does “prepared to receive” > mean, and how can “MUST be prepared to receive” be enforced? Given the > discussion in Section 5 (Error Handling), you might want to add something > like “…even if the Capability is not advertised”. If the capability hasn't been negotiated, then the expectation is that it's a PDU error and the session should be dropped. See prior comments about BGP versioning. > M2. Section 5 (Error Handling). “A BGP speaker that has the ability to > use extended messages but has not advertised the BGP Extended Messages > capability, presumably due to configuration, SHOULD NOT accept an extended > message. A speaker MAY implement a more liberal policy and accept > extended messages even from a peer that has not advertised the > capability.” This paragraph troubles me a lot because it is in direct > contraction with Section 3: “A peer which does not advertise this > capability MUST NOT send BGP Extended Messages, and BGP Extended Messages > MUST NOT be sent to it.”. However, I think that John Scudder’s reasoning > [3] makes sense ("keep the session up at (almost) all costs", and there’s > clear precedence in the WG) for the case where the sender did advertise > the Capability, but I’m not convinced on the case where it didn’t – please > include something like John’s explanation in the text. John can own this one. I find the case a little weaker. It vaguely makes me want a probe message to verify that I can indeed get a full-sized PDU through. > M5. Section 5 (Error Handling). “The inconsistency between the local and > remote BGP speakers MUST be reported via syslog and/or SNMP.” SNMP? > AFAIK, there’s no object that can report this inconsistency since there’s > no NOTIFICATION generated. In the proposed text by Gunter Van De Velde > [4], SNMP and syslog were mentioned as examples – I suggest you follow > that path (no need for all the “flowery language”) and just reference > mechanisms by example to avoid having to point at how it would be done. IMO, "brought to the attention of the operator. Example mechanisms might include syslog or SNMP notifications." While you're correct that no IETF standard MIB object covers such a scenario, we shouldn't be proscriptive about some vendor deciding they want it in their enterprise implementation. At some point, we need similar boilerplate language for yang notifications. > M7. What about transition/migration/partial deployment? What should the > behavior be if, for example, an Extended Message UPDATE is received from a > peer, but can’t be propagated to others because they don’t support > Extended Messages (think route reflectors or simple eBGP -> iBGP)?? There > should be some guidance for the general case (i.e. when the total size is > >4k due simply to the total amount of information, and not because a > single attribute, for example, is really big), and some requirements > looking forward to potential new messages/attributes that specifically > rely on Extended Messages. I'm not sure such guidance belongs in this document. We already have scenarios wherein normal protocol machinery can result in messages that are too large. The expected behavior is "treat as withdraw" to the next downstream, similar to the BGP Error handling RFC. Examples of this include AS_PATH or CLUSTER_LIST attributes needing to add a new entry on a full PDU. > M7.2. What should the default be for this extension? Should it be enabled by default or not? IMO, there are good reasons to not turn it on for existing BGP deployments but alternatively good reasons once the extension is widely enough present in a given topology. The latter example includes bgpsec. -- Jeff From nobody Tue Feb 28 13:39: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 6121A127ABE; Tue, 28 Feb 2017 13:39:00 -0800 (PST) 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 grXv8rtSHeyu; Tue, 28 Feb 2017 13:38:58 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id B3CD3127071; Tue, 28 Feb 2017 13:38:58 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 439191E32D; Tue, 28 Feb 2017 16:44:46 -0500 (EST) Date: Tue, 28 Feb 2017 16:44:46 -0500 From: Jeffrey Haas To: Geoff Huston Message-ID: <20170228214445.GC17448@pfrc.org> References: <9C5FD3EFA72E1740A3D41BADDE0B461FC61A7A91@szxema506-mbs.china.huawei.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: Cc: draft-ietf-idr-flowspec-interfaceset.all@ietf.org, idr wg , "Yemin \(Amy\)" , rtg-dir@ietf.org Subject: Re: [Idr] Routing directorate QA review of draft-ietf-idr-flowspec-interfaceset X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 21:39:00 -0000 Geoff, Thank you for your comments. On Mon, Feb 27, 2017 at 02:02:05PM +1100, Geoff Huston wrote: > Here’s where I have a few issues that I found in reviewing this draft. > > The diagram in figures 1 and 2 appear to overuse the term “PE” - it > appears that this may or may not be a MPLS PE router, as in the context of > this draft it appears that they are simply EBGP speakers. It would be > helpful to clarify this. While I'm not aware of any specific IETF document clarifying such usage, PE is often an overloaded term among various Service Providers these days. While you are correct that PE in most IETF contexts tends to refer to the router fulfilling a MPLS LxVPN Provider Edge router, it's also become a term that is used interchangable as the router at the edge of the Service Provider's domain. That domain edge might be a MPLS LxVPN PE, or it might be an ASBR facing an entity that isn't the Service Provider. However, many Service Providers build their networks out of multiple-ASes, sometimes public, sometimes private - and they do so without the benefit of the BGP Confederations feature. This greying of the Service Provider administrative boundary is what I believe is contributing toward your comment. Given the above, do you have a preferred term you'd care to use? (As an aside, PE isn't even consistently used across various large providers. Figuring out their preferred alphabet soup of acronyms for the roles of their routers is always an interesting exercise.) > This brings on a second comment that the document is not overly clear > about the scope of intended application - the ability to declare filter > rules per interface appears to assume a detailed level of device > configuration that would only normally be accessible to a network > management - so that the intended scope of this form of flowspec > propagation is iBGP. But the example in section 2 appears to say > otherwise - the draft would benefit from some clarity over the intended > (and safe) scope of propagation of such interface flowspecs. As you may note above, there is some likelihood of the feature being used within the scope of multiple ASes under the control of the same Service Provider. You might note that an AS# is part of the encoding. This provides clarity for the receiving router as to the semantics of the Group Identifier, which will be defined by that AS's network. I do note that the draft isn't sufficiently descriptive about the use of that field. > The third comment is that the draft is a mix of motivation for the desired > mechanism, advocating the chosen solution, and the protocol mechanisms > (extension to BGP extended community set). My own personal taste is to > split this to a document about the need, and a seperate document about the > protocol mechanism and the related IANA considerations. Such motivational documents are not terribly common in IDR and I wouldn't advocate for one. But you do make good points later on that the discussion of the flowspec distributed ACL case that makes use of the proposed mechanism does muddle things. > The fourth comment is that the section “Security Considerations” appears > to also contain some critical design information that is conveniently > ignored in the rest of the draft. A broader document about the general > problem space and the strengths and weaknesses of various approaches to > automated traffic filter management in devices (see previous comment) > would be a better place to argue the relative merits of various forms of > network automation vs the use of signalling within BGP. Previous schools > of through were that flow spec signalling was an ideal approach to remote > (inter-AS) RBH signalling, while various in-house forms of network > management would be more approach to operate the local network. It is arguable that a better solution to your comment is to simply restrict the considerations to the impact of this feature upon the existing RFC 5575 feature and its deployment. The broader context of using BGP flowspec for domain-wide ACL management, while being one of the use cases of the feature described in this document, is not the sole motivation. > This draft > does not appear to to clearly state exactly what problem it is solving. If > it is trying to perform remote filter management in Other Peoples Networks > then there are huge security implications. The draft conveniently waves > its hands about the group identifier and its intended interpretation. This > is a large conceptual hole in the draft imho. The second part of this is > also touched upon in a passing comment in the Security Considerations, > that these filters are ephemeral in nature, as compared to a more > ‘conventional’ network management tool that would maintain filters as > configured elements in the device. Given the comments above, I think I agree. Our document should start by describing the protocol mechanism and the gap that it is filling in the current flow-spec ecosystem. That gap being that flow-spec filters apply to *all* interfaces in *all* directions, which may result in improper filtering. (Note that targeted BGP sessions with the routes set with the NO_ADVERTISE community is one way this is mitigated in some deployments.) > I think what is missing relates to the observation that sure, you CAN > stuff this into BGP using extended communities, but SHOULD we do this? > What are the reasons why this particular approach makes sense over and > above other existing tools and approaches. If the role of this WG is to > document everything we COULD do in BGP then the workload may well be > infinite - if the role is to document what we SHOULD be specifying as a > BGP-based tool then this would make more sense. As a result, I suspect > that this draft could benefit from some operational perspectives. Does > this materially help network operators in attempting to respond to DDOS > attacks? Or is it just another tool in an environment already replete with > various tools and technique and as such limited adoption would imply that > it would be effectively unused by network operators. The feature is operationally motivated. In particular, this early review was motivated by looking for a community assignment so that running code could start getting deployed without squatting on an arbitrary code point. And that said, one option open to the authors and implementors is simply requesting first-come, first-served. We do appreciate the thorough review. > Obviously I am at this point unconvinced that it “makes sense” in the > broader sense, and rather than trying to add more words to a single > document it may be helpful to look at splitting the specification of the > proposed mechanism and the IANA instructions and the discussion of why > this particular approach to distributed filter management makes more sense > than what current operational practices rely on. We'll take that under consideration for the next revision. -- Jeff